From sip-admin@ietf.org Tue Oct 1 07:21:59 2002 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 HAA08465 for ; Tue, 1 Oct 2002 07:21:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91BNRv15678 for ; Tue, 1 Oct 2002 07:23:27 -0400 Date: Tue, 01 Oct 2002 07:23:27 -0400 Message-ID: <20021001112327.2977.71030.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@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. If you have questions, problems, comments, etc, send them to mailman-owner@. 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 Wed Oct 2 17:50:27 2002 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 RAA09116; Wed, 2 Oct 2002 17:50:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92LpJv22771; Wed, 2 Oct 2002 17:51:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g92LnLv22684 for ; Wed, 2 Oct 2002 17:49:21 -0400 Received: from khem.blackfedora.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09094 for ; Wed, 2 Oct 2002 17:47:14 -0400 (EDT) Received: (from mark@localhost) by khem.blackfedora.com (8.11.2/8.11.2) id g92LnCZ05334; Wed, 2 Oct 2002 14:49:12 -0700 X-Authentication-Warning: khem.blackfedora.com: mark set sender to mra@pobox.com using -f To: dhcwg@ietf.org From: Mark Atwood Date: 02 Oct 2002 14:49:12 -0700 Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] SNMP on DHCP *client* 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 asked this on the developer list for net-snmp, and they recommended I come here and ask. Is there a "right place" for SNMP variables for a DHCP *client*? I was somewhat surprised not to see anything like that in rfc1213/rfc1573. What I mean is, I would like to ask the question "was this address configured manually, or via DHCP, (or by BOOTP, RARP, etc)?", "what is the lease time for this address?", etc. I could add this to my local vendor MIB, but if possible, I would really prefer to use an IETF RFC MIB. If such a RFC doesn't yet exist, maybe I should see if I can invest the effort to encourage one to come into existence... -- Mark Atwood | Well done is better than well said. mra@pobox.com | http://www.pobox.com/~mra _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 3 11:11:36 2002 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 LAA16141; Thu, 3 Oct 2002 11:11:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93FCUv25765; Thu, 3 Oct 2002 11:12:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91AZlv32400 for ; Tue, 1 Oct 2002 06:35:47 -0400 Received: from marge.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06485 for ; Tue, 1 Oct 2002 06:33:49 -0400 (EDT) Received: from antigen.bucknell.edu (antigen.bucknell.edu [134.82.9.20]) by marge.bucknell.edu (8.12.4/8.12.4) with ESMTP id g91AZhIB009052 for ; Tue, 1 Oct 2002 06:35:46 -0400 (EDT) Received: from mmcmail.megasoft.com (IDENT:root@[203.197.143.66]) by antigen.bucknell.edu (8.12.4/8.12.4) with SMTP id g91AZ5CR005045 for ; Tue, 1 Oct 2002 06:35:06 -0400 (EDT) Received: from wksmmc314 ([172.16.1.11]) by mmcmail.megasoft.com (8.9.3/8.9.3) with SMTP id QAA26043 for ; Tue, 1 Oct 2002 16:07:30 +0530 Message-ID: <001201c26937$6ea57490$0b0110ac@megasoft.com> From: "chandru" To: Date: Tue, 1 Oct 2002 16:13:51 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C26965.87F44060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MailScanner: Found to be clean Subject: [dhcwg] Hi 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_000F_01C26965.87F44060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20 I need a help, I am tester in megasoft, I am using Load Runner to = perofrm the performance testing=20 For Creating Virtual user we need to create IP , for that I used IP = wizard of LR , I am getting the following error=20 DHCP is not supported.=20 Can u help me how to solve this . Thnaks Chandru ------=_NextPart_000_000F_01C26965.87F44060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
I need a help, I am tester in megasoft, = I am using=20 Load Runner to perofrm the performance testing
 
For Creating Virtual user we need to = create IP ,=20 for that I used IP wizard of LR , I am getting the following error =
 
DHCP is not supported.
 
Can u help me how to solve this = .
 
Thnaks
Chandru
------=_NextPart_000_000F_01C26965.87F44060-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 3 11:16:04 2002 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 LAA16908; Thu, 3 Oct 2002 11:16:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93FHAv26254; Thu, 3 Oct 2002 11:17:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93F8Hv25559 for ; Thu, 3 Oct 2002 11:08:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15675; Thu, 3 Oct 2002 11:06:12 -0400 (EDT) Message-Id: <200210031506.LAA15675@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: dhcwg@ietf.org From: The IESG Date: Thu, 03 Oct 2002 11:06:12 -0400 Subject: [dhcwg] Protocol Action: Encoding Long DHCP Options to Proposed Standard 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 IESG has approved the Internet-Draft 'Encoding Long DHCP Options' as a Proposed Standard. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This document specifies the processing rules for DHCP options that appear multiple times in the same message. The need to send multiple instances of the same option occurs when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order that it place it within a DHCP packet in the "file" or "sname" field. When multiple instances of the same option appear in a packet, the contents of the option are concatenated together prior to processing. Working Group Summary There was support for this document in the WG and no issues were raised during the Last Call. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 3 17:37:16 2002 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 RAA05978; Thu, 3 Oct 2002 17:37:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93LcLv18488; Thu, 3 Oct 2002 17:38:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g93LWwv17734 for ; Thu, 3 Oct 2002 17:32:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05842; Thu, 3 Oct 2002 17:30:45 -0400 (EDT) Message-Id: <200210032130.RAA05842@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: dhcwg@ietf.org From: The IESG Date: Thu, 03 Oct 2002 17:30:45 -0400 Subject: [dhcwg] Resend with Corrected ID Version: Protocol Action: Encoding Long DHCP Options to Proposed Standard 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 IESG has approved the Internet-Draft 'Encoding Long DHCP Options' as a Proposed Standard. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This document specifies the processing rules for DHCP options that appear multiple times in the same message. The need to send multiple instances of the same option occurs when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order that it place it within a DHCP packet in the "file" or "sname" field. When multiple instances of the same option appear in a packet, the contents of the option are concatenated together prior to processing. Working Group Summary There was support for this document in the WG and no issues were raised during the Last Call. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 13:59:40 2002 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 NAA24076; Tue, 8 Oct 2002 13:59:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98I0lv19801; Tue, 8 Oct 2002 14:00:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98Hq0v19357 for ; Tue, 8 Oct 2002 13:52:00 -0400 Received: from e35.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23692 for ; Tue, 8 Oct 2002 13:49:50 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g98Hphxf074112; Tue, 8 Oct 2002 13:51:43 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g98Hpgtr019142; Tue, 8 Oct 2002 11:51:42 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g98Ho1b27921; Tue, 8 Oct 2002 13:50:01 -0400 Message-Id: <200210081750.g98Ho1b27921@rotala.raleigh.ibm.com> To: Kim Kinnear cc: rdroms@cisco.com, dhcwg@ietf.org In-Reply-To: Message from Kim Kinnear of "Mon, 07 Oct 2002 10:59:40 EDT." <4.3.2.7.2.20021007105541.058707d0@goblet.cisco.com> Date: Tue, 08 Oct 2002 13:50:01 -0400 From: Thomas Narten Subject: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection 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: , Hi Kim. > I was trying to recover some lost ground and figure out where the > drafts which I am editing are in the process. The following mail > is the last on the subject of the subnet-selection sub-option > that I can find in my mail archives. This document is tied up in IESG unhappiness with the WGs dealing with security issues. Basically, the IESG thinks that the overall security model of relay agent option is rather inadequate (it assumes that the entire network from the relay agent to the DHC servers is trustable/secure). This is not a new issue; it was a concern back when the original relay agent option document was approved. However, the WG keeps sending new relay agent options to the IESG without also working on the security model. One thing that was pointed out was that other WGs have been told flat out "no approval until you get a realistic security story". So, the issue that was raised was why should the DHC WG be held to a lesser standard. What the IESG wants to see is a credible story for the WG will get deployable/useable DHC security. In the case of the relay agent option, the technical issues seem fairly straightforward. Because relay-agents need to be configured, and because relay agents only need to talk (securely) with DHC servers, the key distribution problem can be handled via static keys/configuration. Bottom line: the IESG wants an updated charter that has a reasonable story for getting better security, together with an indication that there is meat behind the wording (e.g., a draft, and/or a design team that includes security clueful folk, etc.) Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 14:15:56 2002 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 OAA24877; Tue, 8 Oct 2002 14:15:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98IH8v21240; Tue, 8 Oct 2002 14:17:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98IGwv21217 for ; Tue, 8 Oct 2002 14:16:58 -0400 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 OAA24836 for ; Tue, 8 Oct 2002 14:14:47 -0400 (EDT) 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 g98IGqj08419; Tue, 8 Oct 2002 13:16:52 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g98IGqC21413; Tue, 8 Oct 2002 13:16:52 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PANK63>; Tue, 8 Oct 2002 13:16:52 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , Kim Kinnear Cc: rdroms@cisco.com, dhcwg@ietf.org Subject: RE: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection Date: Tue, 8 Oct 2002 13:16:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26EF6.DF8CAC86" 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_01C26EF6.DF8CAC86 Content-Type: text/plain; charset="iso-8859-1" Thomas: Perhaps I shouldn't raise this, but it seems like we should be worrying much more about security on the first hop (client <-> server/relay) than the relay <-> server hop. The latter is much easier to secure as IPsec, tunneling, and other fairly standard techniques could be used. Also, is the DHCPv6 draft strong enough in this area to satisfy the IESG (at least around the relay <-> server security)? - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Tuesday, October 08, 2002 1:50 PM To: Kim Kinnear Cc: rdroms@cisco.com; dhcwg@ietf.org Subject: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection Hi Kim. > I was trying to recover some lost ground and figure out where the > drafts which I am editing are in the process. The following mail > is the last on the subject of the subnet-selection sub-option > that I can find in my mail archives. This document is tied up in IESG unhappiness with the WGs dealing with security issues. Basically, the IESG thinks that the overall security model of relay agent option is rather inadequate (it assumes that the entire network from the relay agent to the DHC servers is trustable/secure). This is not a new issue; it was a concern back when the original relay agent option document was approved. However, the WG keeps sending new relay agent options to the IESG without also working on the security model. One thing that was pointed out was that other WGs have been told flat out "no approval until you get a realistic security story". So, the issue that was raised was why should the DHC WG be held to a lesser standard. What the IESG wants to see is a credible story for the WG will get deployable/useable DHC security. In the case of the relay agent option, the technical issues seem fairly straightforward. Because relay-agents need to be configured, and because relay agents only need to talk (securely) with DHC servers, the key distribution problem can be handled via static keys/configuration. Bottom line: the IESG wants an updated charter that has a reasonable story for getting better security, together with an indication that there is meat behind the wording (e.g., a draft, and/or a design team that includes security clueful folk, etc.) Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C26EF6.DF8CAC86 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection

Thomas:

Perhaps I shouldn't raise this, but it seems like we should be worrying much
more about security on the first hop (client <-> server/relay) than the
relay <-> server hop. The latter is much easier to secure as IPsec, tunneling,
and other fairly standard techniques could be used.

Also, is the DHCPv6 draft strong enough in this area to satisfy the IESG (at
least around the relay <-> server security)?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Tuesday, October 08, 2002 1:50 PM
To: Kim Kinnear
Cc: rdroms@cisco.com; dhcwg@ietf.org
Subject: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection


Hi Kim.

> I was trying to recover some lost ground and figure out where the
> drafts which I am editing are in the process.  The following mail
> is the last on the subject of the subnet-selection sub-option
> that I can find in my mail archives.

This document is tied up in IESG unhappiness with the WGs dealing with
security issues. Basically, the IESG thinks that the overall security
model of relay agent option is rather inadequate (it assumes that the
entire network from the relay agent to the DHC servers is
trustable/secure). This is not a new issue; it was a concern back when
the original relay agent option document was approved. However, the WG
keeps sending new relay agent options to the IESG without also working
on the security model.

One thing that was pointed out was that other WGs have been told flat
out "no approval until you get a realistic security story". So, the
issue that was raised was why should the DHC WG be held to a lesser
standard.

What the IESG wants to see is a credible story for the WG will get
deployable/useable DHC security. In the case of the relay agent
option, the technical issues seem fairly straightforward. Because
relay-agents need to be configured, and because relay agents only need
to talk (securely) with DHC servers, the key distribution problem can
be handled via static keys/configuration.

Bottom line: the IESG wants an updated charter that has a reasonable
story for getting better security, together with an indication that
there is meat behind the wording (e.g., a draft, and/or a design team
that includes security clueful folk, etc.)

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

------_=_NextPart_001_01C26EF6.DF8CAC86-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 15:01:16 2002 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 PAA26570; Tue, 8 Oct 2002 15:01:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98J2Nv23669; Tue, 8 Oct 2002 15:02:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98IxWv23491 for ; Tue, 8 Oct 2002 14:59:32 -0400 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 OAA26294 for ; Tue, 8 Oct 2002 14:57:21 -0400 (EDT) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g98ImE202361; Tue, 8 Oct 2002 13:48:14 -0500 (CDT) Date: Tue, 8 Oct 2002 13:59:08 -0500 Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Thomas Narten'" , Kim Kinnear , rdroms@cisco.com, dhcwg@ietf.org To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: Message-Id: <061142C8-DAF0-11D6-A9B4-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 > Perhaps I shouldn't raise this, but it seems like we should be > worrying much > more about security on the first hop (client <-> server/relay) than the > relay <-> server hop. The latter is much easier to secure as IPsec, > tunneling, > and other fairly standard techniques could be used. > > Also, is the DHCPv6 draft strong enough in this area to satisfy the > IESG (at > least around the relay <-> server security)? Right, the relay<->server hop is regular IP, so there's no reason not to use IPsec to secure it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 15:12:11 2002 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 PAA26956; Tue, 8 Oct 2002 15:12:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98JDOv24721; Tue, 8 Oct 2002 15:13:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98JCxv24671 for ; Tue, 8 Oct 2002 15:12:59 -0400 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 PAA26902 for ; Tue, 8 Oct 2002 15:10:48 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g98JAQaI028840; Tue, 8 Oct 2002 15:10:26 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g98JAOtr050398; Tue, 8 Oct 2002 13:10:25 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g98J8gq28110; Tue, 8 Oct 2002 15:08:42 -0400 Message-Id: <200210081908.g98J8gq28110@rotala.raleigh.ibm.com> To: "Bernie Volz (EUD)" cc: Kim Kinnear , rdroms@cisco.com, dhcwg@ietf.org Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection In-Reply-To: Message from "Bernie Volz (EUD)" of "Tue, 08 Oct 2002 13:16:51 CDT." Date: Tue, 08 Oct 2002 15:08:42 -0400 From: Thomas Narten 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: , > Perhaps I shouldn't raise this, but it seems like we should be > worrying much more about security on the first hop (client <-> > server/relay) than the relay <-> server hop. We should be worried about both. So, we do need to revisit the DHCP authentication stuff to come up with something more deployable. I.e, wouldn't it be nice to (say) before an IETF download a certificate that identifies the DHC servers that will be available (and trustable) while at the IETF meetings? > The latter is much > easier to secure as IPsec, tunneling, and other fairly standard > techniques could be used. Right. So, for the case of IPv4, it would be really nice to at least have this. Right now, we don't. > Also, is the DHCPv6 draft strong enough in this area to satisfy the > IESG (at least around the relay <-> server security)? Section 21.2 in the dhcpv6 doc seems good enough. Use IPsec, with static keys. This seems deployable/manageable, if not ideal. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 15:14:48 2002 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 PAA27113; Tue, 8 Oct 2002 15:14:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98JG2v24821; Tue, 8 Oct 2002 15:16:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98JFcv24803 for ; Tue, 8 Oct 2002 15:15:38 -0400 Received: from e31.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27029 for ; Tue, 8 Oct 2002 15:13:27 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g98JD06m033706; Tue, 8 Oct 2002 15:13:01 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g98JCutr229920; Tue, 8 Oct 2002 13:12:56 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g98JBEK28127; Tue, 8 Oct 2002 15:11:14 -0400 Message-Id: <200210081911.g98JBEK28127@rotala.raleigh.ibm.com> To: Ted Lemon cc: "Bernie Volz (EUD)" , Kim Kinnear , rdroms@cisco.com, dhcwg@ietf.org Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection In-Reply-To: Message from Ted Lemon of "Tue, 08 Oct 2002 13:59:08 CDT." <061142C8-DAF0-11D6-A9B4-00039367340A@nominum.com> Date: Tue, 08 Oct 2002 15:11:14 -0400 From: Thomas Narten 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: , Ted Lemon writes: > > Perhaps I shouldn't raise this, but it seems like we should be > > worrying much > > more about security on the first hop (client <-> server/relay) than the > > relay <-> server hop. The latter is much easier to secure as IPsec, > > tunneling, > > and other fairly standard techniques could be used. > > > > Also, is the DHCPv6 draft strong enough in this area to satisfy the > > IESG (at > > least around the relay <-> server security)? > Right, the relay<->server hop is regular IP, so there's no reason not > to use IPsec to secure it. In DHCPv6, using IPsec makes sense. The relay agent is originating a new message that it sends to the DHC server. But DHCPv4 is different, in that it relays the client packet. So IPsec can't really be used there. But certainly a DHC-specific authentication option could be defined for covering the relay agent option and/or portions of the client request. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 15:23:00 2002 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 PAA27520; Tue, 8 Oct 2002 15:23:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98JO9v25258; Tue, 8 Oct 2002 15:24:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98JMRv25173 for ; Tue, 8 Oct 2002 15:22:27 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27460 for ; Tue, 8 Oct 2002 15:20:16 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-107.cisco.com [161.44.150.107]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA01704; Tue, 8 Oct 2002 15:22:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20021008151605.00b72388@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Oct 2002 15:22:11 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection Cc: Ted Lemon , "Bernie Volz (EUD)" , Kim Kinnear , dhcwg@ietf.org In-Reply-To: <200210081911.g98JBEK28127@rotala.raleigh.ibm.com> References: <061142C8-DAF0-11D6-A9B4-00039367340A@nominum.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: , If I squint my eyes and stand back far enough, I don't see that the DHCPv4 case is different. While the relay agent is relaying a message on behalf of the client, it really is relaying that message in an independent UDP message, in which the source address belongs to the relay agent. I don't think there is any reason the relay agent and server can't employ IPsec on the relay agent<->server messages. Of course, IPsec may be problematic if there are multiple relay agents in the path - which is the problem Mark Stapp is trying to solve, right? - Ralph At 03:11 PM 10/8/2002 -0400, Thomas Narten wrote: >Ted Lemon writes: > > > > Perhaps I shouldn't raise this, but it seems like we should be > > > worrying much > > > more about security on the first hop (client <-> server/relay) than the > > > relay <-> server hop. The latter is much easier to secure as IPsec, > > > tunneling, > > > and other fairly standard techniques could be used. > > > > > > Also, is the DHCPv6 draft strong enough in this area to satisfy the > > > IESG (at > > > least around the relay <-> server security)? > > > Right, the relay<->server hop is regular IP, so there's no reason not > > to use IPsec to secure it. > >In DHCPv6, using IPsec makes sense. The relay agent is originating a >new message that it sends to the DHC server. > >But DHCPv4 is different, in that it relays the client packet. So IPsec >can't really be used there. But certainly a DHC-specific >authentication option could be defined for covering the relay agent >option and/or portions of the client request. > >Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 15:45:12 2002 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 PAA28324; Tue, 8 Oct 2002 15:45:12 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98JkJv26523; Tue, 8 Oct 2002 15:46:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98JjEv26502 for ; Tue, 8 Oct 2002 15:45:14 -0400 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 PAA28283 for ; Tue, 8 Oct 2002 15:43:03 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g98Jj8g12848; Tue, 8 Oct 2002 14:45:08 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g98Jj7127407; Tue, 8 Oct 2002 14:45:07 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PANQ5X>; Tue, 8 Oct 2002 14:45:07 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , Thomas Narten Cc: Ted Lemon , Kim Kinnear , dhcwg@ietf.org Subject: RE: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection Date: Tue, 8 Oct 2002 14:45:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26F03.332B1D26" 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_01C26F03.332B1D26 Content-Type: text/plain; charset="iso-8859-1" Why is IPsec a problem if you have multiple relays? If so, we may have the same issue with DHCPv6? In DHCPv4, each relay generates a new message so it can be subject to IPsec. The server must assume that the relay before it (the one it received the packet from) has sufficiently trusted the source (such as another relay) to relay the packet. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, October 08, 2002 3:22 PM To: Thomas Narten Cc: Ted Lemon; Bernie Volz (EUD); Kim Kinnear; dhcwg@ietf.org Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection If I squint my eyes and stand back far enough, I don't see that the DHCPv4 case is different. While the relay agent is relaying a message on behalf of the client, it really is relaying that message in an independent UDP message, in which the source address belongs to the relay agent. I don't think there is any reason the relay agent and server can't employ IPsec on the relay agent<->server messages. Of course, IPsec may be problematic if there are multiple relay agents in the path - which is the problem Mark Stapp is trying to solve, right? - Ralph At 03:11 PM 10/8/2002 -0400, Thomas Narten wrote: >Ted Lemon writes: > > > > Perhaps I shouldn't raise this, but it seems like we should be > > > worrying much > > > more about security on the first hop (client <-> server/relay) than the > > > relay <-> server hop. The latter is much easier to secure as IPsec, > > > tunneling, > > > and other fairly standard techniques could be used. > > > > > > Also, is the DHCPv6 draft strong enough in this area to satisfy the > > > IESG (at > > > least around the relay <-> server security)? > > > Right, the relay<->server hop is regular IP, so there's no reason not > > to use IPsec to secure it. > >In DHCPv6, using IPsec makes sense. The relay agent is originating a >new message that it sends to the DHC server. > >But DHCPv4 is different, in that it relays the client packet. So IPsec >can't really be used there. But certainly a DHC-specific >authentication option could be defined for covering the relay agent >option and/or portions of the client request. > >Thomas ------_=_NextPart_001_01C26F03.332B1D26 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection

Why is IPsec a problem if you have multiple relays? If so, we may have the same
issue with DHCPv6?

In DHCPv4, each relay generates a new message so it can be subject to IPsec.

The server must assume that the relay before it (the one it received the packet
from) has sufficiently trusted the source (such as another relay) to relay the
packet.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, October 08, 2002 3:22 PM
To: Thomas Narten
Cc: Ted Lemon; Bernie Volz (EUD); Kim Kinnear; dhcwg@ietf.org
Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection


If I squint my eyes and stand back far enough, I don't see that the DHCPv4
case is different.  While the relay agent is relaying a message on behalf
of the client, it really is relaying that message in an independent UDP
message, in which the source address belongs to the relay agent.  I don't
think there is any reason the relay agent and server can't employ IPsec on
the relay agent<->server messages.

Of course, IPsec may be problematic if there are multiple relay agents in
the path - which is the problem Mark Stapp is trying to solve, right?

- Ralph

At 03:11 PM 10/8/2002 -0400, Thomas Narten wrote:
>Ted Lemon <Ted.Lemon@nominum.com> writes:
>
> > > Perhaps I shouldn't raise this, but it seems like we should be
> > > worrying much
> > > more about security on the first hop (client <-> server/relay) than the
> > > relay <-> server hop. The latter is much easier to secure as IPsec,
> > > tunneling,
> > > and other fairly standard techniques could be used.
> > >
> > > Also, is the DHCPv6 draft strong enough in this area to satisfy the
> > > IESG (at
> > > least around the relay <-> server security)?
>
> > Right, the relay<->server hop is regular IP, so there's no reason not
> > to use IPsec to secure it.
>
>In DHCPv6, using IPsec makes sense. The relay agent is originating a
>new message that it sends to the DHC server.
>
>But DHCPv4 is different, in that it relays the client packet. So IPsec
>can't really be used there. But certainly a DHC-specific
>authentication option could be defined for covering the relay agent
>option and/or portions of the client request.
>
>Thomas

------_=_NextPart_001_01C26F03.332B1D26-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 15:46:54 2002 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 PAA28382; Tue, 8 Oct 2002 15:46:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98Jm2v26596; Tue, 8 Oct 2002 15:48:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98Jlmv26580 for ; Tue, 8 Oct 2002 15:47:48 -0400 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 PAA28357 for ; Tue, 8 Oct 2002 15:45:37 -0400 (EDT) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g98Jal202536; Tue, 8 Oct 2002 14:36:48 -0500 (CDT) Date: Tue, 8 Oct 2002 14:47:41 -0500 Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: dhcwg@ietf.org, rdroms@cisco.com, Kim Kinnear , "Bernie Volz (EUD)" To: Thomas Narten From: Ted Lemon In-Reply-To: <200210081911.g98JBEK28127@rotala.raleigh.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 > In DHCPv6, using IPsec makes sense. The relay agent is originating a > new message that it sends to the DHC server. > > But DHCPv4 is different, in that it relays the client packet. So IPsec > can't really be used there. But certainly a DHC-specific > authentication option could be defined for covering the relay agent > option and/or portions of the client request. IPsec is done at the IP header level. The IP header for the DHCPv4 relay agent is in fact newly-generated. So I don't see how this would be a problem. The difference between v4 and v6 relaying has to do with the format of the newly-generated packet, not with the IP header. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 15:49:06 2002 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 PAA28475; Tue, 8 Oct 2002 15:49:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98Jo2v26671; Tue, 8 Oct 2002 15:50:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98Jn7v26639 for ; Tue, 8 Oct 2002 15:49:07 -0400 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 PAA28407 for ; Tue, 8 Oct 2002 15:46:57 -0400 (EDT) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g98Jc6202546; Tue, 8 Oct 2002 14:38:06 -0500 (CDT) Date: Tue, 8 Oct 2002 14:49:00 -0500 Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: dhcwg@ietf.org, Kim Kinnear , "Bernie Volz (EUD)" , Thomas Narten To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20021008151605.00b72388@funnel.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 > Of course, IPsec may be problematic if there are multiple relay agents > in the path - which is the problem Mark Stapp is trying to solve, > right? Still not a problem, technically. You just have one security association for each DHCP agent pair, so if you have a double relay, you have two security associations. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 16:03:38 2002 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 QAA28863; Tue, 8 Oct 2002 16:03:38 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98K4kv27243; Tue, 8 Oct 2002 16:04:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98K1Cv27117 for ; Tue, 8 Oct 2002 16:01:12 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28750 for ; Tue, 8 Oct 2002 15:59:02 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-107.cisco.com [161.44.150.107]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA05077; Tue, 8 Oct 2002 16:01:02 -0400 (EDT) Message-Id: <4.3.2.7.2.20021008155721.00b80818@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Oct 2002 16:00:57 -0400 To: "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection Cc: Thomas Narten , Ted Lemon , Kim Kinnear , dhcwg@ietf.org 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: , Oh, right, if I remember correctly the IPsec trust is pairwise between relay agents and then between the last relay agent and the server. Not pretty to configure - but the configuration is reasonably static. - Ralph At 02:45 PM 10/8/2002 -0500, Bernie Volz (EUD) wrote: >Why is IPsec a problem if you have multiple relays? If so, we may have the >same >issue with DHCPv6? > >In DHCPv4, each relay generates a new message so it can be subject to IPsec. > >The server must assume that the relay before it (the one it received the >packet >from) has sufficiently trusted the source (such as another relay) to relay >the >packet. > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Tuesday, October 08, 2002 3:22 PM >To: Thomas Narten >Cc: Ted Lemon; Bernie Volz (EUD); Kim Kinnear; dhcwg@ietf.org >Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection > >If I squint my eyes and stand back far enough, I don't see that the DHCPv4 >case is different. While the relay agent is relaying a message on behalf >of the client, it really is relaying that message in an independent UDP >message, in which the source address belongs to the relay agent. I don't >think there is any reason the relay agent and server can't employ IPsec on >the relay agent<->server messages. > >Of course, IPsec may be problematic if there are multiple relay agents in >the path - which is the problem Mark Stapp is trying to solve, right? > >- Ralph > >At 03:11 PM 10/8/2002 -0400, Thomas Narten wrote: > >Ted Lemon writes: > > > > > > Perhaps I shouldn't raise this, but it seems like we should be > > > > worrying much > > > > more about security on the first hop (client <-> server/relay) than > the > > > > relay <-> server hop. The latter is much easier to secure as IPsec, > > > > tunneling, > > > > and other fairly standard techniques could be used. > > > > > > > > Also, is the DHCPv6 draft strong enough in this area to satisfy the > > > > IESG (at > > > > least around the relay <-> server security)? > > > > > Right, the relay<->server hop is regular IP, so there's no reason not > > > to use IPsec to secure it. > > > >In DHCPv6, using IPsec makes sense. The relay agent is originating a > >new message that it sends to the DHC server. > > > >But DHCPv4 is different, in that it relays the client packet. So IPsec > >can't really be used there. But certainly a DHC-specific > >authentication option could be defined for covering the relay agent > >option and/or portions of the client request. > > > >Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 16:56:58 2002 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 QAA00465; Tue, 8 Oct 2002 16:56:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98Kw5v30172; Tue, 8 Oct 2002 16:58:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g978Elv03835 for ; Mon, 7 Oct 2002 04:14:47 -0400 Received: from ns1.thmulti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10298 for ; Mon, 7 Oct 2002 04:12:27 -0400 (EDT) Received: from smtprelay2.thmulti.com (smtprelay2 [141.11.195.242]) by ns1.thmulti.com (8.9.3/8.9.1) with ESMTP id KAA26268 for ; Mon, 7 Oct 2002 10:14:26 +0200 (MET DST) Received: from parexch3.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay2.thmulti.com (8.9.3/8.9.1) with ESMTP id KAA29749 for ; Mon, 7 Oct 2002 10:14:25 +0200 (MET DST) Received: by parexch3 with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Oct 2002 10:14:24 +0200 Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090E33@edgmsmsg01.eu.thmulti.com> From: Van Aken Dirk To: "'dhcwg@ietf.org'" Cc: Dedecker Hans , Dekeyser Miek Date: Mon, 7 Oct 2002 10:14:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [dhcwg] - Classfull ? 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: , Hello Working group, Could it be that the "Link Selection sub-option for the Relay Agent Information Option" is a classfull option ? i.e. According this draft, the format of the sub-option is: >>>> SubOpt Len subnet IP address +------+------+------+------+------+------+ | TBD | 4 | a1 | a2 | a3 | a4 | +------+------+------+------+------+------+ The sub-option contains a single IP address that is an address con- tained in a subnet. The value for the subnet address is determined by taking any IP address on the subnet and ANDing that address with the subnet mask (i.e.: the network and subnet bits are left alone and the remaining (address) bits are set to zero). >>>> If I understand the above text correctly, a single (masked) IP address is added to this sub-option by the relay agent and submitted to the DHCP server. The latter will subsequently supply an address within the same subnet. I wonder though how the DHCP server can derive a subnet from a single quantity being an IP address. e.g. 20.0.0.0 can be an alias for 20.0.0.0/8 or 20.0.0.0/29. So my guess is that the only way the DHCP server can derive the subnet form is based on the leading bits of the address being either class A, B or C. Am I correct ? Thanks in advance - Dirk Dirk Van Aken THOMSON multimedia Broadband Belgium NV System Architect Prins Boudewijnlaan 47, Tel. : 03/443.65.08 2650 Edegem Fax.: 03/443.66.32 Belgium vanakend@thmulti.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 16:58:44 2002 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 QAA00660; Tue, 8 Oct 2002 16:58:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98Kxrv30225; Tue, 8 Oct 2002 16:59:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g978S7v04198 for ; Mon, 7 Oct 2002 04:28:07 -0400 Received: from ns1.thmulti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10485 for ; Mon, 7 Oct 2002 04:25:47 -0400 (EDT) Received: from smtprelay2.thmulti.com (smtprelay2 [141.11.195.242]) by ns1.thmulti.com (8.9.3/8.9.1) with ESMTP id KAA27758 for ; Mon, 7 Oct 2002 10:27:45 +0200 (MET DST) Received: from parexch3.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay2.thmulti.com (8.9.3/8.9.1) with ESMTP id KAA01182 for ; Mon, 7 Oct 2002 10:27:44 +0200 (MET DST) Received: by parexch3 with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Oct 2002 10:27:44 +0200 Message-ID: <421CB3B9B2D2F645B548D213C0A90E5583F8B9@edgmsmsg01.eu.thmulti.com> From: Van Aken Dirk To: "'dhcwg@ietf.org'" Cc: Dedecker Hans , Dekeyser Miek Date: Mon, 7 Oct 2002 10:27:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [dhcwg] Conflicting information regarding DHCP options 82 and 83. 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: , Hello DHCP Working Group, I have some conflicting information regarding the DHCP options defined below. i.e. On the IANA bootp-dhcp parameter list ( http://www.iana.org/assignments/bootp-dhcp-parameters ) I see the following options: 82 Agent Circuit ID N Agent Circuit ID 83 Agent Remote ID N Agent Remote ID On the other hand RFC3046 mentions the following": >>>> 2.0 Relay Agent Information Option This document defines a new DHCP Option called the Relay Agent Information Option. It is a "container" option for specific agent- supplied sub-options. The format of the Relay Agent Information option is: Code Len Agent Information Field +------+------+------+------+------+------+--...-+------+ | 82 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ The length N gives the total number of octets in the Agent Information Field. The Agent Information field consists of a sequence of SubOpt/Length/Value tuples for each sub-option, encoded in the following manner: SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 1 | N | s1 | s2 | s3 | s4 | | sN | +------+------+------+------+------+------+--...-+------+ SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 2 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ No "pad" sub-option is defined, and the Information field shall NOT be terminated with a 255 sub-option. The length N of the DHCP Agent Information Option shall include all bytes of the sub-option code/length/value tuples. Since at least one sub-option must be defined, the minimum Relay Agent Information length is two (2). The length N of the sub-options shall be the number of octets in only that sub-option's value field. A sub-option length may be zero. The sub-options need not appear in sub-option code order. The initial assignment of DHCP Relay Agent Sub-options is as follows: DHCP Agent Sub-Option Description Sub-option Code --------------- ---------------------- 1 Agent Circuit ID Sub-option 2 Agent Remote ID Sub-option >>>> So I wonder now if DHCP option 82 refers to the DHCP Relay Information option for which there are defined two sub-options (1: Agent Circuit ID Sub-option and 2: Agent Remote ID Sub-option"). Or do I misunderstand something here ? Thanks in advance - Dirk Dirk Van Aken THOMSON multimedia Broadband Belgium NV System Architect Prins Boudewijnlaan 47, Tel. : 03/443.65.08 2650 Edegem Fax.: 03/443.66.32 Belgium vanakend@thmulti.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 8 17:33:49 2002 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 RAA01555; Tue, 8 Oct 2002 17:33:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98LYwv32361; Tue, 8 Oct 2002 17:34:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g98LVsv32283 for ; Tue, 8 Oct 2002 17:31:54 -0400 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 RAA01471 for ; Tue, 8 Oct 2002 17:29:43 -0400 (EDT) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g98LKq203025; Tue, 8 Oct 2002 16:20:52 -0500 (CDT) Date: Tue, 8 Oct 2002 16:31:46 -0500 Subject: Re: [dhcwg] - Classfull ? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'dhcwg@ietf.org'" , Dedecker Hans , Dekeyser Miek To: Van Aken Dirk From: Ted Lemon In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090E33@edgmsmsg01.eu.thmulti.com> Message-Id: <590C54D2-DB05-11D6-A9B4-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 wonder though how the DHCP server can derive a subnet from a single > quantity being an IP address. e.g. 20.0.0.0 can be an alias for > 20.0.0.0/8 > or 20.0.0.0/29. > So my guess is that the only way the DHCP server can derive the subnet > form > is based on the leading bits of the address being either class A, B or > C. The DHCP server is configured with a list of subnets. It has to be, to make address assignment decisions. This is exactly the same problem that you have if you use giaddr for subnet selection. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 08:21:33 2002 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 IAA12384; Wed, 9 Oct 2002 08:21:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99CMev17564; Wed, 9 Oct 2002 08:22:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99CIpv17448 for ; Wed, 9 Oct 2002 08:18:51 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12283 for ; Wed, 9 Oct 2002 08:16:43 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ams-clip-vpn-dhcp4247.cisco.com [10.50.16.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA22812 for ; Wed, 9 Oct 2002 08:18:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20021004141513.03876e48@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Oct 2002 08:18:38 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] DHC WG meeting agenda, IETF 55 Atlanta (1st request) 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 dhc WG will meet 0900-1130, Monday, November 18. I'm compiling an agenda - please forward any agenda requests to me by Oct 14. Thanks... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 11:51:36 2002 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 LAA22830; Wed, 9 Oct 2002 11:51:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Fqgv31306; Wed, 9 Oct 2002 11:52:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Fpcv31222 for ; Wed, 9 Oct 2002 11:51:38 -0400 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 LAA22700 for ; Wed, 9 Oct 2002 11:49:28 -0400 (EDT) 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 17zJ7e-0005z9-00; Wed, 09 Oct 2002 08:51:42 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <4249T0XD>; Wed, 9 Oct 2002 08:52:47 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67480@homer.incognito.com.> From: "Kostur, Andre" To: "'Van Aken Dirk'" , "'dhcwg@ietf.org'" Cc: Dedecker Hans , Dekeyser Miek Subject: RE: [dhcwg] Conflicting information regarding DHCP options 82 and 83. Date: Wed, 9 Oct 2002 08:52:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FAB.E77CC600" 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_01C26FAB.E77CC600 Content-Type: text/plain; charset="iso-8859-1" I wonder if 83 was previously mentioned in a draft somewhere. However, RFC 3046 is authoritative on this matter, and option 82 is the one to look at. 82 currently has 2 defined sub-options (and I know of 2 or 3 more that are currently in draft) -----Original Message----- From: Van Aken Dirk [mailto:VanAkenD@thmulti.com] Sent: Monday, October 07, 2002 1:27 AM To: 'dhcwg@ietf.org' Cc: Dedecker Hans; Dekeyser Miek Subject: [dhcwg] Conflicting information regarding DHCP options 82 and 83. Hello DHCP Working Group, I have some conflicting information regarding the DHCP options defined below. i.e. On the IANA bootp-dhcp parameter list ( http://www.iana.org/assignments/bootp-dhcp-parameters ) I see the following options: 82 Agent Circuit ID N Agent Circuit ID 83 Agent Remote ID N Agent Remote ID On the other hand RFC3046 mentions the following": >>>> 2.0 Relay Agent Information Option This document defines a new DHCP Option called the Relay Agent Information Option. It is a "container" option for specific agent- supplied sub-options. The format of the Relay Agent Information option is: Code Len Agent Information Field +------+------+------+------+------+------+--...-+------+ | 82 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ The length N gives the total number of octets in the Agent Information Field. The Agent Information field consists of a sequence of SubOpt/Length/Value tuples for each sub-option, encoded in the following manner: SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 1 | N | s1 | s2 | s3 | s4 | | sN | +------+------+------+------+------+------+--...-+------+ SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 2 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ No "pad" sub-option is defined, and the Information field shall NOT be terminated with a 255 sub-option. The length N of the DHCP Agent Information Option shall include all bytes of the sub-option code/length/value tuples. Since at least one sub-option must be defined, the minimum Relay Agent Information length is two (2). The length N of the sub-options shall be the number of octets in only that sub-option's value field. A sub-option length may be zero. The sub-options need not appear in sub-option code order. The initial assignment of DHCP Relay Agent Sub-options is as follows: DHCP Agent Sub-Option Description Sub-option Code --------------- ---------------------- 1 Agent Circuit ID Sub-option 2 Agent Remote ID Sub-option >>>> So I wonder now if DHCP option 82 refers to the DHCP Relay Information option for which there are defined two sub-options (1: Agent Circuit ID Sub-option and 2: Agent Remote ID Sub-option"). Or do I misunderstand something here ? Thanks in advance - Dirk Dirk Van Aken THOMSON multimedia Broadband Belgium NV System Architect Prins Boudewijnlaan 47, Tel. : 03/443.65.08 2650 Edegem Fax.: 03/443.66.32 Belgium vanakend@thmulti.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C26FAB.E77CC600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Conflicting information regarding DHCP options 82 = and 83.

I wonder if 83 was previously mentioned in a draft = somewhere.  However, RFC 3046 is authoritative on this matter, and = option 82 is the one to look at.  82 currently has 2 defined = sub-options (and I know of 2 or 3 more that are currently in = draft)

-----Original Message-----
From: Van Aken Dirk [mailto:VanAkenD@thmulti.com]
Sent: Monday, October 07, 2002 1:27 AM
To: 'dhcwg@ietf.org'
Cc: Dedecker Hans; Dekeyser Miek
Subject: [dhcwg] Conflicting information regarding = DHCP options 82 and
83.


Hello DHCP Working Group,

I have some conflicting information regarding the = DHCP options defined
below. i.e. On the IANA bootp-dhcp parameter list = (
http://www.iana.org/assignments/bootp-dhcp-parameters<= /A> ) I see the following
options:

   82      Agent = Circuit ID         = N    Agent Circuit ID
   83      Agent = Remote ID          = N    Agent Remote ID

On the other hand RFC3046 mentions the = following":

>>>>
2.0 Relay Agent Information Option

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

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

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

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

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

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

          &nb= sp;      DHCP = Agent           &= nbsp;  Sub-Option Description
          &nb= sp;      Sub-option Code
          &nb= sp;      = ---------------         = ----------------------
          &nb= sp;          = 1            = ;       Agent Circuit ID = Sub-option
          &nb= sp;          = 2            = ;       Agent Remote ID Sub-option
>>>>

So I wonder now if DHCP option 82 refers to the DHCP = Relay Information
option for which there are defined two sub-options = (1: Agent Circuit ID
Sub-option and = 2:           &nbs= p;    Agent Remote ID Sub-option").

Or do I misunderstand something here ?

Thanks in advance - Dirk


Dirk Van = Aken           &n= bsp;           &n= bsp;      THOMSON multimedia Broadband
Belgium NV
System = Architect          &nb= sp;           &nb= sp;    Prins Boudewijnlaan 47,
Tel. : = 03/443.65.08          =             =   2650 Edegem
Fax.: = 03/443.66.32          =             =    Belgium
vanakend@thmulti.com


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

------_=_NextPart_001_01C26FAB.E77CC600-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 13:12:24 2002 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 NAA25977; Wed, 9 Oct 2002 13:12:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99HDSv04470; Wed, 9 Oct 2002 13:13:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99HAtv04400 for ; Wed, 9 Oct 2002 13:10:55 -0400 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 NAA25845 for ; Wed, 9 Oct 2002 13:08:44 -0400 (EDT) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id g99H8Bgl019397; Wed, 9 Oct 2002 11:10:48 -0600 (MDT) Received: from 147.191.89.201 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Wed, 09 Oct 2002 11:07:56 -0600 X-Server-Uuid: 90826C58-91B0-45EB-95A5-46B6D42E456F Received: by entexchimc02.tci.com with Internet Mail Service ( 5.5.2653.19) id <41CH17RR>; Wed, 9 Oct 2002 11:10:40 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBCD94@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Kostur, Andre'" , "'Van Aken Dirk'" , "'dhcwg@ietf.org'" cc: "Dedecker Hans" , "Dekeyser Miek" Subject: RE: [dhcwg] Conflicting information regarding DHCP options 82 and 83. Date: Wed, 9 Oct 2002 11:10:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11BABDE6221063-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 IANA seems to be a little more confused than we realize. Looking at http://www.iana.org/assignments/bootp-dhcp-parameters, I see: 82 Agent Circuit ID N Agent Circuit ID 83 Agent Remote ID N Agent Remote ID 84 Agent Subnet Mask N Agent Subnet Mask And then later on the same page: DHCP Agent Sub-Option Codes per [RFC3046] Code Sub-Option Description Reference ----- ----------------------- --------- 1 Agent Circuit ID Sub-option [RFC3046] 2 Agent Remote ID Sub-option [RFC3046] 3 Sub-option 3 is reserved and should [Droms] not be assigned at this time; proprietary and incompatible usages of this sub-option value have been seen limited deployment. 4 DOCSIS Device Class Suboption [RFC3256] It appears that IANA assigned three DHCP option codes (82-84) when only one DHCP option code was assigned in RFC 3046 (82). Note that an earlier draft of RFC 3046 had a third suboption, "Agent Subnet Mask Sub-option", that was removed prior to RFC publication -- this is why suboption 3 is "reserved". That's why I think option 84 should be part of this IANA cleanup. -- Rich -----Original Message----- From: Kostur, Andre [mailto:Andre@incognito.com] Sent: Wednesday, October 09, 2002 11:53 AM To: 'Van Aken Dirk'; 'dhcwg@ietf.org' Cc: Dedecker Hans; Dekeyser Miek Subject: RE: [dhcwg] Conflicting information regarding DHCP options 82 and 83. I wonder if 83 was previously mentioned in a draft somewhere. However, RFC 3046 is authoritative on this matter, and option 82 is the one to look at. 82 currently has 2 defined sub-options (and I know of 2 or 3 more that are currently in draft) -----Original Message----- From: Van Aken Dirk [mailto:VanAkenD@thmulti.com] Sent: Monday, October 07, 2002 1:27 AM To: 'dhcwg@ietf.org' Cc: Dedecker Hans; Dekeyser Miek Subject: [dhcwg] Conflicting information regarding DHCP options 82 and 83. Hello DHCP Working Group, I have some conflicting information regarding the DHCP options defined below. i.e. On the IANA bootp-dhcp parameter list ( http://www.iana.org/assignments/bootp-dhcp-parameters ) I see the following options: 82 Agent Circuit ID N Agent Circuit ID 83 Agent Remote ID N Agent Remote ID On the other hand RFC3046 mentions the following": >>>> 2.0 Relay Agent Information Option This document defines a new DHCP Option called the Relay Agent Information Option. It is a "container" option for specific agent- supplied sub-options. The format of the Relay Agent Information option is: Code Len Agent Information Field +------+------+------+------+------+------+--...-+------+ | 82 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ The length N gives the total number of octets in the Agent Information Field. The Agent Information field consists of a sequence of SubOpt/Length/Value tuples for each sub-option, encoded in the following manner: SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 1 | N | s1 | s2 | s3 | s4 | | sN | +------+------+------+------+------+------+--...-+------+ SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 2 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ No "pad" sub-option is defined, and the Information field shall NOT be terminated with a 255 sub-option. The length N of the DHCP Agent Information Option shall include all bytes of the sub-option code/length/value tuples. Since at least one sub-option must be defined, the minimum Relay Agent Information length is two (2). The length N of the sub-options shall be the number of octets in only that sub-option's value field. A sub-option length may be zero. The sub-options need not appear in sub-option code order. The initial assignment of DHCP Relay Agent Sub-options is as follows: DHCP Agent Sub-Option Description Sub-option Code --------------- ---------------------- 1 Agent Circuit ID Sub-option 2 Agent Remote ID Sub-option >>>> So I wonder now if DHCP option 82 refers to the DHCP Relay Information option for which there are defined two sub-options (1: Agent Circuit ID Sub-option and 2: Agent Remote ID Sub-option"). Or do I misunderstand something here ? Thanks in advance - Dirk Dirk Van Aken THOMSON multimedia Broadband Belgium NV System Architect Prins Boudewijnlaan 47, Tel. : 03/443.65.08 2650 Edegem Fax.: 03/443.66.32 Belgium vanakend@thmulti.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 13:41:03 2002 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 NAA26887; Wed, 9 Oct 2002 13:41:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Hg7v06144; Wed, 9 Oct 2002 13:42:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Hcuv05964 for ; Wed, 9 Oct 2002 13:38:56 -0400 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 NAA26789 for ; Wed, 9 Oct 2002 13:36:45 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g99HVLIm012467; Wed, 9 Oct 2002 10:31:21 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g99HVKtr024942; Wed, 9 Oct 2002 10:31:20 -0700 (PDT) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn1-9.cisco.com [10.82.224.9]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA26156; Wed, 9 Oct 2002 10:31:18 -0700 (PDT) Message-Id: <4.3.2.7.2.20021009132649.018c3f00@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Oct 2002 13:31:16 -0400 To: "Woundy, Richard" From: John Schnizlein Subject: RE: [dhcwg] Conflicting information regarding DHCP options 82 and 83. Cc: In-Reply-To: <6732623D2548D61193C90002A5C88DCC01EBCD94@entmaexch02.broad band.att.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: , And DHCP option 83 should also be part of this IANA cleanup. I recall a remark in an IETF plenary that IANA was still planning to clean up the assignments, and that DHCP options was recognized as needing work. Thanks for the historical explanation of the (erroneous) option 84. John At 01:10 PM 10/9/2002, Woundy, Richard wrote: >IANA seems to be a little more confused than we realize. > >Looking at http://www.iana.org/assignments/bootp-dhcp-parameters, I see: > > 82 Agent Circuit ID N Agent Circuit ID > 83 Agent Remote ID N Agent Remote ID > 84 Agent Subnet Mask N Agent Subnet Mask > >And then later on the same page: > >DHCP Agent Sub-Option Codes per [RFC3046] > >Code Sub-Option Description Reference >----- ----------------------- --------- > 1 Agent Circuit ID Sub-option [RFC3046] > 2 Agent Remote ID Sub-option [RFC3046] > 3 Sub-option 3 is reserved and should [Droms] > not be assigned at this time; > proprietary and incompatible usages > of this sub-option value have been > seen limited deployment. > 4 DOCSIS Device Class Suboption [RFC3256] > >It appears that IANA assigned three DHCP option codes (82-84) when only one >DHCP option code was assigned in RFC 3046 (82). > >Note that an earlier draft of RFC 3046 had a third suboption, "Agent Subnet >Mask Sub-option", that was removed prior to RFC publication -- this is why >suboption 3 is "reserved". That's why I think option 84 should be part of >this IANA cleanup. > >-- Rich _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 14:37:06 2002 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 OAA28915; Wed, 9 Oct 2002 14:37:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99IcHv09333; Wed, 9 Oct 2002 14:38:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Ibfv09306 for ; Wed, 9 Oct 2002 14:37:41 -0400 Received: from e32.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28843 for ; Wed, 9 Oct 2002 14:35:29 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g99IbOpw061772; Wed, 9 Oct 2002 14:37:24 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g99IbNHY204912; Wed, 9 Oct 2002 12:37:23 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g99IZa632120; Wed, 9 Oct 2002 14:35:36 -0400 Message-Id: <200210091835.g99IZa632120@rotala.raleigh.ibm.com> To: Ralph Droms cc: Ted Lemon , "Bernie Volz (EUD)" , Kim Kinnear , dhcwg@ietf.org Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection In-Reply-To: Message from Ralph Droms of "Tue, 08 Oct 2002 15:22:11 EDT." <4.3.2.7.2.20021008151605.00b72388@funnel.cisco.com> Date: Wed, 09 Oct 2002 14:35:36 -0400 From: Thomas Narten 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 I squint my eyes and stand back far enough, I don't see that the DHCPv4 > case is different. Conceptually similar, details are different. > While the relay agent is relaying a message on behalf > of the client, it really is relaying that message in an independent UDP > message, in which the source address belongs to the relay agent. Isn't the source address of the packet that of the client (and not the relay agent)? This makes a huge differences with regards to IPsec. Even worse, the client has no IP address yet, so the relayed packet has no source address... This can't be made to work trivially with stock IPsec. You'd need extensions I'd suspect, defeating much of the purpose of trying to use IPsec. Note that the above also factored into why DHC needed something specific to DHC rather than trying to somehow use IPsec. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 14:39:51 2002 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 OAA29034; Wed, 9 Oct 2002 14:39:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99If4v09521; Wed, 9 Oct 2002 14:41:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99IT3v08390 for ; Wed, 9 Oct 2002 14:29:03 -0400 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 OAA28579 for ; Wed, 9 Oct 2002 14:26:46 -0400 (EDT) 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 g99ISqj05849; Wed, 9 Oct 2002 13:28:52 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g99ISpe01391; Wed, 9 Oct 2002 13:28:52 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PAPF4H>; Wed, 9 Oct 2002 13:28:51 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'John Schnizlein'" , "Woundy, Richard" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Conflicting information regarding DHCP options 82 and 83. Date: Wed, 9 Oct 2002 13:28:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FC1.B66B5E3A" 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_01C26FC1.B66B5E3A Content-Type: text/plain; charset="iso-8859-1" How do we officially get these comments to IANA? Is this something Ralph would handle? I also recall that there was some past discussion on cleaning up the option assignments, to get some numbers reclaimed or removing some assignments that were not widely implemented and had no RFC behind them. I don't recall who volunteered to do it - I also didn't notice it in the recent WG Meeting Minutes. Below is an updated "BOOTP Vendor Extensions and DHCP Options" adding the RFC number for each option defined by an RFC. There was one draft that defined an option number explicitly and this was also included (some of the other option numbers may have been defined in earlier revisions of current drafts or in drafts that since have expired). Though I could have missed some as well! Data Tag Name Length Meaning --- ---- ------ ------- 0 Pad 0 None [RFC2132] 1 Subnet Mask 4 Subnet Mask Value [RFC2132] 2 Time Offset 4 Time Offset in [RFC2132] Seconds from UTC 3 Router N N/4 Router addresses [RFC2132] 4 Time Server N N/4 Timeserver addresses [RFC2132] 5 Name Server N N/4 IEN-116 Server addresses [RFC2132] 6 Domain Server N N/4 DNS Server addresses [RFC2132] 7 Log Server N N/4 Logging Server addresses [RFC2132] 8 Quotes Server N N/4 Quotes Server addresses [RFC2132] 9 LPR Server N N/4 Printer Server addresses [RFC2132] 10 Impress Server N N/4 Impress Server addresses [RFC2132] 11 RLP Server N N/4 RLP Server addresses [RFC2132] 12 Hostname N Hostname string [RFC2132] 13 Boot File Size 2 Size of boot file in 512 byte [RFC2132] chunks 14 Merit Dump File N Client to dump and name [RFC2132] the file to dump it to 15 Domain Name N The DNS domain name of the [RFC2132] client 16 Swap Server N Swap Server addeess [RFC2132] 17 Root Path N Path name for root disk [RFC2132] 18 Extension File N Path name for more BOOTP info [RFC2132] 19 Forward On/Off 1 Enable/Disable IP Forwarding [RFC2132] 20 SrcRte On/Off 1 Enable/Disable Source Routing [RFC2132] 21 Policy Filter N Routing Policy Filters [RFC2132] 22 Max DG Assembly 2 Max Datagram Reassembly Size [RFC2132] 23 Default IP TTL 1 Default IP Time to Live [RFC2132] 24 MTU Timeout 4 Path MTU Aging Timeout [RFC2132] 25 MTU Plateau N Path MTU Plateau Table [RFC2132] 26 MTU Interface 2 Interface MTU Size [RFC2132] 27 MTU Subnet 1 All Subnets are Local [RFC2132] 28 Broadcast Address 4 Broadcast Address [RFC2132] 29 Mask Discovery 1 Perform Mask Discovery [RFC2132] 30 Mask Supplier 1 Provide Mask to Others [RFC2132] 31 Router Discovery 1 Perform Router Discovery [RFC2132] 32 Router Request 4 Router Solicitation Address [RFC2132] 33 Static Route N Static Routing Table [RFC2132] 34 Trailers 1 Trailer Encapsulation [RFC2132] 35 ARP Timeout 4 ARP Cache Timeout [RFC2132] 36 Ethernet 1 Ethernet Encapsulation [RFC2132] 37 Default TCP TTL 1 Default TCP Time to Live [RFC2132] 38 Keepalive Time 4 TCP Keepalive Interval [RFC2132] 39 Keepalive Data 1 TCP Keepalive Garbage [RFC2132] 40 NIS Domain N NIS Domain Name [RFC2132] 41 NIS Servers N NIS Server Addresses [RFC2132] 42 NTP Servers N NTP Server Addresses [RFC2132] 43 Vendor Specific N Vendor Specific Information [RFC2132] 44 NETBIOS Name Srv N NETBIOS Name Servers [RFC2132] 45 NETBIOS Dist Srv N NETBIOS Datagram Distribution [RFC2132] 46 NETBIOS Node Type 1 NETBIOS Node Type [RFC2132] 47 NETBIOS Scope N NETBIOS Scope [RFC2132] 48 X Window Font N X Window Font Server [RFC2132] 49 X Window Manmager N X Window Display Manager [RFC2132] 50 Address Request 4 Requested IP Address [RFC2132] 51 Address Time 4 IP Address Lease Time [RFC2132] 52 Overload 1 Overload "sname" or "file" [RFC2132] 53 DHCP Msg Type 1 DHCP Message Type [RFC2132] 54 DHCP Server Id 4 DHCP Server Identification [RFC2132] 55 Parameter List N Parameter Request List [RFC2132] 56 DHCP Message N DHCP Error Message [RFC2132] 57 DHCP Max Msg Size 2 DHCP Maximum Message Size [RFC2132] 58 Renewal Time 4 DHCP Renewal (T1) Time [RFC2132] 59 Rebinding Time 4 DHCP Rebinding (T2) Time [RFC2132] 60 Class Id N Class Identifier [RFC2132] 61 Client Id N Client Identifier [RFC2132] 62 Netware/IP Domain N Netware/IP Domain Name [RFC2242] 63 Netware/IP Option N Netware/IP sub Options [RFC2242] 64 NIS-Domain-Name N NIS+ v3 Client Domain Name [RFC2132] 65 NIS-Server-Addr N NIS+ v3 Server Addresses [RFC2132] 66 Server-Name N TFTP Server Name [RFC2132] 67 Bootfile-Name N Boot File Name [RFC2132] 68 Home-Agent-Addrs N Home Agent Addresses [RFC2132] 69 SMTP-Server N Simple Mail Server Addresses [RFC2132] 70 POP3-Server N Post Office Server Addresses [RFC2132] 71 NNTP-Server N Network News Server Addresses [RFC2132] 72 WWW-Server N WWW Server Addresses [RFC2132] 73 Finger-Server N Finger Server Addresses [RFC2132] 74 IRC-Server N Chat Server Addresses [RFC2132] 75 StreetTalk-Server N StreetTalk Server Addresses [RFC2132] 76 STDA-Server N ST Directory Assist. Addresses[RFC2132] 77 User-Class N User Class Information [RFC3004] 78 Directory Agent N directory agent information [RFC2610] 79 Service Scope N service location agent scope [RFC2610] 80 Naming Authority N naming authority 81 Client FQDN N Fully Qualified Domain Name [DRAFT-IETF-DHC-FQDN-OPTION] 82 Relay Agent Information N Relay Agent Information [RFC3046] 83 Agent Remote ID N Agent Remote ID 84 Agent Subnet Mask N Agent Subnet Mask 85 NDS Servers N Novell Directory Services [RFC2241] 86 NDS Tree Name N Novell Directory Services [RFC2241] 87 NDS Context N Novell Directory Services [RFC2241] 88 IEEE 1003.1 POSIX N IEEE 1003.1 POSIX Timezone 89 FQDN N Fully Qualified Domain Name 90 Authentication N Authentication [RFC3118] 91 Vines TCP/IP N Vines TCP/IP Server Option 92 Server Selection N Server Selection Option 93 Client System N Client System Architecture 94 Client NDI N Client Network Device Interface 95 LDAP N Lightweight Directory Access Protocol 96 IPv6 Transitions N IPv6 Transitions 97 UUID/GUID N UUID/GUID-based Client Identifier 98 User-Auth N Open Group's User Authentication [RFC2485] 99 Unassigned 100 Printer Name N Printer Name 101 MDHCP N DHCP multicast address 102-107 REMOVED/Unassigned 108 Swap Path N Swap Path Option 109 Unassigned 110 IPX Compatability N IPX Compatability 111 Unassigned 112 Netinfo Address N NetInfo Parent Server Address 113 Netinfo Tag N NetInfo Parent Server Tag 114 URL N URL 115 Failover N DHCP Failover Protocol 116 Auto-Config N DHCP Auto-Configuration [RFC2563] 117 Name Service Search 2 Name Service Search [RFC2937] 118 Subnet Selection Option 4 Subnet Selection Option [RFC3011] 119 Domain Search N DNS domain serach list 120 SIP Servers DHCP Option N SIP Servers DHCP Option [RFC3361] 121 Unassigned 122 Unassigned 123 Unassigned 124 Unassigned 125 Unassigned 126 Extension N Extension 127 Extension N Extension 128-254 Private Use 255 End 0 None [RFC2132] - Bernie -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Wednesday, October 09, 2002 1:31 PM To: Woundy, Richard Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Conflicting information regarding DHCP options 82 and 83. And DHCP option 83 should also be part of this IANA cleanup. I recall a remark in an IETF plenary that IANA was still planning to clean up the assignments, and that DHCP options was recognized as needing work. Thanks for the historical explanation of the (erroneous) option 84. John At 01:10 PM 10/9/2002, Woundy, Richard wrote: >IANA seems to be a little more confused than we realize. > >Looking at http://www.iana.org/assignments/bootp-dhcp-parameters, I see: > > 82 Agent Circuit ID N Agent Circuit ID > 83 Agent Remote ID N Agent Remote ID > 84 Agent Subnet Mask N Agent Subnet Mask > >And then later on the same page: > >DHCP Agent Sub-Option Codes per [RFC3046] > >Code Sub-Option Description Reference >----- ----------------------- --------- > 1 Agent Circuit ID Sub-option [RFC3046] > 2 Agent Remote ID Sub-option [RFC3046] > 3 Sub-option 3 is reserved and should [Droms] > not be assigned at this time; > proprietary and incompatible usages > of this sub-option value have been > seen limited deployment. > 4 DOCSIS Device Class Suboption [RFC3256] > >It appears that IANA assigned three DHCP option codes (82-84) when only one >DHCP option code was assigned in RFC 3046 (82). > >Note that an earlier draft of RFC 3046 had a third suboption, "Agent Subnet >Mask Sub-option", that was removed prior to RFC publication -- this is why >suboption 3 is "reserved". That's why I think option 84 should be part of >this IANA cleanup. > >-- Rich _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C26FC1.B66B5E3A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Conflicting information regarding DHCP options 82 = and 83.

How do we officially get these comments to IANA? Is = this something Ralph
would handle?

I also recall that there was some past discussion on = cleaning up the
option assignments, to get some numbers reclaimed or = removing some
assignments that were not widely implemented and had = no RFC behind
them. I don't recall who volunteered to do it - I = also didn't notice
it in the recent WG Meeting Minutes.

Below is an updated "BOOTP Vendor Extensions and = DHCP Options" adding the RFC
number for each option defined by an RFC.

There was one draft that defined an option number = explicitly and this was
also included (some of the other option numbers may = have been defined in
earlier revisions of current drafts or in drafts = that since have expired).
Though I could have missed some as well!

          &nb= sp;           &nb= sp;           = Data
   Tag     = Name           &n= bsp;      Length  = Meaning         
   ---     = ----           &n= bsp;      ------  = -------         
    0      = Pad           &nb= sp;          = 0    = None           &n= bsp;           &n= bsp;  [RFC2132]   
    1      = Subnet = Mask           &n= bsp;  4    Subnet Mask = Value           &= nbsp; [RFC2132]
    2      = Time = Offset           =    4    Time Offset = in           &nbs= p;    [RFC2132]
          &nb= sp;           &nb= sp;           &nb= sp;      Seconds from UTC
    3      = Router           =         N    N/4 = Router addresses          = [RFC2132]
    4      = Time Server          &= nbsp;   N    N/4 Timeserver = addresses      [RFC2132]
    5      = Name = Server           =    N    N/4 IEN-116 Server addresses  = [RFC2132]
    6      = Domain = Server           = N    N/4 DNS Server = addresses      [RFC2132]
    7      = Log = Server           =     N    N/4 Logging Server = addresses  [RFC2132]
    8      = Quotes = Server           = N    N/4 Quotes Server addresses   = [RFC2132]
    9      = LPR = Server           =     N    N/4 Printer Server = addresses  [RFC2132]
   10      = Impress = Server           = N    N/4 Impress Server addresses  [RFC2132]
   11      RLP = Server           =     N    N/4 RLP Server = addresses      [RFC2132]
   12      = Hostname          &nbs= p;      N    Hostname = string           =     [RFC2132]
   13      Boot = File Size           = 2    Size of boot file in 512 byte [RFC2132]
          &nb= sp;           &nb= sp;           &nb= sp;      chunks
   14      Merit = Dump File          = N    Client to dump and = name       [RFC2132]
          &nb= sp;           &nb= sp;           &nb= sp;      the file to dump it to
   15      Domain = Name           &n= bsp;  N    The DNS domain name of = the    [RFC2132]
          &nb= sp;           &nb= sp;           &nb= sp;      client
   16      Swap = Server           =    N    Swap Server = addeess           = [RFC2132]
   17      Root = Path           &n= bsp;    N    Path name for root = disk       [RFC2132]
   18      = Extension = File           = N    Path name for more BOOTP info [RFC2132]
   19      = Forward = On/Off           = 1    Enable/Disable IP Forwarding  [RFC2132]
   20      SrcRte = On/Off           = 1    Enable/Disable Source Routing [RFC2132]
   21      Policy = Filter           = N    Routing Policy = Filters        [RFC2132]
   22      Max DG = Assembly          = 2    Max Datagram Reassembly Size  [RFC2132]
   23      = Default IP = TTL           = 1    Default IP Time to = Live       [RFC2132]
   24      MTU = Timeout           = ;   4    Path MTU Aging = Timeout        [RFC2132]
   25      MTU = Plateau           = ;   N    Path MTU  Plateau = Table       [RFC2132]
   26      MTU = Interface          &nb= sp; 2    Interface MTU = Size            = [RFC2132]
   27      MTU = Subnet           =     1    All Subnets are = Local         [RFC2132]
   28      = Broadcast Address        = 4    Broadcast = Address           = ;  [RFC2132]
   29      Mask = Discovery           = 1    Perform Mask = Discovery        [RFC2132]
   30      Mask = Supplier          &nbs= p; 1    Provide Mask to = Others        [RFC2132]
   31      Router = Discovery         = 1    Perform Router = Discovery      [RFC2132]
   32      Router = Request           = 4    Router Solicitation Address   = [RFC2132]
   33      Static = Route           &= nbsp; N    Static Routing = Table          = [RFC2132]
   34      = Trailers          &nbs= p;      1    Trailer = Encapsulation         = [RFC2132]
   35      ARP = Timeout           = ;   4    ARP Cache = Timeout           = ;  [RFC2132]
   36      = Ethernet          &nbs= p;      1    Ethernet = Encapsulation        = [RFC2132]
   37      = Default TCP TTL          = 1    Default TCP Time to = Live      [RFC2132]
   38      = Keepalive = Time           = 4    TCP Keepalive = Interval        [RFC2132]
   39      = Keepalive = Data           = 1    TCP Keepalive = Garbage         = [RFC2132]
   40      NIS = Domain           =     N    NIS Domain = Name           &n= bsp;   [RFC2132]
   41      NIS = Servers           = ;   N    NIS Server = Addresses          = [RFC2132]
   42      NTP = Servers           = ;   N    NTP Server = Addresses          = [RFC2132]
   43      Vendor = Specific          = N    Vendor Specific Information   = [RFC2132]
   44      = NETBIOS Name Srv         = N    NETBIOS Name = Servers          = [RFC2132]
   45      = NETBIOS Dist Srv         = N    NETBIOS Datagram Distribution [RFC2132]
   46      = NETBIOS Node Type        = 1    NETBIOS Node = Type           &n= bsp; [RFC2132]
   47      = NETBIOS = Scope            = N    NETBIOS = Scope           &= nbsp;     [RFC2132]
   48      X = Window = Font            = N    X Window Font = Server          = [RFC2132]
   49      X = Window Manmager        = N    X Window Display = Manager      [RFC2132]
   50      = Address Request          = 4    Requested IP Address     &n= bsp;    [RFC2132]
   51      = Address = Time           &n= bsp; 4    IP Address Lease = Time         [RFC2132]
   52      = Overload          &nbs= p;      1    Overload = "sname" or "file"    = [RFC2132]
   53      DHCP = Msg = Type            = 1    DHCP Message = Type           &n= bsp; [RFC2132]
   54      DHCP = Server Id           = 4    DHCP Server Identification    = [RFC2132]
   55      = Parameter = List           = N    Parameter Request = List        [RFC2132]
   56      DHCP = Message           = ;  N    DHCP Error = Message           = ; [RFC2132]
   57      DHCP = Max Msg Size        = 2    DHCP Maximum Message Size     = [RFC2132]
   58      = Renewal = Time           &n= bsp; 4    DHCP Renewal (T1) = Time        [RFC2132]
   59      = Rebinding = Time           = 4    DHCP Rebinding (T2) = Time      [RFC2132]
   60      Class = Id           &nbs= p;     N    Class = Identifier          &n= bsp;   [RFC2132]
   61      Client = Id           &nbs= p;    N    Client = Identifier          &n= bsp;  [RFC2132]
   62      = Netware/IP Domain        = N    Netware/IP Domain = Name        [RFC2242]
   63      = Netware/IP Option        = N    Netware/IP sub = Options        [RFC2242]
   64      = NIS-Domain-Name          = N    NIS+ v3 Client Domain Name    = [RFC2132]
   65      = NIS-Server-Addr          = N    NIS+ v3 Server = Addresses      [RFC2132]
   66      = Server-Name          &= nbsp;   N    TFTP Server = Name           &n= bsp;  [RFC2132]
   67      = Bootfile-Name          = ;  N    Boot File = Name           &n= bsp;    [RFC2132]
   68      = Home-Agent-Addrs         = N    Home Agent = Addresses          = [RFC2132]
   69      = SMTP-Server          &= nbsp;   N    Simple Mail Server = Addresses  [RFC2132]
   70      = POP3-Server          &= nbsp;   N    Post Office Server = Addresses  [RFC2132]
   71      = NNTP-Server          &= nbsp;   N    Network News Server Addresses = [RFC2132]
   72      = WWW-Server          &n= bsp;    N    WWW Server = Addresses          = [RFC2132]
   73      = Finger-Server          = ;  N    Finger Server = Addresses       [RFC2132]
   74      = IRC-Server          &n= bsp;    N    Chat Server = Addresses         = [RFC2132]
   75      = StreetTalk-Server        = N    StreetTalk Server Addresses   = [RFC2132]
   76      = STDA-Server          &= nbsp;   N    ST Directory Assist. = Addresses[RFC2132]
   77      = User-Class          &n= bsp;    N    User Class = Information        [RFC3004]
   78      = Directory Agent          = N    directory agent information   = [RFC2610]
   79      = Service = Scope            = N    service location agent scope  [RFC2610]
   80      Naming = Authority         = N    naming authority
   81      Client = FQDN           &n= bsp;  N    Fully Qualified Domain Name   = [DRAFT-IETF-DHC-FQDN-OPTION]
   82      Relay = Agent Information  N    Relay Agent = Information       [RFC3046]
   83      Agent = Remote ID          = N    Agent Remote = ID           &nbs= p;  
   84      Agent = Subnet Mask        = N    Agent Subnet = Mask           &n= bsp;
   85      NDS = Servers           = ;   N    Novell Directory = Services     [RFC2241]
   86      NDS = Tree = Name            = N    Novell Directory Services     = [RFC2241]
   87      NDS = Context           = ;   N    Novell Directory = Services     [RFC2241]
   88      IEEE = 1003.1 POSIX        = N    IEEE 1003.1 POSIX Timezone
   89      = FQDN           &n= bsp;         = N    Fully Qualified Domain Name
   90      = Authentication         &nbs= p; N    = Authentication         &nbs= p;      [RFC3118]
   91      Vines = TCP/IP           =   N    Vines TCP/IP Server Option
   92      Server = Selection         = N    Server Selection Option
   93      Client = System           = N    Client System Architecture
   94      Client = NDI           &nb= sp;   N    Client Network Device = Interface
   95      LDAP =             =       N    Lightweight = Directory Access Protocol
   96      IPv6 = Transitions         = N    IPv6 Transitions
   97      = UUID/GUID          &nb= sp;     N    UUID/GUID-based Client = Identifier
   98      = User-Auth          &nb= sp;     N    Open Group's User = Authentication [RFC2485]
   99      = Unassigned
   100     Printer = Name           &n= bsp; N    Printer Name
   101     = MDHCP           &= nbsp;        N    = DHCP multicast address
   102-107 REMOVED/Unassigned
   108     Swap Path =    =             = N    Swap Path Option
   109     = Unassigned
   110     IPX = Compatability        = N    IPX Compatability
   111     = Unassigned
   112     Netinfo = Address          = N    NetInfo Parent Server Address
   113     Netinfo = Tag           &nb= sp;  N    NetInfo Parent Server Tag
   114     = URL           &nb= sp;          = N    URL
   115     = Failover          &nbs= p;      N    DHCP Failover = Protocol
   116     = Auto-Config          &= nbsp;   N    DHCP = Auto-Configuration       [RFC2563]
   117     Name = Service Search      2    Name = Service = Search           = [RFC2937]
   118     Subnet = Selection Option  4    Subnet Selection = Option       [RFC3011]
   119     Domain = Search           = N    DNS domain serach list
   120     SIP Servers = DHCP Option  N    SIP Servers DHCP = Option       [RFC3361]
   121     = Unassigned
   122     = Unassigned
   123     = Unassigned
   124     = Unassigned
   125     = Unassigned
   126     = Extension          &nb= sp;     N    Extension
   127     = Extension          &nb= sp;     N    Extension
   128-254 Private Use
   255     = End           &nb= sp;          = 0    = None           &n= bsp;           &n= bsp;  [RFC2132]

- Bernie

-----Original Message-----
From: John Schnizlein [mailto:jschnizl@cisco.com]=
Sent: Wednesday, October 09, 2002 1:31 PM
To: Woundy, Richard
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Conflicting information = regarding DHCP options 82
and 83.


And DHCP option 83 should also be part of this IANA = cleanup.
I recall a remark in an IETF plenary that IANA was = still planning
to clean up the assignments, and that DHCP options = was recognized
as needing work.

Thanks for the historical explanation of the = (erroneous) option 84.

John

At 01:10 PM 10/9/2002, Woundy, Richard wrote:
>IANA seems to be a little more confused than we = realize.
>
>Looking at http://www.iana.org/assignments/bootp-dhcp-parameters<= /A>, I see:
>
>   82      = Agent Circuit ID         = N    Agent Circuit ID
>   83      = Agent Remote ID          = N    Agent Remote ID
>   84      = Agent Subnet Mask        = N    Agent Subnet Mask
>
>And then later on the same page:
>
>DHCP Agent Sub-Option Codes  per = [RFC3046]
>
>Code    Sub-Option = Description          &= nbsp;      Reference
>-----   = -----------------------        &= nbsp;       ---------
>   1    Agent Circuit = ID = Sub-option          &n= bsp; [RFC3046]
>   2    Agent Remote ID = Sub-option          &n= bsp;  [RFC3046]
>   3    Sub-option 3 is = reserved and should      [Droms]
>        not = be assigned at this time;
>        = proprietary and incompatible usages
>        of = this sub-option value have been
>        seen = limited deployment.
>   4    DOCSIS Device = Class Suboption          = [RFC3256]
>
>It appears that IANA assigned three DHCP option = codes (82-84) when only one
>DHCP option code was assigned in RFC 3046 = (82).
>
>Note that an earlier draft of RFC 3046 had a = third suboption, "Agent Subnet
>Mask Sub-option", that was removed prior to = RFC publication -- this is why
>suboption 3 is "reserved". That's why = I think option 84 should be part of
>this IANA cleanup.
>
>-- Rich

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

------_=_NextPart_001_01C26FC1.B66B5E3A-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 14:59:00 2002 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 OAA00065; Wed, 9 Oct 2002 14:58:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99J09v10213; Wed, 9 Oct 2002 15:00:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99IxDv10139 for ; Wed, 9 Oct 2002 14:59:13 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00021 for ; Wed, 9 Oct 2002 14:57:01 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-282.cisco.com [10.82.241.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA25568; Wed, 9 Oct 2002 14:59:02 -0400 (EDT) Message-Id: <4.3.2.7.2.20021009144203.03622970@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Oct 2002 14:58:58 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection Cc: Ted Lemon , "Bernie Volz (EUD)" , Kim Kinnear , dhcwg@ietf.org In-Reply-To: <200210091835.g99IZa632120@rotala.raleigh.ibm.com> References: <4.3.2.7.2.20021008151605.00b72388@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The message from the relay agent to the server uses the relay agent's address as the source address. The relay agent modifies and sends the DHCP message as the payload in a UDP message that appears to originate from the relay agent. Section 4 of RFC1542 gives more details. The difference between DHCPv4 and DHCPv6 is in the way in which the client message is processed by the relay agent (in DHCPv6, the message is encapsulated in a new message generated by the relay agent). Yes, IPsec cannot be used from the client to the server. The proposal for the use of IPsec under consideration here is to protect the message as it travels between the relay agent and the server. The primary purpose is to protect any relay agent options, addressing an issue raised by the original relay option spec (RFC3046), which assumes no security is needed between the relay agent and the server. - Ralph At 02:35 PM 10/9/2002 -0400, Thomas Narten wrote: > > If I squint my eyes and stand back far enough, I don't see that the DHCPv4 > > case is different. > >Conceptually similar, details are different. > > > While the relay agent is relaying a message on behalf > > of the client, it really is relaying that message in an independent UDP > > message, in which the source address belongs to the relay agent. > >Isn't the source address of the packet that of the client (and not the >relay agent)? This makes a huge differences with regards to IPsec. > >Even worse, the client has no IP address yet, so the relayed packet >has no source address... > >This can't be made to work trivially with stock IPsec. You'd need >extensions I'd suspect, defeating much of the purpose of trying to use >IPsec. > >Note that the above also factored into why DHC needed something >specific to DHC rather than trying to somehow use IPsec. > >Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 15:30:15 2002 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 PAA00985; Wed, 9 Oct 2002 15:30:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99JVRv12384; Wed, 9 Oct 2002 15:31:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99JUIv12329 for ; Wed, 9 Oct 2002 15:30:18 -0400 Received: from rtp-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 PAA00909 for ; Wed, 9 Oct 2002 15:28:05 -0400 (EDT) Received: from goblet.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g99JUGqd017726; Wed, 9 Oct 2002 15:30:16 -0400 (EDT) Received: from MJS-PC.cisco.com (mjs-pc.cisco.com [172.27.181.69]) by goblet.cisco.com (Mirapoint) with ESMTP id ABW96925; Wed, 9 Oct 2002 15:30:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20021009151714.01a1ccc8@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Oct 2002 15:29:46 -0400 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection Cc: Thomas Narten , Ted Lemon , "Bernie Volz (EUD)" , Kim Kinnear , dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20021009144203.03622970@funnel.cisco.com> References: <200210091835.g99IZa632120@rotala.raleigh.ibm.com> <4.3.2.7.2.20021008151605.00b72388@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I had thought that the progressing relay-agent-authentication draft was the response to Thomas's issue. That seemed to me to be targetted at the specific problem of relay<->server communication, and to require relatively light-weight implementation and configuration changes while providing an appropriate level of security. That path still seems to me to offer the best cost/benefit/deployment balance. Will it be more difficult to deploy and configure an ipsec solution in heterogeneous or complex networks? Will any additional configuration work required provide any additional security? Will relays need separate SAs to all the dhcp failover server pairs? Will all the kinds of v4 devices that act as relays and servers be able to implement ipsec? I'm concerned that choosing ipsec may lead to reduced adoption of relay-agent security. -- Mark At 02:58 PM 10/9/2002 -0400, Ralph Droms wrote: >The message from the relay agent to the server uses the relay agent's >address as the source address. The relay agent modifies and sends the >DHCP message as the payload in a UDP message that appears to originate >from the relay agent. Section 4 of RFC1542 gives more details. The >difference between DHCPv4 and DHCPv6 is in the way in which the client >message is processed by the relay agent (in DHCPv6, the message is >encapsulated in a new message generated by the relay agent). > >Yes, IPsec cannot be used from the client to the server. The proposal for >the use of IPsec under consideration here is to protect the message as it >travels between the relay agent and the server. The primary purpose is to >protect any relay agent options, addressing an issue raised by the >original relay option spec (RFC3046), which assumes no security is needed >between the relay agent and the server. > >- Ralph > >At 02:35 PM 10/9/2002 -0400, Thomas Narten wrote: >> > If I squint my eyes and stand back far enough, I don't see that the DHCPv4 >> > case is different. >> >>Conceptually similar, details are different. >> >> > While the relay agent is relaying a message on behalf >> > of the client, it really is relaying that message in an independent UDP >> > message, in which the source address belongs to the relay agent. >> >>Isn't the source address of the packet that of the client (and not the >>relay agent)? This makes a huge differences with regards to IPsec. >> >>Even worse, the client has no IP address yet, so the relayed packet >>has no source address... >> >>This can't be made to work trivially with stock IPsec. You'd need >>extensions I'd suspect, defeating much of the purpose of trying to use >>IPsec. >> >>Note that the above also factored into why DHC needed something >>specific to DHC rather than trying to somehow use IPsec. >> >>Thomas > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 15:42:10 2002 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 PAA01217; Wed, 9 Oct 2002 15:42:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99JhNv13303; Wed, 9 Oct 2002 15:43:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99JgUv13272 for ; Wed, 9 Oct 2002 15:42:30 -0400 Received: from e31.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01187 for ; Wed, 9 Oct 2002 15:40:17 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g99Jg9nL017228; Wed, 9 Oct 2002 15:42:09 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g99Jg8HY228616; Wed, 9 Oct 2002 13:42:08 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g99JeLt32363; Wed, 9 Oct 2002 15:40:21 -0400 Message-Id: <200210091940.g99JeLt32363@rotala.raleigh.ibm.com> To: Ralph Droms cc: Ted Lemon , "Bernie Volz (EUD)" , Kim Kinnear , dhcwg@ietf.org Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection In-Reply-To: Message from Ralph Droms of "Wed, 09 Oct 2002 14:58:58 EDT." <4.3.2.7.2.20021009144203.03622970@funnel.cisco.com> Date: Wed, 09 Oct 2002 15:40:21 -0400 From: Thomas Narten 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 message from the relay agent to the server uses the relay agent's > address as the source address. The relay agent modifies and sends the DHCP > message as the payload in a UDP message that appears to originate from the > relay agent. Section 4 of RFC1542 gives more details. The difference > between DHCPv4 and DHCPv6 is in the way in which the client message is > processed by the relay agent (in DHCPv6, the message is encapsulated in a > new message generated by the relay agent). OK. I misunderstood how this worked. Because the relay agent mucks with the giaddr field, I had never understood that the relay agent is in fact sourcing a packet with its own source address (which contains the same info as the giaddr field). I guess back then, getting the source address of a packet out of the API was deemed to hard or something? So yes, I agree IPsec could be used to secure the relay-agent - server path. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 15:46:52 2002 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 PAA01384; Wed, 9 Oct 2002 15:46:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Jm3v13474; Wed, 9 Oct 2002 15:48:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Jl7v13426 for ; Wed, 9 Oct 2002 15:47:07 -0400 Received: from e3.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01330 for ; Wed, 9 Oct 2002 15:44:54 -0400 (EDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g99Jkqxw095896; Wed, 9 Oct 2002 15:46:52 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g99Jknn4028144; Wed, 9 Oct 2002 15:46:49 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g99Jj4I32387; Wed, 9 Oct 2002 15:45:04 -0400 Message-Id: <200210091945.g99Jj4I32387@rotala.raleigh.ibm.com> To: Mark Stapp cc: dhcwg@ietf.org Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection In-Reply-To: Message from Mark Stapp of "Wed, 09 Oct 2002 15:29:46 EDT." <4.3.2.7.2.20021009151714.01a1ccc8@goblet.cisco.com> Date: Wed, 09 Oct 2002 15:45:04 -0400 From: Thomas Narten 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: , Mark Stapp writes: > I had thought that the progressing relay-agent-authentication draft was the > response to Thomas's issue. You mean draft-ietf-dhc-auth-suboption-00.txt? That would seem to be a good step! But I think the IESG also has asked for a recharter and a more general plan for dealing with DHC security. I also agree with Mark that using IPsec, while possible, isn't necessarily the obvious answer. I think a very real question is whether one could get IPsec deployed on the relay agent devices where its usage is actually needed most. Note also, that IPsec (without IKE) might be adequate too. Manual keying may well be workable given the trust relationship between DHC servers and relay agents. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 16:03:57 2002 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 QAA02162; Wed, 9 Oct 2002 16:03:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99K5Av14163; Wed, 9 Oct 2002 16:05:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99K4Qv14108 for ; Wed, 9 Oct 2002 16:04:26 -0400 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 QAA01929 for ; Wed, 9 Oct 2002 16:02:13 -0400 (EDT) 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 17zN4B-00024L-00; Wed, 09 Oct 2002 13:04:23 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <42494AKG>; Wed, 9 Oct 2002 13:05:25 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67484@homer.incognito.com.> From: "Kostur, Andre" To: "'Thomas Narten'" , Ralph Droms Cc: Ted Lemon , "Bernie Volz (EUD)" , Kim Kinnear , dhcwg@ietf.org Subject: RE: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection Date: Wed, 9 Oct 2002 13:05:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FCF.3259BB10" 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_01C26FCF.3259BB10 Content-Type: text/plain; charset="iso-8859-1" Not necessarily. The giaddr is required to be the IP address of the interface upon which the original packet was heard, but I don't recall an actual restriction on what IP the relayed packet must be sourced from. If you have a multiple interface router doing the relaying, the giaddr could be different than the source IP.... However, the DHCP server is required to send the answer back to the giaddr, and not the source IP. -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, October 09, 2002 12:40 PM To: Ralph Droms Cc: Ted Lemon; Bernie Volz (EUD); Kim Kinnear; dhcwg@ietf.org Subject: Re: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection > The message from the relay agent to the server uses the relay agent's > address as the source address. The relay agent modifies and sends the DHCP > message as the payload in a UDP message that appears to originate from the > relay agent. Section 4 of RFC1542 gives more details. The difference > between DHCPv4 and DHCPv6 is in the way in which the client message is > processed by the relay agent (in DHCPv6, the message is encapsulated in a > new message generated by the relay agent). OK. I misunderstood how this worked. Because the relay agent mucks with the giaddr field, I had never understood that the relay agent is in fact sourcing a packet with its own source address (which contains the same info as the giaddr field). I guess back then, getting the source address of a packet out of the API was deemed to hard or something? So yes, I agree IPsec could be used to secure the relay-agent - server path. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C26FCF.3259BB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection =

Not necessarily.  The giaddr is required to be = the IP address of the interface upon which the original packet was = heard, but I don't recall an actual restriction on what IP the relayed = packet must be sourced from.  If you have a multiple interface = router doing the relaying, the giaddr could be different than the = source IP....

However, the DHCP server is required to send the = answer back to the giaddr, and not the source IP.

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, October 09, 2002 12:40 PM
To: Ralph Droms
Cc: Ted Lemon; Bernie Volz (EUD); Kim Kinnear; = dhcwg@ietf.org
Subject: Re: [dhcwg] status of = draft-ietf-dhc-agent-subnet-selection


> The message from the relay agent to the server = uses the relay agent's
> address as the source address.  The relay = agent modifies and sends the DHCP
> message as the payload in a UDP message that = appears to originate from the
> relay agent.  Section 4 of RFC1542 gives = more details.  The difference
> between DHCPv4 and DHCPv6 is in the way in = which the client message is
> processed by the relay agent (in DHCPv6, the = message is encapsulated in a
> new message generated by the relay = agent).

OK. I misunderstood how this worked. Because the = relay agent mucks
with the giaddr field, I had never understood that = the relay agent is
in fact sourcing a packet with its own source = address (which contains
the same info as the giaddr field). I guess back = then, getting the
source address of a packet out of the API was deemed = to hard or
something?

So yes, I agree IPsec could be used to secure the = relay-agent - server
path.

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

------_=_NextPart_001_01C26FCF.3259BB10-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 16:29:15 2002 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 QAA03399; Wed, 9 Oct 2002 16:29:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99KULv15929; Wed, 9 Oct 2002 16:30:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99KTVv15898 for ; Wed, 9 Oct 2002 16:29:31 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03372 for ; Wed, 9 Oct 2002 16:27:18 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-282.cisco.com [10.82.241.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA03414; Wed, 9 Oct 2002 16:29:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20021009162256.03601d40@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Oct 2002 16:29:17 -0400 To: John Schnizlein From: Ralph Droms Subject: RE: [dhcwg] Conflicting information regarding DHCP options 82 and 83. Cc: "Woundy, Richard" , In-Reply-To: <4.3.2.7.2.20021009132649.018c3f00@wells.cisco.com> References: <6732623D2548D61193C90002A5C88DCC01EBCD94@entmaexch02.broad band.att.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 one point, I did some work on an option code cleanup. I still have the basic information if anyone is interested in picking it up and finishing the review, or I can move it forward. Options 83 and 84 are on the list as "returnable". - Ralph At 01:31 PM 10/9/2002 -0400, John Schnizlein wrote: >And DHCP option 83 should also be part of this IANA cleanup. >I recall a remark in an IETF plenary that IANA was still planning >to clean up the assignments, and that DHCP options was recognized >as needing work. > >Thanks for the historical explanation of the (erroneous) option 84. > >John > >At 01:10 PM 10/9/2002, Woundy, Richard wrote: > >IANA seems to be a little more confused than we realize. > > > >Looking at http://www.iana.org/assignments/bootp-dhcp-parameters, I see: > > > > 82 Agent Circuit ID N Agent Circuit ID > > 83 Agent Remote ID N Agent Remote ID > > 84 Agent Subnet Mask N Agent Subnet Mask > > > >And then later on the same page: > > > >DHCP Agent Sub-Option Codes per [RFC3046] > > > >Code Sub-Option Description Reference > >----- ----------------------- --------- > > 1 Agent Circuit ID Sub-option [RFC3046] > > 2 Agent Remote ID Sub-option [RFC3046] > > 3 Sub-option 3 is reserved and should [Droms] > > not be assigned at this time; > > proprietary and incompatible usages > > of this sub-option value have been > > seen limited deployment. > > 4 DOCSIS Device Class Suboption [RFC3256] > > > >It appears that IANA assigned three DHCP option codes (82-84) when only one > >DHCP option code was assigned in RFC 3046 (82). > > > >Note that an earlier draft of RFC 3046 had a third suboption, "Agent Subnet > >Mask Sub-option", that was removed prior to RFC publication -- this is why > >suboption 3 is "reserved". That's why I think option 84 should be part of > >this IANA cleanup. > > > >-- Rich > >_______________________________________________ >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 Oct 9 16:52:11 2002 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 QAA04022; Wed, 9 Oct 2002 16:52:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99KrJv17371; Wed, 9 Oct 2002 16:53:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99KqFv17330 for ; Wed, 9 Oct 2002 16:52:15 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03972 for ; Wed, 9 Oct 2002 16:50:02 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-282.cisco.com [10.82.241.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA05287 for ; Wed, 9 Oct 2002 16:52:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20021009164052.03697880@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Oct 2002 16:52:00 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Fwd: RFC-to-be: 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, considering we're now at option code 121, perhaps I should start the process of resolving the status of some of the unused option codes. Here are some option codes that should be easy to decide on: Option Name code ------ -------- 83, 84 Relay agent options 89 FQDNs in DHCP options 91 VINES TCP/IP server 96 IPv6 Transition 100 Printer name 101-107 Multicast assignment through DHCP 108 Swap path 110 IPX compatibility These option codes were assigned based on requests to IANA, but none of the associated options were ever published as RFCs. I've tried to contact the persons to whom these option codes were assigned, and have either received an ack that the option codes can be returned or no response to my e-mail. As an informal next step, please respond to the mailing list if you know of any implementation or use of any of these option codes. - Ralph >From: "IANA" >To: , , > >Cc: >Subject: RFC-to-be: >Date: Wed, 9 Oct 2002 13:16:48 -0700 >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) >Importance: Normal > >Authors: > >We are working on the IANA Actions for RFC-to-be: >. > >We have assigned value 121 to the Classless Static >Route Option. Please see the following for the >registration and make sure everything looks OK: > > > >Please reply back with a final OK so that we may >send a message to the RFC Editor indicating that the >IANA Actions are completed. > >Thank you, > >Michelle S. Cotton >IANA Administrator _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 16:56:46 2002 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 QAA04248; Wed, 9 Oct 2002 16:56:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Kw2v17543; Wed, 9 Oct 2002 16:58:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Kv1v17510 for ; Wed, 9 Oct 2002 16:57:01 -0400 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 QAA04192 for ; Wed, 9 Oct 2002 16:54:48 -0400 (EDT) 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 g99Kusj15658; Wed, 9 Oct 2002 15:56:54 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g99KusK19309; Wed, 9 Oct 2002 15:56:54 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PAP34R>; Wed, 9 Oct 2002 15:56:54 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Fwd: RFC-to-be: Date: Wed, 9 Oct 2002 15:56:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FD6.0EBD0BB0" 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_01C26FD6.0EBD0BB0 Content-Type: text/plain; charset="iso-8859-1" What about adding: 115 Failover N DHCP Failover Protocol That option was probably used in some of the early failover protocol designs? It is not used in DRAFT-IETF-DHC-FAILOVER-10.TXT. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, October 09, 2002 4:52 PM To: dhcwg@ietf.org Subject: [dhcwg] Fwd: RFC-to-be: Well, considering we're now at option code 121, perhaps I should start the process of resolving the status of some of the unused option codes. Here are some option codes that should be easy to decide on: Option Name code ------ -------- 83, 84 Relay agent options 89 FQDNs in DHCP options 91 VINES TCP/IP server 96 IPv6 Transition 100 Printer name 101-107 Multicast assignment through DHCP 108 Swap path 110 IPX compatibility These option codes were assigned based on requests to IANA, but none of the associated options were ever published as RFCs. I've tried to contact the persons to whom these option codes were assigned, and have either received an ack that the option codes can be returned or no response to my e-mail. As an informal next step, please respond to the mailing list if you know of any implementation or use of any of these option codes. - Ralph >From: "IANA" >To: , , > >Cc: >Subject: RFC-to-be: >Date: Wed, 9 Oct 2002 13:16:48 -0700 >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) >Importance: Normal > >Authors: > >We are working on the IANA Actions for RFC-to-be: >. > >We have assigned value 121 to the Classless Static >Route Option. Please see the following for the >registration and make sure everything looks OK: > > > >Please reply back with a final OK so that we may >send a message to the RFC Editor indicating that the >IANA Actions are completed. > >Thank you, > >Michelle S. Cotton >IANA Administrator _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C26FD6.0EBD0BB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Fwd: RFC-to-be: = <draft-ietf-dhc-csr-07.txt>

What about adding:

   115     = Failover          &nbs= p;      N    DHCP Failover = Protocol

That option was probably used in some of the early = failover protocol
designs? It is not used in = DRAFT-IETF-DHC-FAILOVER-10.TXT.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, October 09, 2002 4:52 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Fwd: RFC-to-be: = <draft-ietf-dhc-csr-07.txt>


Well, considering we're now at option code 121, = perhaps I should start the
process of resolving the status of some of the = unused option codes.  Here
are some option codes that should be easy to decide = on:

Option  Name
code
------  --------
83, 84   Relay agent options
89       FQDNs in DHCP = options
91       VINES TCP/IP = server
96       IPv6 = Transition
100      Printer = name
101-107 Multicast assignment through DHCP
108      Swap path
110      IPX = compatibility

These option codes were assigned based on requests to = IANA, but none of the
associated options were ever published as = RFCs.  I've tried to contact the
persons to whom these option codes were assigned, = and have either received
an ack that the option codes can be returned or no = response to my
e-mail.  As an informal next step, please = respond to the mailing list if
you know of any implementation or use of any of = these option codes.

- Ralph


>From: "IANA" = <iana@icann.org>
>To: <Ted.Lemon@nominum.com>, = <rfc@stuartcheshire.org>,
>         = <bernie.volz@ericsson.com>
>Cc: <rdroms@cisco.com>
>Subject: RFC-to-be: = <draft-ietf-dhc-csr-07.txt>
>Date: Wed, 9 Oct 2002 13:16:48 -0700
>X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 = (9.0.2911.0)
>Importance: Normal
>
>Authors:
>
>We are working on the IANA Actions for = RFC-to-be:
><draft-ietf-dhc-csr-07.txt>.
>
>We have assigned value 121 to the Classless = Static
>Route Option.  Please see the following for = the
>registration and make sure everything looks = OK:
>
><http://www.iana.org/assignments/bootp-dhcp-parameters<= /A>>
>
>Please reply back with a final OK so that we = may
>send a message to the RFC Editor indicating that = the
>IANA Actions are completed.
>
>Thank you,
>
>Michelle S. Cotton
>IANA Administrator

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

------_=_NextPart_001_01C26FD6.0EBD0BB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 16:56:48 2002 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 QAA04274; Wed, 9 Oct 2002 16:56:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Kw3v17559; Wed, 9 Oct 2002 16:58:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99Kvmv17528 for ; Wed, 9 Oct 2002 16:57:48 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04197 for ; Wed, 9 Oct 2002 16:55:34 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-282.cisco.com [10.82.241.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA05695 for ; Wed, 9 Oct 2002 16:57:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20021009165526.03611b30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Oct 2002 16:57:37 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Fwd: RFC-to-be: 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: , Based on a quick review of the current IANA list (thanks for posting the list, Bernie), here's a revised list of option codes that might be reassigned: Option Name code ------ -------- 83, 84 Relay agent options 89 FQDNs in DHCP options 91 VINES TCP/IP server 96 IPv6 Transition 100 Printer name 101-107 Multicast assignment through DHCP 108 Swap path 110 IPX compatibility 115 Failover 126 Extension 127 Extension _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 9 17:07:01 2002 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 RAA04771; Wed, 9 Oct 2002 17:07:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99L89v18995; Wed, 9 Oct 2002 17:08:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g99L7kv18980 for ; Wed, 9 Oct 2002 17:07:46 -0400 Received: from rtp-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 RAA04729 for ; Wed, 9 Oct 2002 17:05:34 -0400 (EDT) Received: from goblet.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g99L7gAp029180; Wed, 9 Oct 2002 17:07:43 -0400 (EDT) Received: from KKINNEAR-W2K.cisco.com (ch2-dhcp150-119.cisco.com [161.44.150.119]) by goblet.cisco.com (Mirapoint) with ESMTP id ABW99061; Wed, 9 Oct 2002 17:07:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20021009170712.024efa38@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Oct 2002 17:07:34 -0400 To: "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org From: Kim Kinnear Subject: RE: [dhcwg] Fwd: RFC-to-be: In-Reply-To: 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 04:56 PM 10/9/2002, Bernie Volz (EUD) wrote: >What about adding: > > 115 Failover N DHCP Failover Protocol > >That option was probably used in some of the early failover protocol >designs? It is not used in DRAFT-IETF-DHC-FAILOVER-10.TXT. I agree with Bernie -- we should reclaim this. Cheers -- Kim >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Wednesday, October 09, 2002 4:52 PM >To: dhcwg@ietf.org >Subject: [dhcwg] Fwd: RFC-to-be: > >Well, considering we're now at option code 121, perhaps I should start the >process of resolving the status of some of the unused option codes. Here >are some option codes that should be easy to decide on: > >Option Name >code >------ -------- >83, 84 Relay agent options >89 FQDNs in DHCP options >91 VINES TCP/IP server >96 IPv6 Transition >100 Printer name >101-107 Multicast assignment through DHCP >108 Swap path >110 IPX compatibility > >These option codes were assigned based on requests to IANA, but none of the >associated options were ever published as RFCs. I've tried to contact the >persons to whom these option codes were assigned, and have either received >an ack that the option codes can be returned or no response to my >e-mail. As an informal next step, please respond to the mailing list if >you know of any implementation or use of any of these option codes. > >- Ralph > >>From: "IANA" >>To: , , >> >>Cc: >>Subject: RFC-to-be: >>Date: Wed, 9 Oct 2002 13:16:48 -0700 >>X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) >>Importance: Normal >> >>Authors: >> >>We are working on the IANA Actions for RFC-to-be: >>. >> >>We have assigned value 121 to the Classless Static >>Route Option. Please see the following for the >>registration and make sure everything looks OK: >> >><http://www.iana.org/assignments/bootp-dhcp-parameters> >> >>Please reply back with a final OK so that we may >>send a message to the RFC Editor indicating that the >>IANA Actions are completed. >> >>Thank you, >> >>Michelle S. Cotton >>IANA Administrator > >_______________________________________________ >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 Oct 10 03:16:41 2002 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 DAA24349; Thu, 10 Oct 2002 03:16:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9A7Hpv23101; Thu, 10 Oct 2002 03:17:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9A7Gcv23042 for ; Thu, 10 Oct 2002 03:16:38 -0400 Received: from ns1.thmulti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24330 for ; Thu, 10 Oct 2002 03:14:20 -0400 (EDT) Received: from smtprelay2.thmulti.com (smtprelay2 [141.11.195.242]) by ns1.thmulti.com (8.9.3/8.9.1) with ESMTP id JAA25776; Thu, 10 Oct 2002 09:16:20 +0200 (MET DST) Received: from parexch9.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay2.thmulti.com (8.9.3/8.9.1) with ESMTP id JAA08380; Thu, 10 Oct 2002 09:16:12 +0200 (MET DST) Received: by outlook.paris.thmulti.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 09:16:15 +0200 Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090E3C@edgmsmsg01.eu.thmulti.com> From: Van Aken Dirk To: "'Ted Lemon'" Cc: "'dhcwg@ietf.org'" , Dedecker Hans , Dekeyser Miek , "'Dirk.Ooms@alcatel.be'" Subject: RE: [dhcwg] - Clas sfull ? Date: Thu, 10 Oct 2002 09:16:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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: , Hi Ted, As you as you mentioned in the reply, it is indeed exactly the same problem as with giaddr. But why can this problem not be solved ? After all, the overloading of giaddr (communication with the relay agent and address pool selection) was defined 17 years ago (RFC951-1985). All networks were classfull at that time but today almost all IP systems can operate in a classless environment.. As it is a totally new DHCP Relay Information Sub-Option, one can easily define two fields: IP address and IP mask or IP address and Prefix length. One could eventually reuse the syntax of - The Classless Static Route Option for DHCPv4. Best regards - Dirk -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Tuesday 8 October 2002 11:32 To: Van Aken Dirk Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek Subject: Re: [dhcwg] - Classfull ? > I wonder though how the DHCP server can derive a subnet from a single > quantity being an IP address. e.g. 20.0.0.0 can be an alias for > 20.0.0.0/8 > or 20.0.0.0/29. > So my guess is that the only way the DHCP server can derive the subnet > form > is based on the leading bits of the address being either class A, B or > C. The DHCP server is configured with a list of subnets. It has to be, to make address assignment decisions. This is exactly the same problem that you have if you use giaddr for subnet selection. _______________________________________________ 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 Oct 10 09:02:28 2002 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 JAA02009; Thu, 10 Oct 2002 09:02:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AD3Qv08453; Thu, 10 Oct 2002 09:03:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9ACxRv08287 for ; Thu, 10 Oct 2002 08:59:27 -0400 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 IAA01800 for ; Thu, 10 Oct 2002 08:57:18 -0400 (EDT) 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 g9ACxCj09558; Thu, 10 Oct 2002 07:59:12 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9ACxCe04275; Thu, 10 Oct 2002 07:59:12 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PAQK64>; Thu, 10 Oct 2002 07:59:12 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Van Aken Dirk'" , "'Ted Lemon'" Cc: "'dhcwg@ietf.org'" , Dedecker Hans , Dekeyser Miek , "'Dirk.Ooms@alcatel.be'" Subject: RE: [dhcwg] - Clas sfull ? Date: Thu, 10 Oct 2002 07:59:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2705C.84E25DC8" 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_01C2705C.84E25DC8 Content-Type: text/plain; charset="iso-8859-1" There is no need to do this. What's the benefit? You'd have to configure the relay agent with more information than it currently needs. (While in many cases the relay is probably a router and has this information, why is it needed?) The server can figure out the subnet without the prefix because the server needs both the address and subnet mask length for all of the subnets (at least those it will be allocating addresses on). Also, what happens if the server and relay agent disagree on the subnet mask length? Suppose you wrongly configured the relay to send 20.0.0.0/23 and the server is configured with 20.0.0.0/24? - Bernie -----Original Message----- From: Van Aken Dirk [mailto:VanAkenD@thmulti.com] Sent: Thursday, October 10, 2002 3:16 AM To: 'Ted Lemon' Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek; 'Dirk.Ooms@alcatel.be' Subject: RE: [dhcwg] - Clas sfull ? Hi Ted, As you as you mentioned in the reply, it is indeed exactly the same problem as with giaddr. But why can this problem not be solved ? After all, the overloading of giaddr (communication with the relay agent and address pool selection) was defined 17 years ago (RFC951-1985). All networks were classfull at that time but today almost all IP systems can operate in a classless environment.. As it is a totally new DHCP Relay Information Sub-Option, one can easily define two fields: IP address and IP mask or IP address and Prefix length. One could eventually reuse the syntax of - The Classless Static Route Option for DHCPv4. Best regards - Dirk -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Tuesday 8 October 2002 11:32 To: Van Aken Dirk Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek Subject: Re: [dhcwg] - Classfull ? > I wonder though how the DHCP server can derive a subnet from a single > quantity being an IP address. e.g. 20.0.0.0 can be an alias for > 20.0.0.0/8 > or 20.0.0.0/29. > So my guess is that the only way the DHCP server can derive the subnet > form > is based on the leading bits of the address being either class A, B or > C. The DHCP server is configured with a list of subnets. It has to be, to make address assignment decisions. This is exactly the same problem that you have if you use giaddr for subnet selection. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2705C.84E25DC8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] <draft-ietf-dhc-agent-subnet-selection-03.txt> = - Clas sfull ?

There is no need to do this. What's the = benefit?

You'd have to configure the relay agent with more = information than it currently
needs. (While in many cases the relay is probably a = router and has this
information, why is it needed?) The server can = figure out the subnet without
the prefix because the server needs both the address = and subnet mask length for
all of the subnets (at least those it will be = allocating addresses on).

Also, what happens if the server and relay agent = disagree on the subnet mask
length? Suppose you wrongly configured the relay to = send 20.0.0.0/23 and the
server is configured with 20.0.0.0/24?

- Bernie

-----Original Message-----
From: Van Aken Dirk [mailto:VanAkenD@thmulti.com]
Sent: Thursday, October 10, 2002 3:16 AM
To: 'Ted Lemon'
Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser = Miek;
'Dirk.Ooms@alcatel.be'
Subject: RE: [dhcwg] = <draft-ietf-dhc-agent-subnet-selection-03.txt> -
Clas sfull ?


Hi Ted,

As you as you mentioned in the reply, it is indeed = exactly the same problem
as with giaddr.

But why can this problem not be solved ? After all, = the overloading of
giaddr (communication with the relay agent and = address pool selection) was
defined 17 years ago (RFC951-1985). All networks = were classfull at that time
but today almost all IP systems can operate in a = classless environment..

As it is a totally new DHCP Relay Information = Sub-Option, one can easily
define two fields: IP address and IP mask or IP = address and Prefix length.

One could eventually reuse the syntax of = <draft-ietf-dhc-csr-07.txt> - The
Classless Static Route Option for DHCPv4.

Best regards - Dirk

          &nb= sp;         

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
Sent: Tuesday 8 October 2002 11:32
To: Van Aken Dirk
Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser = Miek
Subject: Re: [dhcwg] = <draft-ietf-dhc-agent-subnet-selection-03.txt> -
Classfull ?


> I wonder though how the DHCP server can derive a = subnet from a single
> quantity being an IP address. e.g. 20.0.0.0 can = be an alias for
> 20.0.0.0/8
> or 20.0.0.0/29.
> So my guess is that the only way the DHCP = server can derive the subnet
> form
> is based on the leading bits of the address = being either class A, B or
> C.

The DHCP server is configured with a list of = subnets.   It has to be,
to make address assignment decisions.

This is exactly the same problem that you have if you = use giaddr for
subnet selection.

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

------_=_NextPart_001_01C2705C.84E25DC8-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 10 10:34:40 2002 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 KAA06244; Thu, 10 Oct 2002 10:34:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AEZcv13564; Thu, 10 Oct 2002 10:35:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AEYav13534 for ; Thu, 10 Oct 2002 10:34:36 -0400 Received: from ns1.thmulti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06132 for ; Thu, 10 Oct 2002 10:32:21 -0400 (EDT) Received: from smtprelay2.thmulti.com (smtprelay2 [141.11.195.242]) by ns1.thmulti.com (8.9.3/8.9.1) with ESMTP id QAA13292; Thu, 10 Oct 2002 16:34:06 +0200 (MET DST) Received: from parexch9.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay2.thmulti.com (8.9.3/8.9.1) with ESMTP id QAA24239; Thu, 10 Oct 2002 16:34:05 +0200 (MET DST) Received: by outlook.paris.thmulti.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Oct 2002 16:34:08 +0200 Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090E41@edgmsmsg01.eu.thmulti.com> From: Van Aken Dirk To: "'Bernie Volz (EUD)'" , "'Ted Lemon'" Cc: "'dhcwg@ietf.org'" , Dedecker Hans , Dekeyser Miek , "'Dirk.Ooms@alcatel.be'" Subject: RE: [dhcwg] - Clas sfull ? Date: Thu, 10 Oct 2002 16:31:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27069.BDBCD9A4" 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_01C27069.BDBCD9A4 Content-Type: text/plain; charset="ISO-8859-1" If a relay agent supplies a masked IP address only, the scenario only works fine provided the server does "longest prefix matching" on its available pools. If the server does not start with the pool having the smallest mask, situations where VLSM (Variable Length Subnet Mask) is applied will not converge no ? -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday 10 October 2002 2:59 To: Van Aken Dirk; 'Ted Lemon' Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek; 'Dirk.Ooms@alcatel.be' Subject: RE: [dhcwg] - Clas sfull ? There is no need to do this. What's the benefit? You'd have to configure the relay agent with more information than it currently needs. (While in many cases the relay is probably a router and has this information, why is it needed?) The server can figure out the subnet without the prefix because the server needs both the address and subnet mask length for all of the subnets (at least those it will be allocating addresses on). Also, what happens if the server and relay agent disagree on the subnet mask length? Suppose you wrongly configured the relay to send 20.0.0.0/23 and the server is configured with 20.0.0.0/24? - Bernie -----Original Message----- From: Van Aken Dirk [ mailto:VanAkenD@thmulti.com ] Sent: Thursday, October 10, 2002 3:16 AM To: 'Ted Lemon' Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek; 'Dirk.Ooms@alcatel.be' Subject: RE: [dhcwg] - Clas sfull ? Hi Ted, As you as you mentioned in the reply, it is indeed exactly the same problem as with giaddr. But why can this problem not be solved ? After all, the overloading of giaddr (communication with the relay agent and address pool selection) was defined 17 years ago (RFC951-1985). All networks were classfull at that time but today almost all IP systems can operate in a classless environment.. As it is a totally new DHCP Relay Information Sub-Option, one can easily define two fields: IP address and IP mask or IP address and Prefix length. One could eventually reuse the syntax of - The Classless Static Route Option for DHCPv4. Best regards - Dirk -----Original Message----- From: Ted Lemon [ mailto:Ted.Lemon@nominum.com ] Sent: Tuesday 8 October 2002 11:32 To: Van Aken Dirk Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek Subject: Re: [dhcwg] - Classfull ? > I wonder though how the DHCP server can derive a subnet from a single > quantity being an IP address. e.g. 20.0.0.0 can be an alias for > 20.0.0.0/8 > or 20.0.0.0/29. > So my guess is that the only way the DHCP server can derive the subnet > form > is based on the leading bits of the address being either class A, B or > C. The DHCP server is configured with a list of subnets. It has to be, to make address assignment decisions. This is exactly the same problem that you have if you use giaddr for subnet selection. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C27069.BDBCD9A4 Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] <draft-ietf-dhc-agent-subnet-selection-03.txt> - Clas sfull ?
If a relay agent supplies a masked IP address only, the scenario only works fine provided the server does "longest prefix matching" on its available pools.
If the server does not start with the pool having the smallest mask, situations where VLSM (Variable Length Subnet Mask) is applied will not converge no ?
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday 10 October 2002 2:59
To: Van Aken Dirk; 'Ted Lemon'
Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek; 'Dirk.Ooms@alcatel.be'
Subject: RE: [dhcwg] <draft-ietf-dhc-agent-subnet-selection-03.txt> - Clas sfull ?

There is no need to do this. What's the benefit?

You'd have to configure the relay agent with more information than it currently
needs. (While in many cases the relay is probably a router and has this
information, why is it needed?) The server can figure out the subnet without
the prefix because the server needs both the address and subnet mask length for
all of the subnets (at least those it will be allocating addresses on).

Also, what happens if the server and relay agent disagree on the subnet mask
length? Suppose you wrongly configured the relay to send 20.0.0.0/23 and the
server is configured with 20.0.0.0/24?

- Bernie

-----Original Message-----
From: Van Aken Dirk [mailto:VanAkenD@thmulti.com]
Sent: Thursday, October 10, 2002 3:16 AM
To: 'Ted Lemon'
Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek;
'Dirk.Ooms@alcatel.be'
Subject: RE: [dhcwg] <draft-ietf-dhc-agent-subnet-selection-03.txt> -
Clas sfull ?


Hi Ted,

As you as you mentioned in the reply, it is indeed exactly the same problem
as with giaddr.

But why can this problem not be solved ? After all, the overloading of
giaddr (communication with the relay agent and address pool selection) was
defined 17 years ago (RFC951-1985). All networks were classfull at that time
but today almost all IP systems can operate in a classless environment..

As it is a totally new DHCP Relay Information Sub-Option, one can easily
define two fields: IP address and IP mask or IP address and Prefix length.

One could eventually reuse the syntax of <draft-ietf-dhc-csr-07.txt> - The
Classless Static Route Option for DHCPv4.

Best regards - Dirk

                    

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent: Tuesday 8 October 2002 11:32
To: Van Aken Dirk
Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek
Subject: Re: [dhcwg] <draft-ietf-dhc-agent-subnet-selection-03.txt> -
Classfull ?


> I wonder though how the DHCP server can derive a subnet from a single
> quantity being an IP address. e.g. 20.0.0.0 can be an alias for
> 20.0.0.0/8
> or 20.0.0.0/29.
> So my guess is that the only way the DHCP server can derive the subnet
> form
> is based on the leading bits of the address being either class A, B or
> C.

The DHCP server is configured with a list of subnets.   It has to be,
to make address assignment decisions.

This is exactly the same problem that you have if you use giaddr for
subnet selection.

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

------_=_NextPart_001_01C27069.BDBCD9A4-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 10 10:45:02 2002 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 KAA06524; Thu, 10 Oct 2002 10:45:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AEk7v14472; Thu, 10 Oct 2002 10:46:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AEjtv14451 for ; Thu, 10 Oct 2002 10:45:55 -0400 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 KAA06489 for ; Thu, 10 Oct 2002 10:43:44 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g9AEjdj28278; Thu, 10 Oct 2002 09:45:39 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9AEjdK13202; Thu, 10 Oct 2002 09:45:39 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PC6X5J>; Thu, 10 Oct 2002 09:45:39 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Van Aken Dirk'" , "'Ted Lemon'" Cc: "'dhcwg@ietf.org'" , Dedecker Hans , Dekeyser Miek , "'Dirk.Ooms@alcatel.be'" Subject: RE: [dhcwg] - Clas sfull ? Date: Thu, 10 Oct 2002 09:45:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2706B.6B0E044C" 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_01C2706B.6B0E044C Content-Type: text/plain; charset="iso-8859-1" Longest prefix matching is only needed if the server allows overlapping subnets (such as 20.0.0.0/8 and 20.1.0/16). If the server doesn't allow this, there is no problem. - Bernie -----Original Message----- From: Van Aken Dirk [mailto:VanAkenD@thmulti.com] Sent: Thursday, October 10, 2002 10:32 AM To: 'Bernie Volz (EUD)'; 'Ted Lemon' Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek; 'Dirk.Ooms@alcatel.be' Subject: RE: [dhcwg] - Clas sfull ? If a relay agent supplies a masked IP address only, the scenario only works fine provided the server does "longest prefix matching" on its available pools. If the server does not start with the pool having the smallest mask, situations where VLSM (Variable Length Subnet Mask) is applied will not converge no ? -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday 10 October 2002 2:59 To: Van Aken Dirk; 'Ted Lemon' Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek; 'Dirk.Ooms@alcatel.be' Subject: RE: [dhcwg] - Clas sfull ? There is no need to do this. What's the benefit? You'd have to configure the relay agent with more information than it currently needs. (While in many cases the relay is probably a router and has this information, why is it needed?) The server can figure out the subnet without the prefix because the server needs both the address and subnet mask length for all of the subnets (at least those it will be allocating addresses on). Also, what happens if the server and relay agent disagree on the subnet mask length? Suppose you wrongly configured the relay to send 20.0.0.0/23 and the server is configured with 20.0.0.0/24? - Bernie -----Original Message----- From: Van Aken Dirk [ mailto:VanAkenD@thmulti.com ] Sent: Thursday, October 10, 2002 3:16 AM To: 'Ted Lemon' Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek; 'Dirk.Ooms@alcatel.be' Subject: RE: [dhcwg] - Clas sfull ? Hi Ted, As you as you mentioned in the reply, it is indeed exactly the same problem as with giaddr. But why can this problem not be solved ? After all, the overloading of giaddr (communication with the relay agent and address pool selection) was defined 17 years ago (RFC951-1985). All networks were classfull at that time but today almost all IP systems can operate in a classless environment.. As it is a totally new DHCP Relay Information Sub-Option, one can easily define two fields: IP address and IP mask or IP address and Prefix length. One could eventually reuse the syntax of - The Classless Static Route Option for DHCPv4. Best regards - Dirk -----Original Message----- From: Ted Lemon [ mailto:Ted.Lemon@nominum.com ] Sent: Tuesday 8 October 2002 11:32 To: Van Aken Dirk Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek Subject: Re: [dhcwg] - Classfull ? > I wonder though how the DHCP server can derive a subnet from a single > quantity being an IP address. e.g. 20.0.0.0 can be an alias for > 20.0.0.0/8 > or 20.0.0.0/29. > So my guess is that the only way the DHCP server can derive the subnet > form > is based on the leading bits of the address being either class A, B or > C. The DHCP server is configured with a list of subnets. It has to be, to make address assignment decisions. This is exactly the same problem that you have if you use giaddr for subnet selection. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2706B.6B0E044C Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] <draft-ietf-dhc-agent-subnet-selection-03.txt> - Clas sfull ?
Longest prefix matching is only needed if the server allows overlapping subnets (such as 20.0.0.0/8 and 20.1.0/16). If the server doesn't allow this, there is no problem.
 
- Bernie
-----Original Message-----
From: Van Aken Dirk [mailto:VanAkenD@thmulti.com]
Sent: Thursday, October 10, 2002 10:32 AM
To: 'Bernie Volz (EUD)'; 'Ted Lemon'
Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek; 'Dirk.Ooms@alcatel.be'
Subject: RE: [dhcwg] <draft-ietf-dhc-agent-subnet-selection-03.txt> - Clas sfull ?

If a relay agent supplies a masked IP address only, the scenario only works fine provided the server does "longest prefix matching" on its available pools.
If the server does not start with the pool having the smallest mask, situations where VLSM (Variable Length Subnet Mask) is applied will not converge no ?
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday 10 October 2002 2:59
To: Van Aken Dirk; 'Ted Lemon'
Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek; 'Dirk.Ooms@alcatel.be'
Subject: RE: [dhcwg] <draft-ietf-dhc-agent-subnet-selection-03.txt> - Clas sfull ?

There is no need to do this. What's the benefit?

You'd have to configure the relay agent with more information than it currently
needs. (While in many cases the relay is probably a router and has this
information, why is it needed?) The server can figure out the subnet without
the prefix because the server needs both the address and subnet mask length for
all of the subnets (at least those it will be allocating addresses on).

Also, what happens if the server and relay agent disagree on the subnet mask
length? Suppose you wrongly configured the relay to send 20.0.0.0/23 and the
server is configured with 20.0.0.0/24?

- Bernie

-----Original Message-----
From: Van Aken Dirk [mailto:VanAkenD@thmulti.com]
Sent: Thursday, October 10, 2002 3:16 AM
To: 'Ted Lemon'
Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek;
'Dirk.Ooms@alcatel.be'
Subject: RE: [dhcwg] <draft-ietf-dhc-agent-subnet-selection-03.txt> -
Clas sfull ?


Hi Ted,

As you as you mentioned in the reply, it is indeed exactly the same problem
as with giaddr.

But why can this problem not be solved ? After all, the overloading of
giaddr (communication with the relay agent and address pool selection) was
defined 17 years ago (RFC951-1985). All networks were classfull at that time
but today almost all IP systems can operate in a classless environment..

As it is a totally new DHCP Relay Information Sub-Option, one can easily
define two fields: IP address and IP mask or IP address and Prefix length.

One could eventually reuse the syntax of <draft-ietf-dhc-csr-07.txt> - The
Classless Static Route Option for DHCPv4.

Best regards - Dirk

                    

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent: Tuesday 8 October 2002 11:32
To: Van Aken Dirk
Cc: 'dhcwg@ietf.org'; Dedecker Hans; Dekeyser Miek
Subject: Re: [dhcwg] <draft-ietf-dhc-agent-subnet-selection-03.txt> -
Classfull ?


> I wonder though how the DHCP server can derive a subnet from a single
> quantity being an IP address. e.g. 20.0.0.0 can be an alias for
> 20.0.0.0/8
> or 20.0.0.0/29.
> So my guess is that the only way the DHCP server can derive the subnet
> form
> is based on the leading bits of the address being either class A, B or
> C.

The DHCP server is configured with a list of subnets.   It has to be,
to make address assignment decisions.

This is exactly the same problem that you have if you use giaddr for
subnet selection.

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

------_=_NextPart_001_01C2706B.6B0E044C-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 10 11:23:07 2002 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 LAA07502; Thu, 10 Oct 2002 11:23:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AFOFv16238; Thu, 10 Oct 2002 11:24:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AFNdv16220 for ; Thu, 10 Oct 2002 11:23:39 -0400 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 LAA07455 for ; Thu, 10 Oct 2002 11:21:28 -0400 (EDT) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g9AFCI219653; Thu, 10 Oct 2002 10:12:18 -0500 (CDT) Date: Thu, 10 Oct 2002 10:23:35 -0500 Subject: Re: [dhcwg] - Clas sfull ? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Van Aken Dirk'" , "'dhcwg@ietf.org'" , Dedecker Hans , Dekeyser Miek , "'Dirk.Ooms@alcatel.be'" To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: Message-Id: <3E27E3C3-DC64-11D6-A9B4-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 > Longest prefix matching is only needed if the server allows > overlapping subnets (such as 20.0.0.0/8 and 20.1.0/16). If the server > doesn't allow this, there is no problem. The ISC DHCP server handles subnet overlaps just fine without the relay agent sending a subnet mask. Bernie's point about which configuration you trust is the correct rebuttal to this whole line of reasoning, I think. It would actually be harmful to send a subnet mask in the subnet selection option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 10 11:39:13 2002 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 LAA08379; Thu, 10 Oct 2002 11:39:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AFeOv17951; Thu, 10 Oct 2002 11:40:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AFdRv17847 for ; Thu, 10 Oct 2002 11:39:27 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08277 for ; Thu, 10 Oct 2002 11:37:16 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-107.cisco.com [161.44.150.107]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02061 for ; Thu, 10 Oct 2002 11:39:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20021010113510.03961ed8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Oct 2002 11:39:21 -0400 To: "'dhcwg@ietf.org'" From: Ralph Droms Subject: Re: [dhcwg] - Classfull ? In-Reply-To: <3E27E3C3-DC64-11D6-A9B4-00039367340A@nominum.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , As I remember, Ted's last sentence reflects the consensus of the dhc WG at the time the subnet selection option was reviewed: the subnet mask is information that the server must be configured with (regardless of whether the subnet selection option is used); sending the subnet mask from the relay agent would be redundant and represent an opportunity for the information from the relay agent and the server to be out of sync. Thus, the subnet selection option does not include a subnet mask... - Ralph At 10:23 AM 10/10/2002 -0500, Ted Lemon wrote: >>Longest prefix matching is only needed if the server allows overlapping >>subnets (such as 20.0.0.0/8 and 20.1.0/16). If the server doesn't allow >>this, there is no problem. > >The ISC DHCP server handles subnet overlaps just fine without the relay >agent sending a subnet mask. Bernie's point about which configuration >you trust is the correct rebuttal to this whole line of reasoning, I >think. It would actually be harmful to send a subnet mask in the subnet >selection option. > >_______________________________________________ >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 Oct 10 15:33:21 2002 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 PAA20956; Thu, 10 Oct 2002 15:33:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AJYKv31369; Thu, 10 Oct 2002 15:34:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9AJW7v31326 for ; Thu, 10 Oct 2002 15:32:07 -0400 Received: from rtp-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 PAA20797 for ; Thu, 10 Oct 2002 15:29:54 -0400 (EDT) Received: from goblet.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9AJW7R3023381; Thu, 10 Oct 2002 15:32:07 -0400 (EDT) Received: from KKINNEAR-W2K.cisco.com (ch2-dhcp150-119.cisco.com [161.44.150.119]) by goblet.cisco.com (Mirapoint) with ESMTP id ABX15591; Thu, 10 Oct 2002 15:31:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20021010153104.0243ec10@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Oct 2002 15:31:57 -0400 To: Ralph Droms , "'dhcwg@ietf.org'" From: Kim Kinnear Subject: Re: [dhcwg] - Classfull ? Cc: kkinnear@cisco.com In-Reply-To: <4.3.2.7.2.20021010113510.03961ed8@funnel.cisco.com> References: <3E27E3C3-DC64-11D6-A9B4-00039367340A@nominum.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 11:39 AM 10/10/2002, Ralph Droms wrote: >As I remember, Ted's last sentence reflects the consensus of the dhc WG at the time the subnet selection option was reviewed: the subnet mask is information that the server must be configured with (regardless of whether the subnet selection option is used); sending the subnet mask from the relay agent would be redundant and represent an opportunity for the information from the relay agent and the server to be out of sync. Thus, the subnet selection option does not include a subnet mask... I also remember it exactly this way, and agree wholeheartedly with Ted! Cheers -- Kim >- Ralph > >At 10:23 AM 10/10/2002 -0500, Ted Lemon wrote: >>>Longest prefix matching is only needed if the server allows overlapping subnets (such as 20.0.0.0/8 and 20.1.0/16). If the server doesn't allow this, there is no problem. >> >>The ISC DHCP server handles subnet overlaps just fine without the relay agent sending a subnet mask. Bernie's point about which configuration you trust is the correct rebuttal to this whole line of reasoning, I think. It would actually be harmful to send a subnet mask in the subnet selection option. >> >>_______________________________________________ >>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 Thu Oct 10 22:26:33 2002 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 WAA29132; Thu, 10 Oct 2002 22:26:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B2Riv19044; Thu, 10 Oct 2002 22:27:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9B2QLv19014 for ; Thu, 10 Oct 2002 22:26:21 -0400 Received: from cichlid.adsl.duke.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29108 for ; Thu, 10 Oct 2002 22:24:05 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g9B2Jt004892; Thu, 10 Oct 2002 22:19:55 -0400 Message-Id: <200210110219.g9B2Jt004892@cichlid.adsl.duke.edu> To: "Bernie Volz (EUD)" cc: "'John Schnizlein'" , "Woundy, Richard" , dhcwg@ietf.org Subject: Re: [dhcwg] Conflicting information regarding DHCP options 82 and 83. In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 09 Oct 2002 13:28:50 CDT." Date: Thu, 10 Oct 2002 22:19:54 -0400 From: Thomas Narten 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: , > How do we officially get these comments to IANA? Is this something Ralph > would handle? The IANA web pages are not necessarily organized ideally. I'm sure they'd welcome specific suggestions on how to make them better or to have more specific information to include. For example, a number of options don't point to an RFC or other document. If folks could fill in that info, getting it up on the web page would be good. Process wise, having Ralph provide a list to IANA that has been reviewed by the WG would be great. (This goes for suggestions on retiring old options as well.) Look at the list below. Can folks fill in pointers to where the option is documented there is none now: 80 Naming Authority N naming authority 81 Client FQDN N Fully Qualified Domain Name [DRAFT-IETF-DHC-FQDN-OPTION] 82 Relay Agent Information N Relay Agent Information [RFC3046] 83 Agent Remote ID N Agent Remote ID 84 Agent Subnet Mask N Agent Subnet Mask 85 NDS Servers N Novell Directory Services [RFC2241] 86 NDS Tree Name N Novell Directory Services [RFC2241] 87 NDS Context N Novell Directory Services [RFC2241] 88 IEEE 1003.1 POSIX N IEEE 1003.1 POSIX Timezone 89 FQDN N Fully Qualified Domain Name 90 Authentication N Authentication [RFC3118] 91 Vines TCP/IP N Vines TCP/IP Server Option 92 Server Selection N Server Selection Option 93 Client System N Client System Architecture 94 Client NDI N Client Network Device Interface 95 LDAP N Lightweight Directory Access Protocol 96 IPv6 Transitions N IPv6 Transitions 97 UUID/GUID N UUID/GUID-based Client Identifier 98 User-Auth N Open Group's User Authentication [RFC2485] 99 Unassigned 100 Printer Name N Printer Name 101 MDHCP N DHCP multicast address 102-107 REMOVED/Unassigned 108 Swap Path N Swap Path Option 109 Unassigned 110 IPX Compatability N IPX Compatability 111 Unassigned 112 Netinfo Address N NetInfo Parent Server Address 113 Netinfo Tag N NetInfo Parent Server Tag 114 URL N URL 115 Failover N DHCP Failover Protocol 116 Auto-Config N DHCP Auto-Configuration [RFC2563] 117 Name Service Search N Name Service Search [RFC2937] 118 Subnet Selection Option 4 Subnet Selection Option [RFC3011] 119 Domain Search N DNS domain serach list [RFCABOB] 120 SIP Servers DHCP Option N SIP Servers DHCP Option [RFC3361] 121 Classless Static Route N Classless Static Route Option [RFCCSR7] Option 122-125 Unassigned 126 Extension N Extension 127 Extension N Extension 128-254 Private Use 255 End 0 None [RFC2132] Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 11 07:28:35 2002 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 HAA16863; Fri, 11 Oct 2002 07:28:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBTdv19412; Fri, 11 Oct 2002 07:29:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BBSuv19384 for ; Fri, 11 Oct 2002 07:28:56 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16531; Fri, 11 Oct 2002 07:26:48 -0400 (EDT) Message-Id: <200210111126.HAA16531@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, 11 Oct 2002 07:26:48 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-suboptions-kdc-serveraddress-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 : KDC Server Address Sub-option Author(s) : K. Luehrs, J. Bevilacqua Filename : draft-ietf-dhc-suboptions-kdc-serveraddress-00.txt Pages : 4 Date : 2002-10-10 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-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-suboptions-kdc-serveraddress-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-suboptions-kdc-serveraddress-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: <2002-10-10140555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-suboptions-kdc-serveraddress-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-10140555.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 Oct 11 08:22:04 2002 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 IAA18601; Fri, 11 Oct 2002 08:22:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCNFv22518; Fri, 11 Oct 2002 08:23:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BCMdv22487 for ; Fri, 11 Oct 2002 08:22:39 -0400 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 IAA18551 for ; Fri, 11 Oct 2002 08:20:29 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g9BCMZj11261; Fri, 11 Oct 2002 07:22:35 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9BCMZl04983; Fri, 11 Oct 2002 07:22:35 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PC82ZC>; Fri, 11 Oct 2002 07:22:35 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Thomas Narten'" Cc: "'John Schnizlein'" , "Woundy, Richard" , dhcwg@ietf.org Subject: RE: [dhcwg] Conflicting information regarding DHCP options 82 and 83. Date: Fri, 11 Oct 2002 07:22:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27120.E0D5DF00" 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_01C27120.E0D5DF00 Content-Type: text/plain; charset="iso-8859-1" Thomas: We are already working with IANA. They are willing to update the options list with the specific references to RFCs (as I have provided them). (As well as correct a few minor errors spotted by Ted and IANA themselves.) They will deassign the old options once Ralph works this through the IETF/DHC WG to assure that there are no objections. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Thursday, October 10, 2002 10:20 PM To: Bernie Volz (EUD) Cc: 'John Schnizlein'; Woundy, Richard; dhcwg@ietf.org Subject: Re: [dhcwg] Conflicting information regarding DHCP options 82 and 83. > How do we officially get these comments to IANA? Is this something Ralph > would handle? The IANA web pages are not necessarily organized ideally. I'm sure they'd welcome specific suggestions on how to make them better or to have more specific information to include. For example, a number of options don't point to an RFC or other document. If folks could fill in that info, getting it up on the web page would be good. Process wise, having Ralph provide a list to IANA that has been reviewed by the WG would be great. (This goes for suggestions on retiring old options as well.) Look at the list below. Can folks fill in pointers to where the option is documented there is none now: 80 Naming Authority N naming authority 81 Client FQDN N Fully Qualified Domain Name [DRAFT-IETF-DHC-FQDN-OPTION] 82 Relay Agent Information N Relay Agent Information [RFC3046] 83 Agent Remote ID N Agent Remote ID 84 Agent Subnet Mask N Agent Subnet Mask 85 NDS Servers N Novell Directory Services [RFC2241] 86 NDS Tree Name N Novell Directory Services [RFC2241] 87 NDS Context N Novell Directory Services [RFC2241] 88 IEEE 1003.1 POSIX N IEEE 1003.1 POSIX Timezone 89 FQDN N Fully Qualified Domain Name 90 Authentication N Authentication [RFC3118] 91 Vines TCP/IP N Vines TCP/IP Server Option 92 Server Selection N Server Selection Option 93 Client System N Client System Architecture 94 Client NDI N Client Network Device Interface 95 LDAP N Lightweight Directory Access Protocol 96 IPv6 Transitions N IPv6 Transitions 97 UUID/GUID N UUID/GUID-based Client Identifier 98 User-Auth N Open Group's User Authentication [RFC2485] 99 Unassigned 100 Printer Name N Printer Name 101 MDHCP N DHCP multicast address 102-107 REMOVED/Unassigned 108 Swap Path N Swap Path Option 109 Unassigned 110 IPX Compatability N IPX Compatability 111 Unassigned 112 Netinfo Address N NetInfo Parent Server Address 113 Netinfo Tag N NetInfo Parent Server Tag 114 URL N URL 115 Failover N DHCP Failover Protocol 116 Auto-Config N DHCP Auto-Configuration [RFC2563] 117 Name Service Search N Name Service Search [RFC2937] 118 Subnet Selection Option 4 Subnet Selection Option [RFC3011] 119 Domain Search N DNS domain serach list [RFCABOB] 120 SIP Servers DHCP Option N SIP Servers DHCP Option [RFC3361] 121 Classless Static Route N Classless Static Route Option [RFCCSR7] Option 122-125 Unassigned 126 Extension N Extension 127 Extension N Extension 128-254 Private Use 255 End 0 None [RFC2132] Thomas ------_=_NextPart_001_01C27120.E0D5DF00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Conflicting information regarding DHCP options 82 = and 83.

Thomas:

We are already working with IANA. They are willing to = update the
options list with the specific references to RFCs = (as I have
provided them). (As well as correct a few minor = errors spotted
by Ted and IANA themselves.)

They will deassign the old options once Ralph works = this through
the IETF/DHC WG to assure that there are no = objections.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Thursday, October 10, 2002 10:20 PM
To: Bernie Volz (EUD)
Cc: 'John Schnizlein'; Woundy, Richard; = dhcwg@ietf.org
Subject: Re: [dhcwg] Conflicting information = regarding DHCP options 82
and 83.


> How do we officially get these comments to IANA? = Is this something Ralph
> would handle?

The IANA web pages are not necessarily organized = ideally. I'm sure
they'd welcome specific suggestions on how to make = them better or to
have more specific information to include. For = example, a number of
options don't point to an RFC or other document. If = folks could fill
in that info, getting it up on the web page would be = good.

Process wise, having Ralph provide a list to IANA = that has been
reviewed by the WG would be great. (This goes for = suggestions on
retiring old options as well.)

Look at the list below. Can folks fill in pointers to = where the option
is documented  there is none now:


   80      Naming = Authority         = N    naming authority
   81      Client = FQDN           &n= bsp;  N    Fully Qualified Domain Name   = [DRAFT-IETF-DHC-FQDN-OPTION]
   82      Relay = Agent Information  N    Relay Agent = Information       [RFC3046]
   83      Agent = Remote ID          = N    Agent Remote = ID           &nbs= p;  
   84      Agent = Subnet Mask        = N    Agent Subnet = Mask           &n= bsp;
   85      NDS = Servers           = ;   N    Novell Directory = Services     [RFC2241]
   86      NDS = Tree = Name            = N    Novell Directory Services     = [RFC2241]
   87      NDS = Context           = ;   N    Novell Directory = Services     [RFC2241]
   88      IEEE = 1003.1 POSIX        = N    IEEE 1003.1 POSIX Timezone
   89      = FQDN           &n= bsp;         = N    Fully Qualified Domain Name
   90      = Authentication         &nbs= p; N    = Authentication         &nbs= p;      [RFC3118]
   91      Vines = TCP/IP           =   N    Vines TCP/IP Server Option
   92      Server = Selection         = N    Server Selection Option
   93      Client = System           = N    Client System Architecture
   94      Client = NDI           &nb= sp;   N    Client Network Device Interface =
   95      = LDAP           &n= bsp;         = N    Lightweight Directory Access Protocol
   96      IPv6 = Transitions         = N    IPv6 Transitions
   97      = UUID/GUID          &nb= sp;     N    UUID/GUID-based Client = Identifier
   98      = User-Auth          &nb= sp;     N    Open Group's User = Authentication [RFC2485]
   99      = Unassigned
   100     Printer = Name           &n= bsp; N    Printer Name
   101     = MDHCP           &= nbsp;        N    = DHCP multicast address
   102-107 REMOVED/Unassigned
   108     Swap = Path           &n= bsp;    N    Swap Path Option
   109     Unassigned =
   110     IPX = Compatability        = N    IPX Compatability
   111     Unassigned =
   112     Netinfo = Address          = N    NetInfo Parent Server Address
   113     Netinfo = Tag           &nb= sp;  N    NetInfo Parent Server Tag
   114     = URL           &nb= sp;          = N    URL
   115     = Failover          &nbs= p;      N    DHCP Failover = Protocol
   116     = Auto-Config          &= nbsp;   N    DHCP = Auto-Configuration       [RFC2563] =
   117     Name = Service Search      N    Name = Service = Search           = [RFC2937]
   118     Subnet = Selection Option  4    Subnet Selection = Option       [RFC3011]
   119     Domain = Search           = N    DNS domain serach = list        [RFCABOB]
   120     SIP Servers = DHCP Option  N    SIP Servers DHCP = Option       [RFC3361]
   121     Classless = Static Route   N    Classless Static Route = Option [RFCCSR7]
           = Option
   122-125 Unassigned
   126     = Extension          &nb= sp;     N    Extension
   127     = Extension          &nb= sp;     N    Extension
   128-254 Private Use
   255     = End           &nb= sp;          = 0    = None           &n= bsp;           &n= bsp;  [RFC2132]



Thomas  

------_=_NextPart_001_01C27120.E0D5DF00-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 11 13:02:52 2002 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 NAA28126; Fri, 11 Oct 2002 13:02:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BH3uv04324; Fri, 11 Oct 2002 13:03:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BH2hv04295 for ; Fri, 11 Oct 2002 13:02:43 -0400 Received: from e1.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28102 for ; Fri, 11 Oct 2002 13:00:31 -0400 (EDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9BH2bkC127910 for ; Fri, 11 Oct 2002 13:02:37 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9BH2Y5F029196 for ; Fri, 11 Oct 2002 13:02:35 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g9BH0dH08214 for ; Fri, 11 Oct 2002 13:00:39 -0400 Message-Id: <200210111700.g9BH0dH08214@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Fri, 11 Oct 2002 13:00:39 -0400 From: Thomas Narten Subject: [dhcwg] draft-ietf-dhc-packetcable-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: , Background: there was a quite a lot of private discussion/conference calls a month or two ago on this document, followed by a revised document. Here is my review of the current document. Thomas > 8.1. TSP's DHCP Server Address Sub-Options Seems to me that this options does (however subtly) modify DHC client behavior. My understanding is that CCC option 1/2, which lists a primary/backup DHC server are sent to the CM, which then communicates those two addresses to the MTA (a separate entity). The MTA then invokes DHC on its own, but is only allowed to talk to the servers whos addresses it received from the CM. In normal DHC, the client isn't restricted in anyway in what servers it communicates with. Thus, I would argue that CCC options 1/2 do modify the DHC protocol, albeit subtly and perhaps not signficantly. I am not particularly comfortable with this, but would like to hear more from the WG on this point. (Also, is my understanding here correct?) > Due to specific needs of the MTA configuration process (described in > [5]), a new CableLabs Client Configuration (CCC) option is needed for > the DHCP protocol. Both CM and MTA DHCP clients will request this > option. When requested, both the CM and TSP DHCP servers will > populate this option into DHCP responses. Doesn't the client also provide this option and fill in some info? better to say this above (one or two sentences here would suffice). Or maybe just merge Section 9 text into the text here. Should this document add a normative references to draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so referencing it shouldn't be a problem)? Seems like that would make sense. > - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035 > [7] section 3.1. Note that a terminating 0 is required. is compression allowed? (probably not useful -- then say so.) For CCC option 3, does IANA need to maintain a registry for other "types"? An IANA considerations would seem to be needed. It could say: - allocation of future types requires IETF Consensus (or whatever) - there will be no additional values, IANA does not need to maintain a registry - something else? The CCC options for configuring Kerberos parameters seems odd to me (what kerberos document talks about the need for tuning these parameters?). The IESG may want this reviewed by someone with kerberos clue. (I'm just saying this so that there are no surprises should this issue come up later.) Also, the kerberos REALM name option seems like one that could easily be more general (i.e, not cablelabs specific). But probably too late for this. Also: "Douglas E. Engert" writes: > You should also look at: > " Distributing Kerberos KDC and Realm Information with DNS" > http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-03.txt > Which describes how to find a KDC using DNS. I should point out that > W2K, MIT and I think Hiemdal all have this implemented. I assume that cablelabs is familiar with this but still wants to go the DHC route? > Cablelabs client devices issue DHCP requests that include DHCP > options 55 and 60. Option 55 will request the CCC option from the nit: would be good include neumonic names (e.g., ORO and class ID) here rather than just using the option number rather than assuming everyone knows the option meaning > IANA is requested to register codes for future CableLabs Client > Configuration Sub-options with an "Expert Review" approval policy as > described in RFC 2434 [2]. Future proposed sub-options will be > assigned a numeric code chosen by CableLabs, which will be > documented in the Internet Drafts that describe the sub-options. The > code assignment will be reviewed by a designated expert from the > IETF prior to publication in an RFC. 1) I think it should be IETF consensus, not expert review. these options need to be reviewed by the IETF before they get implemented and cast in stone. IETF Consensus is the safest way to ensure that this happens. 2) IANA chooses the values (as it typically does), not cablelabs. (Having cablelabs chose smells a bit like they want the values early for their implementations and/or specs) > 13. Security Considerations > > This draft relies on the DHCP protocol [4] for authentication and > security, i.e. it does not provide in excess of what DHCP is (or will > be) providing. It does not expose any security threats beyond what is > currently exposed by other DHCP options. The security considerations section is inadequate. It should say something about the options themselves and what the security implications are should the options be spoofed, etc. That is, what are the security issues related to the specific options discussed in the document? Is it required that some sort of DHC authentication be used in order to prevent vulnerabilities (say) to the configuration of the kerberos stuff? Note on the kerberos options, the following comment was made (privately): Jonathan Trostle writes: > Section 13 (Security Considerations) indicates they are relying on > the DHCP protocol for authentication and security (should be more > precise about what security services). > If the new option data is manipulated, various DoS attacks are possible. > One option, Kerberos realm name, is potentially more serious. By modifying > the realm, the attacker can change the user's TSP (if I recall correctly, > packetcable uses pkinit where the client authenticates the KDC by the > KDC's realm name in the KDC's certificate). Therefore, a malicious TSP > can act as a TSP for any user and then have access to the user's VoIP > and multimedia data. So it would be a good thing if the Kerberos realm > name is protected from modification in the DHCP protocol. Alternatively, > changing the realm name could be a means by which one TSP steals customers > from another TSP without the customer's permission. then later, Jonathan Trostle writes: > Tom, > Yes, there should be some extra wording in the security considerations at > least. I recall an argument that layer 2 encryption protects the link > between the modem and the head end, and the DCHP server may be at the head > end. But there should definitely be some words indicating that there is > protection for the DHCP messages at some layer. If this draft is used in > some other scenario (or even in the packetcable scenario possibly) then there > is the potential for security vulnerabilities. > Jonathan Finally, references should be split into normative/non-normative sections. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 11 13:04:58 2002 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 NAA28222; Fri, 11 Oct 2002 13:04:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BH69v04388; Fri, 11 Oct 2002 13:06:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BH5Wv04357 for ; Fri, 11 Oct 2002 13:05:32 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28155 for ; Fri, 11 Oct 2002 13:03:20 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-41.cisco.com [10.82.224.41]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA10348 for ; Fri, 11 Oct 2002 13:05:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20021011125559.03a78560@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Oct 2002 13:05:07 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] DHC WG charter In-Reply-To: <2C054C5A-8014-11D6-9A23-00039367340A@nominum.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here's a revised draft WG charter, with edits based on feedback from mailing list discussion. The primary changes in this revision are: * Rewrote the authentication charter item to require require development of a threat model and analysis of RFC3118, with suggestions about specific issues to consider in the analysis. Added separate charter item to develop mechanisms to address issues identified by threat model and analysis. * Deleted references to specific options to be published as part of DHCPv6; deleted reference to prefix delegation, DNS configuration (see below for more details) * Replaced charter item on acceptance of DHCP as Standard with analysis of problems with current spec that impede development of interoperable implementations. We need consensus on whether the following charter items should be included in the charter: - Develop extensions to DHCPv6 for prefix delegation, DNS configuration, etc. - Determine the requirements for DHC to support the dynamic renumbering of networks using fast path delegation as CPE front end between ISP and Private Networks. Please reply with comments... - Ralph ===== Dynamic Host Configuration (dhc) The working group has the following primary objectives: * Develop a threat model and analysis of the authentication protection provided by RFC3118; specific issues to be addressed include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through FORCERENEW * Develop requirements for any new protocols to address threats or other enhancement identified by the threat model and analysis of 3118 * Complete the specification of DHCP for IPv6 (DHCPv6): - Gain acceptance and publication of current Internet Draft as Proposed Standard - Develop and publish specifications for options and other extensions to DHCPv6, including those already published as Internet Drafts - Encourage independent implementations and report on interoperability testing - Revise specification and publish for acceptance as Draft Standard by 10/18/2002 * 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 the specification and publish work in progress as standards: - Failover protocol - DHCP/DDNS interaction - SNMP MIB - Host name options - Leasequery - Other client and relay agent options * Review new options for DHCP, as deemed appropriate by the working group and/or the Internet area directors _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 11 14:37:04 2002 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 OAA01712; Fri, 11 Oct 2002 14:37:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BIc8v09645; Fri, 11 Oct 2002 14:38:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9BIawv09060 for ; Fri, 11 Oct 2002 14:36:58 -0400 Received: from zmamail05.zma.compaq.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01664 for ; Fri, 11 Oct 2002 14:34:46 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id F006F7FC; Fri, 11 Oct 2002 14:36:51 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 11 Oct 2002 14:36:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] DHC WG charter Date: Fri, 11 Oct 2002 14:36:51 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE94BC@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] DHC WG charter Thread-Index: AcJxS+CXJ//RcqMaQaitnxkTRkyDeAACLskQ From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 11 Oct 2002 18:36:51.0808 (UTC) FILETIME=[2A722E00:01C27155] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9BIawv09061 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 OK with your update and replaces. > - Develop extensions to DHCPv6 for prefix delegation, DNS > configuration, etc. > - Determine the requirements for DHC to support the dynamic > renumbering of networks using fast path delegation as CPE > front end between ISP and Private Networks. > > Please reply with comments... > Both topics above have charateristics that will require the IETF to develop protocol operations or extensions to make them happen. They also both have market needs so we have a customer. As they will be using dhc to perform these functions and that the necessary routing, application, dhc, and IP stack expertise exists in the dhc working group and that is a clear effort by the dhc group these should be part of our charter. If there are any backroom statements about the expertise in this group to solve this problem let them have integrity and state so on this list or do not use it to prevent this charter ammendment. regards, /jim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 14 11:52:08 2002 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 LAA24154; Mon, 14 Oct 2002 11:52:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EFrDv07007; Mon, 14 Oct 2002 11:53:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EFpEv06947 for ; Mon, 14 Oct 2002 11:51:14 -0400 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 LAA24080 for ; Mon, 14 Oct 2002 11:49:01 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g9EFpAg29974; Mon, 14 Oct 2002 10:51:10 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9EFpAD05737; Mon, 14 Oct 2002 10:51:10 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PDAN7H>; Mon, 14 Oct 2002 10:51:10 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] DHC WG charter Date: Mon, 14 Oct 2002 10:51:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27399.83462CC0" 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_01C27399.83462CC0 Content-Type: text/plain; charset="iso-8859-1" Ralph: Some comments: Regarding: * Develop requirements for any new protocols to address threats or other enhancement identified by the threat model and analysis of 3118 Can we better qualify "new protocols"? This sounds rather open ended and we don't mean to impose on things outside of DHCP. Would this be "new DHCP authentication protocols"? Regarding: - Develop extensions to DHCPv6 for prefix delegation, DNS configuration, etc. - Determine the requirements for DHC to support the dynamic renumbering of networks using fast path delegation as CPE front end between ISP and Private Networks. I don't have any issues with including the first - these extensions are very important. I'm less certain of the second and not exactly sure if this is part of the Prefix Delegation issue or something else. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, October 11, 2002 1:05 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] DHC WG charter Here's a revised draft WG charter, with edits based on feedback from mailing list discussion. The primary changes in this revision are: * Rewrote the authentication charter item to require require development of a threat model and analysis of RFC3118, with suggestions about specific issues to consider in the analysis. Added separate charter item to develop mechanisms to address issues identified by threat model and analysis. * Deleted references to specific options to be published as part of DHCPv6; deleted reference to prefix delegation, DNS configuration (see below for more details) * Replaced charter item on acceptance of DHCP as Standard with analysis of problems with current spec that impede development of interoperable implementations. We need consensus on whether the following charter items should be included in the charter: - Develop extensions to DHCPv6 for prefix delegation, DNS configuration, etc. - Determine the requirements for DHC to support the dynamic renumbering of networks using fast path delegation as CPE front end between ISP and Private Networks. Please reply with comments... - Ralph ===== Dynamic Host Configuration (dhc) The working group has the following primary objectives: * Develop a threat model and analysis of the authentication protection provided by RFC3118; specific issues to be addressed include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through FORCERENEW * Develop requirements for any new protocols to address threats or other enhancement identified by the threat model and analysis of 3118 * Complete the specification of DHCP for IPv6 (DHCPv6): - Gain acceptance and publication of current Internet Draft as Proposed Standard - Develop and publish specifications for options and other extensions to DHCPv6, including those already published as Internet Drafts - Encourage independent implementations and report on interoperability testing - Revise specification and publish for acceptance as Draft Standard by 10/18/2002 * 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 the specification and publish work in progress as standards: - Failover protocol - DHCP/DDNS interaction - SNMP MIB - Host name options - Leasequery - Other client and relay agent options * Review new options for DHCP, as deemed appropriate by the working group and/or the Internet area directors _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C27399.83462CC0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] DHC WG charter

Ralph:

Some comments:

Regarding:
* Develop requirements for any new protocols to address threats or
   other enhancement identified by the threat model and analysis of
   3118

Can we better qualify "new protocols"? This sounds rather open ended and we don't
mean to impose on things outside of DHCP. Would this be "new DHCP authentication
protocols"?


Regarding:
- Develop extensions to DHCPv6 for prefix delegation, DNS
   configuration, etc.
- Determine the requirements for DHC to support the dynamic
   renumbering of networks using fast path delegation as CPE
   front end between ISP and Private Networks.

I don't have any issues with including the first - these extensions are very
important. I'm less certain of the second and not exactly sure if this is part
of the Prefix Delegation issue or something else.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, October 11, 2002 1:05 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] DHC WG charter


Here's a revised draft WG charter, with edits based on feedback from
mailing list discussion.  The primary changes in this revision are:

* Rewrote the authentication charter item to require
   require development of a threat model and analysis
   of RFC3118, with suggestions about specific issues
   to consider in the analysis.  Added separate charter
   item to develop mechanisms to address issues identified
   by threat model and analysis.
* Deleted references to specific options to be published
   as part of DHCPv6; deleted reference to prefix delegation,
   DNS configuration (see below for more details)
* Replaced charter item on acceptance of DHCP as Standard
   with analysis of problems with current spec that impede
   development of interoperable implementations.

We need consensus on whether the following charter items should be included
in the charter:

- Develop extensions to DHCPv6 for prefix delegation, DNS
   configuration, etc.
- Determine the requirements for DHC to support the dynamic
   renumbering of networks using fast path delegation as CPE
   front end between ISP and Private Networks.

Please reply with comments...

- Ralph

=====


                   Dynamic Host Configuration (dhc)

The working group has the following primary objectives:

* Develop a threat model and analysis of the authentication
   protection provided by RFC3118; specific issues to be addressed
   include:
   - Improved key management and scalability
   - Security for messages passed between relay agents and servers
   - Threats of DoS attacks through FORCERENEW

* Develop requirements for any new protocols to address threats or
   other enhancement identified by the threat model and analysis of
   3118

* Complete the specification of DHCP for IPv6 (DHCPv6):
   - Gain acceptance and publication of current Internet Draft as
     Proposed Standard
   - Develop and publish specifications for options and other
     extensions to DHCPv6, including those already published as
     Internet Drafts
   - Encourage independent implementations and report on
     interoperability testing
   - Revise specification and publish for acceptance as Draft Standard
     by 10/18/2002

* 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 the specification and publish work in progress as
   standards:
   - Failover protocol
   - DHCP/DDNS interaction
   - SNMP MIB
   - Host name options
   - Leasequery
   - Other client and relay agent options

* Review new options for DHCP, as deemed appropriate by the working
   group and/or the Internet area directors

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

------_=_NextPart_001_01C27399.83462CC0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 14 12:46:58 2002 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 MAA25742; Mon, 14 Oct 2002 12:46:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EGm8v10393; Mon, 14 Oct 2002 12:48:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EGlsv10359 for ; Mon, 14 Oct 2002 12:47:54 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25642 for ; Mon, 14 Oct 2002 12:45:41 -0400 (EDT) Received: from paduffy-w2k.cisco.com (rtp-vpn2-593.cisco.com [10.82.242.81]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA29468; Mon, 14 Oct 2002 12:47:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20021014124706.0289bf18@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Oct 2002 12:47:39 -0400 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt Cc: dhcwg@ietf.org In-Reply-To: <200210111700.g9BH0dH08214@rotala.raleigh.ibm.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: , Thank you...we'll have a detailed response Wednesday. Cheers, At 01:00 PM 10/11/2002 -0400, Thomas Narten wrote: >Background: there was a quite a lot of private discussion/conference >calls a month or two ago on this document, followed by a revised >document. Here is my review of the current document. > >Thomas > > > 8.1. TSP's DHCP Server Address Sub-Options > >Seems to me that this options does (however subtly) modify DHC client >behavior. My understanding is that CCC option 1/2, which >lists a primary/backup DHC server are sent to the CM, which then >communicates those two addresses to the MTA (a separate entity). The >MTA then invokes DHC on its own, but is only allowed to talk to the >servers whos addresses it received from the CM. In normal DHC, the >client isn't restricted in anyway in what servers it communicates >with. Thus, I would argue that CCC options 1/2 do modify the DHC >protocol, albeit subtly and perhaps not signficantly. I am not >particularly comfortable with this, but would like to hear more from >the WG on this point. (Also, is my understanding here correct?) > > > Due to specific needs of the MTA configuration process (described in > > [5]), a new CableLabs Client Configuration (CCC) option is needed for > > the DHCP protocol. Both CM and MTA DHCP clients will request this > > option. When requested, both the CM and TSP DHCP servers will > > populate this option into DHCP responses. > > >Doesn't the client also provide this option and fill in some info? >better to say this above (one or two sentences here would suffice). Or >maybe just merge Section 9 text into the text here. > >Should this document add a normative references to >draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so >referencing it shouldn't be a problem)? Seems like that would make >sense. > > > - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035 > > [7] section 3.1. Note that a terminating 0 is required. > >is compression allowed? (probably not useful -- then say so.) > >For CCC option 3, does IANA need to maintain a registry for other >"types"? An IANA considerations would seem to be needed. It could say: > - allocation of future types requires IETF Consensus (or whatever) > - there will be no additional values, IANA does not need to maintain > a registry > - something else? > >The CCC options for configuring Kerberos parameters seems odd to me >(what kerberos document talks about the need for tuning these >parameters?). The IESG may want this reviewed by someone with kerberos >clue. (I'm just saying this so that there are no surprises should this >issue come up later.) > >Also, the kerberos REALM name option seems like one that could easily >be more general (i.e, not cablelabs specific). But probably too late >for this. Also: > >"Douglas E. Engert" writes: > > > You should also look at: > > " Distributing Kerberos KDC and Realm Information with DNS" > > http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-03.txt > > > Which describes how to find a KDC using DNS. I should point out that > > W2K, MIT and I think Hiemdal all have this implemented. > >I assume that cablelabs is familiar with this but still wants to go >the DHC route? > > > Cablelabs client devices issue DHCP requests that include DHCP > > options 55 and 60. Option 55 will request the CCC option from the > >nit: would be good include neumonic names (e.g., ORO and class ID) >here rather than just using the option number rather than assuming >everyone knows the option meaning > > > IANA is requested to register codes for future CableLabs Client > > Configuration Sub-options with an "Expert Review" approval policy as > > described in RFC 2434 [2]. Future proposed sub-options will be > > assigned a numeric code chosen by CableLabs, which will be > > documented in the Internet Drafts that describe the sub-options. The > > code assignment will be reviewed by a designated expert from the > > IETF prior to publication in an RFC. > >1) I think it should be IETF consensus, not expert review. these > options need to be reviewed by the IETF before they get implemented > and cast in stone. IETF Consensus is the safest way to ensure that > this happens. > >2) IANA chooses the values (as it typically does), not > cablelabs. (Having cablelabs chose smells a bit like they want the > values early for their implementations and/or specs) > > > 13. Security Considerations > > > > This draft relies on the DHCP protocol [4] for authentication and > > security, i.e. it does not provide in excess of what DHCP is (or will > > be) providing. It does not expose any security threats beyond what is > > currently exposed by other DHCP options. > >The security considerations section is inadequate. It should say >something about the options themselves and what the security >implications are should the options be spoofed, etc. That is, what are >the security issues related to the specific options discussed in the >document? Is it required that some sort of DHC authentication be used >in order to prevent vulnerabilities (say) to the configuration of the >kerberos stuff? > >Note on the kerberos options, the following comment was made >(privately): > >Jonathan Trostle writes: > > > Section 13 (Security Considerations) indicates they are relying on > > the DHCP protocol for authentication and security (should be more > > precise about what security services). > > > If the new option data is manipulated, various DoS attacks are possible. > > One option, Kerberos realm name, is potentially more serious. By modifying > > the realm, the attacker can change the user's TSP (if I recall correctly, > > packetcable uses pkinit where the client authenticates the KDC by the > > KDC's realm name in the KDC's certificate). Therefore, a malicious TSP > > can act as a TSP for any user and then have access to the user's VoIP > > and multimedia data. So it would be a good thing if the Kerberos realm > > name is protected from modification in the DHCP protocol. Alternatively, > > changing the realm name could be a means by which one TSP steals customers > > from another TSP without the customer's permission. > >then later, > >Jonathan Trostle writes: > > > Tom, > > > Yes, there should be some extra wording in the security considerations at > > least. I recall an argument that layer 2 encryption protects the link > > between the modem and the head end, and the DCHP server may be at the head > > end. But there should definitely be some words indicating that there is > > protection for the DHCP messages at some layer. If this draft is used in > > some other scenario (or even in the packetcable scenario possibly) then > there > > is the potential for security vulnerabilities. > > > Jonathan > >Finally, references should be split into normative/non-normative >sections. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 14 14:18:28 2002 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 OAA28615; Mon, 14 Oct 2002 14:18:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EIJav15517; Mon, 14 Oct 2002 14:19:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EIIdv15481 for ; Mon, 14 Oct 2002 14:18:40 -0400 Received: from cichlid.adsl.duke.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28575 for ; Mon, 14 Oct 2002 14:16:24 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g9EIGhP04091; Mon, 14 Oct 2002 14:16:43 -0400 Message-Id: <200210141816.g9EIGhP04091@cichlid.adsl.duke.edu> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHC WG charter In-Reply-To: Message from Ralph Droms of "Fri, 11 Oct 2002 13:05:07 EDT." <4.3.2.7.2.20021011125559.03a78560@funnel.cisco.com> Date: Mon, 14 Oct 2002 14:16:43 -0400 From: Thomas Narten 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: , some comments on the charter: Nits: Would be good to have a short intro sentence at the start something like: The base DHC protocol is documented in RFCs 2131 and 2132 as well as a number of related extensions and options (e.g., RFC 3118). The working group has the following primary objectives ... > * Develop a threat model and analysis of the authentication > protection provided by RFC3118; specific issues to be addressed > include: > - Improved key management and scalability Sounds here like your already jumping ahead to the requirements for new protocols. I.e., shouldn't this phase be focused on undertstanding limiations of the current mechanisms? Is this just a wording issue? > - Security for messages passed between relay agents and servers > - Threats of DoS attacks through FORCERENEW > * Develop requirements for any new protocols to address threats or > other enhancement identified by the threat model and analysis of > 3118 What's missing above is a clear statement that this WG will develop new authentication mechanisms that address the deployability problems with the current schemes (whether through an extension to 3118 or something else). Or that it will address the relay-agent to DHC server path. > * Complete the specification of DHCP for IPv6 (DHCPv6): > - Gain acceptance and publication of current Internet Draft as > Proposed Standard > - Develop and publish specifications for options and other > extensions to DHCPv6, including those already published as > Internet Drafts General comment on options (both IPv4 and IPv6). I'd like the charter to clearly indicate that the DHC WG will be reviewing options to make sure they are consistent with the protocol, other option usages, etc. In terms of reviewing options for their semantic contents, that will be done by subject matter experts, which may well not be in this WG. This WG is not to take on options as WG documents until such an outside expert has been identified and, e.g., the relevant WG has agreed on the need for such an option. What I'd like to avoid is having the DHC WG spend time on options for which there isn't a clear customer. > - Encourage independent implementations and report on > interoperability testing > - Revise specification and publish for acceptance as Draft Standard > by 10/18/2002 > * 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. The way its written above, sounds like one big fat hard-to-write document. :-) Can't we do something simpler, such as just have folks write IDs that take on specific issues and advance them as standalone RFCs (as appropriate), incorporating them into the base spec when the base spec is republished? I'm worried that the above reads like a lot of work that no one will be foolish enough to sign up for. > * Complete the specification and publish work in progress as > standards: > - Failover protocol > - DHCP/DDNS interaction > - SNMP MIB > - Host name options > - Leasequery > - Other client and relay agent options Are there IDs for all of the above? If so, citing them would be good. Also, I don't like the "other client and relay agent options" as it is too open ended. I think the WG needs a way of vetting potential options before the WG takes them on officially. > * Review new options for DHCP, as deemed appropriate by the working > group and/or the Internet area directors See above. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 14 18:26:17 2002 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 SAA04600; Mon, 14 Oct 2002 18:26:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EMRQv28574; Mon, 14 Oct 2002 18:27:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9EMQ2v28498 for ; Mon, 14 Oct 2002 18:26:02 -0400 Received: from zmamail04.zma.compaq.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04400 for ; Mon, 14 Oct 2002 18:23:46 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D7E335AF0; Mon, 14 Oct 2002 18:25:55 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 14 Oct 2002 18:25:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] DHC WG charter Date: Mon, 14 Oct 2002 18:25:55 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE94F2@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] DHC WG charter Thread-Index: AcJzsQdHiKev0cazT7+e3BCiHMXZpwAH2DEQ From: "Bound, Jim" To: "Thomas Narten" , "Ralph Droms" Cc: X-OriginalArrivalTime: 14 Oct 2002 22:25:55.0710 (UTC) FILETIME=[A9B071E0:01C273D0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9EMQ2v28499 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 Thomas, And who defines who a subject matter expert is? What if we don't think they measure up technically? Do we go to Harald as IESG Chair? Your tone is belittleing to this group IMO. I don't like it sir. thanks /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Monday, October 14, 2002 2:17 PM > To: Ralph Droms > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DHC WG charter > > > some comments on the charter: > > Nits: > > Would be good to have a short intro sentence at the start something > like: > > The base DHC protocol is documented in RFCs 2131 and 2132 as well as a > number of related extensions and options (e.g., RFC 3118). The working > group has the following primary objectives ... > > > * Develop a threat model and analysis of the authentication > > protection provided by RFC3118; specific issues to be addressed > > include: > > - Improved key management and scalability > > Sounds here like your already jumping ahead to the requirements for > new protocols. I.e., shouldn't this phase be focused on undertstanding > limiations of the current mechanisms? Is this just a wording issue? > > > - Security for messages passed between relay agents and servers > > - Threats of DoS attacks through FORCERENEW > > > * Develop requirements for any new protocols to address threats or > > other enhancement identified by the threat model and analysis of > > 3118 > > What's missing above is a clear statement that this WG will develop > new authentication mechanisms that address the deployability problems > with the current schemes (whether through an extension to 3118 or > something else). Or that it will address the relay-agent to DHC server > path. > > > * Complete the specification of DHCP for IPv6 (DHCPv6): > > - Gain acceptance and publication of current Internet Draft as > > Proposed Standard > > - Develop and publish specifications for options and other > > extensions to DHCPv6, including those already published as > > Internet Drafts > > General comment on options (both IPv4 and IPv6). I'd like the charter > to clearly indicate that the DHC WG will be reviewing options to make > sure they are consistent with the protocol, other option usages, etc. > > In terms of reviewing options for their semantic contents, that > will be done by subject matter experts, which may well not be in this > WG. This WG is not to take on options as WG documents until such an > outside expert has been identified and, e.g., the relevant WG has > agreed on the need for such an option. What I'd like to avoid is > having the DHC WG spend time on options for which there isn't a clear > customer. > > > - Encourage independent implementations and report on > > interoperability testing > > - Revise specification and publish for acceptance as > Draft Standard > > by 10/18/2002 > > > * 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. > > The way its written above, sounds like one big fat hard-to-write > document. :-) Can't we do something simpler, such as just have folks > write IDs that take on specific issues and advance them as > standalone RFCs (as appropriate), incorporating them into the base > spec when the base spec is republished? I'm worried that the above > reads like a lot of work that no one will be foolish enough > to sign up for. > > > * Complete the specification and publish work in progress as > > standards: > > - Failover protocol > > - DHCP/DDNS interaction > > - SNMP MIB > > - Host name options > > - Leasequery > > - Other client and relay agent options > > Are there IDs for all of the above? If so, citing them would be good. > > Also, I don't like the "other client and relay agent options" as it is > too open ended. I think the WG needs a way of vetting potential > options before the WG takes them on officially. > > > * Review new options for DHCP, as deemed appropriate by the working > > group and/or the Internet area directors > > See above. > > Thomas > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 14 22:35:31 2002 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 WAA08752; Mon, 14 Oct 2002 22:35:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F2afv07362; Mon, 14 Oct 2002 22:36:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F2Zkv07334 for ; Mon, 14 Oct 2002 22:35:46 -0400 Received: from cichlid.adsl.duke.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08707 for ; Mon, 14 Oct 2002 22:33:28 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g9F2Xiq06688; Mon, 14 Oct 2002 22:33:44 -0400 Message-Id: <200210150233.g9F2Xiq06688@cichlid.adsl.duke.edu> To: "Bound, Jim" cc: "Ralph Droms" , dhcwg@ietf.org Subject: Re: [dhcwg] DHC WG charter In-Reply-To: Message from "Bound, Jim" of "Mon, 14 Oct 2002 18:25:55 EDT." <9C422444DE99BC46B3AD3C6EAFC9711B02BE94F2@tayexc13.americas.cpqcorp.net> Date: Mon, 14 Oct 2002 22:33:43 -0400 From: Thomas Narten 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: , > And who defines who a subject matter expert is? I would hope that this will generally be obvious. The folks who understand/develop the technology that the DHC option is to be used for. That could the SIP, IPS, LDAP, Kerberos, and SLP folk, etc. In general, the DHC WG won't know much about how such options will be used, so they can't really evaluate whether the option (other than its encoding) makes sense. What I'm trying to avoid is having the charter imply (or seem to imply) that the WG will take on any/all options someone brings to the WG. I think it is fine for the WG to review any option from the perspective of DHC, but it should be clear that approval of all DHC options is a two step process. Acceptance from the DHC community and the actual users of the option. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 14 23:02:10 2002 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 XAA09252; Mon, 14 Oct 2002 23:02:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F33Qv08665; Mon, 14 Oct 2002 23:03:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9F303v08579 for ; Mon, 14 Oct 2002 23:00:03 -0400 Received: from zmamail05.zma.compaq.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09183 for ; Mon, 14 Oct 2002 22:57:46 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E5D12BE0; Mon, 14 Oct 2002 22:59:54 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 14 Oct 2002 22:59:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] DHC WG charter Date: Mon, 14 Oct 2002 22:59:54 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE94FC@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] DHC WG charter Thread-Index: AcJz84sCPtuHVy1GSbWagi/KUbhbswAA1N7Q From: "Bound, Jim" To: "Thomas Narten" Cc: "Ralph Droms" , X-OriginalArrivalTime: 15 Oct 2002 02:59:54.0757 (UTC) FILETIME=[F01FF350:01C273F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9F303v08580 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 that was a good answer and I am glad your doing that. more clear now. thanks /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Monday, October 14, 2002 10:34 PM > To: Bound, Jim > Cc: Ralph Droms; dhcwg@ietf.org > Subject: Re: [dhcwg] DHC WG charter > > > > And who defines who a subject matter expert is? > > I would hope that this will generally be obvious. The folks who > understand/develop the technology that the DHC option is to be used > for. That could the SIP, IPS, LDAP, Kerberos, and SLP folk, etc. In > general, the DHC WG won't know much about how such options will be > used, so they can't really evaluate whether the option (other than its > encoding) makes sense. What I'm trying to avoid is having the charter > imply (or seem to imply) that the WG will take on any/all options > someone brings to the WG. I think it is fine for the WG to review any > option from the perspective of DHC, but it should be clear that > approval of all DHC options is a two step process. Acceptance from the > DHC community and the actual users of the option. > > Thomas > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 15 09:08:44 2002 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 JAA00164; Tue, 15 Oct 2002 09:08:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FD9ov14032; Tue, 15 Oct 2002 09:09:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FD6rv13397 for ; Tue, 15 Oct 2002 09:06:53 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29888 for ; Tue, 15 Oct 2002 09:04:40 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-814.cisco.com [10.82.243.46]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00650; Tue, 15 Oct 2002 09:06:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20021015085328.0392fbd0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Oct 2002 08:55:55 -0400 To: "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] DHC WG charter Cc: dhcwg@ietf.org 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: , At 10:51 AM 10/14/2002 -0500, Bernie Volz (EUD) wrote: >Ralph: > >Some comments: > >Regarding: >* Develop requirements for any new protocols to address threats or > other enhancement identified by the threat model and analysis of > 3118 > >Can we better qualify "new protocols"? This sounds rather open ended and >we don't >mean to impose on things outside of DHCP. Would this be "new DHCP >authentication >protocols"? Yes - "new DHPC authentication protocols" is what was intended. At the risk of verbosity, some hint about "using the existing DHCP authentication framework (RFC3118) and other existing security protocols (IPsec, etc.)" might be appropriate. >Regarding: >- Develop extensions to DHCPv6 for prefix delegation, DNS > configuration, etc. >- Determine the requirements for DHC to support the dynamic > renumbering of networks using fast path delegation as CPE > front end between ISP and Private Networks. > >I don't have any issues with including the first - these extensions are very >important. I'm less certain of the second and not exactly sure if this is >part >of the Prefix Delegation issue or something else. > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Friday, October 11, 2002 1:05 PM >To: dhcwg@ietf.org >Subject: Re: [dhcwg] DHC WG charter > >Here's a revised draft WG charter, with edits based on feedback from >mailing list discussion. The primary changes in this revision are: > >* Rewrote the authentication charter item to require > require development of a threat model and analysis > of RFC3118, with suggestions about specific issues > to consider in the analysis. Added separate charter > item to develop mechanisms to address issues identified > by threat model and analysis. >* Deleted references to specific options to be published > as part of DHCPv6; deleted reference to prefix delegation, > DNS configuration (see below for more details) >* Replaced charter item on acceptance of DHCP as Standard > with analysis of problems with current spec that impede > development of interoperable implementations. > >We need consensus on whether the following charter items should be included >in the charter: > >- Develop extensions to DHCPv6 for prefix delegation, DNS > configuration, etc. >- Determine the requirements for DHC to support the dynamic > renumbering of networks using fast path delegation as CPE > front end between ISP and Private Networks. > >Please reply with comments... > >- Ralph > >===== > > Dynamic Host Configuration (dhc) > >The working group has the following primary objectives: > >* Develop a threat model and analysis of the authentication > protection provided by RFC3118; specific issues to be addressed > include: > - Improved key management and scalability > - Security for messages passed between relay agents and servers > - Threats of DoS attacks through FORCERENEW > >* Develop requirements for any new protocols to address threats or > other enhancement identified by the threat model and analysis of > 3118 > >* Complete the specification of DHCP for IPv6 (DHCPv6): > - Gain acceptance and publication of current Internet Draft as > Proposed Standard > - Develop and publish specifications for options and other > extensions to DHCPv6, including those already published as > Internet Drafts > - Encourage independent implementations and report on > interoperability testing > - Revise specification and publish for acceptance as Draft Standard > by 10/18/2002 > >* 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 the specification and publish work in progress as > standards: > - Failover protocol > - DHCP/DDNS interaction > - SNMP MIB > - Host name options > - Leasequery > - Other client and relay agent options > >* Review new options for DHCP, as deemed appropriate by the working > group and/or the Internet area directors > >_______________________________________________ >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 Oct 15 09:11:06 2002 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 JAA00334; Tue, 15 Oct 2002 09:11:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDCIv14129; Tue, 15 Oct 2002 09:12:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FD6sv13401 for ; Tue, 15 Oct 2002 09:06:54 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29891 for ; Tue, 15 Oct 2002 09:04:41 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-814.cisco.com [10.82.243.46]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00657; Tue, 15 Oct 2002 09:06:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20021015085610.00b5baa8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Oct 2002 09:06:44 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] DHC WG charter Cc: dhcwg@ietf.org In-Reply-To: <200210141816.g9EIGhP04091@cichlid.adsl.duke.edu> References: <4.3.2.7.2.20021011125559.03a78560@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 02:16 PM 10/14/2002 -0400, Thomas Narten wrote: >some comments on the charter: > >Nits: > >Would be good to have a short intro sentence at the start something >like: > >The base DHC protocol is documented in RFCs 2131 and 2132 as well as a >number of related extensions and options (e.g., RFC 3118). The working >group has the following primary objectives ... OK. > > * Develop a threat model and analysis of the authentication > > protection provided by RFC3118; specific issues to be addressed > > include: > > - Improved key management and scalability > >Sounds here like your already jumping ahead to the requirements for >new protocols. I.e., shouldn't this phase be focused on undertstanding >limiations of the current mechanisms? Is this just a wording issue? Perhaps it is a wording issue? s/include/might include/ ?? The intended purpose for the bullet list is to capture current "common knowledge" about the threat model and RFC3118. > > - Security for messages passed between relay agents and servers > > - Threats of DoS attacks through FORCERENEW > > > * Develop requirements for any new protocols to address threats or > > other enhancement identified by the threat model and analysis of > > 3118 > >What's missing above is a clear statement that this WG will develop >new authentication mechanisms that address the deployability problems >with the current schemes (whether through an extension to 3118 or >something else). Or that it will address the relay-agent to DHC server >path. Can you explain this comment in a different way, as it seems to be at cross-purposes with your previous comment about "jumping ahead to the requirements". I think we're in having a violent agreement that we want to (a) get some DHCP authentication out to the client deployed and common wisdom is that the best path is through new mechanisms in the RFC3118 framework; and (b) secure communication between the DHCP relay agents and servers. > > * Complete the specification of DHCP for IPv6 (DHCPv6): > > - Gain acceptance and publication of current Internet Draft as > > Proposed Standard > > - Develop and publish specifications for options and other > > extensions to DHCPv6, including those already published as > > Internet Drafts > >General comment on options (both IPv4 and IPv6). I'd like the charter >to clearly indicate that the DHC WG will be reviewing options to make >sure they are consistent with the protocol, other option usages, etc. The charter has a separate bullet item for review of options. Are you suggesting that the bullet item be extended to include "consistent with the protocol, other option usages, etc." as specific types of review? >In terms of reviewing options for their semantic contents, that >will be done by subject matter experts, which may well not be in this >WG. This WG is not to take on options as WG documents until such an >outside expert has been identified and, e.g., the relevant WG has >agreed on the need for such an option. What I'd like to avoid is >having the DHC WG spend time on options for which there isn't a clear >customer. > > > - Encourage independent implementations and report on > > interoperability testing > > - Revise specification and publish for acceptance as Draft Standard > > by 10/18/2002 > > > * 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. > >The way its written above, sounds like one big fat hard-to-write >document. :-) Can't we do something simpler, such as just have folks >write IDs that take on specific issues and advance them as >standalone RFCs (as appropriate), incorporating them into the base >spec when the base spec is republished? I'm worried that the above >reads like a lot of work that no one will be foolish enough to sign up for. > > > * Complete the specification and publish work in progress as > > standards: > > - Failover protocol > > - DHCP/DDNS interaction > > - SNMP MIB > > - Host name options > > - Leasequery > > - Other client and relay agent options > >Are there IDs for all of the above? If so, citing them would be good. OK. >Also, I don't like the "other client and relay agent options" as it is >too open ended. I think the WG needs a way of vetting potential >options before the WG takes them on officially. There are other options currently in the pipeline; this "other ... options" bullet is intended to refer to those options that are "work in progress". New work is intended to fall under the following bullet item. > > * Review new options for DHCP, as deemed appropriate by the working > > group and/or the Internet area directors > >See above. > >Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 15 09:27:52 2002 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 JAA00834; Tue, 15 Oct 2002 09:27:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDT5v14683; Tue, 15 Oct 2002 09:29:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDP5v14548 for ; Tue, 15 Oct 2002 09:25:05 -0400 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00703 for ; Tue, 15 Oct 2002 09:22:52 -0400 (EDT) Received: from srvmail.cablelabs.com (srvmail.cablelabs.com [10.5.0.15]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id g9FDP0PL003489; Tue, 15 Oct 2002 07:25:01 -0600 (MDT) Received: by srvmail.cablelabs.com with Internet Mail Service (5.5.2653.19) id <4GFF4GVB>; Tue, 15 Oct 2002 07:25:00 -0600 Message-ID: <4DF5E8A771ECD21187020008C7B1C5AF03CED81C@srvmail.cablelabs.com> From: Jean-Francois Mule To: "'Thomas Narten'" Cc: Matt Osman , dhcwg@ietf.org Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-03.txt Date: Tue, 15 Oct 2002 07:24:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Approved: ondar 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 will reply the comments pertaining to draft-ietf-dhc-packetcable-03. I'm replying on the more general questions Thomas asked on behalf of CableLabs. Thomans Narten wrote: > > IANA is requested to register codes for future CableLabs Client > > Configuration Sub-options with an "Expert Review" > approval policy as > > described in RFC 2434 [2]. Future proposed sub-options will be > > assigned a numeric code chosen by CableLabs, which will be > > documented in the Internet Drafts that describe the > sub-options. The > > code assignment will be reviewed by a designated expert from the > > IETF prior to publication in an RFC. > > 1) I think it should be IETF consensus, not expert review. these > options need to be reviewed by the IETF before they get implemented > and cast in stone. IETF Consensus is the safest way to ensure that > this happens. > 2) IANA chooses the values (as it typically does), not > cablelabs. (Having cablelabs chose smells a bit like they want the > values early for their implementations and/or specs) Fully agree with the "IETF Consensus" approach. My concern is we should be able to choose a temporary or experimental sub-option code to get implementations going & interoperability testing started. Nothing "cast in stone" and upon IETF review and comments, we will issue Engineering Change Requests to modify our specs as appropriate. What would be your best recommendation so that we can achieve our short-term goals to get implementations going for interop purposes while allowing IETF Consensus? Jean-Francois. CableLabs, PacketCable _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 15 09:55:35 2002 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 JAA01965; Tue, 15 Oct 2002 09:55:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDuov16411; Tue, 15 Oct 2002 09:56:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FDrHv16338 for ; Tue, 15 Oct 2002 09:53:17 -0400 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 JAA01686 for ; Tue, 15 Oct 2002 09:51:03 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g9FDrAj05511; Tue, 15 Oct 2002 08:53:10 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9FDrAS26285; Tue, 15 Oct 2002 08:53:10 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PDB7MV>; Tue, 15 Oct 2002 08:53:10 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Jean-Francois Mule'" , Matt Osman Cc: dhcwg@ietf.org, "'Thomas Narten'" Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-03.txt Date: Tue, 15 Oct 2002 08:53:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27451.F282C6A8" 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_01C27451.F282C6A8 Content-Type: text/plain; charset="iso-8859-1" FYI - Perhaps you want to reserve a few suboption codes for experimental and/or "private" sub-options? This would be similar to how the DHCPv4 option space is assigned (1-127 are for IETF assigned options, 128-254 are for "private" options). - Bernie -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Tuesday, October 15, 2002 9:25 AM To: 'Thomas Narten' Cc: Matt Osman; dhcwg@ietf.org Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-03.txt Paul will reply the comments pertaining to draft-ietf-dhc-packetcable-03. I'm replying on the more general questions Thomas asked on behalf of CableLabs. Thomans Narten wrote: > > IANA is requested to register codes for future CableLabs Client > > Configuration Sub-options with an "Expert Review" > approval policy as > > described in RFC 2434 [2]. Future proposed sub-options will be > > assigned a numeric code chosen by CableLabs, which will be > > documented in the Internet Drafts that describe the > sub-options. The > > code assignment will be reviewed by a designated expert from the > > IETF prior to publication in an RFC. > > 1) I think it should be IETF consensus, not expert review. these > options need to be reviewed by the IETF before they get implemented > and cast in stone. IETF Consensus is the safest way to ensure that > this happens. > 2) IANA chooses the values (as it typically does), not > cablelabs. (Having cablelabs chose smells a bit like they want the > values early for their implementations and/or specs) Fully agree with the "IETF Consensus" approach. My concern is we should be able to choose a temporary or experimental sub-option code to get implementations going & interoperability testing started. Nothing "cast in stone" and upon IETF review and comments, we will issue Engineering Change Requests to modify our specs as appropriate. What would be your best recommendation so that we can achieve our short-term goals to get implementations going for interop purposes while allowing IETF Consensus? Jean-Francois. CableLabs, PacketCable _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C27451.F282C6A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] draft-ietf-dhc-packetcable-03.txt

FYI - Perhaps you want to reserve a few suboption = codes for experimental and/or "private" sub-options? This = would be similar to how the DHCPv4 option space is assigned (1-127 are = for IETF assigned options, 128-254 are for "private" = options).

- Bernie

-----Original Message-----
From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]<= /FONT>
Sent: Tuesday, October 15, 2002 9:25 AM
To: 'Thomas Narten'
Cc: Matt Osman; dhcwg@ietf.org
Subject: RE: [dhcwg] = draft-ietf-dhc-packetcable-03.txt


Paul will reply the comments pertaining to = draft-ietf-dhc-packetcable-03. I'm replying on the more general = questions Thomas asked on behalf of CableLabs.

Thomans Narten wrote:
> >    IANA is requested to = register codes for future CableLabs Client
> >    Configuration = Sub-options with an "Expert Review"
> approval policy as
> >    described in RFC 2434 = [2]. Future proposed sub-options will be
> >    assigned a numeric code = chosen by CableLabs, which will be
> >    documented in the = Internet Drafts that describe the
> sub-options. The
> >    code assignment will be = reviewed by a designated expert from the
> >    IETF prior to = publication in an RFC.
>
> 1) I think it should be IETF consensus, not = expert review. these
>    options need to be reviewed = by the IETF before they get implemented
>    and cast in stone. IETF = Consensus is the safest way to ensure that
>    this happens.
> 2) IANA chooses the values (as it typically = does), not
>    cablelabs. (Having cablelabs = chose smells a bit like they want the
>    values early for their = implementations and/or specs)
Fully agree with the "IETF Consensus" = approach.
My concern is we should be able to choose a = temporary or experimental sub-option code to get implementations going = & interoperability testing started.  Nothing "cast in = stone" and upon IETF review and comments, we will issue = Engineering Change Requests to modify our specs as = appropriate.

What would be your best recommendation so that we can = achieve our short-term goals to get implementations going for interop = purposes while allowing IETF Consensus?

Jean-Francois.
CableLabs, PacketCable
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C27451.F282C6A8-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 16 08:26:41 2002 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 IAA26727; Wed, 16 Oct 2002 08:26:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GCRnv31242; Wed, 16 Oct 2002 08:27:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GBuAv29682 for ; Wed, 16 Oct 2002 07:56:10 -0400 Received: from diabolik.elettra.trieste.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25491 for ; Wed, 16 Oct 2002 07:53:57 -0400 (EDT) Received: from diabolik (mauri@localhost [127.0.0.1]) by diabolik.elettra.trieste.it (8.11.4/8.11.4) with SMTP id g9GBu5w21920 for ; Wed, 16 Oct 2002 13:56:05 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Maurizio Bossi Reply-To: bossi@elettra.trieste.it To: dhcwg@ietf.org Date: Wed, 16 Oct 2002 13:56:04 +0200 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <02101613560400.21860@diabolik> Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [dhcwg] DHCP boot file size 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: , Content-Transfer-Encoding: 8bit Hi, I looking for some information on this option how does it work and how to set this option in the dhcpd.conf file. I found this information: This option specifies the length in 512-octet blocks of the default boot image for the client. The file length is specified as an unsigned 16-bit integer. The code for this option is 13, and its length is 2. Code Len File Size +-----+-----+-----+-----+ | 13 | 2 | l1 | l2 | +-----+-----+-----+-----+ But what does it mean ' File Size' of lenght 16-bit ( 16 bit are 65KB) is very little for a boot-file . What is the default size ? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 16 13:33:37 2002 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 NAA06912; Wed, 16 Oct 2002 13:33:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GHYmv17156; Wed, 16 Oct 2002 13:34:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GHX9v17104 for ; Wed, 16 Oct 2002 13:33:09 -0400 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 NAA06851 for ; Wed, 16 Oct 2002 13:30:54 -0400 (EDT) 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 g9GHX4j15753; Wed, 16 Oct 2002 12:33:04 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9GHX4Y18512; Wed, 16 Oct 2002 12:33:04 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PAY68A>; Wed, 16 Oct 2002 12:33:04 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'bossi@elettra.trieste.it'" , dhcwg@ietf.org Subject: RE: [dhcwg] DHCP boot file size option Date: Wed, 16 Oct 2002 12:33:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2753A.13E30716" 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_01C2753A.13E30716 Content-Type: text/plain; charset="iso-8859-1" >specifies the length in 512-octet blocks This means a file size of 1 means 512 bytes ... 65535 means 65535*512 bytes (33MB). Not sure what you mean by "what is the default size". This is an informational item to the client and if not specified, the client would have no knowledge of the size. I'm not sure what the original motivation for this option was, but perhaps it tells the client how much memory it needs to have in order to receive this file. - Bernie -----Original Message----- From: Maurizio Bossi [mailto:mauri@diabolik.elettra.trieste.it] Sent: Wednesday, October 16, 2002 7:56 AM To: dhcwg@ietf.org Subject: [dhcwg] DHCP boot file size option Hi, I looking for some information on this option how does it work and how to set this option in the dhcpd.conf file. I found this information: This option specifies the length in 512-octet blocks of the default boot image for the client. The file length is specified as an unsigned 16-bit integer. The code for this option is 13, and its length is 2. Code Len File Size +-----+-----+-----+-----+ | 13 | 2 | l1 | l2 | +-----+-----+-----+-----+ But what does it mean ' File Size' of lenght 16-bit ( 16 bit are 65KB) is very little for a boot-file . What is the default size ? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2753A.13E30716 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCP boot file size option

>specifies the length in 512-octet blocks

This means a file size of 1 means 512 bytes ... 65535 = means 65535*512 bytes (33MB).

Not sure what you mean by "what is the default = size". This is an informational item to the client and if not = specified, the client would have no knowledge of the size. I'm not sure = what the original motivation for this option was, but perhaps it tells = the client how much memory it needs to have in order to receive this = file.

- Bernie

-----Original Message-----
From: Maurizio Bossi [mailto:mauri@diabolik.= elettra.trieste.it]
Sent: Wednesday, October 16, 2002 7:56 AM
To: dhcwg@ietf.org
Subject: [dhcwg] DHCP boot file size option


Hi,
I looking for some information on this option how = does it work and how to set
this option in the dhcpd.conf file.
I found this information:

   This option specifies the length in = 512-octet blocks of the default
   boot image for the client.  The = file length is specified as an
   unsigned 16-bit integer.

   The code for this option is 13, and its = length is 2.

    Code   Len   = File Size
   +-----+-----+-----+-----+
   |  13 |  2  |  l1 = |  l2 |
   +-----+-----+-----+-----+

But what does it mean ' File Size'  of lenght = 16-bit ( 16 bit are 65KB) is
very little for a boot-file . What is the default = size ?

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

------_=_NextPart_001_01C2753A.13E30716-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 16 14:16:02 2002 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 OAA08045; Wed, 16 Oct 2002 14:16:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GIHFv20332; Wed, 16 Oct 2002 14:17:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GIGtv20315 for ; Wed, 16 Oct 2002 14:16:55 -0400 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 OAA08030 for ; Wed, 16 Oct 2002 14:14:39 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g9GIGM220516; Wed, 16 Oct 2002 13:16:22 -0500 (CDT) Received: from nominum.com (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g9GIH7Y6006893; Wed, 16 Oct 2002 13:17:07 -0500 (CDT) Date: Wed, 16 Oct 2002 13:17:07 -0500 Subject: Re: [dhcwg] DHCP boot file size option Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: dhcwg@ietf.org To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: Message-Id: <7A98DF94-E133-11D6-809A-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 > Not sure what you mean by "what is the default size". This is an > informational item to the client and if not specified, the client > would have no knowledge of the size. I'm not sure what the original > motivation for this option was, but perhaps it tells the client how > much memory it needs to have in order to receive this file. It would certainly help with a boot status progress bar... :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 16 15:29:07 2002 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 PAA10108; Wed, 16 Oct 2002 15:29:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GJUFv24617; Wed, 16 Oct 2002 15:30:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GJS9v24425 for ; Wed, 16 Oct 2002 15:28:09 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09979 for ; Wed, 16 Oct 2002 15:25:51 -0400 (EDT) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-253.cisco.com [161.44.149.253]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA00628; Wed, 16 Oct 2002 15:27:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20021016112408.02a0a348@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Oct 2002 15:26:10 -0400 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt Cc: dhcwg@ietf.org In-Reply-To: <200210111700.g9BH0dH08214@rotala.raleigh.ibm.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: , Hello Thomas, Please find responses inline...formed from several conversations with various PacketCable participants. I'll try to have a new draft ready for next week. We'd greatly appreciate your effort to keep this moving along swiftly. Cheers, At 01:00 PM 10/11/2002 -0400, Thomas Narten wrote: >Background: there was a quite a lot of private discussion/conference >calls a month or two ago on this document, followed by a revised >document. Here is my review of the current document. > >Thomas > > > 8.1. TSP's DHCP Server Address Sub-Options > >Seems to me that this options does (however subtly) modify DHC client >behavior. My understanding is that CCC option 1/2, which >lists a primary/backup DHC server are sent to the CM, which then >communicates those two addresses to the MTA (a separate entity). The >MTA then invokes DHC on its own, but is only allowed to talk to the >servers whos addresses it received from the CM. In normal DHC, the >client isn't restricted in anyway in what servers it communicates >with. Thus, I would argue that CCC options 1/2 do modify the DHC >protocol, albeit subtly and perhaps not signficantly. I am not >particularly comfortable with this, but would like to hear more from >the WG on this point. (Also, is my understanding here correct?) RFC 2131 Section 4.4.1 "The time over which the client collects messages and the mechanism used to select one DHCPOFFER are implementation dependent". PacketCable does not feel CCC.1/.2 in any way modifies the RFC. > > Due to specific needs of the MTA configuration process (described in > > [5]), a new CableLabs Client Configuration (CCC) option is needed for > > the DHCP protocol. Both CM and MTA DHCP clients will request this > > option. When requested, both the CM and TSP DHCP servers will > > populate this option into DHCP responses. > > >Doesn't the client also provide this option and fill in some info? >better to say this above (one or two sentences here would suffice). Or >maybe just merge Section 9 text into the text here. No, an MTA DHCP client never populates CCC option content into its any if its requests. The PacketCable MTA provisioning specification (section 7) contains detailed descriptions of when the CCC option is/is not populated into DHCP messaging. PacketCable's intent is to specify option syntax in the draft/RFC, while referring to the PacketCable MTA prov specification for usage details. Otherwise, we're going to end up pulling large pieces of the PacketCable provisioning spec into this draft...lots of duplication between the documents (which I thought we agreed was undesirable). That said, I can add a sentence or two stating that the client never populates CCC option content into DHCP request messages. >Should this document add a normative references to >draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so >referencing it shouldn't be a problem)? Seems like that would make >sense. As stated in the IETF draft writer's guidelines and the beginning of the our draft..."It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress". I took this to mean referencing non RFC docs is prohibited. Attempting to maximize the speed at which this draft might progress through the IETF process, I tried to adhere as faithfully as possible to those guidelines...PacketCable did not consider ANY drafts for reference within this draft. If you feel inclusion of this draft is a hard requirement, PacketCable will have to open this issue with the manufacturers...further delaying the progress of this draft (not good for us). I'm also going to need an RFC # for the ref ? > > - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035 > > [7] section 3.1. Note that a terminating 0 is required. > >is compression allowed? (probably not useful -- then say so.) Agreed. PacketCable will state compression "is/is not" allowed in the draft (following discussion with the MTA manufacturers). >For CCC option 3, does IANA need to maintain a registry for other >"types"? An IANA considerations would seem to be needed. It could say: > - allocation of future types requires IETF Consensus (or whatever) > - there will be no additional values, IANA does not need to maintain > a registry > - something else? Agreed. No additional values are planned. PacketCable will state "IANA does not need to maintain a registry". >The CCC options for configuring Kerberos parameters seems odd to me >(what kerberos document talks about the need for tuning these >parameters?). The IESG may want this reviewed by someone with kerberos >clue. (I'm just saying this so that there are no surprises should this >issue come up later.) This is a specific need of a PacketCable MTA. It does not present any issues with the Kerberos RFCs. The CCC option is, by definition, Cablelabs specific, so PacketCable does not see this causing any issues with non Cablelabs devices. >Also, the kerberos REALM name option seems like one that could easily >be more general (i.e, not cablelabs specific). But probably too late >for this. Also: Agreed, too late. PacketCable simply can not absorb the delay that would result if we split the realm name sub-option out into a distinct DHCP option draft. >"Douglas E. Engert" writes: > > > You should also look at: > > " Distributing Kerberos KDC and Realm Information with DNS" > > http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-03.txt > > > Which describes how to find a KDC using DNS. I should point out that > > W2K, MIT and I think Hiemdal all have this implemented. > >I assume that cablelabs is familiar with this but still wants to go >the DHC route? 1. Agreed, we prefer to stick to the DHCP route. 2. PacketCable does not see where this draft applies. This draft appears to describe how one uses DNS to turn a realm name into a KDC address. CCC.6 describes how the realm name initially arrives at the MTA . 3. Again, this would be citing a draft (which I understood to be not acceptable) > > Cablelabs client devices issue DHCP requests that include DHCP > > options 55 and 60. Option 55 will request the CCC option from the > >nit: would be good include neumonic names (e.g., ORO and class ID) >here rather than just using the option number rather than assuming >everyone knows the option meaning Agreed. I'll spell out the names. > > IANA is requested to register codes for future CableLabs Client > > Configuration Sub-options with an "Expert Review" approval policy as > > described in RFC 2434 [2]. Future proposed sub-options will be > > assigned a numeric code chosen by CableLabs, which will be > > documented in the Internet Drafts that describe the sub-options. The > > code assignment will be reviewed by a designated expert from the > > IETF prior to publication in an RFC. > >1) I think it should be IETF consensus, not expert review. these > options need to be reviewed by the IETF before they get implemented > and cast in stone. IETF Consensus is the safest way to ensure that > this happens. > >2) IANA chooses the values (as it typically does), not > cablelabs. (Having cablelabs chose smells a bit like they want the > values early for their implementations and/or specs) I'll defer comment on this issue to the Cablelabs folks. > > 13. Security Considerations > > > > This draft relies on the DHCP protocol [4] for authentication and > > security, i.e. it does not provide in excess of what DHCP is (or will > > be) providing. It does not expose any security threats beyond what is > > currently exposed by other DHCP options. > >The security considerations section is inadequate. It should say >something about the options themselves and what the security >implications are should the options be spoofed, etc. That is, what are >the security issues related to the specific options discussed in the >document? Is it required that some sort of DHC authentication be used >in order to prevent vulnerabilities (say) to the configuration of the >kerberos stuff? > >Note on the kerberos options, the following comment was made >(privately): > >Jonathan Trostle writes: > > > Section 13 (Security Considerations) indicates they are relying on > > the DHCP protocol for authentication and security (should be more > > precise about what security services). > > > If the new option data is manipulated, various DoS attacks are possible. > > One option, Kerberos realm name, is potentially more serious. By modifying > > the realm, the attacker can change the user's TSP (if I recall correctly, > > packetcable uses pkinit where the client authenticates the KDC by the > > KDC's realm name in the KDC's certificate). Therefore, a malicious TSP > > can act as a TSP for any user and then have access to the user's VoIP > > and multimedia data. So it would be a good thing if the Kerberos realm > > name is protected from modification in the DHCP protocol. Alternatively, > > changing the realm name could be a means by which one TSP steals customers > > from another TSP without the customer's permission. > >then later, > >Jonathan Trostle writes: > > > Tom, > > > Yes, there should be some extra wording in the security considerations at > > least. I recall an argument that layer 2 encryption protects the link > > between the modem and the head end, and the DCHP server may be at the head > > end. But there should definitely be some words indicating that there is > > protection for the DHCP messages at some layer. If this draft is used in > > some other scenario (or even in the packetcable scenario possibly) then > there > > is the potential for security vulnerabilities. > > > Jonathan Agree that the security section could use some beefing up. >Finally, references should be split into normative/non-normative >sections. nit: I have a single reference section primarily because I followed the example of many other drafts/RFCs...assuming this would be adequate. I'll split it. >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 16 17:53:26 2002 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 RAA13251; Wed, 16 Oct 2002 17:53:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GLsWv32650; Wed, 16 Oct 2002 17:54:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GLrxv32616 for ; Wed, 16 Oct 2002 17:53:59 -0400 Received: from hoth.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13218; Wed, 16 Oct 2002 17:51:39 -0400 (EDT) From: pall.ramanathan@arrisi.com Received: from mars.ARRISI.COM ([10.0.248.10]) by hoth.arrisi.com (Lotus Domino Release 5.0.10) with ESMTP id 2002101617534600:696 ; Wed, 16 Oct 2002 17:53:46 -0400 To: Paul Duffy Cc: dhcwg@ietf.org, dhcwg-admin@ietf.org, Thomas Narten Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Wed, 16 Oct 2002 17:53:46 -0400 X-MIMETrack: Serialize by Router on Mars/Arris(Release 5.0.11 |July 24, 2002) at 10/16/2002 05:53:45 PM, Serialize complete at 10/16/2002 05:53:45 PM, Itemize by SMTP Server on Hoth/Antec(Release 5.0.10 |March 22, 2002) at 10/16/2002 05:53:46 PM, Serialize by Router on Hoth/Antec(Release 5.0.10 |March 22, 2002) at 10/16/2002 05:53:52 PM, Serialize complete at 10/16/2002 05:53:52 PM Content-Type: multipart/alternative; boundary="=_alternative 007823C985256C54_=" 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 multipart message in MIME format. --=_alternative 007823C985256C54_= Content-Type: text/plain; charset="us-ascii" My understanding per RFC 2131 was that when client receives offers from multiple offers for DHCP Broadcast, the client can select a DHCP and send a unicast request to the DHCP the client selects. Couldn't the MTA do a unicast message to the TSP's DHCP server using the DHCP address the MTA receives from the cable modem. I tend to think that this will eliminate tearing up the DHCP protocol for PacketCable MTA. I would think, this would be easy for vendore to implement also since it is within RFC 2131. Am I missing somethings here. My opinions are mys own and has nothing to do with my employer. Pall Ramanathan Paul Duffy Sent by: dhcwg-admin@ietf.org 10/16/2002 03:26 PM To: Thomas Narten cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt Hello Thomas, Please find responses inline...formed from several conversations with various PacketCable participants. I'll try to have a new draft ready for next week. We'd greatly appreciate your effort to keep this moving along swiftly. Cheers, At 01:00 PM 10/11/2002 -0400, Thomas Narten wrote: >Background: there was a quite a lot of private discussion/conference >calls a month or two ago on this document, followed by a revised >document. Here is my review of the current document. > >Thomas > > > 8.1. TSP's DHCP Server Address Sub-Options > >Seems to me that this options does (however subtly) modify DHC client >behavior. My understanding is that CCC option 1/2, which >lists a primary/backup DHC server are sent to the CM, which then >communicates those two addresses to the MTA (a separate entity). The >MTA then invokes DHC on its own, but is only allowed to talk to the >servers whos addresses it received from the CM. In normal DHC, the >client isn't restricted in anyway in what servers it communicates >with. Thus, I would argue that CCC options 1/2 do modify the DHC >protocol, albeit subtly and perhaps not signficantly. I am not >particularly comfortable with this, but would like to hear more from >the WG on this point. (Also, is my understanding here correct?) RFC 2131 Section 4.4.1 "The time over which the client collects messages and the mechanism used to select one DHCPOFFER are implementation dependent". PacketCable does not feel CCC.1/.2 in any way modifies the RFC. > > Due to specific needs of the MTA configuration process (described in > > [5]), a new CableLabs Client Configuration (CCC) option is needed for > > the DHCP protocol. Both CM and MTA DHCP clients will request this > > option. When requested, both the CM and TSP DHCP servers will > > populate this option into DHCP responses. > > >Doesn't the client also provide this option and fill in some info? >better to say this above (one or two sentences here would suffice). Or >maybe just merge Section 9 text into the text here. No, an MTA DHCP client never populates CCC option content into its any if its requests. The PacketCable MTA provisioning specification (section 7) contains detailed descriptions of when the CCC option is/is not populated into DHCP messaging. PacketCable's intent is to specify option syntax in the draft/RFC, while referring to the PacketCable MTA prov specification for usage details. Otherwise, we're going to end up pulling large pieces of the PacketCable provisioning spec into this draft...lots of duplication between the documents (which I thought we agreed was undesirable). That said, I can add a sentence or two stating that the client never populates CCC option content into DHCP request messages. >Should this document add a normative references to >draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so >referencing it shouldn't be a problem)? Seems like that would make >sense. As stated in the IETF draft writer's guidelines and the beginning of the our draft..."It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress". I took this to mean referencing non RFC docs is prohibited. Attempting to maximize the speed at which this draft might progress through the IETF process, I tried to adhere as faithfully as possible to those guidelines...PacketCable did not consider ANY drafts for reference within this draft. If you feel inclusion of this draft is a hard requirement, PacketCable will have to open this issue with the manufacturers...further delaying the progress of this draft (not good for us). I'm also going to need an RFC # for the ref ? > > - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035 > > [7] section 3.1. Note that a terminating 0 is required. > >is compression allowed? (probably not useful -- then say so.) Agreed. PacketCable will state compression "is/is not" allowed in the draft (following discussion with the MTA manufacturers). >For CCC option 3, does IANA need to maintain a registry for other >"types"? An IANA considerations would seem to be needed. It could say: > - allocation of future types requires IETF Consensus (or whatever) > - there will be no additional values, IANA does not need to maintain > a registry > - something else? Agreed. No additional values are planned. PacketCable will state "IANA does not need to maintain a registry". >The CCC options for configuring Kerberos parameters seems odd to me >(what kerberos document talks about the need for tuning these >parameters?). The IESG may want this reviewed by someone with kerberos >clue. (I'm just saying this so that there are no surprises should this >issue come up later.) This is a specific need of a PacketCable MTA. It does not present any issues with the Kerberos RFCs. The CCC option is, by definition, Cablelabs specific, so PacketCable does not see this causing any issues with non Cablelabs devices. >Also, the kerberos REALM name option seems like one that could easily >be more general (i.e, not cablelabs specific). But probably too late >for this. Also: Agreed, too late. PacketCable simply can not absorb the delay that would result if we split the realm name sub-option out into a distinct DHCP option draft. >"Douglas E. Engert" writes: > > > You should also look at: > > " Distributing Kerberos KDC and Realm Information with DNS" > > http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-03.txt > > > Which describes how to find a KDC using DNS. I should point out that > > W2K, MIT and I think Hiemdal all have this implemented. > >I assume that cablelabs is familiar with this but still wants to go >the DHC route? 1. Agreed, we prefer to stick to the DHCP route. 2. PacketCable does not see where this draft applies. This draft appears to describe how one uses DNS to turn a realm name into a KDC address. CCC.6 describes how the realm name initially arrives at the MTA . 3. Again, this would be citing a draft (which I understood to be not acceptable) > > Cablelabs client devices issue DHCP requests that include DHCP > > options 55 and 60. Option 55 will request the CCC option from the > >nit: would be good include neumonic names (e.g., ORO and class ID) >here rather than just using the option number rather than assuming >everyone knows the option meaning Agreed. I'll spell out the names. > > IANA is requested to register codes for future CableLabs Client > > Configuration Sub-options with an "Expert Review" approval policy as > > described in RFC 2434 [2]. Future proposed sub-options will be > > assigned a numeric code chosen by CableLabs, which will be > > documented in the Internet Drafts that describe the sub-options. The > > code assignment will be reviewed by a designated expert from the > > IETF prior to publication in an RFC. > >1) I think it should be IETF consensus, not expert review. these > options need to be reviewed by the IETF before they get implemented > and cast in stone. IETF Consensus is the safest way to ensure that > this happens. > >2) IANA chooses the values (as it typically does), not > cablelabs. (Having cablelabs chose smells a bit like they want the > values early for their implementations and/or specs) I'll defer comment on this issue to the Cablelabs folks. > > 13. Security Considerations > > > > This draft relies on the DHCP protocol [4] for authentication and > > security, i.e. it does not provide in excess of what DHCP is (or will > > be) providing. It does not expose any security threats beyond what is > > currently exposed by other DHCP options. > >The security considerations section is inadequate. It should say >something about the options themselves and what the security >implications are should the options be spoofed, etc. That is, what are >the security issues related to the specific options discussed in the >document? Is it required that some sort of DHC authentication be used >in order to prevent vulnerabilities (say) to the configuration of the >kerberos stuff? > >Note on the kerberos options, the following comment was made >(privately): > >Jonathan Trostle writes: > > > Section 13 (Security Considerations) indicates they are relying on > > the DHCP protocol for authentication and security (should be more > > precise about what security services). > > > If the new option data is manipulated, various DoS attacks are possible. > > One option, Kerberos realm name, is potentially more serious. By modifying > > the realm, the attacker can change the user's TSP (if I recall correctly, > > packetcable uses pkinit where the client authenticates the KDC by the > > KDC's realm name in the KDC's certificate). Therefore, a malicious TSP > > can act as a TSP for any user and then have access to the user's VoIP > > and multimedia data. So it would be a good thing if the Kerberos realm > > name is protected from modification in the DHCP protocol. Alternatively, > > changing the realm name could be a means by which one TSP steals customers > > from another TSP without the customer's permission. > >then later, > >Jonathan Trostle writes: > > > Tom, > > > Yes, there should be some extra wording in the security considerations at > > least. I recall an argument that layer 2 encryption protects the link > > between the modem and the head end, and the DCHP server may be at the head > > end. But there should definitely be some words indicating that there is > > protection for the DHCP messages at some layer. If this draft is used in > > some other scenario (or even in the packetcable scenario possibly) then > there > > is the potential for security vulnerabilities. > > > Jonathan Agree that the security section could use some beefing up. >Finally, references should be split into normative/non-normative >sections. nit: I have a single reference section primarily because I followed the example of many other drafts/RFCs...assuming this would be adequate. I'll split it. >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --=_alternative 007823C985256C54_= Content-Type: text/html; charset="us-ascii"
My understanding per RFC 2131 was that when client receives offers from multiple offers for DHCP Broadcast, the client can select a DHCP and send a unicast request to the DHCP the client selects. Couldn't the MTA do a unicast message to the TSP's DHCP server using the DHCP address the MTA receives from the cable modem. I tend to think that this will eliminate tearing up the DHCP protocol for PacketCable MTA. I would think, this would be easy for vendore to implement also since it is within RFC 2131. Am I missing somethings here.

My opinions are mys own and has nothing to do with my employer.


Pall Ramanathan


Paul Duffy <paduffy@cisco.com>
Sent by: dhcwg-admin@ietf.org

10/16/2002 03:26 PM

       
        To:        Thomas Narten <narten@us.ibm.com>
        cc:        dhcwg@ietf.org
        Subject:        Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt



Hello Thomas,

Please find responses inline...formed from several conversations with
various PacketCable participants.

I'll try to have a new draft ready for next week.  We'd greatly appreciate
your effort to keep this moving along swiftly.

Cheers,

At 01:00 PM 10/11/2002 -0400, Thomas Narten wrote:
>Background: there was a quite a lot of private discussion/conference
>calls a month or two ago on this document, followed by a revised
>document. Here is my review of the current document.
>
>Thomas
>
> >   8.1. TSP's DHCP Server Address Sub-Options
>
>Seems to me that this options does (however subtly) modify DHC client
>behavior. My understanding is that CCC option 1/2, which
>lists a primary/backup DHC server are sent to the CM, which then
>communicates those two addresses to the MTA (a separate entity). The
>MTA then invokes DHC on its own, but is only allowed to talk to the
>servers whos addresses it received from the CM. In normal DHC, the
>client isn't restricted in anyway in what servers it communicates
>with. Thus, I would argue that CCC options 1/2 do modify the DHC
>protocol, albeit subtly and perhaps not signficantly. I am not
>particularly comfortable with this, but would like to hear more from
>the WG on this point. (Also, is my understanding here correct?)

RFC 2131 Section 4.4.1 "The time over which the client collects messages
and the mechanism used to select one DHCPOFFER are implementation
dependent".   PacketCable does not feel CCC.1/.2 in any way modifies the RFC.

> >    Due to specific needs of the MTA configuration process (described in
> >    [5]), a new CableLabs Client Configuration (CCC) option is needed for
> >    the DHCP protocol.  Both CM and MTA DHCP clients will request this
> >    option.  When requested, both the CM and TSP DHCP servers will
> >    populate this option into DHCP responses.
>
>
>Doesn't the client also provide this option and fill in some info?
>better to say this above (one or two sentences here would suffice). Or
>maybe just merge Section 9 text into the text here.

No, an MTA DHCP client never populates CCC option content into its any if
its requests.  The PacketCable MTA provisioning  specification (section 7)
contains detailed descriptions of when the CCC option is/is not populated
into DHCP messaging.

PacketCable's intent is to specify option syntax in the draft/RFC, while
referring to the PacketCable MTA prov specification for usage
details.  Otherwise, we're going to end up pulling large pieces of the
PacketCable provisioning spec into this draft...lots of duplication between
the documents (which I thought we agreed was undesirable).

That said, I can add a sentence or two stating that the client never
populates CCC option content into DHCP request messages.

>Should this document add a normative references to
>draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so
>referencing it shouldn't be a problem)? Seems like that would make
>sense.

As stated in the IETF draft writer's guidelines and the beginning of the
our draft..."It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as work in progress".  I took this to
mean referencing non RFC docs is prohibited.  Attempting to maximize the
speed at which this draft might progress through the IETF process, I tried
to adhere as faithfully as possible to those guidelines...PacketCable did
not consider ANY drafts for reference within this draft.

If you feel inclusion of this draft is a hard requirement, PacketCable will
have to open this issue with the manufacturers...further delaying the
progress of this draft (not good for us).  I'm also going to need an RFC #
for the ref ?

> >    - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035
> >      [7] section 3.1. Note that a terminating 0 is required.
>
>is compression allowed? (probably not useful -- then say so.)

Agreed. PacketCable will state compression "is/is not" allowed in the draft
(following discussion with the MTA manufacturers).

>For CCC option 3, does IANA need to maintain a registry for other
>"types"? An IANA considerations would seem to be  needed. It could say:
>  - allocation of future types requires IETF Consensus (or whatever)
>  - there will be no additional values, IANA does not need to maintain
>    a registry
>  - something else?

Agreed. No additional values are planned. PacketCable will state "IANA does
not need to maintain a registry".

>The CCC options for configuring Kerberos parameters seems odd to me
>(what kerberos document talks about the need for tuning these
>parameters?). The IESG may want this reviewed by someone with kerberos
>clue. (I'm just saying this so that there are no surprises should this
>issue come up later.)

This is a specific need of a PacketCable MTA.  It does not present any
issues with the Kerberos RFCs.  The CCC option is, by definition, Cablelabs
specific, so PacketCable does not see this causing any issues with non
Cablelabs devices.

>Also, the kerberos REALM name option seems like one that could easily
>be more general (i.e, not cablelabs specific). But probably too late
>for this. Also:

Agreed, too late.  PacketCable simply can not absorb the delay that would
result if we split the realm name sub-option out into a distinct DHCP
option draft.

>"Douglas E. Engert" <deengert@anl.gov> writes:
>
> > You should also look at:
> > " Distributing Kerberos KDC and Realm Information with DNS"
> > http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-03.txt
>
> > Which describes how to find a KDC using DNS. I should point out that
> > W2K, MIT and I think Hiemdal all have this implemented.
>
>I assume that cablelabs is familiar with this but still wants to go
>the DHC route?

1. Agreed, we prefer to stick to the DHCP route.
2. PacketCable does not see where this draft applies.  This draft appears
to describe how one uses DNS to turn a realm name into a KDC
address.  CCC.6 describes how the realm name initially arrives at the MTA .
3. Again, this would be citing a draft (which I understood to be not
acceptable)

> >    Cablelabs client devices issue DHCP requests that include DHCP
> >    options 55 and 60.  Option 55 will request the CCC option from the
>
>nit: would be good include neumonic names (e.g., ORO and class ID)
>here rather than just using the option number rather than assuming
>everyone knows the option meaning

Agreed.  I'll spell out the names.

> >    IANA is requested to register codes for future CableLabs Client
> >    Configuration Sub-options with an "Expert Review" approval policy as
> >    described in RFC 2434 [2]. Future proposed sub-options will be
> >    assigned a numeric code chosen by CableLabs, which will be
> >    documented in the Internet Drafts that describe the sub-options. The
> >    code assignment will be reviewed by a designated expert from the
> >    IETF prior to publication in an RFC.
>
>1) I think it should be IETF consensus, not expert review. these
>    options need to be reviewed by the IETF before they get implemented
>    and cast in stone. IETF Consensus is the safest way to ensure that
>    this happens.
>
>2) IANA chooses the values (as it typically does), not
>    cablelabs. (Having cablelabs chose smells a bit like they want the
>    values early for their implementations and/or specs)

I'll defer comment on this issue to the Cablelabs folks.

> >    13.  Security Considerations
> >
> >    This draft relies on the DHCP protocol [4] for authentication and
> >    security, i.e. it does not provide in excess of what DHCP is (or will
> >    be) providing. It does not expose any security threats beyond what is
> >    currently exposed by other DHCP options.
>
>The security considerations section is inadequate. It should say
>something about the options themselves and what the security
>implications are should the options be spoofed, etc. That is, what are
>the security issues related to the specific options discussed in the
>document? Is it required that some sort of DHC authentication be used
>in order to prevent vulnerabilities (say) to the configuration of the
>kerberos stuff?
>
>Note on the kerberos options, the following comment was made
>(privately):
>
>Jonathan Trostle <jtrostle@world.std.com> writes:
>
> > Section 13 (Security Considerations) indicates they are relying on
> > the DHCP protocol for authentication and security (should be more
> > precise about what security services).
>
> > If the new option data is manipulated, various DoS attacks are possible.
> > One option, Kerberos realm name, is potentially more serious. By modifying
> > the realm, the attacker can change the user's TSP (if I recall correctly,
> > packetcable uses pkinit where the client authenticates the KDC by the
> > KDC's realm name in the KDC's certificate). Therefore, a malicious TSP
> > can act as a TSP for any user and then have access to the user's VoIP
> > and multimedia data. So it would be a good thing if the Kerberos realm
> > name is protected from modification in the DHCP protocol. Alternatively,
> > changing the realm name could be a means by which one TSP steals customers
> > from another TSP without the customer's permission.
>
>then later,
>
>Jonathan Trostle <jtrostle@world.std.com> writes:
>
> > Tom,
>
> > Yes, there should be some extra wording in the security considerations at
> > least. I recall an argument that layer 2 encryption protects the link
> > between the modem and the head end, and the DCHP server may be at the head
> > end. But there should definitely be some words indicating that there is
> > protection for the DHCP messages at some layer. If this draft is used in
> > some other scenario (or even in the packetcable scenario possibly) then
> there
> > is the potential for security vulnerabilities.
>
> > Jonathan

Agree that the security section could use some beefing up.

>Finally, references should be split into normative/non-normative
>sections.

nit: I have a single reference section primarily because I followed the
example of many other drafts/RFCs...assuming this would be adequate.

I'll split it.

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

--

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com


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

--=_alternative 007823C985256C54_=-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 16 18:02:44 2002 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 SAA13412; Wed, 16 Oct 2002 18:02:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GM44v00472; Wed, 16 Oct 2002 18:04:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GM3fv00453 for ; Wed, 16 Oct 2002 18:03:41 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13377; Wed, 16 Oct 2002 18:01:20 -0400 (EDT) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-253.cisco.com [161.44.149.253]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA13572; Wed, 16 Oct 2002 18:03:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20021016175924.02926070@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Oct 2002 18:03:27 -0400 To: pall.ramanathan@arrisi.com From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt Cc: dhcwg@ietf.org, dhcwg-admin@ietf.org, Thomas Narten In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_21113569==_.ALT" 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: , --=====================_21113569==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:53 PM 10/16/2002 -0400, pall.ramanathan@arrisi.com wrote: >My understanding per RFC 2131 was that when client receives offers from >multiple offers for DHCP Broadcast, the client can select a DHCP and send >a unicast request to the DHCP the client selects. Couldn't the MTA do a >unicast message to the TSP's DHCP server using the DHCP address the MTA >receives from the cable modem. I tend to think that this will eliminate >tearing up the DHCP protocol for PacketCable MTA. Pall, I am not understanding how a PacketCable MTA is "tearing up" the DHCP protocol. Please elaborate... >I would think, this would be easy for vendore to implement also since it >is within RFC 2131. Am I missing somethings here. > >My opinions are mys own and has nothing to do with my employer. > > >Pall Ramanathan > > > > > > >Paul Duffy >Sent by: dhcwg-admin@ietf.org > >10/16/2002 03:26 PM > > To: Thomas Narten > cc: dhcwg@ietf.org > Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt > > >Hello Thomas, > >Please find responses inline...formed from several conversations with >various PacketCable participants. > >I'll try to have a new draft ready for next week. We'd greatly appreciate >your effort to keep this moving along swiftly. > >Cheers, > >At 01:00 PM 10/11/2002 -0400, Thomas Narten wrote: > >Background: there was a quite a lot of private discussion/conference > >calls a month or two ago on this document, followed by a revised > >document. Here is my review of the current document. > > > >Thomas > > > > > 8.1. TSP's DHCP Server Address Sub-Options > > > >Seems to me that this options does (however subtly) modify DHC client > >behavior. My understanding is that CCC option 1/2, which > >lists a primary/backup DHC server are sent to the CM, which then > >communicates those two addresses to the MTA (a separate entity). The > >MTA then invokes DHC on its own, but is only allowed to talk to the > >servers whos addresses it received from the CM. In normal DHC, the > >client isn't restricted in anyway in what servers it communicates > >with. Thus, I would argue that CCC options 1/2 do modify the DHC > >protocol, albeit subtly and perhaps not signficantly. I am not > >particularly comfortable with this, but would like to hear more from > >the WG on this point. (Also, is my understanding here correct?) > >RFC 2131 Section 4.4.1 "The time over which the client collects messages >and the mechanism used to select one DHCPOFFER are implementation >dependent". PacketCable does not feel CCC.1/.2 in any way modifies the RFC. > > > > Due to specific needs of the MTA configuration process (described in > > > [5]), a new CableLabs Client Configuration (CCC) option is needed for > > > the DHCP protocol. Both CM and MTA DHCP clients will request this > > > option. When requested, both the CM and TSP DHCP servers will > > > populate this option into DHCP responses. > > > > > >Doesn't the client also provide this option and fill in some info? > >better to say this above (one or two sentences here would suffice). Or > >maybe just merge Section 9 text into the text here. > >No, an MTA DHCP client never populates CCC option content into its any if >its requests. The PacketCable MTA provisioning specification (section 7) >contains detailed descriptions of when the CCC option is/is not populated >into DHCP messaging. > >PacketCable's intent is to specify option syntax in the draft/RFC, while >referring to the PacketCable MTA prov specification for usage >details. Otherwise, we're going to end up pulling large pieces of the >PacketCable provisioning spec into this draft...lots of duplication between >the documents (which I thought we agreed was undesirable). > >That said, I can add a sentence or two stating that the client never >populates CCC option content into DHCP request messages. > > >Should this document add a normative references to > >draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so > >referencing it shouldn't be a problem)? Seems like that would make > >sense. > >As stated in the IETF draft writer's guidelines and the beginning of the >our draft..."It is inappropriate to use Internet-Drafts as reference >material or to cite them other than as work in progress". I took this to >mean referencing non RFC docs is prohibited. Attempting to maximize the >speed at which this draft might progress through the IETF process, I tried >to adhere as faithfully as possible to those guidelines...PacketCable did >not consider ANY drafts for reference within this draft. > >If you feel inclusion of this draft is a hard requirement, PacketCable will >have to open this issue with the manufacturers...further delaying the >progress of this draft (not good for us). I'm also going to need an RFC # >for the ref ? > > > > - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035 > > > [7] section 3.1. Note that a terminating 0 is required. > > > >is compression allowed? (probably not useful -- then say so.) > >Agreed. PacketCable will state compression "is/is not" allowed in the draft >(following discussion with the MTA manufacturers). > > >For CCC option 3, does IANA need to maintain a registry for other > >"types"? An IANA considerations would seem to be needed. It could say: > > - allocation of future types requires IETF Consensus (or whatever) > > - there will be no additional values, IANA does not need to maintain > > a registry > > - something else? > >Agreed. No additional values are planned. PacketCable will state "IANA does >not need to maintain a registry". > > >The CCC options for configuring Kerberos parameters seems odd to me > >(what kerberos document talks about the need for tuning these > >parameters?). The IESG may want this reviewed by someone with kerberos > >clue. (I'm just saying this so that there are no surprises should this > >issue come up later.) > >This is a specific need of a PacketCable MTA. It does not present any >issues with the Kerberos RFCs. The CCC option is, by definition, Cablelabs >specific, so PacketCable does not see this causing any issues with non >Cablelabs devices. > > >Also, the kerberos REALM name option seems like one that could easily > >be more general (i.e, not cablelabs specific). But probably too late > >for this. Also: > >Agreed, too late. PacketCable simply can not absorb the delay that would >result if we split the realm name sub-option out into a distinct DHCP >option draft. > > >"Douglas E. Engert" writes: > > > > > You should also look at: > > > " Distributing Kerberos KDC and Realm Information with DNS" > > > > http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-03.txt > > > > > Which describes how to find a KDC using DNS. I should point out that > > > W2K, MIT and I think Hiemdal all have this implemented. > > > >I assume that cablelabs is familiar with this but still wants to go > >the DHC route? > >1. Agreed, we prefer to stick to the DHCP route. >2. PacketCable does not see where this draft applies. This draft appears >to describe how one uses DNS to turn a realm name into a KDC >address. CCC.6 describes how the realm name initially arrives at the MTA . >3. Again, this would be citing a draft (which I understood to be not >acceptable) > > > > Cablelabs client devices issue DHCP requests that include DHCP > > > options 55 and 60. Option 55 will request the CCC option from the > > > >nit: would be good include neumonic names (e.g., ORO and class ID) > >here rather than just using the option number rather than assuming > >everyone knows the option meaning > >Agreed. I'll spell out the names. > > > > IANA is requested to register codes for future CableLabs Client > > > Configuration Sub-options with an "Expert Review" approval policy as > > > described in RFC 2434 [2]. Future proposed sub-options will be > > > assigned a numeric code chosen by CableLabs, which will be > > > documented in the Internet Drafts that describe the sub-options. The > > > code assignment will be reviewed by a designated expert from the > > > IETF prior to publication in an RFC. > > > >1) I think it should be IETF consensus, not expert review. these > > options need to be reviewed by the IETF before they get implemented > > and cast in stone. IETF Consensus is the safest way to ensure that > > this happens. > > > >2) IANA chooses the values (as it typically does), not > > cablelabs. (Having cablelabs chose smells a bit like they want the > > values early for their implementations and/or specs) > >I'll defer comment on this issue to the Cablelabs folks. > > > > 13. Security Considerations > > > > > > This draft relies on the DHCP protocol [4] for authentication and > > > security, i.e. it does not provide in excess of what DHCP is (or will > > > be) providing. It does not expose any security threats beyond what is > > > currently exposed by other DHCP options. > > > >The security considerations section is inadequate. It should say > >something about the options themselves and what the security > >implications are should the options be spoofed, etc. That is, what are > >the security issues related to the specific options discussed in the > >document? Is it required that some sort of DHC authentication be used > >in order to prevent vulnerabilities (say) to the configuration of the > >kerberos stuff? > > > >Note on the kerberos options, the following comment was made > >(privately): > > > >Jonathan Trostle writes: > > > > > Section 13 (Security Considerations) indicates they are relying on > > > the DHCP protocol for authentication and security (should be more > > > precise about what security services). > > > > > If the new option data is manipulated, various DoS attacks are possible. > > > One option, Kerberos realm name, is potentially more serious. By > modifying > > > the realm, the attacker can change the user's TSP (if I recall correctly, > > > packetcable uses pkinit where the client authenticates the KDC by the > > > KDC's realm name in the KDC's certificate). Therefore, a malicious TSP > > > can act as a TSP for any user and then have access to the user's VoIP > > > and multimedia data. So it would be a good thing if the Kerberos realm > > > name is protected from modification in the DHCP protocol. Alternatively, > > > changing the realm name could be a means by which one TSP steals > customers > > > from another TSP without the customer's permission. > > > >then later, > > > >Jonathan Trostle writes: > > > > > Tom, > > > > > Yes, there should be some extra wording in the security considerations at > > > least. I recall an argument that layer 2 encryption protects the link > > > between the modem and the head end, and the DCHP server may be at the > head > > > end. But there should definitely be some words indicating that there is > > > protection for the DHCP messages at some layer. If this draft is used in > > > some other scenario (or even in the packetcable scenario possibly) then > > there > > > is the potential for security vulnerabilities. > > > > > Jonathan > >Agree that the security section could use some beefing up. > > >Finally, references should be split into normative/non-normative > >sections. > >nit: I have a single reference section primarily because I followed the >example of many other drafts/RFCs...assuming this would be adequate. > >I'll split it. > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > >-- > >Paul Duffy >Cisco Systems, Inc. >paduffy@cisco.com > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com --=====================_21113569==_.ALT Content-Type: text/html; charset="us-ascii" At 05:53 PM 10/16/2002 -0400, pall.ramanathan@arrisi.com wrote:

My understanding per RFC 2131 was that when client receives offers from multiple offers for DHCP Broadcast, the client can select a DHCP and send a unicast request to the DHCP the client selects. Couldn't the MTA do a unicast message to the TSP's DHCP server using the DHCP address the MTA receives from the cable modem. I tend to think that this will eliminate tearing up the DHCP protocol for PacketCable MTA.

Pall,

I am not understanding how a PacketCable MTA is "tearing up" the DHCP protocol.  Please elaborate...


I would think, this would be easy for vendore to implement also since it is within RFC 2131. Am I missing somethings here.

My opinions are mys own and has nothing to do with my employer.


Pall Ramanathan






Paul Duffy <paduffy@cisco.com>
Sent by: dhcwg-admin@ietf.org

10/16/2002 03:26 PM
       
        To:        Thomas Narten <narten@us.ibm.com>
        cc:        dhcwg@ietf.org
        Subject:        Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt


Hello Thomas,

Please find responses inline...formed from several conversations with
various PacketCable participants.

I'll try to have a new draft ready for next week.  We'd greatly appreciate
your effort to keep this moving along swiftly.

Cheers,

At 01:00 PM 10/11/2002 -0400, Thomas Narten wrote:
>Background: there was a quite a lot of private discussion/conference
>calls a month or two ago on this document, followed by a revised
>document. Here is my review of the current document.
>
>Thomas
>
> >   8.1. TSP's DHCP Server Address Sub-Options
>
>Seems to me that this options does (however subtly) modify DHC client
>behavior. My understanding is that CCC option 1/2, which
>lists a primary/backup DHC server are sent to the CM, which then
>communicates those two addresses to the MTA (a separate entity). The
>MTA then invokes DHC on its own, but is only allowed to talk to the
>servers whos addresses it received from the CM. In normal DHC, the
>client isn't restricted in anyway in what servers it communicates
>with. Thus, I would argue that CCC options 1/2 do modify the DHC
>protocol, albeit subtly and perhaps not signficantly. I am not
>particularly comfortable with this, but would like to hear more from
>the WG on this point. (Also, is my understanding here correct?)

RFC 2131 Section 4.4.1 "The time over which the client collects messages
and the mechanism used to select one DHCPOFFER are implementation
dependent".   PacketCable does not feel CCC.1/.2 in any way modifies the RFC.

> >    Due to specific needs of the MTA configuration process (described in
> >    [5]), a new CableLabs Client Configuration (CCC) option is needed for
> >    the DHCP protocol.  Both CM and MTA DHCP clients will request this
> >    option.  When requested, both the CM and TSP DHCP servers will
> >    populate this option into DHCP responses.
>
>
>Doesn't the client also provide this option and fill in some info?
>better to say this above (one or two sentences here would suffice). Or
>maybe just merge Section 9 text into the text here.

No, an MTA DHCP client never populates CCC option content into its any if
its requests.  The PacketCable MTA provisioning  specification (section 7)
contains detailed descriptions of when the CCC option is/is not populated
into DHCP messaging.

PacketCable's intent is to specify option syntax in the draft/RFC, while
referring to the PacketCable MTA prov specification for usage
details.  Otherwise, we're going to end up pulling large pieces of the
PacketCable provisioning spec into this draft...lots of duplication between
the documents (which I thought we agreed was undesirable).

That said, I can add a sentence or two stating that the client never
populates CCC option content into DHCP request messages.

>Should this document add a normative references to
>draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so
>referencing it shouldn't be a problem)? Seems like that would make
>sense.

As stated in the IETF draft writer's guidelines and the beginning of the
our draft..."It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as work in progress".  I took this to
mean referencing non RFC docs is prohibited.  Attempting to maximize the
speed at which this draft might progress through the IETF process, I tried
to adhere as faithfully as possible to those guidelines...PacketCable did
not consider ANY drafts for reference within this draft.

If you feel inclusion of this draft is a hard requirement, PacketCable will
have to open this issue with the manufacturers...further delaying the
progress of this draft (not good for us).  I'm also going to need an RFC #
for the ref ?

> >    - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035
> >      [7] section 3.1. Note that a terminating 0 is required.
>
>is compression allowed? (probably not useful -- then say so.)

Agreed. PacketCable will state compression "is/is not" allowed in the draft
(following discussion with the MTA manufacturers).

>For CCC option 3, does IANA need to maintain a registry for other
>"types"? An IANA considerations would seem to be  needed. It could say:
>  - allocation of future types requires IETF Consensus (or whatever)
>  - there will be no additional values, IANA does not need to maintain
>    a registry
>  - something else?

Agreed. No additional values are planned. PacketCable will state "IANA does
not need to maintain a registry".

>The CCC options for configuring Kerberos parameters seems odd to me
>(what kerberos document talks about the need for tuning these
>parameters?). The IESG may want this reviewed by someone with kerberos
>clue. (I'm just saying this so that there are no surprises should this
>issue come up later.)

This is a specific need of a PacketCable MTA.  It does not present any
issues with the Kerberos RFCs.  The CCC option is, by definition, Cablelabs
specific, so PacketCable does not see this causing any issues with non
Cablelabs devices.

>Also, the kerberos REALM name option seems like one that could easily
>be more general (i.e, not cablelabs specific). But probably too late
>for this. Also:

Agreed, too late.  PacketCable simply can not absorb the delay that would
result if we split the realm name sub-option out into a distinct DHCP
option draft.

>"Douglas E. Engert" <deengert@anl.gov> writes:
>
> > You should also look at:
> > " Distributing Kerberos KDC and Realm Information with DNS"
> > http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-03.txt
>
> > Which describes how to find a KDC using DNS. I should point out that
> > W2K, MIT and I think Hiemdal all have this implemented.
>
>I assume that cablelabs is familiar with this but still wants to go
>the DHC route?

1. Agreed, we prefer to stick to the DHCP route.
2. PacketCable does not see where this draft applies.  This draft appears
to describe how one uses DNS to turn a realm name into a KDC
address.  CCC.6 describes how the realm name initially arrives at the MTA .
3. Again, this would be citing a draft (which I understood to be not
acceptable)

> >    Cablelabs client devices issue DHCP requests that include DHCP
> >    options 55 and 60.  Option 55 will request the CCC option from the
>
>nit: would be good include neumonic names (e.g., ORO and class ID)
>here rather than just using the option number rather than assuming
>everyone knows the option meaning

Agreed.  I'll spell out the names.

> >    IANA is requested to register codes for future CableLabs Client
> >    Configuration Sub-options with an "Expert Review" approval policy as
> >    described in RFC 2434 [2]. Future proposed sub-options will be
> >    assigned a numeric code chosen by CableLabs, which will be
> >    documented in the Internet Drafts that describe the sub-options. The
> >    code assignment will be reviewed by a designated expert from the
> >    IETF prior to publication in an RFC.
>
>1) I think it should be IETF consensus, not expert review. these
>    options need to be reviewed by the IETF before they get implemented
>    and cast in stone. IETF Consensus is the safest way to ensure that
>    this happens.
>
>2) IANA chooses the values (as it typically does), not
>    cablelabs. (Having cablelabs chose smells a bit like they want the
>    values early for their implementations and/or specs)

I'll defer comment on this issue to the Cablelabs folks.

> >    13.  Security Considerations
> >
> >    This draft relies on the DHCP protocol [4] for authentication and
> >    security, i.e. it does not provide in excess of what DHCP is (or will
> >    be) providing. It does not expose any security threats beyond what is
> >    currently exposed by other DHCP options.
>
>The security considerations section is inadequate. It should say
>something about the options themselves and what the security
>implications are should the options be spoofed, etc. That is, what are
>the security issues related to the specific options discussed in the
>document? Is it required that some sort of DHC authentication be used
>in order to prevent vulnerabilities (say) to the configuration of the
>kerberos stuff?
>
>Note on the kerberos options, the following comment was made
>(privately):
>
>Jonathan Trostle <jtrostle@world.std.com> writes:
>
> > Section 13 (Security Considerations) indicates they are relying on
> > the DHCP protocol for authentication and security (should be more
> > precise about what security services).
>
> > If the new option data is manipulated, various DoS attacks are possible.
> > One option, Kerberos realm name, is potentially more serious. By modifying
> > the realm, the attacker can change the user's TSP (if I recall correctly,
> > packetcable uses pkinit where the client authenticates the KDC by the
> > KDC's realm name in the KDC's certificate). Therefore, a malicious TSP
> > can act as a TSP for any user and then have access to the user's VoIP
> > and multimedia data. So it would be a good thing if the Kerberos realm
> > name is protected from modification in the DHCP protocol. Alternatively,
> > changing the realm name could be a means by which one TSP steals customers
> > from another TSP without the customer's permission.
>
>then later,
>
>Jonathan Trostle <jtrostle@world.std.com> writes:
>
> > Tom,
>
> > Yes, there should be some extra wording in the security considerations at
> > least. I recall an argument that layer 2 encryption protects the link
> > between the modem and the head end, and the DCHP server may be at the head
> > end. But there should definitely be some words indicating that there is
> > protection for the DHCP messages at some layer. If this draft is used in
> > some other scenario (or even in the packetcable scenario possibly) then
> there
> > is the potential for security vulnerabilities.
>
> > Jonathan

Agree that the security section could use some beefing up.

>Finally, references should be split into normative/non-normative
>sections.

nit: I have a single reference section primarily because I followed the
example of many other drafts/RFCs...assuming this would be adequate.

I'll split it.

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

--

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com


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


--

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com

--=====================_21113569==_.ALT-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 16 18:23:00 2002 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 SAA13807; Wed, 16 Oct 2002 18:23:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GMOIv01643; Wed, 16 Oct 2002 18:24:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9GMNSv01614 for ; Wed, 16 Oct 2002 18:23:28 -0400 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 SAA13793 for ; Wed, 16 Oct 2002 18:21:09 -0400 (EDT) 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 g9GMN9gc008739; Wed, 16 Oct 2002 16:23:09 -0600 (MDT) Received: from 147.191.89.201 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Wed, 16 Oct 2002 16:19:59 -0600 X-Server-Uuid: 4520D425-5A30-451F-8662-E5DDF307F3B1 Received: by entexchimc02.tci.com with Internet Mail Service ( 5.5.2653.19) id <4XYBWVCR>; Wed, 16 Oct 2002 16:22:55 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBCDFA@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'pall.ramanathan@arrisi.com'" , "Paul Duffy" cc: dhcwg@ietf.org, "Thomas Narten" Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-03.txt Date: Wed, 16 Oct 2002 16:22:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11B3398589038-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27562.8ED4A2E0" 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_01C27562.8ED4A2E0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pall, you need to re-read RFC 2131 again. When a standard DHCP client chooses an offer, it sends a *broadcast* DHCPREQUEST message which is relayed to all of the DHCP servers. Here's the relevant text from RFC 2131 section 3.1: 3. The client receives one or more DHCPOFFER messages from one or more servers. The client may choose to wait for multiple responses. The client chooses one server from which to request configuration parameters, based on the configuration parameters offered in the DHCPOFFER messages. The client broadcasts a DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected, and that MAY include other options specifying desired configuration values. The 'requested IP address' option MUST be set to the value of 'yiaddr' in the DHCPOFFER message from the server. This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents. To help ensure that any BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message MUST use the same value in the DHCP message header's 'secs' field and be sent to the same IP broadcast address as the original DHCPDISCOVER message. The client times out and retransmits the DHCPDISCOVER message if the client receives no DHCPOFFER messages. -- Rich -----Original Message----- From: pall.ramanathan@arrisi.com [mailto:pall.ramanathan@arrisi.com] Sent: Wednesday, October 16, 2002 5:54 PM To: Paul Duffy Cc: dhcwg@ietf.org; dhcwg-admin@ietf.org; Thomas Narten Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt My understanding per RFC 2131 was that when client receives offers from multiple offers for DHCP Broadcast, the client can select a DHCP and send a unicast request to the DHCP the client selects. Couldn't the MTA do a unicast message to the TSP's DHCP server using the DHCP address the MTA receives from the cable modem. I tend to think that this will eliminate tearing up the DHCP protocol for PacketCable MTA. I would think, this would be easy for vendore to implement also since it is within RFC 2131. Am I missing somethings here. My opinions are mys own and has nothing to do with my employer. Pall Ramanathan Paul Duffy Sent by: dhcwg-admin@ietf.org 10/16/2002 03:26 PM To: Thomas Narten cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt Hello Thomas, Please find responses inline...formed from several conversations with various PacketCable participants. I'll try to have a new draft ready for next week. We'd greatly appreciate your effort to keep this moving along swiftly. Cheers, At 01:00 PM 10/11/2002 -0400, Thomas Narten wrote: >Background: there was a quite a lot of private discussion/conference >calls a month or two ago on this document, followed by a revised >document. Here is my review of the current document. > >Thomas > > > 8.1. TSP's DHCP Server Address Sub-Options > >Seems to me that this options does (however subtly) modify DHC client >behavior. My understanding is that CCC option 1/2, which >lists a primary/backup DHC server are sent to the CM, which then >communicates those two addresses to the MTA (a separate entity). The >MTA then invokes DHC on its own, but is only allowed to talk to the >servers whos addresses it received from the CM. In normal DHC, the >client isn't restricted in anyway in what servers it communicates >with. Thus, I would argue that CCC options 1/2 do modify the DHC >protocol, albeit subtly and perhaps not signficantly. I am not >particularly comfortable with this, but would like to hear more from >the WG on this point. (Also, is my understanding here correct?) RFC 2131 Section 4.4.1 "The time over which the client collects messages and the mechanism used to select one DHCPOFFER are implementation dependent". PacketCable does not feel CCC.1/.2 in any way modifies the RFC. > > Due to specific needs of the MTA configuration process (described in > > [5]), a new CableLabs Client Configuration (CCC) option is needed for > > the DHCP protocol. Both CM and MTA DHCP clients will request this > > option. When requested, both the CM and TSP DHCP servers will > > populate this option into DHCP responses. > > >Doesn't the client also provide this option and fill in some info? >better to say this above (one or two sentences here would suffice). Or >maybe just merge Section 9 text into the text here. No, an MTA DHCP client never populates CCC option content into its any if its requests. The PacketCable MTA provisioning specification (section 7) contains detailed descriptions of when the CCC option is/is not populated into DHCP messaging. PacketCable's intent is to specify option syntax in the draft/RFC, while referring to the PacketCable MTA prov specification for usage details. Otherwise, we're going to end up pulling large pieces of the PacketCable provisioning spec into this draft...lots of duplication between the documents (which I thought we agreed was undesirable). That said, I can add a sentence or two stating that the client never populates CCC option content into DHCP request messages. >Should this document add a normative references to >draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so >referencing it shouldn't be a problem)? Seems like that would make >sense. As stated in the IETF draft writer's guidelines and the beginning of the our draft..."It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress". I took this to mean referencing non RFC docs is prohibited. Attempting to maximize the speed at which this draft might progress through the IETF process, I tried to adhere as faithfully as possible to those guidelines...PacketCable did not consider ANY drafts for reference within this draft. If you feel inclusion of this draft is a hard requirement, PacketCable will have to open this issue with the manufacturers...further delaying the progress of this draft (not good for us). I'm also going to need an RFC # for the ref ? > > - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035 > > [7] section 3.1. Note that a terminating 0 is required. > >is compression allowed? (probably not useful -- then say so.) Agreed. PacketCable will state compression "is/is not" allowed in the draft (following discussion with the MTA manufacturers). >For CCC option 3, does IANA need to maintain a registry for other >"types"? An IANA considerations would seem to be needed. It could say: > - allocation of future types requires IETF Consensus (or whatever) > - there will be no additional values, IANA does not need to maintain > a registry > - something else? Agreed. No additional values are planned. PacketCable will state "IANA does not need to maintain a registry". >The CCC options for configuring Kerberos parameters seems odd to me >(what kerberos document talks about the need for tuning these >parameters?). The IESG may want this reviewed by someone with kerberos >clue. (I'm just saying this so that there are no surprises should this >issue come up later.) This is a specific need of a PacketCable MTA. It does not present any issues with the Kerberos RFCs. The CCC option is, by definition, Cablelabs specific, so PacketCable does not see this causing any issues with non Cablelabs devices. >Also, the kerberos REALM name option seems like one that could easily >be more general (i.e, not cablelabs specific). But probably too late >for this. Also: Agreed, too late. PacketCable simply can not absorb the delay that would result if we split the realm name sub-option out into a distinct DHCP option draft. >"Douglas E. Engert" writes: > > > You should also look at: > > " Distributing Kerberos KDC and Realm Information with DNS" > > http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-03.txt > > > Which describes how to find a KDC using DNS. I should point out that > > W2K, MIT and I think Hiemdal all have this implemented. > >I assume that cablelabs is familiar with this but still wants to go >the DHC route? 1. Agreed, we prefer to stick to the DHCP route. 2. PacketCable does not see where this draft applies. This draft appears to describe how one uses DNS to turn a realm name into a KDC address. CCC.6 describes how the realm name initially arrives at the MTA . 3. Again, this would be citing a draft (which I understood to be not acceptable) > > Cablelabs client devices issue DHCP requests that include DHCP > > options 55 and 60. Option 55 will request the CCC option from the > >nit: would be good include neumonic names (e.g., ORO and class ID) >here rather than just using the option number rather than assuming >everyone knows the option meaning Agreed. I'll spell out the names. > > IANA is requested to register codes for future CableLabs Client > > Configuration Sub-options with an "Expert Review" approval policy as > > described in RFC 2434 [2]. Future proposed sub-options will be > > assigned a numeric code chosen by CableLabs, which will be > > documented in the Internet Drafts that describe the sub-options. The > > code assignment will be reviewed by a designated expert from the > > IETF prior to publication in an RFC. > >1) I think it should be IETF consensus, not expert review. these > options need to be reviewed by the IETF before they get implemented > and cast in stone. IETF Consensus is the safest way to ensure that > this happens. > >2) IANA chooses the values (as it typically does), not > cablelabs. (Having cablelabs chose smells a bit like they want the > values early for their implementations and/or specs) I'll defer comment on this issue to the Cablelabs folks. > > 13. Security Considerations > > > > This draft relies on the DHCP protocol [4] for authentication and > > security, i.e. it does not provide in excess of what DHCP is (or will > > be) providing. It does not expose any security threats beyond what is > > currently exposed by other DHCP options. > >The security considerations section is inadequate. It should say >something about the options themselves and what the security >implications are should the options be spoofed, etc. That is, what are >the security issues related to the specific options discussed in the >document? Is it required that some sort of DHC authentication be used >in order to prevent vulnerabilities (say) to the configuration of the >kerberos stuff? > >Note on the kerberos options, the following comment was made >(privately): > >Jonathan Trostle writes: > > > Section 13 (Security Considerations) indicates they are relying on > > the DHCP protocol for authentication and security (should be more > > precise about what security services). > > > If the new option data is manipulated, various DoS attacks are possible. > > One option, Kerberos realm name, is potentially more serious. By modifying > > the realm, the attacker can change the user's TSP (if I recall correctly, > > packetcable uses pkinit where the client authenticates the KDC by the > > KDC's realm name in the KDC's certificate). Therefore, a malicious TSP > > can act as a TSP for any user and then have access to the user's VoIP > > and multimedia data. So it would be a good thing if the Kerberos realm > > name is protected from modification in the DHCP protocol. Alternatively, > > changing the realm name could be a means by which one TSP steals customers > > from another TSP without the customer's permission. > >then later, > >Jonathan Trostle writes: > > > Tom, > > > Yes, there should be some extra wording in the security considerations at > > least. I recall an argument that layer 2 encryption protects the link > > between the modem and the head end, and the DCHP server may be at the head > > end. But there should definitely be some words indicating that there is > > protection for the DHCP messages at some layer. If this draft is used in > > some other scenario (or even in the packetcable scenario possibly) then > there > > is the potential for security vulnerabilities. > > > Jonathan Agree that the security section could use some beefing up. >Finally, references should be split into normative/non-normative >sections. nit: I have a single reference section primarily because I followed the example of many other drafts/RFCs...assuming this would be adequate. I'll split it. >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C27562.8ED4A2E0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Pall, you need to re-read RFC 2131 again. When a standard DHCP client chooses an offer, it sends a *broadcast* DHCPREQUEST message which is relayed to all of the DHCP servers. Here's the relevant text from RFC 2131 section 3.1:
 
  3. The client receives one or more DHCPOFFER messages from one or more
     servers.  The client may choose to wait for multiple responses.
     The client chooses one server from which to request configuration
     parameters, based on the configuration parameters offered in the
     DHCPOFFER messages.  The client broadcasts a DHCPREQUEST message
     that MUST include the 'server identifier' option to indicate which
     server it has selected, and that MAY include other options
     specifying desired configuration values.  The 'requested IP
     address' option MUST be set to the value of 'yiaddr' in the
     DHCPOFFER message from the server.  This DHCPREQUEST message is
     broadcast and relayed through DHCP/BOOTP relay agents.  To help
     ensure that any BOOTP relay agents forward the DHCPREQUEST message
     to the same set of DHCP servers that received the original
     DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
     value in the DHCP message header's 'secs' field and be sent to the
     same IP broadcast address as the original DHCPDISCOVER message.
     The client times out and retransmits the DHCPDISCOVER message if
     the client receives no DHCPOFFER messages.
-- Rich
-----Original Message-----
From: pall.ramanathan@arrisi.com [mailto:pall.ramanathan@arrisi.com]
Sent: Wednesday, October 16, 2002 5:54 PM
To: Paul Duffy
Cc: dhcwg@ietf.org; dhcwg-admin@ietf.org; Thomas Narten
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt


My understanding per RFC 2131 was that when client receives offers from multiple offers for DHCP Broadcast, the client can select a DHCP and send a unicast request to the DHCP the client selects. Couldn't the MTA do a unicast message to the TSP's DHCP server using the DHCP address the MTA receives from the cable modem. I tend to think that this will eliminate tearing up the DHCP protocol for PacketCable MTA. I would think, this would be easy for vendore to implement also since it is within RFC 2131. Am I missing somethings here.

My opinions are mys own and has nothing to do with my employer.


Pall Ramanathan






Paul Duffy <paduffy@cisco.com>
Sent by: dhcwg-admin@ietf.org

10/16/2002 03:26 PM

       
        To:        Thomas Narten <narten@us.ibm.com>
        cc:        dhcwg@ietf.org
        Subject:        Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt



Hello Thomas,

Please find responses inline...formed from several conversations with
various PacketCable participants.

I'll try to have a new draft ready for next week.  We'd greatly appreciate
your effort to keep this moving along swiftly.

Cheers,

At 01:00 PM 10/11/2002 -0400, Thomas Narten wrote:
>Background: there was a quite a lot of private discussion/conference
>calls a month or two ago on this document, followed by a revised
>document. Here is my review of the current document.
>
>Thomas
>
> >   8.1. TSP's DHCP Server Address Sub-Options
>
>Seems to me that this options does (however subtly) modify DHC client
>behavior. My understanding is that CCC option 1/2, which
>lists a primary/backup DHC server are sent to the CM, which then
>communicates those two addresses to the MTA (a separate entity). The
>MTA then invokes DHC on its own, but is only allowed to talk to the
>servers whos addresses it received from the CM. In normal DHC, the
>client isn't restricted in anyway in what servers it communicates
>with. Thus, I would argue that CCC options 1/2 do modify the DHC
>protocol, albeit subtly and perhaps not signficantly. I am not
>particularly comfortable with this, but would like to hear more from
>the WG on this point. (Also, is my understanding here correct?)

RFC 2131 Section 4.4.1 "The time over which the client collects messages
and the mechanism used to select one DHCPOFFER are implementation
dependent".   PacketCable does not feel CCC.1/.2 in any way modifies the RFC.

> >    Due to specific needs of the MTA configuration process (described in
> >    [5]), a new CableLabs Client Configuration (CCC) option is needed for
> >    the DHCP protocol.  Both CM and MTA DHCP clients will request this
> >    option.  When requested, both the CM and TSP DHCP servers will
> >    populate this option into DHCP responses.
>
>
>Doesn't the client also provide this option and fill in some info?
>better to say this above (one or two sentences here would suffice). Or
>maybe just merge Section 9 text into the text here.

No, an MTA DHCP client never populates CCC option content into its any if
its requests.  The PacketCable MTA provisioning  specification (section 7)
contains detailed descriptions of when the CCC option is/is not populated
into DHCP messaging.

PacketCable's intent is to specify option syntax in the draft/RFC, while
referring to the PacketCable MTA prov specification for usage
details.  Otherwise, we're going to end up pulling large pieces of the
PacketCable provisioning spec into this draft...lots of duplication between
the documents (which I thought we agreed was undesirable).

That said, I can add a sentence or two stating that the client never
populates CCC option content into DHCP request messages.

>Should this document add a normative references to
>draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so
>referencing it shouldn't be a problem)? Seems like that would make
>sense.

As stated in the IETF draft writer's guidelines and the beginning of the
our draft..."It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as work in progress".  I took this to
mean referencing non RFC docs is prohibited.  Attempting to maximize the
speed at which this draft might progress through the IETF process, I tried
to adhere as faithfully as possible to those guidelines...PacketCable did
not consider ANY drafts for reference within this draft.

If you feel inclusion of this draft is a hard requirement, PacketCable will
have to open this issue with the manufacturers...further delaying the
progress of this draft (not good for us).  I'm also going to need an RFC #
for the ref ?

> >    - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035
> >      [7] section 3.1. Note that a terminating 0 is required.
>
>is compression allowed? (probably not useful -- then say so.)

Agreed. PacketCable will state compression "is/is not" allowed in the draft
(following discussion with the MTA manufacturers).

>For CCC option 3, does IANA need to maintain a registry for other
>"types"? An IANA considerations would seem to be  needed. It could say:
>  - allocation of future types requires IETF Consensus (or whatever)
>  - there will be no additional values, IANA does not need to maintain
>    a registry
>  - something else?

Agreed. No additional values are planned. PacketCable will state "IANA does
not need to maintain a registry".

>The CCC options for configuring Kerberos parameters seems odd to me
>(what kerberos document talks about the need for tuning these
>parameters?). The IESG may want this reviewed by someone with kerberos
>clue. (I'm just saying this so that there are no surprises should this
>issue come up later.)

This is a specific need of a PacketCable MTA.  It does not present any
issues with the Kerberos RFCs.  The CCC option is, by definition, Cablelabs
specific, so PacketCable does not see this causing any issues with non
Cablelabs devices.

>Also, the kerberos REALM name option seems like one that could easily
>be more general (i.e, not cablelabs specific). But probably too late
>for this. Also:

Agreed, too late.  PacketCable simply can not absorb the delay that would
result if we split the realm name sub-option out into a distinct DHCP
option draft.

>"Douglas E. Engert" <deengert@anl.gov> writes:
>
> > You should also look at:
> > " Distributing Kerberos KDC and Realm Information with DNS"
> > http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-03.txt
>
> > Which describes how to find a KDC using DNS. I should point out that
> > W2K, MIT and I think Hiemdal all have this implemented.
>
>I assume that cablelabs is familiar with this but still wants to go
>the DHC route?

1. Agreed, we prefer to stick to the DHCP route.
2. PacketCable does not see where this draft applies.  This draft appears
to describe how one uses DNS to turn a realm name into a KDC
address.  CCC.6 describes how the realm name initially arrives at the MTA .
3. Again, this would be citing a draft (which I understood to be not
acceptable)

> >    Cablelabs client devices issue DHCP requests that include DHCP
> >    options 55 and 60.  Option 55 will request the CCC option from the
>
>nit: would be good include neumonic names (e.g., ORO and class ID)
>here rather than just using the option number rather than assuming
>everyone knows the option meaning

Agreed.  I'll spell out the names.

> >    IANA is requested to register codes for future CableLabs Client
> >    Configuration Sub-options with an "Expert Review" approval policy as
> >    described in RFC 2434 [2]. Future proposed sub-options will be
> >    assigned a numeric code chosen by CableLabs, which will be
> >    documented in the Internet Drafts that describe the sub-options. The
> >    code assignment will be reviewed by a designated expert from the
> >    IETF prior to publication in an RFC.
>
>1) I think it should be IETF consensus, not expert review. these
>    options need to be reviewed by the IETF before they get implemented
>    and cast in stone. IETF Consensus is the safest way to ensure that
>    this happens.
>
>2) IANA chooses the values (as it typically does), not
>    cablelabs. (Having cablelabs chose smells a bit like they want the
>    values early for their implementations and/or specs)

I'll defer comment on this issue to the Cablelabs folks.

> >    13.  Security Considerations
> >
> >    This draft relies on the DHCP protocol [4] for authentication and
> >    security, i.e. it does not provide in excess of what DHCP is (or will
> >    be) providing. It does not expose any security threats beyond what is
> >    currently exposed by other DHCP options.
>
>The security considerations section is inadequate. It should say
>something about the options themselves and what the security
>implications are should the options be spoofed, etc. That is, what are
>the security issues related to the specific options discussed in the
>document? Is it required that some sort of DHC authentication be used
>in order to prevent vulnerabilities (say) to the configuration of the
>kerberos stuff?
>
>Note on the kerberos options, the following comment was made
>(privately):
>
>Jonathan Trostle <jtrostle@world.std.com> writes:
>
> > Section 13 (Security Considerations) indicates they are relying on
> > the DHCP protocol for authentication and security (should be more
> > precise about what security services).
>
> > If the new option data is manipulated, various DoS attacks are possible.
> > One option, Kerberos realm name, is potentially more serious. By modifying
> > the realm, the attacker can change the user's TSP (if I recall correctly,
> > packetcable uses pkinit where the client authenticates the KDC by the
> > KDC's realm name in the KDC's certificate). Therefore, a malicious TSP
> > can act as a TSP for any user and then have access to the user's VoIP
> > and multimedia data. So it would be a good thing if the Kerberos realm
> > name is protected from modification in the DHCP protocol. Alternatively,
> > changing the realm name could be a means by which one TSP steals customers
> > from another TSP without the customer's permission.
>
>then later,
>
>Jonathan Trostle <jtrostle@world.std.com> writes:
>
> > Tom,
>
> > Yes, there should be some extra wording in the security considerations at
> > least. I recall an argument that layer 2 encryption protects the link
> > between the modem and the head end, and the DCHP server may be at the head
> > end. But there should definitely be some words indicating that there is
> > protection for the DHCP messages at some layer. If this draft is used in
> > some other scenario (or even in the packetcable scenario possibly) then
> there
> > is the potential for security vulnerabilities.
>
> > Jonathan

Agree that the security section could use some beefing up.

>Finally, references should be split into normative/non-normative
>sections.

nit: I have a single reference section primarily because I followed the
example of many other drafts/RFCs...assuming this would be adequate.

I'll split it.

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

--

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com


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


------_=_NextPart_001_01C27562.8ED4A2E0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 16 20:10:26 2002 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 UAA15888; Wed, 16 Oct 2002 20:10:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H0Bbv06716; Wed, 16 Oct 2002 20:11:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9H0AVv06696 for ; Wed, 16 Oct 2002 20:10:31 -0400 Received: from hoth.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15863; Wed, 16 Oct 2002 20:08:13 -0400 (EDT) From: pall.ramanathan@arrisi.com Received: from mars.ARRISI.COM ([10.0.248.10]) by hoth.arrisi.com (Lotus Domino Release 5.0.10) with ESMTP id 2002101620102365:734 ; Wed, 16 Oct 2002 20:10:23 -0400 To: Paul Duffy Cc: dhcwg@ietf.org, dhcwg-admin@ietf.org, Thomas Narten Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Wed, 16 Oct 2002 20:10:23 -0400 X-MIMETrack: Serialize by Router on Mars/Arris(Release 5.0.11 |July 24, 2002) at 10/16/2002 08:10:23 PM, Serialize complete at 10/16/2002 08:10:23 PM, Itemize by SMTP Server on Hoth/Antec(Release 5.0.10 |March 22, 2002) at 10/16/2002 08:10:23 PM, Serialize by Router on Hoth/Antec(Release 5.0.10 |March 22, 2002) at 10/16/2002 08:10:24 PM, Serialize complete at 10/16/2002 08:10:24 PM Content-Type: multipart/alternative; boundary="=_alternative 0000EE0B85256C55_=" 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 multipart message in MIME format. --=_alternative 0000EE0B85256C55_= Content-Type: text/plain; charset="us-ascii" Paul, A bad choice of words. I appologize. Pall --=_alternative 0000EE0B85256C55_= Content-Type: text/html; charset="us-ascii"
Paul,

A bad choice of words. I appologize.

Pall
 --=_alternative 0000EE0B85256C55_=-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 17 12:54:26 2002 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 MAA17599; Thu, 17 Oct 2002 12:54:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HGuAv04558; Thu, 17 Oct 2002 12:56:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HGsOv04502 for ; Thu, 17 Oct 2002 12:54:24 -0400 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 MAA17467 for ; Thu, 17 Oct 2002 12:52:07 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9HGsJIn014334 for ; Thu, 17 Oct 2002 09:54:20 -0700 (PDT) Date: Thu, 17 Oct 2002 12:54:19 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] WG agenda and discussion of charter 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'm taking requests for agenda slots during the dhc WG meeting in Atlanta. I'll post a summrary of the requests I've received later today at www.dhcp.org We need broader WG participation in the WG charter discussion. I've posted the current draft revised charter at http://www.dhcp.org/charter-update.html, and the e-mail discussion thread on the WG charter is at http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01406.html Finally, I've posted a sumary of dhc WG and related Internet Drafts at http://www.dhcp.org/dhcp-ids.html _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 17 12:56:14 2002 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 MAA17669; Thu, 17 Oct 2002 12:56:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HGw3v04618; Thu, 17 Oct 2002 12:58:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9HGvTv04586 for ; Thu, 17 Oct 2002 12:57:29 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17635 for ; Thu, 17 Oct 2002 12:55:12 -0400 (EDT) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-253.cisco.com [161.44.149.253]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA12392; Thu, 17 Oct 2002 12:57:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20021017123314.02862720@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Oct 2002 12:57:21 -0400 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20021016112408.02a0a348@funnel.cisco.com> References: <200210111700.g9BH0dH08214@rotala.raleigh.ibm.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: , Thomas, Pall's comment re: unicasting a REQUEST prompted me to re-read the relevant section of 2131 and the PacketCable MTA prov spec. I now have a better sense of where the confusion is rooted... >> > 8.1. TSP's DHCP Server Address Sub-Options >> >>Seems to me that this options does (however subtly) modify DHC client >>behavior. My understanding is that CCC option 1/2, which >>lists a primary/backup DHC server are sent to the CM, which then >>communicates those two addresses to the MTA (a separate entity). The >>MTA then invokes DHC on its own, but is only allowed to talk to the >>servers whos addresses it received from the CM. In normal DHC, the >>client isn't restricted in anyway in what servers it communicates >>with. Thus, I would argue that CCC options 1/2 do modify the DHC >>protocol, albeit subtly and perhaps not signficantly. I am not >>particularly comfortable with this, but would like to hear more from >>the WG on this point. (Also, is my understanding here correct?) > >RFC 2131 Section 4.4.1 "The time over which the client collects messages >and the mechanism used to select one DHCPOFFER are implementation >dependent". PacketCable does not feel CCC.1/.2 in any way modifies the RFC. The PacketCable MTA prov spec, as it is currently worded, could give the reader the impression that an MTA unicasts its DHCP REQUEST to a specific server identified via CCC.1/.2. This is not the intent, nor how the present implementations currently operate. The MTA applies CCC.1/.2 as a filter to all received OFFERS, selects one, then broadcasts its REQUEST (per RFC 2131). PacketCable is modifying the MTA prov spec (in the next few days) to clearly state that the REQUEST is broadcast. Good point Pall ! Cheers, -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 18 07:32:54 2002 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 HAA21698; Fri, 18 Oct 2002 07:32:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBXuv08175; Fri, 18 Oct 2002 07:33:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9IBVjv08065 for ; Fri, 18 Oct 2002 07:31:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21226; Fri, 18 Oct 2002 07:29:30 -0400 (EDT) Message-Id: <200210181129.HAA21226@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, 18 Oct 2002 07:29:30 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-suboptions-kdc-serveraddress-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 : KDC Server Address Sub-option Author(s) : K. Luehrs, R. Woundy, J. Bevilacqua Filename : draft-ietf-dhc-suboptions-kdc-serveraddress-01.txt Pages : 4 Date : 2002-10-17 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-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-suboptions-kdc-serveraddress-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-suboptions-kdc-serveraddress-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: <2002-10-17145831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-suboptions-kdc-serveraddress-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-17145831.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 Oct 21 16:08:03 2002 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 QAA13477; Mon, 21 Oct 2002 16:08:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LK9Fv20599; Mon, 21 Oct 2002 16:09:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9LK51v19946 for ; Mon, 21 Oct 2002 16:05:01 -0400 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 QAA13320 for ; Mon, 21 Oct 2002 16:02:39 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9LK4oQm025648; Mon, 21 Oct 2002 16:04:50 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9LK4nDL075148; Mon, 21 Oct 2002 14:04:49 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g9LK2Ck23663; Mon, 21 Oct 2002 16:02:12 -0400 Message-Id: <200210212002.g9LK2Ck23663@rotala.raleigh.ibm.com> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHC WG charter In-Reply-To: Message from Ralph Droms of "Tue, 15 Oct 2002 09:06:44 EDT." <4.3.2.7.2.20021015085610.00b5baa8@funnel.cisco.com> Date: Mon, 21 Oct 2002 16:02:12 -0400 From: Thomas Narten 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: , Hi Ralph. > > > * Develop a threat model and analysis of the authentication > > > protection provided by RFC3118; specific issues to be addressed > > > include: > > > - Improved key management and scalability > > > >Sounds here like your already jumping ahead to the requirements for > >new protocols. I.e., shouldn't this phase be focused on undertstanding > >limiations of the current mechanisms? Is this just a wording issue? > Perhaps it is a wording issue? s/include/might include/ ?? The intended > purpose for the bullet list is to capture current "common knowledge" about > the threat model and RFC3118. The word "improved" implies to me not analyzing/understanding the current systems, but jumping to the next steps of what is needed. Seems like the threat model/analysis should be focused on understanding the limitations and threats of what we have specified today. Having said that, I don't doubt that improvements are needed. :-) So this is a wording issue I think. > > > - Security for messages passed between relay agents and servers > > > - Threats of DoS attacks through FORCERENEW > > > > > * Develop requirements for any new protocols to address threats or > > > other enhancement identified by the threat model and analysis of > > > 3118 > > > >What's missing above is a clear statement that this WG will develop > >new authentication mechanisms that address the deployability problems > >with the current schemes (whether through an extension to 3118 or > >something else). Or that it will address the relay-agent to DHC server > >path. > Can you explain this comment in a different way, as it seems to be at > cross-purposes with your previous comment about "jumping ahead to the > requirements". I think we're in having a violent agreement that we want to > (a) get some DHCP authentication out to the client deployed and common > wisdom is that the best path is through new mechanisms in the RFC3118 > framework; and (b) secure communication between the DHCP relay agents and > servers. Maybe what is needed is a context paragraph before the specific tasks. It could say something like: RFC 3118 defines current security mechanisms for DHCP. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. There is widespread feeling that its current restriction to manual keying of clients limits its deployability. It is the goal of this WG to rectify this situation by defining extensions that have better deployability properties. In order to achive this goal, the WG will perform the following security-related tasks: [and then list specific items] > > > * Complete the specification of DHCP for IPv6 (DHCPv6): > > > - Gain acceptance and publication of current Internet Draft as > > > Proposed Standard > > > - Develop and publish specifications for options and other > > > extensions to DHCPv6, including those already published as > > > Internet Drafts > > > >General comment on options (both IPv4 and IPv6). I'd like the charter > >to clearly indicate that the DHC WG will be reviewing options to make > >sure they are consistent with the protocol, other option usages, etc. > The charter has a separate bullet item for review of options. Are you > suggesting that the bullet item be extended to include "consistent with the > protocol, other option usages, etc." as specific types of review? I think it would be useful to have more specific text that describes how (and when) options will be reviewed by the WG, and when they will be taken on by the WG. I.e, something like: This WG also is responsible for reviewing (and sometimes developing) DHC options (for both IPv4 and IPv6). The WG is expected to review all proposed DHC options to ensure that they are consistent with the DHC protocol, other option formats, that they do not duplicate existing options, etc. The WG cannot (generally) be responsible for evaluating the semantic content of proposed options. Only subject matter experts for the technology the option relates to can do so. The DHC WG will not adopt new DHC option proposals as WG documents without first coordinating with other relevant WGs and determining who has the responsibility for reviewing the semantic content of an option. I don't have a strong feeling about which WG owns a DHC option document (when the option is needed by another WG). So long as the two WGs coordinate, things should work out. But in anycase, the WG should sign off on all DHC options no later than (and hopefully much sooner than) IETF LC. But this level of detail can probably be left out of the charter and dealt with on a case-by-case basis. > >Also, I don't like the "other client and relay agent options" as it is > >too open ended. I think the WG needs a way of vetting potential > >options before the WG takes them on officially. > There are other options currently in the pipeline; this "other ... options" > bullet is intended to refer to those options that are "work in > progress". New work is intended to fall under the following bullet > item. The problem is that once the charter is out, there is no context for recalling which options were "in the pipeline" when the charter was written and which are new. Thus, it would probably be better to just list the IDs that the WG thinks it still has responsbility for. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 22 09:19:32 2002 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 JAA15846; Tue, 22 Oct 2002 09:19:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MDKfv13238; Tue, 22 Oct 2002 09:20:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MDIkv13098 for ; Tue, 22 Oct 2002 09:18:46 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15715 for ; Tue, 22 Oct 2002 09:16:27 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-145.cisco.com [10.82.240.145]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07138 for ; Tue, 22 Oct 2002 09:18:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20021022091558.03c28e58@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Oct 2002 09:18:39 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] DHC WG charter In-Reply-To: <200210212002.g9LK2Ck23663@rotala.raleigh.ibm.com> References: <4.3.2.7.2.20021015085610.00b5baa8@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , WG members: We *require* input from WG members regarding the revision of the WG charter. This is *not* a task for just the WG chair and the AD. Please review the current revised charter at http://www.dhcp.org/charter-update.html and contribute to the discussion thread. - Ralph At 04:02 PM 10/21/2002 -0400, Thomas Narten wrote: >Hi Ralph. > > > > > * Develop a threat model and analysis of the authentication > > > > protection provided by RFC3118; specific issues to be addressed > > > > include: > > > > - Improved key management and scalability > > > > > >Sounds here like your already jumping ahead to the requirements for > > >new protocols. I.e., shouldn't this phase be focused on undertstanding > > >limiations of the current mechanisms? Is this just a wording issue? > > > Perhaps it is a wording issue? s/include/might include/ ?? The intended > > purpose for the bullet list is to capture current "common knowledge" about > > the threat model and RFC3118. > >The word "improved" implies to me not analyzing/understanding the >current systems, but jumping to the next steps of what is >needed. Seems like the threat model/analysis should be focused on >understanding the limitations and threats of what we have specified >today. > >Having said that, I don't doubt that improvements are needed. :-) So >this is a wording issue I think. > > > > > - Security for messages passed between relay agents and servers > > > > - Threats of DoS attacks through FORCERENEW > > > > > > > * Develop requirements for any new protocols to address threats or > > > > other enhancement identified by the threat model and analysis of > > > > 3118 > > > > > >What's missing above is a clear statement that this WG will develop > > >new authentication mechanisms that address the deployability problems > > >with the current schemes (whether through an extension to 3118 or > > >something else). Or that it will address the relay-agent to DHC server > > >path. > > > Can you explain this comment in a different way, as it seems to be at > > cross-purposes with your previous comment about "jumping ahead to the > > requirements". I think we're in having a violent agreement that we > want to > > (a) get some DHCP authentication out to the client deployed and common > > wisdom is that the best path is through new mechanisms in the RFC3118 > > framework; and (b) secure communication between the DHCP relay agents and > > servers. > >Maybe what is needed is a context paragraph before the specific >tasks. It could say something like: > > RFC 3118 defines current security mechanisms for DHCP. > Unfortunately, RFC 3118 has neither been implemented nor deployed > to date. There is widespread feeling that its current restriction > to manual keying of clients limits its deployability. It is the > goal of this WG to rectify this situation by defining extensions > that have better deployability properties. In order to achive this > goal, the WG will perform the following security-related tasks: > > [and then list specific items] > > > > > > * Complete the specification of DHCP for IPv6 (DHCPv6): > > > > - Gain acceptance and publication of current Internet Draft as > > > > Proposed Standard > > > > - Develop and publish specifications for options and other > > > > extensions to DHCPv6, including those already published as > > > > Internet Drafts > > > > > >General comment on options (both IPv4 and IPv6). I'd like the charter > > >to clearly indicate that the DHC WG will be reviewing options to make > > >sure they are consistent with the protocol, other option usages, etc. > > > The charter has a separate bullet item for review of options. Are you > > suggesting that the bullet item be extended to include "consistent with > the > > protocol, other option usages, etc." as specific types of review? > >I think it would be useful to have more specific text that describes >how (and when) options will be reviewed by the WG, and when they will >be taken on by the WG. I.e, something like: > > This WG also is responsible for reviewing (and sometimes > developing) DHC options (for both IPv4 and IPv6). The WG is > expected to review all proposed DHC options to ensure that they are > consistent with the DHC protocol, other option formats, that they > do not duplicate existing options, etc. The WG cannot (generally) > be responsible for evaluating the semantic content of proposed > options. Only subject matter experts for the technology the option > relates to can do so. The DHC WG will not adopt new DHC option > proposals as WG documents without first coordinating with other > relevant WGs and determining who has the responsibility for > reviewing the semantic content of an option. > >I don't have a strong feeling about which WG owns a DHC option >document (when the option is needed by another WG). So long as the two >WGs coordinate, things should work out. But in anycase, the WG should >sign off on all DHC options no later than (and hopefully much sooner >than) IETF LC. But this level of detail can probably be left out of >the charter and dealt with on a case-by-case basis. > > > >Also, I don't like the "other client and relay agent options" as it is > > >too open ended. I think the WG needs a way of vetting potential > > >options before the WG takes them on officially. > > > There are other options currently in the pipeline; this "other ... > options" > > bullet is intended to refer to those options that are "work in > > progress". New work is intended to fall under the following bullet > > item. > >The problem is that once the charter is out, there is no context for >recalling which options were "in the pipeline" when the charter was >written and which are new. Thus, it would probably be better to just >list the IDs that the WG thinks it still has responsbility for. > >Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 22 10:49:25 2002 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 KAA20227; Tue, 22 Oct 2002 10:49:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MEobv18363; Tue, 22 Oct 2002 10:50:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MEnxv18318 for ; Tue, 22 Oct 2002 10:49:59 -0400 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 KAA19918 for ; Tue, 22 Oct 2002 10:47:38 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g9MEnsW13148; Tue, 22 Oct 2002 09:49:54 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9MEnsk12263; Tue, 22 Oct 2002 09:49:54 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PDL6BK>; Tue, 22 Oct 2002 09:49:54 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] DHC WG charter Date: Tue, 22 Oct 2002 09:48:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C279DA.24D3FFE0" 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_01C279DA.24D3FFE0 Content-Type: text/plain; charset="iso-8859-1" Ralph: You guys appear to be doing rather well on your own! The current revised charter at the web site doesn't include any recent changes. Using the discussion between Thomas and you, the charter now looks more like the following? o Complete the specification of DHCP for IPv6 (DHCPv6): - Gain acceptance and publication of the specification as a Proposed Standard by [12/31/2002?] - Encourage independent implementations and report on interoperability testing - Revise the specification and publish for acceptance as Draft Standard by [9/30/2003?] o RFC 3118 defines current security mechanisms for DHCP[v4?]. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. There is widespread feeling that its current restriction to manual keying of clients limits its deployability. It is the goal of this WG to rectify this situation by defining extensions that have better deployability properties. In order to achive this goal, the WG will perform the following security-related tasks: - Develop a threat model and analysis of the authentication protection provided by RFC 3118 - Improve key management and scalability - Develop a means to secure messages passed between relay agents and servers - Develop a means to reduce the threats of DoS attacks through FORCERENEW messages o This WG also is responsible for reviewing (and sometimes developing) DHC options (for both IPv4 and IPv6). The WG is expected to review all proposed DHC options to ensure that they are consistent with the DHC protocol, other option formats, that they do not duplicate existing options, etc. The WG cannot (generally) be responsible for evaluating the semantic content of proposed options. Only subject matter experts for the technology the option relates to can do so. The DHC WG will not adopt new DHC option proposals as WG documents without first coordinating with other relevant WGs and determining who has the responsibility for reviewing the semantic content of an option. o Complete the specification and publish the following work in progress as standards: (We need to include a list of the specific drafts, such as - Failover protocol (draft-ietf-dhc-failover-*.txt) - DHCP/DDNS interaction (draft-ietf-dhc-ddns-resolution-*.txt) - Client FQDN option (draft-ietf-dhc-fqdn-option-*.txt) ... Do we want to include all of those at http://www.dhcp.org/dhcp-ids.html or just a subset? Should we perhaps not even add this item into the list of tasks as the previous item (reviewing DHC options) covers much of this work. We could instead include some of the documents in the Milestones section with planned completion dates. We may need to address non-option related documents separately - such as Failover, SNMP MIB.) o Write an analysis of the DHCP specification, including RFC213, RFC2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Develop a process for resolving identified problems and incorporating the resolutions into the DHCP specification, perhaps by publishing an updated DHCP specification or a clarifying document. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, October 22, 2002 9:19 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] DHC WG charter WG members: We *require* input from WG members regarding the revision of the WG charter. This is *not* a task for just the WG chair and the AD. Please review the current revised charter at http://www.dhcp.org/charter-update.html and contribute to the discussion thread. - Ralph At 04:02 PM 10/21/2002 -0400, Thomas Narten wrote: >Hi Ralph. > > > > > * Develop a threat model and analysis of the authentication > > > > protection provided by RFC3118; specific issues to be addressed > > > > include: > > > > - Improved key management and scalability > > > > > >Sounds here like your already jumping ahead to the requirements for > > >new protocols. I.e., shouldn't this phase be focused on undertstanding > > >limiations of the current mechanisms? Is this just a wording issue? > > > Perhaps it is a wording issue? s/include/might include/ ?? The intended > > purpose for the bullet list is to capture current "common knowledge" about > > the threat model and RFC3118. > >The word "improved" implies to me not analyzing/understanding the >current systems, but jumping to the next steps of what is >needed. Seems like the threat model/analysis should be focused on >understanding the limitations and threats of what we have specified >today. > >Having said that, I don't doubt that improvements are needed. :-) So >this is a wording issue I think. > > > > > - Security for messages passed between relay agents and servers > > > > - Threats of DoS attacks through FORCERENEW > > > > > > > * Develop requirements for any new protocols to address threats or > > > > other enhancement identified by the threat model and analysis of > > > > 3118 > > > > > >What's missing above is a clear statement that this WG will develop > > >new authentication mechanisms that address the deployability problems > > >with the current schemes (whether through an extension to 3118 or > > >something else). Or that it will address the relay-agent to DHC server > > >path. > > > Can you explain this comment in a different way, as it seems to be at > > cross-purposes with your previous comment about "jumping ahead to the > > requirements". I think we're in having a violent agreement that we > want to > > (a) get some DHCP authentication out to the client deployed and common > > wisdom is that the best path is through new mechanisms in the RFC3118 > > framework; and (b) secure communication between the DHCP relay agents and > > servers. > >Maybe what is needed is a context paragraph before the specific >tasks. It could say something like: > > RFC 3118 defines current security mechanisms for DHCP. > Unfortunately, RFC 3118 has neither been implemented nor deployed > to date. There is widespread feeling that its current restriction > to manual keying of clients limits its deployability. It is the > goal of this WG to rectify this situation by defining extensions > that have better deployability properties. In order to achive this > goal, the WG will perform the following security-related tasks: > > [and then list specific items] > > > > > > * Complete the specification of DHCP for IPv6 (DHCPv6): > > > > - Gain acceptance and publication of current Internet Draft as > > > > Proposed Standard > > > > - Develop and publish specifications for options and other > > > > extensions to DHCPv6, including those already published as > > > > Internet Drafts > > > > > >General comment on options (both IPv4 and IPv6). I'd like the charter > > >to clearly indicate that the DHC WG will be reviewing options to make > > >sure they are consistent with the protocol, other option usages, etc. > > > The charter has a separate bullet item for review of options. Are you > > suggesting that the bullet item be extended to include "consistent with > the > > protocol, other option usages, etc." as specific types of review? > >I think it would be useful to have more specific text that describes >how (and when) options will be reviewed by the WG, and when they will >be taken on by the WG. I.e, something like: > > This WG also is responsible for reviewing (and sometimes > developing) DHC options (for both IPv4 and IPv6). The WG is > expected to review all proposed DHC options to ensure that they are > consistent with the DHC protocol, other option formats, that they > do not duplicate existing options, etc. The WG cannot (generally) > be responsible for evaluating the semantic content of proposed > options. Only subject matter experts for the technology the option > relates to can do so. The DHC WG will not adopt new DHC option > proposals as WG documents without first coordinating with other > relevant WGs and determining who has the responsibility for > reviewing the semantic content of an option. > >I don't have a strong feeling about which WG owns a DHC option >document (when the option is needed by another WG). So long as the two >WGs coordinate, things should work out. But in anycase, the WG should >sign off on all DHC options no later than (and hopefully much sooner >than) IETF LC. But this level of detail can probably be left out of >the charter and dealt with on a case-by-case basis. > > > >Also, I don't like the "other client and relay agent options" as it is > > >too open ended. I think the WG needs a way of vetting potential > > >options before the WG takes them on officially. > > > There are other options currently in the pipeline; this "other ... > options" > > bullet is intended to refer to those options that are "work in > > progress". New work is intended to fall under the following bullet > > item. > >The problem is that once the charter is out, there is no context for >recalling which options were "in the pipeline" when the charter was >written and which are new. Thus, it would probably be better to just >list the IDs that the WG thinks it still has responsbility for. > >Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C279DA.24D3FFE0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] DHC WG charter

Ralph:

You guys appear to be doing rather well on your own!

The current revised charter at the web site doesn't include any
recent changes. Using the discussion between Thomas and you, the
charter now looks more like the following?

o  Complete the specification of DHCP for IPv6 (DHCPv6):
   - Gain acceptance and publication of the specification as a
     Proposed Standard by [12/31/2002?]
   - Encourage independent implementations and report on
     interoperability testing
   - Revise the specification and publish for acceptance as Draft
     Standard by [9/30/2003?]
o  RFC 3118 defines current security mechanisms for DHCP[v4?].
   Unfortunately, RFC 3118 has neither been implemented nor deployed
   to date. There is widespread feeling that its current restriction
   to manual keying of clients limits its deployability. It is the
   goal of this WG to rectify this situation by defining extensions
   that have better deployability properties. In order to achive this
   goal, the WG will perform the following security-related tasks:
   - Develop a threat model and analysis of the authentication
     protection provided by RFC 3118
   - Improve key management and scalability
   - Develop a means to secure messages passed between relay agents
     and servers
   - Develop a means to reduce the threats of DoS attacks through
     FORCERENEW messages
o  This WG also is responsible for reviewing (and sometimes
   developing) DHC options (for both IPv4 and IPv6). The WG is
   expected to review all proposed DHC options to ensure that they are
   consistent with the DHC protocol, other option formats, that they
   do not duplicate existing options, etc.  The WG cannot (generally)
   be responsible for evaluating the semantic content of proposed
   options. Only subject matter experts for the technology the option
   relates to can do so. The DHC WG will not adopt new DHC option
   proposals as WG documents without first coordinating with other
   relevant WGs and determining who has the responsibility for
   reviewing the semantic content of an option.
o  Complete the specification and publish the following work in progress
   as standards:
   (We need to include a list of the specific drafts, such as
   - Failover protocol (draft-ietf-dhc-failover-*.txt)
   - DHCP/DDNS interaction (draft-ietf-dhc-ddns-resolution-*.txt)
   - Client FQDN option (draft-ietf-dhc-fqdn-option-*.txt)
   ...
   Do we want to include all of those at http://www.dhcp.org/dhcp-ids.html
   or just a subset? Should we perhaps not even add this item into
   the list of tasks as the previous item (reviewing DHC options)
   covers much of this work. We could instead include some of the
   documents in the Milestones section with planned completion
   dates. We may need to address non-option related documents
   separately - such as Failover, SNMP MIB.)
o  Write an analysis of the DHCP specification, including RFC213,
   RFC2132 and other RFCs defining additional options, which
   identifies ambiguities, contradictory specifications and other
   obstacles to development of interoperable implementations.
   Develop a process for resolving identified problems and
   incorporating the resolutions into the DHCP specification,
   perhaps by publishing an updated DHCP specification or a
   clarifying document.

- Bernie


-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, October 22, 2002 9:19 AM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] DHC WG charter


WG members:

We *require* input from WG members regarding the revision of the WG
charter.  This is *not* a task for just the WG chair and the AD.

Please review the current revised charter at
http://www.dhcp.org/charter-update.html and contribute to the discussion
thread.

- Ralph

At 04:02 PM 10/21/2002 -0400, Thomas Narten wrote:
>Hi Ralph.
>
> > > > * Develop a threat model and analysis of the authentication
> > > >    protection provided by RFC3118; specific issues to be addressed
> > > >    include:
> > > >    - Improved key management and scalability
> > >
> > >Sounds here like your already jumping ahead to the requirements for
> > >new protocols. I.e., shouldn't this phase be focused on undertstanding
> > >limiations of the current mechanisms? Is this just a wording issue?
>
> > Perhaps it is a wording issue?  s/include/might include/ ??  The intended
> > purpose for the bullet list is to capture current "common knowledge" about
> > the threat model and RFC3118.
>
>The word "improved" implies to me not analyzing/understanding the
>current systems, but jumping to the next steps of what is
>needed. Seems like the threat model/analysis should be focused on
>understanding the limitations and threats of what we have specified
>today.
>
>Having said that, I don't doubt that improvements are needed. :-) So
>this is a wording issue I think.
>
> > > >    - Security for messages passed between relay agents and servers
> > > >    - Threats of DoS attacks through FORCERENEW
> > >
> > > > * Develop requirements for any new protocols to address threats or
> > > >    other enhancement identified by the threat model and analysis of
> > > >    3118
> > >
> > >What's missing above is a clear statement that this WG will develop
> > >new authentication mechanisms that address the deployability problems
> > >with the current schemes (whether through an extension to 3118 or
> > >something else). Or that it will address the relay-agent to DHC server
> > >path.
>
> > Can you explain this comment in a different way, as it seems to be at
> > cross-purposes with your previous comment about "jumping ahead to the
> > requirements".  I think we're in having a violent agreement that we
> want to
> > (a) get some DHCP authentication out to the client deployed and common
> > wisdom is that the best path is through new mechanisms in the RFC3118
> > framework; and (b) secure communication between the DHCP relay agents and
> > servers.
>
>Maybe what is needed is a context paragraph before the specific
>tasks. It could say something like:
>
>    RFC 3118 defines current security mechanisms for DHCP.
>    Unfortunately, RFC 3118 has neither been implemented nor deployed
>    to date. There is widespread feeling that its current restriction
>    to manual keying of clients limits its deployability. It is the
>    goal of this WG to rectify this situation by defining extensions
>    that have better deployability properties. In order to achive this
>    goal, the WG will perform the following security-related tasks:
>
>    [and then list specific items]
>
>
> > > > * Complete the specification of DHCP for IPv6 (DHCPv6):
> > > >    - Gain acceptance and publication of current Internet Draft as
> > > >      Proposed Standard
> > > >    - Develop and publish specifications for options and other
> > > >      extensions to DHCPv6, including those already published as
> > > >      Internet Drafts
> > >
> > >General comment on options (both IPv4 and IPv6). I'd like the charter
> > >to clearly indicate that the DHC WG will be reviewing options to make
> > >sure they are  consistent with the protocol, other option usages, etc.
>
> > The charter has a separate bullet item for review of options.  Are you
> > suggesting that the bullet item be extended to include "consistent with
> the
> > protocol, other option usages, etc." as specific types of review?
>
>I think it would be useful to have more specific text that describes
>how (and when) options will be reviewed by the WG, and when they will
>be taken on by the WG. I.e, something like:
>
>    This WG also is responsible for reviewing (and sometimes
>    developing) DHC options (for both IPv4 and IPv6). The WG is
>    expected to review all proposed DHC options to ensure that they are
>    consistent with the DHC protocol, other option formats, that they
>    do not duplicate existing options, etc.  The WG cannot (generally)
>    be responsible for evaluating the semantic content of proposed
>    options. Only subject matter experts for the technology the option
>    relates to can do so. The DHC WG will not adopt new DHC option
>    proposals as WG documents without first coordinating with other
>    relevant WGs and determining who has the responsibility for
>    reviewing the semantic content of an option.
>
>I don't have a strong feeling about which WG owns a DHC option
>document (when the option is needed by another WG). So long as the two
>WGs coordinate, things should work out. But in anycase, the WG should
>sign off on all DHC options no later than (and hopefully much sooner
>than) IETF LC. But this level of detail can probably be left out of
>the charter and dealt with on a case-by-case basis.
>
> > >Also, I don't like the "other client and relay agent options" as it is
> > >too open ended. I think the WG needs a way of vetting potential
> > >options before the WG takes them on officially.
>
> > There are other options currently in the pipeline; this "other ...
> options"
> > bullet is intended to refer to those options that are "work in
> > progress".  New work is intended to fall under the following bullet
> > item.
>
>The problem is that once the charter is out, there is no context for
>recalling which options were "in the pipeline" when the charter was
>written and which are new. Thus, it would probably be better to just
>list the IDs that the WG thinks it still has responsbility for.
>
>Thomas

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

------_=_NextPart_001_01C279DA.24D3FFE0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 22 11:07:46 2002 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 LAA21015; Tue, 22 Oct 2002 11:07:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MF98v19534; Tue, 22 Oct 2002 11:09:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MF8Zv19505 for ; Tue, 22 Oct 2002 11:08:35 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20940 for ; Tue, 22 Oct 2002 11:06:15 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-128-107-133-128.cisco.com [128.107.133.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA18449 for ; Tue, 22 Oct 2002 11:08:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20021022110632.00b8d320@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Oct 2002 11:08:26 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] DHC WG charter 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: , WG members - while I appreciate Bernie's encouragement, we *need* more diversity of opinion to form a healthy, effective charter. *Please* speak up. Bernie - I hadn't updated the charter, waiting (hoping) for additional WG input to minimize editing thrash. I will upload your text into the web site when I get a chance (some time today). - Ralph At 09:48 AM 10/22/2002 -0500, Bernie Volz (EUD) wrote: >Ralph: > >You guys appear to be doing rather well on your own! > >The current revised charter at the web site doesn't include any >recent changes. Using the discussion between Thomas and you, the >charter now looks more like the following? > >o Complete the specification of DHCP for IPv6 (DHCPv6): > - Gain acceptance and publication of the specification as a > Proposed Standard by [12/31/2002?] > - Encourage independent implementations and report on > interoperability testing > - Revise the specification and publish for acceptance as Draft > Standard by [9/30/2003?] >o RFC 3118 defines current security mechanisms for DHCP[v4?]. > Unfortunately, RFC 3118 has neither been implemented nor deployed > to date. There is widespread feeling that its current restriction > to manual keying of clients limits its deployability. It is the > goal of this WG to rectify this situation by defining extensions > that have better deployability properties. In order to achive this > goal, the WG will perform the following security-related tasks: > - Develop a threat model and analysis of the authentication > protection provided by RFC 3118 > - Improve key management and scalability > - Develop a means to secure messages passed between relay agents > and servers > - Develop a means to reduce the threats of DoS attacks through > FORCERENEW messages >o This WG also is responsible for reviewing (and sometimes > developing) DHC options (for both IPv4 and IPv6). The WG is > expected to review all proposed DHC options to ensure that they are > consistent with the DHC protocol, other option formats, that they > do not duplicate existing options, etc. The WG cannot (generally) > be responsible for evaluating the semantic content of proposed > options. Only subject matter experts for the technology the option > relates to can do so. The DHC WG will not adopt new DHC option > proposals as WG documents without first coordinating with other > relevant WGs and determining who has the responsibility for > reviewing the semantic content of an option. >o Complete the specification and publish the following work in progress > as standards: > (We need to include a list of the specific drafts, such as > - Failover protocol (draft-ietf-dhc-failover-*.txt) > - DHCP/DDNS interaction (draft-ietf-dhc-ddns-resolution-*.txt) > - Client FQDN option (draft-ietf-dhc-fqdn-option-*.txt) > ... > Do we want to include all of those at > http://www.dhcp.org/dhcp-ids.html > or just a subset? Should we perhaps not even add this item into > the list of tasks as the previous item (reviewing DHC options) > covers much of this work. We could instead include some of the > documents in the Milestones section with planned completion > dates. We may need to address non-option related documents > separately - such as Failover, SNMP MIB.) >o Write an analysis of the DHCP specification, including RFC213, > RFC2132 and other RFCs defining additional options, which > identifies ambiguities, contradictory specifications and other > obstacles to development of interoperable implementations. > Develop a process for resolving identified problems and > incorporating the resolutions into the DHCP specification, > perhaps by publishing an updated DHCP specification or a > clarifying document. > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Tuesday, October 22, 2002 9:19 AM >To: dhcwg@ietf.org >Subject: Re: [dhcwg] DHC WG charter > >WG members: > >We *require* input from WG members regarding the revision of the WG >charter. This is *not* a task for just the WG chair and the AD. > >Please review the current revised charter at >http://www.dhcp.org/charter-update.html >and contribute to the discussion >thread. > >- Ralph > >At 04:02 PM 10/21/2002 -0400, Thomas Narten wrote: > >Hi Ralph. > > > > > > > * Develop a threat model and analysis of the authentication > > > > > protection provided by RFC3118; specific issues to be addressed > > > > > include: > > > > > - Improved key management and scalability > > > > > > > >Sounds here like your already jumping ahead to the requirements for > > > >new protocols. I.e., shouldn't this phase be focused on undertstanding > > > >limiations of the current mechanisms? Is this just a wording issue? > > > > > Perhaps it is a wording issue? s/include/might include/ ?? The > intended > > > purpose for the bullet list is to capture current "common knowledge" > about > > > the threat model and RFC3118. > > > >The word "improved" implies to me not analyzing/understanding the > >current systems, but jumping to the next steps of what is > >needed. Seems like the threat model/analysis should be focused on > >understanding the limitations and threats of what we have specified > >today. > > > >Having said that, I don't doubt that improvements are needed. :-) So > >this is a wording issue I think. > > > > > > > - Security for messages passed between relay agents and servers > > > > > - Threats of DoS attacks through FORCERENEW > > > > > > > > > * Develop requirements for any new protocols to address threats or > > > > > other enhancement identified by the threat model and analysis of > > > > > 3118 > > > > > > > >What's missing above is a clear statement that this WG will develop > > > >new authentication mechanisms that address the deployability problems > > > >with the current schemes (whether through an extension to 3118 or > > > >something else). Or that it will address the relay-agent to DHC server > > > >path. > > > > > Can you explain this comment in a different way, as it seems to be at > > > cross-purposes with your previous comment about "jumping ahead to the > > > requirements". I think we're in having a violent agreement that we > > want to > > > (a) get some DHCP authentication out to the client deployed and common > > > wisdom is that the best path is through new mechanisms in the RFC3118 > > > framework; and (b) secure communication between the DHCP relay agents > and > > > servers. > > > >Maybe what is needed is a context paragraph before the specific > >tasks. It could say something like: > > > > RFC 3118 defines current security mechanisms for DHCP. > > Unfortunately, RFC 3118 has neither been implemented nor deployed > > to date. There is widespread feeling that its current restriction > > to manual keying of clients limits its deployability. It is the > > goal of this WG to rectify this situation by defining extensions > > that have better deployability properties. In order to achive this > > goal, the WG will perform the following security-related tasks: > > > > [and then list specific items] > > > > > > > > > * Complete the specification of DHCP for IPv6 (DHCPv6): > > > > > - Gain acceptance and publication of current Internet Draft as > > > > > Proposed Standard > > > > > - Develop and publish specifications for options and other > > > > > extensions to DHCPv6, including those already published as > > > > > Internet Drafts > > > > > > > >General comment on options (both IPv4 and IPv6). I'd like the charter > > > >to clearly indicate that the DHC WG will be reviewing options to make > > > >sure they are consistent with the protocol, other option usages, etc. > > > > > The charter has a separate bullet item for review of options. Are you > > > suggesting that the bullet item be extended to include "consistent with > > the > > > protocol, other option usages, etc." as specific types of review? > > > >I think it would be useful to have more specific text that describes > >how (and when) options will be reviewed by the WG, and when they will > >be taken on by the WG. I.e, something like: > > > > This WG also is responsible for reviewing (and sometimes > > developing) DHC options (for both IPv4 and IPv6). The WG is > > expected to review all proposed DHC options to ensure that they are > > consistent with the DHC protocol, other option formats, that they > > do not duplicate existing options, etc. The WG cannot (generally) > > be responsible for evaluating the semantic content of proposed > > options. Only subject matter experts for the technology the option > > relates to can do so. The DHC WG will not adopt new DHC option > > proposals as WG documents without first coordinating with other > > relevant WGs and determining who has the responsibility for > > reviewing the semantic content of an option. > > > >I don't have a strong feeling about which WG owns a DHC option > >document (when the option is needed by another WG). So long as the two > >WGs coordinate, things should work out. But in anycase, the WG should > >sign off on all DHC options no later than (and hopefully much sooner > >than) IETF LC. But this level of detail can probably be left out of > >the charter and dealt with on a case-by-case basis. > > > > > >Also, I don't like the "other client and relay agent options" as it is > > > >too open ended. I think the WG needs a way of vetting potential > > > >options before the WG takes them on officially. > > > > > There are other options currently in the pipeline; this "other ... > > options" > > > bullet is intended to refer to those options that are "work in > > > progress". New work is intended to fall under the following bullet > > > item. > > > >The problem is that once the charter is out, there is no context for > >recalling which options were "in the pipeline" when the charter was > >written and which are new. Thus, it would probably be better to just > >list the IDs that the WG thinks it still has responsbility for. > > > >Thomas > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 22 11:10:42 2002 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 LAA21160; Tue, 22 Oct 2002 11:10:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MFC2v19687; Tue, 22 Oct 2002 11:12:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MFB9v19635 for ; Tue, 22 Oct 2002 11:11:09 -0400 Received: from zmamail04.zma.compaq.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21079 for ; Tue, 22 Oct 2002 11:08:48 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 17FBF4255; Tue, 22 Oct 2002 11:11:04 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 22 Oct 2002 11:11:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [dhcwg] DHC WG charter Date: Tue, 22 Oct 2002 11:11:00 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE962E@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] DHC WG charter Thread-Index: AcJ50GiYMxsiBcajR3eNZG7No2f68wADKjZQ From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 22 Oct 2002 15:11:03.0714 (UTC) FILETIME=[3CF3D020:01C279DD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9MFB9v19636 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 Ralph, This looks good. I must have missed it but I don't see prefix delegation? Is that within the options? Or do we move that to IPv6 WG? This is very important work required. Thanks /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Tuesday, October 22, 2002 9:19 AM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] DHC WG charter > > > WG members: > > We *require* input from WG members regarding the revision of the WG > charter. This is *not* a task for just the WG chair and the AD. > > Please review the current revised charter at > http://www.dhcp.org/charter-update.html and contribute to the > discussion > thread. > > - Ralph > > At 04:02 PM 10/21/2002 -0400, Thomas Narten wrote: > >Hi Ralph. > > > > > > > * Develop a threat model and analysis of the authentication > > > > > protection provided by RFC3118; specific issues to > be addressed > > > > > include: > > > > > - Improved key management and scalability > > > > > > > >Sounds here like your already jumping ahead to the > requirements for > > > >new protocols. I.e., shouldn't this phase be focused on > > > >undertstanding limiations of the current mechanisms? Is > this just a > > > >wording issue? > > > > > Perhaps it is a wording issue? s/include/might include/ ?? The > > > intended purpose for the bullet list is to capture > current "common > > > knowledge" about the threat model and RFC3118. > > > >The word "improved" implies to me not analyzing/understanding the > >current systems, but jumping to the next steps of what is > needed. Seems > >like the threat model/analysis should be focused on > understanding the > >limitations and threats of what we have specified today. > > > >Having said that, I don't doubt that improvements are needed. :-) So > >this is a wording issue I think. > > > > > > > - Security for messages passed between relay > agents and servers > > > > > - Threats of DoS attacks through FORCERENEW > > > > > > > > > * Develop requirements for any new protocols to > address threats or > > > > > other enhancement identified by the threat model > and analysis of > > > > > 3118 > > > > > > > >What's missing above is a clear statement that this WG > will develop > > > >new authentication mechanisms that address the deployability > > > >problems with the current schemes (whether through an > extension to > > > >3118 or something else). Or that it will address the > relay-agent to > > > >DHC server path. > > > > > Can you explain this comment in a different way, as it > seems to be > > > at cross-purposes with your previous comment about > "jumping ahead to > > > the requirements". I think we're in having a violent > agreement that > > > we > > want to > > > (a) get some DHCP authentication out to the client deployed and > > > common wisdom is that the best path is through new > mechanisms in the > > > RFC3118 framework; and (b) secure communication between the DHCP > > > relay agents and servers. > > > >Maybe what is needed is a context paragraph before the > specific tasks. > >It could say something like: > > > > RFC 3118 defines current security mechanisms for DHCP. > > Unfortunately, RFC 3118 has neither been implemented nor deployed > > to date. There is widespread feeling that its current restriction > > to manual keying of clients limits its deployability. It is the > > goal of this WG to rectify this situation by defining extensions > > that have better deployability properties. In order to > achive this > > goal, the WG will perform the following security-related tasks: > > > > [and then list specific items] > > > > > > > > > * Complete the specification of DHCP for IPv6 (DHCPv6): > > > > > - Gain acceptance and publication of current > Internet Draft as > > > > > Proposed Standard > > > > > - Develop and publish specifications for options and other > > > > > extensions to DHCPv6, including those already > published as > > > > > Internet Drafts > > > > > > > >General comment on options (both IPv4 and IPv6). I'd like the > > > >charter to clearly indicate that the DHC WG will be reviewing > > > >options to make sure they are consistent with the > protocol, other > > > >option usages, etc. > > > > > The charter has a separate bullet item for review of > options. Are > > > you suggesting that the bullet item be extended to include > > > "consistent with > > the > > > protocol, other option usages, etc." as specific types of review? > > > >I think it would be useful to have more specific text that describes > >how (and when) options will be reviewed by the WG, and when > they will > >be taken on by the WG. I.e, something like: > > > > This WG also is responsible for reviewing (and sometimes > > developing) DHC options (for both IPv4 and IPv6). The WG is > > expected to review all proposed DHC options to ensure > that they are > > consistent with the DHC protocol, other option formats, that they > > do not duplicate existing options, etc. The WG cannot > (generally) > > be responsible for evaluating the semantic content of proposed > > options. Only subject matter experts for the technology > the option > > relates to can do so. The DHC WG will not adopt new DHC option > > proposals as WG documents without first coordinating with other > > relevant WGs and determining who has the responsibility for > > reviewing the semantic content of an option. > > > >I don't have a strong feeling about which WG owns a DHC > option document > >(when the option is needed by another WG). So long as the two WGs > >coordinate, things should work out. But in anycase, the WG > should sign > >off on all DHC options no later than (and hopefully much sooner > >than) IETF LC. But this level of detail can probably be left > out of the > >charter and dealt with on a case-by-case basis. > > > > > >Also, I don't like the "other client and relay agent > options" as it > > > >is too open ended. I think the WG needs a way of vetting > potential > > > >options before the WG takes them on officially. > > > > > There are other options currently in the pipeline; this "other ... > > options" > > > bullet is intended to refer to those options that are "work in > > > progress". New work is intended to fall under the > following bullet > > > item. > > > >The problem is that once the charter is out, there is no context for > >recalling which options were "in the pipeline" when the charter was > >written and which are new. Thus, it would probably be better to just > >list the IDs that the WG thinks it still has responsbility for. > > > >Thomas > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 22 12:00:06 2002 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 MAA23733; Tue, 22 Oct 2002 12:00:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MG0fv22112; Tue, 22 Oct 2002 12:00:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MFwPv22003 for ; Tue, 22 Oct 2002 11:58:25 -0400 Received: from e4.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23552 for ; Tue, 22 Oct 2002 11:56:04 -0400 (EDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9MFwHaZ083974; Tue, 22 Oct 2002 11:58:17 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9MFwEUd061362; Tue, 22 Oct 2002 11:58:14 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g9MFtYP31452; Tue, 22 Oct 2002 11:55:34 -0400 Message-Id: <200210221555.g9MFtYP31452@rotala.raleigh.ibm.com> To: Jean-Francois Mule cc: Matt Osman , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt In-Reply-To: Message from Jean-Francois Mule of "Tue, 15 Oct 2002 07:24:52 MDT." <4DF5E8A771ECD21187020008C7B1C5AF03CED81C@srvmail.cablelabs.com> Date: Tue, 22 Oct 2002 11:55:34 -0400 From: Thomas Narten 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: , Jean-Francois Mule writes: > Fully agree with the "IETF Consensus" approach. > My concern is we should be able to choose a temporary or > experimental sub-option code to get implementations going & > interoperability testing started. Nothing "cast in stone" and upon > IETF review and comments, we will issue Engineering Change Requests > to modify our specs as appropriate. What would be your best > recommendation so that we can achieve our short-term goals to get > implementations going for interop purposes while allowing IETF > Consensus? Have you considered the approach outlined in draft-narten-iana-experimental-allocations-01.txt? Reserving one or two values out of the option would seem sufficent. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 22 12:17:52 2002 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 MAA24559; Tue, 22 Oct 2002 12:17:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MGJDv23771; Tue, 22 Oct 2002 12:19:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MGIQv23696 for ; Tue, 22 Oct 2002 12:18:26 -0400 Received: from e32.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24486 for ; Tue, 22 Oct 2002 12:16:04 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9MGI9ol027192; Tue, 22 Oct 2002 12:18:09 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9MGI8lJ104850; Tue, 22 Oct 2002 10:18:08 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g9MGFR831663; Tue, 22 Oct 2002 12:15:27 -0400 Message-Id: <200210221615.g9MGFR831663@rotala.raleigh.ibm.com> To: Paul Duffy cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt In-Reply-To: Message from Paul Duffy of "Wed, 16 Oct 2002 15:26:10 EDT." <4.3.2.7.2.20021016112408.02a0a348@funnel.cisco.com> Date: Tue, 22 Oct 2002 12:15:27 -0400 From: Thomas Narten 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 Duffy writes: > RFC 2131 Section 4.4.1 "The time over which the client collects > messages and the mechanism used to select one DHCPOFFER are > implementation dependent". PacketCable does not feel CCC.1/.2 in > any way modifies the RFC. OK, I think we're OK then. What would be good is if the words in the document communicated clearly what is going on (at a high-level) so its clear how the option is used (at a high-level) and that the usage is consistent with the DHC specs. > > > Due to specific needs of the MTA configuration process (described in > > > [5]), a new CableLabs Client Configuration (CCC) option is needed for > > > the DHCP protocol. Both CM and MTA DHCP clients will request this > > > option. When requested, both the CM and TSP DHCP servers will > > > populate this option into DHCP responses. > > > > > >Doesn't the client also provide this option and fill in some info? > >better to say this above (one or two sentences here would suffice). Or > >maybe just merge Section 9 text into the text here. > No, an MTA DHCP client never populates CCC option content into its any if > its requests. The PacketCable MTA provisioning specification (section 7) > contains detailed descriptions of when the CCC option is/is not populated > into DHCP messaging. > PacketCable's intent is to specify option syntax in the draft/RFC, while > referring to the PacketCable MTA prov specification for usage > details. Otherwise, we're going to end up pulling large pieces of the > PacketCable provisioning spec into this draft...lots of duplication between > the documents (which I thought we agreed was undesirable). Right. > That said, I can add a sentence or two stating that the client never > populates CCC option content into DHCP request messages. This is all I'm asking for. So that at a high-level one can understand what is going on. The details can be elsewhere. > >Should this document add a normative references to > >draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so > >referencing it shouldn't be a problem)? Seems like that would make > >sense. > If you feel inclusion of this draft is a hard requirement, PacketCable will > have to open this issue with the manufacturers...further delaying the > progress of this draft (not good for us). I'm also going to need an RFC # > for the ref ? Note: dhc-concat has been approved by the IESG, so this document doesn't need to wait for it. The question is, should this document require the other as well? Seems to me like that might be useful. Hence, I asked. > >The CCC options for configuring Kerberos parameters seems odd to me > >(what kerberos document talks about the need for tuning these > >parameters?). The IESG may want this reviewed by someone with kerberos > >clue. (I'm just saying this so that there are no surprises should this > >issue come up later.) > This is a specific need of a PacketCable MTA. It does not present any > issues with the Kerberos RFCs. The CCC option is, by definition, Cablelabs > specific, so PacketCable does not see this causing any issues with non > Cablelabs devices. If there are no issues with the kerberos RFCs, why do you need an option to tune how they behave? In terms of how to proceed, you might consider posting proposed text for each of the items prior to reissuing the draft. That way, you're more likely to get quick review of the new wording and that might save on the need for an additional revision. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 22 15:26:10 2002 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 PAA01372; Tue, 22 Oct 2002 15:26:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MJRVv01420; Tue, 22 Oct 2002 15:27:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9MJQuv01382 for ; Tue, 22 Oct 2002 15:26:56 -0400 Received: from e6.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01354 for ; Tue, 22 Oct 2002 15:24:34 -0400 (EDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9MJQgUF265268; Tue, 22 Oct 2002 15:26:42 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9MJQdUd066190; Tue, 22 Oct 2002 15:26:40 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g9MJNxk01087; Tue, 22 Oct 2002 15:23:59 -0400 Message-Id: <200210221923.g9MJNxk01087@rotala.raleigh.ibm.com> To: "Bound, Jim" cc: "Ralph Droms" , dhcwg@ietf.org Subject: Re: [dhcwg] DHC WG charter In-Reply-To: Message from "Bound, Jim" of "Tue, 22 Oct 2002 11:11:00 EDT." <9C422444DE99BC46B3AD3C6EAFC9711B02BE962E@tayexc13.americas.cpqcorp.net> Date: Tue, 22 Oct 2002 15:23:59 -0400 From: Thomas Narten 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 looks good. I must have missed it but I don't see prefix > delegation? Is that within the options? Or do we move that to IPv6 > WG? This is very important work required. I agree that it is important work. In practice it needs to be joint between IPv6 and DHC. I don't have strong opinions on whether it is more appropriate to list it as a DHC item vs. one in the IPv6 WG. I believe *they* believe they should own it. :-) Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 22 21:14:54 2002 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 VAA10377; Tue, 22 Oct 2002 21:14:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N1G5v17978; Tue, 22 Oct 2002 21:16:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N1CDv17785 for ; Tue, 22 Oct 2002 21:12:13 -0400 Received: from zmamail05.zma.compaq.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10152 for ; Tue, 22 Oct 2002 21:09:49 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 35DDBB85; Tue, 22 Oct 2002 21:12:05 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 22 Oct 2002 21:12:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [dhcwg] DHC WG charter Date: Tue, 22 Oct 2002 21:12:04 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9640@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] DHC WG charter Thread-Index: AcJ6Dxj24GGLHbvZTo+x7Q5clFaBPwAIcYPQ From: "Bound, Jim" To: "Thomas Narten" Cc: "Ralph Droms" , X-OriginalArrivalTime: 23 Oct 2002 01:12:05.0052 (UTC) FILETIME=[332F4FC0:01C27A31] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9N1CDv17786 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 I am not sure either. But it is important. If we state the problem we are trying to solve, the ways dhc could solve it, and then ????? Would that work. We can always get IPv6 people as subject matter experts too. There is something more to do above for the charter but not sure what else. Thanks /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Tuesday, October 22, 2002 3:24 PM > To: Bound, Jim > Cc: Ralph Droms; dhcwg@ietf.org > Subject: Re: [dhcwg] DHC WG charter > > > > This looks good. I must have missed it but I don't see prefix > > delegation? Is that within the options? Or do we move > that to IPv6 > > WG? This is very important work required. > > I agree that it is important work. > > In practice it needs to be joint between IPv6 and DHC. I > don't have strong opinions on whether it is more appropriate > to list it as a DHC item vs. one in the IPv6 WG. I believe > *they* believe they should own it. :-) > > Thomas > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 22 22:43:05 2002 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 WAA13117; Tue, 22 Oct 2002 22:43:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N2iUv22902; Tue, 22 Oct 2002 22:44:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N2h4v22847 for ; Tue, 22 Oct 2002 22:43:04 -0400 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 WAA13036 for ; Tue, 22 Oct 2002 22:40:38 -0400 (EDT) Received: from nominum.com (az-ben-pm3-2-32.ppp.theriver.com [206.25.50.32]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g9N2fL222976; Tue, 22 Oct 2002 21:41:22 -0500 (CDT) Date: Tue, 22 Oct 2002 19:42:54 -0700 Subject: Re: [dhcwg] DHC WG charter Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: dhcwg@ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20021022110632.00b8d320@funnel.cisco.com> Message-Id: <21D3E6AE-E631-11D6-A979-003065D63CF6@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 think the tasks before us are: - Advance DHCPv6 - Define a deployable DHCP security protocol. - Get the DNS drafts finished - Advance the other drafts that are currently under consideration, or drop them. I.e., I don't have any real argument with your suggestions. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 22 22:43:36 2002 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 WAA13161; Tue, 22 Oct 2002 22:43:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N2j5v22948; Tue, 22 Oct 2002 22:45:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9N2iEv22891 for ; Tue, 22 Oct 2002 22:44:14 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13106 for ; Tue, 22 Oct 2002 22:41:48 -0400 (EDT) Received: from paduffy-w2k.cisco.com (che-vpn1-42.cisco.com [10.86.240.42]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA13239; Tue, 22 Oct 2002 22:43:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20021022180633.04fd38a8@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Oct 2002 22:43:58 -0400 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt Cc: dhcwg@ietf.org In-Reply-To: <200210221615.g9MGFR831663@rotala.raleigh.ibm.com> References: <4.3.2.7.2.20021016112408.02a0a348@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thomas, Inline please... > > >Should this document add a normative references to > > >draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so > > >referencing it shouldn't be a problem)? Seems like that would make > > >sense. > > > If you feel inclusion of this draft is a hard requirement, PacketCable > will > > have to open this issue with the manufacturers...further delaying the > > progress of this draft (not good for us). I'm also going to need an RFC # > > for the ref ? > >Note: dhc-concat has been approved by the IESG, so this document >doesn't need to wait for it. > >The question is, should this document require the other as well? Seems >to me like that might be useful. Hence, I asked. I assume you mean "should the CCC option require concat". We're discussing this at PacketCable. > > >The CCC options for configuring Kerberos parameters seems odd to me > > >(what kerberos document talks about the need for tuning these > > >parameters?). The IESG may want this reviewed by someone with kerberos > > >clue. (I'm just saying this so that there are no surprises should this > > >issue come up later.) > > > This is a specific need of a PacketCable MTA. It does not present any > > issues with the Kerberos RFCs. The CCC option is, by definition, > Cablelabs > > specific, so PacketCable does not see this causing any issues with non > > Cablelabs devices. > >If there are no issues with the kerberos RFCs, why do you need an >option to tune how they behave? Several comments from various PacketCable team members: "Kerberos-5 protocol (RFC-1510) does not define any specific backoff and retry algorithm. Consequently, all specifics of the backoff and retry mechanism for AS- and AP-exchange are defined by the PacketCable security spec, and involves the parameters supplied by the DHCP Server to parameterize the Kerberos Authentication for Provisioning Service." Further... "None of the subsequent IETF drafts such as Kerberos clarifications define it either - I don't think that a specific retry mechanism was ever considered to be in scope of the Kerberos IETF working group." Thus the need for the sub-options. >In terms of how to proceed, you might consider posting proposed text >for each of the items prior to reissuing the draft. Cheers, -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 23 14:25:46 2002 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 OAA28560; Wed, 23 Oct 2002 14:25:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NIR3v15630; Wed, 23 Oct 2002 14:27:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NIPkv15559 for ; Wed, 23 Oct 2002 14:25:46 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28359 for ; Wed, 23 Oct 2002 14:23:25 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-171-71-57-14.cisco.com [171.71.57.14]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12436 for ; Wed, 23 Oct 2002 14:25:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20021023142414.00b65bd8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Oct 2002 14:25:35 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] DHC WG charter In-Reply-To: <21D3E6AE-E631-11D6-A979-003065D63CF6@nominum.com> References: <4.3.2.7.2.20021022110632.00b8d320@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here's a revised charter, based on input from mailing list discussion (this charter also available at http://www.dhcp.org/charter-update.html); comments or acknowledgments (this looks OK) strongly encouraged... Dynamic Host Configuration (dhc) The dhc working group (DHCWG) 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 document in RFC2131 and RFC2132. Additional options are documented in a series of RFCs (see http://www.dhcp.org/rfcs.html). The working group now has four main objectives: * RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. There is widespread feeling that its current restriction to manual keying of clients limits its deployability. It is the goal of DHCWG to rectify this situation by defining extensions that have better deployability properties. In order to achive this goal, DHCWG will develop a threat model and analysis of the authentication protection provided by RFC3118; specific issues to be addressed might include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through FORCERENEW * Develop requirements for any new protocols to address threats or other enhancement identified by the threat model and analysis of 3118 * Complete the specification of DHCP for IPv6 (DHCPv6): - Gain acceptance and publication of current Internet Draft as Proposed Standard - Complete or terminate work on published DHCPv6 options: IPv6 Prefix Options for DHCPv6 DSTM Options for DHCP DSTM Ports Option 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 - Encourage independent implementations and report on interoperability testing * Complete or terminate work on DHCP extensions and new options that are currently work in progress: - Failover protocol - DHCP/DDNS interaction - DHCP Server MIB - Host name options (Smith/Lemon?) - DHCP Leasequery - DHCP Option for CableLabs Client Configuration - KDC Server Address Sub-option - DHCP Options for Internet Storage name Service - The Authentication Suboption for the DHCP Relay Agent Option - Link Selection sub-option for the Relay Agent Information Option - DHCP VPN Information Option - VPN Identifier sub-option for the Relay Agent Information Option - RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option * DHCWG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). DHCWG 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. DHCWG will not (generally) be responsible for evaluating the semantic content of proposed options. DHCWG 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. * 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. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 23 15:38:26 2002 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 PAA02637; Wed, 23 Oct 2002 15:38:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NJdVv19973; Wed, 23 Oct 2002 15:39:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NJcGv19927 for ; Wed, 23 Oct 2002 15:38:16 -0400 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 PAA02384 for ; Wed, 23 Oct 2002 15:35:52 -0400 (EDT) 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 g9NJc8d01022; Wed, 23 Oct 2002 14:38:08 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9NJc8c04561; Wed, 23 Oct 2002 14:38:08 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PBC7RP>; Wed, 23 Oct 2002 14:38:08 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] DHC WG charter Date: Wed, 23 Oct 2002 14:37:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27ACB.9393687A" 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_01C27ACB.9393687A Content-Type: text/plain; charset="iso-8859-1" Ralph: This looks OK! One minor nit ... "The working group now has four main objectives:", actually there are 6 listed. Perhaps best just to change this to: "The working group now has the following main objectives:"? And, in the list of DHCPv6 documents, what about your draft draft-droms-dhcpv6-stateless-guide-00.txt? Do we need to also do a new Goals & Milestones section? - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, October 23, 2002 2:26 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] DHC WG charter Here's a revised charter, based on input from mailing list discussion (this charter also available at http://www.dhcp.org/charter-update.html); comments or acknowledgments (this looks OK) strongly encouraged... Dynamic Host Configuration (dhc) The dhc working group (DHCWG) 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 document in RFC2131 and RFC2132. Additional options are documented in a series of RFCs (see http://www.dhcp.org/rfcs.html). The working group now has four main objectives: * RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. There is widespread feeling that its current restriction to manual keying of clients limits its deployability. It is the goal of DHCWG to rectify this situation by defining extensions that have better deployability properties. In order to achive this goal, DHCWG will develop a threat model and analysis of the authentication protection provided by RFC3118; specific issues to be addressed might include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through FORCERENEW * Develop requirements for any new protocols to address threats or other enhancement identified by the threat model and analysis of 3118 * Complete the specification of DHCP for IPv6 (DHCPv6): - Gain acceptance and publication of current Internet Draft as Proposed Standard - Complete or terminate work on published DHCPv6 options: IPv6 Prefix Options for DHCPv6 DSTM Options for DHCP DSTM Ports Option 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 - Encourage independent implementations and report on interoperability testing * Complete or terminate work on DHCP extensions and new options that are currently work in progress: - Failover protocol - DHCP/DDNS interaction - DHCP Server MIB - Host name options (Smith/Lemon?) - DHCP Leasequery - DHCP Option for CableLabs Client Configuration - KDC Server Address Sub-option - DHCP Options for Internet Storage name Service - The Authentication Suboption for the DHCP Relay Agent Option - Link Selection sub-option for the Relay Agent Information Option - DHCP VPN Information Option - VPN Identifier sub-option for the Relay Agent Information Option - RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option * DHCWG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). DHCWG 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. DHCWG will not (generally) be responsible for evaluating the semantic content of proposed options. DHCWG 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. * 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. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C27ACB.9393687A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHC WG charter

Ralph:

This looks OK!

One minor nit ... "The working group now has = four main objectives:",
actually there are 6 listed. Perhaps best just to = change this to:
"The working group now has the following main = objectives:"?

And, in the list of DHCPv6 documents, what about your = draft
draft-droms-dhcpv6-stateless-guide-00.txt?

Do we need to also do a new Goals & Milestones = section?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, October 23, 2002 2:26 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] DHC WG charter


Here's a revised charter, based on input from mailing = list discussion (this
charter also available at http://www.dhcp.org/charter-update.html);
comments or acknowledgments (this looks OK) strongly = encouraged...



        =            = Dynamic Host Configuration (dhc)

The dhc working group (DHCWG) 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 document in RFC2131 and = RFC2132.  Additional options
are documented in a series of RFCs (see
http://www.dhcp.org/rfcs.html).  The working = group now has four main
objectives:

* RFC 3118 defines current security mechanisms for = DHCPv4.
   Unfortunately, RFC 3118 has neither = been implemented nor deployed to
   date. There is widespread feeling that = its current restriction to
   manual keying of clients limits its = deployability. It is the goal of
   DHCWG to rectify this situation by = defining extensions that have
   better deployability properties. In = order to achive this goal, DHCWG
   will develop a threat model and = analysis of the authentication
   protection provided by RFC3118; = specific issues to be addressed
   might include:
   - Improved key management and = scalability
   - Security for messages passed between = relay agents and servers
   - Threats of DoS attacks through = FORCERENEW

* Develop requirements for any new protocols to = address threats or
   other enhancement identified by the = threat model and analysis of
   3118

* Complete the specification of DHCP for IPv6 = (DHCPv6):
   - Gain acceptance and publication of = current Internet Draft as
     Proposed Standard
   - Complete or terminate work on = published DHCPv6 options:
       IPv6 Prefix = Options for DHCPv6
         = <draft-troan-dhcpv6-opt-prefix-delegation-01.txt>
       DSTM Options = for DHCP
         = <draft-ietf-dhc-dhcpv6-opt-dstm-01.txt>
       DSTM Ports = Option for DHCPv6
         = <draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt>
       DNS = Configuration options for DHCPv6
         = <draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt>
       Load Balancing = for DHCPv6
         = <draft-ietf-dhc-dhcpv6-loadb-02.txt>
       NIS = Configuration Options for DHCPv6
         = <draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt>
       Time = Configuration Options for DHCPv6
         = <draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt>
       Client = Preferred Prefix option for DHCPv6
         = <draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt>
   - Encourage independent implementations = and report on
     interoperability = testing

* Complete or terminate work on DHCP extensions and = new options that
   are currently work in progress:
   - Failover protocol
   - DHCP/DDNS interaction
     = <draft-ietf-dhc-fqdn-option-04.txt>
     = <draft-ietf-dhc-ddns-resolution-04.txt>
   - DHCP Server MIB
     = <draft-ietf-dhc-server-mib-07.txtDHCP MIB>
   - Host name options = (Smith/Lemon?)
   - DHCP Leasequery
   - DHCP Option for CableLabs Client = Configuration
     = <draft-ietf-dhc-packetcable-03.txt>
   - KDC Server Address Sub-option
     = <draft-ietf-dhc-suboptions-kdc-serveraddress-00.txt>
   - DHCP Options for Internet Storage = name Service
     = <draft-ietf-dhc-isnsoption-03.txt>
   - The Authentication Suboption for the = DHCP Relay Agent Option
     = <draft-ietf-dhc-auth-suboption-00.txt>
   - Link Selection sub-option for the = Relay Agent Information Option
     = <draft-ietf-dhc-agent-subnet-selection-03.txt>
   - DHCP VPN Information Option
   - VPN Identifier sub-option for the = Relay Agent Information Option
   - RADIUS Attributes Sub-option for the = DHCP Relay Agent Information Option

* DHCWG is responsible for reviewing (and sometimes = developing) DHCP
   options or other extensions (for both = IPv4 and IPv6). DHCWG 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.  DHCWG
   will not (generally) be responsible for = evaluating the semantic
   content of proposed options. DHCWG 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.

* 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.


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

------_=_NextPart_001_01C27ACB.9393687A-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 23 15:45:40 2002 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 PAA02886; Wed, 23 Oct 2002 15:45:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NJl5v20258; Wed, 23 Oct 2002 15:47:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NJkrv20228 for ; Wed, 23 Oct 2002 15:46:53 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02859 for ; Wed, 23 Oct 2002 15:44:30 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-128-107-208-132.cisco.com [128.107.208.132]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA20243; Wed, 23 Oct 2002 15:46:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20021023154150.03e463e8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Oct 2002 15:46:33 -0400 To: "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] DHC WG charter Cc: dhcwg@ietf.org 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: , Thanks, Bernie... I agree about the change to "following main objectives"... I'll add draft-droms-dhcpv6-stateless-guide-00.txt to the list of DHCPv6 docs. Once we agree on the charter, we can draft a new list of "Goals and Milestones"... - Ralph At 02:37 PM 10/23/2002 -0500, Bernie Volz (EUD) wrote: >Ralph: > >This looks OK! > >One minor nit ... "The working group now has four main objectives:", >actually there are 6 listed. Perhaps best just to change this to: >"The working group now has the following main objectives:"? > >And, in the list of DHCPv6 documents, what about your draft >draft-droms-dhcpv6-stateless-guide-00.txt? > >Do we need to also do a new Goals & Milestones section? > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Wednesday, October 23, 2002 2:26 PM >To: dhcwg@ietf.org >Subject: Re: [dhcwg] DHC WG charter > >Here's a revised charter, based on input from mailing list discussion (this >charter also available at >http://www.dhcp.org/charter-update.html); > >comments or acknowledgments (this looks OK) strongly encouraged... > > > Dynamic Host Configuration (dhc) > >The dhc working group (DHCWG) 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 document in RFC2131 and RFC2132. Additional options >are documented in a series of RFCs (see >http://www.dhcp.org/rfcs.html). The >working group now has four main >objectives: > >* RFC 3118 defines current security mechanisms for DHCPv4. > Unfortunately, RFC 3118 has neither been implemented nor deployed to > date. There is widespread feeling that its current restriction to > manual keying of clients limits its deployability. It is the goal of > DHCWG to rectify this situation by defining extensions that have > better deployability properties. In order to achive this goal, DHCWG > will develop a threat model and analysis of the authentication > protection provided by RFC3118; specific issues to be addressed > might include: > - Improved key management and scalability > - Security for messages passed between relay agents and servers > - Threats of DoS attacks through FORCERENEW > >* Develop requirements for any new protocols to address threats or > other enhancement identified by the threat model and analysis of > 3118 > >* Complete the specification of DHCP for IPv6 (DHCPv6): > - Gain acceptance and publication of current Internet Draft as > Proposed Standard > - Complete or terminate work on published DHCPv6 options: > IPv6 Prefix Options for DHCPv6 > > DSTM Options for DHCP > > DSTM Ports Option 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 > > - Encourage independent implementations and report on > interoperability testing > >* Complete or terminate work on DHCP extensions and new options that > are currently work in progress: > - Failover protocol > - DHCP/DDNS interaction > > > - DHCP Server MIB > > - Host name options (Smith/Lemon?) > - DHCP Leasequery > - DHCP Option for CableLabs Client Configuration > > - KDC Server Address Sub-option > > - DHCP Options for Internet Storage name Service > > - The Authentication Suboption for the DHCP Relay Agent Option > > - Link Selection sub-option for the Relay Agent Information Option > > - DHCP VPN Information Option > - VPN Identifier sub-option for the Relay Agent Information Option > - RADIUS Attributes Sub-option for the DHCP Relay Agent Information > Option > >* DHCWG is responsible for reviewing (and sometimes developing) DHCP > options or other extensions (for both IPv4 and IPv6). DHCWG 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. DHCWG > will not (generally) be responsible for evaluating the semantic > content of proposed options. DHCWG 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. > >* 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. > >_______________________________________________ >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 Oct 23 16:14:47 2002 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 QAA03938; Wed, 23 Oct 2002 16:14:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NKGBv21679; Wed, 23 Oct 2002 16:16:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9NKFVv21665 for ; Wed, 23 Oct 2002 16:15:31 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03750 for ; Wed, 23 Oct 2002 16:13:08 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-128-107-133-128.cisco.com [128.107.133.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA23225 for ; Wed, 23 Oct 2002 16:15:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20021023161441.03ecb358@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Oct 2002 16:15:18 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] DHC WG charter 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: , The posted charter has been revised based on Bernie's input... - Ralph At 02:37 PM 10/23/2002 -0500, Bernie Volz (EUD) wrote: >Ralph: > >This looks OK! > >One minor nit ... "The working group now has four main objectives:", >actually there are 6 listed. Perhaps best just to change this to: >"The working group now has the following main objectives:"? > >And, in the list of DHCPv6 documents, what about your draft >draft-droms-dhcpv6-stateless-guide-00.txt? > >Do we need to also do a new Goals & Milestones section? > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Wednesday, October 23, 2002 2:26 PM >To: dhcwg@ietf.org >Subject: Re: [dhcwg] DHC WG charter > >Here's a revised charter, based on input from mailing list discussion (this >charter also available at >http://www.dhcp.org/charter-update.html); > >comments or acknowledgments (this looks OK) strongly encouraged... > > > Dynamic Host Configuration (dhc) > >The dhc working group (DHCWG) 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 document in RFC2131 and RFC2132. Additional options >are documented in a series of RFCs (see >http://www.dhcp.org/rfcs.html). The >working group now has four main >objectives: > >* RFC 3118 defines current security mechanisms for DHCPv4. > Unfortunately, RFC 3118 has neither been implemented nor deployed to > date. There is widespread feeling that its current restriction to > manual keying of clients limits its deployability. It is the goal of > DHCWG to rectify this situation by defining extensions that have > better deployability properties. In order to achive this goal, DHCWG > will develop a threat model and analysis of the authentication > protection provided by RFC3118; specific issues to be addressed > might include: > - Improved key management and scalability > - Security for messages passed between relay agents and servers > - Threats of DoS attacks through FORCERENEW > >* Develop requirements for any new protocols to address threats or > other enhancement identified by the threat model and analysis of > 3118 > >* Complete the specification of DHCP for IPv6 (DHCPv6): > - Gain acceptance and publication of current Internet Draft as > Proposed Standard > - Complete or terminate work on published DHCPv6 options: > IPv6 Prefix Options for DHCPv6 > > DSTM Options for DHCP > > DSTM Ports Option 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 > > - Encourage independent implementations and report on > interoperability testing > >* Complete or terminate work on DHCP extensions and new options that > are currently work in progress: > - Failover protocol > - DHCP/DDNS interaction > > > - DHCP Server MIB > > - Host name options (Smith/Lemon?) > - DHCP Leasequery > - DHCP Option for CableLabs Client Configuration > > - KDC Server Address Sub-option > > - DHCP Options for Internet Storage name Service > > - The Authentication Suboption for the DHCP Relay Agent Option > > - Link Selection sub-option for the Relay Agent Information Option > > - DHCP VPN Information Option > - VPN Identifier sub-option for the Relay Agent Information Option > - RADIUS Attributes Sub-option for the DHCP Relay Agent Information > Option > >* DHCWG is responsible for reviewing (and sometimes developing) DHCP > options or other extensions (for both IPv4 and IPv6). DHCWG 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. DHCWG > will not (generally) be responsible for evaluating the semantic > content of proposed options. DHCWG 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. > >* 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. > >_______________________________________________ >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 Oct 24 07:35:13 2002 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 HAA02282; Thu, 24 Oct 2002 07:35:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OBaPv09325; Thu, 24 Oct 2002 07:36:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OBY6v09276 for ; Thu, 24 Oct 2002 07:34:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02061; Thu, 24 Oct 2002 07:31:44 -0400 (EDT) Message-Id: <200210241131.HAA02061@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, 24 Oct 2002 07:31:44 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-27.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 IPv6 (DHCPv6) Author(s) : R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney Filename : draft-ietf-dhc-dhcpv6-27.txt Pages : 87 Date : 2002-10-23 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to 'IPv6 Stateless Address Autoconfiguration' (RFC2462), and can be used separately or concurrently with the latter to obtain configuration parameters A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-27.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-27.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-27.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: <2002-10-23133323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-27.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-27.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-23133323.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 Oct 24 09:06:32 2002 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 JAA05443; Thu, 24 Oct 2002 09:06:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OD7nv15059; Thu, 24 Oct 2002 09:07:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OD6Cv14348 for ; Thu, 24 Oct 2002 09:06:12 -0400 Received: from zmamail05.zma.compaq.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05297 for ; Thu, 24 Oct 2002 09:03:51 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9129747DD; Thu, 24 Oct 2002 09:06:09 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 24 Oct 2002 09:06:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [dhcwg] DHC WG charter Date: Thu, 24 Oct 2002 09:06:09 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9696@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] DHC WG charter Thread-Index: AcJ6xGPBIEF+709JScWjYNVoNhuZBAAmZmEQ From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 24 Oct 2002 13:06:09.0478 (UTC) FILETIME=[1EDDA660:01C27B5E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9OD6Cv14349 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 Looks good to me. If the prefix option in v6 covers us for prefix delegation that is fine otherwise a no or yeah on that would be good on the list. I vote yeah. /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, October 23, 2002 2:26 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] DHC WG charter > > > Here's a revised charter, based on input from mailing list > discussion (this > charter also available at http://www.dhcp.org/charter-update.html); > comments or acknowledgments (this looks OK) strongly encouraged... > > > > Dynamic Host Configuration (dhc) > > The dhc working group (DHCWG) 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 document > in RFC2131 and RFC2132. Additional options are documented in > a series of RFCs (see http://www.dhcp.org/rfcs.html). The > working group now has four main > objectives: > > * RFC 3118 defines current security mechanisms for DHCPv4. > Unfortunately, RFC 3118 has neither been implemented nor > deployed to > date. There is widespread feeling that its current restriction to > manual keying of clients limits its deployability. It is > the goal of > DHCWG to rectify this situation by defining extensions that have > better deployability properties. In order to achive this > goal, DHCWG > will develop a threat model and analysis of the authentication > protection provided by RFC3118; specific issues to be addressed > might include: > - Improved key management and scalability > - Security for messages passed between relay agents and servers > - Threats of DoS attacks through FORCERENEW > > * Develop requirements for any new protocols to address threats or > other enhancement identified by the threat model and analysis of > 3118 > > * Complete the specification of DHCP for IPv6 (DHCPv6): > - Gain acceptance and publication of current Internet Draft as > Proposed Standard > - Complete or terminate work on published DHCPv6 options: > IPv6 Prefix Options for DHCPv6 > > DSTM Options for DHCP > > DSTM Ports Option 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 > > - Encourage independent implementations and report on > interoperability testing > > * Complete or terminate work on DHCP extensions and new options that > are currently work in progress: > - Failover protocol > - DHCP/DDNS interaction > > > - DHCP Server MIB > > - Host name options (Smith/Lemon?) > - DHCP Leasequery > - DHCP Option for CableLabs Client Configuration > > - KDC Server Address Sub-option > > - DHCP Options for Internet Storage name Service > > - The Authentication Suboption for the DHCP Relay Agent Option > > - Link Selection sub-option for the Relay Agent Information Option > > - DHCP VPN Information Option > - VPN Identifier sub-option for the Relay Agent Information Option > - RADIUS Attributes Sub-option for the DHCP Relay Agent > Information Option > > * DHCWG is responsible for reviewing (and sometimes developing) DHCP > options or other extensions (for both IPv4 and IPv6). DHCWG 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. DHCWG > will not (generally) be responsible for evaluating the semantic > content of proposed options. DHCWG 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. > > * 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. > > > _______________________________________________ > 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 Oct 24 14:41:13 2002 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 OAA19209; Thu, 24 Oct 2002 14:41:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OIgNv03404; Thu, 24 Oct 2002 14:42:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OIeZv03373 for ; Thu, 24 Oct 2002 14:40:35 -0400 Received: from e32.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19135 for ; Thu, 24 Oct 2002 14:38:11 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9OIceol053664; Thu, 24 Oct 2002 14:38:40 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9OIbOgM213074; Thu, 24 Oct 2002 12:37:24 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g9OIYWh19187; Thu, 24 Oct 2002 14:34:32 -0400 Message-Id: <200210241834.g9OIYWh19187@rotala.raleigh.ibm.com> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHC WG charter In-Reply-To: Message from Ralph Droms of "Wed, 23 Oct 2002 16:15:18 EDT." <4.3.2.7.2.20021023161441.03ecb358@funnel.cisco.com> Date: Thu, 24 Oct 2002 14:34:32 -0400 From: Thomas Narten 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 posted charter has been revised based on Bernie's input... Looks pretty good overall. But one thing seems odd: > Complete or terminate work on DHCP ... And then lists all the relevant WG drafts. I think everyone will agree that the majority of the listed IDs stay as WG items. Maybe a small number should be terminated? We should have the discussion now about which documents are in and which are no longer needed/appropriate. After all, the (re)chartering process is about aligning the charter with the work being done. There may be cases where there is a specific document that we don't really know today what to do with it, that's OK, so long as it is clear in the milestone (or charter) that the first order of business is to figure out what to do with it (i.e., before additional work is done on it). But I don't think the charter should leave it so open ended as to which IDs may or may not be kept. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 24 15:03:48 2002 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 PAA19963; Thu, 24 Oct 2002 15:03:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OJ5Bv04382; Thu, 24 Oct 2002 15:05:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OJ4uv04344 for ; Thu, 24 Oct 2002 15:04:56 -0400 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 PAA19911 for ; Thu, 24 Oct 2002 15:02:31 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g9OJ4md15314; Thu, 24 Oct 2002 14:04:48 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9OJ4mm06899; Thu, 24 Oct 2002 14:04:48 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PDP50N>; Thu, 24 Oct 2002 14:04:48 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] DHC WG charter Date: Thu, 24 Oct 2002 14:03:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27B8F.FE281658" 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_01C27B8F.FE281658 Content-Type: text/plain; charset="iso-8859-1" Why don't we just then change this part to read "Complete work on ..." (remove "or terminate"). I don't believe we want to terminate anything on the list yet. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Thursday, October 24, 2002 2:35 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHC WG charter > The posted charter has been revised based on Bernie's input... Looks pretty good overall. But one thing seems odd: > Complete or terminate work on DHCP ... And then lists all the relevant WG drafts. I think everyone will agree that the majority of the listed IDs stay as WG items. Maybe a small number should be terminated? We should have the discussion now about which documents are in and which are no longer needed/appropriate. After all, the (re)chartering process is about aligning the charter with the work being done. There may be cases where there is a specific document that we don't really know today what to do with it, that's OK, so long as it is clear in the milestone (or charter) that the first order of business is to figure out what to do with it (i.e., before additional work is done on it). But I don't think the charter should leave it so open ended as to which IDs may or may not be kept. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C27B8F.FE281658 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHC WG charter

Why don't we just then change this part to read = "Complete work on ..." (remove "or terminate"). I = don't believe we want to terminate anything on the list yet.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Thursday, October 24, 2002 2:35 PM
To: Ralph Droms
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] DHC WG charter


> The posted charter has been revised based on = Bernie's input...

Looks pretty good overall.

But one thing seems odd:

> Complete or terminate work on DHCP ...

And then lists all the relevant WG drafts.

I think everyone will agree that the majority of the = listed IDs stay
as WG items. Maybe a small number should be = terminated?

We should have the discussion now about which = documents are in and
which are no longer needed/appropriate. After all, = the (re)chartering
process is about aligning the charter with the work = being done.

There may be cases where there is a specific document = that we don't
really know today what to do with it, that's OK, so = long as it is
clear in the milestone (or charter) that the first = order of business
is to figure out what to do with it (i.e., before = additional work is
done on it).

But I don't think the charter should leave it so open = ended as to
which IDs may or may not be kept.

Thomas


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

------_=_NextPart_001_01C27B8F.FE281658-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 24 16:24:24 2002 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 QAA22138; Thu, 24 Oct 2002 16:24:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OKPdv08781; Thu, 24 Oct 2002 16:25:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9OKOqv08730 for ; Thu, 24 Oct 2002 16:24:52 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22099 for ; Thu, 24 Oct 2002 16:22:29 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-128-107-133-128.cisco.com [128.107.133.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA00486 for ; Thu, 24 Oct 2002 16:24:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20021024162427.03bd3a30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Oct 2002 16:24:42 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] DHC WG charter In-Reply-To: <200210241834.g9OIYWh19187@rotala.raleigh.ibm.com> References: <4.3.2.7.2.20021023161441.03ecb358@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The idea behind "complete or terminate..." was to be conscious about the progress (or lack thereof) on expired documents. Mostly an explicit and visible sanity check with the authors to find out if progress will be made in the future (with a pretty low bar on "progress"). There may be some docs that the WG wants to take off the charter (but I doubt it). - Ralph At 02:34 PM 10/24/2002 -0400, Thomas Narten wrote: > > The posted charter has been revised based on Bernie's input... > >Looks pretty good overall. > >But one thing seems odd: > > > Complete or terminate work on DHCP ... > >And then lists all the relevant WG drafts. > >I think everyone will agree that the majority of the listed IDs stay >as WG items. Maybe a small number should be terminated? > >We should have the discussion now about which documents are in and >which are no longer needed/appropriate. After all, the (re)chartering >process is about aligning the charter with the work being done. > >There may be cases where there is a specific document that we don't >really know today what to do with it, that's OK, so long as it is >clear in the milestone (or charter) that the first order of business >is to figure out what to do with it (i.e., before additional work is >done on it). > >But I don't think the charter should leave it so open ended as to >which IDs may or may not be kept. > >Thomas > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 24 23:29:23 2002 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 XAA01671; Thu, 24 Oct 2002 23:29:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P3Uiv29372; Thu, 24 Oct 2002 23:30:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9P2Qiv26551 for ; Thu, 24 Oct 2002 22:26:44 -0400 Received: from web40503.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00414 for ; Thu, 24 Oct 2002 22:24:17 -0400 (EDT) Message-ID: <20021025022633.93007.qmail@web40503.mail.yahoo.com> Received: from [137.132.3.9] by web40503.mail.yahoo.com via HTTP; Fri, 25 Oct 2002 10:26:33 CST Date: Fri, 25 Oct 2002 10:26:33 +0800 (CST) From: =?iso-8859-1?q?Raymond=20Jayaraj?= To: dhcwg@ietf.org Cc: jraymond@icr.a-star.edu.sg MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [dhcwg] How should a DHCPv6 server respond to retransmitted packets 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 all, How should a server respond to retransmitted packets received after a REPLY packet is sent, e.g.: DHC6CLIENT DHC6SERVER INFOSERVER | | (e.g. LDAP) | | | |1)INFO-REQ | | |>>> | | | >>> | | | >>> | | | >>> | | | >>>|2)processing/retrieve info |3)INFO-REQ |>>>>>>>>>>>>>>>| |>>> |<<<<<<<<<<<<<<<| | >>> <<<| | | >>><<< | | | <<<>>> | | | <<< >>>| | |<<< 4)REPLY |5)??? | What should (5) be? Should the server: a) drop (3) and subsequent duplicates (base on transaction id). b) reprocess the request and retransmit the reply, i.e. do (2)&(4) again. c) retransmit the reply, i.e. do (4) again. d) do any of the above (implementation specific). No indication for the above could be found in the draft. I suspect it should be a) or d), but it'd be nice to know for sure. ------------------------------------------------------------------------ Raymond J. Jayabal | ICR, A-STAR jraymond@icr.a-star.edu.sg | 20 Science Park Rd #02-34/37 Tel: +65 6870 9330 | Singapore 117674 ------------------------------------------------------------------------ __________________________________________________ Do You Yahoo!? Great flight deals, travel info and prizes! http://sg.travel.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 25 07:29:58 2002 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 HAA20413; Fri, 25 Oct 2002 07:29:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBVDv29479; Fri, 25 Oct 2002 07:31:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBTVv29283 for ; Fri, 25 Oct 2002 07:29:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19731; Fri, 25 Oct 2002 07:27:11 -0400 (EDT) Message-Id: <200210251127.HAA19731@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, 25 Oct 2002 07:27:11 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-prefix-delegation-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 : IPv6 Prefix Options for DHCPv6 Author(s) : O. Troan, R. Droms Filename : draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt Pages : 18 Date : 2002-10-24 The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This prefix delegation mechanism is intended for simple prefix delegation 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-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-dhcpv6-opt-prefix-delegation-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-dhcpv6-opt-prefix-delegation-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: <2002-10-24142000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-24142000.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 Oct 25 07:30:02 2002 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 HAA20440; Fri, 25 Oct 2002 07:30:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBVPv29503; Fri, 25 Oct 2002 07:31:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PBTav29288 for ; Fri, 25 Oct 2002 07:29:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19747; Fri, 25 Oct 2002 07:27:16 -0400 (EDT) Message-Id: <200210251127.HAA19747@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, 25 Oct 2002 07:27:16 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agentopt-radius-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 : RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option Author(s) : R. Droms, J. Schnizlein Filename : draft-ietf-dhc-agentopt-radius-01.txt Pages : 7 Date : 2002-10-24 A network access device may choose to authenticate the identity of a device before granting that device access to the network. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access. A network element using RADIUS as an authentication authority will receive attributes from a RADIUS server that may be used by a DHCP server in the selection of an IP address for assignment to the device through its DHCP client. The RADIUS Attributes sub-option allows a network element to pass along attributes for the user of a device received during RADIUS authentication to a DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-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-agentopt-radius-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-agentopt-radius-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: <2002-10-24142009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agentopt-radius-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-24142009.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 Oct 25 08:26:45 2002 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 IAA22431; Fri, 25 Oct 2002 08:26:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PCS7v00658; Fri, 25 Oct 2002 08:28:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PCRkv00643 for ; Fri, 25 Oct 2002 08:27:46 -0400 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 IAA22372 for ; Fri, 25 Oct 2002 08:25:24 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g9PCRVW05533; Fri, 25 Oct 2002 07:27:33 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9PCRUH05409; Fri, 25 Oct 2002 07:27:30 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PBF43X>; Fri, 25 Oct 2002 07:27:30 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Raymond Jayaraj'" , dhcwg@ietf.org Cc: jraymond@icr.a-star.edu.sg Subject: RE: [dhcwg] How should a DHCPv6 server respond to retransmitted p ackets Date: Fri, 25 Oct 2002 07:26:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27C21.9D0D838E" 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_01C27C21.9D0D838E Content-Type: text/plain; charset="iso-8859-1" This is implementation specific. It is important to respond. Whether the server keeps an Transaction ID cache and responds from that or reprocesses the packet is really a server implementation issue. - Bernie -----Original Message----- From: Raymond Jayaraj [mailto:raymondjayaraj@yahoo.com.sg] Sent: Thursday, October 24, 2002 10:27 PM To: dhcwg@ietf.org Cc: jraymond@icr.a-star.edu.sg Subject: [dhcwg] How should a DHCPv6 server respond to retransmitted packets Hi all, How should a server respond to retransmitted packets received after a REPLY packet is sent, e.g.: DHC6CLIENT DHC6SERVER INFOSERVER | | (e.g. LDAP) | | | |1)INFO-REQ | | |>>> | | | >>> | | | >>> | | | >>> | | | >>>|2)processing/retrieve info |3)INFO-REQ |>>>>>>>>>>>>>>>| |>>> |<<<<<<<<<<<<<<<| | >>> <<<| | | >>><<< | | | <<<>>> | | | <<< >>>| | |<<< 4)REPLY |5)??? | What should (5) be? Should the server: a) drop (3) and subsequent duplicates (base on transaction id). b) reprocess the request and retransmit the reply, i.e. do (2)&(4) again. c) retransmit the reply, i.e. do (4) again. d) do any of the above (implementation specific). No indication for the above could be found in the draft. I suspect it should be a) or d), but it'd be nice to know for sure. ------------------------------------------------------------------------ Raymond J. Jayabal | ICR, A-STAR jraymond@icr.a-star.edu.sg | 20 Science Park Rd #02-34/37 Tel: +65 6870 9330 | Singapore 117674 ------------------------------------------------------------------------ __________________________________________________ Do You Yahoo!? Great flight deals, travel info and prizes! http://sg.travel.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C27C21.9D0D838E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] How should a DHCPv6 server respond to retransmitted = packets

This is implementation specific. It is important to = respond.

Whether the server keeps an Transaction ID cache and = responds from that or reprocesses the packet is really a server = implementation issue.

- Bernie

-----Original Message-----
From: Raymond Jayaraj [mailto:raymondjayaraj@yahoo.= com.sg]
Sent: Thursday, October 24, 2002 10:27 PM
To: dhcwg@ietf.org
Cc: jraymond@icr.a-star.edu.sg
Subject: [dhcwg] How should a DHCPv6 server respond = to retransmitted
packets


Hi all,

How should a server respond to retransmitted = packets
received after a
REPLY packet is sent, e.g.:

DHC6CLIENT      = DHC6SERVER      INFOSERVER
|          &n= bsp;    = |            = ;   (e.g. LDAP)
|          &n= bsp;    = |            = ;   |
|1)INFO-REQ     = |            = ;   |
|>>>        &n= bsp;   = |            = ;   |
|   = >>>         = |            = ;   |
|      = >>>      = |            = ;   |
|         = >>>   = |            = ;   |
|          &n= bsp; >>>|2)processing/retrieve info
|3)INFO-REQ     = |>>>>>>>>>>>>>>>|
|>>>        &n= bsp;   = |<<<<<<<<<<<<<<<|
|   = >>>      = <<<|          = ;     |
|      = >>><<<   = |            = ;   |
|      = <<<>>>   = |            = ;   |
|   = <<<      = >>>|          = ;     |
|<<< 4)REPLY    = |5)???          |

What should (5) be? Should the server:

a) drop (3) and subsequent duplicates (base on
transaction id).

b) reprocess the request and retransmit the = reply,
i.e. do (2)&(4)
   again.

c) retransmit the reply, i.e. do (4) again.

d) do any of the above (implementation = specific).

No indication for the above could be found in = the
draft. I suspect
it should be a) or d), but it'd be nice to know = for
sure.

---------------------------------------------------------------= ---------
Raymond J. = Jayabal           = ;      | ICR, A-STAR
jraymond@icr.a-star.edu.sg      &= nbsp;  | 20 Science Park
Rd #02-34/37
Tel: +65 6870 = 9330           &n= bsp;     | Singapore 117674
---------------------------------------------------------------= ---------




__________________________________________________
Do You Yahoo!?
Great flight deals, travel info and prizes!
http://sg.travel.yahoo.com
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C27C21.9D0D838E-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 25 08:41:11 2002 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 IAA22907; Fri, 25 Oct 2002 08:41:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PCgXv01891; Fri, 25 Oct 2002 08:42:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PCf8v01790 for ; Fri, 25 Oct 2002 08:41:08 -0400 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22820 for ; Fri, 25 Oct 2002 08:38:46 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn2-320.cisco.com [10.21.113.64]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA20254; Fri, 25 Oct 2002 08:41:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20021025083729.00b859d8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Oct 2002 08:41:00 -0400 To: Raymond Jayaraj From: Ralph Droms Subject: Re: [dhcwg] How should a DHCPv6 server respond to retransmitted packets Cc: dhcwg@ietf.org, jraymond@icr.a-star.edu.sg In-Reply-To: <20021025022633.93007.qmail@web40503.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , In the case of Information-request, the answer is (b) or (c), depending on the implementation. The responses to retransmitted Informat-request messages are likely to be identical, so the use of a response cache shouldn't affect the results of the message exchange. - Ralph At 10:26 AM 10/25/2002 +0800, Raymond Jayaraj wrote: >Hi all, > >How should a server respond to retransmitted packets >received after a >REPLY packet is sent, e.g.: > >DHC6CLIENT DHC6SERVER INFOSERVER >| | (e.g. LDAP) >| | | >|1)INFO-REQ | | >|>>> | | >| >>> | | >| >>> | | >| >>> | | >| >>>|2)processing/retrieve info >|3)INFO-REQ |>>>>>>>>>>>>>>>| >|>>> |<<<<<<<<<<<<<<<| >| >>> <<<| | >| >>><<< | | >| <<<>>> | | >| <<< >>>| | >|<<< 4)REPLY |5)??? | > >What should (5) be? Should the server: > >a) drop (3) and subsequent duplicates (base on >transaction id). > >b) reprocess the request and retransmit the reply, >i.e. do (2)&(4) > again. > >c) retransmit the reply, i.e. do (4) again. > >d) do any of the above (implementation specific). > >No indication for the above could be found in the >draft. I suspect >it should be a) or d), but it'd be nice to know for >sure. > >------------------------------------------------------------------------ >Raymond J. Jayabal | ICR, A-STAR >jraymond@icr.a-star.edu.sg | 20 Science Park >Rd #02-34/37 >Tel: +65 6870 9330 | Singapore 117674 >------------------------------------------------------------------------ > > > > >__________________________________________________ >Do You Yahoo!? >Great flight deals, travel info and prizes! >http://sg.travel.yahoo.com >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 25 09:44:04 2002 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 JAA24609; Fri, 25 Oct 2002 09:44:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PDjQv04979; Fri, 25 Oct 2002 09:45:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PD8Cv03274 for ; Fri, 25 Oct 2002 09:08:12 -0400 Received: from gwserver.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23605 for ; Fri, 25 Oct 2002 09:05:46 -0400 (EDT) Received: from galadriel ([172.16.1.68]) by gwserver.icr.a-star.edu.sg; Fri, 25 Oct 2002 21:02:32 +0800 Message-ID: <04d601c27c27$737c7420$440110ac@galadriel> From: "Raymond J. Jayabal" To: "Ralph Droms" Cc: References: <4.3.2.7.2.20021025083729.00b859d8@funnel.cisco.com> Subject: Re: [dhcwg] How should a DHCPv6 server respond to retransmitted packets Date: Fri, 25 Oct 2002 21:07:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 > In the case of Information-request, the answer is (b) or (c), > depending on the implementation What about the other client messages, e.g. RENEW, etc? Is it safe to apply (b) or (c) too? ----- Original Message ----- From: "Ralph Droms" To: "Raymond Jayaraj" Cc: ; Sent: Friday, October 25, 2002 8:41 PM Subject: Re: [dhcwg] How should a DHCPv6 server respond to retransmitted packets > In the case of Information-request, the answer is (b) or (c), depending on > the implementation. The responses to retransmitted Informat-request > messages are likely to be identical, so the use of a response cache > shouldn't affect the results of the message exchange. > > - Ralph > > At 10:26 AM 10/25/2002 +0800, Raymond Jayaraj wrote: > >Hi all, > > > >How should a server respond to retransmitted packets > >received after a > >REPLY packet is sent, e.g.: > > > >DHC6CLIENT DHC6SERVER INFOSERVER > >| | (e.g. LDAP) > >| | | > >|1)INFO-REQ | | > >|>>> | | > >| >>> | | > >| >>> | | > >| >>> | | > >| >>>|2)processing/retrieve info > >|3)INFO-REQ |>>>>>>>>>>>>>>>| > >|>>> |<<<<<<<<<<<<<<<| > >| >>> <<<| | > >| >>><<< | | > >| <<<>>> | | > >| <<< >>>| | > >|<<< 4)REPLY |5)??? | > > > >What should (5) be? Should the server: > > > >a) drop (3) and subsequent duplicates (base on > >transaction id). > > > >b) reprocess the request and retransmit the reply, > >i.e. do (2)&(4) > > again. > > > >c) retransmit the reply, i.e. do (4) again. > > > >d) do any of the above (implementation specific). > > > >No indication for the above could be found in the > >draft. I suspect > >it should be a) or d), but it'd be nice to know for > >sure. > > > >----------------------------------------------------------------------- - > >Raymond J. Jayabal | ICR, A-STAR > >jraymond@icr.a-star.edu.sg | 20 Science Park > >Rd #02-34/37 > >Tel: +65 6870 9330 | Singapore 117674 > >----------------------------------------------------------------------- - > > > > > > > > > >__________________________________________________ > >Do You Yahoo!? > >Great flight deals, travel info and prizes! > >http://sg.travel.yahoo.com > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 25 16:34:02 2002 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 QAA10649; Fri, 25 Oct 2002 16:34:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PKZGv29943; Fri, 25 Oct 2002 16:35:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PKXbv29891 for ; Fri, 25 Oct 2002 16:33:37 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10583 for ; Fri, 25 Oct 2002 16:31:10 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9PKXUot016757 for ; Fri, 25 Oct 2002 13:33:30 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9PKXSit014784; Fri, 25 Oct 2002 13:33:29 -0700 (PDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-820.cisco.com [10.82.243.52]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA11122; Fri, 25 Oct 2002 13:33:27 -0700 (PDT) Message-Id: <4.3.2.7.2.20021023142936.01d98d88@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Oct 2002 16:33:20 -0400 To: dhcwg@ietf.org From: John Schnizlein Cc: "James M. Polk" , "Marc Linsner" In-Reply-To: <4.1.20021023115844.02893e00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: Fwd: I-D ACTION:draft-polk-dhcp-geo-loc-option-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: , Please comment on the geo-loc-option draft announced in the following. While we are asking for a moment in the DHC WG at the Atlanta meeting, the semantics of this option are to be discussed in the GEOPRIV WG. We hope the format will be useful more widely, but it is designed to fit the circumstances of DHCP. The concept of this draft is different from the recently discussed draft-critchley-dhc-location-option-00.txt in several ways: 1) the location configured is that of the DHC client, not the server, 2) the encoding is binary for economy, 3) the resolution of each measure is under explicit control, and 4) an immediate purpose is to give wired IP telephones the location they would send when calling to report an emergency. There is, of course, no reason to wait for Atlanta to comment. John >To: IETF-Announce:; >From: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-polk-dhcp-geo-loc-option-00.txt >Date: Wed, 23 Oct 2002 07:36:17 -0400 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : DHCP Option for Geographic Location > Author(s) : J. Polk et al. > Filename : draft-polk-dhcp-geo-loc-option-00.txt > Pages : 22 > Date : 2002-10-22 > >This document specifies a Dynamic Host Configuration Protocol option for >the geographic location of the client. The location includes latitude, >longitude, and altitude, with resolution indicators for each. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-polk-dhcp-geo-loc-option-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-polk-dhcp-geo-loc-option-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-polk-dhcp-geo-loc-option-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2002-10-22143434.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-polk-dhcp-geo-loc-option-00.txt > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 25 16:56:44 2002 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 QAA11547; Fri, 25 Oct 2002 16:56:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PKw9v31196; Fri, 25 Oct 2002 16:58:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PKvZv31182 for ; Fri, 25 Oct 2002 16:57:35 -0400 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 QAA11509 for ; Fri, 25 Oct 2002 16:55:11 -0400 (EDT) Received: from nominum.com (a35.pm3-67.theriver.com [206.25.48.227]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g9PKtN211855; Fri, 25 Oct 2002 15:55:23 -0500 (CDT) Date: Fri, 25 Oct 2002 13:57:21 -0700 Subject: Re: [dhcwg] Re: Fwd: I-D ACTION:draft-polk-dhcp-geo-loc-option-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Marc Linsner" , "James M. Polk" , dhcwg@ietf.org To: John Schnizlein From: Ted Lemon In-Reply-To: <4.3.2.7.2.20021023142936.01d98d88@wells.cisco.com> Message-Id: <5AE3D9D6-E85C-11D6-B81E-003065D63CF6@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 It looks fine, superficially, but all those fiddly 4-bit, 34-bit, and 30-bit values are going to be a real pain for implementation. I don't know if this is going to be implemented on servers that are not embedded in devices that can do location calculations, but if it is, it would be better to use a less complex numbering scheme. It's normally considered bad form to have a DHCP option that requires special modifications to the server in order to implement. I'm also a bit skeptical that DHCP is even the right way to do this, because the DHCP server's physical location, and even the relay agent's physical location, is not the same as the device's physical location. For wired devices, you can figure out the devices location through a database lookup, but for wireless devices you need to triangulate, and I have trouble figuring out how you're going to cram that functionality into a DHCP server. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 25 17:30:52 2002 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 RAA12804; Fri, 25 Oct 2002 17:30:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PLW9v01052; Fri, 25 Oct 2002 17:32:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PLV2v01006 for ; Fri, 25 Oct 2002 17:31:02 -0400 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12756 for ; Fri, 25 Oct 2002 17:28:37 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9PLUtot025919; Fri, 25 Oct 2002 14:30:55 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9PLUsqx002409; Fri, 25 Oct 2002 14:30:54 -0700 (PDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-820.cisco.com [10.82.243.52]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA05850; Fri, 25 Oct 2002 14:30:47 -0700 (PDT) Message-Id: <4.3.2.7.2.20021025170935.01eaf5f8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Oct 2002 17:30:45 -0400 To: Ted Lemon From: John Schnizlein Cc: "Marc Linsner" , "James M. Polk" , dhcwg@ietf.org In-Reply-To: <5AE3D9D6-E85C-11D6-B81E-003065D63CF6@nominum.com> References: <4.3.2.7.2.20021023142936.01d98d88@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] draft-polk-dhcp-geo-loc-option-00 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: , Wow, Ted! Thanks for the almost instantaneous reply. The only modification is a little arithmetic to evaluate the option. We thought dividing the byte containing the MU by 16, would be easy. And fixed point arithmetic is often handled by treating the combination, which we arranged to be 5 bytes long, as an integer multiple of the (peculiar) smallest increment precision. There would be just a few tricky arithmetic expressions for the client to extract the resolution and apply it to the location measure. The server would, presumably, just hand out the properly formatted lump of 15 bytes it gets out of the Circuit-ID-to-location database lookup. We completely agree that the DHCP server's location is irrelevant. Although we have not considered the wireless case beyond the obvious that the location of the access-point, which this method can support, is within radio distance of the client. The appropriately smaller resolution would be associated with those entries in the location database. We suspect that the triangulation to determine more precise locations might be performed by the receiver in the client, which would be someone else's problem to standardize. The point that we think GEO-PRIV really cares about is that the host finds its location in some not-very-public way, and it decides when and where to send it - for example to an emergency responder. John At 04:57 PM 10/25/2002, Ted Lemon wrote: >It looks fine, superficially, but all those fiddly 4-bit, 34-bit, and 30-bit values are going to be a real pain for implementation. I don't know if this is going to be implemented on servers that are not embedded in devices that can do location calculations, but if it is, it would be better to use a less complex numbering scheme. It's normally considered bad form to have a DHCP option that requires special modifications to the server in order to implement. > >I'm also a bit skeptical that DHCP is even the right way to do this, because the DHCP server's physical location, and even the relay agent's physical location, is not the same as the device's physical location. >For wired devices, you can figure out the devices location through a database lookup, but for wireless devices you need to triangulate, and I have trouble figuring out how you're going to cram that functionality into a DHCP server. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 26 19:05:23 2002 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 TAA13631; Sat, 26 Oct 2002 19:05:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QN6ev05653; Sat, 26 Oct 2002 19:06:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PE5sv05871 for ; Fri, 25 Oct 2002 10:05:54 -0400 Received: from icarai.microlink.com.br (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25420 for ; Fri, 25 Oct 2002 10:03:29 -0400 (EDT) Received: from microlink.com.br (alex@Cafuba.microlink.com.br [200.239.245.76]) by icarai.microlink.com.br (8.11.6/8.11.6) with ESMTP id g9PE5kt24836 for ; Fri, 25 Oct 2002 12:05:47 -0200 Message-ID: <3DB94FBB.AED5CA04@microlink.com.br> Date: Fri, 25 Oct 2002 11:05:47 -0300 From: Alex Robertson Organization: Microlink X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: pt-BR, pt, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] two dhcp server 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 Hi all, Sorry if this is not the correct place for asking this kind of question. If not, please, tell me the right address. I would like to have two dhcp servers. If one crashes, the other assume. How can i do that without getting machines confused with their ip's? I didn't find anything in the web. Is there a location where i can find this information? thanks in advance. -- Alex G Robertson NOC - Microlink _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 26 19:07:13 2002 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 TAA13693; Sat, 26 Oct 2002 19:07:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9QN8dv06271; Sat, 26 Oct 2002 19:08:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9PIIBv21320 for ; Fri, 25 Oct 2002 14:18:11 -0400 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 OAA05346 for ; Fri, 25 Oct 2002 14:15:47 -0400 (EDT) Received: from nas5-48-187.mystarhub.com.sg (HELO silmaril) (raymondjayaraj@203.117.48.187 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Oct 2002 18:18:03 -0000 Message-ID: <000c01c27c54$542149c0$6400a8c0@silmaril> From: "Raymond J. Jayabal" To: Cc: References: <4.3.2.7.2.20021025083729.00b859d8@funnel.cisco.com> Subject: Re: [dhcwg] How should a DHCPv6 server respond to retransmitted packets Date: Sat, 26 Oct 2002 02:28:29 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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 Hi, Stumbled upon what may or may not be a problem, given that (b) is an acceptable alternative to (c), as follows. * * * Whether (b) or (c), the client will receive 2 or more REPLY packets. As the client will leave its 'waiting-for-REPLY' state when it receives REPLY #1, I assume it will drop REPLY #2 and subsequent REPLY packets and configure itself based on REPLY #1. Further assume that the server (or the network it serves, or the information services it rely on to satisfy client requests) is in State-1 when request #1 arrives, and State-2 when request #2 arrives. If (b) is allowed, then the REPLY packets will differ in content. Since REPLY #2 is last to leave the server, it would have committed to memory that it sent State-2 data to the client, whereas the client would have configured itself with State-1 data. This doesn't seem to be a good situation in the general sense, even if it happens for a short while. In case of (c), both client and server will always be synchronised. When State-2 happens, server will know exactly which clients need updating. Does this disqualify (b) as an alternative? Or is it still an acceptable implementation? - Ray ----- Original Message ----- From: "Ralph Droms" To: "Raymond Jayaraj" Cc: ; Sent: Friday, October 25, 2002 8:41 PM Subject: Re: [dhcwg] How should a DHCPv6 server respond to retransmitted packets > In the case of Information-request, the answer is (b) or (c), depending on > the implementation. The responses to retransmitted Informat-request > messages are likely to be identical, so the use of a response cache > shouldn't affect the results of the message exchange. > > - Ralph > > At 10:26 AM 10/25/2002 +0800, Raymond Jayaraj wrote: > >Hi all, > > > >How should a server respond to retransmitted packets > >received after a > >REPLY packet is sent, e.g.: > > > >DHC6CLIENT DHC6SERVER INFOSERVER > >| | (e.g. LDAP) > >| | | > >|1)INFO-REQ | | > >|>>> | | > >| >>> | | > >| >>> | | > >| >>> | | > >| >>>|2)processing/retrieve info > >|3)INFO-REQ |>>>>>>>>>>>>>>>| > >|>>> |<<<<<<<<<<<<<<<| > >| >>> <<<| | > >| >>><<< | | > >| <<<>>> | | > >| <<< >>>| | > >|<<< 4)REPLY |5)??? | > > > >What should (5) be? Should the server: > > > >a) drop (3) and subsequent duplicates (base on > >transaction id). > > > >b) reprocess the request and retransmit the reply, > >i.e. do (2)&(4) > > again. > > > >c) retransmit the reply, i.e. do (4) again. > > > >d) do any of the above (implementation specific). > > > >No indication for the above could be found in the > >draft. I suspect > >it should be a) or d), but it'd be nice to know for > >sure. > > > >------------------------------------------------------------------------ > >Raymond J. Jayabal | ICR, A-STAR > >jraymond@icr.a-star.edu.sg | 20 Science Park > >Rd #02-34/37 > >Tel: +65 6870 9330 | Singapore 117674 > >------------------------------------------------------------------------ > > > > > > > > > >__________________________________________________ > >Do You Yahoo!? > >Great flight deals, travel info and prizes! > >http://sg.travel.yahoo.com > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg __________________________________________________ Do You Yahoo!? Great flight deals, travel info and prizes! http://sg.travel.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 27 09:36:20 2002 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 JAA04313; Sun, 27 Oct 2002 09:36: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 g9REbbv21607; Sun, 27 Oct 2002 09:37:37 -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 g9REZ5v20991 for ; Sun, 27 Oct 2002 09:35:05 -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 JAA04300 for ; Sun, 27 Oct 2002 09:32:41 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g9REYKd06327; Sun, 27 Oct 2002 08:34:46 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9REYKC14547; Sun, 27 Oct 2002 08:34:20 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PDTB6Q>; Sun, 27 Oct 2002 08:34:19 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Raymond J. Jayabal'" , dhcwg@ietf.org Cc: jraymond@icr.a-star.edu.sg Subject: RE: [dhcwg] How should a DHCPv6 server respond to retransmitted p ackets Date: Sun, 27 Oct 2002 08:33:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27DC5.CA7B5A8A" 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_01C27DC5.CA7B5A8A Content-Type: text/plain; charset="iso-8859-1" The reply using (c) should generally be similar enough not to be a concern - but this is important for the server implementor to consider. In particular, Information-Request is likely not to generate any difference except of the configuration information of the server has changed OR it is doing some "round-robining" of parameters (such as the addresses of the DNS server) - even in this case, there is no problem. For the case of Request/Renew/Release/Decline, this may indeed generate some differences but again this should not be an issue: - For a Request, the server must take care to give the client addresses it has previously allocated for the IAID and IA type. - For a Request/Renew, the lifetimes may have changed slightly (but as long as the server takes care not to reduce the lifetimes from what it sent earlier, this should not matter). - For Release/Decline, the Reply to the retransmitted Release/Decline may indeed contain slightly different information as discussed in the draft: For each IA in the Release message for which the server has no binding information, the server adds an IA option using the IAID from the Release message and includes a Status Code option with the value NoBinding in the IA option. No other options are included in the IA option. But, as also mentioned in the draft, a Client should accept this status code. - Bernie Volz -----Original Message----- From: Raymond J. Jayabal [mailto:raymondjayaraj@yahoo.com.sg] Sent: Friday, October 25, 2002 2:28 PM To: dhcwg@ietf.org Cc: jraymond@icr.a-star.edu.sg Subject: Re: [dhcwg] How should a DHCPv6 server respond to retransmitted packets Hi, Stumbled upon what may or may not be a problem, given that (b) is an acceptable alternative to (c), as follows. * * * Whether (b) or (c), the client will receive 2 or more REPLY packets. As the client will leave its 'waiting-for-REPLY' state when it receives REPLY #1, I assume it will drop REPLY #2 and subsequent REPLY packets and configure itself based on REPLY #1. Further assume that the server (or the network it serves, or the information services it rely on to satisfy client requests) is in State-1 when request #1 arrives, and State-2 when request #2 arrives. If (b) is allowed, then the REPLY packets will differ in content. Since REPLY #2 is last to leave the server, it would have committed to memory that it sent State-2 data to the client, whereas the client would have configured itself with State-1 data. This doesn't seem to be a good situation in the general sense, even if it happens for a short while. In case of (c), both client and server will always be synchronised. When State-2 happens, server will know exactly which clients need updating. Does this disqualify (b) as an alternative? Or is it still an acceptable implementation? - Ray ----- Original Message ----- From: "Ralph Droms" To: "Raymond Jayaraj" Cc: ; Sent: Friday, October 25, 2002 8:41 PM Subject: Re: [dhcwg] How should a DHCPv6 server respond to retransmitted packets > In the case of Information-request, the answer is (b) or (c), depending on > the implementation. The responses to retransmitted Informat-request > messages are likely to be identical, so the use of a response cache > shouldn't affect the results of the message exchange. > > - Ralph > > At 10:26 AM 10/25/2002 +0800, Raymond Jayaraj wrote: > >Hi all, > > > >How should a server respond to retransmitted packets > >received after a > >REPLY packet is sent, e.g.: > > > >DHC6CLIENT DHC6SERVER INFOSERVER > >| | (e.g. LDAP) > >| | | > >|1)INFO-REQ | | > >|>>> | | > >| >>> | | > >| >>> | | > >| >>> | | > >| >>>|2)processing/retrieve info > >|3)INFO-REQ |>>>>>>>>>>>>>>>| > >|>>> |<<<<<<<<<<<<<<<| > >| >>> <<<| | > >| >>><<< | | > >| <<<>>> | | > >| <<< >>>| | > >|<<< 4)REPLY |5)??? | > > > >What should (5) be? Should the server: > > > >a) drop (3) and subsequent duplicates (base on > >transaction id). > > > >b) reprocess the request and retransmit the reply, > >i.e. do (2)&(4) > > again. > > > >c) retransmit the reply, i.e. do (4) again. > > > >d) do any of the above (implementation specific). > > > >No indication for the above could be found in the > >draft. I suspect > >it should be a) or d), but it'd be nice to know for > >sure. > > > >------------------------------------------------------------------------ > >Raymond J. Jayabal | ICR, A-STAR > >jraymond@icr.a-star.edu.sg | 20 Science Park > >Rd #02-34/37 > >Tel: +65 6870 9330 | Singapore 117674 > >------------------------------------------------------------------------ > > > > > > > > > >__________________________________________________ > >Do You Yahoo!? > >Great flight deals, travel info and prizes! > >http://sg.travel.yahoo.com > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg __________________________________________________ Do You Yahoo!? Great flight deals, travel info and prizes! http://sg.travel.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C27DC5.CA7B5A8A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] How should a DHCPv6 server respond to retransmitted = packets

The reply using (c) should generally be similar = enough not to be a concern - but this is important for the server = implementor to consider. In particular, Information-Request is likely = not to generate any difference except of the configuration information = of the server has changed OR it is doing some = "round-robining" of parameters (such as the addresses of the = DNS server) - even in this case, there is no problem.

For the case of Request/Renew/Release/Decline, this = may indeed generate some differences but again this should not be an = issue:

- For a Request, the server must take care to give = the client addresses it has previously allocated for the IAID and IA = type.

- For a Request/Renew, the lifetimes may have changed = slightly (but as long as the server takes care not to reduce the = lifetimes from what it sent earlier, this should not = matter).

- For Release/Decline, the Reply to the retransmitted = Release/Decline may indeed contain slightly different information as = discussed in the draft:

   For each IA in the Release
   message for which the server has no = binding information, the server
   adds an IA option using the IAID from = the Release message and
   includes a Status Code option with the = value NoBinding in the IA
   option.  No other options are = included in the IA option.
But, as also mentioned in the draft, a Client should = accept this status code.

- Bernie Volz

-----Original Message-----
From: Raymond J. Jayabal [mailto:raymondjayaraj@yahoo.= com.sg]
Sent: Friday, October 25, 2002 2:28 PM
To: dhcwg@ietf.org
Cc: jraymond@icr.a-star.edu.sg
Subject: Re: [dhcwg] How should a DHCPv6 server = respond to retransmitted
packets


Hi,

Stumbled upon what may or may not be a problem, given = that (b) is an
acceptable alternative to (c), as follows.

          &nb= sp;           &nb= sp;       *  *  *

Whether (b) or (c), the client will receive 2 or more = REPLY packets.

As the client will leave its 'waiting-for-REPLY' = state when it receives
REPLY #1, I assume it will drop REPLY #2 and = subsequent REPLY packets
and configure itself based on REPLY #1.

Further assume that the server (or the network it = serves, or the
information services it rely on to satisfy client = requests) is in
State-1 when request #1 arrives, and State-2 when = request #2 arrives.

If (b) is allowed, then the REPLY packets will differ = in content. Since
REPLY #2 is last to leave the server, it would have = committed to memory
that it sent State-2 data to the client, whereas the = client would have
configured itself with State-1 data. This doesn't = seem to be a good
situation in the general sense, even if it happens = for a short while.

In case of (c), both client and server will always be = synchronised.
When State-2 happens, server will know exactly which = clients need
updating.

Does this disqualify (b) as an alternative? Or is it = still an acceptable
implementation?

- Ray


----- Original Message -----
From: "Ralph Droms" = <rdroms@cisco.com>
To: "Raymond Jayaraj" = <raymondjayaraj@yahoo.com.sg>
Cc: <dhcwg@ietf.org>; = <jraymond@icr.a-star.edu.sg>
Sent: Friday, October 25, 2002 8:41 PM
Subject: Re: [dhcwg] How should a DHCPv6 server = respond to retransmitted
packets


> In the case of Information-request, the answer = is (b) or (c), depending on
> the implementation.  The responses to = retransmitted Informat-request
> messages are likely to be identical, so the use = of a response cache
> shouldn't affect the results of the message = exchange.
>
> - Ralph
>
> At 10:26 AM 10/25/2002 +0800, Raymond Jayaraj = wrote:
> >Hi all,
> >
> >How should a server respond to = retransmitted packets
> >received after a
> >REPLY packet is sent, e.g.:
> >
> >DHC6CLIENT      = DHC6SERVER      INFOSERVER
> = >|           &= nbsp;   = |            = ;   (e.g. LDAP)
> = >|           &= nbsp;   = |            = ;   |
> >|1)INFO-REQ     = |            = ;   |
> = >|>>>         &= nbsp;  = |            = ;   |
> >|   = >>>         = |            = ;   |
> >|      = >>>      = |            = ;   |
> = >|         = >>>   = |            = ;   |
> = >|            = >>>|2)processing/retrieve info
> >|3)INFO-REQ     = |>>>>>>>>>>>>>>>|
> = >|>>>         &= nbsp;  |<<<<<<<<<<<<<<<= ;|
> >|   = >>>      = <<<|          = ;     |
> >|      = >>><<<   = |            = ;   |
> >|      = <<<>>>   = |            = ;   |
> >|   = <<<      = >>>|          = ;     |
> >|<<< 4)REPLY    = |5)???          |
> >
> >What should (5) be? Should the = server:
> >
> >a) drop (3) and subsequent duplicates (base = on
> >transaction id).
> >
> >b) reprocess the request and retransmit the = reply,
> >i.e. do (2)&(4)
> >    again.
> >
> >c) retransmit the reply, i.e. do (4) = again.
> >
> >d) do any of the above (implementation = specific).
> >
> >No indication for the above could be found = in the
> >draft. I suspect
> >it should be a) or d), but it'd be nice to = know for
> >sure.
> >
> = >--------------------------------------------------------------------= ----
> >Raymond J. = Jayabal           = ;      | ICR, A-STAR
> = >jraymond@icr.a-star.edu.sg       =   | 20 Science Park
> >Rd #02-34/37
> >Tel: +65 6870 = 9330           &n= bsp;     | Singapore 117674
> = >--------------------------------------------------------------------= ----
> >
> >
> >
> >
> = >__________________________________________________
> >Do You Yahoo!?
> >Great flight deals, travel info and = prizes!
> >http://sg.travel.yahoo.com
> = >_______________________________________________
> >dhcwg mailing list
> >dhcwg@ietf.org
> >https://www1.ietf.org/mailman/listinfo/dhcwg

__________________________________________________
Do You Yahoo!?
Great flight deals, travel info and prizes!
http://sg.travel.yahoo.com
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C27DC5.CA7B5A8A-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 28 15:35:53 2002 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 PAA28734; Mon, 28 Oct 2002 15:35: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 g9SKb8v15998; Mon, 28 Oct 2002 15:37: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 g9SKZ1v15800 for ; Mon, 28 Oct 2002 15:35:01 -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 PAA28580 for ; Mon, 28 Oct 2002 15:32:34 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g9SKYtW22610; Mon, 28 Oct 2002 14:34:55 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9SKYs619988; Mon, 28 Oct 2002 14:34:55 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PBJK89>; Mon, 28 Oct 2002 14:34:54 -0600 Message-ID: From: "Bernie Volz (EUD)" To: rdroms@cisco.com Cc: dhcwg@ietf.org Date: Mon, 28 Oct 2002 14:33:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27EC1.53EE71DE" Subject: [dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-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: , 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_01C27EC1.53EE71DE Content-Type: text/plain; charset="iso-8859-1" Ralph: Looks like you've been a bit busy! Regarding this draft, does it make sense when multiple relays are involved to disallow (MUST?) a relay agent from forwarding using IPSec if the relay received the relayed client message without IPSec? (This might also have been a good restriction to add to the DHCPv6 specification.) One potential issue with this is that it would require code changes in the relay or some filtering rules in the stack to assure non-protected relay messages are not processed. But if you don't have it, security could easily be compromised since an attacker can just set up a relay-chaining arrangement. Note that by your description in Section 4, this is already stated but perhaps not as clearly as it should be. Also, we should move to make this a Working Group item. Any objections? - Bernie -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, October 28, 2002 6:27 AM Subject: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use of IPsec for Securing DHCPv4 Messages Exchanged Between Relay Agents and Servers Author(s) : R. Droms Filename : draft-droms-dhcp-relay-agent-ipsec-00.txt Pages : 4 Date : 2002-10-25 'DHCP Relay Agent Information Option' (RFC 3046) assumes that DHCP messages exchanged between relay agents and servers are not subject to attack. This document describes how IPsec can be used to protect messages exchanged between relay agents and servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-droms-dhcp-relay-agent-ipsec-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-droms-dhcp-relay-agent-ipsec-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-droms-dhcp-relay-agent-ipsec-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_001_01C27EC1.53EE71DE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt

Ralph:

Looks like you've been a bit busy!

Regarding this draft, does it make sense when = multiple relays are involved to
disallow (MUST?) a relay agent from forwarding using = IPSec if the relay
received the relayed client message without IPSec? = (This might also have been
a good restriction to add to the DHCPv6 = specification.) One potential issue
with this is that it would require code changes in = the relay or some filtering
rules in the stack to assure non-protected relay = messages are not processed. But
if you don't have it, security could easily be = compromised since an attacker can
just set up a relay-chaining arrangement.

Note that by your description in Section 4, this is = already stated but perhaps
not as clearly as it should be.

Also, we should move to make this a Working Group = item. Any objections?

- Bernie

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Monday, October 28, 2002 6:27 AM
Subject: I-D = ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt


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


        Title           : = Use of IPsec for Securing DHCPv4 Messages Exchanged
          &nb= sp;           &nb= sp;   Between Relay Agents and Servers
        Author(s)       : R. = Droms
        Filename        : = draft-droms-dhcp-relay-agent-ipsec-00.txt
        Pages           : = 4
        Date    =         : 2002-10-25
       =20
'DHCP Relay Agent Information Option' (RFC 3046) = assumes that DHCP
messages exchanged between relay agents and servers = are not subject
to attack.  This document describes how IPsec = can be used to protect
messages exchanged between relay agents and = servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-droms-dhcp-r= elay-agent-ipsec-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-droms-dhcp-relay-agent-ipsec-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-droms-dhcp-relay-agent-ipsec-00.txt".=
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

------_=_NextPart_001_01C27EC1.53EE71DE-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 29 06:19:17 2002 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 GAA28123; Tue, 29 Oct 2002 06:19:17 -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 g9TBKZv04974; Tue, 29 Oct 2002 06:20:35 -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 g9TBIgv04865 for ; Tue, 29 Oct 2002 06:18: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 GAA27515; Tue, 29 Oct 2002 06:16:19 -0500 (EST) Message-Id: <200210291116.GAA27515@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, 29 Oct 2002 06:16:18 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-mipadvert-opt-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 : DHCP Option for Mobile IP Mobility Agents Author(s) : H. Levkowetz Filename : draft-ietf-dhc-mipadvert-opt-00.txt Pages : 9 Date : 2002-10-28 This document defines a new Dynamic Host Configuration Protocol (DHCP) option with suboptions. One suboption is passed from the DHCP Server to the DHCP Client to announce the presence of one or more Mobile IP Mobility Agents. For each announced Mobility Agent, information is provided which is the same as that of the Mobile IP Agent Advertisement extension to ICMP Router Advertisements. There is also one suboption which may be used by a DHCP client to provide identity information to the DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-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-mipadvert-opt-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-mipadvert-opt-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: <2002-10-28162911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-mipadvert-opt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-mipadvert-opt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-28162911.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 Oct 29 06:19:26 2002 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 GAA28167; Tue, 29 Oct 2002 06:19: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 g9TBKmv05022; Tue, 29 Oct 2002 06:20: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 g9TBIqv04873 for ; Tue, 29 Oct 2002 06:18:52 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27549; Tue, 29 Oct 2002 06:16:28 -0500 (EST) Message-Id: <200210291116.GAA27549@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, 29 Oct 2002 06:16:28 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agent-subnet-selection-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: , --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 : Link Selection sub-option for the Relay Agent Information Option for DHCPv4 Author(s) : K. Kinnear, M. Stapp, R. Johnson, J. Kumarasamy Filename : draft-ietf-dhc-agent-subnet-selection-04.txt Pages : 8 Date : 2002-10-28 In RFC 2131, the giaddr specifies an IP address which determines both a subnet and thereby a link on which a DHCP client resides as well as an IP address which can be used to communicate with the relay agent. The subnet-selection option [RFC 3011] allows these functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address which is different from the IP address with which it desires to communicate with the DHCP server. Analgous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides which is different from an IP address which can be used to communicate with the relay agent. The link-selection sub- option (specified here) of the relay-agent-information option allows a relay agent to do this. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-subnet-selection-04.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-agent-subnet-selection-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-subnet-selection-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-28162931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-subnet-selection-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agent-subnet-selection-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-28162931.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 Oct 29 06:19:27 2002 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 GAA28195; Tue, 29 Oct 2002 06:19: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 g9TBKlv05002; Tue, 29 Oct 2002 06:20:47 -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 g9TBIlv04869 for ; Tue, 29 Oct 2002 06:18:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27533; Tue, 29 Oct 2002 06:16:23 -0500 (EST) Message-Id: <200210291116.GAA27533@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, 29 Oct 2002 06:16:23 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-vpn-option-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 : DHCP VPN Information option Author(s) : R. Johnson, K. Kinnear, M. Stapp, J. Kumarasamy Filename : draft-ietf-dhc-vpn-option-02.txt Pages : 6 Date : 2002-10-28 This memo defines a new DHCP option for passing VPN information between the DHCP client and the DHCP server. It is intended for use primarily by DHCP proxy clients in situations where VPN information needs to be passed to the DHCP server for proper address allocation to take place. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-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-vpn-option-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-vpn-option-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: <2002-10-28162920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-vpn-option-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-vpn-option-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-28162920.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 Oct 29 13:03:12 2002 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 NAA16776; Tue, 29 Oct 2002 13:03: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 g9TI4bv28290; Tue, 29 Oct 2002 13:04:37 -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 g9TI3fv28266 for ; Tue, 29 Oct 2002 13:03:41 -0500 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16672 for ; Tue, 29 Oct 2002 13:01:14 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-386.cisco.com [10.82.225.130]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA14393 for ; Tue, 29 Oct 2002 13:03:35 -0500 (EST) Message-Id: <4.3.2.7.2.20021029114502.03af6ae0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Oct 2002 11:55:50 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] First pass at agenda for dhc WG in Atlanta 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's a first (very rough) pass at an agenda for the dhc WG meeting in Atlanta. I apologize for any oversights; please let me know if I've missed a request. - Ralph * Failover status 5 mins * Leasequery status & short discussion 5 (or maybe 10) minutes * subnet-selection-sub-option status 5 minutes * vpn-id (both flavors) 5 minutes status (unless you think people will want to discuss them more) * subnet-allocation I'd guess it will need 10 minutes for introduction if Richard submits this. * server-id-override suboption * host name considerations Carl Smith * DHCPv6 * DHCPv6 PD * DHCPv6 stateless implementation * TTL on DHCPv6 service options * charter/milestones * authentication (?) Ted Lemon * draft-polk-dhcp-geo-loc-00.txt John Schnizlein * IPsec for authentication * Recycling option codes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 29 13:03:16 2002 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 NAA16801; Tue, 29 Oct 2002 13:03: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 g9TI4jv28306; Tue, 29 Oct 2002 13:04: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 g9TI3gv28270 for ; Tue, 29 Oct 2002 13:03:42 -0500 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16673 for ; Tue, 29 Oct 2002 13:01:14 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-386.cisco.com [10.82.225.130]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA14388; Tue, 29 Oct 2002 13:03:34 -0500 (EST) Message-Id: <4.3.2.7.2.20021029101715.00b9e608@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Oct 2002 10:22:16 -0500 To: "Bernie Volz (EUD)" From: Ralph Droms Cc: dhcwg@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-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: , Bernie - thanks for your review and feedback on the IPsec for relay agent draft. I had not intended the text in section 4 to require an unbroken chain of IPsec forwarding (although not using IPsec over every link doesn't make much sense). Are you referring to the following text: If a client message is relayed through multiple relay agents, each of the relay agents must have established independent, pairwise trust relationships. That is, if messages from client C will be relayed by relay agent A to relay agent B and then to the server, relay agents A and B must be configured to use IPSec for the messages they exchange, and relay agent B and the server must be configured to use IPSec for the messages they exchange. I intend the text to describe the use of hop-by-hop IPsec, without an absolute requirement that all hops use IPsec. Not being able to anticipate every possible deployment, I suggest "SHOULD use IPsec on every hop", with some appropriate word-smithing of the spec for clarification. - Ralph At 02:33 PM 10/28/2002 -0600, Bernie Volz (EUD) wrote: >Ralph: > >Looks like you've been a bit busy! > >Regarding this draft, does it make sense when multiple relays are involved to >disallow (MUST?) a relay agent from forwarding using IPSec if the relay >received the relayed client message without IPSec? (This might also have been >a good restriction to add to the DHCPv6 specification.) One potential issue >with this is that it would require code changes in the relay or some >filtering >rules in the stack to assure non-protected relay messages are not >processed. But >if you don't have it, security could easily be compromised since an >attacker can >just set up a relay-chaining arrangement. > >Note that by your description in Section 4, this is already stated but >perhaps >not as clearly as it should be. > >Also, we should move to make this a Working Group item. Any objections? > >- Bernie > >-----Original Message----- >From: Internet-Drafts@ietf.org >[mailto:Internet-Drafts@ietf.org] >Sent: Monday, October 28, 2002 6:27 AM >Subject: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Use of IPsec for Securing DHCPv4 Messages > Exchanged > Between Relay Agents and Servers > Author(s) : R. Droms > Filename : draft-droms-dhcp-relay-agent-ipsec-00.txt > Pages : 4 > Date : 2002-10-25 > >'DHCP Relay Agent Information Option' (RFC 3046) assumes that DHCP >messages exchanged between relay agents and servers are not subject >to attack. This document describes how IPsec can be used to protect >messages exchanged between relay agents and servers. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-droms-dhcp-relay-agent-ipsec-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-droms-dhcp-relay-agent-ipsec-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-droms-dhcp-relay-agent-ipsec-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. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 29 13:33:49 2002 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 NAA18243; Tue, 29 Oct 2002 13:33: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 g9TIZDv29994; Tue, 29 Oct 2002 13:35: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 g9TIYtv29971 for ; Tue, 29 Oct 2002 13:34:55 -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 NAA18168 for ; Tue, 29 Oct 2002 13:32:26 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g9TIYnd14729; Tue, 29 Oct 2002 12:34:49 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9TIYn801672; Tue, 29 Oct 2002 12:34:49 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PDW15G>; Tue, 29 Oct 2002 12:34:48 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" Cc: dhcwg@ietf.org Date: Tue, 29 Oct 2002 12:33:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27F78.E36C5148" Subject: [dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-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: , 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_01C27F78.E36C5148 Content-Type: text/plain; charset="iso-8859-1" Ralph: Yes, that was the text I was referring to. And, I think we are in agreement. I just feel it is better to state it the other way around - a relay agent SHOULD NOT relay a relayed message (giaddr field is no-zero) using IPsec unless the relay received that message secured by IPsec. Without this requirement, what value is there in securing the traffic at a later hop? - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, October 29, 2002 10:22 AM To: Bernie Volz (EUD) Cc: dhcwg@ietf.org Subject: RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt Bernie - thanks for your review and feedback on the IPsec for relay agent draft. I had not intended the text in section 4 to require an unbroken chain of IPsec forwarding (although not using IPsec over every link doesn't make much sense). Are you referring to the following text: If a client message is relayed through multiple relay agents, each of the relay agents must have established independent, pairwise trust relationships. That is, if messages from client C will be relayed by relay agent A to relay agent B and then to the server, relay agents A and B must be configured to use IPSec for the messages they exchange, and relay agent B and the server must be configured to use IPSec for the messages they exchange. I intend the text to describe the use of hop-by-hop IPsec, without an absolute requirement that all hops use IPsec. Not being able to anticipate every possible deployment, I suggest "SHOULD use IPsec on every hop", with some appropriate word-smithing of the spec for clarification. - Ralph At 02:33 PM 10/28/2002 -0600, Bernie Volz (EUD) wrote: >Ralph: > >Looks like you've been a bit busy! > >Regarding this draft, does it make sense when multiple relays are involved to >disallow (MUST?) a relay agent from forwarding using IPSec if the relay >received the relayed client message without IPSec? (This might also have been >a good restriction to add to the DHCPv6 specification.) One potential issue >with this is that it would require code changes in the relay or some >filtering >rules in the stack to assure non-protected relay messages are not >processed. But >if you don't have it, security could easily be compromised since an >attacker can >just set up a relay-chaining arrangement. > >Note that by your description in Section 4, this is already stated but >perhaps >not as clearly as it should be. > >Also, we should move to make this a Working Group item. Any objections? > >- Bernie > >-----Original Message----- >From: Internet-Drafts@ietf.org >[mailto:Internet-Drafts@ietf.org] >Sent: Monday, October 28, 2002 6:27 AM >Subject: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Use of IPsec for Securing DHCPv4 Messages > Exchanged > Between Relay Agents and Servers > Author(s) : R. Droms > Filename : draft-droms-dhcp-relay-agent-ipsec-00.txt > Pages : 4 > Date : 2002-10-25 > >'DHCP Relay Agent Information Option' (RFC 3046) assumes that DHCP >messages exchanged between relay agents and servers are not subject >to attack. This document describes how IPsec can be used to protect >messages exchanged between relay agents and servers. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-droms-dhcp-relay-agent-ipsec-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-droms-dhcp-relay-agent-ipsec-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-droms-dhcp-relay-agent-ipsec-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_001_01C27F78.E36C5148 Content-Type: text/html; charset="iso-8859-1" RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt

Ralph:

Yes, that was the text I was referring to. And, I think we are in agreement. I just
feel it is better to state it the other way around - a relay agent SHOULD NOT relay a
relayed message (giaddr field is no-zero) using IPsec unless the relay received
that message secured by IPsec.

Without this requirement, what value is there in securing the traffic at a later
hop?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, October 29, 2002 10:22 AM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt


Bernie - thanks for your review and feedback on the IPsec for relay agent
draft.

I had not intended the text in section 4 to require an unbroken chain of
IPsec forwarding (although not using IPsec over every link doesn't make
much sense).  Are you referring to the following text:

    If a client message is relayed through multiple relay agents,
    each of the relay agents must have established independent, pairwise
    trust relationships.  That is, if messages from client C will be
    relayed by relay agent A to relay agent B and then to the server,
    relay agents A and B must be configured to use IPSec for the messages
    they exchange, and relay agent B and the server must be configured to
    use IPSec for the messages they exchange.

I intend the text to describe the use of hop-by-hop IPsec, without an
absolute requirement that all hops use IPsec.  Not being able to anticipate
every possible deployment, I suggest "SHOULD use IPsec on every hop", with
some appropriate word-smithing of the spec for clarification.

- Ralph

At 02:33 PM 10/28/2002 -0600, Bernie Volz (EUD) wrote:

>Ralph:
>
>Looks like you've been a bit busy!
>
>Regarding this draft, does it make sense when multiple relays are involved to
>disallow (MUST?) a relay agent from forwarding using IPSec if the relay
>received the relayed client message without IPSec? (This might also have been
>a good restriction to add to the DHCPv6 specification.) One potential issue
>with this is that it would require code changes in the relay or some
>filtering
>rules in the stack to assure non-protected relay messages are not
>processed. But
>if you don't have it, security could easily be compromised since an
>attacker can
>just set up a relay-chaining arrangement.
>
>Note that by your description in Section 4, this is already stated but
>perhaps
>not as clearly as it should be.
>
>Also, we should move to make this a Working Group item. Any objections?
>
>- Bernie
>
>-----Original Message-----
>From: Internet-Drafts@ietf.org
>[<mailto:Internet-Drafts@ietf.org>mailto:Internet-Drafts@ietf.org]
>Sent: Monday, October 28, 2002 6:27 AM
>Subject: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>         Title           : Use of IPsec for Securing DHCPv4 Messages
> Exchanged
>                           Between Relay Agents and Servers
>         Author(s)       : R. Droms
>         Filename        : draft-droms-dhcp-relay-agent-ipsec-00.txt
>         Pages           : 4
>         Date            : 2002-10-25
>
>'DHCP Relay Agent Information Option' (RFC 3046) assumes that DHCP
>messages exchanged between relay agents and servers are not subject
>to attack.  This document describes how IPsec can be used to protect
>messages exchanged between relay agents and servers.
>
>A URL for this Internet-Draft is:
><http://www.ietf.org/internet-drafts/draft-droms-dhcp-relay-agent-ipsec-00.txt>http://www.ietf.org/internet-drafts/draft-droms-dhcp-relay-agent-ipsec-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-droms-dhcp-relay-agent-ipsec-00.txt".
>
>A list of Internet-Drafts directories can be found in
><http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
>or
><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>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-droms-dhcp-relay-agent-ipsec-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_001_01C27F78.E36C5148-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 29 16:42:49 2002 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 QAA26913; Tue, 29 Oct 2002 16:42: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 g9TLi4v08442; Tue, 29 Oct 2002 16:44: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 g9TLglv08338 for ; Tue, 29 Oct 2002 16:42:47 -0500 Received: from mailwest.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26783 for ; Tue, 29 Oct 2002 16:40:18 -0500 (EST) Received: by uniwest1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Oct 2002 16:42:40 -0500 Received: from rhussongpc.dhcp.west.unispherenetworks.com ([10.10.121.9]) by mailwest2.unispherenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VDJM9TSA; Tue, 29 Oct 2002 16:35:32 -0500 From: Richard Hussong To: dhcwg@ietf.org Date: Tue, 29 Oct 2002 16:42:44 -0500 Organization: Juniper Networks, Inc. Message-ID: <310uru0q1a32fthd4qt21qb71h8jhhoelj@4ax.com> X-Mailer: Forte Agent 1.9/32.560 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9TLglv08339 Subject: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.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: , Content-Transfer-Encoding: 8bit To: Ralph Droms I have some comments on the new DHCPv6 draft. I think the changes have improved its clarity quite a bit, but I still see a few problems. Actually, some of these were in the previous draft; I'm sorry I didn't find them there and bring them to your attention, but I haven't been on this stuff for long. First, a general comment: since IPv6 has stateless address auto-configuration, and small routers are becoming increasingly common, even in homes, isn't it possible, even likely, that the main use of DHCPv6 will be for prefix delegation rather than address assignment? If this is the case, it seems unfortunate that prefix delegation is not in this document, since that fact makes it appear that it is of lower status or importance than the address assignment that is in the document. I am sure there are sound historical reasons for putting prefix delegation in a separate document (including the controversy over whether prefix delegation should be handled by DHCPv6 at all), but there are so many parallels between address assignment and prefix delegation that it seems a shame not to treat them in a parallel fashion. The rest of the comments are on particular sections of the draft. ============= Section 1.3, "Client-server Exchanges Involving Four Messages" Typo in Paragraph 2: "the client sends a Renew messages ..."; "messages" should be "message". ============= Section 16. Client Source Address and Interface Selection Typo in Paragraph 1: "... is certain the two interface are ..."; "interface" should be "interfaces". ============= Section 17.1.1. Creation of Solicit Messages In Paragraph 4: The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. This states that the Option Request option is required in a Solicit message. However, Section 22.7 says: A client MAY include an Option Request option in a Solicit, Request, Renew, Rebind, Confirm or Information-request message to inform the server about options the client wants the server to send to the client. This implies that the Option Request option is not required in a Solicit message. Should the server treat a Solicit message without an Option Request option as invalid? If the client includes instances of particular options without listing their codes in the Option Request option, should those options be ignored? ============= Section 17.1.1. Creation of Solicit Messages In Paragraph 5: The client MUST include a Reconfigure Accept option (see section 22.20) indicating whether or not the client is willing to accept Reconfigure messages from the server. This states that the Reconfigure Accept option is required in a Solicit message. However, Section 22.20 says: The default behavior, in the absence of this option, means unwillingness to accept Reconfigure messages, or instruction not to accept Reconfigure messages, for the client and server messages, respectively. This implies that the Reconfigure Accept option is not required in a Solicit message. Should the server treat a Solicit message without a Reconfigure Accept option as invalid? ============= Section 18.1.5. Creation and Transmission of Information Request Messages In Paragraph 5: The first Information-request message from the client on the interface MUST be delayed by a random amount of time between 0 and INF_MAX_DELAY. It is not specified what event defines the start of the delay period. I imagine the intent is that the delay starts from the "interface up" event. Is that true, and would there be any value in making it explicit? ============= Section 18.1.8. Receipt of Reply Messages Paragraph 3, bullet 4: - Discard any addresses from the IA as recorded by the client that have a lifetime of 0 in the IA Address option Just for clarity, perhaps "lifetime" should be "valid lifetime"? ============= Section 18.2.8. Transmission of Reply Messages Typo in Paragraph 2: "see Section!22.10" should be "see Section 22.10". ============= Section 22.4. Identity Association for Non-temporary Addresses Option In the next-to-last paragraph, In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters. However, in the last paragraph, If the time at which the addresses in an IA_NA are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. I suspect the intent of the extract from the next-to-last paragraph is something like "In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters, unless they are 0", right? ============= Section 22.6. IA Address Option In Paragraph 3: 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. Just for clarity, it might be useful to note here than a valid lifetime field value of 0 has the special meaning of "stop using this address", even though that is the natural consequence of a valid lifetime of 0. It would be even handier if a cross-reference were included to Section 18.1.8, which discusses the Reply message that might actually use such 0 lifetime values. ============= Section 22.6. IA Address Option Typo in Paragraph 3: "More than one IA Address Options can appear"; "Options" should be "Option". ============= - Richard Hussong _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 29 17:20:48 2002 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 RAA29528; Tue, 29 Oct 2002 17:20: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 g9TMMIv10764; Tue, 29 Oct 2002 17:22: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 g9TMKpv10672 for ; Tue, 29 Oct 2002 17:20:51 -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 RAA29406 for ; Tue, 29 Oct 2002 17:18:22 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g9TMKid00773; Tue, 29 Oct 2002 16:20:44 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9TMKhG16360; Tue, 29 Oct 2002 16:20:43 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <41PDWSZ1>; Tue, 29 Oct 2002 16:20:43 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Richard Hussong'" , dhcwg@ietf.org Subject: RE: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt Date: Tue, 29 Oct 2002 16:19:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27F99.470676C8" 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_01C27F99.470676C8 Content-Type: text/plain; charset="iso-8859-1" Richard: Thanks for the corrections ... The prefix delegation came after much of the core work on the DHCPv6 protocol was far along. And, as it is still debated as to how best to accomplish this, we felt it best to keep it out of the base specification. Regarding 18.1.5, see 17.1.2 as this explains the delay start. Perhaps we should add a reference to 17.1.2 here or cut and paste the text. If a -28 is done (or during the RFC editing process assuming the IESG accepts this draft), we will look to clarify this (and the other corrections). Regarding 17.1.1 and 22.7 (ORO option), I think we can change it to a SHOULD for the Solicit message. I don't see that this is a MUST. (Section 15.2 does not indicate that no ORO means drop the message.) Regarding 17.1.1 and Reconfigure Accept option, this is an error and should be modified to read that the option is included only if the client desires to have the server make use of Reconfigure. At one time this option contained a flag byte which indicated whether Reconfigure was or was not supported and this was not properly updated then the option was changed. Regarding the issue with Section 22.4, a T1/T2 of 0 means don't renew. It is client implementation specific as to how it deals with this (whether it uses 0 to mean don't renew and don't start a timer) or does something else (such as using very large values). - Bernie -----Original Message----- From: Richard Hussong [mailto:rhussong@juniper.net] Sent: Tuesday, October 29, 2002 4:43 PM To: dhcwg@ietf.org Subject: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt To: Ralph Droms I have some comments on the new DHCPv6 draft. I think the changes have improved its clarity quite a bit, but I still see a few problems. Actually, some of these were in the previous draft; I'm sorry I didn't find them there and bring them to your attention, but I haven't been on this stuff for long. First, a general comment: since IPv6 has stateless address auto-configuration, and small routers are becoming increasingly common, even in homes, isn't it possible, even likely, that the main use of DHCPv6 will be for prefix delegation rather than address assignment? If this is the case, it seems unfortunate that prefix delegation is not in this document, since that fact makes it appear that it is of lower status or importance than the address assignment that is in the document. I am sure there are sound historical reasons for putting prefix delegation in a separate document (including the controversy over whether prefix delegation should be handled by DHCPv6 at all), but there are so many parallels between address assignment and prefix delegation that it seems a shame not to treat them in a parallel fashion. The rest of the comments are on particular sections of the draft. ============= Section 1.3, "Client-server Exchanges Involving Four Messages" Typo in Paragraph 2: "the client sends a Renew messages ..."; "messages" should be "message". ============= Section 16. Client Source Address and Interface Selection Typo in Paragraph 1: "... is certain the two interface are ..."; "interface" should be "interfaces". ============= Section 17.1.1. Creation of Solicit Messages In Paragraph 4: The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. This states that the Option Request option is required in a Solicit message. However, Section 22.7 says: A client MAY include an Option Request option in a Solicit, Request, Renew, Rebind, Confirm or Information-request message to inform the server about options the client wants the server to send to the client. This implies that the Option Request option is not required in a Solicit message. Should the server treat a Solicit message without an Option Request option as invalid? If the client includes instances of particular options without listing their codes in the Option Request option, should those options be ignored? ============= Section 17.1.1. Creation of Solicit Messages In Paragraph 5: The client MUST include a Reconfigure Accept option (see section 22.20) indicating whether or not the client is willing to accept Reconfigure messages from the server. This states that the Reconfigure Accept option is required in a Solicit message. However, Section 22.20 says: The default behavior, in the absence of this option, means unwillingness to accept Reconfigure messages, or instruction not to accept Reconfigure messages, for the client and server messages, respectively. This implies that the Reconfigure Accept option is not required in a Solicit message. Should the server treat a Solicit message without a Reconfigure Accept option as invalid? ============= Section 18.1.5. Creation and Transmission of Information Request Messages In Paragraph 5: The first Information-request message from the client on the interface MUST be delayed by a random amount of time between 0 and INF_MAX_DELAY. It is not specified what event defines the start of the delay period. I imagine the intent is that the delay starts from the "interface up" event. Is that true, and would there be any value in making it explicit? ============= Section 18.1.8. Receipt of Reply Messages Paragraph 3, bullet 4: - Discard any addresses from the IA as recorded by the client that have a lifetime of 0 in the IA Address option Just for clarity, perhaps "lifetime" should be "valid lifetime"? ============= Section 18.2.8. Transmission of Reply Messages Typo in Paragraph 2: "see Section!22.10" should be "see Section 22.10". ============= Section 22.4. Identity Association for Non-temporary Addresses Option In the next-to-last paragraph, In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters. However, in the last paragraph, If the time at which the addresses in an IA_NA are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. I suspect the intent of the extract from the next-to-last paragraph is something like "In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters, unless they are 0", right? ============= Section 22.6. IA Address Option In Paragraph 3: 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. Just for clarity, it might be useful to note here than a valid lifetime field value of 0 has the special meaning of "stop using this address", even though that is the natural consequence of a valid lifetime of 0. It would be even handier if a cross-reference were included to Section 18.1.8, which discusses the Reply message that might actually use such 0 lifetime values. ============= Section 22.6. IA Address Option Typo in Paragraph 3: "More than one IA Address Options can appear"; "Options" should be "Option". ============= - Richard Hussong _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C27F99.470676C8 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt

Richard:

Thanks for the corrections ...

The prefix delegation came after much of the core work on the DHCPv6 protocol was far
along. And, as it is still debated as to how best to accomplish this, we felt it best
to keep it out of the base specification.

Regarding 18.1.5, see 17.1.2 as this explains the delay start. Perhaps we should add
a reference to 17.1.2 here or cut and paste the text. If a -28 is done (or during the
RFC editing process assuming the IESG accepts this draft), we will look to clarify
this (and the other corrections).

Regarding 17.1.1 and 22.7 (ORO option), I think we can change it to a SHOULD for the
Solicit message. I don't see that this is a MUST. (Section 15.2 does not indicate that
no ORO means drop the message.)

Regarding 17.1.1 and Reconfigure Accept option, this is an error and should be modified
to read that the option is included only if the client desires to have the server make
use of Reconfigure. At one time this option contained a flag byte which indicated whether
Reconfigure was or was not supported and this was not properly updated then the option
was changed.

Regarding the issue with Section 22.4, a T1/T2 of 0 means don't renew. It is client
implementation specific as to how it deals with this (whether it uses 0 to mean don't
renew and don't start a timer) or does something else (such as using very large values).

- Bernie

-----Original Message-----
From: Richard Hussong [mailto:rhussong@juniper.net]
Sent: Tuesday, October 29, 2002 4:43 PM
To: dhcwg@ietf.org
Subject: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt


To: Ralph Droms <rdroms@cisco.com>

I have some comments on the new DHCPv6 draft.  I think the changes have
improved its clarity quite a bit, but I still see a few problems.
Actually, some of these were in the previous draft; I'm sorry I didn't find
them there and bring them to your attention, but I haven't been on this
stuff for long.

First, a general comment:  since IPv6 has stateless address
auto-configuration, and small routers are becoming increasingly common,
even in homes, isn't it possible, even likely, that the main use of DHCPv6
will be for prefix delegation rather than address assignment?  If this is
the case, it seems unfortunate that prefix delegation is not in this
document, since that fact makes it appear that it is of lower status or
importance than the address assignment that is in the document.  I am sure
there are sound historical reasons for putting prefix delegation in a
separate document (including the controversy over whether prefix delegation
should be handled by DHCPv6 at all), but there are so many parallels
between address assignment and prefix delegation that it seems a shame not
to treat them in a parallel fashion.

The rest of the comments are on particular sections of the draft.

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

Section 1.3, "Client-server Exchanges Involving Four Messages"

Typo in Paragraph 2: "the client sends a Renew messages ..."; "messages"
should be "message".

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

Section 16. Client Source Address and Interface Selection

Typo in Paragraph 1: "... is certain the two interface are ...";
"interface" should be "interfaces".

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

Section 17.1.1. Creation of Solicit Messages

In Paragraph 4:

  The client MUST include an Option Request option (see section 22.7)
  to indicate the options the client is interested in receiving.

This states that the Option Request option is required in a Solicit
message.  However, Section 22.7 says:

  A client MAY include an Option Request option in a Solicit, Request,
  Renew, Rebind, Confirm or Information-request message to inform
  the server about options the client wants the server to send to
  the client.

This implies that the Option Request option is not required in a Solicit
message.

Should the server treat a Solicit message without an Option Request option
as invalid?  If the client includes instances of particular options without
listing their codes in the Option Request option, should those options be
ignored?

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

Section 17.1.1. Creation of Solicit Messages

In Paragraph 5:

  The client MUST include a Reconfigure Accept option (see
  section 22.20) indicating whether or not the client is willing to
  accept Reconfigure messages from the server.

This states that the Reconfigure Accept option is required in a Solicit
message.  However, Section 22.20 says:

  The default behavior, in the absence of this
  option, means unwillingness to accept Reconfigure messages, or
  instruction not to accept Reconfigure messages, for the client and
  server messages, respectively.

This implies that the Reconfigure Accept option is not required in a
Solicit message.

Should the server treat a Solicit message without a Reconfigure Accept
option as invalid?

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

Section 18.1.5. Creation and Transmission of Information Request Messages

In Paragraph 5:

  The first Information-request message from the client on the interface
  MUST be delayed by a random amount of time between 0 and INF_MAX_DELAY.

It is not specified what event defines the start of the delay period.  I
imagine the intent is that the delay starts from the "interface up" event.
Is that true, and would there be any value in making it explicit?

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

Section 18.1.8. Receipt of Reply Messages

Paragraph 3, bullet 4:

    -  Discard any addresses from the IA as recorded by the client that
       have a lifetime of 0 in the IA Address option

Just for clarity, perhaps "lifetime" should be "valid lifetime"?

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

Section 18.2.8. Transmission of Reply Messages

Typo in Paragraph 2: "see Section!22.10" should be "see Section 22.10".

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

Section 22.4. Identity Association for Non-temporary Addresses Option

In the next-to-last paragraph,

  In a message sent by a server to a client, the client MUST use the
  values in the T1 and T2 fields for the T1 and T2 parameters.

However, in the last paragraph,

   If the time at which the addresses in an IA_NA are to be renewed is
   to be left to the discretion of the client, the server sets T1 and T2
   to 0.

I suspect the intent of the extract from the next-to-last paragraph is
something like "In a message sent by a server to a client, the client MUST
use the values in the T1 and T2 fields for the T1 and T2 parameters, unless
they are 0", right?

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

Section 22.6. IA Address Option

In Paragraph 3:

  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.

Just for clarity, it might be useful to note here than a valid lifetime
field value of 0 has the special meaning of "stop using this address", even
though that is the natural consequence of a valid lifetime of 0.  It would
be even handier if a cross-reference were included to Section 18.1.8, which
discusses the Reply message that might actually use such 0 lifetime values.

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

Section 22.6. IA Address Option

Typo in Paragraph 3: "More than one IA Address Options can appear";
"Options" should be "Option".

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

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

------_=_NextPart_001_01C27F99.470676C8-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 30 07:50:11 2002 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 HAA12281; Wed, 30 Oct 2002 07:50:10 -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 g9UCpPv32497; Wed, 30 Oct 2002 07:51: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 g9UCmKv32380 for ; Wed, 30 Oct 2002 07:48:20 -0500 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12177 for ; Wed, 30 Oct 2002 07:45:54 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-506.cisco.com [10.82.225.250]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA17723; Wed, 30 Oct 2002 07:40:47 -0500 (EST) Message-Id: <4.3.2.7.2.20021029153741.03b963b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Oct 2002 15:39:01 -0500 To: Alex Robertson From: Ralph Droms Subject: Re: [dhcwg] two dhcp server Cc: dhcwg@ietf.org In-Reply-To: <3DB94FBB.AED5CA04@microlink.com.br> 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: , The dhc WG has a specification for a DHCP failover protocol as a work item. The spec should be republished as an Internet Draft soon. The protocol will be discussed at the upcoming IETF meeting in Atlanta. - Ralph At 11:05 AM 10/25/2002 -0300, Alex Robertson wrote: >Hi all, > >Sorry if this is not the correct place for asking this kind of question. >If not, please, tell me the right address. > >I would like to have two dhcp servers. If one crashes, the other assume. >How can i do that without getting machines confused with their ip's? >I didn't find anything in the web. Is there a location where i can find >this information? > >thanks in advance. > >-- >Alex G Robertson >NOC - Microlink >_______________________________________________ >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 Oct 30 11:13:45 2002 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 LAA22450; Wed, 30 Oct 2002 11:13: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 g9UGF6v13560; Wed, 30 Oct 2002 11:15: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 g9UGCwv13470 for ; Wed, 30 Oct 2002 11:12:58 -0500 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22268 for ; Wed, 30 Oct 2002 11:10:29 -0500 (EST) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-120.cisco.com [161.44.149.120]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA04464 for ; Wed, 30 Oct 2002 11:12:51 -0500 (EST) Message-Id: <4.3.2.7.2.20021030110943.02715530@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Oct 2002 11:12:50 -0500 To: dhcwg@ietf.org From: Paul Duffy Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_12293607==_" Subject: [dhcwg] Cablelabs Client Configuration Option - draft 4. 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: , --=====================_12293607==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Please accept the following updated draft for consideration by the DHC working group. It was inadvertently posted to internet-drafts@ietf.org about 90 minutes after the November deadline expired. Thank You, --=====================_12293607==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-dhc-packetcable-04.txt" Internet Engineering Task Force B. Beser INTERNET DRAFT Juniper Networks DHC Working Group P. Duffy (ed.) Document: draft-ietf-dhc-packetcable-04.txt Cisco Systems October 2002 DHCP Option for CableLabs Client Configuration 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document defines a 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. 3. Table of Contents 1. Status of this Memo..........................................1 2. Abstract.....................................................1 3. Table of Contents............................................1 4. Conventions used in this document............................2 5. Terminology..................................................2 6. Introduction.................................................2 7. CableLabs Client Configuration Option Format.................4 8. CableLabs Client Configuration Option: Sub-Option Definitions 5 8.1. TSP's DHCP Server Address Sub-Options.......................5 Beser & Duffy 1 Internet Draft DHCP Option for CableLabs Clients October 2002 8.2. TSP's Provisioning Server Address Sub-Option................5 8.3. TSP's AS-REQ/AS-REP Backoff and Retry.......................6 8.4. TSP's AP-REQ/AP-REP Backoff and Retry.......................7 8.5. TSP's Kerberos Realm Name Sub-Option........................7 8.6. TSP's Ticket Granting Server Utilization Sub-Option.........8 8.7. TSP's Provisioning Timer Sub-Option.........................8 9. Informational Description of CCC Option Usage................8 10. IANA Considerations..........................................9 11. Legacy Use Information.......................................9 12. Procedure for Adding Additional Sub-options..................9 13. Security Considerations......................................9 14. References..................................................10 15. Acknowledgments.............................................11 16. Author's Addresses..........................................11 17. Full Copyright Statement....................................11 4. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 5. Terminology Definitions of terms used throughout this document: * "Telephony Service Provider" or "TSP" The business entity from which a subscriber receives telephony service. See RFC 2131[6] for additional DHCP terminology. 6. Introduction Cable Television Laboratories, Inc. (CableLabs) is a non-profit research and development consortium that serves the cable television industry via design and specification of new and emerging broadband service architectures. Several CableLabs initiatives define DHCP clients that have specific DHCP configuration requirements. One such initiative is the PacketCable project. The PacketCable project is aimed at architecting, qualifying, and supporting Internet-based multimedia services over cable-based packet networks. These new multimedia services will include telephony and videoconferencing, delivered using the basic Internet Protocol (IP) technology that is used to send data via the Internet. Beser & Duffy Expires April 2003 2 Internet Draft DHCP Option for CableLabs Clients October 2002 PacketCable 1.0 provides Voice over IP (VoIP) service delivery. The VoIP service is supported at the customer site by two key components: a Cable Modem (CM) and a Media Terminal Adapter (MTA). The CM converts the cable RF signals to/from various IP voice protocols, while the MTA converts the VoIP protocols into analog telephony compatible with a common telephone. The CM and MTA may be packaged together or separately. If packaged together, the unit is referred to as an Embedded-MTA (EMTA - depicted in Figure 1). If packaged separately, the MTA is referred to as a Standalone MTA (SMTA). |----------------------------------------------| | | | |-----------| |-------------| | | | | | | | Telephony | | Media | internal | Cable | | RF Link ---------_|---| Terminal |===========| Modem |----|------- Link | | Adapter | connection| | | | |-----------| |-------------| | | | |----------------------------------------------| Figure 1. PacketCable 1.0 Embedded-MTA The CM and MTA are distinct IP devices: each has its own MAC address and IP configuration. The CM and MTA utilize the DHCP protocol to obtain IP configuration. It is assumed that the CM and MTA may be administered by different business entities. The CM communicates with and is configured by the data access provider's DHCP servers. Likewise, the MTA communicates with and is configured by the Telephony Service Provider's (TSP's) DHCP servers. The PacketCable architecture requires that the business entity controlling configuration of the CM also determines which business entities control the configuration of the MTA. This is similar to the example found in the PSTN system: individuals can pick their long distance carriers even though the ultimate control of their telephone remains with the local carrier. Due to specific needs of the MTA configuration process (described in [7]), a new CableLabs Client Configuration (CCC) option is needed for the DHCP protocol. Both CM and MTA DHCP clients will request this option. When requested, both the CM and TSP DHCP servers will populate this option into DHCP responses. See section 9 for further operational details. It should be noted that, although the CCC option will be initially deployed to support PacketCable VOIP applications, the CCC option will also be used to support various non VOIP applications. Use of the CCC option does not necessarily mean that the service provider is a TSP. Beser & Duffy Expires April 2003 3 Internet Draft DHCP Option for CableLabs Clients October 2002 7. CableLabs Client Configuration Option Format The option begins with a tag octet containing the option code (code TBD). A length octet follows the tag octet. The value of the length octet does not include itself or the tag octet. The length octet is followed by "length" octets of sub-option content (total length, not sub-option count). The option layout is depicted below: +------+--------+--------------+--------------+---+--------------+ | Code | Length | Sub-option 1 | Sub-option 2 |...| Sub-option n | +------+--------+--------------+--------------+---+--------------+ When the total length of a CCC option exceeds 255 octets, the procedure outlined in [4] SHOULD be employed to split the option into multiple, smaller options. A sub-option begins with a tag octet containing the sub-option code. A length octet follows the tag octet. The value of the length octet does not include itself or the tag octet. The length octet is followed by "length" octets of sub-option information. The sub- option layout is depicted below: +-------------------+--------+------------------------+ | Sub-option Code | Length | Sub-option information | +-------------------+--------+------------------------+ The sub-option codes are summarized below. +---------+---------+--------------------------------------------+ | Sub- | Sent to | Description | | option | | | | Code | | | +===================+============================================+ | 1 | CM | TSP's Primary DHCP Server Address | +---------+---------+--------------------------------------------+ | 2 | CM | TSP's Secondary DHCP Server Address | +---------+---------+--------------------------------------------+ | 3 | MTA | TSP's Provisioning Server Address | +---------+---------+--------------------------------------------+ | 4 | MTA | TSP's AS-REQ/AS-REP Backoff and Retry | +---------+---------+--------------------------------------------+ | 5 | MTA | TSP's AP-REQ/AP-REP Backoff and Retry | +---------+---------+--------------------------------------------+ | 6 | MTA | TSP's Kerberos Realm Name | +---------+---------+--------------------------------------------+ | 7 | MTA | TSP's Ticket Granting Server Utilization | +---------+---------+--------------------------------------------+ | 8 | MTA | TSP's Provisioning Timer Value | +---------+---------+--------------------------------------------+ | 9 - 255 | | Reserved for future extensions | +---------+---------+--------------------------------------------+ Beser & Duffy Expires April 2003 4 Internet Draft DHCP Option for CableLabs Clients October 2002 8. CableLabs Client Configuration Option: Sub-Option Definitions The following sections provide detailed descriptions of each sub- option. There are a few general formatting rules: - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035 [3] section 3.1. Note that a terminating 0 is required. Also note that compression, as described in RFC 1035 [3] section 4.1.4, MUST NOT be applied. - IPv4 addresses MUST be encoded as 4 binary octets in network byte- order (high order byte first). - All multi-octet quantities MUST be encoded per network byte- ordering. 8.1. TSP's DHCP Server Address Sub-Options The TSP DHCP Server Address sub-options identify the DHCP servers from which an MTA is permitted to accept a DHCP OFFER.. Sub-option 1 is the address of the TSP's primary DHCP server. Sub-option 2 is the address of the TSP's secondary DHCP server. The sub-option length MUST be 4 and the sub-option MUST include the DHCP server's IPv4 address as follows: Code Len Address +-----+-----+-----+-----+-----+-----+ | 1/2 | 4 | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+ 8.2. TSP's Provisioning Server Address Sub-Option This option contains the address of the TSP's Provisioning server. MTAs communicate with the Provisioning server at various stages in their provisioning process. The address can be configured as either an IPv4 address or as an FQDN. The encoding of sub-option 3 will adhere to one of 2 formats. 1. IPv4 address. The sub-option length MUST be 5. The length octet MUST be followed by a single octet that indicates the specific address type that follows. This type octet MUST be set to 0 to indicate an IPv4 address. The type octet MUST be followed by 4 octets of IPv4 address: Code Len Type Address +-----+-----+-----+-----+-----+-----+-----+ | 3 | 5 | 0 | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+-----+ Beser & Duffy Expires April 2003 5 Internet Draft DHCP Option for CableLabs Clients October 2002 2. FQDN. The length octet MUST be followed by a single octet that indicates the specific address type that follows. This type octet MUST be set to 1 to indicate an FQDN. The type octet MUST be followed by the encoded FQDN: Code Len Type FQDN +-----+-----+-----+-----+-----+ +-----+ | 3 | n+1 | 1 | f1 | f2 |...| fn | +-----+-----+-----+-----+-----+ +-----+ It is not anticipated that additional type codes, beyond IPv4 (0) and FQDN (1), will be required. Thus, IANA will not be required to maintain a registry of type codes. 8.3. TSP's AS-REQ/AS-REP Backoff and Retry This sub-option configures an MTA's Kerberos AS-REQ/AS-REP timeout, backoff, and retry mechanism. RFC-1510 [5] does not define a backoff/retry mechanism to be employed when an AS-REQ/AS-REP message exchange fails. This sub- option contains parameters required by the backoff/retry mechanism outlined in [8]. The encoding of this sub-option is depicted below: Code Len Nom Timeout Max Timeout Max Retries +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 4 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ The length octet of this sub-option MUST contain the value 12. The length octet MUST be followed by 4 octets containing the AS- REQ/AS-REP nominal (initial) timeout value. This value is a 32 bit unsigned quantity in units of seconds. The next 4 octets MUST contain the AS-REQ/AS-REP maximum timeout value. This value is a 32 bit unsigned quantity in units of seconds The final 4 octets MUST contain the AS-REQ/AS-REP maximum retry count. This value is a 32 bit unsigned quantity. Beser & Duffy Expires April 2003 6 Internet Draft DHCP Option for CableLabs Clients October 2002 8.4. TSP's AP-REQ/AP-REP Backoff and Retry This sub-option configures an MTA's Kerberos AP-REQ/AP-REP timeout, backoff, and retry mechanism. RFC-1510 [5] does not define a backoff/retry mechanism to be employed when an AP-REQ/AP-REP message exchange fails. This sub- option contains parameters required by the backoff/retry mechanism outlined in [8]. The encoding of this sub-option is depicted below: Code Len Nom Timeout Max Timeout Max Retries +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 5 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ The length octet of this sub-option MUST contain the value 12. The length octet MUST be followed by 4 octets containing the AP- REQ/AP-REP nominal (initial) timeout value. This value is a 32 bit unsigned quantity in units of seconds. The next 4 octets MUST contain the AP-REQ/AP-REP maximum timeout value. This value is a 32 bit unsigned quantity in units of seconds. The final 4 octets MUST contain the AP-REQ/AP-REP maximum retry count. This value is a 32 bit unsigned quantity. 8.5. TSP's Kerberos Realm Name Sub-Option The PacketCable architecture requires an MTA to authenticate itself to the TSP's network via the Kerberos protocol. A Kerberos Realm name is required at the MTA to permit a DNS lookup for the address of the TSP's Kerberos Key Distribution Center (KDC) entity. The Kerberos Realm name MUST be encoded per the domain style realm name described in RFC 1510 [5]. This realm name MUST be all capital letters and conform to the syntax described in RFC 1035 [3] section 3.1. The sub-option is encoded as follows: Code Len Kerberos Realm Name +-----+-----+-----+-----+ +-----+ | 6 | n | k1 | k2 |...| kn | +-----+-----+-----+-----+ +-----+ Beser & Duffy Expires April 2003 7 Internet Draft DHCP Option for CableLabs Clients October 2002 8.6. TSP's Ticket Granting Server Utilization Sub-Option This sub-option encodes a boolean value which indicates whether an MTA should or should not utilize a TGT (Ticket Granting Ticket) when obtaining a service ticket for one of the PacketCable application servers. The encoding is as follows: Code Len Value +-----+-----+-----+ | 7 | 1 | 1/0 | +-----+-----+-----+ The length MUST be 1. The last octet contains a Boolean value which MUST be either 0 or 1. A value of 1 MUST be interpreted as true. A value of 0 MUST be interpreted as false. 8.7. TSP's Provisioning Timer Sub-Option The provisioning timer defines the maximum time allowed for the MTA provisioning process to complete. If this timer expires before the MTA has completed the provisioning process, the MTA should reset the timer and re-start its provisioning process from the beginning. The sub-option length MUST be 1 and a value between 1 and 30 (minutes, inclusive) MUST be used. If any other value is specified, the MTA MUST treat the sub-option as non-populated. Code Len Value +-----+-----+---------+ | 8 | 1 | (1..30) | +-----+-----+---------+ 9. Informational Description of CCC Option Usage. Cablelabs client devices issue DHCP requests that include DHCP options 55 (Parameter Request List) and 60 (Vendor Class Identifier). Option 55 will request the CCC option from the DHCP server. Option 60 will indicate the specific Cablelabs client device type, thus directing the DHCP server to populate specific CCC sub-option content in its responses. The details of which CCC sub- options are populated for each specific client type are specified in various Cablelabs project specifications. For example, specific usage of the CCC option for the PacketCable project is described in [7]. Note that client devices never populate the CCC option in their DHCP requests. Beser & Duffy Expires April 2003 8 Internet Draft DHCP Option for CableLabs Clients October 2002 10. IANA Considerations IANA has assigned a value of TBD for the DHCP option code described in this document. 11. Legacy Use Information The CableLabs Client Configuration option initially used the site- specific option value of 177 (0xB1). The use of the site-specific option is to be deprecated when IANA issues an official option number. 12. Procedure for Adding Additional Sub-options IANA is requested to maintain a new number space of "CableLabs Client Configuration Sub-options", located in the BOOTP-DHCP Parameters Registry. The initial sub-option codes are described in sections of this document. IANA is requested to register codes for future CableLabs Client Configuration Sub-options with an "Expert Review" approval policy as described in RFC 2434 [2]. Future proposed sub-options will be assigned a numeric code chosen by CableLabs, which will be documented in the Internet Drafts that describe the sub-options. The code assignment will be reviewed by a designated expert from the IETF prior to publication in an RFC. 13. Security Considerations Potential exposures to attack in the DHCP protocol are discussed in section 7 of the DHCP protocol specification [6] and in Authentication for DHCP Messages [9]. The CCC option can be used to misdirect network traffic by providing incorrect DHCP server addresses, incorrect provisioning server addresses, and incorrect Kerberos realm names to a Cablelabs client device. This misdirection can lead to several threat scenarios. A Denial of Service (DoS) attack can result from address information being simply valid. A man-in-the-middle attack can be mounted by providing addresses to a potential snooper. A malicious TSP can steal customers from the customer selected TSP, by altering the Kerberos realm designation. These threats are mitigated by several factors. Within the cable delivery architecture required by PacketCable, the DHCP client is connected to a network through a cable modem and the CMTS (head-end). The CMTS is explicitly configured with a set of Beser & Duffy Expires April 2003 9 Internet Draft DHCP Option for CableLabs Clients October 2002 DHCP servers to which DHCP requests are forwarded. Further, a correctly configured CMTS will only allow downstream traffic from specific IP addresses/ranges. Assuming that server addresses and Kerberos realm name were successfully spoofed to the point that a malicious client device was able to contact a KDC, the client device must still present valid certificates to the KDC before being service enabled. Given the computational overhead of the certificate validation process, this situation could present a DoS opportunity. Finally, it is possible for a malicious (although certified) TSP to redirect a customer from the customer's selected TSP. It is assumed that all TSP's permitted onto an access providers network are trusted entities that will cooperate to insure peaceful coexistence. If a TSP is found to be redirecting customers, this should be handled as an administrative matter between the access provider and the TSP. 14. References 14.1. Normative 1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 2. T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. 3. P. Mockapetris, "Domain Names - Implementation and Specification ", RFC 1035, November 1987 4. T. Lemon and S. Cheshire, "Encoding Long Options in DHCPv4", draft-ietf-dhc-concat-05.txt, September 2002. 5. J. Kohl and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. 6. R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March 1997. 14.2. Informational 7. "PacketCable MTA Device Provisioning Specification", PKT-SP-PROV- I04-021018. http://www.packetcable.com/specifications.html 8. "PacketCable Security Specification", PKT-SP-SEC-I06-021018, http://www.packetcable.com/specifications.html Beser & Duffy Expires April 2003 10 Internet Draft DHCP Option for CableLabs Clients October 2002 9. R. Droms and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001 15. Acknowledgments The authors would like to extend a heartfelt thanks to all those who contributed to the development of the PacketCable Provisioning specifications: Sumanth Channabasappa (Alopa Networks); Angela Lyda, Rick Morris, Rodney Osborne (Arris Interactive); Steven Bellovin and Chris Melle (AT&T); Eugene Nechamkin (Broadcom); John Berg, Maria Stachelek, Matt Osman (CableLabs); Klaus Hermanns, Azita Kia, Michael Thomas, Paul Duffy (Cisco); Deepak Patil (Com21); Jeff Ollis, Rick Vetter (General Instrument/Motorola); Roger Loots, David Walters (Lucent); Peter Bates (Telcordia); Patrick Meehan (Tellabs); Satish Kumar, Itay Sherman, Roy Spitzer (Telogy/TI), Aviv Goren (Terayon); Prithivraj Narayanan (Wipro); and Rich Woundy (AT&T Broadband). 16. Author's Addresses Burcak Beser Juniper Networks 1194 North Matilda Avenue Sunnyvale, CA, 94089 Email: burcak@juniper.net Paul Duffy Cisco Systems 300 Apollo Drive Chelmsford, MA, 01824 Email: paduffy@cisco.com 17. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Beser & Duffy Expires April 2003 11 Internet Draft DHCP Option for CableLabs Clients October 2002 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Beser & Duffy Expires April 2003 12 --=====================_12293607==_ Content-Type: text/plain; charset="us-ascii"; format=flowed -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com --=====================_12293607==_-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 30 16:46:45 2002 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 QAA14136; Wed, 30 Oct 2002 16:46: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 g9ULlxv04775; Wed, 30 Oct 2002 16: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 g9ULinv04712 for ; Wed, 30 Oct 2002 16:44:49 -0500 Received: from wells.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14035 for ; Wed, 30 Oct 2002 16:42:19 -0500 (EST) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA04849; Wed, 30 Oct 2002 13:44:37 -0800 (PST) Message-Id: <4.1.20021030145152.013ae820@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 30 Oct 2002 15:44:27 -0500 To: geopriv@mail.apps.ietf.org From: "James M. Polk" Cc: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Two companion IDs for consideration 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: , All A few of us have written two companion Drafts for consideration into 2 WGs (GEOPRIV and DHC). The first ID (into the DHC WG) is at: http://www.ietf.org/internet-drafts/draft-polk-dhcp-geo-loc-option-00.txt and defines a Location Object format that satisfies (we hope) the basic required elements to represent a Target as well as the requirement for granular resolution. This ID in no way affects the GEOPRIV Protocol and it's goal for security or user control (ie rules for actively responding to a Location request). It provides a mechanism for getting the location information to an (wired) IP device which can then use the eventual GEOPRIV Protocol as that WG specifies. There are no semantics written into the DHC ID, and leaves some questions as to why the authors made certain choices. Hence the reason for the second ID. The second ID (into the GEOPRIV WG) is the semantics ID for the DHC ID. It's at: http://www.ietf.org/internet-drafts/draft-polk-geopriv-loc-object-semantics- 00.txt and shows (with many examples) why the meaning of "resolution" is better suited to meet the requirement of granular (im)precision than "accuracy". The examples of how the location Target device can simply alter the resolution presented to a location request from within 3.11mm x 2.62mm to as much as 1/6th that of the earth. Neither ID talks about the circumstances of these choices - the authors believe this normative text should reside elsewhere in GEOPRIV efforts with whatever rules that WG places on its Protocol efforts and output. Questions and comments have already been raised on the IEPREP WG list in the Transport Area, so this combined effort looks like it will have multiple lists with comments on them regarding these two IDs. Comments are encouraged cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg