From mailman-bounces@ietf.org Fri Oct 1 09:44:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29440 for ; Fri, 1 Oct 2004 09:44:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDK89-0004du-6J for dhc-archive@lists.ietf.org; Fri, 01 Oct 2004 05:55:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: dhc-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:21:15 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit 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, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for dhc-archive@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-bounces@ietf.org Fri Oct 1 14:36:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05389; Fri, 1 Oct 2004 14:36:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRt7-0007Xh-5F; Fri, 01 Oct 2004 14:12:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRTp-0003sK-43 for dhcwg@megatron.ietf.org; Fri, 01 Oct 2004 13:46:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00229 for ; Fri, 1 Oct 2004 13:46:02 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRcJ-0005Pd-QU for dhcwg@ietf.org; Fri, 01 Oct 2004 13:54:52 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 01 Oct 2004 14:03:22 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i91HjUr5024284; Fri, 1 Oct 2004 13:45:31 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-2-174.cisco.com [10.86.242.174]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALZ27455; Fri, 1 Oct 2004 13:45:27 -0400 (EDT) From: "Bernie Volz" To: "'Soohong Daniel Park'" , "'Ralph Droms'" , Subject: RE: [dhcwg] IPv6 tunnelling options for IPv4 Date: Fri, 1 Oct 2004 13:45:27 -0400 Organization: Cisco Message-ID: <002201c4a7de$708773c0$6501a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi: Because there are so many different tunnel technologies and so many different ways in which these can be used, clarity would be extremely useful. So, I'd highly recommend adding diagrams and descriptions of the likely uses unless there are good IETF documents elsewhere that can be referenced (and referenced explicitly, with figure and section numbers). I don't understand the diagram you included Daniel. Modifying Ralph's, perhaps it should look like: IPv6|<-------------IPv4 only----------->|<--IPv6--... +-------+ IPv4 +--------+ | Dual | network | Tunnel | | Host +------------core----------+endpoint| +-------+ | +--------+ +---+--+ | DHCP | |server| +------+ The Dual [Stack] host tunnels traffic over IPv4 to get IPv6 = connectivity. I'm also wondering whether there would ever need to be any redundancy in = the tunnel end-points and whether returning a list of IPv4 addresses would = be appropriate. The node can try the first, if no response (not exactly = sure how it would tell - no RA?), it can try the others? But perhaps this is unneeded complexity at this time as there may not be any easy way for a = node to tell if the end-point is up? - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Soohong Daniel Park > Sent: Thursday, September 30, 2004 8:09 PM > To: Ralph Droms; dhcwg@ietf.org > Subject: RE: [dhcwg] IPv6 tunnelling options for IPv4 >=20 >=20 > > I've been reviewing draft-daniel-dhc-ipv6in4-opt-04.txt - does=20 > > draft-daniel-dhc-ipv6in4-opt-04.txt specify "configured=20 > IPv6-over-IPv4=20 > > tunneling", as described in section 4 of RFC 2893? If so,=20 > it would be=20 > > helpful to include a specific reference, as there are numerous=20 > > tunneling and "IPv6-xxx-IPv4" transition mechanisms... >=20 > So, I've added this concern into the revised version. >=20 > >=20 > > I can imagine the mechanism in > > draft-daniel-dhc-ipv6in4-opt-04.txt as being > > useful in the following scenario: > >=20 > > <---IPv6---->|<-------------IPv4 only----------->|<--IPv6--... > >=20 > > +-------+ +------+ +--------+ > > | CPE | | Edge | ISP | Tunnel | > > |gateway+-----+Router+-----core-----+endpoint| > > +-------+ +------+ | +--------+ > > +---+--+ > > | DHCP | > > |server| > > +------+ > >=20 > > In this scenario, the CPE gateway uses DHCPv4 to obtain its IPv4 > > address and > > other configuration information. The DHCPv4 configured=20 > tunnel endpoint > > option would provide the IPv4 address of the ISP tunnel endpoint=20 > > as part of > > the DHCPv4 configuration process to the CPE gateway, which=20 > would then use > > that IPv4 address as the destination to tunnel IPv6 traffic from the > > customer network through the IPv4-only portion of the ISP network. > >=20 >=20 > Also, this option is useful for dual stack user to obtain its=20 > IPv6 connectivity > via IPv6-over-IPv4 tunnel within its IPv4 network. >=20 > [DHCP server] > | > | > <-----IPv4--------------------+------------------------>IPv6 > [IPv4/6 user]=3D=3DIPv6-over-IPv4 Tunnel=3D=3D=3D> >=20 >=20 > > If I have this scenario right, it would help to include a=20 > > description of it > > in draft-daniel-dhc-ipv6in4-opt-04.txt, both to clarify the=20 > use of the > > option and motivate the requirements for its definition. > =20 > Originally, I thought of this point as out of scope of the=20 > draft because > several similar draft were proposed in this WG without specific=20 > description of use case like mine. If needed, it can be done simply. >=20 > > Is the expectation in draft-daniel-dhc-ipv6in4-opt-04.txt=20 > that the tunnel, > > once established, looks like a simple link to the IPv6 stack? =20 > > That is, will > > RAs be exchanged and ND be run across the link? Will the=20 > tunnel endpoints > > use a routing protocol? >=20 > It was also tested and added into the new version. RA runs well=20 > via this configured tunnel. >=20 >=20 >=20 > Daniel (Soohong Daniel Park) > Mobile Platform Lab. Samsung Electronics. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 1 20:11:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12180; Fri, 1 Oct 2004 20:11:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDXBF-0006gZ-A7; Fri, 01 Oct 2004 19:51:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDX3G-00006T-Rr for dhcwg@megatron.ietf.org; Fri, 01 Oct 2004 19:43:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10585 for ; Fri, 1 Oct 2004 19:42:59 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDXBd-0000i0-Oe for dhcwg@ietf.org; Fri, 01 Oct 2004 19:51:52 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I4X00E0LJ6IIE@mailout1.samsung.com> for dhcwg@ietf.org; Sat, 02 Oct 2004 08:42:18 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I4X0056QJ64VV@mailout1.samsung.com> for dhcwg@ietf.org; Sat, 02 Oct 2004 08:42:04 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I4X004WAJ64KA@mmp2.samsung.com> for dhcwg@ietf.org; Sat, 02 Oct 2004 08:42:04 +0900 (KST) Date: Sat, 02 Oct 2004 08:43:25 +0900 From: Soohong Daniel Park Subject: RE: [dhcwg] IPv6 tunnelling options for IPv4 In-reply-to: <002201c4a7de$708773c0$6501a8c0@amer.cisco.com> To: Bernie Volz , "'Ralph Droms'" , dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7BIT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Bernie > Because there are so many different tunnel technologies and so many > different ways in which these can be used, clarity would be extremely > useful. So, I'd highly recommend adding diagrams and descriptions of the > likely uses unless there are good IETF documents elsewhere that can be > referenced (and referenced explicitly, with figure and section numbers). no problem here. > I don't understand the diagram you included Daniel. Modifying Ralph's, > perhaps it should look like: > > IPv6|<-------------IPv4 only----------->|<--IPv6--... > > +-------+ IPv4 +--------+ > | Dual | network | Tunnel | > | Host +------------core----------+endpoint| > +-------+ | +--------+ > +---+--+ > | DHCP | > |server| > +------+ > > The Dual [Stack] host tunnels traffic over IPv4 to get IPv6 connectivity. It's why we need a IPv6-over-IPv4 tunnel. There are several possible use cases according to this tunnel and your depict is one of them. > I'm also wondering whether there would ever need to be any > redundancy in the > tunnel end-points and whether returning a list of IPv4 addresses would be > appropriate. The node can try the first, if no response (not exactly sure > how it would tell - no RA?), it can try the others? But perhaps this is > unneeded complexity at this time as there may not be any easy way > for a node > to tell if the end-point is up? In my figure below, when a dual stack node attached to IPv4 only network generates an IPv6 packet for IPv6 connectivity, it must use a tunnel interface among its multiple internal interfaces. At that time, IPv6 packet is encapsulated in IPv4 packet and forwarded it to the tunnel endpoint via IPv6-over-IPv4 tunnel which is already configured by this mechanism proposed in this draft automatically. Tunnel protocol must allow for means for one tunnel endpoint to verify the reachability of other tunnel endpoint towards which it intends to send packets.When I implemented this mechanism with DHCP, I used TCP/UDP port assigned by admin in advance between dual stack node and tunnel endpoint and it works well of course. > [DHCP server] > | > | > <-----IPv4--------------------+------------------------>IPv6 > [IPv4/6 user]==IPv6-over-IPv4 Tunnel===> As I indicated earlier (many times), this task works in progress in v6ops and here are several related document as below; DHCP approach aims the same concern of below documents http://www.watersprings.org/pub/id/draft-palet-v6ops-tun-auto-disc-01.txt http://www.watersprings.org/pub/id/draft-nielsen-v6ops-zeroconf-goals-01.txt Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Oct 4 04:04:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09376; Mon, 4 Oct 2004 04:04:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CENfh-0003Yq-IH; Mon, 04 Oct 2004 03:54:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CENZj-0002aD-9g for dhcwg@megatron.ietf.org; Mon, 04 Oct 2004 03:48:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07987 for ; Mon, 4 Oct 2004 03:48:01 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CENia-0000Hv-BS for dhcwg@ietf.org; Mon, 04 Oct 2004 03:57:24 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i947lkBT020912 for ; Mon, 4 Oct 2004 16:47:47 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i947lkMM002215 for ; Mon, 4 Oct 2004 16:47:46 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i947lkaL002212 for ; Mon, 4 Oct 2004 16:47:46 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i947ljK6024058 for ; Mon, 4 Oct 2004 16:47:45 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i947ljr0024055 for ; Mon, 4 Oct 2004 16:47:45 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i947liRT016186 for ; Mon, 4 Oct 2004 16:47:44 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i947lilj015786 for ; Mon, 4 Oct 2004 16:47:44 +0900 (JST) Received: from imk.m.ecl.ntt.co.jp (imk0.m.ecl.ntt.co.jp [129.60.5.149]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i947liqw015783 for ; Mon, 4 Oct 2004 16:47:44 +0900 (JST) Received: from [129.60.10.235] by imk.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id QAA03714 for ; Mon, 4 Oct 2004 16:47:43 +0900 (JST) Date: Mon, 04 Oct 2004 16:47:44 +0900 From: "OTA Masazumi" To: dhcwg@ietf.org Message-Id: <20041004163648.DAA4.OOTA.MASAZUMI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.04 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [dhcwg] All_DHCP_SERVERS Multicast address X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, Could you please answer my question about All_DHCP_SERVERS Multicast address? Can I think that the All_DHCP_SERVERS multicast packet defined as Site local Address exceeds router in the same site? On the other hand, it is a direction where the use of a site local address with IPv6 is prohibited. How is the All_DHCP_SERVERS multicast address used for the future? Masazumi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Oct 4 06:44:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21970; Mon, 4 Oct 2004 06:44:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQDR-0005cW-5A; Mon, 04 Oct 2004 06:37:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQ7s-0004Ef-5Y for dhcwg@megatron.ietf.org; Mon, 04 Oct 2004 06:31:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20823 for ; Mon, 4 Oct 2004 06:31:24 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEQGu-0006fM-ME for dhcwg@ietf.org; Mon, 04 Oct 2004 06:40:50 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i94AUsRC031553; Mon, 4 Oct 2004 12:30:54 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i94AUo6v014697; Mon, 4 Oct 2004 12:30:50 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 4 Oct 2004 12:30:50 +0200 From: Stig Venaas To: OTA Masazumi Subject: Re: [dhcwg] All_DHCP_SERVERS Multicast address Message-ID: <20041004103050.GH14398@sverresborg.uninett.no> References: <20041004163648.DAA4.OOTA.MASAZUMI@lab.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041004163648.DAA4.OOTA.MASAZUMI@lab.ntt.co.jp> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Oct 04, 2004 at 04:47:44PM +0900, OTA Masazumi wrote: > Hello, > > Could you please answer my question about All_DHCP_SERVERS Multicast address? > > Can I think that the All_DHCP_SERVERS multicast packet defined as Site > local Address exceeds router in the same site? The site boundary should be defined on the border routers so that they don't forward packets or send e.g. PIM messages for site-scoped groups outside the site. > On the other hand, it is a direction where the use of a site local > address with IPv6 is prohibited. How is the All_DHCP_SERVERS multicast > address used for the future? It's only the site local unicast addresses that are gone. Scoping for IPv6 multicast has not changed in any way. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Oct 4 07:09:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23969; Mon, 4 Oct 2004 07:09:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQcx-0001JB-UH; Mon, 04 Oct 2004 07:03:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQW7-0000ET-8O for dhcwg@megatron.ietf.org; Mon, 04 Oct 2004 06:56:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23021 for ; Mon, 4 Oct 2004 06:56:27 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEQex-00029I-GS for dhcwg@ietf.org; Mon, 04 Oct 2004 07:05:53 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94AuDND007795 for ; Mon, 4 Oct 2004 19:56:13 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94AuC5n004597 for ; Mon, 4 Oct 2004 19:56:12 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94AuCeP004589 for ; Mon, 4 Oct 2004 19:56:12 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94AuBIn026765 for ; Mon, 4 Oct 2004 19:56:11 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94AuBRX026757 for ; Mon, 4 Oct 2004 19:56:11 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94AuBQp021082 for ; Mon, 4 Oct 2004 19:56:11 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94AuAmQ003439 for ; Mon, 4 Oct 2004 19:56:10 +0900 (JST) Received: from imk.m.ecl.ntt.co.jp (imk0.m.ecl.ntt.co.jp [129.60.5.149]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94AuAMt003433 for ; Mon, 4 Oct 2004 19:56:10 +0900 (JST) Received: from [129.60.10.235] by imk.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id TAA18350 for ; Mon, 4 Oct 2004 19:56:09 +0900 (JST) Date: Mon, 04 Oct 2004 19:56:10 +0900 From: =?ISO-2022-JP?B?Ik9UQSBNYXNhenVtaS8bJEJCQEVEQDU9YxsoQg==?= =?ISO-2022-JP?B?Ig==?= To: dhcwg@ietf.org Subject: Re: [dhcwg] All_DHCP_SERVERS Multicast address In-Reply-To: <20041004103050.GH14398@sverresborg.uninett.no> References: <20041004163648.DAA4.OOTA.MASAZUMI@lab.ntt.co.jp> <20041004103050.GH14398@sverresborg.uninett.no> Message-Id: <20041004195537.73DE.OOTA.MASAZUMI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.04 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Thank you for your reply. I understood Border router judge whether packets can pass or not. Site local multicast address is alive. -Masazumi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Oct 4 16:19:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12930; Mon, 4 Oct 2004 16:19:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZ1S-0006tD-OU; Mon, 04 Oct 2004 16:01:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYlT-0007fT-RM; Mon, 04 Oct 2004 15:44:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08473; Mon, 4 Oct 2004 15:44:53 -0400 (EDT) Message-Id: <200410041944.PAA08473@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 04 Oct 2004 15:44:53 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Server-ID Override Suboption Author(s) : R. Johnson, et al. Filename : draft-ietf-dhc-server-override-01.txt Pages : 5 Date : 2004-10-4 This memo defines a new suboption of the DHCP relay information option [6] which allows the DHCP relay to specify a new value for the Server-ID option, which is inserted by the DHCP Server. In some cases it is convenient for the DHCP relay to act as the actual DHCP server such that DHCP RENEWAL requests will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on RENEWAL messages. This new relay agent suboption allows the relay to tell the DHCP server what value to use in the Server-ID option [3]. If this suboption is not present, the server should build the Server-ID option in the normal fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-override-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-server-override-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-server-override-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: <2004-10-4152535.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-server-override-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-server-override-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-4152535.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Mon Oct 4 16:20:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13018; Mon, 4 Oct 2004 16:20:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZ1U-0006vJ-S4; Mon, 04 Oct 2004 16:01:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYlX-0007ik-Il; Mon, 04 Oct 2004 15:44:59 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08480; Mon, 4 Oct 2004 15:44:57 -0400 (EDT) Message-Id: <200410041944.PAA08480@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 04 Oct 2004 15:44:57 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-vpn-option-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --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, et al. Filename : draft-ietf-dhc-vpn-option-03.txt Pages : 6 Date : 2004-10-4 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-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-vpn-option-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-vpn-option-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-4152541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-vpn-option-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-vpn-option-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-4152541.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Mon Oct 4 17:25:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26934; Mon, 4 Oct 2004 17:25:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZWb-0008GC-Rm; Mon, 04 Oct 2004 16:33:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYMm-0003RF-5J; Mon, 04 Oct 2004 15:19:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05732; Mon, 4 Oct 2004 15:19:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEYVu-0007hP-PU; Mon, 04 Oct 2004 15:28:50 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CEYDc-0007W9-Ht; Mon, 04 Oct 2004 15:09:56 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 04 Oct 2004 15:09:56 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Mon, 04 Oct 2004 16:33:36 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: 'Rapid Commit Option for DHCPv4' to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'Rapid Commit Option for DHCPv4 ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-10-18. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-05.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Oct 6 19:36:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29653; Wed, 6 Oct 2004 19:36:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFLJ4-0004Au-9T; Wed, 06 Oct 2004 19:34:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFLEH-00031r-84 for dhcwg@megatron.ietf.org; Wed, 06 Oct 2004 19:29:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29196 for ; Wed, 6 Oct 2004 19:29:49 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFLNg-0003G7-UE for dhcwg@ietf.org; Wed, 06 Oct 2004 19:39:47 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I5600101RWLRH@mailout2.samsung.com> for dhcwg@ietf.org; Thu, 07 Oct 2004 08:29:09 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I560012NRWLCU@mailout2.samsung.com> for dhcwg@ietf.org; Thu, 07 Oct 2004 08:29:09 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I5600FGNRWKIJ@mmp2.samsung.com> for dhcwg@ietf.org; Thu, 07 Oct 2004 08:29:09 +0900 (KST) Date: Thu, 07 Oct 2004 08:30:32 +0900 From: Soohong Daniel Park To: Dhcwg Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7BIT Subject: [dhcwg] IPv6-over-IPv4 Tunnel with DHCP (Ready for WG Item ?) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hello Folks The latest version of draft-daniel-dhc-ipv6in4-opt appears in the IETF repository as below: http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-05.txt Above all, this protocol works well in our enterprise networks. Change log: 1. Added some text with use case and detailed flow of this protocol. 2. Text improvement around this draft. 3. Added Terminology section to clarify what tunnel is used in this draft. 4. Added Implementation Experience section for useful information. Now, I'd ask the dhc folks whether it is ready to be accepted as official WG Item or not... Let me know your view on this. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Oct 6 19:47:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00479; Wed, 6 Oct 2004 19:47:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFLT6-0005co-3i; Wed, 06 Oct 2004 19:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFLLl-0004ZX-Ip for dhcwg@megatron.ietf.org; Wed, 06 Oct 2004 19:37:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29735 for ; Wed, 6 Oct 2004 19:37:33 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFLVK-0003oi-1v for dhcwg@ietf.org; Wed, 06 Oct 2004 19:47:32 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I560034IS9QOD@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 07 Oct 2004 08:37:02 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I5600MWLS920X@mailout3.samsung.com> for dhcwg@ietf.org; Thu, 07 Oct 2004 08:36:39 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I5600HAAS925L@mmp1.samsung.com> for dhcwg@ietf.org; Thu, 07 Oct 2004 08:36:38 +0900 (KST) Date: Thu, 07 Oct 2004 08:38:02 +0900 From: Soohong Daniel Park To: Dhcwg Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7BIT Subject: [dhcwg] Multicast Reconfiguration Protocol for Stateless DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hello folks Vijay and I have updated draft-vijay-dhc-dhcpv6-mcast-reconf draft reflecting valuable comments from several guys as below: http://www.ietf.org/internet-drafts/draft-vijay-dhc-dhcpv6-mcast-reconf-01.txt Especially, O-Policy is newly applied for this protocol in conjunction with M/O document to reconfigure the stateless DHCPv6 domain without other protocol extension (Refresh Other Configuration Option of IPv6 RA). It would be useful to adopt this protocol to reconfigure the stateless DHCPv6 domain in a instant manner. All comments are highly welcome. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 8 17:49:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20948; Fri, 8 Oct 2004 17:49:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2Y9-0007dT-1l; Fri, 08 Oct 2004 17:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2QK-0004Jl-AI for dhcwg@megatron.ietf.org; Fri, 08 Oct 2004 17:37:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19783 for ; Fri, 8 Oct 2004 17:37:09 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2aJ-0005VV-AR for dhcwg@ietf.org; Fri, 08 Oct 2004 17:47:31 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 08 Oct 2004 14:44:45 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i98LabdV029687; Fri, 8 Oct 2004 14:36:37 -0700 (PDT) Received: from [161.44.65.113] ([161.44.65.113]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMD97453; Fri, 8 Oct 2004 17:36:29 -0400 (EDT) Message-ID: <4167085D.3010109@cisco.com> Date: Fri, 08 Oct 2004 17:36:29 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soohong Daniel Park Subject: Re: [dhcwg] IPv6 tunnelling options for IPv4 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Bernie Volz , "'Ralph Droms'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Based on the documents you refer to, it seems that Ralph's diagram, which includes an IPv6 router/gateway in the home, is not specifically a target of this option, or of the zeroconf tunnel architecture. The zeroconf-goals document describes the need to assign a single /128 address to the host (sec. 3.1). While it's possible to support a v6 gateway on the DHCPv4 client end of the link (through manual configuration of IPv6 networks, and RIP, or through DHCPv6 prefix delegation), it seems out of scope for this particular document. In relation to RFC 2983, I think it would be useful to indicate that this is in support of automatically configuring a host to router configured tunnel (not "automatic tunneling"). By definition, this is unidirectional. Then, if the intent is to support an automated establishment of a reverse configured tunnel, that is up to the TEP and the host, and to a large extent is beyond the scope of this document. I would think a different document, most likely within v6ops, would define things such as how the TEP decides to accept the tunnel, how it decides to assist the host in global address assignment, how it the two maintain reachability, etc. In other words, I would thing the details of reverse tunnel establishment and maintenance, addressing, etc., would be part of a tunnel protocol document that cites this one as the way to kick things off. -josh Soohong Daniel Park wrote: > Hi Bernie > > >>Because there are so many different tunnel technologies and so many >>different ways in which these can be used, clarity would be extremely >>useful. So, I'd highly recommend adding diagrams and descriptions of the >>likely uses unless there are good IETF documents elsewhere that can be >>referenced (and referenced explicitly, with figure and section numbers). > > > no problem here. > > >>I don't understand the diagram you included Daniel. Modifying Ralph's, >>perhaps it should look like: >> >> IPv6|<-------------IPv4 only----------->|<--IPv6--... >> >> +-------+ IPv4 +--------+ >> | Dual | network | Tunnel | >> | Host +------------core----------+endpoint| >> +-------+ | +--------+ >> +---+--+ >> | DHCP | >> |server| >> +------+ >> >>The Dual [Stack] host tunnels traffic over IPv4 to get IPv6 connectivity. > > > It's why we need a IPv6-over-IPv4 tunnel. There are several possible > use cases according to this tunnel and your depict is one of them. > > >>I'm also wondering whether there would ever need to be any >>redundancy in the >>tunnel end-points and whether returning a list of IPv4 addresses would be >>appropriate. The node can try the first, if no response (not exactly sure >>how it would tell - no RA?), it can try the others? But perhaps this is >>unneeded complexity at this time as there may not be any easy way >>for a node >>to tell if the end-point is up? > > > In my figure below, when a dual stack node attached to IPv4 only network > generates an IPv6 packet for IPv6 connectivity, it must use a tunnel > interface among its multiple internal interfaces. At that time, IPv6 packet is > encapsulated in IPv4 packet and forwarded it to the tunnel endpoint > via IPv6-over-IPv4 tunnel which is already configured by this mechanism > proposed in this draft automatically. Tunnel protocol must allow for means > for one tunnel endpoint to verify the reachability of other tunnel endpoint > towards which it intends to send packets.When I implemented this > mechanism with DHCP, I used TCP/UDP port assigned by admin in > advance between dual stack node and tunnel endpoint and it works > well of course. > > >> [DHCP server] >> | >> | >><-----IPv4--------------------+------------------------>IPv6 >>[IPv4/6 user]==IPv6-over-IPv4 Tunnel===> > > > > > As I indicated earlier (many times), this task works in progress in v6ops > and here are several related document as below; > > DHCP approach aims the same concern of below documents > > http://www.watersprings.org/pub/id/draft-palet-v6ops-tun-auto-disc-01.txt > http://www.watersprings.org/pub/id/draft-nielsen-v6ops-zeroconf-goals-01.txt > > > Daniel (Soohong Daniel Park) > Mobile Platform Lab. Samsung Electronics. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 8 19:58:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00588; Fri, 8 Oct 2004 19:58:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG4Nu-0007Ew-P7; Fri, 08 Oct 2004 19:42:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG4Ke-0006VV-PS; Fri, 08 Oct 2004 19:39:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28953; Fri, 8 Oct 2004 19:39:25 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG4Ue-0007ps-SR; Fri, 08 Oct 2004 19:49:49 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i98NcFJ25044; Fri, 8 Oct 2004 16:38:15 -0700 (PDT) Message-Id: <200410082338.i98NcFJ25044@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 08 Oct 2004 16:38:15 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 3898 on Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3898 Title: Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s): V. Kalusivalingam Status: Standards Track Date: October 2004 Mailbox: vibhaska@cisco.com Pages: 7 Characters: 13955 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3898.txt This document describes four options for Network Information Service (NIS) related configuration information in Dynamic Host Configuration Protocol for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <041008163651.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3898 --OtherAccess Content-Type: Message/External-body; name="rfc3898.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <041008163651.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Fri Oct 8 22:13:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14320; Fri, 8 Oct 2004 22:13:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG6hN-0000DF-75; Fri, 08 Oct 2004 22:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG6gc-0008N5-Fk for dhcwg@megatron.ietf.org; Fri, 08 Oct 2004 22:10:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11953 for ; Fri, 8 Oct 2004 22:10:16 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG6qd-0002bO-1F for dhcwg@ietf.org; Fri, 08 Oct 2004 22:20:40 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id EE1F01525D; Sat, 9 Oct 2004 11:09:49 +0900 (JST) Date: Sat, 09 Oct 2004 11:09:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig Venaas Subject: Re: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00 In-Reply-To: References: <1090333421.11056.266.camel@localhost> <20040720145508.GL29655@sverresborg.uninett.no> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hello, Perhaps you've already forgotten the context, but I'm now revising the dhcpv6-clarify-auth draft, and would like to address your concern in the next version. >>>>> On Mon, 26 Jul 2004 18:10:35 +0900, >>>>> JINMEI Tatuya said: >> For stateless I think it's generally enough to authenticate the DHCP >> server. In most cases I don't think it's important to guard against >> replay, or to authenticate the client. That could perhaps simplify >> the security mechanism. It's relatively easy to guard against replay >> anyway though. > On the one hand, I see and tend to agree that it's nice to prevent > per-client state for "stateless" DHCP. > On the other hand, we should be very careful when we are going to > justify something that could introduce weaker security. While the > current main usage for stateless DHCP is client independent, the > specification leaves the possibility for per-client configuration > (otherwise, we could have prohibited including the client identifier > option in Information-request in the first place). Regarding replay > attacks, the client might want to minimize the possibility of > receiving a replayed reply to Information-request that contains a very > small lifetime in the lifetime option. > Perhaps a possible compromise would be something like this: > - loosen the "MUST record the per-client state" to SHOULD > - allow (using MAY) the server to not record the state when replay > attacks can be ignored and it is acceptable that Information-request > is always non-authenticated > What do you think? I've not seen any responses to this rough proposal, so I'm currently going to implement the idea in the next draft. I've attached the current cut of the new text below (sorry, it's quite long), so it would be nice if you could review and make comment on it (whether it's acceptable or not, etc). Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp 2. Usage with Information-Request According to [RFC3315], it seems possible to use the authentication mechanism for Information-request and Reply exchanges. The RFC says in Section 21.4.4.4 as follows: If the server has selected a key for the client in a previous message exchange (see section 21.4.5.1), the client MUST use the same key to generate the authentication information throughout the session. However, this description is not really clear. Section 21.4.5.1, which is referred from the above part, actually describes the case of Solicit and Advertise exchange: 21.4.5.1. Receiving Solicit Messages and Sending Advertise Messages The server selects a key for the client and includes authentication information in the Advertise message returned to the client as specified in section 21.4. [...] It does not necessarily mean contradiction because the client and the server may have exchanged Solicit and Advertise with authentication before starting the Information-request and Reply exchange. However, it then restricts the usage scenario of the authentication mechanism for Information-request and Reply exchanges. In particular, this assumption prohibits the use of the mechanism with the "stateless" service using DHCPv6 [RFC3736]. Whereas the specification allows an implementation that only supports the stateless service and does not support Solicit and Advertise messages, the authentication mechanism depends on Solicit and Advertise exchanges. This fact can (partly) invalidate a security consideration in [RFC3736]: Authenticated DHCP, as described in sections 21 and 22.11 of the DHCP specification [1], can be used to avoid attacks mounted through the stateless DHCP service. (where [1] refers to [RFC3315].) In fact, as was just shown above, authenticated DHCP cannot be used unless the implementations also support Solicit and Advertise messages (or the entire [RFC3315] in general). It should also be noted that [RFC3315] does not define what the server should do when it receives an Information-request message containing an authentication option; Section 21.4.5.2 excludes the Information-request message. 2.1 Suggested Resolution Considering the fact that [RFC3736] allows implementations that only support the subset of the full specification [RFC3315], it should make sense to define the authentication usage for Information-request and Reply exchanges separately. One significant difference between Information-request and other "stateful" cases is that there is no explicit notion of "session" in the former. In some cases, however, the same client and server may exchange Information-request and Reply multiple times, where the entire exchanges can be regarded as a "session". For example, the client may want to get different configuration information in multiple exchanges. Also, if the client and the server use the Information Refresh Time Option [I-D.ietf-dhc-lifetime], they will restart exchanges when the refresh time expires. On the other hand, keeping a "session" in the server decreases an advantage of the [RFC3736] usage that the server can run in a stateless fashion without any client-specific state. Thus, it is worth considering a trade off between securing multiple exchanges as a single session and keeping the server stateless. Securing multiple exchanges has two beneficial points: o the server can authenticate Information-request messages from the client. o the client and the server can perform replay protection. In other words, it would make sense to separate each exchange and to keep the server stateless in the case where neither of them is desired. And, in fact, it is not so important to authenticate client's messages in the current usage of [RFC3736] for providing client-independent information. Additionally, replay attacks in such a typical usage might not be a big threat, since any Reply messages from the server will simply be the same. Still, there will be other cases where (one of) the above two points are important. For example, if the address of a DNS recursive name resolver [RFC3646] is provided in reply to an Information-request message and the address is renumbered, the client will not want to be confused with the previous address containing the previous valid authentication information. In this case, the client wants to reject such an invalid or stale Reply by the reply protection mechanism. Also, the current design of the Information-request message still allows including the Client DUID option in order for per-client configuration, while it is not common today. In this type of configuration, the server will want to authenticate the client's request. The proposed revision of Section 21.4.4.4 is therefore as follows: 21.4.4.4. Sending Information-request Messages When the client sends an Information-request message and wishes to use authentication, it includes an Authentication option with the desired protocol, algorithm and RDM as described in section 21.4. The client does not include any replay detection or authentication information in the Authentication option. If the client authenticated past exchanges of Information-request and Reply, the client MAY reuse the same key used in the previous exchanges to generate the authentication information. In this case, the client generates authentication information for the Information-request message as described in section 21.4. Normally, the client performs replay detection when it reuses the same key. However, to be able to interoperate with "stateless" servers that do not maintain per-client state, the client MUST be configurable to turn off replay detection for a Reply message to Information-request. Since disabling replay detection can cause a security threat, the client SHOULD be configured by default to enable it. Note that the keys used for these exchanges are separately managed from the keys used for the other exchanges beginning with the Solicit message when the two types of exchanges run concurrently, while the two keys may happen to be the same. For example, replay detection should be performed separately, and validation failure for one type of exchanges does not affect the other. Section 21.4.4.5 will also need to be revised. However, since this section has a separate issue per se as will be discussed in Section 6, we do not discuss further details on this here. The server side behavior needs to be described, too. Along with the above change to Section 21.4.4.4, we propose to add a new subsection of Section 21.4.5: 21.4.5.x. Receiving Information-request Messages and Sending Reply Messages If the Information-request message includes an authentication option without authentication information, the server selects a key for the client and includes authentication information in the Reply message returned to the client as specified in section 21.4. The server SHOULD record the identifier of the key selected for the client so that it can validate further Information-request messages from the client if the client reuses the same key for the future exchanges. In some cases, however, the server would rather be just stateless, without maintaining any per-client state. Thus, the server MAY skip keeping per-client state, in which case it will not authenticate Information-request messages from clients or necessarily provide a valid replay detection information with the client which performs replay detection. If the Information-request message includes an authentication option with authentication information, the server uses the key identified in the message and validates the message as specified in section 21.4.2. If the message fails to pass the validation test, or the key identified by the authentication information of the message is not identical to the key that the server used in the previous exchange (when it has recorded the key), the server MUST discard the message and MAY choose to log the validation failure. If the server has not recorded the key, it MAY skip replay detection in the above procedure, but MUST perform the rest of validation. If the message passes the validation test, the server responds to the Reply message as described in section 18.2.5. The server MUST include authentication information generated using the key just selected or identified in the received message, as specified in section 21.4. Note that the keys used for these exchanges are separately managed from the keys used for the other exchanges beginning with the Solicit message when the two types of exchanges run concurrently (See Section 21.4.4.4). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From lottoextra@zipmail.com.br Sat Oct 9 09:33:46 2004 Received: from www.zipmail.com.br (smtp.zipmail.com.br [200.221.11.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13569 for ; Sat, 9 Oct 2004 09:33:45 -0400 (EDT) From: lottoextra@zipmail.com.br Received: from [192.116.69.86] by www.zipmail.com.br with HTTP; Sat, 9 Oct 2004 10:27:53 -0300 Message-ID: <41679A8400000542@www.zipmail.com.br> Date: Sat, 9 Oct 2004 14:27:53 +0100 Subject: =?iso-8859-1?Q?AWARD=20WINNING=20NOTIFICATION=20=21=21=21?= To: DHC-ARCHIVE@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: P/L/E /26510460037/04 BATCH: 24/00319/IPD ATTENTION: AWARD NOTIFICATION; FINAL NOTICE we are pleased to inform you of the announcement today,8th October,of 2004 winners of our promo:LONDON LOTTO EXTRA PROGRAMS held on 30th September, 2004 Your name, is attached to ticket number 023-0148-790-459,with serial number 5073-11 drew the lucky numbers 43-11-44-37-10-43, and consequently won the lottery in the 3rd category. You have therefore been approved for a lump sum payout of US$5,000.000,00 credited to file REF NO:P/L/E/26510460037/03 this forms part of the total prize sum of $15,000,000.00 shared among the five international winners in this category. All participants were selected through a computerized random ballot system drawn from 25,000 names from Australia, New Zealand, America,Europe, North America, and Asia as part of International Promotions Program, which is conducted quarterly. CONGRATULATIONS! Your fund is now deposited under the custody of a Financial Security company whom on due processing of your winning documentations and appropriate identification shall release to you a certified bank check via through a secured mailing procedure in any event you may not be able to receive your payout physically as required by Law. You are therefore requested to indicate to ensure a prompt processing of your payment. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money received by you. This is part of our security protocol to avoid double claiming or unscrupulous acts by unauthorized persons. To begin your claim, you will be given a form to complete and return same to an accredited lawyer to this office . He shall upon your retainership of his services notarize and endorse your won prize at the Court of competent jurisdiction. To commence the facilitation of this process kindly contact your claim agent Mrs Rose Janet via this mail ddress:lottoextraclaimagent= @yahoo.com. Remember, all prize money must be claimed not later than 30th october, 2004.After this date, all funds will be foreclosed and returned as unclaimed. NOTE: In order to avoid unnecessary delays and complications, All Winners will be asked to produce evidence of identification and eligibility. Please remember to quote your reference and batch numbers in every one of your correspondences with your agent.Furthermore, should there be any change of your address, do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for Being part of our promotion program. Sincerely, Anderson smith The Promotions Manager, LOTTO EXTRA PROMOTION N.B. Any breach of confidentiality on the part of the winners will result to disqualification and annulment of already declared prize=20 ------------------------------------------ Use o melhor sistema de busca da Internet Radar UOL - http://www.radaruol.com.br From dhcwg-bounces@ietf.org Sun Oct 10 08:14:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06108; Sun, 10 Oct 2004 08:14:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGcYP-0004xI-7D; Sun, 10 Oct 2004 08:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGcVV-0004Vy-6r for dhcwg@megatron.ietf.org; Sun, 10 Oct 2004 08:08:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05645; Sun, 10 Oct 2004 08:08:55 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGcff-0006Rq-HE; Sun, 10 Oct 2004 08:19:37 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Oct 2004 08:27:38 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9AC8BKm011400; Sun, 10 Oct 2004 08:08:12 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn2-751.cisco.com [10.21.114.239]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AME36012; Sun, 10 Oct 2004 08:08:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20041010080700.01f024c0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Oct 2004 08:08:09 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: agenda@ietf.org Subject: [dhcwg] Tentative agenda for dhc WG meeting at IETF 61 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Here's a first draft agenda for the dhc WG meeting at IETF 61. - Ralph DHC WG agenda - IETF 61 0900 Mon 2004-11-08 (tentative) (Last revised 10/10/2004 08:05 AM) ---------------------------------- Administrivia Ralph Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Request for milestones for dhc WG drafts DNS zone suffix option for DHCPv6 Renxiang Yan 10 minutes Accept as dhc WG work item? Reclassifying DHCPv4 Options TBD 10 minutes How to implement the process after RFC is published? DHCP Authentication via EAP Mark Stapp 10 minutes Technical discussion Lifetime Option for DHCPv6 Stig Venaas 10 minutes Ready for WG last call? DHCP-DNS interaction Bernie Volz 30 minutes Technical discussion ----------- 80 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Oct 10 09:30:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10014; Sun, 10 Oct 2004 09:30:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGdk0-0007L9-ST; Sun, 10 Oct 2004 09:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGdel-0006nH-7O for dhcwg@megatron.ietf.org; Sun, 10 Oct 2004 09:22:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09729 for ; Sun, 10 Oct 2004 09:22:33 -0400 (EDT) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGdp6-0007Ys-Ef for dhcwg@ietf.org; Sun, 10 Oct 2004 09:33:16 -0400 Received: from [69.173.190.121] (account margaret HELO [192.168.1.103]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 170692; Sun, 10 Oct 2004 09:17:26 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: Date: Sun, 10 Oct 2004 09:22:22 -0400 To: Ralph Droms , dhcwg@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Thomas Narten , vijayak@india.hp.com Subject: [dhcwg] draft-ietf-dhc-dhcpv6-opt-sntp-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hi Ralph and the DHCP WG, Is the WG still interested in seeing the DHCPv6 SNTP option published as a Proposed Standard RFC? The IESG reviewed draft-ietf-dhc-dhcpv6-opt-sntp-00.txt in February 2004 and there were three discusses from Thomas Narten, Alex Zinin and Harald Alvestrand (see below). I believe that there is a good understanding of how to address all three of these discusses. We even had a conference call with Harald to determine how to address his discuss, and we agreed to specific wording. Although I have sent several reminders to the author, the document has not been updated since November 2003. I also haven't received any response to at least my last two queries. So, I don't even know that the author is still reachable. I'm not sure what to do in this situation. I don't see any sign that there is significant WG interest in this document (at least no one has asked me about it), and I don't feel comfortable with having a document sit in this partially IESG-approved state indefinitely, especially through an AD transition (such as the Security AD transition we expect at IETF 61). So, unless this document is updated to address (or at least attempt to address) the three IESG discuss comments below by the Internet-Draft cut-off for IETF 61 (October 25th @ 9:00am EST), I will return this draft to the DHC WG (by moving it to the "AD is Watching" state), which will cause it to expire. Then, if the WG chooses to do further work in this area, it will need to be re-submitted to the IESG. Please speak up if you consider this work important and want to see it move forward! Margaret IESG Discusses and Comments Harald Alvestrand: Discuss: [2004-02-05] This document should specify whether or not SNTPv4 servers can be listed in the options list. If they can, it should specify how they are listed. If they cannot, it should say so; it would be beneficial to have it explain how a client with both IPv4 and IPv6 stacks decides which SNTP servers to use. Thomas Narten: Discuss: [2004-01-22] > The Simple Network Time Protocol Servers option provides a list of > one or more IPv6 addresses of SNTP [3] servers available to the > client for synchronization. The SNTP servers SHOULD be listed in > the order of preference. For interoperability, it would be better to say that clients MUST processes the servers as if they were in priority order. Whether the server takes advantage of that or not is an operational issue. But if the clients aren't guaranteed to process them in order, there is little point in the server putting them in order. Jon Peterson: Comment: [2004-01-22] The end of the sentence in Section 3 might want to include a direct reference to the DHCPv6 spec (presumably, [1]). Bert Wijnen: Comment: [2004-01-20] From OPS DIrectorate (Pekka): nits: - spell out SNTP in the Abstract - acknowledgement section should be split to a real acknowledgement section, and the regular ISOC funding acknowledgement. - IPR statement could be added. - add a dot at the end of the paragraph in section 2. Alex Zinin: Discuss: [2004-01-22] Section 5 should say what the receiver should do if the option [number] appears in a message it is not supposed to. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Oct 12 16:20:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00491; Tue, 12 Oct 2004 16:20:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHSnR-0005E0-34; Tue, 12 Oct 2004 15:58:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHScX-0007OR-23; Tue, 12 Oct 2004 15:47:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24986; Tue, 12 Oct 2004 15:47:39 -0400 (EDT) Message-Id: <200410121947.PAA24986@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 12 Oct 2004 15:47:39 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-ddns-resolution-08.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Resolution of DNS Name Conflicts Among DHCP Clients Author(s) : M. Stapp, B. Volz Filename : draft-ietf-dhc-ddns-resolution-08.txt Pages : 14 Date : 2004-10-12 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document describes techniques for the resolution of DNS name conflicts among DHCP clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-ddns-resolution-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-12160329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-ddns-resolution-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-12160329.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Wed Oct 13 05:26:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05581; Wed, 13 Oct 2004 05:26:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHfG1-0005WK-V4; Wed, 13 Oct 2004 05:17:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHf9Y-0003bU-M6 for dhcwg@megatron.ietf.org; Wed, 13 Oct 2004 05:10:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04765 for ; Wed, 13 Oct 2004 05:10:32 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHfKO-0008MT-Nz for dhcwg@ietf.org; Wed, 13 Oct 2004 05:21:50 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9D9AQs5010566 for ; Wed, 13 Oct 2004 18:10:26 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9D9APiH025052 for ; Wed, 13 Oct 2004 18:10:25 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9D9APiJ025047 for ; Wed, 13 Oct 2004 18:10:25 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9D9AON2006230 for ; Wed, 13 Oct 2004 18:10:24 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9D9AOmE006224 for ; Wed, 13 Oct 2004 18:10:24 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9D9ANc0022192 for ; Wed, 13 Oct 2004 18:10:23 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9D9ANxp011720 for ; Wed, 13 Oct 2004 18:10:23 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (ime0.m.ecl.ntt.co.jp [129.60.5.143]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9D9AMbe011715 for ; Wed, 13 Oct 2004 18:10:22 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA10611 for ; Wed, 13 Oct 2004 18:10:22 +0900 (JST) Message-ID: <416CF1E4.9030102@lab.ntt.co.jp> Date: Wed, 13 Oct 2004 18:14:12 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [dhcwg] [Q] Threat analysis X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, I have a question on "DHCPv4 Threat Analysis". In section 4.2, capability of client is described as follows. $B!H(BClients MUST be able to authenticate servers (to prevent misconfigured clients and assure that the correct servers are being contacted).$B!I(B I understood this sentence didn't mean that client MUST authenticate server whenever client uses DHCP. Is my understanding right? --Mayumi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Oct 13 09:59:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28260; Wed, 13 Oct 2004 09:59:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHjb4-00088Z-T8; Wed, 13 Oct 2004 09:55:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHjZl-0007bG-BW for dhcwg@megatron.ietf.org; Wed, 13 Oct 2004 09:53:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27873 for ; Wed, 13 Oct 2004 09:53:51 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHjkb-0005Zf-66 for dhcwg@ietf.org; Wed, 13 Oct 2004 10:05:11 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 13 Oct 2004 10:13:11 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9DDrDYX002683; Wed, 13 Oct 2004 09:53:13 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn5-229.cisco.com [10.21.88.229]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMG20431; Wed, 13 Oct 2004 09:53:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20041013094804.02a861d0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Oct 2004 09:53:08 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Allison Mankin , Randall Gellens , Andrew Newton Subject: [dhcwg] WGLC for draft-ietf-geopriv-dhcp-civil-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Included below is the announcement of a WG last call on draft-ietf-geopriv-dhcp-civil-04.txt. Please review this draft and reply with comments directly to geopriv@ietf.org - Ralph ------------------------ Begin forwarded message: From: Andrew Newton Date: October 13, 2004 8:47:44 AM EDT To: GEOPRIV WG Cc: Randall Gellens , Allison Mankin Subject: WGLC for draft-ietf-geopriv-dhcp-civil-04.txt This begins a working group last call for draft-ietf-geopriv-dhcp-civil-04.txt for the GEOPRIV working group. The GEOPRIV co-chairs will ask for a simultaneous last call of this document in DHC working group. This duration of this last call is to be 3 weeks, concluding on November 3, 2004. -andy _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Oct 14 11:07:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28254; Thu, 14 Oct 2004 11:07:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI7AP-0000iX-AK; Thu, 14 Oct 2004 11:05:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI78a-0008Ud-Ig for dhcwg@megatron.ietf.org; Thu, 14 Oct 2004 11:03:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27950 for ; Thu, 14 Oct 2004 11:03:25 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI7Jk-0004EU-5M for dhcwg@ietf.org; Thu, 14 Oct 2004 11:15:01 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 14 Oct 2004 08:12:00 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9EF2mk2010405; Thu, 14 Oct 2004 08:02:48 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMH05912; Thu, 14 Oct 2004 11:01:29 -0400 (EDT) From: "Bernie Volz" To: "'Mayumi Yanagiya'" , Subject: RE: [dhcwg] [Q] Threat analysis Date: Thu, 14 Oct 2004 11:01:29 -0400 Organization: Cisco Message-ID: <000401c4b1fe$af273b90$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <416CF1E4.9030102@lab.ntt.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit We may want to lowercase the MUSTs in this section. It is "MUST be able". This does not mean that they MUST do this. We were listing the capabilities that we believe are required for any new work in DHCPv4 security to support. If new work in this area can't provide this capability, we likely should not consider that work until it does provide this support. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Mayumi Yanagiya > Sent: Wednesday, October 13, 2004 5:14 AM > To: dhcwg@ietf.org > Subject: [dhcwg] [Q] Threat analysis > > > Hi, > > I have a question on "DHCPv4 Threat Analysis". > > In section 4.2, capability of client is described as follows. > "Clients MUST be able to authenticate servers (to prevent > misconfigured clients and assure that the correct servers are > being contacted)." > > I understood this sentence didn't mean that client MUST > authenticate server whenever client uses DHCP. Is my > understanding right? > > > --Mayumi > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Oct 14 11:32:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00422; Thu, 14 Oct 2004 11:32:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI7Sa-0005sL-3P; Thu, 14 Oct 2004 11:24:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI7SC-0005g4-W1; Thu, 14 Oct 2004 11:23:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29707; Thu, 14 Oct 2004 11:23:42 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI7dN-0004bs-7M; Thu, 14 Oct 2004 11:35:18 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 14 Oct 2004 11:23:11 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9EFN9YX007382; Thu, 14 Oct 2004 11:23:10 -0400 (EDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMH08213; Thu, 14 Oct 2004 11:23:08 -0400 (EDT) From: "Bernie Volz" To: , , Subject: RE: [dhcwg] WGLC for draft-ietf-geopriv-dhcp-civil-04.txt Date: Thu, 14 Oct 2004 11:23:08 -0400 Organization: Cisco Message-ID: <000501c4b201$b5c7fb30$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <4.3.2.7.2.20041013094804.02a861d0@flask.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi: Here's some quick review comments (these are mostly nits): - Clean up figure in 3.2? - Is there a minimum option length? Wouldn't it be at least 3 bytes (to specify the country code and what)? Or, is at least one "civic address element" also needed in which case the minimum length would be 6? - Is an IANA registry of the "what" values required? Or, do we believe = that the 3 values are all that will ever be needed (which is likely the = case)? - For clarity, section 2's text: As discussed in Security Considerations (Section 5), the GeoConf_Civi option SHOULD be returned by DHCP servers only when the DHCP client has included this option in its 'parameter request list' (Section 3.5 [2]). The DHCP long-options mechanism described in RFC 3396 [8] MUST be used if the civic address option exceeds the maximum DHCP option size of 255 octets. Should likely be reworked to: As discussed in Security Considerations (Section 5), the = GEOCONFIG_CIVIC option SHOULD be returned by DHCPv4 servers only when the DHCPv4 = client has included this option in its 'parameter request list' (Section 3.5 [2]). Similarily, the OPTION_CIVIC_ADDRESS option SHOULD be returned = by DHCPv6 servers only when the DHCPv6 client has included this option = in its OPTION_ORO. The DHCPv4 long-options mechanism described in RFC 3396 [8] MUST be used if the civic address option exceeds the maximum DHCPv4 option = size of 255 octets. And, similar adjustments should be made to section 5. - Also, in section 2, shouldn't the text: To provide multiple renderings, the client repeats sequences of address elements, prefixing each with 'language' and/or 'script' element (see Section 3.3). The language and script Be: To provide multiple renderings, the server ^^^^^^ repeats sequences of address elements, prefixing each with 'language' and/or 'script' element (see Section 3.3). The language and script - In section 3.1, it isn't immediately clear what the countrycode is = used for. I presume this is used to specify the mapping for the Catype to a textual representation? Countrycode: The two-letter ISO 3166 country code in capital ASCII letters, e.g., DE or US. - In section 6, specify that the initial allocations are provided in = Section 3.4 (I've found that IANA doesn't read the entire document, just the = IANA Considerations section so they'd need to be told about the initial = registry list or where to find it in the IANA Considerations section.) - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms > Sent: Wednesday, October 13, 2004 9:53 AM > To: dhcwg@ietf.org > Cc: Allison Mankin; Randall Gellens; Andrew Newton > Subject: [dhcwg] WGLC for draft-ietf-geopriv-dhcp-civil-04.txt >=20 >=20 > Included below is the announcement of a WG last call on=20 > draft-ietf-geopriv-dhcp-civil-04.txt. >=20 > Please review this draft and reply with comments directly to=20 > geopriv@ietf.org >=20 > - Ralph >=20 > ------------------------ > Begin forwarded message: >=20 > From: Andrew Newton > Date: October 13, 2004 8:47:44 AM EDT > To: GEOPRIV WG > Cc: Randall Gellens , Allison Mankin=20 > > Subject: WGLC for draft-ietf-geopriv-dhcp-civil-04.txt >=20 > This begins a working group last call for=20 > draft-ietf-geopriv-dhcp-civil-04.txt for the GEOPRIV working group. >=20 > The GEOPRIV co-chairs will ask for a simultaneous last call=20 > of this document in DHC working group. >=20 > This duration of this last call is to be 3 weeks, concluding=20 > on November 3, 2004. >=20 > -andy >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 15 06:13:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13285; Fri, 15 Oct 2004 06:13:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIP2Q-0004S4-7s; Fri, 15 Oct 2004 06:10:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIOyj-0003sM-84 for dhcwg@megatron.ietf.org; Fri, 15 Oct 2004 06:06:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12947 for ; Fri, 15 Oct 2004 06:06:26 -0400 (EDT) Received: from tama55.ecl.ntt.co.jp ([129.60.39.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIPA4-0002vn-B1 for dhcwg@ietf.org; Fri, 15 Oct 2004 06:18:13 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama55.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9FA6NPL013254; Fri, 15 Oct 2004 19:06:23 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9FA6N3V019528; Fri, 15 Oct 2004 19:06:23 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9FA6MpE019523; Fri, 15 Oct 2004 19:06:22 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9FA6MWw006051; Fri, 15 Oct 2004 19:06:22 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9FA6Mtg006046; Fri, 15 Oct 2004 19:06:22 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9FA6L8M013736; Fri, 15 Oct 2004 19:06:21 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9FA6LL8012101; Fri, 15 Oct 2004 19:06:21 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (ime0.m.ecl.ntt.co.jp [129.60.5.143]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9FA6KTR012098; Fri, 15 Oct 2004 19:06:20 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id TAA05605; Fri, 15 Oct 2004 19:06:20 +0900 (JST) Message-ID: <416FA204.1040403@lab.ntt.co.jp> Date: Fri, 15 Oct 2004 19:10:12 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Bernie Volz Subject: Re: [dhcwg] [Q] Threat analysis References: <000401c4b1fe$af273b90$d0412ca1@amer.cisco.com> In-Reply-To: <000401c4b1fe$af273b90$d0412ca1@amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tama55.ecl.ntt.co.jp id i9FA6NPL013254 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Berinie, Thank you for your reply. I understood the meaning. The reason why I asked such question is=85 I think that broadcast messages are isolated per subscriber in many=20 public access services. Thus, it is difficult for another subscriber to=20 impersonate DHCP server, and it is easy to impersonate DHCP client. So, I personally think that client authentication by server is more=20 important. Best Regards, --Mayumi > We may want to lowercase the MUSTs in this section. > > It is "MUST be able". This does not mean that they MUST do this. > > We were listing the capabilities that we believe are required for any = new > work in DHCPv4 security to support. If new work in this area can't=20 provide > this capability, we likely should not consider that work until it does > provide this support. > > - Bernie > > >>-----Original Message----- >>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] >>On Behalf Of Mayumi Yanagiya >>Sent: Wednesday, October 13, 2004 5:14 AM >>To: dhcwg@ietf.org >>Subject: [dhcwg] [Q] Threat analysis >> >> >>Hi, >> >>I have a question on "DHCPv4 Threat Analysis". >> >>In section 4.2, capability of client is described as follows. >> "Clients MUST be able to authenticate servers (to prevent >> misconfigured clients and assure that the correct servers are >> being contacted)." >> >>I understood this sentence didn't mean that client MUST >>authenticate server whenever client uses DHCP. Is my >>understanding right? >> >> >>--Mayumi >> >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/dhcwg >> > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 15 23:58:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04541; Fri, 15 Oct 2004 23:58:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIffw-0007K7-C6; Fri, 15 Oct 2004 23:56:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIff9-00075k-6x; Fri, 15 Oct 2004 23:55:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04342; Fri, 15 Oct 2004 23:55:19 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIfqc-0005SV-TU; Sat, 16 Oct 2004 00:07:16 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 Oct 2004 00:15:12 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9G3slj9015636; Fri, 15 Oct 2004 23:54:47 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-2-95.cisco.com [10.86.242.95]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMI37103; Fri, 15 Oct 2004 23:54:45 -0400 (EDT) From: "Bernie Volz" To: "'Henning Schulzrinne'" Subject: RE: [dhcwg] WGLC for draft-ietf-geopriv-dhcp-civil-04.txt Date: Fri, 15 Oct 2004 23:54:45 -0400 Organization: Cisco Message-ID: <003e01c4b333$e049e660$6501a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <41708EE7.206@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, dhcwg@ietf.org, hgs+simple@cs.columbia.edu X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Henning: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_CIVIC_ADDRESS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Countrycode | what | elements ... | civic address elements | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Would usually be shown as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_CIVIC_ADDRESS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Countrycode | what | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . civic address elements . . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (At least if we use RFC 3315 and 3633 as a guide.) But, it's no big deal. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, October 15, 2004 11:01 PM > To: Bernie Volz > Cc: hgs+simple@cs.columbia.edu; dhcwg@ietf.org; geopriv@ietf.org > Subject: Re: [dhcwg] WGLC for draft-ietf-geopriv-dhcp-civil-04.txt > > > Bernie Volz wrote: > > Hi: > > > > Here's some quick review comments (these are mostly nits): > > > > - Clean up figure in 3.2? > > Can you clarify? I must be missing something obvious as to > the defects > of the figure... > > > > > - Is there a minimum option length? Wouldn't it be at least 3 bytes > > (to specify the country code and what)? Or, is at least one "civic > > address element" also needed in which case the minimum > length would be > > 6? > > All elements are optional, so min. length would be 3 (just > country code > + what). > > > > > - Is an IANA registry of the "what" values required? Or, do > we believe > > that the 3 values are all that will ever be needed (which is likely > > the case)? > > I suspect that additional values are sufficiently unlikely > that we can > rely on a revised version of the document for extending the > registry. I > don't feel strongly about this; there used to be a time, > maybe now past, > where adding IANA registries was considered ill-advised. > > > > > - For clarity, section 2's text: > > ... > > Fixed. > > > > > And, similar adjustments should be made to section 5. > > Fixed. > > > > > - Also, in section 2, shouldn't the text: > > > To provide multiple renderings, the server > > ^^^^^^ > > repeats sequences of address elements, prefixing each > with 'language' > > and/or 'script' element (see Section 3.3). The language > and script > > Indeed. > > > > > > - In section 3.1, it isn't immediately clear what the > countrycode is > > used for. I presume this is used to specify the mapping for > the Catype > > to a textual representation? > > > > Countrycode: The two-letter ISO 3166 country code in > capital ASCII > > letters, e.g., DE or US. > > > Not really. This is just for space efficiency, since every > civic address > must contain a country code and since its length is fixed. > There is no > assumed mapping from country to language or script. I added a > parenthesized explanation. > > > > > - In section 6, specify that the initial allocations are > provided in > > Section 3.4 (I've found that IANA doesn't read the entire document, > > just the IANA Considerations section so they'd need to be > told about > > the initial registry list or where to find it in the IANA > > Considerations section.) > > > > Reference added. > > Thanks for your comments! > > Henning > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Oct 18 09:23:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15159; Mon, 18 Oct 2004 09:23:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJXNC-00079E-RH; Mon, 18 Oct 2004 09:16:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIeoZ-0001dY-Nn; Fri, 15 Oct 2004 23:01:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01493; Fri, 15 Oct 2004 23:01:01 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIf03-0004X8-Ac; Fri, 15 Oct 2004 23:12:56 -0400 Received: from razor.cs.columbia.edu (IDENT:Ce9qvSsB/4CKHZEk8jakl2mxv80d7jJn@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9G30ux6006673 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 15 Oct 2004 23:00:56 -0400 (EDT) Received: from [127.0.0.1] (IDENT:V5tjJ45yZY9tWLOho04IFCpu+UpqNMrb@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9G30tYZ007325; Fri, 15 Oct 2004 23:00:55 -0400 Message-ID: <41708EE7.206@cs.columbia.edu> Date: Fri, 15 Oct 2004 23:00:55 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernie Volz Subject: Re: [dhcwg] WGLC for draft-ietf-geopriv-dhcp-civil-04.txt References: <000501c4b201$b5c7fb30$d0412ca1@amer.cisco.com> In-Reply-To: <000501c4b201$b5c7fb30$d0412ca1@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.15.2 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 18 Oct 2004 09:16:25 -0400 Cc: geopriv@ietf.org, dhcwg@ietf.org, hgs+simple@cs.columbia.edu X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Bernie Volz wrote: > Hi: > > Here's some quick review comments (these are mostly nits): > > - Clean up figure in 3.2? Can you clarify? I must be missing something obvious as to the defects of the figure... > > - Is there a minimum option length? Wouldn't it be at least 3 bytes (to > specify the country code and what)? Or, is at least one "civic address > element" also needed in which case the minimum length would be 6? All elements are optional, so min. length would be 3 (just country code + what). > > - Is an IANA registry of the "what" values required? Or, do we believe that > the 3 values are all that will ever be needed (which is likely the case)? I suspect that additional values are sufficiently unlikely that we can rely on a revised version of the document for extending the registry. I don't feel strongly about this; there used to be a time, maybe now past, where adding IANA registries was considered ill-advised. > > - For clarity, section 2's text: ... Fixed. > > And, similar adjustments should be made to section 5. Fixed. > > - Also, in section 2, shouldn't the text: > To provide multiple renderings, the server > ^^^^^^ > repeats sequences of address elements, prefixing each with 'language' > and/or 'script' element (see Section 3.3). The language and script Indeed. > > - In section 3.1, it isn't immediately clear what the countrycode is used > for. I presume this is used to specify the mapping for the Catype to a > textual representation? > > Countrycode: The two-letter ISO 3166 country code in capital ASCII > letters, e.g., DE or US. Not really. This is just for space efficiency, since every civic address must contain a country code and since its length is fixed. There is no assumed mapping from country to language or script. I added a parenthesized explanation. > > - In section 6, specify that the initial allocations are provided in Section > 3.4 (I've found that IANA doesn't read the entire document, just the IANA > Considerations section so they'd need to be told about the initial registry > list or where to find it in the IANA Considerations section.) > Reference added. Thanks for your comments! Henning _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Oct 18 21:20:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14312; Mon, 18 Oct 2004 21:20:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJiJ5-0002Bj-OG; Mon, 18 Oct 2004 20:56:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJi1N-0007Ix-P8 for dhcwg@megatron.ietf.org; Mon, 18 Oct 2004 20:38:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11065 for ; Mon, 18 Oct 2004 20:38:31 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJiDM-00069U-66 for dhcwg@ietf.org; Mon, 18 Oct 2004 20:51:03 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I5T00N6K3394B@mailout2.samsung.com> for dhcwg@ietf.org; Tue, 19 Oct 2004 09:37:57 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I5T00JSG31ZYD@mailout2.samsung.com> for dhcwg@ietf.org; Tue, 19 Oct 2004 09:37:11 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I5T003RZ31YZ1@mmp1.samsung.com> for dhcwg@ietf.org; Tue, 19 Oct 2004 09:37:11 +0900 (KST) Date: Tue, 19 Oct 2004 09:38:37 +0900 From: Soohong Daniel Park To: Dhcwg Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7BIT Cc: Syam-SISO , soohong.park@samsung.com Subject: [dhcwg] Anycast Address Assignment Using DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT To raise the awareness of this work, I am posting it using below link and submitted draft will appear soon. http://daniel.vsix.net/daniel/draft-madanapalli-dhcpv6-anycast-00.txt This protocol is useful to let client you service unique identifiers with anycast address, so that client will use a stable and reliable service. If one of the servers fails, other servers can still provide service because packets with the anycast address are routed to another nearest server. Comments are highly welcome Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Oct 19 06:47:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09580; Tue, 19 Oct 2004 06:47:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJr9e-0008MD-1l; Tue, 19 Oct 2004 06:23:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJqtn-0005BI-IR for dhcwg@megatron.ietf.org; Tue, 19 Oct 2004 06:07:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06996 for ; Tue, 19 Oct 2004 06:07:11 -0400 (EDT) Received: from mail.nttv6.net ([192.68.245.115]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJr5o-0000eU-50 for dhcwg@ietf.org; Tue, 19 Oct 2004 06:19:49 -0400 Received: from [10.0.22.187] ([192.16.178.225]) by mail.nttv6.net (8.13.1/3.7Wpl2-00020918) with ESMTP id i9JA4ahD020554 for ; Tue, 19 Oct 2004 19:04:36 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Dhcwg From: Arifumi Matsumoto Date: Tue, 19 Oct 2004 19:07:14 +0900 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [dhcwg] New Draft on DHCPv6 Source Address Selection Policy Option Posted X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello all, I've submitted a new Internet-Draft to distribute source address selection policies via DHCPv6. draft-hirotaka-dhc-source-address-selection-opt-00.txt There are two other related I-Ds, one is a brief overview of our proposed model. http://www.nttv6.net/~arifumi/draft-arifumi-multi6-sas-policy-dist -00.txt And the other is a new option proposal for Neighbor Discovery Router Advertisement Message. http://www.nttv6.net/~arifumi/draft-arifumi-ipv6-nd-source-address- selection-opt-00.txt # Later two drafts will be on IETF server soon, I hope.. Please give me questions and comments. -- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Oct 19 07:58:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14994; Tue, 19 Oct 2004 07:58:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsEV-0001WQ-6V; Tue, 19 Oct 2004 07:32:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJrq2-0006To-MG for dhcwg@megatron.ietf.org; Tue, 19 Oct 2004 07:07:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10898; Tue, 19 Oct 2004 07:07:26 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJs28-0001h2-BJ; Tue, 19 Oct 2004 07:20:05 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 19 Oct 2004 04:16:55 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9JB6qk2009796; Tue, 19 Oct 2004 04:06:53 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn1-230.cisco.com [10.21.96.230]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMJ66919; Tue, 19 Oct 2004 07:06:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20041019070432.01f46e50@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Oct 2004 07:06:49 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: agenda@ietf.org Subject: [dhcwg] Tentative agenda for dhc WG meeting at IETF 61 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Here is the latest draft agenda for the dhc WG meeting at IETF 61. - Ralph DHC WG agenda - IETF 61 0900 Mon 2004-11-08 (tentative) (Last revised 10/19/2004 06:56 AM) ---------------------------------- Administrivia Ralph Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Request for milestones for dhc WG drafts DNS zone suffix option for DHCPv6 Renxiang Yan 10 minutes Accept as dhc WG work item? Reclassifying DHCPv4 Options TBD 10 minutes How to implement the process after RFC is published? Vendor-Specific Information Suboption Mark Stapp 10 minutes Ready for WG last call? DHCP Authentication via EAP Mark Stapp 10 minutes Technical discussion Lifetime Option for DHCPv6 Stig Venaas 10 minutes Ready for WG last call? Anycast Address Assignment using DHCPv6 Syam Madanapalli 10 minutes Accept as dhc WG work item? Source Address Selection Policy option for DHCPv6 Arifumi Matsumoto 10 minutes (available as http://www.nttv6.net/~arifumi/draft-hirotaka-dhc-source-address-selection-opt-00.txt) Accept as dhc WG work item? DHCP-DNS interaction Bernie Volz 30 minutes Technical discussion ----------- 110 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Oct 19 09:17:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22628; Tue, 19 Oct 2004 09:17:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJskx-0006az-NJ; Tue, 19 Oct 2004 08:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsQU-0003OU-NP; Tue, 19 Oct 2004 07:45:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13783; Tue, 19 Oct 2004 07:45:13 -0400 (EDT) Message-Id: <200410191145.HAA13783@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 19 Oct 2004 07:45:13 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-clarify-auth-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --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 : Clarifications on DHCPv6 Authentication Author(s) : T. Jinmei Filename : draft-ietf-dhc-dhcpv6-clarify-auth-00.txt Pages : 13 Date : 2004-10-18 This document describes issues about the authentication mechanism of the Dynamic Host Configuration Protocol for IP version 6 that were identified from implementation experiences. It also tries to propose resolutions to some of the issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-clarify-auth-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-clarify-auth-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-clarify-auth-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: <2004-10-18172729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-clarify-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-clarify-auth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-18172729.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Tue Oct 19 09:23:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23168; Tue, 19 Oct 2004 09:23:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsl0-0006bW-5N; Tue, 19 Oct 2004 08:06:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsQc-0003RP-1h; Tue, 19 Oct 2004 07:45:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13791; Tue, 19 Oct 2004 07:45:20 -0400 (EDT) Message-Id: <200410191145.HAA13791@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 19 Oct 2004 07:45:20 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Detection of Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-09.txt Pages : 16 Date : 2004-10-18 The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. This document synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and Link-Local IPv4 addresses. A procedure is specified for detection of network attachment in order to better accommodate mobile hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dna-ipv4-09.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-dna-ipv4-09.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: <2004-10-18172734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-18172734.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Thu Oct 21 15:15:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08412; Thu, 21 Oct 2004 15:15:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiA3-00021H-5b; Thu, 21 Oct 2004 14:59:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhn1-0005he-FH for dhcwg@megatron.ietf.org; Thu, 21 Oct 2004 14:35:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03928 for ; Thu, 21 Oct 2004 14:35:53 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhzf-0002nF-I7 for dhcwg@ietf.org; Thu, 21 Oct 2004 14:49:01 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2004 11:43:17 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9LIZFk2025075 for ; Thu, 21 Oct 2004 11:35:15 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.190]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AML78509; Thu, 21 Oct 2004 14:35:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20041021143445.02504d48@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Oct 2004 14:35:14 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [dhcwg] BCMCS server option drafts X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org We need to have a short WG conversation about two options that were discussed at the WG meeting in San Diego. The outcome of the conversation will be to determine consensus about taking on these two drafts: draft-chowdhury-dhc-bcmcv4-option-01.txt draft-chowdhury-dhc-bcmcv6-option-01.txt as dhc WG work items or recommending that 3GPP2 define vendor-identifying vendor-specific option (VIVSO; option code 125) sub-options to carry the information described in the drafts. If the WG consensus is to take on the drafts as WG work items drafts, are they acceptable as currently published? Because of the time constraints imposed by the 3GPP2 schedule, I'm going to cut off discussion on this topic next Thursday, 10/28, and determine WG consensus at that time. Here are some considerations for discussion: 3GPP2 has defined some vendor-specific sub-options, for example, to identify a MIP home agent for the DHCP client. A 3GPP2 client needs to specify to the DHCP server which parameters it needs - specifically, whether it needs to receive the BCMCS servers. If the current drafts are adopted, the client can simply use the parameter request list option (option code 55) for the request. If a VIVSO sub-option is used, 3GPP2 would also define a parameter request list sub-option. There is a deployment issue, as some service providers already have DHCP servers in place that must be updated for any new options. Is it the case that the options defined in the current drafts can be supported without code changes to existing servers? Use of a VIVSO sub-option would require code changes to existing servers. How long would it take to deploy DHCP server that can support VIVSO. BCMCS may be adopted across multiple technologies, so the options in the current drafts would not be specific to 3GPP2. However, the BCMCS specification has not adopted by other standards, yet, so we may need to define additional options for related services in the future if those services are not interoperable with the 3GPP2 BCMCS service. CableLabs has one option with sub-options (RFC 3495) rather than multiple options because: * wanted to avoid exhaustion of DHCP option code space; perhaps less of an issue with option code reclassification * would have used VIVSO if available * use of VIVSO with sub-options would give 3GPP2 freedom to define new sub-options on demand Do these considerations have an impact on our decision about how to proceed with the 3GPP2 options? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Oct 21 16:17:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16960; Thu, 21 Oct 2004 16:17:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiuK-0002XX-Cl; Thu, 21 Oct 2004 15:47:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKihU-00078z-1r; Thu, 21 Oct 2004 15:34:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10907; Thu, 21 Oct 2004 15:34:13 -0400 (EDT) Message-Id: <200410211934.PAA10907@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 21 Oct 2004 15:34:13 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-proxyserver-opt-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Option for Proxy Server Configuration Author(s) : S. Balasubramanian, et al. Filename : draft-ietf-dhc-proxyserver-opt-02.txt Pages : 10 Date : 2004-10-21 This document defines a new Dynamic Host Configuration Protocol (DHCP) option, which can be used to configure the TCP/IP host's Proxy Server configuration for standard protocols like HTTP, FTP, NNTP, SOCKS, Gopher, SLL and etc. Proxy Server provides controlled and efficient access to the Internet by access control mechanism for different types of user requests and caching frequently accessed information (Web pages and possibly files that might have been downloaded using FTP and other protocols). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-proxyserver-opt-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-proxyserver-opt-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: <2004-10-21154042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-proxyserver-opt-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-proxyserver-opt-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-21154042.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Thu Oct 21 21:00:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18090; Thu, 21 Oct 2004 21:00:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl92-0007vw-19; Thu, 21 Oct 2004 18:10:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjIi-0007tg-RL for dhcwg@megatron.ietf.org; Thu, 21 Oct 2004 16:12:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15674 for ; Thu, 21 Oct 2004 16:12:42 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjVO-0005RQ-M2 for dhcwg@ietf.org; Thu, 21 Oct 2004 16:25:51 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 Oct 2004 16:33:36 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9LKCA7K000078; Thu, 21 Oct 2004 16:12:10 -0400 (EDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AML88368; Thu, 21 Oct 2004 16:12:08 -0400 (EDT) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] BCMCS server option drafts Date: Thu, 21 Oct 2004 16:12:08 -0400 Organization: Cisco Message-ID: <002e01c4b7aa$3e045090$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <4.3.2.7.2.20041021143445.02504d48@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Personally, I'd like to see the DHCPv4 VIVSO get deployed and pushing = these options to using it would be a step at making this happen (as one would expect 3GPP2 vendors to have some significant input to the decisions of = DHCP server vendors). It also means that 3GPP2 is free to define other VIVSO options in the = future within their own forum and need not go to the IETF (and DHC WG). I = suspect that this would provide much faster deployment for them in the future. Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS are already there for DHCPv6. BTW, 3GPP2 already has an enterprise-id number: 5535 3rd Generation Partnership Project 2 (3GPP2) Allen Long along@cisco.com So, they'd be good to go! - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms > Sent: Thursday, October 21, 2004 2:35 PM > To: dhcwg@ietf.org > Subject: [dhcwg] BCMCS server option drafts >=20 >=20 > We need to have a short WG conversation about two options=20 > that were discussed at the WG meeting in San Diego. The=20 > outcome of the conversation will be to determine consensus=20 > about taking on these two > drafts: >=20 > draft-chowdhury-dhc-bcmcv4-option-01.txt > draft-chowdhury-dhc-bcmcv6-option-01.txt >=20 > as dhc WG work items or recommending that 3GPP2 define=20 > vendor-identifying vendor-specific option (VIVSO; option code=20 > 125) sub-options to carry the information described in the drafts. >=20 > If the WG consensus is to take on the drafts as WG work items=20 > drafts, are they acceptable as currently published? >=20 > Because of the time constraints imposed by the 3GPP2=20 > schedule, I'm going to cut off discussion on this topic next=20 > Thursday, 10/28, and determine WG consensus at that time. >=20 > Here are some considerations for discussion: >=20 > 3GPP2 has defined some vendor-specific sub-options, for=20 > example, to identify a MIP home agent for the DHCP client. >=20 > A 3GPP2 client needs to specify to the DHCP server which=20 > parameters it needs - specifically, whether it needs to=20 > receive the BCMCS servers. If the current drafts are adopted,=20 > the client can simply use the parameter request list option=20 > (option code 55) for the request. If a VIVSO sub-option is=20 > used, 3GPP2 would also define a parameter request list sub-option. >=20 > There is a deployment issue, as some service providers=20 > already have DHCP servers in place that must be updated for=20 > any new options. Is it the case that the options defined in=20 > the current drafts can be supported without code changes to=20 > existing servers? Use of a VIVSO sub-option would require=20 > code changes to existing servers. How long would it take to=20 > deploy DHCP server that can support VIVSO. >=20 > BCMCS may be adopted across multiple technologies, so the=20 > options in the current drafts would not be specific to 3GPP2.=20 > However, the BCMCS specification has not adopted by other=20 > standards, yet, so we may need to define additional options=20 > for related services in the future if those services are not=20 > interoperable with the 3GPP2 BCMCS service. >=20 > CableLabs has one option with sub-options (RFC 3495) rather=20 > than multiple options because: > * wanted to avoid exhaustion of DHCP option code space; perhaps less > of an issue with option code reclassification > * would have used VIVSO if available > * use of VIVSO with sub-options would give 3GPP2 freedom to define new > sub-options on demand > Do these considerations have an impact on our decision about=20 > how to proceed with the 3GPP2 options? >=20 > - Ralph >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 22 12:55:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20173; Fri, 22 Oct 2004 12:55:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2f2-0002xA-Hu; Fri, 22 Oct 2004 12:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2XP-0000Tf-U3 for dhcwg@megatron.ietf.org; Fri, 22 Oct 2004 12:45:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19465 for ; Fri, 22 Oct 2004 12:45:07 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2kD-0001y8-GE for dhcwg@ietf.org; Fri, 22 Oct 2004 12:58:27 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9MGiYjH029488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Oct 2004 09:44:35 -0700 (PDT) Received: from WLAU.qualcomm.com (wlau.qualcomm.com [129.46.74.167]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9MGiW9A005132 for ; Fri, 22 Oct 2004 09:44:33 -0700 (PDT) Message-Id: <6.0.0.22.2.20041022092741.046dca70@qcmail1.qualcomm.com> X-Sender: wlau@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 22 Oct 2004 09:44:30 -0700 To: dhcwg@ietf.org From: Wing Cheong Lau Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1858374065==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1858374065== Content-Type: multipart/alternative; boundary="=====================_149297728==.ALT" --=====================_149297728==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear all, We have submitted a new draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option last week. It's already available from the ietf site http://www.ietf.org/internet-drafts/draft-droms-dhc-v6-relayopt-00.txt but I have not seen the official announcement so far. The draft basically carries over similar capabilities, namely, RFC 3046 and draft-ietf-dhc-agentopt-radius-08.txt from DHCPv4 to DHCPv6, with initial use cases targetting for the 3GPP2 environment. Comments are welcome. Regards, Wing Abstract This document introduces the capabilities of the DHCPv4 Relay Agent Information Option in RFC 3046 and the corresponding RADIUS- Attributes Sub-option to DHCPv6. In particular, the document describes a new DHCPv6 option called the Relay Agent Information option which extends the set of DHCPv6 options as defined in RFC 3315 and 3376. Following its DHCPv4 counterpart as defined in RFC 3046, the new option is inserted by the DHCPv6 relay agent when forwarding client-originated DHCPv6 packets to a DHCPv6 server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client. The Relay Agent Information option is organized as a single DHCPv6 option that contains one or more "sub-options" that convey information known by the relay agent. A RADIUS Attributes Sub-option, following its DHCPv4 counterpart, is also defined. --=====================_149297728==.ALT Content-Type: text/html; charset="us-ascii" Dear all,

We have submitted a new draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option last week. It's already available from the ietf site

http://www.ietf.org/internet-drafts/draft-droms-dhc-v6-relayopt-00.txt

but I have not seen the official announcement so far.

The draft basically carries over similar capabilities, namely,
RFC 3046 and draft-ietf-dhc-agentopt-radius-08.txt
from DHCPv4 to DHCPv6, with initial use cases targetting for
the 3GPP2 environment.

Comments are welcome.

Regards,

Wing

Abstract
   
   This document introduces the capabilities of the DHCPv4 Relay Agent
   Information Option in RFC 3046 and the corresponding RADIUS-
   Attributes Sub-option to DHCPv6. In particular, the document
   describes a new DHCPv6 option called the Relay Agent Information
   option which extends the set of DHCPv6 options as defined in RFC 3315
   and 3376. Following its DHCPv4 counterpart as defined in RFC 3046,
   the new option is inserted by the DHCPv6 relay agent when forwarding
   client-originated DHCPv6 packets to a DHCPv6 server. Servers
   recognizing the Relay Agent Information option may use the
   information to implement IP address or other parameter assignment
   policies.  The DHCP Server echoes the option back verbatim to the
   relay agent in server-to-client replies, and the relay agent strips
   the option before forwarding the reply to the client. The Relay Agent
   Information option is organized as a single DHCPv6 option that
   contains one or more "sub-options" that convey information known by
   the relay agent.  A RADIUS Attributes Sub-option, following its
   DHCPv4 counterpart, is also defined.  --=====================_149297728==.ALT-- --===============1858374065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1858374065==-- From dhcwg-bounces@ietf.org Fri Oct 22 18:45:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06131; Fri, 22 Oct 2004 18:45:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7p8-00053W-EW; Fri, 22 Oct 2004 18:23:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL79n-0002WN-0Z; Fri, 22 Oct 2004 17:41:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23323; Fri, 22 Oct 2004 17:41:02 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7Md-0002sH-Kv; Fri, 22 Oct 2004 17:54:24 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i9MLcYi29125; Fri, 22 Oct 2004 14:38:34 -0700 (PDT) Message-Id: <200410222138.i9MLcYi29125@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 22 Oct 2004 14:38:34 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 3925 on Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3925 Title: Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) Author(s): J. Littlefield Status: Standards Track Date: October 2004 Mailbox: joshl@cisco.com Pages: 9 Characters: 17999 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-vendor-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3925.txt The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <041022143705.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3925 --OtherAccess Content-Type: Message/External-body; name="rfc3925.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <041022143705.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Fri Oct 22 18:48:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06771; Fri, 22 Oct 2004 18:48:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7pK-0005HD-8n; Fri, 22 Oct 2004 18:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7Ab-0003Hn-Qh for dhcwg@megatron.ietf.org; Fri, 22 Oct 2004 17:41:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23603 for ; Fri, 22 Oct 2004 17:41:52 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7NR-0002wi-D5 for dhcwg@ietf.org; Fri, 22 Oct 2004 17:55:14 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2004 18:02:56 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9MLfIxT003311; Fri, 22 Oct 2004 17:41:19 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-2-248.cisco.com [10.86.242.248]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMM74668; Fri, 22 Oct 2004 17:41:17 -0400 (EDT) From: "Bernie Volz" To: "'Wing Cheong Lau'" , Subject: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option Date: Fri, 22 Oct 2004 17:41:17 -0400 Organization: Cisco Message-ID: <004301c4b87f$dcc8efd0$6501a8c0@amer.cisco.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <6.0.0.22.2.20041022092741.046dca70@qcmail1.qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.6 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: "'Ralph Droms'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1745972218==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1745972218== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C4B85E.55B74FD0" This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C4B85E.55B74FD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable A very basic question ... why have a Relay Agent Information option and = have sub-options inside this? And, especially 8-bit suboptions. =20 It seems to me that with the larger 16-bit DHCPv6 option space, we'd = just define an option to carry the "Radius Attributes" instead of placing = this under a general "Relay Agent" option. The context of the message is = pretty clear -- if it is from the relay, it can only be in a Relay-Forw (and Relay-Reply) message option area. =20 There's also another advantage to this. Take the DHCPv4 subnet-selection option - there are two forms of this, one in for the relay agent and = another for the client. This won't be necessary in DHCPv6 as the LOCATION of the message (either in the Client's Solicit, Request, ... or in a Relay-Forw/Relay-Reply) tells us who added it and which we'd prefer to = use. This means only ONE option number is needed. =20 So, I'd much rather see this specify a base option, OPTION-RADIUS-ATTRIBUTES, and have this contain the Radius attributes in = the standard Radius encoding. So, it is just 16-bit option code, 16-bit = length, followed by the radius encoding (as 8-bit suboptions). =20 You can then specify that OPTION-RADIUS-ATTRIBUTES can only appear in = the Relay-Forw (and Relay-Reply) message and MUST NOT appear in client = messages themselves. =20 - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Wing Cheong Lau Sent: Friday, October 22, 2004 12:45 PM To: dhcwg@ietf.org Subject: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option Dear all, We have submitted a new draft on DHCPv6 Relay Information Option and = RADIUS Attributes sub-option last week. It's already available from the ietf = site=20 http://www.ietf.org/internet-drafts/draft-droms-dhc-v6-relayopt-00.txt but I have not seen the official announcement so far. The draft basically carries over similar capabilities, namely,=20 RFC 3046 and draft-ietf-dhc-agentopt-radius-08.txt from DHCPv4 to DHCPv6, with initial use cases targetting for=20 the 3GPP2 environment. Comments are welcome. Regards, Wing Abstract=20 =20 This document introduces the capabilities of the DHCPv4 Relay Agent=20 Information Option in RFC 3046 and the corresponding RADIUS- Attributes Sub-option to DHCPv6. In particular, the document=20 describes a new DHCPv6 option called the Relay Agent Information=20 option which extends the set of DHCPv6 options as defined in RFC 3315 = and 3376. Following its DHCPv4 counterpart as defined in RFC 3046,=20 the new option is inserted by the DHCPv6 relay agent when forwarding=20 client-originated DHCPv6 packets to a DHCPv6 server. Servers=20 recognizing the Relay Agent Information option may use the=20 information to implement IP address or other parameter assignment=20 policies. The DHCP Server echoes the option back verbatim to the=20 relay agent in server-to-client replies, and the relay agent strips=20 the option before forwarding the reply to the client. The Relay Agent = Information option is organized as a single DHCPv6 option that=20 contains one or more "sub-options" that convey information known by=20 the relay agent. A RADIUS Attributes Sub-option, following its=20 DHCPv4 counterpart, is also defined. =20 ------=_NextPart_000_0044_01C4B85E.55B74FD0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
A very=20 basic question ... why have a Relay Agent Information option=20 and have sub-options inside this? And, especially 8-bit=20 suboptions.
 
It=20 seems to me that with the larger 16-bit DHCPv6 option space, we'd = just=20 define an option to carry the "Radius Attributes" instead of placing = this under=20 a general "Relay Agent" option. The context of the message is pretty = clear -- if=20 it is from the relay, it can only be in a Relay-Forw (and Relay-Reply) = message=20 option area.
 
There's also another advantage to this. Take = the DHCPv4=20 subnet-selection option - there are two forms of this, one in for the = relay=20 agent and another for the client. This won't be necessary in DHCPv6 as = the=20 LOCATION of the message (either in the Client's Solicit, Request, ... or = in a=20 Relay-Forw/Relay-Reply) tells us who added it and which we'd prefer to = use. This=20 means only ONE option number is needed.
 
So,=20 I'd much rather see this specify a base option, = OPTION-RADIUS-ATTRIBUTES, and=20 have this contain the Radius attributes in the standard Radius encoding. = So, it=20 is just 16-bit option code, 16-bit length, followed by the radius = encoding (as=20 8-bit suboptions).
 
You=20 can then specify that OPTION-RADIUS-ATTRIBUTES can only appear in the = Relay-Forw=20 (and Relay-Reply) message and MUST NOT appear in client messages=20 themselves.
 
-=20 Bernie
-----Original Message-----
From:=20 dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Wing Cheong Lau
Sent: Friday, October 22, 2004 12:45=20 PM
To: dhcwg@ietf.org
Subject: [dhcwg] New draft = on DHCPv6=20 Relay Information Option and RADIUS Attributes=20 sub-option

Dear all,

We have submitted a = new draft=20 on DHCPv6 Relay Information Option and RADIUS Attributes sub-option = last week.=20 It's already available from the ietf site

http://www.ietf.org/internet-drafts/draft-droms-dhc-v6= -relayopt-00.txt

but=20 I have not seen the official announcement so far.

The draft = basically=20 carries over similar capabilities, namely,
RFC 3046 and draft-ietf-dhc-agentopt-radius-08.txt
from=20 DHCPv4 to DHCPv6, with = initial use=20 cases targetting for
the 3GPP2 environment.

Comments are=20 welcome.

Regards,

Wing

Abstract
    =
  =20 This document introduces the capabilities of the DHCPv4 Relay Agent=20
   Information Option in RFC 3046 and the corresponding=20 RADIUS-
   Attributes Sub-option to DHCPv6. In = particular, the=20 document
   describes a new DHCPv6 option called the = Relay Agent=20 Information
   option which extends the set of DHCPv6 = options as=20 defined in RFC 3315
   and 3376. Following its DHCPv4=20 counterpart as defined in RFC 3046,
   the new option is = inserted by the DHCPv6 relay agent when forwarding
  =20 client-originated DHCPv6 packets to a DHCPv6 server. Servers =
  =20 recognizing the Relay Agent Information option may use the =
  =20 information to implement IP address or other parameter assignment=20
   policies.  The DHCP Server echoes the option = back=20 verbatim to the
   relay agent in server-to-client = replies, and=20 the relay agent strips
   the option before forwarding = the reply=20 to the client. The Relay Agent
   Information option is=20 organized as a single DHCPv6 option that
   contains one = or more=20 "sub-options" that convey information known by
   the = relay=20 agent.  A RADIUS Attributes Sub-option, following its =
  =20 DHCPv4 counterpart, is also defined.  = ------=_NextPart_000_0044_01C4B85E.55B74FD0-- --===============1745972218== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1745972218==-- From dhcwg-bounces@ietf.org Fri Oct 22 20:39:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18141; Fri, 22 Oct 2004 20:39:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9rA-00028K-BL; Fri, 22 Oct 2004 20:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9bc-0002Ig-T4 for dhcwg@megatron.ietf.org; Fri, 22 Oct 2004 20:18:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15952 for ; Fri, 22 Oct 2004 20:18:00 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9oX-0001Ot-PV for dhcwg@ietf.org; Fri, 22 Oct 2004 20:31:22 -0400 Received: from [192.168.11.2] (206-169-64-120.vtc.net [206.169.64.120]) by toccata.fugue.com (Postfix) with ESMTP id C63851B2155; Fri, 22 Oct 2004 17:10:54 -0700 (MST) In-Reply-To: <004301c4b87f$dcc8efd0$6501a8c0@amer.cisco.com> References: <004301c4b87f$dcc8efd0$6501a8c0@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option Date: Fri, 22 Oct 2004 17:17:48 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "'Ralph Droms'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Er, furthermore there's already a relay encapsulation method defined in the base DHCPv6 specification. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 22 23:18:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07258; Fri, 22 Oct 2004 23:18:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLCIo-0004Cv-BL; Fri, 22 Oct 2004 23:10:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLCDw-0003Cq-EX for dhcwg@megatron.ietf.org; Fri, 22 Oct 2004 23:05:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06952 for ; Fri, 22 Oct 2004 23:05:43 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLCQs-00040z-Dq for dhcwg@ietf.org; Fri, 22 Oct 2004 23:19:07 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Oct 2004 20:13:24 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9N3586s016546; Fri, 22 Oct 2004 20:05:09 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-248.cisco.com [10.86.242.248]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMM87094; Fri, 22 Oct 2004 23:05:07 -0400 (EDT) From: "Bernie Volz" To: "'Ted Lemon'" Subject: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option Date: Fri, 22 Oct 2004 23:05:07 -0400 Organization: Cisco Message-ID: <000601c4b8ad$1a343aa0$6501a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, "'Ralph Droms'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Ted: Not sure what you're referring to. A relay would normally take a client message and place it into a = Relay-Forw with a Relay Message option containing the client's message. It can also = add any other options that it wants (and are allowed). In the base spec, = this might include an Interface-ID option, for example. And, why I suggested = was that this new I-D just define a "Radius Attribute" option which the = Relay Agent would add into the Relay-Forw message. - Bernie > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com]=20 > Sent: Friday, October 22, 2004 8:18 PM > To: Bernie Volz > Cc: dhcwg@ietf.org; 'Ralph Droms'; 'Wing Cheong Lau' > Subject: Re: [dhcwg] New draft on DHCPv6 Relay Information=20 > Option and RADIUS Attributes sub-option >=20 >=20 > Er, furthermore there's already a relay encapsulation method=20 > defined in=20 > the base DHCPv6 specification. >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Oct 23 01:20:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14183; Sat, 23 Oct 2004 01:20:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLEA9-0004V8-Ry; Sat, 23 Oct 2004 01:09:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLE2w-0001P0-UV for dhcwg@megatron.ietf.org; Sat, 23 Oct 2004 01:02:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12896 for ; Sat, 23 Oct 2004 01:02:29 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLEFu-0005qN-Qe for dhcwg@ietf.org; Sat, 23 Oct 2004 01:15:55 -0400 Received: from [192.168.2.110] (206-169-64-119.vtc.net [206.169.64.119]) by toccata.fugue.com (Postfix) with ESMTP id 561DD1B26E9; Fri, 22 Oct 2004 21:55:24 -0700 (MST) In-Reply-To: <000601c4b8ad$1a343aa0$6501a8c0@amer.cisco.com> References: <000601c4b8ad$1a343aa0$6501a8c0@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option Date: Fri, 22 Oct 2004 22:02:20 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "'Ralph Droms'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Oct 22, 2004, at 8:05 PM, Bernie Volz wrote: > A relay would normally take a client message and place it into a > Relay-Forw > with a Relay Message option containing the client's message. It can > also add > any other options that it wants (and are allowed). In the base spec, > this > might include an Interface-ID option, for example. And, why I > suggested was > that this new I-D just define a "Radius Attribute" option which the > Relay > Agent would add into the Relay-Forw message. Right, that's what I was referring to. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Oct 24 21:47:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17709; Sun, 24 Oct 2004 21:47:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLtuZ-0002Bn-6V; Sun, 24 Oct 2004 21:44:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLtsa-00021l-TP for dhcwg@megatron.ietf.org; Sun, 24 Oct 2004 21:42:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17360 for ; Sun, 24 Oct 2004 21:42:34 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLu5l-0001JB-S0 for dhcwg@ietf.org; Sun, 24 Oct 2004 21:56:24 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6400EHJA1SO9@mailout2.samsung.com> for dhcwg@ietf.org; Mon, 25 Oct 2004 10:41:52 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I64007A59VY2N@mailout2.samsung.com> for dhcwg@ietf.org; Mon, 25 Oct 2004 10:38:22 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I64008ID9VY0V@mmp2.samsung.com> for dhcwg@ietf.org; Mon, 25 Oct 2004 10:38:22 +0900 (KST) Date: Mon, 25 Oct 2004 10:39:51 +0900 From: Soohong Daniel Park To: Dhcwg Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/mixed; boundary="Boundary_(ID_FMnrSZ3dLFZJVlopLaFKgA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [dhcwg] FW: I-D ACTION:draft-madanapalli-dhcpv6-anycast-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_FMnrSZ3dLFZJVlopLaFKgA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT FYI > Title : Anycast Address Assignment using DHCPv6 > Author(s) : S. Madanapalli, et al. > Filename : draft-madanapalli-dhcpv6-anycast-00.txt > Pages : 9 > Date : 2004-10-20 > > This document introduces a new option in DHCPv6 for Anycast/Shared > Unicast Address assignment for a particular type of service that > DHCPv6 Client provides. This address assignment is much similar to > other address types assignments, except that Anycast Address > assignment requires the specification of Service Type of the Anycast > or Shared Unicast Address. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-madanapalli-dhcpv6-anycast-00.txt Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. --Boundary_(ID_FMnrSZ3dLFZJVlopLaFKgA) Content-type: Message/External-body; name=ATT00875.dat Content-disposition: attachment; filename=ATT00875.dat Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-10-21154132.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-madanapalli-dhcpv6-anycast-00.txt --Boundary_(ID_FMnrSZ3dLFZJVlopLaFKgA) Content-type: Message/External-body; name=draft-madanapalli-dhcpv6-anycast-00.txt Content-disposition: attachment; filename=draft-madanapalli-dhcpv6-anycast-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-10-21154132.I-D@ietf.org> --Boundary_(ID_FMnrSZ3dLFZJVlopLaFKgA) Content-type: text/plain; name=ATT00878.txt Content-disposition: attachment; filename=ATT00878.txt Content-Transfer-Encoding: 7BIT _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_FMnrSZ3dLFZJVlopLaFKgA) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --Boundary_(ID_FMnrSZ3dLFZJVlopLaFKgA)-- From dhcwg-bounces@ietf.org Mon Oct 25 13:04:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14332; Mon, 25 Oct 2004 13:04:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM87d-0003cm-BT; Mon, 25 Oct 2004 12:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM83I-0002jy-7v for dhcwg@megatron.ietf.org; Mon, 25 Oct 2004 12:50:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13210 for ; Mon, 25 Oct 2004 12:50:32 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8Gl-0002fw-Iz for dhcwg@ietf.org; Mon, 25 Oct 2004 13:04:32 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9PGnuRQ001914; Mon, 25 Oct 2004 09:49:56 -0700 (PDT) Received: from WLAU.qualcomm.com (wlau.qualcomm.com [129.46.74.167]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9PGnr9A022319; Mon, 25 Oct 2004 09:49:53 -0700 (PDT) Message-Id: <6.0.0.22.2.20041025092643.040c8e10@qcmail1.qualcomm.com> X-Sender: wlau@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 25 Oct 2004 09:49:51 -0700 To: dhcwg@ietf.org From: Wing Cheong Lau Subject: Fwd: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option Mime-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Cc: volz@cisco.com, Ted.Lemon@nominum.com, rdroms@cisco.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1380722247==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1380722247== Content-Type: multipart/alternative; boundary="=====================_127414882==.ALT" --=====================_127414882==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Bernie and Ted, Thanks for your suggestion. My response is interlaced below. >X-BrightmailFiltered: true >From: "Bernie Volz" >To: "'Wing Cheong Lau'" , >Cc: "'Ralph Droms'" >Subject: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and >RADIUS Attributes sub-option >Date: Fri, 22 Oct 2004 17:41:17 -0400 >Organization: Cisco >X-Mailer: Microsoft Outlook, Build 10.0.6626 >Importance: Normal >X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.97340, Antispam-Data: >2004.10.22.1 >X-OriginalArrivalTime: 22 Oct 2004 21:42:20.0795 (UTC) >FILETIME=[025954B0:01C4B880] > >A very basic question ... why have a Relay Agent Information option and >have sub-options inside this? And, especially 8-bit suboptions. > >It seems to me that with the larger 16-bit DHCPv6 option space, we'd just >define an option to carry the "Radius Attributes" instead of placing this >under a general "Relay Agent" option. The context of the message is pretty >clear -- if it is from the relay, it can only be in a Relay-Forw (and >Relay-Reply) message option area. > >There's also another advantage to this. Take the DHCPv4 subnet-selection >option - there are two forms of this, one in for the relay agent and >another for the client. This won't be necessary in DHCPv6 as the LOCATION >of the message (either in the Client's Solicit, Request, ... or in a >Relay-Forw/Relay-Reply) tells us who added it and which we'd prefer to >use. This means only ONE option number is needed. > >So, I'd much rather see this specify a base option, >OPTION-RADIUS-ATTRIBUTES, and have this contain the Radius attributes in >the standard Radius encoding. So, it is just 16-bit option code, 16-bit >length, followed by the radius encoding (as 8-bit suboptions). > > >You can then specify that OPTION-RADIUS-ATTRIBUTES can only appear in the >Relay-Forw (and Relay-Reply) message and MUST NOT appear in client >messages themselves. > >- Bernie The original intent of specifying the sub-option was to try to simplify the definition of other sub-options in the future, e.g. the DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt and to save a byte of so if the relay needs to include multiple sub-options at the same time. On 2nd thought, this "uncommon case" may not worth the complexity. Your suggestion looks cleaner. Also, the use of 16-bit instead of 8-bit length field can eliminate the 255-byte length limit of RADIUS attributes to be included. I will make it a single-level option according your suggestion in the next revision. About the naming of the option, how about "OPTION-RELAYED-RADIUS-ATTRIBUTES" instead of "OPTION-RADIUS-ATTRIBUTES" ? This is to highlight the nature of this option, i.e. being inserted by the Relay Agent. Thanks again. Regards, Wing >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of >Wing Cheong Lau >Sent: Friday, October 22, 2004 12:45 PM >To: dhcwg@ietf.org >Subject: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS >Attributes sub-option > >Dear all, > >We have submitted a new draft on DHCPv6 Relay Information Option and >RADIUS Attributes sub-option last week. It's already available from the >ietf site > >http://www.ietf.org/internet-drafts/draft-droms-dhc-v6-relayopt-00.txt > >but I have not seen the official announcement so far. > >The draft basically carries over similar capabilities, namely, >RFC 3046 and draft-ietf-dhc-agentopt-radius-08.txt >from DHCPv4 to DHCPv6, with initial use cases targetting for >the 3GPP2 environment. > >Comments are welcome. > >Regards, > >Wing > >Abstract > > This document introduces the capabilities of the DHCPv4 Relay Agent > Information Option in RFC 3046 and the corresponding RADIUS- > Attributes Sub-option to DHCPv6. In particular, the document > describes a new DHCPv6 option called the Relay Agent Information > option which extends the set of DHCPv6 options as defined in RFC 3315 > and 3376. Following its DHCPv4 counterpart as defined in RFC 3046, > the new option is inserted by the DHCPv6 relay agent when forwarding > client-originated DHCPv6 packets to a DHCPv6 server. Servers > recognizing the Relay Agent Information option may use the > information to implement IP address or other parameter assignment > policies. The DHCP Server echoes the option back verbatim to the > relay agent in server-to-client replies, and the relay agent strips > the option before forwarding the reply to the client. The Relay Agent > Information option is organized as a single DHCPv6 option that > contains one or more "sub-options" that convey information known by > the relay agent. A RADIUS Attributes Sub-option, following its > DHCPv4 counterpart, is also defined. >Ted: > >Not sure what you're referring to. > >A relay would normally take a client message and place it into a Relay-Forw >with a Relay Message option containing the client's message. It can also add >any other options that it wants (and are allowed). In the base spec, this >might include an Interface-ID option, for example. And, why I suggested was >that this new I-D just define a "Radius Attribute" option which the Relay >Agent would add into the Relay-Forw message. >- Bernie > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Friday, October 22, 2004 8:18 PM > To: Bernie Volz > Cc: dhcwg@ietf.org; 'Ralph Droms'; 'Wing Cheong Lau' > Subject: Re: [dhcwg] New draft on DHCPv6 Relay Information > Option and RADIUS Attributes sub-option > > > Er, furthermore there's already a relay encapsulation method > defined in > the base DHCPv6 specification. > --=====================_127414882==.ALT Content-Type: text/html; charset="us-ascii" Dear Bernie and Ted,

Thanks for your suggestion. My response is interlaced below.

X-BrightmailFiltered: true
From: "Bernie Volz" <volz@cisco.com>
To: "'Wing Cheong Lau'" <lau@qualcomm.com>, <dhcwg@ietf.org>
Cc: "'Ralph Droms'" <rdroms@cisco.com>
Subject: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option
Date: Fri, 22 Oct 2004 17:41:17 -0400
Organization: Cisco
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.10.22.1
X-OriginalArrivalTime: 22 Oct 2004 21:42:20.0795 (UTC) FILETIME=[025954B0:01C4B880]

A very basic question ... why have a Relay Agent Information option and have sub-options inside this? And, especially 8-bit suboptions.
 
It seems to me that with the larger 16-bit DHCPv6 option space, we'd just define an option to carry the "Radius Attributes" instead of placing this under a general "Relay Agent" option. The context of the message is pretty clear -- if it is from the relay, it can only be in a Relay-Forw (and Relay-Reply) message option area.
 
There's also another advantage to this. Take the DHCPv4 subnet-selection option - there are two forms of this, one in for the relay agent and another for the client. This won't be necessary in DHCPv6 as the LOCATION of the message (either in the Client's Solicit, Request, ... or in a Relay-Forw/Relay-Reply) tells us who added it and which we'd prefer to use. This means only ONE option number is needed.
 
So, I'd much rather see this specify a base option, OPTION-RADIUS-ATTRIBUTES, and have this contain the Radius attributes in the standard Radius encoding. So, it is just 16-bit option code, 16-bit length, followed by the radius encoding (as 8-bit suboptions).

 
You can then specify that OPTION-RADIUS-ATTRIBUTES can only appear in the Relay-Forw (and Relay-Reply) message and MUST NOT appear in client messages themselves.
 
- Bernie

The original intent of specifying the sub-option was to try to simplify the definition of other sub-options in the future,
e.g. the DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt and to
save a byte of so if the relay needs to include multiple sub-options at the same time. 
On 2nd thought, this "uncommon case"  may not worth the complexity.

Your suggestion looks cleaner.
Also, the use of 16-bit instead of 8-bit length field can  eliminate the
255-byte length limit of RADIUS attributes to be included.
I will make it a single-level option according your suggestion in the next revision.


About the naming of the option, how about  "OPTION-RELAYED-RADIUS-ATTRIBUTES"
instead of "OPTION-RADIUS-ATTRIBUTES" ? This  is to highlight the nature of this option,
i.e.  being inserted by the Relay Agent.


Thanks again.

Regards,

Wing



-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Wing Cheong Lau
Sent: Friday, October 22, 2004 12:45 PM
To: dhcwg@ietf.org
Subject: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option
Dear all,

We have submitted a new draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option last week. It's already available from the ietf site

http://www.ietf.org/internet-drafts/draft-droms-dhc-v6-relayopt-00.txt

but I have not seen the official announcement so far.

The draft basically carries over similar capabilities, namely,
RFC 3046 and draft-ietf-dhc-agentopt-radius-08.txt
from DHCPv4 to DHCPv6, with initial use cases targetting for
the 3GPP2 environment.

Comments are welcome.

Regards,

Wing

Abstract
   
   This document introduces the capabilities of the DHCPv4 Relay Agent
   Information Option in RFC 3046 and the corresponding RADIUS-
   Attributes Sub-option to DHCPv6. In particular, the document
   describes a new DHCPv6 option called the Relay Agent Information
   option which extends the set of DHCPv6 options as defined in RFC 3315
   and 3376. Following its DHCPv4 counterpart as defined in RFC 3046,
   the new option is inserted by the DHCPv6 relay agent when forwarding
   client-originated DHCPv6 packets to a DHCPv6 server. Servers
   recognizing the Relay Agent Information option may use the
   information to implement IP address or other parameter assignment
   policies.  The DHCP Server echoes the option back verbatim to the
   relay agent in server-to-client replies, and the relay agent strips
   the option before forwarding the reply to the client. The Relay Agent
   Information option is organized as a single DHCPv6 option that
   contains one or more "sub-options" that convey information known by
   the relay agent.  A RADIUS Attributes Sub-option, following its
   DHCPv4 counterpart, is also defined. 

>Ted:
>
>Not sure what you're referring to.
>
>A relay would normally take a client message and place it into a Relay-Forw
>with a Relay Message option containing the client's message. It can also add
>any other options that it wants (and are allowed). In the base spec, this
>might include an Interface-ID option, for example. And, why I suggested was
>that this new I-D just define a "Radius Attribute" option which the Relay
>Agent would add into the Relay-Forw message.

>- Bernie

> -----Original Message-----
> From: Ted Lemon [mailto:mellon@nominum.com]
> Sent: Friday, October 22, 2004 8:18 PM
> To: Bernie Volz
> Cc: dhcwg@ietf.org; 'Ralph Droms'; 'Wing Cheong Lau'
> Subject: Re: [dhcwg] New draft on DHCPv6 Relay Information
> Option and RADIUS Attributes sub-option
>
>
> Er, furthermore there's already a relay encapsulation method
> defined in
> the base DHCPv6 specification.
>
--=====================_127414882==.ALT-- --===============1380722247== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1380722247==-- From dhcwg-bounces@ietf.org Mon Oct 25 13:20:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15459; Mon, 25 Oct 2004 13:20:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8Ra-0006cQ-LY; Mon, 25 Oct 2004 13:15:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8O4-0005Wu-Vj for dhcwg@megatron.ietf.org; Mon, 25 Oct 2004 13:12:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14737 for ; Mon, 25 Oct 2004 13:12:01 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8bY-00037Z-HP for dhcwg@ietf.org; Mon, 25 Oct 2004 13:26:01 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2004 13:11:33 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9PHBS7K024502; Mon, 25 Oct 2004 13:11:29 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-2-248.cisco.com [10.86.242.248]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMN59909; Mon, 25 Oct 2004 13:11:27 -0400 (EDT) From: "Bernie Volz" To: "'Wing Cheong Lau'" , Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option Date: Mon, 25 Oct 2004 13:11:27 -0400 Organization: Cisco Message-ID: <003501c4bab5$aa200a90$6501a8c0@amer.cisco.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <6.0.0.22.2.20041025092643.040c8e10@qcmail1.qualcomm.com> Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: dae47ebd0d959deee2d6f67621ddb2e3 Cc: Ted.Lemon@nominum.com, rdroms@cisco.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1866488297==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1866488297== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C4BA94.230E6A90" This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C4BA94.230E6A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Great, I have no objection to your suggested name other than it is = rather long - perhaps it will become known as OPTION_RRA. =20 Are you or Ralph going to discuss this at the upcoming DHC WG session = and request it become a WG work item? =20 =20 BTW, we don't need a DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt because the existing DHCPv6 = Vendor options can be used by the Relay Agent just fine. Again, it is WHERE = these options appear that indicates whether they are for the client (in the = client part of the message) or the relay, in the Relay-Forw or Relay-Reply part = of the message. That work is already done and is not needed!! =20 - Bernie =20 -----Original Message----- From: Wing Cheong Lau [mailto:lau@qualcomm.com]=20 Sent: Monday, October 25, 2004 12:50 PM To: dhcwg@ietf.org Cc: Ted.Lemon@nominum.com; rdroms@cisco.com; volz@cisco.com Subject: Fwd: RE: [dhcwg] New draft on DHCPv6 Relay Information Option = and RADIUS Attributes sub-option Dear Bernie and Ted, Thanks for your suggestion. My response is interlaced below. X-BrightmailFiltered: true From: "Bernie Volz" To: "'Wing Cheong Lau'" , Cc: "'Ralph Droms'" Subject: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and = RADIUS Attributes sub-option Date: Fri, 22 Oct 2004 17:41:17 -0400 Organization: Cisco X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.10.22.1 X-OriginalArrivalTime: 22 Oct 2004 21:42:20.0795 (UTC) FILETIME=3D[025954B0:01C4B880] A very basic question ... why have a Relay Agent Information option and = have sub-options inside this? And, especially 8-bit suboptions. =20 It seems to me that with the larger 16-bit DHCPv6 option space, we'd = just define an option to carry the "Radius Attributes" instead of placing = this under a general "Relay Agent" option. The context of the message is = pretty clear -- if it is from the relay, it can only be in a Relay-Forw (and Relay-Reply) message option area. =20 There's also another advantage to this. Take the DHCPv4 subnet-selection option - there are two forms of this, one in for the relay agent and = another for the client. This won't be necessary in DHCPv6 as the LOCATION of the message (either in the Client's Solicit, Request, ... or in a Relay-Forw/Relay-Reply) tells us who added it and which we'd prefer to = use. This means only ONE option number is needed. =20 So, I'd much rather see this specify a base option, OPTION-RADIUS-ATTRIBUTES, and have this contain the Radius attributes in = the standard Radius encoding. So, it is just 16-bit option code, 16-bit = length, followed by the radius encoding (as 8-bit suboptions). =20 You can then specify that OPTION-RADIUS-ATTRIBUTES can only appear in = the Relay-Forw (and Relay-Reply) message and MUST NOT appear in client = messages themselves. =20 - Bernie The original intent of specifying the sub-option was to try to simplify = the definition of other sub-options in the future,=20 e.g. the DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt and to save a byte of so if the relay needs to include multiple sub-options at = the same time. =20 On 2nd thought, this "uncommon case" may not worth the complexity.=20 Your suggestion looks cleaner.=20 Also, the use of 16-bit instead of 8-bit length field can eliminate the 255-byte length limit of RADIUS attributes to be included. I will make it a single-level option according your suggestion in the = next revision. About the naming of the option, how about "OPTION-RELAYED-RADIUS-ATTRIBUTES" instead of "OPTION-RADIUS-ATTRIBUTES" ? This is to highlight the nature = of this option, i.e. being inserted by the Relay Agent. Thanks again. Regards, Wing -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Wing Cheong Lau Sent: Friday, October 22, 2004 12:45 PM To: dhcwg@ietf.org Subject: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option Dear all, We have submitted a new draft on DHCPv6 Relay Information Option and = RADIUS Attributes sub-option last week. It's already available from the ietf = site=20 http://www.ietf.org/internet-drafts/draft-droms-dhc-v6-relayopt-00.txt but I have not seen the official announcement so far. The draft basically carries over similar capabilities, namely,=20 RFC 3046 and draft-ietf-dhc-agentopt-radius-08.txt from DHCPv4 to DHCPv6, with initial use cases targetting for=20 the 3GPP2 environment. Comments are welcome. Regards, Wing Abstract=20 =20 This document introduces the capabilities of the DHCPv4 Relay Agent=20 Information Option in RFC 3046 and the corresponding RADIUS- Attributes Sub-option to DHCPv6. In particular, the document=20 describes a new DHCPv6 option called the Relay Agent Information=20 option which extends the set of DHCPv6 options as defined in RFC 3315 = and 3376. Following its DHCPv4 counterpart as defined in RFC 3046,=20 the new option is inserted by the DHCPv6 relay agent when forwarding=20 client-originated DHCPv6 packets to a DHCPv6 server. Servers=20 recognizing the Relay Agent Information option may use the=20 information to implement IP address or other parameter assignment=20 policies. The DHCP Server echoes the option back verbatim to the=20 relay agent in server-to-client replies, and the relay agent strips=20 the option before forwarding the reply to the client. The Relay Agent = Information option is organized as a single DHCPv6 option that=20 contains one or more "sub-options" that convey information known by=20 the relay agent. A RADIUS Attributes Sub-option, following its=20 DHCPv4 counterpart, is also defined. =20 >Ted: > >Not sure what you're referring to. > >A relay would normally take a client message and place it into a = Relay-Forw >with a Relay Message option containing the client's message. It can = also add >any other options that it wants (and are allowed). In the base spec, = this >might include an Interface-ID option, for example. And, why I suggested = was >that this new I-D just define a "Radius Attribute" option which the = Relay >Agent would add into the Relay-Forw message. >- Bernie > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com]=20 > Sent: Friday, October 22, 2004 8:18 PM > To: Bernie Volz > Cc: dhcwg@ietf.org; 'Ralph Droms'; 'Wing Cheong Lau' > Subject: Re: [dhcwg] New draft on DHCPv6 Relay Information=20 > Option and RADIUS Attributes sub-option >=20 >=20 > Er, furthermore there's already a relay encapsulation method=20 > defined in=20 > the base DHCPv6 specification. >=20 ------=_NextPart_000_0036_01C4BA94.230E6A90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Great,=20 I have no objection to your suggested name other than it is rather = long -=20 perhaps it will become known as OPTION_RRA.
 
Are=20 you or Ralph going to discuss this at the upcoming DHC WG session and = request it=20 become a WG work item?
 
 
BTW,=20 we don't need a DHCPv6 version=20 of draft-ietf-dhc-vendor-suboption-00.txt because the existing DHCPv6 Vendor options can be used by the = Relay Agent=20 just fine. Again, it is WHERE these options appear that indicates = whether they=20 are for the client (in the client part of the message) or the relay, in = the=20 Relay-Forw or Relay-Reply part of the message. That work is already done = and is=20 not needed!!
 
-=20 Bernie
 
-----Original Message-----
From: Wing = Cheong Lau=20 [mailto:lau@qualcomm.com]
Sent: Monday, October 25, 2004 = 12:50=20 PM
To: dhcwg@ietf.org
Cc: Ted.Lemon@nominum.com;=20 rdroms@cisco.com; volz@cisco.com
Subject: Fwd: RE: [dhcwg] = New draft=20 on DHCPv6 Relay Information Option and RADIUS Attributes=20 sub-option

Dear Bernie and Ted,

Thanks for = your=20 suggestion. My response is interlaced below.

X-BrightmailFiltered: = true
From: "Bernie Volz" <volz@cisco.com>
To: "'Wing = Cheong=20 Lau'" <lau@qualcomm.com>, <dhcwg@ietf.org>
Cc: = "'Ralph=20 Droms'" <rdroms@cisco.com>
Subject: RE: [dhcwg] New draft = on DHCPv6=20 Relay Information Option and RADIUS Attributes sub-option
Date: = Fri, 22=20 Oct 2004 17:41:17 -0400
Organization: Cisco
X-Mailer: = Microsoft=20 Outlook, Build 10.0.6626
Importance: Normal
X-PMX-Version:=20 4.6.0.99824, Antispam-Core: 4.6.0.97340, Antispam-Data:=20 2004.10.22.1
X-OriginalArrivalTime: 22 Oct 2004 21:42:20.0795 = (UTC)=20 FILETIME=3D[025954B0:01C4B880]

A=20 very basic question ... why have a Relay Agent Information option = and have=20 sub-options inside this? And, especially 8-bit=20 suboptions.
 
It=20 seems to me that with the larger 16-bit DHCPv6 option space, we'd = just=20 define an option to carry the "Radius Attributes" instead of placing = this=20 under a general "Relay Agent" option. The context of the message is = pretty=20 clear -- if it is from the relay, it can only be in a Relay-Forw = (and=20 Relay-Reply) message option area.
 
There's also another advantage to this. = Take the DHCPv4=20 subnet-selection option - there are two forms of this, one in for = the relay=20 agent and another for the client. This won't be necessary in DHCPv6 = as the=20 LOCATION of the message (either in the Client's Solicit, Request, = ... or in=20 a Relay-Forw/Relay-Reply) tells us who added it and which we'd = prefer to=20 use. This means only ONE option number is = needed.
 
So, I'd much rather see this = specify a base=20 option, OPTION-RADIUS-ATTRIBUTES, and have this contain the Radius=20 attributes in the standard Radius encoding. So, it is just 16-bit = option=20 code, 16-bit length, followed by the radius encoding (as 8-bit=20 suboptions).

 
You can then specify that OPTION-RADIUS-ATTRIBUTES can only = appear in=20 the Relay-Forw (and Relay-Reply) message and MUST NOT appear in = client=20 messages themselves.
 
- Bernie

The original intent of specifying the sub-option = was to try=20 to simplify the definition of other sub-options in the future, =
e.g. the=20 DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt and = to
save a byte=20 of so if the relay needs to include multiple sub-options at the same=20 time. 
On 2nd thought, this "uncommon case"  may not = worth the=20 complexity.

Your suggestion looks cleaner.
Also, the use = of 16-bit=20 instead of 8-bit length field can  eliminate the
255-byte = length limit=20 of RADIUS attributes to be included.
I will make it a single-level = option=20 according your suggestion in the next revision.


About the = naming of=20 the option, how about  = "OPTION-RELAYED-RADIUS-ATTRIBUTES"
instead of=20 "OPTION-RADIUS-ATTRIBUTES" ? This  is to highlight the nature of = this=20 option,
i.e.  being inserted by the Relay = Agent.


Thanks=20 again.

Regards,

Wing



-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Wing=20 Cheong Lau
Sent: Friday, October 22, 2004 12:45 PM
To: dhcwg@ietf.org
Subject: [dhcwg] New draft on DHCPv6 Relay Information = Option and=20 RADIUS Attributes sub-option
Dear all,

We have submitted a new draft on DHCPv6 Relay Information = Option and=20 RADIUS Attributes sub-option last week. It's already available = from the=20 ietf site

http://www.ietf.org/internet-drafts/draft-droms-dhc-v6= -relayopt-00.txt

but I have not seen the official announcement so far.

The draft basically carries over similar capabilities, namely, =
RFC 3046 and draft-ietf-dhc-agentopt-radius-08.txt
from DHCPv4 to DHCPv6, with initial use cases targetting for =
the 3GPP2 environment.

Comments are welcome.

Regards,

Wing

Abstract
   
   This document introduces the capabilities of the = DHCPv4=20 Relay Agent
   Information Option in RFC 3046 and the = corresponding=20 RADIUS-
   Attributes Sub-option to DHCPv6. In particular, = the=20 document
   describes a new DHCPv6 option called the Relay = Agent=20 Information
   option which extends the set of DHCPv6 options as = defined=20 in RFC 3315
   and 3376. Following its DHCPv4 counterpart as = defined in=20 RFC 3046,
   the new option is inserted by the DHCPv6 relay = agent when=20 forwarding
   client-originated DHCPv6 packets to a DHCPv6 = server.=20 Servers
   recognizing the Relay Agent Information option = may use=20 the
   information to implement IP address or other = parameter=20 assignment
   policies.  The DHCP Server echoes the option = back=20 verbatim to the
   relay agent in server-to-client replies, and the = relay=20 agent strips
   the option before forwarding the reply to the = client. The=20 Relay Agent
   Information option is organized as a single = DHCPv6 option=20 that
   contains one or more "sub-options" that convey=20 information known by
   the relay agent.  A RADIUS Attributes = Sub-option,=20 following its
   DHCPv4 counterpart, is also defined. =20

>Ted:
>
>Not sure what you're referring=20 to.
>
>A relay would normally take a client message and = place it=20 into a Relay-Forw
>with a Relay Message option containing the = client's=20 message. It can also add
>any other options that it wants (and = are=20 allowed). In the base spec, this
>might include an Interface-ID = option,=20 for example. And, why I suggested was
>that this new I-D just = define a=20 "Radius Attribute" option which the Relay
>Agent would add into = the=20 Relay-Forw message.

>- Bernie

> -----Original=20 Message-----
> From: Ted Lemon [mailto:mellon@nominum.com]
> Sent: = Friday, October=20 22, 2004 8:18 PM
> To: Bernie Volz
> Cc: dhcwg@ietf.org; = 'Ralph=20 Droms'; 'Wing Cheong Lau'
> Subject: Re: [dhcwg] New draft on = DHCPv6=20 Relay Information
> Option and RADIUS Attributes = sub-option
>=20
>
> Er, furthermore there's already a relay = encapsulation method=20
> defined in
> the base DHCPv6 specification.
>=20
------=_NextPart_000_0036_01C4BA94.230E6A90-- --===============1866488297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1866488297==-- From dhcwg-bounces@ietf.org Mon Oct 25 13:43:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17498; Mon, 25 Oct 2004 13:43:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8oP-0001km-2B; Mon, 25 Oct 2004 13:39:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8kL-0001Sg-3x for dhcwg@megatron.ietf.org; Mon, 25 Oct 2004 13:35:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17001 for ; Mon, 25 Oct 2004 13:35:01 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8xp-0003kH-AL for dhcwg@ietf.org; Mon, 25 Oct 2004 13:49:02 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9PHYURQ006237; Mon, 25 Oct 2004 10:34:31 -0700 (PDT) Received: from WLAU.qualcomm.com (wlau.qualcomm.com [129.46.74.167]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9PHYR9A008113; Mon, 25 Oct 2004 10:34:28 -0700 (PDT) Message-Id: <6.0.0.22.2.20041025103245.040dbd80@qcmail1.qualcomm.com> X-Sender: wlau@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 25 Oct 2004 10:34:27 -0700 To: "Bernie Volz" , "'Wing Cheong Lau'" , From: Wing Cheong Lau Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option In-Reply-To: <003501c4bab5$aa200a90$6501a8c0@amer.cisco.com> References: <6.0.0.22.2.20041025092643.040c8e10@qcmail1.qualcomm.com> <003501c4bab5$aa200a90$6501a8c0@amer.cisco.com> Mime-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 Cc: Ted.Lemon@nominum.com, rdroms@cisco.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0842428322==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0842428322== Content-Type: multipart/alternative; boundary="=====================_130089178==.ALT" --=====================_130089178==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:11 AM 10/25/2004, Bernie Volz wrote: >Great, I have no objection to your suggested name other than it is rather >long - perhaps it will become known as OPTION_RRA. > >Are you or Ralph going to discuss this at the upcoming DHC WG session and >request it become a WG work item? Yes, I have just requested for a 10-min slot and the objective is to request it to become a WG work-item. Regards, Wing > > >BTW, we don't need a DHCPv6 version of >draft-ietf-dhc-vendor-suboption-00.txt because the existing DHCPv6 Vendor >options can be used by the Relay Agent just fine. Again, it is WHERE these >options appear that indicates whether they are for the client (in the >client part of the message) or the relay, in the Relay-Forw or Relay-Reply >part of the message. That work is already done and is not needed!! > >- Bernie > >-----Original Message----- >From: Wing Cheong Lau [mailto:lau@qualcomm.com] >Sent: Monday, October 25, 2004 12:50 PM >To: dhcwg@ietf.org >Cc: Ted.Lemon@nominum.com; rdroms@cisco.com; volz@cisco.com >Subject: Fwd: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and >RADIUS Attributes sub-option > >Dear Bernie and Ted, > >Thanks for your suggestion. My response is interlaced below. > >>X-BrightmailFiltered: true >>From: "Bernie Volz" >>To: "'Wing Cheong Lau'" , >>Cc: "'Ralph Droms'" >>Subject: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and >>RADIUS Attributes sub-option >>Date: Fri, 22 Oct 2004 17:41:17 -0400 >>Organization: Cisco >>X-Mailer: Microsoft Outlook, Build 10.0.6626 >>Importance: Normal >>X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.97340, Antispam-Data: >>2004.10.22.1 >>X-OriginalArrivalTime: 22 Oct 2004 21:42:20.0795 (UTC) >>FILETIME=[025954B0:01C4B880] >> >>A very basic question ... why have a Relay Agent Information option and >>have sub-options inside this? And, especially 8-bit suboptions. >> >>It seems to me that with the larger 16-bit DHCPv6 option space, we'd just >>define an option to carry the "Radius Attributes" instead of placing this >>under a general "Relay Agent" option. The context of the message is >>pretty clear -- if it is from the relay, it can only be in a Relay-Forw >>(and Relay-Reply) message option area. >> >>There's also another advantage to this. Take the DHCPv4 subnet-selection >>option - there are two forms of this, one in for the relay agent and >>another for the client. This won't be necessary in DHCPv6 as the LOCATION >>of the message (either in the Client's Solicit, Request, ... or in a >>Relay-Forw/Relay-Reply) tells us who added it and which we'd prefer to >>use. This means only ONE option number is needed. >> >>So, I'd much rather see this specify a base option, >>OPTION-RADIUS-ATTRIBUTES, and have this contain the Radius attributes in >>the standard Radius encoding. So, it is just 16-bit option code, 16-bit >>length, followed by the radius encoding (as 8-bit suboptions). >> >> >>You can then specify that OPTION-RADIUS-ATTRIBUTES can only appear in the >>Relay-Forw (and Relay-Reply) message and MUST NOT appear in client >>messages themselves. >> >>- Bernie > >The original intent of specifying the sub-option was to try to simplify >the definition of other sub-options in the future, >e.g. the DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt and to >save a byte of so if the relay needs to include multiple sub-options at >the same time. >On 2nd thought, this "uncommon case" may not worth the complexity. > >Your suggestion looks cleaner. >Also, the use of 16-bit instead of 8-bit length field can eliminate the >255-byte length limit of RADIUS attributes to be included. >I will make it a single-level option according your suggestion in the next >revision. > > >About the naming of the option, how about "OPTION-RELAYED-RADIUS-ATTRIBUTES" >instead of "OPTION-RADIUS-ATTRIBUTES" ? This is to highlight the nature >of this option, >i.e. being inserted by the Relay Agent. > > >Thanks again. > >Regards, > >Wing > > > >>-----Original Message----- >>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of >>Wing Cheong Lau >>Sent: Friday, October 22, 2004 12:45 PM >>To: dhcwg@ietf.org >>Subject: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS >>Attributes sub-option >> >>Dear all, >>We have submitted a new draft on DHCPv6 Relay Information Option and >>RADIUS Attributes sub-option last week. It's already available from the >>ietf site >> >>http://www.ietf.org/internet-drafts/draft-droms-dhc-v6-relayopt-00.txt >>but I have not seen the official announcement so far. >>The draft basically carries over similar capabilities, namely, >>RFC 3046 and draft-ietf-dhc-agentopt-radius-08.txt >>from DHCPv4 to DHCPv6, with initial use cases targetting for >>the 3GPP2 environment. >>Comments are welcome. >>Regards, >>Wing >> >>Abstract >> >> This document introduces the capabilities of the DHCPv4 Relay Agent >> Information Option in RFC 3046 and the corresponding RADIUS- >> Attributes Sub-option to DHCPv6. In particular, the document >> describes a new DHCPv6 option called the Relay Agent Information >> option which extends the set of DHCPv6 options as defined in RFC 3315 >> and 3376. Following its DHCPv4 counterpart as defined in RFC 3046, >> the new option is inserted by the DHCPv6 relay agent when forwarding >> client-originated DHCPv6 packets to a DHCPv6 server. Servers >> recognizing the Relay Agent Information option may use the >> information to implement IP address or other parameter assignment >> policies. The DHCP Server echoes the option back verbatim to the >> relay agent in server-to-client replies, and the relay agent strips >> the option before forwarding the reply to the client. The Relay Agent >> Information option is organized as a single DHCPv6 option that >> contains one or more "sub-options" that convey information known by >> the relay agent. A RADIUS Attributes Sub-option, following its >> DHCPv4 counterpart, is also defined. > > >Ted: > > > >Not sure what you're referring to. > > > >A relay would normally take a client message and place it into a Relay-Forw > >with a Relay Message option containing the client's message. It can also add > >any other options that it wants (and are allowed). In the base spec, this > >might include an Interface-ID option, for example. And, why I suggested was > >that this new I-D just define a "Radius Attribute" option which the Relay > >Agent would add into the Relay-Forw message. > > >- Bernie > > > -----Original Message----- > > From: Ted Lemon [mailto:mellon@nominum.com] > > Sent: Friday, October 22, 2004 8:18 PM > > To: Bernie Volz > > Cc: dhcwg@ietf.org; 'Ralph Droms'; 'Wing Cheong Lau' > > Subject: Re: [dhcwg] New draft on DHCPv6 Relay Information > > Option and RADIUS Attributes sub-option > > > > > > Er, furthermore there's already a relay encapsulation method > > defined in > > the base DHCPv6 specification. > > --=====================_130089178==.ALT Content-Type: text/html; charset="us-ascii" At 10:11 AM 10/25/2004, Bernie Volz wrote:
Great, I have no objection to your suggested name other than it is rather long - perhaps it will become known as OPTION_RRA.
 
Are you or Ralph going to discuss this at the upcoming DHC WG session and request it become a WG work item?

Yes, I have just requested for a 10-min slot and the objective is to request it to become a WG work-item.

Regards,

Wing


 
 
BTW, we don't need a DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt because the existing DHCPv6 Vendor options can be used by the Relay Agent just fine. Again, it is WHERE these options appear that indicates whether they are for the client (in the client part of the message) or the relay, in the Relay-Forw or Relay-Reply part of the message. That work is already done and is not needed!!
 
- Bernie
 
-----Original Message-----
From: Wing Cheong Lau [mailto:lau@qualcomm.com]
Sent: Monday, October 25, 2004 12:50 PM
To: dhcwg@ietf.org
Cc: Ted.Lemon@nominum.com; rdroms@cisco.com; volz@cisco.com
Subject: Fwd: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option
Dear Bernie and Ted,

Thanks for your suggestion. My response is interlaced below.

X-BrightmailFiltered: true
From: "Bernie Volz" <volz@cisco.com>
To: "'Wing Cheong Lau'" <lau@qualcomm.com>, <dhcwg@ietf.org>
Cc: "'Ralph Droms'" <rdroms@cisco.com>
Subject: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option
Date: Fri, 22 Oct 2004 17:41:17 -0400
Organization: Cisco
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.10.22.1
X-OriginalArrivalTime: 22 Oct 2004 21:42:20.0795 (UTC) FILETIME=[025954B0:01C4B880]

A very basic question ... why have a Relay Agent Information option and have sub-options inside this? And, especially 8-bit suboptions.
 
It seems to me that with the larger 16-bit DHCPv6 option space, we'd just define an option to carry the "Radius Attributes" instead of placing this under a general "Relay Agent" option. The context of the message is pretty clear -- if it is from the relay, it can only be in a Relay-Forw (and Relay-Reply) message option area.
 
There's also another advantage to this. Take the DHCPv4 subnet-selection option - there are two forms of this, one in for the relay agent and another for the client. This won't be necessary in DHCPv6 as the LOCATION of the message (either in the Client's Solicit, Request, ... or in a Relay-Forw/Relay-Reply) tells us who added it and which we'd prefer to use. This means only ONE option number is needed.
 
So, I'd much rather see this specify a base option, OPTION-RADIUS-ATTRIBUTES, and have this contain the Radius attributes in the standard Radius encoding. So, it is just 16-bit option code, 16-bit length, followed by the radius encoding (as 8-bit suboptions).

 
You can then specify that OPTION-RADIUS-ATTRIBUTES can only appear in the Relay-Forw (and Relay-Reply) message and MUST NOT appear in client messages themselves.
 
- Bernie

The original intent of specifying the sub-option was to try to simplify the definition of other sub-options in the future,
e.g. the DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt and to
save a byte of so if the relay needs to include multiple sub-options at the same time. 
On 2nd thought, this "uncommon case"  may not worth the complexity.

Your suggestion looks cleaner.
Also, the use of 16-bit instead of 8-bit length field can  eliminate the
255-byte length limit of RADIUS attributes to be included.
I will make it a single-level option according your suggestion in the next revision.


About the naming of the option, how about  "OPTION-RELAYED-RADIUS-ATTRIBUTES"
instead of "OPTION-RADIUS-ATTRIBUTES" ? This  is to highlight the nature of this option,
i.e.  being inserted by the Relay Agent.


Thanks again.

Regards,

Wing



-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Wing Cheong Lau
Sent: Friday, October 22, 2004 12:45 PM
To: dhcwg@ietf.org
Subject: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option
Dear all,
We have submitted a new draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option last week. It's already available from the ietf site

http://www.ietf.org/internet-drafts/draft-droms-dhc-v6-relayopt-00.txt
but I have not seen the official announcement so far.
The draft basically carries over similar capabilities, namely,
RFC 3046 and draft-ietf-dhc-agentopt-radius-08.txt
from DHCPv4 to DHCPv6, with initial use cases targetting for
the 3GPP2 environment.
Comments are welcome.
Regards,
Wing

Abstract
   
   This document introduces the capabilities of the DHCPv4 Relay Agent
   Information Option in RFC 3046 and the corresponding RADIUS-
   Attributes Sub-option to DHCPv6. In particular, the document
   describes a new DHCPv6 option called the Relay Agent Information
   option which extends the set of DHCPv6 options as defined in RFC 3315
   and 3376. Following its DHCPv4 counterpart as defined in RFC 3046,
   the new option is inserted by the DHCPv6 relay agent when forwarding
   client-originated DHCPv6 packets to a DHCPv6 server. Servers
   recognizing the Relay Agent Information option may use the
   information to implement IP address or other parameter assignment
   policies.  The DHCP Server echoes the option back verbatim to the
   relay agent in server-to-client replies, and the relay agent strips
   the option before forwarding the reply to the client. The Relay Agent
   Information option is organized as a single DHCPv6 option that
   contains one or more "sub-options" that convey information known by
   the relay agent.  A RADIUS Attributes Sub-option, following its
   DHCPv4 counterpart, is also defined. 

>Ted:
>
>Not sure what you're referring to.
>
>A relay would normally take a client message and place it into a Relay-Forw
>with a Relay Message option containing the client's message. It can also add
>any other options that it wants (and are allowed). In the base spec, this
>might include an Interface-ID option, for example. And, why I suggested was
>that this new I-D just define a "Radius Attribute" option which the Relay
>Agent would add into the Relay-Forw message.

>- Bernie

> -----Original Message-----
> From: Ted Lemon [mailto:mellon@nominum.com]
> Sent: Friday, October 22, 2004 8:18 PM
> To: Bernie Volz
> Cc: dhcwg@ietf.org; 'Ralph Droms'; 'Wing Cheong Lau'
> Subject: Re: [dhcwg] New draft on DHCPv6 Relay Information
> Option and RADIUS Attributes sub-option
>
>
> Er, furthermore there's already a relay encapsulation method
> defined in
> the base DHCPv6 specification.
>
--=====================_130089178==.ALT-- --===============0842428322== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0842428322==-- From dhcwg-bounces@ietf.org Mon Oct 25 15:05:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24082; Mon, 25 Oct 2004 15:05:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMA85-0003G4-1O; Mon, 25 Oct 2004 15:03:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMA5P-00014T-Iu for dhcwg@megatron.ietf.org; Mon, 25 Oct 2004 15:00:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23743 for ; Mon, 25 Oct 2004 15:00:53 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMAIt-0005FD-PL for dhcwg@ietf.org; Mon, 25 Oct 2004 15:14:53 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9PIxEjH007569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Oct 2004 11:59:15 -0700 (PDT) Received: from WLAU.qualcomm.com (wlau.qualcomm.com [129.46.74.167]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9PIxBba025838; Mon, 25 Oct 2004 11:59:12 -0700 (PDT) Message-Id: <6.0.0.22.2.20041025113534.040e29e0@qcmail1.qualcomm.com> X-Sender: wlau@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 25 Oct 2004 11:59:12 -0700 To: "Bernie Volz" , "'Wing Cheong Lau'" , From: Wing Cheong Lau Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option In-Reply-To: <003501c4bab5$aa200a90$6501a8c0@amer.cisco.com> References: <6.0.0.22.2.20041025092643.040c8e10@qcmail1.qualcomm.com> <003501c4bab5$aa200a90$6501a8c0@amer.cisco.com> Mime-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Ted.Lemon@nominum.com, rdroms@cisco.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1245802174==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1245802174== Content-Type: multipart/alternative; boundary="=====================_135173158==.ALT" --=====================_135173158==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:11 AM 10/25/2004, Bernie Volz wrote: > >BTW, we don't need a DHCPv6 version of >draft-ietf-dhc-vendor-suboption-00.txt because the existing DHCPv6 Vendor >options can be used by the Relay Agent just fine. Again, it is WHERE these >options appear that indicates whether they are for the client (in the >client part of the message) or the relay, in the Relay-Forw or Relay-Reply >part of the message. That work is already done and is not needed!! > >- Bernie I see. However, the use of such vendor-options by the Relay Agent is kind of hidden/missing from the current text of RFC 3315. For example, Sections 22.16 and 22.17 of RFC 3315 only describe the use of such vendor options by the client and the server. The use of these options by the relay agent are not mentioned at all. While it is true that the table in Appendix A of RFC3315 does say the possible inclusion of the vendor options in the Relay-Forward/Relay-Reply message, the table in Appendix B seems to imply otherwise: In the table in Appendix B, while there are "*"'s for the Relay-Message and Interface ID rows under the Relay Forw./Relay Replay columns, no "*"'s are found for the Vendor Class/Vendor Info rows for the Relay Forw./Relay Replay columns. I think if Relay agent is allowed to include those vendor options in the Relay Forw/Replay messages, just like it includes the Interface option, the rows for the Vendor options should look like the row of the Interface option. Am I missing something ? or did I misunderstand the entire meaning of the table in Appendix B ? Actually, what does the "Option Field" column in the table mean ? Also what's the "Note" below the table refers to ? Would you share more clarification/ insights on this ? Thanks a lot in advance. Regards, Wing --=====================_135173158==.ALT Content-Type: text/html; charset="us-ascii" At 10:11 AM 10/25/2004, Bernie Volz wrote:

 
BTW, we don't need a DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt because the existing DHCPv6 Vendor options can be used by the Relay Agent just fine. Again, it is WHERE these options appear that indicates whether they are for the client (in the client part of the message) or the relay, in the Relay-Forw or Relay-Reply part of the message. That work is already done and is not needed!!
 
- Bernie


I see. However,  the use of such vendor-options by the Relay Agent is kind of hidden/missing from the current text of RFC 3315.
For example, Sections  22.16 and 22.17 of RFC 3315 only describe the use of such vendor options by the client and the server. The use of these options by the relay agent are not mentioned at all.

While it is true that the table in Appendix A of RFC3315
does say the possible inclusion of the vendor options in the Relay-Forward/Relay-Reply message, 
the table in Appendix B seems to imply otherwise:

In the table in Appendix B,  while there are  "*"'s  for the  Relay-Message and Interface ID rows under
the Relay Forw./Relay Replay columns,  no "*"'s are found  for the Vendor Class/Vendor Info rows for
the Relay Forw./Relay Replay columns. I think if Relay agent is allowed to include those vendor options in the
Relay Forw/Replay messages, just like it includes the Interface option, 
the rows for the  Vendor options should look like the row of  the Interface option.

Am I missing something ? or did I misunderstand the entire meaning of the table in Appendix B ?
Actually, what does the "Option Field" column in the table mean ?

Also what's the "Note" below the table refers to ?

Would you share more clarification/ insights on this ?

Thanks a lot in advance.

Regards,

Wing

--=====================_135173158==.ALT-- --===============1245802174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1245802174==-- From dhcwg-bounces@ietf.org Mon Oct 25 19:34:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16316; Mon, 25 Oct 2004 19:34:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBZD-0003fq-QX; Mon, 25 Oct 2004 16:35:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBHr-0005cy-El for dhcwg@megatron.ietf.org; Mon, 25 Oct 2004 16:17:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02613 for ; Mon, 25 Oct 2004 16:17:48 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBVN-0007Fi-6e for dhcwg@ietf.org; Mon, 25 Oct 2004 16:31:49 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 25 Oct 2004 16:37:01 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9PKDtWT012255; Mon, 25 Oct 2004 16:13:56 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-2-248.cisco.com [10.86.242.248]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMN78019; Mon, 25 Oct 2004 16:13:53 -0400 (EDT) From: "Bernie Volz" To: "'Wing Cheong Lau'" , Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option Date: Mon, 25 Oct 2004 16:13:52 -0400 Organization: Cisco Message-ID: <005b01c4bacf$266a6500$6501a8c0@amer.cisco.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <6.0.0.22.2.20041025113534.040e29e0@qcmail1.qualcomm.com> Importance: Normal X-Spam-Score: 0.6 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: Ted.Lemon@nominum.com, rdroms@cisco.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1356082034==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1356082034== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01C4BAAD.9F58C500" This is a multi-part message in MIME format. ------=_NextPart_000_005C_01C4BAAD.9F58C500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a RFC 3315-bis, we'll need to correct this. Appendix B is in error = and should allow these options in the Relay-Forw/Relay-Reply. And, the description of the options should mention that these can also be used by = the relay agent <-> server communication. =20 But the intent was always there, as shown in Appendix A, to use these options for the relay agent as well. I think Appendix A is correct and complete (in terms of the options in the base specification.) =20 - Bernie =20 -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Wing Cheong Lau Sent: Monday, October 25, 2004 2:59 PM To: Bernie Volz; 'Wing Cheong Lau'; dhcwg@ietf.org Cc: Ted.Lemon@nominum.com; rdroms@cisco.com Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option = and RADIUS Attributes sub-option At 10:11 AM 10/25/2004, Bernie Volz wrote: BTW, we don't need a DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt because the existing DHCPv6 = Vendor options can be used by the Relay Agent just fine. Again, it is WHERE = these options appear that indicates whether they are for the client (in the = client part of the message) or the relay, in the Relay-Forw or Relay-Reply part = of the message. That work is already done and is not needed!! =20 - Bernie I see. However, the use of such vendor-options by the Relay Agent is = kind of hidden/missing from the current text of RFC 3315. For example, Sections 22.16 and 22.17 of RFC 3315 only describe the use = of such vendor options by the client and the server. The use of these = options by the relay agent are not mentioned at all.=20 While it is true that the table in Appendix A of RFC3315 does say the possible inclusion of the vendor options in the Relay-Forward/Relay-Reply message, =20 the table in Appendix B seems to imply otherwise:=20 In the table in Appendix B, while there are "*"'s for the = Relay-Message and Interface ID rows under the Relay Forw./Relay Replay columns, no "*"'s are found for the = Vendor Class/Vendor Info rows for the Relay Forw./Relay Replay columns. I think if Relay agent is allowed = to include those vendor options in the Relay Forw/Replay messages, just like it includes the Interface option, = the rows for the Vendor options should look like the row of the = Interface option. Am I missing something ? or did I misunderstand the entire meaning of = the table in Appendix B ? Actually, what does the "Option Field" column in the table mean ? Also what's the "Note" below the table refers to ? Would you share more clarification/ insights on this ? Thanks a lot in advance. Regards, Wing=20 ------=_NextPart_000_005C_01C4BAAD.9F58C500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
In a=20 RFC 3315-bis, we'll need to correct this. Appendix B is in error and = should=20 allow these options in the Relay-Forw/Relay-Reply. And, the description = of the=20 options should mention that these can also be used by the = relay agent=20 <-> server communication.
 
But=20 the intent was always there, as shown in Appendix A, to use these = options for=20 the relay agent as well. I think Appendix A is correct and complete (in = terms of=20 the options in the base specification.)
 
-=20 Bernie
 
-----Original Message-----
From:=20 dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Wing Cheong Lau
Sent: Monday, October 25, 2004 2:59=20 PM
To: Bernie Volz; 'Wing Cheong Lau'; = dhcwg@ietf.org
Cc:=20 Ted.Lemon@nominum.com; rdroms@cisco.com
Subject: RE: RE: = [dhcwg] New=20 draft on DHCPv6 Relay Information Option and RADIUS Attributes=20 sub-option

At 10:11 AM 10/25/2004, Bernie Volz=20 wrote:


BTW, we don't need a DHCPv6 version of=20 draft-ietf-dhc-vendor-suboption-00.txt because the existing DHCPv6 Vendor options can be used by = the Relay=20 Agent just fine. Again, it is WHERE these options appear that = indicates=20 whether they are for the client (in the client part of the message) = or the=20 relay, in the Relay-Forw or Relay-Reply part of the message. That = work is=20 already done and is not needed!!
 
- Bernie


I = see.=20 However,  the use of such vendor-options by the Relay Agent is = kind of=20 hidden/missing from the current text of RFC 3315.
For example,=20 Sections  22.16 and 22.17 of RFC 3315 only describe the use of = such=20 vendor options by the client and the server. The use of these options = by the=20 relay agent are not mentioned at all.

While it is true that = the table=20 in Appendix A of RFC3315
does say the possible inclusion of the = vendor=20 options in the Relay-Forward/Relay-Reply message, 
the table = in=20 Appendix B seems to imply otherwise:

In the table in Appendix = B, =20 while there are  "*"'s  for the  Relay-Message and = Interface ID=20 rows under
the Relay Forw./Relay Replay columns,  no "*"'s are = found  for the Vendor Class/Vendor Info rows for
the Relay = Forw./Relay=20 Replay columns. I think if Relay agent is allowed to include those = vendor=20 options in the
Relay Forw/Replay messages, just like it includes = the=20 Interface option, 
the rows for the  Vendor options = should look=20 like the row of  the Interface option.

Am I missing = something ? or=20 did I misunderstand the entire meaning of the table in Appendix B=20 ?
Actually, what does the "Option Field" column in the table mean=20 ?

Also what's the "Note" below the table refers to = ?

Would you=20 share more clarification/ insights on this ?

Thanks a lot in=20 advance.

Regards,

Wing =

------=_NextPart_000_005C_01C4BAAD.9F58C500-- --===============1356082034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1356082034==-- From dhcwg-bounces@ietf.org Tue Oct 26 11:19:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13384; Tue, 26 Oct 2004 11:19:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMT4n-0007lv-BF; Tue, 26 Oct 2004 11:17:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSwd-0006BQ-1I for dhcwg@megatron.ietf.org; Tue, 26 Oct 2004 11:09:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12434 for ; Tue, 26 Oct 2004 11:09:04 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMTAJ-0004v1-5I for dhcwg@ietf.org; Tue, 26 Oct 2004 11:23:15 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9QF8WF15592; Tue, 26 Oct 2004 11:08:32 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Oct 2004 11:08:32 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92037E278A@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Bernie Volz , "'Wing Cheong Lau'" , dhcwg@ietf.org Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option andR ADIUS Attributes sub-option Date: Tue, 26 Oct 2004 11:08:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Ted.Lemon@nominum.com, rdroms@cisco.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I have not followed this discussion yet, but I would like to notify the WG about the following draft we submitted: http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-mip6-agentop-00.txt The idea is to allow the relay agent to convey some received information from RADIUS or DIAMETER server to the MN for MIP6 bootstrapping when the relay agent is also a NAS. " Abstract This document defines a new DHCPv6 option and number of sub-options for DHCP Relay Agent to facilitate Mobile IPv6 bootstrapping along with a AAA infrastructure. " Comments are welcome. Regards, Kuntal -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz Sent: Monday, October 25, 2004 3:14 PM To: 'Wing Cheong Lau'; dhcwg@ietf.org Cc: Ted.Lemon@nominum.com; rdroms@cisco.com Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option andRADIUS Attributes sub-option In a RFC 3315-bis, we'll need to correct this. Appendix B is in error and should allow these options in the Relay-Forw/Relay-Reply. And, the description of the options should mention that these can also be used by the relay agent <-> server communication. But the intent was always there, as shown in Appendix A, to use these options for the relay agent as well. I think Appendix A is correct and complete (in terms of the options in the base specification.) - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Wing Cheong Lau Sent: Monday, October 25, 2004 2:59 PM To: Bernie Volz; 'Wing Cheong Lau'; dhcwg@ietf.org Cc: Ted.Lemon@nominum.com; rdroms@cisco.com Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option At 10:11 AM 10/25/2004, Bernie Volz wrote: BTW, we don't need a DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt because the existing DHCPv6 Vendor options can be used by the Relay Agent just fine. Again, it is WHERE these options appear that indicates whether they are for the client (in the client part of the message) or the relay, in the Relay-Forw or Relay-Reply part of the message. That work is already done and is not needed!! - Bernie I see. However, the use of such vendor-options by the Relay Agent is kind of hidden/missing from the current text of RFC 3315. For example, Sections 22.16 and 22.17 of RFC 3315 only describe the use of such vendor options by the client and the server. The use of these options by the relay agent are not mentioned at all. While it is true that the table in Appendix A of RFC3315 does say the possible inclusion of the vendor options in the Relay-Forward/Relay-Reply message, the table in Appendix B seems to imply otherwise: In the table in Appendix B, while there are "*"'s for the Relay-Message and Interface ID rows under the Relay Forw./Relay Replay columns, no "*"'s are found for the Vendor Class/Vendor Info rows for the Relay Forw./Relay Replay columns. I think if Relay agent is allowed to include those vendor options in the Relay Forw/Replay messages, just like it includes the Interface option, the rows for the Vendor options should look like the row of the Interface option. Am I missing something ? or did I misunderstand the entire meaning of the table in Appendix B ? Actually, what does the "Option Field" column in the table mean ? Also what's the "Note" below the table refers to ? Would you share more clarification/ insights on this ? Thanks a lot in advance. Regards, Wing _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Oct 26 16:39:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15696; Tue, 26 Oct 2004 16:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMXZn-0000vX-6Q; Tue, 26 Oct 2004 16:05:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMXTA-0005qx-BA; Tue, 26 Oct 2004 15:59:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09048; Tue, 26 Oct 2004 15:58:57 -0400 (EDT) Message-Id: <200410261958.PAA09048@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 15:58:57 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-sntp-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Simple Network Time Protocol Configuration Option for DHCPv6 Author(s) : A. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-sntp-01.txt Pages : 5 Date : 2004-10-26 This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-sntp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-sntp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-sntp-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: <2004-10-26160459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-sntp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-sntp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26160459.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Wed Oct 27 09:10:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02154; Wed, 27 Oct 2004 09:10:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnWq-0004XN-M6; Wed, 27 Oct 2004 09:07:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnVP-0004Cv-6K for dhcwg@megatron.ietf.org; Wed, 27 Oct 2004 09:06:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01912 for ; Wed, 27 Oct 2004 09:06:21 -0400 (EDT) Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMnjF-0004rt-Lk for dhcwg@ietf.org; Wed, 27 Oct 2004 09:20:43 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id i9RD5nun019467 for ; Wed, 27 Oct 2004 15:05:49 +0200 Received: from vies141a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i9RD5mmD008268 for ; Wed, 27 Oct 2004 15:05:48 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id <4L37SHP2>; Wed, 27 Oct 2004 15:08:21 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AC4C@viee10pa.erd.siemens.at> From: Grubmair Peter To: "Dhcwg (E-mail)" Date: Wed, 27 Oct 2004 15:03:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [dhcwg] retransmission timeout in stateless DHCPv6 and preference option ? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org If a statelesss dhcpv6 client receives a reply with preference option, it has to wait until retransmission timer expires to select reply highest preference. I wonder if client has to wait for timeout of retransmission timer if the first reply does not contain a preference option ? Or is the client allowed to use the info from the reply imediately ? best regards Peter _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Oct 27 15:38:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06475; Wed, 27 Oct 2004 15:38:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMtaA-0008OG-AR; Wed, 27 Oct 2004 15:35:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMtUE-0004PX-JM for dhcwg@megatron.ietf.org; Wed, 27 Oct 2004 15:29:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05579 for ; Wed, 27 Oct 2004 15:29:32 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMti9-00059K-K2 for dhcwg@ietf.org; Wed, 27 Oct 2004 15:43:58 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2004 12:38:09 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9RJSx6s013947 for ; Wed, 27 Oct 2004 12:28:59 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.190]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMP45981; Wed, 27 Oct 2004 15:28:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20041027152418.022abf00@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Oct 2004 15:28:56 -0400 To: From: Ralph Droms Subject: RE: [dhcwg] BCMCS server option drafts In-Reply-To: <002e01c4b7aa$3e045090$d0412ca1@amer.cisco.com> References: <4.3.2.7.2.20041021143445.02504d48@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org What about the deployment issue? The 3GGP2 specification will be ratified in November, with deployment following soon. Some service providers already have DHCP servers in place that must be updated for any new options. The options defined in the current drafts can likely be supported without code changes to existing servers, allowing for faster deployment. Use of a VIVSO sub-option would require code changes to existing servers. How long would it take to deploy DHCP server that can support VIVSO? BTW, we need more discussion of this issue *soon* due to the time constraints of the upcoming 3GPP2 standards process and deployment. - Ralph At 04:12 PM 10/21/2004 -0400, Bernie Volz wrote: >Personally, I'd like to see the DHCPv4 VIVSO get deployed and pushing these >options to using it would be a step at making this happen (as one would >expect 3GPP2 vendors to have some significant input to the decisions of DHCP >server vendors). > >It also means that 3GPP2 is free to define other VIVSO options in the future >within their own forum and need not go to the IETF (and DHC WG). I suspect >that this would provide much faster deployment for them in the future. > >Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS are already >there for DHCPv6. > >BTW, 3GPP2 already has an enterprise-id number: > >5535 > 3rd Generation Partnership Project 2 (3GPP2) > Allen Long > along@cisco.com > >So, they'd be good to go! > >- Bernie > > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > On Behalf Of Ralph Droms > > Sent: Thursday, October 21, 2004 2:35 PM > > To: dhcwg@ietf.org > > Subject: [dhcwg] BCMCS server option drafts > > > > > > We need to have a short WG conversation about two options > > that were discussed at the WG meeting in San Diego. The > > outcome of the conversation will be to determine consensus > > about taking on these two > > drafts: > > > > draft-chowdhury-dhc-bcmcv4-option-01.txt > > draft-chowdhury-dhc-bcmcv6-option-01.txt > > > > as dhc WG work items or recommending that 3GPP2 define > > vendor-identifying vendor-specific option (VIVSO; option code > > 125) sub-options to carry the information described in the drafts. > > > > If the WG consensus is to take on the drafts as WG work items > > drafts, are they acceptable as currently published? > > > > Because of the time constraints imposed by the 3GPP2 > > schedule, I'm going to cut off discussion on this topic next > > Thursday, 10/28, and determine WG consensus at that time. > > > > Here are some considerations for discussion: > > > > 3GPP2 has defined some vendor-specific sub-options, for > > example, to identify a MIP home agent for the DHCP client. > > > > A 3GPP2 client needs to specify to the DHCP server which > > parameters it needs - specifically, whether it needs to > > receive the BCMCS servers. If the current drafts are adopted, > > the client can simply use the parameter request list option > > (option code 55) for the request. If a VIVSO sub-option is > > used, 3GPP2 would also define a parameter request list sub-option. > > > > There is a deployment issue, as some service providers > > already have DHCP servers in place that must be updated for > > any new options. Is it the case that the options defined in > > the current drafts can be supported without code changes to > > existing servers? Use of a VIVSO sub-option would require > > code changes to existing servers. How long would it take to > > deploy DHCP server that can support VIVSO. > > > > BCMCS may be adopted across multiple technologies, so the > > options in the current drafts would not be specific to 3GPP2. > > However, the BCMCS specification has not adopted by other > > standards, yet, so we may need to define additional options > > for related services in the future if those services are not > > interoperable with the 3GPP2 BCMCS service. > > > > CableLabs has one option with sub-options (RFC 3495) rather > > than multiple options because: > > * wanted to avoid exhaustion of DHCP option code space; perhaps less > > of an issue with option code reclassification > > * would have used VIVSO if available > > * use of VIVSO with sub-options would give 3GPP2 freedom to define new > > sub-options on demand > > Do these considerations have an impact on our decision about > > how to proceed with the 3GPP2 options? > > > > - Ralph > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Oct 27 16:53:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12922; Wed, 27 Oct 2004 16:53:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuaT-0005vT-JF; Wed, 27 Oct 2004 16:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuUD-0003Sw-Ed for dhcwg@megatron.ietf.org; Wed, 27 Oct 2004 16:33:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10794 for ; Wed, 27 Oct 2004 16:33:35 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMui8-0006VI-4k for dhcwg@ietf.org; Wed, 27 Oct 2004 16:48:02 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9RKX0l29985; Wed, 27 Oct 2004 16:33:00 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Oct 2004 16:32:59 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE920382C07B@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Ralph Droms , volz@cisco.com Subject: RE: [dhcwg] BCMCS server option drafts Date: Wed, 27 Oct 2004 16:32:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I have a few questions on the possible use of DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS to request vendor specific info: 1. Since the enterprise number is included in OPTION_VENDOR_OPTS, will it suffice to use only this option in the information request message from the DHCP client? Is the use of OPTION_VENDOR_CLASS mandatory while vendor specific options are requested? 2. Does the mere inclusion of OPTION_VENDOR_OPTS in the information request message indicate to the DHCP server that the DHCP client is requesting for some specific vendor specific options? 3. O-R-O has the format where each of requested option codes are listed in it. However, in OPTION_VENDOR_OPTS the encapsulated vendor-specific options field MUST be encoded as a sequence of code/length/value fields. What value does the DHCP client use while requesting for a vendor specific option? These things are not clearly defined in RFC3315. Regards, Kuntal >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] >On Behalf Of Ralph Droms >Sent: Wednesday, October 27, 2004 2:29 PM >To: dhcwg@ietf.org >Subject: RE: [dhcwg] BCMCS server option drafts > > > >What about the deployment issue? The 3GGP2 specification will >be ratified in November, with deployment following soon. Some >service providers already have DHCP servers in place that must >be updated for any new options. The options defined in the >current drafts can likely be supported without code changes to >existing servers, allowing for faster deployment. Use of a >VIVSO sub-option would require code changes to existing >servers. How long would it take to deploy DHCP server that >can support VIVSO? > >BTW, we need more discussion of this issue *soon* due to the >time constraints of the upcoming 3GPP2 standards process and >deployment. > >- Ralph > >At 04:12 PM 10/21/2004 -0400, Bernie Volz wrote: >>Personally, I'd like to see the DHCPv4 VIVSO get deployed and pushing >>these options to using it would be a step at making this >happen (as one >>would expect 3GPP2 vendors to have some significant input to the >>decisions of DHCP server vendors). >> >>It also means that 3GPP2 is free to define other VIVSO options in the >>future within their own forum and need not go to the IETF >(and DHC WG). >>I suspect that this would provide much faster deployment for them in >>the future. >> >>Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS >are already >>there for DHCPv6. >> >>BTW, 3GPP2 already has an enterprise-id number: >> >>5535 >> 3rd Generation Partnership Project 2 (3GPP2) >> Allen Long >> along@cisco.com >> >>So, they'd be good to go! >> >>- Bernie >> >> > -----Original Message----- >> > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> > Behalf Of Ralph Droms >> > Sent: Thursday, October 21, 2004 2:35 PM >> > To: dhcwg@ietf.org >> > Subject: [dhcwg] BCMCS server option drafts >> > >> > >> > We need to have a short WG conversation about two options >that were >> > discussed at the WG meeting in San Diego. The outcome of the >> > conversation will be to determine consensus about taking on these >> > two >> > drafts: >> > >> > draft-chowdhury-dhc-bcmcv4-option-01.txt >> > draft-chowdhury-dhc-bcmcv6-option-01.txt >> > >> > as dhc WG work items or recommending that 3GPP2 define >> > vendor-identifying vendor-specific option (VIVSO; option code >> > 125) sub-options to carry the information described in the drafts. >> > >> > If the WG consensus is to take on the drafts as WG work items >> > drafts, are they acceptable as currently published? >> > >> > Because of the time constraints imposed by the 3GPP2 schedule, I'm >> > going to cut off discussion on this topic next Thursday, >10/28, and >> > determine WG consensus at that time. >> > >> > Here are some considerations for discussion: >> > >> > 3GPP2 has defined some vendor-specific sub-options, for >example, to >> > identify a MIP home agent for the DHCP client. >> > >> > A 3GPP2 client needs to specify to the DHCP server which >parameters >> > it needs - specifically, whether it needs to receive the BCMCS >> > servers. If the current drafts are adopted, the client can simply >> > use the parameter request list option (option code 55) for the >> > request. If a VIVSO sub-option is used, 3GPP2 would also define a >> > parameter request list sub-option. >> > >> > There is a deployment issue, as some service providers >already have >> > DHCP servers in place that must be updated for any new >options. Is >> > it the case that the options defined in the current drafts can be >> > supported without code changes to existing servers? Use >of a VIVSO >> > sub-option would require code changes to existing servers. > How long >> > would it take to deploy DHCP server that can support VIVSO. >> > >> > BCMCS may be adopted across multiple technologies, so the >options in >> > the current drafts would not be specific to 3GPP2. However, the >> > BCMCS specification has not adopted by other standards, yet, so we >> > may need to define additional options for related services in the >> > future if those services are not interoperable with the >3GPP2 BCMCS >> > service. >> > >> > CableLabs has one option with sub-options (RFC 3495) rather than >> > multiple options because: >> > * wanted to avoid exhaustion of DHCP option code space; >perhaps less >> > of an issue with option code reclassification >> > * would have used VIVSO if available >> > * use of VIVSO with sub-options would give 3GPP2 freedom >to define new >> > sub-options on demand >> > Do these considerations have an impact on our decision >about how to >> > proceed with the 3GPP2 options? >> > >> > - Ralph >> > >> > >> > _______________________________________________ >> > dhcwg mailing list >> > dhcwg@ietf.org >> > https://www1.ietf.org/mailman/listinfo/dhcwg >> > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Oct 27 21:39:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07040; Wed, 27 Oct 2004 21:39:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMzF0-0008QN-IX; Wed, 27 Oct 2004 21:38:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMzEF-0008Kh-A4 for dhcwg@megatron.ietf.org; Wed, 27 Oct 2004 21:37:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06959 for ; Wed, 27 Oct 2004 21:37:25 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMzSA-0004W9-W6 for dhcwg@ietf.org; Wed, 27 Oct 2004 21:51:54 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 27 Oct 2004 18:35:38 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9S1Xm6s003472; Wed, 27 Oct 2004 18:33:49 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-84.cisco.com [10.86.242.84]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMP72155; Wed, 27 Oct 2004 21:33:47 -0400 (EDT) From: "Bernie Volz" To: "'Kuntal Chowdhury'" , "'Ralph Droms'" Subject: RE: [dhcwg] BCMCS server option drafts Date: Wed, 27 Oct 2004 21:33:45 -0400 Organization: Cisco Message-ID: <000901c4bc8e$2a46d6c0$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <591B780D9676844E8A704B5B013FFE920382C07B@zrc2hxm1.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi: I believe the original model was for OPTION_VENDOR_CLASS to be similar = to DHCPv4 Vendor class identifier option (option 60) and for = OPTION_VENDOR_OPTS to be similar to DHCPv4 Vendor Specific Information (option 43). You might refer to draft-ietf-dhc-vendor-03.txt, while for DHCPv4, it = does have some additional information about how the options might be used. = That work is modeled on the DHCPv6 options. In particular, see section 4: 4. Vendor-Identifying Vendor-Specific Information Option DHCP clients and servers may use this option to exchange vendor- specific information. Either party may send this option, as needed. While a typical case might be for a client to send the Vendor-Identifying Vendor Class option, to elicit a useful Vendor-Identifying Vendor-Specific Information Option, there is no requirement for such a flow. It would be good to get general agreement on this as you're perhaps the first user. And, it would be best to set a "standard" for others to = follow. I kind of liked the DHCPv4 model, as it is much easier and clearly to understand (and implement for clients and servers): - A Client includes OPTION_VENDOR_CLASS to identify itself. - A Client MAY include OPTION_VENDOR_OPTS if it has vendor specific data (other than classing information) to communicate. - A Server includes OPTION_VENDOR_OPTS for matching enterprise IDs (and class data, if appropriate). This is only REQUIRED if the ORO includes = the OPTION_VENDOR_OPTS code (the ORO doesn't say which vendors; that is = handled by OPTION_VENDOR_CLASS). - I'm not sure why a server would ever need to include = OPTION_VENDOR_CLASS, though perhaps it could tell the client what implementation the server = is so that perhaps the client knows it could use some extended capabilities? = Or, the server could send back whatever the client sent to it? But, as draft-ietf-dhc-vendor-03.tx states, this is not the only = possible model. Note that in your case, I would assume that the OPTION_VENDOR_CLASS = would have your enterprise ID and some class information to indicate what capabilities the client supports (and therefore the server should = provide configuration for in the OPTION_VENDOR_OPTS). So, this is a good issue for the DHC WG to resolve and clarify for a = future RFC 3315bis. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Kuntal Chowdhury > Sent: Wednesday, October 27, 2004 4:33 PM > To: Ralph Droms; volz@cisco.com > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] BCMCS server option drafts >=20 >=20 > I have a few questions on the possible use of DHCPv6=20 > OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS to request vendor=20 > specific info: >=20 > 1. Since the enterprise number is included in=20 > OPTION_VENDOR_OPTS, will it suffice to use only this option=20 > in the information request message from the DHCP client? Is=20 > the use of OPTION_VENDOR_CLASS mandatory while vendor=20 > specific options are requested? >=20 > 2. Does the mere inclusion of OPTION_VENDOR_OPTS in the=20 > information request message indicate to the DHCP server that=20 > the DHCP client is requesting for some specific vendor=20 > specific options? > > 3. O-R-O has the format where each of requested option codes=20 > are listed in it. However, in OPTION_VENDOR_OPTS the=20 > encapsulated vendor-specific options field MUST be encoded as=20 > a sequence of code/length/value fields. What value does the=20 > DHCP client use while requesting for a vendor specific option?=20 >=20 > These things are not clearly defined in RFC3315. >=20 > Regards, > Kuntal >=20 > >-----Original Message----- > >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > >On Behalf Of Ralph Droms > >Sent: Wednesday, October 27, 2004 2:29 PM > >To: dhcwg@ietf.org > >Subject: RE: [dhcwg] BCMCS server option drafts > > > > > > > >What about the deployment issue? The 3GGP2 specification will > >be ratified in November, with deployment following soon. Some=20 > >service providers already have DHCP servers in place that must=20 > >be updated for any new options. The options defined in the=20 > >current drafts can likely be supported without code changes to=20 > >existing servers, allowing for faster deployment. Use of a=20 > >VIVSO sub-option would require code changes to existing=20 > >servers. How long would it take to deploy DHCP server that=20 > >can support VIVSO? > > > >BTW, we need more discussion of this issue *soon* due to the > >time constraints of the upcoming 3GPP2 standards process and=20 > >deployment. > > > >- Ralph > > > >At 04:12 PM 10/21/2004 -0400, Bernie Volz wrote: > >>Personally, I'd like to see the DHCPv4 VIVSO get deployed=20 > and pushing > >>these options to using it would be a step at making this=20 > >happen (as one > >>would expect 3GPP2 vendors to have some significant input to the > >>decisions of DHCP server vendors). > >> > >>It also means that 3GPP2 is free to define other VIVSO=20 > options in the > >>future within their own forum and need not go to the IETF=20 > >(and DHC WG). > >>I suspect that this would provide much faster deployment for them in > >>the future. > >> > >>Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS > >are already > >>there for DHCPv6. > >> > >>BTW, 3GPP2 already has an enterprise-id number: > >> > >>5535 > >> 3rd Generation Partnership Project 2 (3GPP2) > >> Allen Long > >> along@cisco.com > >> > >>So, they'd be good to go! > >> > >>- Bernie > >> > >> > -----Original Message----- > >> > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On > >> > Behalf Of Ralph Droms > >> > Sent: Thursday, October 21, 2004 2:35 PM > >> > To: dhcwg@ietf.org > >> > Subject: [dhcwg] BCMCS server option drafts > >> > > >> > > >> > We need to have a short WG conversation about two options > >that were > >> > discussed at the WG meeting in San Diego. The outcome of the > >> > conversation will be to determine consensus about taking=20 > on these=20 > >> > two > >> > drafts: > >> > > >> > draft-chowdhury-dhc-bcmcv4-option-01.txt > >> > draft-chowdhury-dhc-bcmcv6-option-01.txt > >> > > >> > as dhc WG work items or recommending that 3GPP2 define > >> > vendor-identifying vendor-specific option (VIVSO; option code > >> > 125) sub-options to carry the information described in=20 > the drafts. > >> > > >> > If the WG consensus is to take on the drafts as WG work items > >> > drafts, are they acceptable as currently published? > >> > > >> > Because of the time constraints imposed by the 3GPP2=20 > schedule, I'm > >> > going to cut off discussion on this topic next Thursday,=20 > >10/28, and > >> > determine WG consensus at that time. > >> > > >> > Here are some considerations for discussion: > >> > > >> > 3GPP2 has defined some vendor-specific sub-options, for > >example, to > >> > identify a MIP home agent for the DHCP client. > >> > > >> > A 3GPP2 client needs to specify to the DHCP server which > >parameters > >> > it needs - specifically, whether it needs to receive the BCMCS > >> > servers. If the current drafts are adopted, the client=20 > can simply=20 > >> > use the parameter request list option (option code 55) for the=20 > >> > request. If a VIVSO sub-option is used, 3GPP2 would=20 > also define a=20 > >> > parameter request list sub-option. > >> > > >> > There is a deployment issue, as some service providers > >already have > >> > DHCP servers in place that must be updated for any new > >options. Is > >> > it the case that the options defined in the current drafts can be > >> > supported without code changes to existing servers? Use=20 > >of a VIVSO > >> > sub-option would require code changes to existing servers. > > How long > >> > would it take to deploy DHCP server that can support VIVSO. > >> > > >> > BCMCS may be adopted across multiple technologies, so the > >options in > >> > the current drafts would not be specific to 3GPP2. However, the > >> > BCMCS specification has not adopted by other standards,=20 > yet, so we=20 > >> > may need to define additional options for related=20 > services in the=20 > >> > future if those services are not interoperable with the=20 > >3GPP2 BCMCS > >> > service. > >> > > >> > CableLabs has one option with sub-options (RFC 3495) rather than > >> > multiple options because: > >> > * wanted to avoid exhaustion of DHCP option code space;=20 > >perhaps less > >> > of an issue with option code reclassification > >> > * would have used VIVSO if available > >> > * use of VIVSO with sub-options would give 3GPP2 freedom > >to define new > >> > sub-options on demand > >> > Do these considerations have an impact on our decision > >about how to > >> > proceed with the 3GPP2 options? > >> > > >> > - Ralph > >> > > >> > > >> > _______________________________________________ > >> > dhcwg mailing list > >> > dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg > >> > > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Oct 28 03:15:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12571; Thu, 28 Oct 2004 03:15:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN4Ss-00008J-Mg; Thu, 28 Oct 2004 03:12:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN4Rn-0008IR-NA for dhcwg@megatron.ietf.org; Thu, 28 Oct 2004 03:11:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12282 for ; Thu, 28 Oct 2004 03:11:46 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN4fo-0001hj-9t for dhcwg@ietf.org; Thu, 28 Oct 2004 03:26:17 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4AD6B15210; Thu, 28 Oct 2004 16:11:37 +0900 (JST) Date: Thu, 28 Oct 2004 16:11:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Grubmair Peter Subject: Re: [dhcwg] retransmission timeout in stateless DHCPv6 and preference option ? In-Reply-To: <4D50D5110555D5119F270800062B41650532AC4C@viee10pa.erd.siemens.at> References: <4D50D5110555D5119F270800062B41650532AC4C@viee10pa.erd.siemens.at> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "Dhcwg \(E-mail\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Wed, 27 Oct 2004 15:03:31 +0200, >>>>> Grubmair Peter said: > If a statelesss dhcpv6 client receives a reply with > preference option, it has to wait until retransmission > timer expires to select reply highest preference. Please let me check, which part of which RFC does specify this behavior? Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Oct 28 10:10:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15300; Thu, 28 Oct 2004 10:10:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAsZ-00041s-8b; Thu, 28 Oct 2004 10:03:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAmp-0001UI-Lk for dhcwg@megatron.ietf.org; Thu, 28 Oct 2004 09:57:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13736 for ; Thu, 28 Oct 2004 09:57:54 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNB0t-0001iX-NT for dhcwg@ietf.org; Thu, 28 Oct 2004 10:12:29 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 28 Oct 2004 07:16:31 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9SDu9YJ009972; Thu, 28 Oct 2004 06:56:10 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMP95531; Thu, 28 Oct 2004 09:57:10 -0400 (EDT) From: "Bernie Volz" To: =?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?= , "'Grubmair Peter'" Subject: RE: [dhcwg] retransmission timeout in stateless DHCPv6 andpreference option ? Date: Thu, 28 Oct 2004 09:57:10 -0400 Organization: Cisco Message-ID: <000901c4bcf6$051a4180$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: "'Dhcwg \(E-mail\)'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable There's nothing I found in RFC 3315 that requires this. We were pretty = clear on what the SOLICIT behavior was, but weren't as clear in the INFORMATION-REQUEST case. I think you could go either way ... Follow the SOLICIT behavior and wait = the "first RT seconds" or take the first response. In the case where there = is a preference option and it specifies the highest preference (or where = there is no preference option), there would be no need to wait. If you wait, it = is only for 1 second based on the RFC specified values. I'd probably = recommend following the SOLICIT behavior. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of JINMEI Tatuya / =90_=96=BE=92B=8D=C6 > Sent: Thursday, October 28, 2004 3:12 AM > To: Grubmair Peter > Cc: Dhcwg (E-mail) > Subject: Re: [dhcwg] retransmission timeout in stateless=20 > DHCPv6 andpreference option ? >=20 >=20 > >>>>> On Wed, 27 Oct 2004 15:03:31 +0200, > >>>>> Grubmair Peter said: >=20 > > If a statelesss dhcpv6 client receives a reply with=20 > preference option,=20 > > it has to wait until retransmission timer expires to select reply=20 > > highest preference. >=20 > Please let me check, which part of which RFC does specify=20 > this behavior? >=20 > Thanks, >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Oct 28 15:48:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27200; Thu, 28 Oct 2004 15:48:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCpV-000760-VE; Thu, 28 Oct 2004 12:08:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNC5M-0005nu-GL for dhcwg@megatron.ietf.org; Thu, 28 Oct 2004 11:21:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25490 for ; Thu, 28 Oct 2004 11:21:06 -0400 (EDT) Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNCJO-0004cS-6V for dhcwg@ietf.org; Thu, 28 Oct 2004 11:35:42 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id i9SFKQT8006128 for ; Thu, 28 Oct 2004 17:20:26 +0200 Received: from vies141a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i9SFKQ45000328 for ; Thu, 28 Oct 2004 17:20:26 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Oct 2004 17:22:59 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AC50@viee10pa.erd.siemens.at> From: Grubmair Peter To: "'Bernie Volz'" Subject: RE: [dhcwg] retransmission timeout in stateless DHCPv6 andprefere nce option ? Date: Thu, 28 Oct 2004 17:18:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: "Dhcwg \(E-mail\)" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi bernie, thank you for your reply, I will use your proposal and implement according 17.1.2 from RFC 3315. best regards Peter -----Original Message----- From: Bernie Volz [mailto:volz@cisco.com] Sent: Donnerstag, 28. Oktober 2004 15:57 To: 'JINMEI Tatuya / =90_-=BE'B=8D=C6'; 'Grubmair Peter' Cc: 'Dhcwg (E-mail)' Subject: RE: [dhcwg] retransmission timeout in stateless DHCPv6 andpreference option ? There's nothing I found in RFC 3315 that requires this. We were pretty = clear on what the SOLICIT behavior was, but weren't as clear in the INFORMATION-REQUEST case. I think you could go either way ... Follow the SOLICIT behavior and = wait the "first RT seconds" or take the first response. In the case where there = is a preference option and it specifies the highest preference (or where = there is no preference option), there would be no need to wait. If you wait, it = is only for 1 second based on the RFC specified values. I'd probably = recommend following the SOLICIT behavior. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of JINMEI Tatuya / =90_-=BE'B=8D=C6 > Sent: Thursday, October 28, 2004 3:12 AM > To: Grubmair Peter > Cc: Dhcwg (E-mail) > Subject: Re: [dhcwg] retransmission timeout in stateless=20 > DHCPv6 andpreference option ? >=20 >=20 > >>>>> On Wed, 27 Oct 2004 15:03:31 +0200, > >>>>> Grubmair Peter said: >=20 > > If a statelesss dhcpv6 client receives a reply with=20 > preference option,=20 > > it has to wait until retransmission timer expires to select reply=20 > > highest preference. >=20 > Please let me check, which part of which RFC does specify=20 > this behavior? >=20 > Thanks, >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Oct 28 15:53:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28036; Thu, 28 Oct 2004 15:53:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCsp-0001ol-01; Thu, 28 Oct 2004 12:12:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCHf-0002VE-VP for dhcwg@megatron.ietf.org; Thu, 28 Oct 2004 11:33:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28450 for ; Thu, 28 Oct 2004 11:33:49 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNCVk-0005cn-9Z for dhcwg@ietf.org; Thu, 28 Oct 2004 11:48:25 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 28 Oct 2004 08:44:42 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9SFX3YJ011657; Thu, 28 Oct 2004 08:33:04 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.190]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMQ04834; Thu, 28 Oct 2004 11:33:02 -0400 (EDT) Message-Id: <4.3.2.7.2.20041028112952.023747c0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Oct 2004 11:33:00 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.3 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [dhcwg] IMPORTANT!!! dhc WG meeting now Tue AM X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Please be aware that, as of the most recent IETF 61 agenda http://ietf.org/meetings/agenda_61.html (updated 10/27), the dhc WG is now scheduled to meet: TUESDAY, November 9, 2004 0900-1130 Morning Sessions INT dhc Dynamic Host Configuration WG * RTG mpls Multiprotocol LabelSwitching WG SEC btns Better-Than-Nothing Security BOF SEC ltans Long-Term Archive and Notary Services WG TSV ippm IP Performance Metrics WG TSV sipping Session Initiation Protocol WG - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Oct 28 19:35:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12986; Thu, 28 Oct 2004 19:35:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNHH3-0001dv-Mn; Thu, 28 Oct 2004 16:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNFeN-0003lT-2m for dhcwg@megatron.ietf.org; Thu, 28 Oct 2004 15:09:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18923 for ; Thu, 28 Oct 2004 15:09:29 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNFsU-0005Ei-6j for dhcwg@ietf.org; Thu, 28 Oct 2004 15:24:06 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9SJ8u716966; Thu, 28 Oct 2004 15:08:56 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Oct 2004 15:08:58 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE920387C3BD@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Bernie Volz , "'Ralph Droms'" Subject: RE: [dhcwg] BCMCS server option drafts Date: Thu, 28 Oct 2004 15:08:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hello Bernie, Thanks for the response. I guess what is not clear to me is how a DHCP client requests vendor specific information from the DHCP server: " - A Client includes OPTION_VENDOR_CLASS to identify itself. - A Client MAY include OPTION_VENDOR_OPTS if it has vendor specific data (other than classing information) to communicate. - A Server includes OPTION_VENDOR_OPTS for matching enterprise IDs (and class data, if appropriate). This is only REQUIRED if the ORO includes the OPTION_VENDOR_OPTS code (the ORO doesn't say which vendors; that is handled by OPTION_VENDOR_CLASS). " Second bullet seems to say that the DHCP client includes OPTION_VENDOR_OPTS to convey some vendor specific information to the DHCP server beside the vendor class info (which is in OPTION_VENDOR_CLASS). It does not state that OPTION_VENDOR_OPTS is included in a DHCP message (such as information request) to REQUEST for vendor specific info from the server. It is true that opcode for OPTION_VENDOR_OPTS can be included in ORO, but that won't necessarily indicate to the server which vendor specific codes it needs to return to the client. Also, the format of the OPTION_VENDOR_OPTS when it appears in the REQUEST message is unclear. A clear description of how to use OPTION_VENDOR_OPTS to request vendor specific information (such as broadcast server address) will be required by SDOs such as 3GPP2. Regards, Kuntal >-----Original Message----- >From: Bernie Volz [mailto:volz@cisco.com] >Sent: Wednesday, October 27, 2004 8:34 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 'Ralph Droms' >Cc: dhcwg@ietf.org >Subject: RE: [dhcwg] BCMCS server option drafts > > >Hi: > >I believe the original model was for OPTION_VENDOR_CLASS to be >similar to DHCPv4 Vendor class identifier option (option 60) >and for OPTION_VENDOR_OPTS to be similar to DHCPv4 Vendor >Specific Information (option 43). > >You might refer to draft-ietf-dhc-vendor-03.txt, while for >DHCPv4, it does have some additional information about how the >options might be used. That work is modeled on the DHCPv6 >options. In particular, see section 4: > >4. Vendor-Identifying Vendor-Specific Information Option > > DHCP clients and servers may use this option to exchange vendor- > specific information. Either party may send this option, as needed. > While a typical case might be for a client to send the > Vendor-Identifying Vendor Class option, to elicit a useful > Vendor-Identifying Vendor-Specific Information Option, there is no > requirement for such a flow. > >It would be good to get general agreement on this as you're >perhaps the first user. And, it would be best to set a >"standard" for others to follow. > >I kind of liked the DHCPv4 model, as it is much easier and >clearly to understand (and implement for clients and servers): >- A Client includes OPTION_VENDOR_CLASS to identify itself. >- A Client MAY include OPTION_VENDOR_OPTS if it has vendor >specific data (other than classing information) to communicate. >- A Server includes OPTION_VENDOR_OPTS for matching enterprise >IDs (and class data, if appropriate). This is only REQUIRED if >the ORO includes the OPTION_VENDOR_OPTS code (the ORO doesn't >say which vendors; that is handled by OPTION_VENDOR_CLASS). >- I'm not sure why a server would ever need to include >OPTION_VENDOR_CLASS, though perhaps it could tell the client >what implementation the server is so that perhaps the client >knows it could use some extended capabilities? Or, the server >could send back whatever the client sent to it? > >But, as draft-ietf-dhc-vendor-03.tx states, this is not the >only possible model. > >Note that in your case, I would assume that the >OPTION_VENDOR_CLASS would have your enterprise ID and some >class information to indicate what capabilities the client >supports (and therefore the server should provide >configuration for in the OPTION_VENDOR_OPTS). > >So, this is a good issue for the DHC WG to resolve and clarify >for a future RFC 3315bis. > >- Bernie > >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] >> On Behalf Of Kuntal Chowdhury >> Sent: Wednesday, October 27, 2004 4:33 PM >> To: Ralph Droms; volz@cisco.com >> Cc: dhcwg@ietf.org >> Subject: RE: [dhcwg] BCMCS server option drafts >> >> >> I have a few questions on the possible use of DHCPv6 >> OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS to request vendor >> specific info: >> >> 1. Since the enterprise number is included in >> OPTION_VENDOR_OPTS, will it suffice to use only this option >> in the information request message from the DHCP client? Is >> the use of OPTION_VENDOR_CLASS mandatory while vendor >> specific options are requested? >> >> 2. Does the mere inclusion of OPTION_VENDOR_OPTS in the >> information request message indicate to the DHCP server that >> the DHCP client is requesting for some specific vendor >> specific options? >> >> 3. O-R-O has the format where each of requested option codes >> are listed in it. However, in OPTION_VENDOR_OPTS the >> encapsulated vendor-specific options field MUST be encoded as >> a sequence of code/length/value fields. What value does the >> DHCP client use while requesting for a vendor specific option? >> >> These things are not clearly defined in RFC3315. >> >> Regards, >> Kuntal >> >> >-----Original Message----- >> >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> >Behalf Of Ralph Droms >> >Sent: Wednesday, October 27, 2004 2:29 PM >> >To: dhcwg@ietf.org >> >Subject: RE: [dhcwg] BCMCS server option drafts >> > >> > >> > >> >What about the deployment issue? The 3GGP2 specification will be >> >ratified in November, with deployment following soon. Some service >> >providers already have DHCP servers in place that must be >updated for >> >any new options. The options defined in the current drafts can >> >likely be supported without code changes to existing servers, >> >allowing for faster deployment. Use of a VIVSO sub-option would >> >require code changes to existing servers. How long would >it take to >> >deploy DHCP server that can support VIVSO? >> > >> >BTW, we need more discussion of this issue *soon* due to the time >> >constraints of the upcoming 3GPP2 standards process and deployment. >> > >> >- Ralph >> > >> >At 04:12 PM 10/21/2004 -0400, Bernie Volz wrote: >> >>Personally, I'd like to see the DHCPv4 VIVSO get deployed >> and pushing >> >>these options to using it would be a step at making this >> >happen (as one >> >>would expect 3GPP2 vendors to have some significant input to the >> >>decisions of DHCP server vendors). >> >> >> >>It also means that 3GPP2 is free to define other VIVSO >> options in the >> >>future within their own forum and need not go to the IETF >> >(and DHC WG). >> >>I suspect that this would provide much faster deployment >for them in >> >>the future. >> >> >> >>Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS >> >are already >> >>there for DHCPv6. >> >> >> >>BTW, 3GPP2 already has an enterprise-id number: >> >> >> >>5535 >> >> 3rd Generation Partnership Project 2 (3GPP2) >> >> Allen Long >> >> along@cisco.com >> >> >> >>So, they'd be good to go! >> >> >> >>- Bernie >> >> >> >> > -----Original Message----- >> >> > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> >> > Behalf Of Ralph Droms >> >> > Sent: Thursday, October 21, 2004 2:35 PM >> >> > To: dhcwg@ietf.org >> >> > Subject: [dhcwg] BCMCS server option drafts >> >> > >> >> > >> >> > We need to have a short WG conversation about two options >> >that were >> >> > discussed at the WG meeting in San Diego. The outcome of the >> >> > conversation will be to determine consensus about taking >> on these >> >> > two >> >> > drafts: >> >> > >> >> > draft-chowdhury-dhc-bcmcv4-option-01.txt >> >> > draft-chowdhury-dhc-bcmcv6-option-01.txt >> >> > >> >> > as dhc WG work items or recommending that 3GPP2 define >> >> > vendor-identifying vendor-specific option (VIVSO; option code >> >> > 125) sub-options to carry the information described in >> the drafts. >> >> > >> >> > If the WG consensus is to take on the drafts as WG work items >> >> > drafts, are they acceptable as currently published? >> >> > >> >> > Because of the time constraints imposed by the 3GPP2 >> schedule, I'm >> >> > going to cut off discussion on this topic next Thursday, >> >10/28, and >> >> > determine WG consensus at that time. >> >> > >> >> > Here are some considerations for discussion: >> >> > >> >> > 3GPP2 has defined some vendor-specific sub-options, for >> >example, to >> >> > identify a MIP home agent for the DHCP client. >> >> > >> >> > A 3GPP2 client needs to specify to the DHCP server which >> >parameters >> >> > it needs - specifically, whether it needs to receive the BCMCS >> >> > servers. If the current drafts are adopted, the client >> can simply >> >> > use the parameter request list option (option code 55) for the >> >> > request. If a VIVSO sub-option is used, 3GPP2 would >> also define a >> >> > parameter request list sub-option. >> >> > >> >> > There is a deployment issue, as some service providers >> >already have >> >> > DHCP servers in place that must be updated for any new >> >options. Is >> >> > it the case that the options defined in the current >drafts can be >> >> > supported without code changes to existing servers? Use >> >of a VIVSO >> >> > sub-option would require code changes to existing servers. >> > How long >> >> > would it take to deploy DHCP server that can support VIVSO. >> >> > >> >> > BCMCS may be adopted across multiple technologies, so the >> >options in >> >> > the current drafts would not be specific to 3GPP2. >However, the >> >> > BCMCS specification has not adopted by other standards, >> yet, so we >> >> > may need to define additional options for related >> services in the >> >> > future if those services are not interoperable with the >> >3GPP2 BCMCS >> >> > service. >> >> > >> >> > CableLabs has one option with sub-options (RFC 3495) >rather than >> >> > multiple options because: >> >> > * wanted to avoid exhaustion of DHCP option code space; >> >perhaps less >> >> > of an issue with option code reclassification >> >> > * would have used VIVSO if available >> >> > * use of VIVSO with sub-options would give 3GPP2 freedom >> >to define new >> >> > sub-options on demand >> >> > Do these considerations have an impact on our decision >> >about how to >> >> > proceed with the 3GPP2 options? >> >> > >> >> > - Ralph >> >> > >> >> > >> >> > _______________________________________________ >> >> > dhcwg mailing list >> >> > dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg >> >> > >> > >> > >> >_______________________________________________ >> >dhcwg mailing list >> >dhcwg@ietf.org >> >https://www1.ietf.org/mailman/listinfo/dhcwg >> > >> > >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/dhcwg >> > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Oct 28 20:04:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21323; Thu, 28 Oct 2004 20:04:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJ8T-00084E-Vx; Thu, 28 Oct 2004 18:52:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGA0-0008PT-MB for dhcwg@megatron.ietf.org; Thu, 28 Oct 2004 15:42:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25732 for ; Thu, 28 Oct 2004 15:42:11 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNGO8-00076E-Cu for dhcwg@ietf.org; Thu, 28 Oct 2004 15:56:49 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I6B00A01819QC@mailout1.samsung.com> for dhcwg@ietf.org; Fri, 29 Oct 2004 04:41:33 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6B003XJ818NT@mailout1.samsung.com> for dhcwg@ietf.org; Fri, 29 Oct 2004 04:41:33 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I6B00LW2816X4@mmp1.samsung.com> for dhcwg@ietf.org; Fri, 29 Oct 2004 04:41:32 +0900 (KST) Date: Thu, 28 Oct 2004 12:41:30 -0700 From: Alper Yegin To: dhcwg@ietf.org Message-id: <002701c4bd26$205513f0$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7BIT Subject: [dhcwg] DHCP auth X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT >From posted agenda: DHCP Authentication via EAP Mark Stapp 10 minutes Technical discussion It's been a while since we discussed this issue. Here is a relevant (now expired) I-D, FYI: http://www.watersprings.org/pub/id/draft-yegin-eap-boot-rfc3118-00.txt Meanwhile, I'm wondering the status of draft-ietf-dhc-v4-threat-analysis-02. Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Oct 28 20:13:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23731; Thu, 28 Oct 2004 20:13:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJ9N-0001Gy-OZ; Thu, 28 Oct 2004 18:53:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGC9-0001EX-K3; Thu, 28 Oct 2004 15:44:25 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26254; Thu, 28 Oct 2004 15:44:24 -0400 (EDT) Message-Id: <200410281944.PAA26254@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 15:44:23 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dual-stack-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP: IPv4 and IPv6 Dual-Stack Issues Author(s) : T. Chown, et al. Filename : draft-ietf-dhc-dual-stack-02.txt Pages : 13 Date : 2004-10-28 A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP [1] designed for IPv4 has now been complemented by a new DHCPv6 [4] for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from DHCPv4 and DHCPv6 servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dual-stack-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dual-stack-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-dual-stack-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: <2004-10-28154902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dual-stack-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dual-stack-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28154902.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Thu Oct 28 20:15:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24671; Thu, 28 Oct 2004 20:15:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJ9V-0001Rs-UP; Thu, 28 Oct 2004 18:53:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGCU-0001R5-06; Thu, 28 Oct 2004 15:44:46 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26344; Thu, 28 Oct 2004 15:44:44 -0400 (EDT) Message-Id: <200410281944.PAA26344@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 15:44:44 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Renumbering Requirements for Stateless DHCPv6 Author(s) : T. Chown, et al. Filename : draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt Pages : 8 Date : 2004-10-28 IPv6 hosts using Stateless Address Autoconfiguration are able to automatically configure their IPv6 address and default router settings. However, further settings are not available. If such hosts wish to automatically configure their DNS, NTP or other specific settings the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using such a combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings, e.g. the addition of a new NTP server address, changes in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-stateless-dhcpv6-renumbering-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-stateless-dhcpv6-renumbering-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: <2004-10-28154907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28154907.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Thu Oct 28 21:14:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06771; Thu, 28 Oct 2004 21:14:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJC7-0005Kn-Ps; Thu, 28 Oct 2004 18:56:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGL2-00073K-NL for dhcwg@megatron.ietf.org; Thu, 28 Oct 2004 15:53:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28181 for ; Thu, 28 Oct 2004 15:53:35 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNGZ9-0007vq-9w for dhcwg@ietf.org; Thu, 28 Oct 2004 16:08:13 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2004 13:02:23 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9SJqvYJ023759; Thu, 28 Oct 2004 12:52:58 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMQ33185; Thu, 28 Oct 2004 15:52:59 -0400 (EDT) From: "Bernie Volz" To: "'Kuntal Chowdhury'" , "'Ralph Droms'" Subject: RE: [dhcwg] BCMCS server option drafts Date: Thu, 28 Oct 2004 15:52:59 -0400 Organization: Cisco Message-ID: <002801c4bd27$b9f6a5e0$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <591B780D9676844E8A704B5B013FFE920387C3BD@zrc2hxm1.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, "'josh Littlefield'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi: Good timing ... I just finished a conversation with Ralph on this issue. Basically, Ralph feels that what comes in from the client *COULD* = trigger what goes back, but there's no requirement for this. And if there is a trigger, it could be anything - it could be from OPTION_VENDOR_CLASS or OPTION_VENDOR_OPTS or some other data (such as USER_CLASS, the link the client is on, etc). For example, in the 3GPP2 environment, it may well be that the DHCP(v6) server is ONLY servicing 3GPP2 clients so it could be configured to = *ALWAYS* send back the OPTION_VENDOR_OPTS regardless of what the client sends in. Note that if the server sends back a OPTION_VENDOR_OPTS (or OPTION_VENDOR_CLASS) with information that the client doesn't know about (ie, enterprise ID isn't a known value), the client MUST ignore that = data (just like if it received an unknown option). If this will be used in environments where it is known that all clients = will need this information, simply require the servers to be configured to = send it. A particular client that doesn't support the functionality will just ignore the information. If this will be used in mixed environments where many different client = types will exist, some which will never want this information (and there are = good reasons not to send it to them), you could define a mechanism to trigger = a server to send it. You might do this using a OPTION_VENDOR_CLASS to, for example, communicate that this is a 3GPP2 device interested in BCMCS service. Or simply that is is a 3GPP2 device. You could also use the OPTION_VENDOR_OPTS to do this (client->server). But, even if you did = this, a server may still be configured to send it unconditionally. - Bernie > -----Original Message----- > From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com]=20 > Sent: Thursday, October 28, 2004 3:09 PM > To: Bernie Volz; 'Ralph Droms' > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] BCMCS server option drafts >=20 >=20 > Hello Bernie, >=20 > Thanks for the response. I guess what is not clear to me is=20 > how a DHCP client requests vendor specific information from=20 > the DHCP server: >=20 > " > - A Client includes OPTION_VENDOR_CLASS to identify itself. > - A Client MAY include OPTION_VENDOR_OPTS if it has vendor=20 > specific data (other than classing information) to communicate. > - A Server includes OPTION_VENDOR_OPTS for matching=20 > enterprise IDs (and class data, if appropriate). This is only=20 > REQUIRED if the ORO includes the OPTION_VENDOR_OPTS code (the=20 > ORO doesn't say which vendors; that is handled by=20 > OPTION_VENDOR_CLASS). " >=20 > Second bullet seems to say that the DHCP client includes=20 > OPTION_VENDOR_OPTS to convey some vendor specific information=20 > to the DHCP server beside the vendor class info (which is in=20 > OPTION_VENDOR_CLASS). It does not state that=20 > OPTION_VENDOR_OPTS is included in a DHCP message (such as information > request) to REQUEST for vendor specific info from the server.=20 > It is true that opcode for OPTION_VENDOR_OPTS can be included=20 > in ORO, but that won't necessarily indicate to the server=20 > which vendor specific codes it needs to return to the client.=20 > Also, the format of the OPTION_VENDOR_OPTS when it appears in=20 > the REQUEST message is unclear. >=20 > A clear description of how to use OPTION_VENDOR_OPTS to=20 > request vendor specific information (such as broadcast server=20 > address) will be required by SDOs such as 3GPP2. >=20 > Regards, > Kuntal >=20 >=20 > >-----Original Message----- > >From: Bernie Volz [mailto:volz@cisco.com] > >Sent: Wednesday, October 27, 2004 8:34 PM > >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 'Ralph Droms' > >Cc: dhcwg@ietf.org > >Subject: RE: [dhcwg] BCMCS server option drafts > > > > > >Hi: > > > >I believe the original model was for OPTION_VENDOR_CLASS to be > >similar to DHCPv4 Vendor class identifier option (option 60)=20 > >and for OPTION_VENDOR_OPTS to be similar to DHCPv4 Vendor=20 > >Specific Information (option 43). > > > >You might refer to draft-ietf-dhc-vendor-03.txt, while for > >DHCPv4, it does have some additional information about how the=20 > >options might be used. That work is modeled on the DHCPv6=20 > >options. In particular, see section 4: > > > >4. Vendor-Identifying Vendor-Specific Information Option > > > > DHCP clients and servers may use this option to exchange vendor- > > specific information. Either party may send this option,=20 > as needed. > > While a typical case might be for a client to send the > > Vendor-Identifying Vendor Class option, to elicit a useful > > Vendor-Identifying Vendor-Specific Information Option, there is no > > requirement for such a flow. > > > >It would be good to get general agreement on this as you're > >perhaps the first user. And, it would be best to set a=20 > >"standard" for others to follow. > > > >I kind of liked the DHCPv4 model, as it is much easier and > >clearly to understand (and implement for clients and servers): > >- A Client includes OPTION_VENDOR_CLASS to identify itself. > >- A Client MAY include OPTION_VENDOR_OPTS if it has vendor=20 > >specific data (other than classing information) to communicate. > >- A Server includes OPTION_VENDOR_OPTS for matching enterprise=20 > >IDs (and class data, if appropriate). This is only REQUIRED if=20 > >the ORO includes the OPTION_VENDOR_OPTS code (the ORO doesn't=20 > >say which vendors; that is handled by OPTION_VENDOR_CLASS). > >- I'm not sure why a server would ever need to include=20 > >OPTION_VENDOR_CLASS, though perhaps it could tell the client=20 > >what implementation the server is so that perhaps the client=20 > >knows it could use some extended capabilities? Or, the server=20 > >could send back whatever the client sent to it? > > > >But, as draft-ietf-dhc-vendor-03.tx states, this is not the > >only possible model. > > > >Note that in your case, I would assume that the > >OPTION_VENDOR_CLASS would have your enterprise ID and some=20 > >class information to indicate what capabilities the client=20 > >supports (and therefore the server should provide=20 > >configuration for in the OPTION_VENDOR_OPTS). > > > >So, this is a good issue for the DHC WG to resolve and clarify > >for a future RFC 3315bis. > > > >- Bernie > > > >> -----Original Message----- > >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 > >> Behalf Of Kuntal Chowdhury > >> Sent: Wednesday, October 27, 2004 4:33 PM > >> To: Ralph Droms; volz@cisco.com > >> Cc: dhcwg@ietf.org > >> Subject: RE: [dhcwg] BCMCS server option drafts > >>=20 > >>=20 > >> I have a few questions on the possible use of DHCPv6=20 > >> OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS to request=20 > vendor specific=20 > >> info: > >>=20 > >> 1. Since the enterprise number is included in OPTION_VENDOR_OPTS,=20 > >> will it suffice to use only this option in the information request=20 > >> message from the DHCP client? Is the use of OPTION_VENDOR_CLASS=20 > >> mandatory while vendor specific options are requested? > >>=20 > >> 2. Does the mere inclusion of OPTION_VENDOR_OPTS in the=20 > information=20 > >> request message indicate to the DHCP server that the DHCP=20 > client is=20 > >> requesting for some specific vendor specific options? > >> > >> 3. O-R-O has the format where each of requested option codes are=20 > >> listed in it. However, in OPTION_VENDOR_OPTS the encapsulated=20 > >> vendor-specific options field MUST be encoded as a sequence of=20 > >> code/length/value fields. What value does the DHCP client=20 > use while=20 > >> requesting for a vendor specific option? > >>=20 > >> These things are not clearly defined in RFC3315. > >>=20 > >> Regards, > >> Kuntal > >>=20 > >> >-----Original Message----- > >> >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On > >> >Behalf Of Ralph Droms > >> >Sent: Wednesday, October 27, 2004 2:29 PM > >> >To: dhcwg@ietf.org > >> >Subject: RE: [dhcwg] BCMCS server option drafts > >> > > >> > > >> > > >> >What about the deployment issue? The 3GGP2 specification will be > >> >ratified in November, with deployment following soon. =20 > Some service=20 > >> >providers already have DHCP servers in place that must be=20 > >updated for > >> >any new options. The options defined in the current drafts can > >> >likely be supported without code changes to existing servers,=20 > >> >allowing for faster deployment. Use of a VIVSO sub-option would=20 > >> >require code changes to existing servers. How long would=20 > >it take to > >> >deploy DHCP server that can support VIVSO? > >> > > >> >BTW, we need more discussion of this issue *soon* due to the time > >> >constraints of the upcoming 3GPP2 standards process and=20 > deployment. > >> > > >> >- Ralph > >> > > >> >At 04:12 PM 10/21/2004 -0400, Bernie Volz wrote: > >> >>Personally, I'd like to see the DHCPv4 VIVSO get deployed > >> and pushing > >> >>these options to using it would be a step at making this > >> >happen (as one > >> >>would expect 3GPP2 vendors to have some significant input to the > >> >>decisions of DHCP server vendors). > >> >> > >> >>It also means that 3GPP2 is free to define other VIVSO > >> options in the > >> >>future within their own forum and need not go to the IETF > >> >(and DHC WG). > >> >>I suspect that this would provide much faster deployment > >for them in > >> >>the future. > >> >> > >> >>Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS > >> >are already > >> >>there for DHCPv6. > >> >> > >> >>BTW, 3GPP2 already has an enterprise-id number: > >> >> > >> >>5535 > >> >> 3rd Generation Partnership Project 2 (3GPP2) > >> >> Allen Long > >> >> along@cisco.com > >> >> > >> >>So, they'd be good to go! > >> >> > >> >>- Bernie > >> >> > >> >> > -----Original Message----- > >> >> > From: dhcwg-bounces@ietf.org=20 > [mailto:dhcwg-bounces@ietf.org] On > >> >> > Behalf Of Ralph Droms > >> >> > Sent: Thursday, October 21, 2004 2:35 PM > >> >> > To: dhcwg@ietf.org > >> >> > Subject: [dhcwg] BCMCS server option drafts > >> >> > > >> >> > > >> >> > We need to have a short WG conversation about two options > >> >that were > >> >> > discussed at the WG meeting in San Diego. The outcome of the > >> >> > conversation will be to determine consensus about taking > >> on these > >> >> > two > >> >> > drafts: > >> >> > > >> >> > draft-chowdhury-dhc-bcmcv4-option-01.txt > >> >> > draft-chowdhury-dhc-bcmcv6-option-01.txt > >> >> > > >> >> > as dhc WG work items or recommending that 3GPP2 define > >> >> > vendor-identifying vendor-specific option (VIVSO; option code > >> >> > 125) sub-options to carry the information described in > >> the drafts. > >> >> > > >> >> > If the WG consensus is to take on the drafts as WG work items > >> >> > drafts, are they acceptable as currently published? > >> >> > > >> >> > Because of the time constraints imposed by the 3GPP2 > >> schedule, I'm > >> >> > going to cut off discussion on this topic next Thursday, > >> >10/28, and > >> >> > determine WG consensus at that time. > >> >> > > >> >> > Here are some considerations for discussion: > >> >> > > >> >> > 3GPP2 has defined some vendor-specific sub-options, for > >> >example, to > >> >> > identify a MIP home agent for the DHCP client. > >> >> > > >> >> > A 3GPP2 client needs to specify to the DHCP server which > >> >parameters > >> >> > it needs - specifically, whether it needs to receive the BCMCS > >> >> > servers. If the current drafts are adopted, the client > >> can simply > >> >> > use the parameter request list option (option code=20 > 55) for the=20 > >> >> > request. If a VIVSO sub-option is used, 3GPP2 would > >> also define a > >> >> > parameter request list sub-option. > >> >> > > >> >> > There is a deployment issue, as some service providers > >> >already have > >> >> > DHCP servers in place that must be updated for any new > >> >options. Is > >> >> > it the case that the options defined in the current > >drafts can be > >> >> > supported without code changes to existing servers? Use > >> >of a VIVSO > >> >> > sub-option would require code changes to existing servers. > >> > How long > >> >> > would it take to deploy DHCP server that can support VIVSO. > >> >> > > >> >> > BCMCS may be adopted across multiple technologies, so the > >> >options in > >> >> > the current drafts would not be specific to 3GPP2. > >However, the > >> >> > BCMCS specification has not adopted by other standards, > >> yet, so we > >> >> > may need to define additional options for related > >> services in the > >> >> > future if those services are not interoperable with the > >> >3GPP2 BCMCS > >> >> > service. > >> >> > > >> >> > CableLabs has one option with sub-options (RFC 3495) > >rather than > >> >> > multiple options because: > >> >> > * wanted to avoid exhaustion of DHCP option code space; > >> >perhaps less > >> >> > of an issue with option code reclassification > >> >> > * would have used VIVSO if available > >> >> > * use of VIVSO with sub-options would give 3GPP2 freedom > >> >to define new > >> >> > sub-options on demand > >> >> > Do these considerations have an impact on our decision > >> >about how to > >> >> > proceed with the 3GPP2 options? > >> >> > > >> >> > - Ralph > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > dhcwg mailing list > >> >> > dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg > >> >> > > >> > > >> > > >> >_______________________________________________ > >> >dhcwg mailing list > >> >dhcwg@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/dhcwg > >> > > >> > > >>=20 > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dhcwg > >>=20 > > > > > > >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Oct 28 22:19:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22856; Thu, 28 Oct 2004 22:19:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJwv-0000px-8M; Thu, 28 Oct 2004 19:44:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNHrH-00022X-Hq for dhcwg@megatron.ietf.org; Thu, 28 Oct 2004 17:30:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16786; Thu, 28 Oct 2004 17:30:57 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNI5P-00058p-RF; Thu, 28 Oct 2004 17:45:37 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 28 Oct 2004 17:53:06 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9SLUPUD017099; Thu, 28 Oct 2004 17:30:26 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.190]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMQ42825; Thu, 28 Oct 2004 17:30:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20041028172738.023a0008@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Oct 2004 17:30:06 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: agenda@ietf.org Subject: [dhcwg] Tentative agenda for dhc WG meeting at IETF 61 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Here is the latest draft agenda for the dhc WG meeting at IETF 61. NOTE CHANGE OF DATE TO TUE, 2004-11-09!!! - Ralph DHC WG agenda - IETF 61 0900 Tue 2004-11-09 (tentative) (Last revised 2004-10-28 05:25 PM) ---------------------------------- Administrivia Ralph Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Request for milestones for dhc WG drafts DNS zone suffix option for DHCPv6 Renxiang Yan 10 minutes Accept as dhc WG work item? Reclassifying DHCPv4 Options TBD 10 minutes How to implement the process after RFC is published? Vendor-Specific Information Suboption Mark Stapp 10 minutes Ready for WG last call? DHCP Authentication via EAP Mark Stapp 10 minutes Technical discussion Lifetime Option for DHCPv6 Stig Venaas 10 minutes Ready for WG last call? Anycast Address Assignment using DHCPv6 Syam Madanapalli 10 minutes Accept as dhc WG work item? Source Address Selection Policy option for DHCPv6 A. Matsumoto 10 minutes (available as http://www.nttv6.net/~arifumi/draft-hirotaka-dhc-source-address-selection-opt-00.txt) Accept as dhc WG work item? DHCPv6 Relay Agent Information Option Wing Cheong Lau 10 minutes Accept as dhc WG work item? DHCP-DNS interaction Bernie Volz 30 minutes Technical discussion ----------- 120 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 29 00:06:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05994; Fri, 29 Oct 2004 00:06:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNNiR-0003HQ-C8; Thu, 28 Oct 2004 23:46:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNNVq-0005zG-QU for dhcwg@megatron.ietf.org; Thu, 28 Oct 2004 23:33:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03313; Thu, 28 Oct 2004 23:33:13 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNk4-0002tu-1L; Thu, 28 Oct 2004 23:47:56 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 28 Oct 2004 23:55:26 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9T3Wgps021740; Thu, 28 Oct 2004 23:32:42 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn2-660.cisco.com [10.21.114.148]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMQ59907; Thu, 28 Oct 2004 23:32:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20041028233131.0276e800@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Oct 2004 23:32:36 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: agenda@ietf.org Subject: [dhcwg] Tentative agenda for dhc WG meeting at IETF 61 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Here is the latest draft agenda for the dhc WG meeting at IETF 61. - Ralph DHC WG agenda - IETF 61 0900 Tue 2004-11-09 (tentative) (Last revised 2004-10-28 11:29 PM) ---------------------------------- Administrivia Ralph Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Request for milestones for dhc WG drafts DNS zone suffix option for DHCPv6 Renxiang Yan 10 minutes Accept as dhc WG work item? Reclassifying DHCPv4 Options TBD 10 minutes How to implement the process after RFC is published? Vendor-Specific Information Suboption Mark Stapp 10 minutes Ready for WG last call? DHCP Authentication via EAP Mark Stapp 10 minutes Technical discussion Lifetime Option for DHCPv6 Stig Venaas 10 minutes Ready for WG last call? Anycast Address Assignment using DHCPv6 Syam Madanapalli 10 minutes Accept as dhc WG work item? Source Address Selection Policy option for DHCPv6 T. Fujisaki 10 minutes (available as http://www.nttv6.net/~arifumi/draft-hirotaka-dhc-source-address-selection-opt-00.txt) Accept as dhc WG work item? DHCPv6 Relay Agent Information Option Wing Cheong Lau 10 minutes Accept as dhc WG work item? DHCP-DNS interaction Bernie Volz 30 minutes Technical discussion ----------- 120 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 29 05:26:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11035; Fri, 29 Oct 2004 05:26:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSSJ-0005X8-Kv; Fri, 29 Oct 2004 04:49:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSIO-0006te-W9 for dhcwg@megatron.ietf.org; Fri, 29 Oct 2004 04:39:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07982 for ; Fri, 29 Oct 2004 04:39:38 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSWd-0000ri-4K for dhcwg@ietf.org; Fri, 29 Oct 2004 04:54:24 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i9T8daP6007881; Fri, 29 Oct 2004 10:39:36 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9T8daBO016475; Fri, 29 Oct 2004 10:39:36 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR70K6>; Fri, 29 Oct 2004 10:39:36 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0468693F@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] IMPORTANT!!! dhc WG meeting now Tue AM Date: Fri, 29 Oct 2004 10:39:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org hi ralph, hi all, the dhc agenda raised my interest. i would like to know more about " DHCP Authentication via EAP Mark Stapp 10 minutes Technical discussion " ciao hannes > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Donnerstag, 28. Oktober 2004 17:33 > To: dhcwg@ietf.org > Subject: [dhcwg] IMPORTANT!!! dhc WG meeting now Tue AM > > Please be aware that, as of the most recent IETF 61 agenda > http://ietf.org/meetings/agenda_61.html (updated 10/27), the > dhc WG is now scheduled to meet: > > TUESDAY, November 9, 2004 > 0900-1130 Morning Sessions > INT dhc Dynamic Host Configuration WG * > RTG mpls Multiprotocol LabelSwitching WG > SEC btns Better-Than-Nothing Security BOF > SEC ltans Long-Term Archive and Notary Services WG > TSV ippm IP Performance Metrics WG > TSV sipping Session Initiation Protocol WG > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 29 08:13:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22762; Fri, 29 Oct 2004 08:13:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNVYf-0006kk-Fa; Fri, 29 Oct 2004 08:08:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNVGb-0006Kh-4I for dhcwg@megatron.ietf.org; Fri, 29 Oct 2004 07:50:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20979 for ; Fri, 29 Oct 2004 07:49:59 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNVUr-0004qg-FU for dhcwg@ietf.org; Fri, 29 Oct 2004 08:04:46 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 29 Oct 2004 07:49:30 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9TBnRps011102; Fri, 29 Oct 2004 07:49:27 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn1-176.cisco.com [10.21.96.176]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMQ71835; Fri, 29 Oct 2004 07:49:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20041029063111.02852d20@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Oct 2004 07:49:21 -0400 To: "Kuntal Chowdhury" From: Ralph Droms Subject: RE: [dhcwg] BCMCS server option drafts In-Reply-To: <591B780D9676844E8A704B5B013FFE920387C3BD@zrc2hxm1.corp.nor tel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: dhcwg@ietf.org, Bernie Volz X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Kuntal - in both DHCPv4 and DHCPv6, there are no required semantic ties between the message from the client to the server and the response from the server. That is, the client is not required to include any option request information or vendor identification (I'm using general terms rather than specific options because of the differences between DHCPv4 and DHCPv6) to cause the server to send certain options or vendor-specific information back to the client. The server uses any option request information or vendor identification or vendor-specific information as input ("hints") to the rules the server uses to send a response to the client. The server is free to send information that has not been specifically requested by the client, based on other information the server gleans from the message it receives from the client. So, in the DHCPv6 case, the client is not required to send an OPTION_ORO requesting OPTION_VENDOR_OPTS (although it may do so) and the server, based on other information, is free to send OPTION_VENDOR_OPTS. In a 3GPP2 deployment, if the DHCPv6 server sees a request from a part of the network topology known to be using 3GPP2, the server may assume that the device sending the request is a 3GPP2 device and send 3GPP2 OPTION_VENDOR_OPTS to that client. And, if, for some reason, the client is not a 3GPP2 device, the client can simply ignore the 3GPP2 OPTION_VENDOR_OPTS. The 3GPP2 standards bodies are free to define any syntax or semantics for the 3GPP2 OPTION_VENDOR_OPTS. So, if 3GPP2 coule require that a client sends a 3GPP2 OPTION_VENDOR_OPTS request, which the server parses and responds with 3GPP2 OPTION_VENDOR_OPTS containing information for the client. - Ralph At 03:08 PM 10/28/2004 -0400, Kuntal Chowdhury wrote: >Hello Bernie, > >Thanks for the response. I guess what is not clear to me is how a DHCP >client requests vendor specific information from the DHCP server: > >" >- A Client includes OPTION_VENDOR_CLASS to identify itself. >- A Client MAY include OPTION_VENDOR_OPTS if it has vendor specific data >(other than classing information) to communicate. >- A Server includes OPTION_VENDOR_OPTS for matching enterprise IDs (and >class data, if appropriate). This is only REQUIRED if the ORO includes the >OPTION_VENDOR_OPTS code (the ORO doesn't say which vendors; that is handled >by OPTION_VENDOR_CLASS). >" > >Second bullet seems to say that the DHCP client includes OPTION_VENDOR_OPTS >to convey some vendor specific information to the DHCP server beside the >vendor class info (which is in OPTION_VENDOR_CLASS). It does not state that >OPTION_VENDOR_OPTS is included in a DHCP message (such as information >request) to REQUEST for vendor specific info from the server. It is true >that opcode for OPTION_VENDOR_OPTS can be included in ORO, but that won't >necessarily indicate to the server which vendor specific codes it needs to >return to the client. Also, the format of the OPTION_VENDOR_OPTS when it >appears in the REQUEST message is unclear. > >A clear description of how to use OPTION_VENDOR_OPTS to request vendor >specific information (such as broadcast server address) will be required by >SDOs such as 3GPP2. > >Regards, >Kuntal > > > >-----Original Message----- > >From: Bernie Volz [mailto:volz@cisco.com] > >Sent: Wednesday, October 27, 2004 8:34 PM > >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 'Ralph Droms' > >Cc: dhcwg@ietf.org > >Subject: RE: [dhcwg] BCMCS server option drafts > > > > > >Hi: > > > >I believe the original model was for OPTION_VENDOR_CLASS to be > >similar to DHCPv4 Vendor class identifier option (option 60) > >and for OPTION_VENDOR_OPTS to be similar to DHCPv4 Vendor > >Specific Information (option 43). > > > >You might refer to draft-ietf-dhc-vendor-03.txt, while for > >DHCPv4, it does have some additional information about how the > >options might be used. That work is modeled on the DHCPv6 > >options. In particular, see section 4: > > > >4. Vendor-Identifying Vendor-Specific Information Option > > > > DHCP clients and servers may use this option to exchange vendor- > > specific information. Either party may send this option, as needed. > > While a typical case might be for a client to send the > > Vendor-Identifying Vendor Class option, to elicit a useful > > Vendor-Identifying Vendor-Specific Information Option, there is no > > requirement for such a flow. > > > >It would be good to get general agreement on this as you're > >perhaps the first user. And, it would be best to set a > >"standard" for others to follow. > > > >I kind of liked the DHCPv4 model, as it is much easier and > >clearly to understand (and implement for clients and servers): > >- A Client includes OPTION_VENDOR_CLASS to identify itself. > >- A Client MAY include OPTION_VENDOR_OPTS if it has vendor > >specific data (other than classing information) to communicate. > >- A Server includes OPTION_VENDOR_OPTS for matching enterprise > >IDs (and class data, if appropriate). This is only REQUIRED if > >the ORO includes the OPTION_VENDOR_OPTS code (the ORO doesn't > >say which vendors; that is handled by OPTION_VENDOR_CLASS). > >- I'm not sure why a server would ever need to include > >OPTION_VENDOR_CLASS, though perhaps it could tell the client > >what implementation the server is so that perhaps the client > >knows it could use some extended capabilities? Or, the server > >could send back whatever the client sent to it? > > > >But, as draft-ietf-dhc-vendor-03.tx states, this is not the > >only possible model. > > > >Note that in your case, I would assume that the > >OPTION_VENDOR_CLASS would have your enterprise ID and some > >class information to indicate what capabilities the client > >supports (and therefore the server should provide > >configuration for in the OPTION_VENDOR_OPTS). > > > >So, this is a good issue for the DHC WG to resolve and clarify > >for a future RFC 3315bis. > > > >- Bernie > > > >> -----Original Message----- > >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > >> On Behalf Of Kuntal Chowdhury > >> Sent: Wednesday, October 27, 2004 4:33 PM > >> To: Ralph Droms; volz@cisco.com > >> Cc: dhcwg@ietf.org > >> Subject: RE: [dhcwg] BCMCS server option drafts > >> > >> > >> I have a few questions on the possible use of DHCPv6 > >> OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS to request vendor > >> specific info: > >> > >> 1. Since the enterprise number is included in > >> OPTION_VENDOR_OPTS, will it suffice to use only this option > >> in the information request message from the DHCP client? Is > >> the use of OPTION_VENDOR_CLASS mandatory while vendor > >> specific options are requested? > >> > >> 2. Does the mere inclusion of OPTION_VENDOR_OPTS in the > >> information request message indicate to the DHCP server that > >> the DHCP client is requesting for some specific vendor > >> specific options? > >> > >> 3. O-R-O has the format where each of requested option codes > >> are listed in it. However, in OPTION_VENDOR_OPTS the > >> encapsulated vendor-specific options field MUST be encoded as > >> a sequence of code/length/value fields. What value does the > >> DHCP client use while requesting for a vendor specific option? > >> > >> These things are not clearly defined in RFC3315. > >> > >> Regards, > >> Kuntal > >> > >> >-----Original Message----- > >> >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On > >> >Behalf Of Ralph Droms > >> >Sent: Wednesday, October 27, 2004 2:29 PM > >> >To: dhcwg@ietf.org > >> >Subject: RE: [dhcwg] BCMCS server option drafts > >> > > >> > > >> > > >> >What about the deployment issue? The 3GGP2 specification will be > >> >ratified in November, with deployment following soon. Some service > >> >providers already have DHCP servers in place that must be > >updated for > >> >any new options. The options defined in the current drafts can > >> >likely be supported without code changes to existing servers, > >> >allowing for faster deployment. Use of a VIVSO sub-option would > >> >require code changes to existing servers. How long would > >it take to > >> >deploy DHCP server that can support VIVSO? > >> > > >> >BTW, we need more discussion of this issue *soon* due to the time > >> >constraints of the upcoming 3GPP2 standards process and deployment. > >> > > >> >- Ralph > >> > > >> >At 04:12 PM 10/21/2004 -0400, Bernie Volz wrote: > >> >>Personally, I'd like to see the DHCPv4 VIVSO get deployed > >> and pushing > >> >>these options to using it would be a step at making this > >> >happen (as one > >> >>would expect 3GPP2 vendors to have some significant input to the > >> >>decisions of DHCP server vendors). > >> >> > >> >>It also means that 3GPP2 is free to define other VIVSO > >> options in the > >> >>future within their own forum and need not go to the IETF > >> >(and DHC WG). > >> >>I suspect that this would provide much faster deployment > >for them in > >> >>the future. > >> >> > >> >>Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS > >> >are already > >> >>there for DHCPv6. > >> >> > >> >>BTW, 3GPP2 already has an enterprise-id number: > >> >> > >> >>5535 > >> >> 3rd Generation Partnership Project 2 (3GPP2) > >> >> Allen Long > >> >> along@cisco.com > >> >> > >> >>So, they'd be good to go! > >> >> > >> >>- Bernie > >> >> > >> >> > -----Original Message----- > >> >> > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On > >> >> > Behalf Of Ralph Droms > >> >> > Sent: Thursday, October 21, 2004 2:35 PM > >> >> > To: dhcwg@ietf.org > >> >> > Subject: [dhcwg] BCMCS server option drafts > >> >> > > >> >> > > >> >> > We need to have a short WG conversation about two options > >> >that were > >> >> > discussed at the WG meeting in San Diego. The outcome of the > >> >> > conversation will be to determine consensus about taking > >> on these > >> >> > two > >> >> > drafts: > >> >> > > >> >> > draft-chowdhury-dhc-bcmcv4-option-01.txt > >> >> > draft-chowdhury-dhc-bcmcv6-option-01.txt > >> >> > > >> >> > as dhc WG work items or recommending that 3GPP2 define > >> >> > vendor-identifying vendor-specific option (VIVSO; option code > >> >> > 125) sub-options to carry the information described in > >> the drafts. > >> >> > > >> >> > If the WG consensus is to take on the drafts as WG work items > >> >> > drafts, are they acceptable as currently published? > >> >> > > >> >> > Because of the time constraints imposed by the 3GPP2 > >> schedule, I'm > >> >> > going to cut off discussion on this topic next Thursday, > >> >10/28, and > >> >> > determine WG consensus at that time. > >> >> > > >> >> > Here are some considerations for discussion: > >> >> > > >> >> > 3GPP2 has defined some vendor-specific sub-options, for > >> >example, to > >> >> > identify a MIP home agent for the DHCP client. > >> >> > > >> >> > A 3GPP2 client needs to specify to the DHCP server which > >> >parameters > >> >> > it needs - specifically, whether it needs to receive the BCMCS > >> >> > servers. If the current drafts are adopted, the client > >> can simply > >> >> > use the parameter request list option (option code 55) for the > >> >> > request. If a VIVSO sub-option is used, 3GPP2 would > >> also define a > >> >> > parameter request list sub-option. > >> >> > > >> >> > There is a deployment issue, as some service providers > >> >already have > >> >> > DHCP servers in place that must be updated for any new > >> >options. Is > >> >> > it the case that the options defined in the current > >drafts can be > >> >> > supported without code changes to existing servers? Use > >> >of a VIVSO > >> >> > sub-option would require code changes to existing servers. > >> > How long > >> >> > would it take to deploy DHCP server that can support VIVSO. > >> >> > > >> >> > BCMCS may be adopted across multiple technologies, so the > >> >options in > >> >> > the current drafts would not be specific to 3GPP2. > >However, the > >> >> > BCMCS specification has not adopted by other standards, > >> yet, so we > >> >> > may need to define additional options for related > >> services in the > >> >> > future if those services are not interoperable with the > >> >3GPP2 BCMCS > >> >> > service. > >> >> > > >> >> > CableLabs has one option with sub-options (RFC 3495) > >rather than > >> >> > multiple options because: > >> >> > * wanted to avoid exhaustion of DHCP option code space; > >> >perhaps less > >> >> > of an issue with option code reclassification > >> >> > * would have used VIVSO if available > >> >> > * use of VIVSO with sub-options would give 3GPP2 freedom > >> >to define new > >> >> > sub-options on demand > >> >> > Do these considerations have an impact on our decision > >> >about how to > >> >> > proceed with the 3GPP2 options? > >> >> > > >> >> > - Ralph > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > dhcwg mailing list > >> >> > dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg > >> >> > > >> > > >> > > >> >_______________________________________________ > >> >dhcwg mailing list > >> >dhcwg@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/dhcwg > >> > > >> > > >> > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dhcwg > >> > > > > > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 29 13:07:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16154; Fri, 29 Oct 2004 13:07:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNa03-0006hs-B9; Fri, 29 Oct 2004 12:53:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZrh-0000L9-Uy for dhcwg@megatron.ietf.org; Fri, 29 Oct 2004 12:44:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14275 for ; Fri, 29 Oct 2004 12:44:35 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNa61-00032c-4q for dhcwg@ietf.org; Fri, 29 Oct 2004 12:59:25 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9TGi0u24082 for ; Fri, 29 Oct 2004 12:44:00 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Oct 2004 12:44:01 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92038DE042@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: dhcwg@ietf.org Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option Date: Fri, 29 Oct 2004 12:43:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org A few questions on this draft: 1. The primary motivation seems to be 3GPP2's network, but fact of the matter is, 3GPP2 NAS (PDSN) does not push information received from a different domain into the DHCP server in the local domain. 2. The draft allows vendor specific RADIUS attributes to be pushed to the DHCP server potentially from different domains. How does the DHCP sever parse these vendor specific RADIUS attributes? Is it the assumption that the DHCP server needs to know possibly all vendor specific RADIUS attributes? This does not scale. 3. It says that the DHCP server uses this RADIUS info to do IP address allocation and other parameter allocation. It would be nice to know what other parameters the authors have in mind. Regards, Kuntal -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Wing Cheong Lau Sent: Monday, October 25, 2004 1:59 PM To: Bernie Volz; 'Wing Cheong Lau'; dhcwg@ietf.org Cc: Ted.Lemon@nominum.com; rdroms@cisco.com Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option At 10:11 AM 10/25/2004, Bernie Volz wrote: BTW, we don't need a DHCPv6 version of draft-ietf-dhc-vendor-suboption-00.txt because the existing DHCPv6 Vendor options can be used by the Relay Agent just fine. Again, it is WHERE these options appear that indicates whether they are for the client (in the client part of the message) or the relay, in the Relay-Forw or Relay-Reply part of the message. That work is already done and is not needed!! - Bernie I see. However, the use of such vendor-options by the Relay Agent is kind of hidden/missing from the current text of RFC 3315. For example, Sections 22.16 and 22.17 of RFC 3315 only describe the use of such vendor options by the client and the server. The use of these options by the relay agent are not mentioned at all. While it is true that the table in Appendix A of RFC3315 does say the possible inclusion of the vendor options in the Relay-Forward/Relay-Reply message, the table in Appendix B seems to imply otherwise: In the table in Appendix B, while there are "*"'s for the Relay-Message and Interface ID rows under the Relay Forw./Relay Replay columns, no "*"'s are found for the Vendor Class/Vendor Info rows for the Relay Forw./Relay Replay columns. I think if Relay agent is allowed to include those vendor options in the Relay Forw/Replay messages, just like it includes the Interface option, the rows for the Vendor options should look like the row of the Interface option. Am I missing something ? or did I misunderstand the entire meaning of the table in Appendix B ? Actually, what does the "Option Field" column in the table mean ? Also what's the "Note" below the table refers to ? Would you share more clarification/ insights on this ? Thanks a lot in advance. Regards, Wing _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 29 14:48:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23370; Fri, 29 Oct 2004 14:48:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNbkm-0007zu-2s; Fri, 29 Oct 2004 14:45:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNbeF-0003lI-0i for dhcwg@megatron.ietf.org; Fri, 29 Oct 2004 14:38:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22547 for ; Fri, 29 Oct 2004 14:38:49 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNbsY-0005Sj-MT for dhcwg@ietf.org; Fri, 29 Oct 2004 14:53:39 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9TIcFeD015573; Fri, 29 Oct 2004 11:38:15 -0700 (PDT) Received: from WLAU.qualcomm.com (wlau.qualcomm.com [129.46.74.167]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9TIcC9A024839; Fri, 29 Oct 2004 11:38:13 -0700 (PDT) Message-Id: <6.0.0.22.2.20041029110145.0480ccf0@qcmail1.qualcomm.com> X-Sender: wlau@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 29 Oct 2004 11:38:12 -0700 To: "Kuntal Chowdhury" From: Wing Cheong Lau Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option In-Reply-To: <591B780D9676844E8A704B5B013FFE92038DE042@zrc2hxm1.corp.nor tel.com> References: <591B780D9676844E8A704B5B013FFE92038DE042@zrc2hxm1.corp.nortel.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0609649224==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0609649224== Content-Type: multipart/alternative; boundary="=====================_479509037==.ALT" --=====================_479509037==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:43 AM 10/29/2004, you wrote: >A few questions on this draft: > >1. The primary motivation seems to be 3GPP2's network, but fact of the >matter is, 3GPP2 NAS (PDSN) does not push information received from a >different domain into the DHCP server in the local domain. Yes. That is the status quo. But the intent of the internet draft is to keep the possibility of such protocol support for roaming mobile scenario in the future. Of course, as clearly stated in the current draft regarding it's applicability and security implication need to be considered. In particular: "The scope of applicability of this specification is such that the NAS (which acts as a DHCP relay agent), any other participating DHCP relay agent, the DHCP server and DHCP client should be within the same administrative domain while the RADIUS service involved may span multiple administrative domains. See the Section 5 for details of security considerations when this specification is deployed with RADIUS service operating across multiple administrative domains. Global interoperability of this specification, across arbitrary administrative domains, is not supported. " and "The RADIUS protocol [6] was designed for intra-domain use, where the NAS, proxy, and home server exist within a single administrative domain, and proxies may be considered a trusted component. However, under roaming situation, the NAS, proxies, and home server will typically be managed by different administrative entities. As a result, inter-domain RADIUS operations are inherently required for roaming applications, and proxies cannot necessarily be trusted. Refer to Section 7 of RFC 2609 for a detailed security threat analysis, limitations and precautions of operating RADIUS in a inter- domain environment. In general, robust and secure operations of RADIUS across multiple administrative domains require pre-established agreement, mutual trust, and secure communications channel amongst all the participating domains." Inter-domain RADIUS operations have its well-known set of risks and limitations and any future applications of the proposed options in an cross-domain environment would be subjected to such considerations. >2. The draft allows vendor specific RADIUS attributes to be pushed to the >DHCP server potentially from different domains. How does the DHCP sever >parse these vendor specific RADIUS attributes? Is it the assumption that the >DHCP server needs to know possibly all vendor specific RADIUS attributes? >This does not scale. In general, as specified in the draft, the DHCP server "MAY" use the information carried in the proposed option as a HINT to make the subsequent assignment. If the DHCP server does not understand a particular vendor-specific option/VSA, it is free to ignore it when making its assignment. On the other hand, given a specific deployment environment, it is not unreasonable to assume the DHCP server would understand a particular set of vendor-specific, e.g. 3GPP2, RADIUS VSA's. After all, as stated in the applicability statement above, we are not talking about cross-domain RADIUS services over any arbitrary domain, but only over those which have some sort of pre-established roaming agreements. >3. It says that the DHCP server uses this RADIUS info to do IP address >allocation and other parameter allocation. It would be nice to know what >other parameters the authors have in mind. > >Regards, >Kuntal Parameters under considerations included Home Agent address, (for dynamic HA assignment), Home Address (HoA) and/or Home-link prefix, etc. In fact, my understanding is that, for a single domain environment, RADIUS 3GPP2 VSA's have already been defined for these set of parameters to enable MIP6 bootstrapping via RADIUS/DHCPv6 within a single domain. If the risks/limitations of cross-domain RADIUS service stated above are deemed to be acceptable, there is a possibility that such bootstrapping scheme can be extended across providers with pre-established roaming agreements. Regards, Wing --=====================_479509037==.ALT Content-Type: text/html; charset="us-ascii" At 09:43 AM 10/29/2004, you wrote:
A few questions on this draft:

1. The primary motivation seems to be 3GPP2's network, but fact of the
matter is, 3GPP2 NAS (PDSN) does not push information received from a
different domain into the DHCP server in the local domain.

Yes. That is the status quo. But the intent of the internet draft is to keep
the possibility of such protocol support for roaming mobile scenario in the future. 
Of course, as clearly stated in the current draft regarding it's applicability and
security implication need to be considered. In particular:

"The scope of applicability of this specification is such that the NAS
   (which acts as a DHCP relay agent), any other participating DHCP
   relay agent, the DHCP server and DHCP client should be within the
   same administrative domain while the RADIUS service involved may span
   multiple administrative domains. See the Section 5 for details of
   security considerations when this specification is deployed with
   RADIUS service operating across multiple administrative domains.
   Global interoperability of this specification, across arbitrary
   administrative domains, is not supported. "

and

"The RADIUS protocol [6] was designed for intra-domain use, where the
   NAS, proxy, and home server exist within a single administrative
   domain, and proxies may be considered a trusted component. However,
   under roaming situation, the NAS, proxies, and home server will
   typically be managed by different administrative entities. As a
   result, inter-domain RADIUS operations are inherently required for
   roaming applications, and proxies cannot necessarily be trusted. 
   Refer to Section 7 of RFC 2609 for a detailed security threat
   analysis, limitations and precautions of operating RADIUS in a inter-
   domain environment. In general, robust and secure operations of
   RADIUS across multiple administrative domains require pre-established
   agreement, mutual trust, and secure communications channel amongst
   all the participating domains."

Inter-domain RADIUS operations have its well-known
set of risks and limitations and any future applications of the proposed options
in an cross-domain environment would be subjected to such considerations. 



2. The draft allows vendor specific RADIUS attributes to be pushed to the
DHCP server potentially from different domains. How does the DHCP sever
parse these vendor specific RADIUS attributes? Is it the assumption that the
DHCP server needs to know possibly all vendor specific RADIUS attributes?
This does not scale.
In general, as specified in the draft, the DHCP server "MAY" use the information carried in the proposed option as a HINT to make the subsequent assignment. If  the DHCP server does not
understand a particular vendor-specific option/VSA, it is free to ignore it when making its
assignment. On the other hand, given a specific deployment environment, it is not unreasonable to
assume the DHCP server would understand a particular set of vendor-specific, e.g. 3GPP2, RADIUS VSA's. After all, as stated in the applicability statement above, we are not talking about cross-domain RADIUS services over any arbitrary domain, but only over those which have some sort of pre-established roaming agreements.


3. It says that the DHCP server uses this RADIUS info to do IP address
allocation and other parameter allocation. It would be nice to know what
other parameters the authors have in mind.

Regards,
Kuntal
Parameters under considerations included Home Agent address, (for dynamic HA assignment),
Home Address (HoA) and/or Home-link prefix, etc.

In fact, my understanding is that, for a single
domain environment, RADIUS 3GPP2 VSA's have already been defined for these set of
parameters to enable MIP6 bootstrapping  via RADIUS/DHCPv6 within a single domain.
 
If the risks/limitations of cross-domain RADIUS service stated above  are deemed to be acceptable,
there is a possibility that such bootstrapping scheme can be extended across providers with
pre-established roaming agreements.

Regards,

Wing --=====================_479509037==.ALT-- --===============0609649224== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0609649224==-- From dhcwg-bounces@ietf.org Fri Oct 29 14:59:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24157; Fri, 29 Oct 2004 14:59:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNbl6-0008FL-5O; Fri, 29 Oct 2004 14:45:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNbjf-00077a-61 for dhcwg@megatron.ietf.org; Fri, 29 Oct 2004 14:44:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22932 for ; Fri, 29 Oct 2004 14:44:25 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNbxy-0005Zf-QJ for dhcwg@ietf.org; Fri, 29 Oct 2004 14:59:15 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9TIhq915946; Fri, 29 Oct 2004 14:43:52 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Oct 2004 14:43:53 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92038DE221@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Ralph Droms Subject: RE: [dhcwg] BCMCS server option drafts Date: Fri, 29 Oct 2004 14:43:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d Cc: dhcwg@ietf.org, Bernie Volz X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hello Ralph, >The 3GPP2 standards bodies are free to define any syntax or >semantics for the 3GPP2 OPTION_VENDOR_OPTS. So, if 3GPP2 >coule require that a client sends a 3GPP2 OPTION_VENDOR_OPTS >request, which the server parses and responds with 3GPP2 >OPTION_VENDOR_OPTS containing information for the client. If I understand what your are saying, the semantics to request/respond vendor specific information should also be vendor specific. I guess this is well understood to the DHCP implementers. It was not clear to me when I read RFC 3115. The syntax of OPTION_VENDOR_OPTS is defined in 3315: " The encapsulated vendor-specific options field MUST be encoded as a sequence of code/length/value fields of identical format to the DHCP options field. The option codes are defined by the vendor identified in the enterprise-number field and are not managed by IANA. Each of the encapsulated options is formatted as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | opt-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . option-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " So, I don't understand your statement "3GPP2 is free to define the syntax of OPTION_VENDOR_OPTS". The syntax of OPTION_VENDOR_OPTS when it appears in a request message from the client is not clear. The suggested behavior of a 3GPP2 DHCP server sending all 3GPP2 specific information to the client (blindly) is not an ideal one. The approach where the client sends specific information request and the server returns the requested information only is a better one, IMHO. -Kuntal >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Friday, October 29, 2004 6:49 AM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH] >Cc: Bernie Volz; dhcwg@ietf.org >Subject: RE: [dhcwg] BCMCS server option drafts > > >Kuntal - in both DHCPv4 and DHCPv6, there are no required >semantic ties between the message from the client to the >server and the response from the server. That is, the client >is not required to include any option request information or >vendor identification (I'm using general terms rather than >specific options because of the differences between DHCPv4 and >DHCPv6) to cause the server to send certain options or >vendor-specific information back to the client. The server >uses any option request information or vendor identification >or vendor-specific information as input ("hints") to the rules >the server uses to send a response to the client. The server >is free to send information that has not been specifically >requested by the client, based on other information the server >gleans from the message it receives from the client. > >So, in the DHCPv6 case, the client is not required to send an >OPTION_ORO requesting OPTION_VENDOR_OPTS (although it may do >so) and the server, based on other information, is free to >send OPTION_VENDOR_OPTS. In a 3GPP2 deployment, if the DHCPv6 >server sees a request from a part of the network topology >known to be using 3GPP2, the server may assume that the device >sending the request is a 3GPP2 device and send 3GPP2 >OPTION_VENDOR_OPTS to that client. And, if, for some reason, >the client is not a 3GPP2 device, the client can simply ignore >the 3GPP2 OPTION_VENDOR_OPTS. > >The 3GPP2 standards bodies are free to define any syntax or >semantics for the 3GPP2 OPTION_VENDOR_OPTS. So, if 3GPP2 >coule require that a client sends a 3GPP2 OPTION_VENDOR_OPTS >request, which the server parses and responds with 3GPP2 >OPTION_VENDOR_OPTS containing information for the client. > > >- Ralph > > >At 03:08 PM 10/28/2004 -0400, Kuntal Chowdhury wrote: >>Hello Bernie, >> >>Thanks for the response. I guess what is not clear to me is >how a DHCP >>client requests vendor specific information from the DHCP server: >> >>" >>- A Client includes OPTION_VENDOR_CLASS to identify itself. >>- A Client MAY include OPTION_VENDOR_OPTS if it has vendor specific >>data (other than classing information) to communicate. >>- A Server includes OPTION_VENDOR_OPTS for matching >enterprise IDs (and >>class data, if appropriate). This is only REQUIRED if the ORO >includes >>the OPTION_VENDOR_OPTS code (the ORO doesn't say which >vendors; that is >>handled by OPTION_VENDOR_CLASS). " >> >>Second bullet seems to say that the DHCP client includes >>OPTION_VENDOR_OPTS to convey some vendor specific information to the >>DHCP server beside the vendor class info (which is in >>OPTION_VENDOR_CLASS). It does not state that OPTION_VENDOR_OPTS is >>included in a DHCP message (such as information >>request) to REQUEST for vendor specific info from the server. >It is true >>that opcode for OPTION_VENDOR_OPTS can be included in ORO, >but that won't >>necessarily indicate to the server which vendor specific >codes it needs to >>return to the client. Also, the format of the >OPTION_VENDOR_OPTS when it >>appears in the REQUEST message is unclear. >> >>A clear description of how to use OPTION_VENDOR_OPTS to >request vendor >>specific information (such as broadcast server address) will be >>required by SDOs such as 3GPP2. >> >>Regards, >>Kuntal >> >> >> >-----Original Message----- >> >From: Bernie Volz [mailto:volz@cisco.com] >> >Sent: Wednesday, October 27, 2004 8:34 PM >> >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 'Ralph Droms' >> >Cc: dhcwg@ietf.org >> >Subject: RE: [dhcwg] BCMCS server option drafts >> > >> > >> >Hi: >> > >> >I believe the original model was for OPTION_VENDOR_CLASS to be >> >similar to DHCPv4 Vendor class identifier option (option >60) and for >> >OPTION_VENDOR_OPTS to be similar to DHCPv4 Vendor Specific >> >Information (option 43). >> > >> >You might refer to draft-ietf-dhc-vendor-03.txt, while for >DHCPv4, it >> >does have some additional information about how the options >might be >> >used. That work is modeled on the DHCPv6 options. In >particular, see >> >section 4: >> > >> >4. Vendor-Identifying Vendor-Specific Information Option >> > >> > DHCP clients and servers may use this option to exchange vendor- >> > specific information. Either party may send this >option, as needed. >> > While a typical case might be for a client to send the >> > Vendor-Identifying Vendor Class option, to elicit a useful >> > Vendor-Identifying Vendor-Specific Information Option, >there is no >> > requirement for such a flow. >> > >> >It would be good to get general agreement on this as you're perhaps >> >the first user. And, it would be best to set a "standard" >for others >> >to follow. >> > >> >I kind of liked the DHCPv4 model, as it is much easier and >clearly to >> >understand (and implement for clients and servers): >> >- A Client includes OPTION_VENDOR_CLASS to identify itself. >> >- A Client MAY include OPTION_VENDOR_OPTS if it has vendor specific >> >data (other than classing information) to communicate. >> >- A Server includes OPTION_VENDOR_OPTS for matching enterprise IDs >> >(and class data, if appropriate). This is only REQUIRED if the ORO >> >includes the OPTION_VENDOR_OPTS code (the ORO doesn't say which >> >vendors; that is handled by OPTION_VENDOR_CLASS). >> >- I'm not sure why a server would ever need to include >> >OPTION_VENDOR_CLASS, though perhaps it could tell the client what >> >implementation the server is so that perhaps the client knows it >> >could use some extended capabilities? Or, the server could >send back >> >whatever the client sent to it? >> > >> >But, as draft-ietf-dhc-vendor-03.tx states, this is not the only >> >possible model. >> > >> >Note that in your case, I would assume that the OPTION_VENDOR_CLASS >> >would have your enterprise ID and some class information to >indicate >> >what capabilities the client supports (and therefore the server >> >should provide configuration for in the OPTION_VENDOR_OPTS). >> > >> >So, this is a good issue for the DHC WG to resolve and >clarify for a >> >future RFC 3315bis. >> > >> >- Bernie >> > >> >> -----Original Message----- >> >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> >> Behalf Of Kuntal Chowdhury >> >> Sent: Wednesday, October 27, 2004 4:33 PM >> >> To: Ralph Droms; volz@cisco.com >> >> Cc: dhcwg@ietf.org >> >> Subject: RE: [dhcwg] BCMCS server option drafts >> >> >> >> >> >> I have a few questions on the possible use of DHCPv6 >> >> OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS to request vendor >> >> specific info: >> >> >> >> 1. Since the enterprise number is included in OPTION_VENDOR_OPTS, >> >> will it suffice to use only this option in the >information request >> >> message from the DHCP client? Is the use of OPTION_VENDOR_CLASS >> >> mandatory while vendor specific options are requested? >> >> >> >> 2. Does the mere inclusion of OPTION_VENDOR_OPTS in the >information >> >> request message indicate to the DHCP server that the DHCP >client is >> >> requesting for some specific vendor specific options? >> >> >> >> 3. O-R-O has the format where each of requested option codes are >> >> listed in it. However, in OPTION_VENDOR_OPTS the encapsulated >> >> vendor-specific options field MUST be encoded as a sequence of >> >> code/length/value fields. What value does the DHCP client >use while >> >> requesting for a vendor specific option? >> >> >> >> These things are not clearly defined in RFC3315. >> >> >> >> Regards, >> >> Kuntal >> >> >> >> >-----Original Message----- >> >> >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >> >> >Behalf Of Ralph Droms >> >> >Sent: Wednesday, October 27, 2004 2:29 PM >> >> >To: dhcwg@ietf.org >> >> >Subject: RE: [dhcwg] BCMCS server option drafts >> >> > >> >> > >> >> > >> >> >What about the deployment issue? The 3GGP2 specification will be >> >> >ratified in November, with deployment following soon. Some >> >> >service providers already have DHCP servers in place that must be >> >updated for >> >> >any new options. The options defined in the current drafts can >> >> >likely be supported without code changes to existing servers, >> >> >allowing for faster deployment. Use of a VIVSO sub-option would >> >> >require code changes to existing servers. How long would >> >it take to >> >> >deploy DHCP server that can support VIVSO? >> >> > >> >> >BTW, we need more discussion of this issue *soon* due to >the time >> >> >constraints of the upcoming 3GPP2 standards process and >> >> >deployment. >> >> > >> >> >- Ralph >> >> > >> >> >At 04:12 PM 10/21/2004 -0400, Bernie Volz wrote: >> >> >>Personally, I'd like to see the DHCPv4 VIVSO get deployed >> >> and pushing >> >> >>these options to using it would be a step at making this >> >> >happen (as one >> >> >>would expect 3GPP2 vendors to have some significant >input to the >> >> >>decisions of DHCP server vendors). >> >> >> >> >> >>It also means that 3GPP2 is free to define other VIVSO >> >> options in the >> >> >>future within their own forum and need not go to the IETF >> >> >(and DHC WG). >> >> >>I suspect that this would provide much faster deployment >> >for them in >> >> >>the future. >> >> >> >> >> >>Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS >> >> >are already >> >> >>there for DHCPv6. >> >> >> >> >> >>BTW, 3GPP2 already has an enterprise-id number: >> >> >> >> >> >>5535 >> >> >> 3rd Generation Partnership Project 2 (3GPP2) >> >> >> Allen Long >> >> >> along@cisco.com >> >> >> >> >> >>So, they'd be good to go! >> >> >> >> >> >>- Bernie >> >> >> >> >> >> > -----Original Message----- >> >> >> > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] >> >> >> > On Behalf Of Ralph Droms >> >> >> > Sent: Thursday, October 21, 2004 2:35 PM >> >> >> > To: dhcwg@ietf.org >> >> >> > Subject: [dhcwg] BCMCS server option drafts >> >> >> > >> >> >> > >> >> >> > We need to have a short WG conversation about two options >> >> >that were >> >> >> > discussed at the WG meeting in San Diego. The >outcome of the >> >> >> > conversation will be to determine consensus about taking >> >> on these >> >> >> > two >> >> >> > drafts: >> >> >> > >> >> >> > draft-chowdhury-dhc-bcmcv4-option-01.txt >> >> >> > draft-chowdhury-dhc-bcmcv6-option-01.txt >> >> >> > >> >> >> > as dhc WG work items or recommending that 3GPP2 define >> >> >> > vendor-identifying vendor-specific option (VIVSO; option code >> >> >> > 125) sub-options to carry the information described in >> >> the drafts. >> >> >> > >> >> >> > If the WG consensus is to take on the drafts as WG >work items >> >> >> > drafts, are they acceptable as currently published? >> >> >> > >> >> >> > Because of the time constraints imposed by the 3GPP2 >> >> schedule, I'm >> >> >> > going to cut off discussion on this topic next Thursday, >> >> >10/28, and >> >> >> > determine WG consensus at that time. >> >> >> > >> >> >> > Here are some considerations for discussion: >> >> >> > >> >> >> > 3GPP2 has defined some vendor-specific sub-options, for >> >> >example, to >> >> >> > identify a MIP home agent for the DHCP client. >> >> >> > >> >> >> > A 3GPP2 client needs to specify to the DHCP server which >> >> >parameters >> >> >> > it needs - specifically, whether it needs to receive >the BCMCS >> >> >> > servers. If the current drafts are adopted, the client >> >> can simply >> >> >> > use the parameter request list option (option code >55) for the >> >> >> > request. If a VIVSO sub-option is used, 3GPP2 would >> >> also define a >> >> >> > parameter request list sub-option. >> >> >> > >> >> >> > There is a deployment issue, as some service providers >> >> >already have >> >> >> > DHCP servers in place that must be updated for any new >> >> >options. Is >> >> >> > it the case that the options defined in the current >> >drafts can be >> >> >> > supported without code changes to existing servers? Use >> >> >of a VIVSO >> >> >> > sub-option would require code changes to existing servers. >> >> > How long >> >> >> > would it take to deploy DHCP server that can support VIVSO. >> >> >> > >> >> >> > BCMCS may be adopted across multiple technologies, so the >> >> >options in >> >> >> > the current drafts would not be specific to 3GPP2. >> >However, the >> >> >> > BCMCS specification has not adopted by other standards, >> >> yet, so we >> >> >> > may need to define additional options for related >> >> services in the >> >> >> > future if those services are not interoperable with the >> >> >3GPP2 BCMCS >> >> >> > service. >> >> >> > >> >> >> > CableLabs has one option with sub-options (RFC 3495) >> >rather than >> >> >> > multiple options because: >> >> >> > * wanted to avoid exhaustion of DHCP option code space; >> >> >perhaps less >> >> >> > of an issue with option code reclassification >> >> >> > * would have used VIVSO if available >> >> >> > * use of VIVSO with sub-options would give 3GPP2 freedom >> >> >to define new >> >> >> > sub-options on demand >> >> >> > Do these considerations have an impact on our decision >> >> >about how to >> >> >> > proceed with the 3GPP2 options? >> >> >> > >> >> >> > - Ralph >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > dhcwg mailing list >> >> >> > dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg >> >> >> > >> >> > >> >> > >> >> >_______________________________________________ >> >> >dhcwg mailing list >> >> >dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg >> >> > >> >> > >> >> >> >> _______________________________________________ >> >> dhcwg mailing list >> >> dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg >> >> >> > >> > >> > >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 29 15:25:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27955; Fri, 29 Oct 2004 15:25:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcLN-0007Wn-8b; Fri, 29 Oct 2004 15:23:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNc3p-0006Wc-MB for dhcwg@megatron.ietf.org; Fri, 29 Oct 2004 15:05:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24679 for ; Fri, 29 Oct 2004 15:05:15 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNcI8-00064e-Vk for dhcwg@ietf.org; Fri, 29 Oct 2004 15:20:06 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9TJ4bI24640 for ; Fri, 29 Oct 2004 15:04:38 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Oct 2004 15:04:39 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92038DE296@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Wing Cheong Lau Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option Date: Fri, 29 Oct 2004 15:04:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I don't see the need for the following in the draft: 1. Reference to 3GPP2: because 3GPP2 does not use the scheme that you are proposing here. 2. Vendor specific attribute parsing requirement on the DHCP server: It does not scale. 3. The requirement of other parameter (non IP address) assignment by the DHCP server: because the examples you give viz. HA, HoA, Home Link prefix etc. are not something that the local domain (ASP) control as per MIP6. These are controlled by the Home/Serving MSP. -Kuntal -----Original Message----- From: Wing Cheong Lau [mailto:lau@qualcomm.com] Sent: Friday, October 29, 2004 1:38 PM To: Chowdhury, Kuntal [RICH1:2H18:EXCH] Cc: dhcwg@ietf.org Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option At 09:43 AM 10/29/2004, you wrote: A few questions on this draft: 1. The primary motivation seems to be 3GPP2's network, but fact of the matter is, 3GPP2 NAS (PDSN) does not push information received from a different domain into the DHCP server in the local domain. Yes. That is the status quo. But the intent of the internet draft is to keep the possibility of such protocol support for roaming mobile scenario in the future. Of course, as clearly stated in the current draft regarding it's applicability and security implication need to be considered. In particular: "The scope of applicability of this specification is such that the NAS (which acts as a DHCP relay agent), any other participating DHCP relay agent, the DHCP server and DHCP client should be within the same administrative domain while the RADIUS service involved may span multiple administrative domains. See the Section 5 for details of security considerations when this specification is deployed with RADIUS service operating across multiple administrative domains. Global interoperability of this specification, across arbitrary administrative domains, is not supported. " and "The RADIUS protocol [6] was designed for intra-domain use, where the NAS, proxy, and home server exist within a single administrative domain, and proxies may be considered a trusted component. However, under roaming situation, the NAS, proxies, and home server will typically be managed by different administrative entities. As a result, inter-domain RADIUS operations are inherently required for roaming applications, and proxies cannot necessarily be trusted. Refer to Section 7 of RFC 2609 for a detailed security threat analysis, limitations and precautions of operating RADIUS in a inter- domain environment. In general, robust and secure operations of RADIUS across multiple administrative domains require pre-established agreement, mutual trust, and secure communications channel amongst all the participating domains." Inter-domain RADIUS operations have its well-known set of risks and limitations and any future applications of the proposed options in an cross-domain environment would be subjected to such considerations. 2. The draft allows vendor specific RADIUS attributes to be pushed to the DHCP server potentially from different domains. How does the DHCP sever parse these vendor specific RADIUS attributes? Is it the assumption that the DHCP server needs to know possibly all vendor specific RADIUS attributes? This does not scale. In general, as specified in the draft, the DHCP server "MAY" use the information carried in the proposed option as a HINT to make the subsequent assignment. If the DHCP server does not understand a particular vendor-specific option/VSA, it is free to ignore it when making its assignment. On the other hand, given a specific deployment environment, it is not unreasonable to assume the DHCP server would understand a particular set of vendor-specific, e.g. 3GPP2, RADIUS VSA's. After all, as stated in the applicability statement above, we are not talking about cross-domain RADIUS services over any arbitrary domain, but only over those which have some sort of pre-established roaming agreements. 3. It says that the DHCP server uses this RADIUS info to do IP address allocation and other parameter allocation. It would be nice to know what other parameters the authors have in mind. Regards, Kuntal Parameters under considerations included Home Agent address, (for dynamic HA assignment), Home Address (HoA) and/or Home-link prefix, etc. In fact, my understanding is that, for a single domain environment, RADIUS 3GPP2 VSA's have already been defined for these set of parameters to enable MIP6 bootstrapping via RADIUS/DHCPv6 within a single domain. If the risks/limitations of cross-domain RADIUS service stated above are deemed to be acceptable, there is a possibility that such bootstrapping scheme can be extended across providers with pre-established roaming agreements. Regards, Wing _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 29 16:46:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09647; Fri, 29 Oct 2004 16:46:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcm1-0005Z1-RC; Fri, 29 Oct 2004 15:50:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNccB-0003wY-CM for dhcwg@megatron.ietf.org; Fri, 29 Oct 2004 15:40:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29240 for ; Fri, 29 Oct 2004 15:40:45 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNcqV-0006wd-I3 for dhcwg@ietf.org; Fri, 29 Oct 2004 15:55:36 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 29 Oct 2004 12:42:20 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i9TJeB81012220; Fri, 29 Oct 2004 12:40:12 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-75.cisco.com [10.86.240.75]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMR12342; Fri, 29 Oct 2004 15:40:09 -0400 (EDT) From: "Bernie Volz" To: "'Kuntal Chowdhury'" , "'Ralph Droms'" Subject: RE: [dhcwg] BCMCS server option drafts Date: Fri, 29 Oct 2004 15:40:09 -0400 Organization: Cisco Message-ID: <002f01c4bdef$19e70360$6701a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <591B780D9676844E8A704B5B013FFE92038DE221@zrc2hxm1.corp.nortel.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 08582f3b796126054df71137d5cb69f8 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I suspect Ralph meant that you're free to do whatever you want within = the bounds of the standard. This means you need to define 3GPP2 vendor = specific option codes, lengths, and contents. So, you might define the following 3GPP2 vendor-specific information = options that would be carried in the DHCPv6 OPTION_VENDOR_OPTS when the = enterprise ID is the 3GPP2 one: 1. 3GPP2_OPTION_ORO (=3D1). Same format as the ORO option, but carries = the 3GPP2 option numbers, not DHCPv6 ones. 2. 3GPP2_OPTION_BCMCS_SERVER_D (=3D2) (same format as in draft-chowdhury-dhc-bcmcv6-option-01.txt) 3. 3GPP2_OPTION_BCMCS_SERVER_A (=3D3) (same format as in draft-chowdhury-dhc-bcmcv6-option-01.txt) You can then have text that says "A server SHOULD return the 3GPP2 Vendor-Specific Options requested in the 3GPP2_OPTION_ORO option in a OPTION_VENDOR_OPTS with the 3GPP2 enterprise ID." A client would then send: OPTION_VENDOR_OPTS, length=3Dxx, data=3D<3ggp2 enterprise ID>, <3GPP2_OPTION_ORO>, , <3GPP2_OPTION_BCMCS_SERVER_D code>,<3GPP2_OPTION_BCMCS_SERVER_A code> The server would then respond with: OPTION_VENDOR_OPTS, length=3Dxx, data<3gpp2 enterprise ID>,=20 <3GPP2_OPTION_BCMCS_SERVER_D>, , <3GPP2_OPTION_BCMCS_SERVER_A>, , - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Kuntal Chowdhury > Sent: Friday, October 29, 2004 2:44 PM > To: Ralph Droms > Cc: dhcwg@ietf.org; Bernie Volz > Subject: RE: [dhcwg] BCMCS server option drafts >=20 >=20 > Hello Ralph, >=20 > >The 3GPP2 standards bodies are free to define any syntax or > >semantics for the 3GPP2 OPTION_VENDOR_OPTS. So, if 3GPP2=20 > >coule require that a client sends a 3GPP2 OPTION_VENDOR_OPTS=20 > >request, which the server parses and responds with 3GPP2=20 > >OPTION_VENDOR_OPTS containing information for the client. >=20 > If I understand what your are saying, the semantics to=20 > request/respond vendor specific information should also be=20 > vendor specific. I guess this is well understood to the DHCP=20 > implementers. It was not clear to me when I read RFC 3115. >=20 > The syntax of OPTION_VENDOR_OPTS is defined in 3315: >=20 > " > The encapsulated vendor-specific options field MUST be encoded as a > sequence of code/length/value fields of identical format=20 > to the DHCP > options field. The option codes are defined by the vendor=20 > identified > in the enterprise-number field and are not managed by=20 > IANA. Each of > the encapsulated options is formatted as follows: >=20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | opt-code | =20 > option-len | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . =20 > . > . option-data =20 > . > . =20 > . > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > " >=20 > So, I don't understand your statement "3GPP2 is free to=20 > define the syntax of OPTION_VENDOR_OPTS". The syntax of=20 > OPTION_VENDOR_OPTS when it appears in a request message from=20 > the client is not clear.=20 >=20 > The suggested behavior of a 3GPP2 DHCP server sending all=20 > 3GPP2 specific information to the client (blindly) is not an=20 > ideal one. The approach where the client sends specific=20 > information request and the server returns the requested=20 > information only is a better one, IMHO. >=20 > -Kuntal >=20 > >-----Original Message----- > >From: Ralph Droms [mailto:rdroms@cisco.com] > >Sent: Friday, October 29, 2004 6:49 AM > >To: Chowdhury, Kuntal [RICH1:2H18:EXCH] > >Cc: Bernie Volz; dhcwg@ietf.org > >Subject: RE: [dhcwg] BCMCS server option drafts > > > > > >Kuntal - in both DHCPv4 and DHCPv6, there are no required > >semantic ties between the message from the client to the=20 > >server and the response from the server. That is, the client=20 > >is not required to include any option request information or=20 > >vendor identification (I'm using general terms rather than=20 > >specific options because of the differences between DHCPv4 and=20 > >DHCPv6) to cause the server to send certain options or=20 > >vendor-specific information back to the client. The server=20 > >uses any option request information or vendor identification=20 > >or vendor-specific information as input ("hints") to the rules=20 > >the server uses to send a response to the client. The server=20 > >is free to send information that has not been specifically=20 > >requested by the client, based on other information the server=20 > >gleans from the message it receives from the client. > > > >So, in the DHCPv6 case, the client is not required to send an > >OPTION_ORO requesting OPTION_VENDOR_OPTS (although it may do=20 > >so) and the server, based on other information, is free to=20 > >send OPTION_VENDOR_OPTS. In a 3GPP2 deployment, if the DHCPv6=20 > >server sees a request from a part of the network topology=20 > >known to be using 3GPP2, the server may assume that the device=20 > >sending the request is a 3GPP2 device and send 3GPP2=20 > >OPTION_VENDOR_OPTS to that client. And, if, for some reason,=20 > >the client is not a 3GPP2 device, the client can simply ignore=20 > >the 3GPP2 OPTION_VENDOR_OPTS. > > > >The 3GPP2 standards bodies are free to define any syntax or > >semantics for the 3GPP2 OPTION_VENDOR_OPTS. So, if 3GPP2=20 > >coule require that a client sends a 3GPP2 OPTION_VENDOR_OPTS=20 > >request, which the server parses and responds with 3GPP2=20 > >OPTION_VENDOR_OPTS containing information for the client. > > > > > >- Ralph > > > > > >At 03:08 PM 10/28/2004 -0400, Kuntal Chowdhury wrote: > >>Hello Bernie, > >> > >>Thanks for the response. I guess what is not clear to me is > >how a DHCP > >>client requests vendor specific information from the DHCP server: > >> > >>" > >>- A Client includes OPTION_VENDOR_CLASS to identify itself. > >>- A Client MAY include OPTION_VENDOR_OPTS if it has vendor specific > >>data (other than classing information) to communicate. > >>- A Server includes OPTION_VENDOR_OPTS for matching=20 > >enterprise IDs (and > >>class data, if appropriate). This is only REQUIRED if the ORO > >includes > >>the OPTION_VENDOR_OPTS code (the ORO doesn't say which > >vendors; that is > >>handled by OPTION_VENDOR_CLASS). " > >> > >>Second bullet seems to say that the DHCP client includes > >>OPTION_VENDOR_OPTS to convey some vendor specific=20 > information to the=20 > >>DHCP server beside the vendor class info (which is in=20 > >>OPTION_VENDOR_CLASS). It does not state that OPTION_VENDOR_OPTS is=20 > >>included in a DHCP message (such as information > >>request) to REQUEST for vendor specific info from the server.=20 > >It is true > >>that opcode for OPTION_VENDOR_OPTS can be included in ORO, > >but that won't > >>necessarily indicate to the server which vendor specific > >codes it needs to > >>return to the client. Also, the format of the > >OPTION_VENDOR_OPTS when it > >>appears in the REQUEST message is unclear. > >> > >>A clear description of how to use OPTION_VENDOR_OPTS to > >request vendor > >>specific information (such as broadcast server address) will be > >>required by SDOs such as 3GPP2. > >> > >>Regards, > >>Kuntal > >> > >> > >> >-----Original Message----- > >> >From: Bernie Volz [mailto:volz@cisco.com] > >> >Sent: Wednesday, October 27, 2004 8:34 PM > >> >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 'Ralph Droms' > >> >Cc: dhcwg@ietf.org > >> >Subject: RE: [dhcwg] BCMCS server option drafts > >> > > >> > > >> >Hi: > >> > > >> >I believe the original model was for OPTION_VENDOR_CLASS to be > >> >similar to DHCPv4 Vendor class identifier option (option=20 > >60) and for > >> >OPTION_VENDOR_OPTS to be similar to DHCPv4 Vendor Specific > >> >Information (option 43). > >> > > >> >You might refer to draft-ietf-dhc-vendor-03.txt, while for > >DHCPv4, it > >> >does have some additional information about how the options > >might be > >> >used. That work is modeled on the DHCPv6 options. In > >particular, see > >> >section 4: > >> > > >> >4. Vendor-Identifying Vendor-Specific Information Option > >> > > >> > DHCP clients and servers may use this option to=20 > exchange vendor- > >> > specific information. Either party may send this > >option, as needed. > >> > While a typical case might be for a client to send the > >> > Vendor-Identifying Vendor Class option, to elicit a useful > >> > Vendor-Identifying Vendor-Specific Information Option, > >there is no > >> > requirement for such a flow. > >> > > >> >It would be good to get general agreement on this as=20 > you're perhaps > >> >the first user. And, it would be best to set a "standard"=20 > >for others > >> >to follow. > >> > > >> >I kind of liked the DHCPv4 model, as it is much easier and > >clearly to > >> >understand (and implement for clients and servers): > >> >- A Client includes OPTION_VENDOR_CLASS to identify itself. > >> >- A Client MAY include OPTION_VENDOR_OPTS if it has=20 > vendor specific > >> >data (other than classing information) to communicate. > >> >- A Server includes OPTION_VENDOR_OPTS for matching=20 > enterprise IDs=20 > >> >(and class data, if appropriate). This is only REQUIRED=20 > if the ORO=20 > >> >includes the OPTION_VENDOR_OPTS code (the ORO doesn't say which=20 > >> >vendors; that is handled by OPTION_VENDOR_CLASS). > >> >- I'm not sure why a server would ever need to include=20 > >> >OPTION_VENDOR_CLASS, though perhaps it could tell the client what=20 > >> >implementation the server is so that perhaps the client knows it=20 > >> >could use some extended capabilities? Or, the server could=20 > >send back > >> >whatever the client sent to it? > >> > > >> >But, as draft-ietf-dhc-vendor-03.tx states, this is not the only > >> >possible model. > >> > > >> >Note that in your case, I would assume that the=20 > OPTION_VENDOR_CLASS > >> >would have your enterprise ID and some class information to=20 > >indicate > >> >what capabilities the client supports (and therefore the server > >> >should provide configuration for in the OPTION_VENDOR_OPTS). > >> > > >> >So, this is a good issue for the DHC WG to resolve and > >clarify for a > >> >future RFC 3315bis. > >> > > >> >- Bernie > >> > > >> >> -----Original Message----- > >> >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On > >> >> Behalf Of Kuntal Chowdhury > >> >> Sent: Wednesday, October 27, 2004 4:33 PM > >> >> To: Ralph Droms; volz@cisco.com > >> >> Cc: dhcwg@ietf.org > >> >> Subject: RE: [dhcwg] BCMCS server option drafts > >> >> > >> >> > >> >> I have a few questions on the possible use of DHCPv6 > >> >> OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS to request vendor=20 > >> >> specific info: > >> >> > >> >> 1. Since the enterprise number is included in=20 > OPTION_VENDOR_OPTS, > >> >> will it suffice to use only this option in the=20 > >information request > >> >> message from the DHCP client? Is the use of OPTION_VENDOR_CLASS > >> >> mandatory while vendor specific options are requested? > >> >> > >> >> 2. Does the mere inclusion of OPTION_VENDOR_OPTS in the > >information > >> >> request message indicate to the DHCP server that the DHCP > >client is > >> >> requesting for some specific vendor specific options? > >> >> > >> >> 3. O-R-O has the format where each of requested option codes are > >> >> listed in it. However, in OPTION_VENDOR_OPTS the encapsulated=20 > >> >> vendor-specific options field MUST be encoded as a sequence of=20 > >> >> code/length/value fields. What value does the DHCP client=20 > >use while > >> >> requesting for a vendor specific option? > >> >> > >> >> These things are not clearly defined in RFC3315. > >> >> > >> >> Regards, > >> >> Kuntal > >> >> > >> >> >-----Original Message----- > >> >> >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On > >> >> >Behalf Of Ralph Droms > >> >> >Sent: Wednesday, October 27, 2004 2:29 PM > >> >> >To: dhcwg@ietf.org > >> >> >Subject: RE: [dhcwg] BCMCS server option drafts > >> >> > > >> >> > > >> >> > > >> >> >What about the deployment issue? The 3GGP2=20 > specification will be > >> >> >ratified in November, with deployment following soon. Some=20 > >> >> >service providers already have DHCP servers in place=20 > that must be > >> >updated for > >> >> >any new options. The options defined in the current drafts can > >> >> >likely be supported without code changes to existing servers,=20 > >> >> >allowing for faster deployment. Use of a VIVSO=20 > sub-option would=20 > >> >> >require code changes to existing servers. How long would > >> >it take to > >> >> >deploy DHCP server that can support VIVSO? > >> >> > > >> >> >BTW, we need more discussion of this issue *soon* due to > >the time > >> >> >constraints of the upcoming 3GPP2 standards process and > >> >> >deployment. > >> >> > > >> >> >- Ralph > >> >> > > >> >> >At 04:12 PM 10/21/2004 -0400, Bernie Volz wrote: > >> >> >>Personally, I'd like to see the DHCPv4 VIVSO get deployed > >> >> and pushing > >> >> >>these options to using it would be a step at making this > >> >> >happen (as one > >> >> >>would expect 3GPP2 vendors to have some significant > >input to the > >> >> >>decisions of DHCP server vendors). > >> >> >> > >> >> >>It also means that 3GPP2 is free to define other VIVSO > >> >> options in the > >> >> >>future within their own forum and need not go to the IETF > >> >> >(and DHC WG). > >> >> >>I suspect that this would provide much faster deployment > >> >for them in > >> >> >>the future. > >> >> >> > >> >> >>Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS > >> >> >are already > >> >> >>there for DHCPv6. > >> >> >> > >> >> >>BTW, 3GPP2 already has an enterprise-id number: > >> >> >> > >> >> >>5535 > >> >> >> 3rd Generation Partnership Project 2 (3GPP2) > >> >> >> Allen Long > >> >> >> along@cisco.com > >> >> >> > >> >> >>So, they'd be good to go! > >> >> >> > >> >> >>- Bernie > >> >> >> > >> >> >> > -----Original Message----- > >> >> >> > From: dhcwg-bounces@ietf.org=20 > [mailto:dhcwg-bounces@ietf.org] > >> >> >> > On Behalf Of Ralph Droms > >> >> >> > Sent: Thursday, October 21, 2004 2:35 PM > >> >> >> > To: dhcwg@ietf.org > >> >> >> > Subject: [dhcwg] BCMCS server option drafts > >> >> >> > > >> >> >> > > >> >> >> > We need to have a short WG conversation about two options > >> >> >that were > >> >> >> > discussed at the WG meeting in San Diego. The > >outcome of the > >> >> >> > conversation will be to determine consensus about taking > >> >> on these > >> >> >> > two > >> >> >> > drafts: > >> >> >> > > >> >> >> > draft-chowdhury-dhc-bcmcv4-option-01.txt > >> >> >> > draft-chowdhury-dhc-bcmcv6-option-01.txt > >> >> >> > > >> >> >> > as dhc WG work items or recommending that 3GPP2 define > >> >> >> > vendor-identifying vendor-specific option (VIVSO;=20 > option code > >> >> >> > 125) sub-options to carry the information described in > >> >> the drafts. > >> >> >> > > >> >> >> > If the WG consensus is to take on the drafts as WG > >work items > >> >> >> > drafts, are they acceptable as currently published? > >> >> >> > > >> >> >> > Because of the time constraints imposed by the 3GPP2 > >> >> schedule, I'm > >> >> >> > going to cut off discussion on this topic next Thursday, > >> >> >10/28, and > >> >> >> > determine WG consensus at that time. > >> >> >> > > >> >> >> > Here are some considerations for discussion: > >> >> >> > > >> >> >> > 3GPP2 has defined some vendor-specific sub-options, for > >> >> >example, to > >> >> >> > identify a MIP home agent for the DHCP client. > >> >> >> > > >> >> >> > A 3GPP2 client needs to specify to the DHCP server which > >> >> >parameters > >> >> >> > it needs - specifically, whether it needs to receive > >the BCMCS > >> >> >> > servers. If the current drafts are adopted, the client > >> >> can simply > >> >> >> > use the parameter request list option (option code > >55) for the > >> >> >> > request. If a VIVSO sub-option is used, 3GPP2 would > >> >> also define a > >> >> >> > parameter request list sub-option. > >> >> >> > > >> >> >> > There is a deployment issue, as some service providers > >> >> >already have > >> >> >> > DHCP servers in place that must be updated for any new > >> >> >options. Is > >> >> >> > it the case that the options defined in the current > >> >drafts can be > >> >> >> > supported without code changes to existing servers? Use > >> >> >of a VIVSO > >> >> >> > sub-option would require code changes to existing servers. > >> >> > How long > >> >> >> > would it take to deploy DHCP server that can support VIVSO. > >> >> >> > > >> >> >> > BCMCS may be adopted across multiple technologies, so the > >> >> >options in > >> >> >> > the current drafts would not be specific to 3GPP2. > >> >However, the > >> >> >> > BCMCS specification has not adopted by other standards, > >> >> yet, so we > >> >> >> > may need to define additional options for related > >> >> services in the > >> >> >> > future if those services are not interoperable with the > >> >> >3GPP2 BCMCS > >> >> >> > service. > >> >> >> > > >> >> >> > CableLabs has one option with sub-options (RFC 3495) > >> >rather than > >> >> >> > multiple options because: > >> >> >> > * wanted to avoid exhaustion of DHCP option code space; > >> >> >perhaps less > >> >> >> > of an issue with option code reclassification > >> >> >> > * would have used VIVSO if available > >> >> >> > * use of VIVSO with sub-options would give 3GPP2 freedom > >> >> >to define new > >> >> >> > sub-options on demand > >> >> >> > Do these considerations have an impact on our decision > >> >> >about how to > >> >> >> > proceed with the 3GPP2 options? > >> >> >> > > >> >> >> > - Ralph > >> >> >> > > >> >> >> > > >> >> >> > _______________________________________________ > >> >> >> > dhcwg mailing list > >> >> >> > dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg > >> >> >> > > >> >> > > >> >> > > >> >> >_______________________________________________ > >> >> >dhcwg mailing list > >> >> >dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg > >> >> > > >> >> > > >> >> > >> >> _______________________________________________ > >> >> dhcwg mailing list > >> >> dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg > >> >> > >> > > >> > > >> > > >> > >>_______________________________________________ > >>dhcwg mailing list > >>dhcwg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 29 16:47:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09932; Fri, 29 Oct 2004 16:47:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcm6-0005br-VO; Fri, 29 Oct 2004 15:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcgB-00075G-3v for dhcwg@megatron.ietf.org; Fri, 29 Oct 2004 15:44:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29565 for ; Fri, 29 Oct 2004 15:44:52 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNcuV-00070j-LN for dhcwg@ietf.org; Fri, 29 Oct 2004 15:59:44 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9TJiKhP028004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Oct 2004 12:44:21 -0700 (PDT) Received: from WLAU.qualcomm.com (wlau.qualcomm.com [129.46.74.167]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9TJiI9A014934; Fri, 29 Oct 2004 12:44:18 -0700 (PDT) Message-Id: <6.0.0.22.2.20041029121509.044f45e0@qcmail1.qualcomm.com> X-Sender: wlau@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 29 Oct 2004 12:44:17 -0700 To: "Kuntal Chowdhury" , Wing Cheong Lau From: Wing Cheong Lau Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and RADIUS Attributes sub-option In-Reply-To: <591B780D9676844E8A704B5B013FFE92038DE296@zrc2hxm1.corp.nor tel.com> References: <591B780D9676844E8A704B5B013FFE92038DE296@zrc2hxm1.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Dear Kuntal, Thank you for your comments. My response is interlaced below: At 12:04 PM 10/29/2004, Kuntal Chowdhury wrote: >I don't see the need for the following in the draft: > >1. Reference to 3GPP2: because 3GPP2 does not use the scheme that you are >proposing here. I disagree. At a minimum, the proposed option will benefit 3GPP2 in the case where the RADIUS and DHCP service are all under the same domain. In particular, the current way (835D) 3GPP2 uses RADIUS/DHCPv6. for doing MIP6 bootstrapping requires the PDSN to act as a DHCPv6 server (to answer stateless request for HA/HoA/HL info). On the other hand, there are also additional needs in 3GPP2 where the PDSN has to act as a relay-agent instead. Such dual role of PDSN is unnecessary and not desirable because it forces the Mobile to issue multiple separate requests for different set of parameters, to be answered by different DHCP servers. With the proposed option, the PDSN only needs to be serve as a relay-agent, and the mobile do not need to issue separate requests the different parameters it requests. >2. Vendor specific attribute parsing requirement on the DHCP server: It does >not scale. I do not see your point. It option is used as a "hint", if the DHCP server does not understand a specific vendor attribute, it can just ignore it while making it's assignment. What's the scalability issue here ? >3. The requirement of other parameter (non IP address) assignment by the >DHCP server: because the examples you give viz. HA, HoA, Home Link prefix >etc. are not something that the local domain (ASP) control as per MIP6. >These are controlled by the Home/Serving MSP. Sorry, I do not get your point. If the proposed option is deemed to be useful for a cross-domain RADIUS envirnoment, then, the HA/HoA/Home-link prefix, will be coming from the Home MSP, via RADIUS 3GPP VSA's, while the DHCPv6 relay-agent (PDSN) and the corresponding DHCPv6 server is under the control of the local domain ASP. This does not contradict your statement above. I do agree that it is valid to debate whether one should allow the Home MSP to push HA/HoA/HL info to its own DHCPv6 server. But regardless of the answer to this question, as I explain above, the proposed option do have value for the single-domain case where the RADIUS service and the DHCP servers/relay-agents are belonging to the same domain. Regards, Wing >-Kuntal > > >-----Original Message----- >From: Wing Cheong Lau [mailto:lau@qualcomm.com] >Sent: Friday, October 29, 2004 1:38 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH] >Cc: dhcwg@ietf.org >Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option and >RADIUS Attributes sub-option > > >At 09:43 AM 10/29/2004, you wrote: > >A few questions on this draft: > >1. The primary motivation seems to be 3GPP2's network, but fact of the >matter is, 3GPP2 NAS (PDSN) does not push information received from a >different domain into the DHCP server in the local domain. > >Yes. That is the status quo. But the intent of the internet draft is to keep > >the possibility of such protocol support for roaming mobile scenario in the >future. >Of course, as clearly stated in the current draft regarding it's >applicability and >security implication need to be considered. In particular: > >"The scope of applicability of this specification is such that the NAS > (which acts as a DHCP relay agent), any other participating DHCP > relay agent, the DHCP server and DHCP client should be within the > same administrative domain while the RADIUS service involved may span > multiple administrative domains. See the Section 5 for details of > security considerations when this specification is deployed with > RADIUS service operating across multiple administrative domains. > Global interoperability of this specification, across arbitrary > administrative domains, is not supported. " > >and > >"The RADIUS protocol [6] was designed for intra-domain use, where the > NAS, proxy, and home server exist within a single administrative > domain, and proxies may be considered a trusted component. However, > under roaming situation, the NAS, proxies, and home server will > typically be managed by different administrative entities. As a > result, inter-domain RADIUS operations are inherently required for > roaming applications, and proxies cannot necessarily be trusted. > Refer to Section 7 of RFC 2609 for a detailed security threat > analysis, limitations and precautions of operating RADIUS in a inter- > domain environment. In general, robust and secure operations of > RADIUS across multiple administrative domains require pre-established > agreement, mutual trust, and secure communications channel amongst > all the participating domains." > >Inter-domain RADIUS operations have its well-known >set of risks and limitations and any future applications of the proposed >options >in an cross-domain environment would be subjected to such considerations. > > > > >2. The draft allows vendor specific RADIUS attributes to be pushed to the >DHCP server potentially from different domains. How does the DHCP sever >parse these vendor specific RADIUS attributes? Is it the assumption that the >DHCP server needs to know possibly all vendor specific RADIUS attributes? >This does not scale. > >In general, as specified in the draft, the DHCP server "MAY" use the >information carried in the proposed option as a HINT to make the subsequent >assignment. If the DHCP server does not >understand a particular vendor-specific option/VSA, it is free to ignore it >when making its >assignment. On the other hand, given a specific deployment environment, it >is not unreasonable to >assume the DHCP server would understand a particular set of vendor-specific, >e.g. 3GPP2, RADIUS VSA's. After all, as stated in the applicability >statement above, we are not talking about cross-domain RADIUS services over >any arbitrary domain, but only over those which have some sort of >pre-established roaming agreements. > > > >3. It says that the DHCP server uses this RADIUS info to do IP address >allocation and other parameter allocation. It would be nice to know what >other parameters the authors have in mind. > >Regards, >Kuntal > >Parameters under considerations included Home Agent address, (for dynamic HA >assignment), >Home Address (HoA) and/or Home-link prefix, etc. > >In fact, my understanding is that, for a single >domain environment, RADIUS 3GPP2 VSA's have already been defined for these >set of >parameters to enable MIP6 bootstrapping via RADIUS/DHCPv6 within a single >domain. > >If the risks/limitations of cross-domain RADIUS service stated above are >deemed to be acceptable, >there is a possibility that such bootstrapping scheme can be extended across >providers with >pre-established roaming agreements. > >Regards, > >Wing _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 29 17:47:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17325; Fri, 29 Oct 2004 17:47:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNeDk-0000pH-LH; Fri, 29 Oct 2004 17:23:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNdlk-0005Ga-Hq for dhcwg@megatron.ietf.org; Fri, 29 Oct 2004 16:54:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10952 for ; Fri, 29 Oct 2004 16:54:42 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNe06-0001o1-8w for dhcwg@ietf.org; Fri, 29 Oct 2004 17:09:34 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9TKsBE07036 for ; Fri, 29 Oct 2004 16:54:11 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Oct 2004 16:54:11 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92038DE51E@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Wing Cheong Lau Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option an d RADIUS Attributes sub-option Date: Fri, 29 Oct 2004 16:54:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The intent in your draft i.e. configure MN with HA/HoA/HL information can be achieved with: http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-mip6-agentop-00.txt Unlike your draft this draft: 1. Does not require the DHCP server to parse vendor-specific RADIUS attributes. 2. Has no interdomain (ASP-MSP) tight coupling assumption. 3. Provides integrity and authenticity of the information that is exchanged. 4. It is AAA protocol agnostic, i.e. works for both RADIUS and DIAMETER. 5. Does not assume a 3GPP2 centric architecture. It is generic. Regards, Kuntal >-----Original Message----- >From: Wing Cheong Lau [mailto:lau@qualcomm.com] >Sent: Friday, October 29, 2004 2:44 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Wing Cheong Lau >Cc: dhcwg@ietf.org >Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information >Option and RADIUS Attributes sub-option > > >Dear Kuntal, > >Thank you for your comments. My response is interlaced below: > >At 12:04 PM 10/29/2004, Kuntal Chowdhury wrote: >>I don't see the need for the following in the draft: >> >>1. Reference to 3GPP2: because 3GPP2 does not use the scheme that you >>are proposing here. > >I disagree. At a minimum, the proposed option will benefit >3GPP2 in the >case where the RADIUS and DHCP service are all under the same >domain. In particular, the current way (835D) 3GPP2 uses >RADIUS/DHCPv6. for doing MIP6 bootstrapping requires the PDSN >to act as a DHCPv6 server >(to answer stateless >request for HA/HoA/HL info). On the other hand, there are also >additional >needs in 3GPP2 where the PDSN has to act as a relay-agent >instead. Such >dual role of PDSN is unnecessary and not desirable >because it forces the Mobile to issue multiple separate requests for >different set of parameters, to be answered by different DHCP servers. > >With the proposed option, the PDSN only needs to be serve as a >relay-agent, >and the mobile do not >need to issue separate requests the different parameters it requests. > >>2. Vendor specific attribute parsing requirement on the DHCP >server: It >>does not scale. >I do not see your point. It option is used as a "hint", if the >DHCP server >does not understand a specific >vendor attribute, it can just ignore it while making it's assignment. >What's the scalability issue here ? > >>3. The requirement of other parameter (non IP address) assignment by >>the DHCP server: because the examples you give viz. HA, HoA, >Home Link >>prefix etc. are not something that the local domain (ASP) control as >>per MIP6. These are controlled by the Home/Serving MSP. > >Sorry, I do not get your point. If the proposed option is deemed to be >useful for a cross-domain >RADIUS envirnoment, then, the HA/HoA/Home-link prefix, will be >coming from >the Home MSP, >via RADIUS 3GPP VSA's, while the DHCPv6 relay-agent (PDSN) and the >corresponding DHCPv6 server is under the control of the local >domain ASP. >This does not contradict your statement above. > >I do agree that it is valid to debate whether one should allow >the Home MSP >to push HA/HoA/HL info to its own DHCPv6 server. But regardless of the >answer to this question, as I explain above, the proposed >option do have >value for the single-domain case where the RADIUS service and >the DHCP servers/relay-agents are belonging to the same domain. > >Regards, > >Wing > > > > > > > >>-Kuntal >> >> >>-----Original Message----- >>From: Wing Cheong Lau [mailto:lau@qualcomm.com] >>Sent: Friday, October 29, 2004 1:38 PM >>To: Chowdhury, Kuntal [RICH1:2H18:EXCH] >>Cc: dhcwg@ietf.org >>Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option >>and RADIUS Attributes sub-option >> >> >>At 09:43 AM 10/29/2004, you wrote: >> >>A few questions on this draft: >> >>1. The primary motivation seems to be 3GPP2's network, but >fact of the >>matter is, 3GPP2 NAS (PDSN) does not push information received from a >>different domain into the DHCP server in the local domain. >> >>Yes. That is the status quo. But the intent of the internet >draft is to >>keep >> >>the possibility of such protocol support for roaming mobile >scenario in >>the future. Of course, as clearly stated in the current draft >regarding >>it's applicability and >>security implication need to be considered. In particular: >> >>"The scope of applicability of this specification is such that the NAS >> (which acts as a DHCP relay agent), any other participating DHCP >> relay agent, the DHCP server and DHCP client should be within the >> same administrative domain while the RADIUS service >involved may span >> multiple administrative domains. See the Section 5 for details of >> security considerations when this specification is deployed with >> RADIUS service operating across multiple administrative domains. >> Global interoperability of this specification, across arbitrary >> administrative domains, is not supported. " >> >>and >> >>"The RADIUS protocol [6] was designed for intra-domain use, where the >> NAS, proxy, and home server exist within a single administrative >> domain, and proxies may be considered a trusted >component. However, >> under roaming situation, the NAS, proxies, and home server will >> typically be managed by different administrative entities. As a >> result, inter-domain RADIUS operations are inherently required for >> roaming applications, and proxies cannot necessarily be trusted. >> Refer to Section 7 of RFC 2609 for a detailed security threat >> analysis, limitations and precautions of operating RADIUS >in a inter- >> domain environment. In general, robust and secure operations of >> RADIUS across multiple administrative domains require >pre-established >> agreement, mutual trust, and secure communications channel amongst >> all the participating domains." >> >>Inter-domain RADIUS operations have its well-known >>set of risks and limitations and any future applications of the >>proposed options in an cross-domain environment would be subjected to >>such considerations. >> >> >> >> >>2. The draft allows vendor specific RADIUS attributes to be pushed to >>the DHCP server potentially from different domains. How does the DHCP >>sever parse these vendor specific RADIUS attributes? Is it the >>assumption that the DHCP server needs to know possibly all vendor >>specific RADIUS attributes? This does not scale. >> >>In general, as specified in the draft, the DHCP server "MAY" use the >>information carried in the proposed option as a HINT to make the >>subsequent assignment. If the DHCP server does not understand a >>particular vendor-specific option/VSA, it is free to ignore it when >>making its assignment. On the other hand, given a specific deployment >>environment, it is not unreasonable to >>assume the DHCP server would understand a particular set of >vendor-specific, >>e.g. 3GPP2, RADIUS VSA's. After all, as stated in the applicability >>statement above, we are not talking about cross-domain RADIUS >services over >>any arbitrary domain, but only over those which have some sort of >>pre-established roaming agreements. >> >> >> >>3. It says that the DHCP server uses this RADIUS info to do >IP address >>allocation and other parameter allocation. It would be nice to know >>what other parameters the authors have in mind. >> >>Regards, >>Kuntal >> >>Parameters under considerations included Home Agent address, (for >>dynamic HA assignment), Home Address (HoA) and/or Home-link prefix, >>etc. >> >>In fact, my understanding is that, for a single >>domain environment, RADIUS 3GPP2 VSA's have already been defined for >>these set of parameters to enable MIP6 bootstrapping via >RADIUS/DHCPv6 >>within a single domain. >> >>If the risks/limitations of cross-domain RADIUS service stated above >>are deemed to be acceptable, there is a possibility that such >>bootstrapping scheme can be extended across providers with >>pre-established roaming agreements. >> >>Regards, >> >>Wing > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Oct 29 18:30:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21630; Fri, 29 Oct 2004 18:30:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNf9Q-0005KF-Bf; Fri, 29 Oct 2004 18:23:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNetO-0001SO-NV for dhcwg@megatron.ietf.org; Fri, 29 Oct 2004 18:06:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19448 for ; Fri, 29 Oct 2004 18:06:40 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNf7k-0003yP-Ug for dhcwg@ietf.org; Fri, 29 Oct 2004 18:21:33 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9TM68hP009487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Oct 2004 15:06:09 -0700 (PDT) Received: from WLAU.qualcomm.com (wlau.qualcomm.com [129.46.74.167]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9TM65HJ019518; Fri, 29 Oct 2004 15:06:06 -0700 (PDT) Message-Id: <6.0.0.22.2.20041029135901.0454ec30@qcmail1.qualcomm.com> X-Sender: wlau@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 29 Oct 2004 15:06:05 -0700 To: "Kuntal Chowdhury" , Wing Cheong Lau From: Wing Cheong Lau Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option an d RADIUS Attributes sub-option In-Reply-To: <591B780D9676844E8A704B5B013FFE92038DE51E@zrc2hxm1.corp.nor tel.com> References: <591B780D9676844E8A704B5B013FFE92038DE51E@zrc2hxm1.corp.nortel.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0757723456==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============0757723456== Content-Type: multipart/alternative; boundary="=====================_491981712==.ALT" --=====================_491981712==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Kuntal, At 01:54 PM 10/29/2004, Kuntal Chowdhury wrote: >The intent in your draft i.e. configure MN with HA/HoA/HL information can be >achieved with: > >http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-mip6-agentop-00.txt Thanks for bringing to our attention the existence of this new draft. Somehow, I have not seen its announcement before, at least not in the dhc or mip6 mailing list. >Unlike your draft this draft: > >1. Does not require the DHCP server to parse vendor-specific RADIUS >attributes. But it requires the DHCP relay-agent to parse and understand the newly defined, yet-to-be standardized RADIUS Attributes carrying HA/HoA/Home-link-prefix as described in draft-chowdhury-mip6-bootstrap-radius-00.txt and similar yet-to-be defined attributes if DIAMETER is used. >2. Has no interdomain (ASP-MSP) tight coupling assumption. >3. Provides integrity and authenticity of the information that is exchanged. >4. It is AAA protocol agnostic, i.e. works for both RADIUS and DIAMETER. >5. Does not assume a 3GPP2 centric architecture. It is generic. >Regards, >Kuntal I just did a quick pass thru it but did not find any description addressing the issue where the NAS/DHCP relay-agent and the AAA belongs to a different domain and RADIUS is used as the AAA protocol. (This is precisely the same issue you raised for the DHCPv6 Relay Information Option/RADIUS Attributes sub-option draft.). So, would you point to the specific text in the draft which substantiates your claims 2) and 4) simultaneously ? Currently, the draft just conveniently states: "The AAA procedures using RADIUS is defined in [MIP6-RADIUS]", but [MIP6-RADIUS] Chowdhury et. al., K., "RADIUS Attributes for Mobile IPv6 bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 (work in progress), July 2004. cannot be found in public (I meant -01 version cannot be found, only -00 is available). On the other hand, I cannot see how the cross-domain scenario described in -00 version of draft-chowdhury-mip6-bootstrap-radius the draftis different than the one in draft-droms-dhc-v6-relayopt-00.txt. Am I missing something here ? I would also like to point out that the DHCPv6 Relay Info Option/ RADIUS Attribute sub-option actually addresses 2 level of needs: 1. The ability of DHCPv6 Relay agent to tag along additional "info" as it forwards requests from the DHCP client to the DHCP server, regardless of the specific nature of the "info". This is a "general" capability for the DHCPv6 Relay agent which is absent from the RFC 3315. It seems like both your and our draft needs such capability. The main difference is that, in draft-chowdhury-dhc-mip6-agentop-00.txt, newly defined MIP6-bootstrapping options are relayed while in draft-droms-dhc-v6-relayopt-00.txt, the info got relayed are RADIUS attributes. 2. As for the relay-agent RADIUS option, it is a feature of its own right, the example given in our draft is just one of its use which can help address an immediate issue in 3GPP2 835D. 3. As stated in draft-droms-dhc-v6-relayopt-00.txt, " This document uses 3GPP2 access authentication as an example to motivate the use of the Relay Agent Information option and the RADIUS Attributes sub-option by a NAS. The Relay Agent Information option is not limited to use in conjunction with RADIUS sub-option when other sub-options are defined in the future. The RADIUS Attributes sub- option for the Relay Agent Information option described in this document is not limited to use in conjunction with 3GPP2 and can be used to carry RADIUS attributes obtained by the relay agent for any reason. That is, the sub-option is not limited to use with 3GPP2, but is constrained by RADIUS semantics." Regards, Wing --=====================_491981712==.ALT Content-Type: text/html; charset="us-ascii" Kuntal,

At 01:54 PM 10/29/2004, Kuntal Chowdhury wrote:
The intent in your draft i.e. configure MN with HA/HoA/HL information can be
achieved with:

http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-mip6-agentop-00.txt

Thanks for bringing to our attention the existence of this new draft. Somehow, I have not seen
its announcement before, at least not in the dhc or mip6 mailing list.

Unlike your draft this draft:

1. Does not require the DHCP server to parse vendor-specific RADIUS
attributes.

But it requires the DHCP relay-agent to parse and understand the newly defined, yet-to-be standardized RADIUS Attributes carrying HA/HoA/Home-link-prefix as described in 
draft-chowdhury-mip6-bootstrap-radius-00.txt and similar yet-to-be
defined attributes if DIAMETER is used.
2. Has no interdomain (ASP-MSP) tight coupling assumption.
3. Provides integrity and authenticity of the information that is exchanged.
4. It is AAA protocol agnostic, i.e. works for both RADIUS and DIAMETER.
5. Does not assume a 3GPP2 centric architecture. It is generic.


Regards,
Kuntal


I just did a quick pass thru it but did not find any description addressing the issue where
the NAS/DHCP relay-agent and the AAA belongs to a different domain and RADIUS is used as
the AAA protocol. (This is precisely the same issue you raised for the DHCPv6 Relay Information Option/RADIUS Attributes sub-option draft.). So, would you point to the specific text in the draft which substantiates your claims 2) and 4) simultaneously ? 

Currently, the draft just conveniently states:
"The AAA procedures using RADIUS is defined in [MIP6-RADIUS]",
but

   [MIP6-RADIUS]
             
Chowdhury et. al., K., "RADIUS Attributes for Mobile IPv6
             
bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01
             
(work in progress), July 2004.
cannot be found in public (I meant -01 version cannot be found, only -00 is available).
On the other hand, I cannot see how the cross-domain scenario described in  -00 version of  
draft-chowdhury-mip6-bootstrap-radius
the draftis different than the one in draft-droms-dhc-v6-relayopt-00.txt.

Am I missing something here ?


I would also like to point out that the DHCPv6 Relay Info Option/ RADIUS Attribute sub-option actually addresses 2 level of  needs:

1. The ability of DHCPv6 Relay agent to tag along additional "info" as it forwards requests from the DHCP client to the DHCP server, regardless of the specific nature of the "info". This is a "general"
capability for the DHCPv6 Relay agent which is absent from the RFC 3315. It seems like both your
and our draft needs such capability. The main difference is that, in draft-chowdhury-dhc-mip6-agentop-00.txt, newly defined MIP6-bootstrapping options are relayed while in draft-droms-dhc-v6-relayopt-00.txt, the info got relayed are RADIUS attributes.


2. As for the relay-agent RADIUS option, it is a feature of its own right, the example given in our draft is just one of its use which can help address an immediate issue in 3GPP2 835D.


3. As stated in draft-droms-dhc-v6-relayopt-00.txt,
" This document uses 3GPP2 access authentication as an example to
   motivate the use of the Relay Agent Information option and the RADIUS
   Attributes sub-option by a NAS. The Relay Agent Information option is
   not limited to use in conjunction with RADIUS sub-option when other
   sub-options are defined in the future. The RADIUS Attributes sub-
   option for the Relay Agent Information option described in this
   document is not limited to use in conjunction with 3GPP2 and can be
   used to carry RADIUS attributes obtained by the relay agent for any
   reason.  That is, the sub-option is not limited to use with 3GPP2,
   but is constrained by RADIUS semantics."


Regards,

Wing --=====================_491981712==.ALT-- --===============0757723456== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0757723456==-- From dhcwg-bounces@ietf.org Fri Oct 29 18:54:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23183; Fri, 29 Oct 2004 18:54:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNfZD-0004hd-KS; Fri, 29 Oct 2004 18:49:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNfOZ-0004GT-59 for dhcwg@megatron.ietf.org; Fri, 29 Oct 2004 18:38:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22291 for ; Fri, 29 Oct 2004 18:38:52 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNfcv-0004Y7-Lb for dhcwg@ietf.org; Fri, 29 Oct 2004 18:53:46 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9TMcMX25964 for ; Fri, 29 Oct 2004 18:38:22 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Oct 2004 18:38:22 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92038DE6C9@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Wing Cheong Lau Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option a n d RADIUS Attributes sub-option Date: Fri, 29 Oct 2004 18:38:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org draft-chowdhury-mip6-bootstrap-radius-01.txt is not publicly available yet because I submitted -01 version after the 25th Nov cutoff date. It will be available after Nov 7th when the new submission gate opens. If you need, I can send you a copy. BTW, the DHCP relay does not do AAA AVP parsing. The NAS which is collocated with the DHCP relay does the parsing. Don't you think AAA AVP parsing is in the job description of a NAS? -Kuntal -----Original Message----- From: Wing Cheong Lau [mailto:lau@qualcomm.com] Sent: Friday, October 29, 2004 5:06 PM To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Wing Cheong Lau Cc: dhcwg@ietf.org Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option an d RADIUS Attributes sub-option Kuntal, At 01:54 PM 10/29/2004, Kuntal Chowdhury wrote: The intent in your draft i.e. configure MN with HA/HoA/HL information can be achieved with: http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-mip6-agentop-00.txt Thanks for bringing to our attention the existence of this new draft. Somehow, I have not seen its announcement before, at least not in the dhc or mip6 mailing list. Unlike your draft this draft: 1. Does not require the DHCP server to parse vendor-specific RADIUS attributes. But it requires the DHCP relay-agent to parse and understand the newly defined, yet-to-be standardized RADIUS Attributes carrying HA/HoA/Home-link-prefix as described in draft-chowdhury-mip6-bootstrap-radius-00.txt and similar yet-to-be defined attributes if DIAMETER is used. 2. Has no interdomain (ASP-MSP) tight coupling assumption. 3. Provides integrity and authenticity of the information that is exchanged. 4. It is AAA protocol agnostic, i.e. works for both RADIUS and DIAMETER. 5. Does not assume a 3GPP2 centric architecture. It is generic. Regards, Kuntal I just did a quick pass thru it but did not find any description addressing the issue where the NAS/DHCP relay-agent and the AAA belongs to a different domain and RADIUS is used as the AAA protocol. (This is precisely the same issue you raised for the DHCPv6 Relay Information Option/RADIUS Attributes sub-option draft.). So, would you point to the specific text in the draft which substantiates your claims 2) and 4) simultaneously ? Currently, the draft just conveniently states: "The AAA procedures using RADIUS is defined in [MIP6-RADIUS]", but [MIP6-RADIUS] Chowdhury et. al., K., "RADIUS Attributes for Mobile IPv6 bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 (work in progress), July 2004. cannot be found in public (I meant -01 version cannot be found, only -00 is available). On the other hand, I cannot see how the cross-domain scenario described in -00 version of draft-chowdhury-mip6-bootstrap-radius the draftis different than the one in draft-droms-dhc-v6-relayopt-00.txt. Am I missing something here ? I would also like to point out that the DHCPv6 Relay Info Option/ RADIUS Attribute sub-option actually addresses 2 level of needs: 1. The ability of DHCPv6 Relay agent to tag along additional "info" as it forwards requests from the DHCP client to the DHCP server, regardless of the specific nature of the "info". This is a "general" capability for the DHCPv6 Relay agent which is absent from the RFC 3315. It seems like both your and our draft needs such capability. The main difference is that, in draft-chowdhury-dhc-mip6-agentop-00.txt, newly defined MIP6-bootstrapping options are relayed while in draft-droms-dhc-v6-relayopt-00.txt, the info got relayed are RADIUS attributes. 2. As for the relay-agent RADIUS option, it is a feature of its own right, the example given in our draft is just one of its use which can help address an immediate issue in 3GPP2 835D. 3. As stated in draft-droms-dhc-v6-relayopt-00.txt, " This document uses 3GPP2 access authentication as an example to motivate the use of the Relay Agent Information option and the RADIUS Attributes sub-option by a NAS. The Relay Agent Information option is not limited to use in conjunction with RADIUS sub-option when other sub-options are defined in the future. The RADIUS Attributes sub- option for the Relay Agent Information option described in this document is not limited to use in conjunction with 3GPP2 and can be used to carry RADIUS attributes obtained by the relay agent for any reason. That is, the sub-option is not limited to use with 3GPP2, but is constrained by RADIUS semantics." Regards, Wing _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Oct 31 01:55:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16058; Sun, 31 Oct 2004 01:55:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CO8bs-0008Oh-Kj; Sun, 31 Oct 2004 01:50:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CO8Ws-0007bu-UN for dhcwg@megatron.ietf.org; Sun, 31 Oct 2004 01:45:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15572 for ; Sun, 31 Oct 2004 01:45:26 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CO8lW-0001M2-0O for dhcwg@ietf.org; Sun, 31 Oct 2004 01:00:34 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9V5ireD016031 for ; Sat, 30 Oct 2004 22:44:53 -0700 (PDT) Received: from WLAU.qualcomm.com (qconnect-10-50-68-119.qualcomm.com [10.50.68.119]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9V5io9A018758 for ; Sat, 30 Oct 2004 22:44:51 -0700 (PDT) Message-Id: <6.0.0.22.2.20041030224427.03fb2630@qcmail1.qualcomm.com> X-Sender: wlau@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 30 Oct 2004 22:44:50 -0700 To: dhcwg@ietf.org From: Wing Cheong Lau Subject: RE: [dhcwg] New draft on DHCPv6 Relay Information Option a n d RADIUS Attributes sub-option Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >Date: Sat, 30 Oct 2004 11:23:40 -0700 >To: "Kuntal Chowdhury" >From: Wing Cheong Lau >Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option a >n d RADIUS Attributes sub-option > >At 03:38 PM 10/29/2004, you wrote: >>draft-chowdhury-mip6-bootstrap-radius-01.txt is not publicly available yet >>because I submitted -01 version after the 25th Nov cutoff date. It will be >>available after Nov 7th when the new submission gate opens. If you need, I >>can send you a copy. > >>-Kuntal > >Sure, a URL for that draft will be welcome. Thanks in advance. >(BTW, the reference date for -01 should be >Oct 04, rather than July 04, as currently shown in >draft-chowdhury-dhc-mip6-agentop-00.txt then). > >In any case, would you share with us in advance how the proposed scheme >addresses the trust/security >issue for the case where the NAS/DHCP relay-agent and the AAA belong to >different domains >and RADIUS is used as the AAA protocol ? >This is to substantiate the support of claims 2) and 4) simultaneously ? > > >Regards, > >Wing > > > >>-----Original Message----- >>From: Wing Cheong Lau [mailto:lau@qualcomm.com] >>Sent: Friday, October 29, 2004 5:06 PM >>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Wing Cheong Lau >>Cc: dhcwg@ietf.org >>Subject: RE: RE: [dhcwg] New draft on DHCPv6 Relay Information Option an d >>RADIUS Attributes sub-option >> >> >>Kuntal, >> >>At 01:54 PM 10/29/2004, Kuntal Chowdhury wrote: >> >>The intent in your draft i.e. configure MN with HA/HoA/HL information can be >>achieved with: >> >>http://www.ietf.org/internet-drafts/draft-chowdhury-dhc-mip6-agentop-00.txt >> >> >>Thanks for bringing to our attention the existence of this new draft. >>Somehow, I have not seen >>its announcement before, at least not in the dhc or mip6 mailing list. >> >> >>Unlike your draft this draft: >> >>1. Does not require the DHCP server to parse vendor-specific RADIUS >>attributes. >> >>But it requires the DHCP relay-agent to parse and understand the newly >>defined, yet-to-be standardized RADIUS Attributes carrying >>HA/HoA/Home-link-prefix as described in >> >>draft-chowdhury-mip6-bootstrap-radius-00.txt and similar yet-to-be >>defined attributes if DIAMETER is used. >> >> >>2. Has no interdomain (ASP-MSP) tight coupling assumption. >>3. Provides integrity and authenticity of the information that is exchanged. >>4. It is AAA protocol agnostic, i.e. works for both RADIUS and DIAMETER. >>5. Does not assume a 3GPP2 centric architecture. It is generic. >> >> >> >> >>Regards, >>Kuntal >> >> >> >>I just did a quick pass thru it but did not find any description addressing >>the issue where >>the NAS/DHCP relay-agent and the AAA belongs to a different domain and >>RADIUS is used as >>the AAA protocol. (This is precisely the same issue you raised for the >>DHCPv6 Relay Information Option/RADIUS Attributes sub-option draft.). So, >>would you point to the specific text in the draft which substantiates your >>claims 2) and 4) simultaneously ? >> >> >>Currently, the draft just conveniently states: >>"The AAA procedures using RADIUS is defined in [MIP6-RADIUS]", >>but >> >> [MIP6-RADIUS] >> >>Chowdhury et. al., K., "RADIUS Attributes for Mobile IPv6 >> >>bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 >> >>(work in progress), July 2004. >> >> >>cannot be found in public (I meant -01 version cannot be found, only -00 is >>available). >>On the other hand, I cannot see how the cross-domain scenario described in >>-00 version of >>draft-chowdhury-mip6-bootstrap-radius >> >>the draftis different than the one in draft-droms-dhc-v6-relayopt-00.txt. >> >>Am I missing something here ? >> >> >>I would also like to point out that the DHCPv6 Relay Info Option/ RADIUS >>Attribute sub-option actually addresses 2 level of needs: >> >>1. The ability of DHCPv6 Relay agent to tag along additional "info" as it >>forwards requests from the DHCP client to the DHCP server, regardless of the >>specific nature of the "info". This is a "general" >>capability for the DHCPv6 Relay agent which is absent from the RFC 3315. It >>seems like both your >>and our draft needs such capability. The main difference is that, in >>draft-chowdhury-dhc-mip6-agentop-00.txt, newly defined MIP6-bootstrapping >>options are relayed while in draft-droms-dhc-v6-relayopt-00.txt, the info >>got relayed are RADIUS attributes. >> >> >>2. As for the relay-agent RADIUS option, it is a feature of its own right, >>the example given in our draft is just one of its use which can help address >>an immediate issue in 3GPP2 835D. >> >> >>3. As stated in draft-droms-dhc-v6-relayopt-00.txt, >>" This document uses 3GPP2 access authentication as an example to >> motivate the use of the Relay Agent Information option and the RADIUS >> Attributes sub-option by a NAS. The Relay Agent Information option is >> not limited to use in conjunction with RADIUS sub-option when other >> sub-options are defined in the future. The RADIUS Attributes sub- >> option for the Relay Agent Information option described in this >> document is not limited to use in conjunction with 3GPP2 and can be >> used to carry RADIUS attributes obtained by the relay agent for any >> reason. That is, the sub-option is not limited to use with 3GPP2, >> but is constrained by RADIUS semantics." >> >> >>Regards, >> >>Wing _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg