From mailman-owner@ietf.org Thu Aug 1 06:16:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18348 for ; Thu, 1 Aug 2002 06:16:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07732 for ; Thu, 1 Aug 2002 06:17:29 -0400 (EDT) Date: Thu, 1 Aug 2002 06:17:29 -0400 (EDT) Message-Id: <200208011017.GAA07732@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: dhc-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ****************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ****************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for dhc-archive@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive@lists.ietf.org From dhcwg-admin@ietf.org Thu Aug 1 07:39:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25702; Thu, 1 Aug 2002 07:39:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21066; Thu, 1 Aug 2002 07:40:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21046 for ; Thu, 1 Aug 2002 07:40:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25659; Thu, 1 Aug 2002 07:39:32 -0400 (EDT) Message-Id: <200208011139.HAA25659@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 01 Aug 2002 07:39:32 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-loadb-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Load Balancing for DHCPv6 Author(s) : B. Volz Filename : draft-ietf-dhc-dhcpv6-loadb-02.txt Pages : 6 Date : 31-Jul-02 This document specifies a load balancing algorithm for use with DHCPv6. Load balancing enables multiple cooperating DHCPv6 servers to decide which one should service a client, without exchanging any information beyond initial configuration. It expands on RFC 3074 'DHC Load Balancing Algorithm' to include DHCPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-loadb-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-loadb-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-loadb-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: <20020731143832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-loadb-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-loadb-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020731143832.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 1 15:33:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12277; Thu, 1 Aug 2002 15:33:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17768; Thu, 1 Aug 2002 15:34:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17752 for ; Thu, 1 Aug 2002 15:34:03 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12265 for ; Thu, 1 Aug 2002 15:32:53 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28185; Thu, 1 Aug 2002 13:33:50 -0600 (MDT) Received: from lillen (hobo077.Eng.Sun.COM [129.146.31.77]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g71JXgg07896; Thu, 1 Aug 2002 21:33:42 +0200 (MEST) Date: Thu, 1 Aug 2002 19:12:14 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration To: Paul Duffy Cc: Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: "Your message with ID" <4.3.2.7.2.20020731174815.02675eb8@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > 1. A primary use case is for testing/lab/trial deployments. The only way > to configure an MTA (a headless, embedded device) for a non standard port > number would be via the CCC sub-option 4/5 mechanism. That seems like an argument for perhaps an experimental RFC, but as I understand it the intent is to make this specification a proposed standard. > 2. Permitting protocol servers to run on a non standard port is not without > precedence. Its been pointed out that Paul Vixie's "named" server allows > it to be configured on a specific port. Does this mean that Paul is > violating Internet Standards ? Come to think of it, I don't think I've > ever seen a protocol server that did not permit configuration of its > protocol port. I don't think anybody has claimed that servers must always use the standard port number. Instead the issue seems to be that the sole reason that these suboptions are needed i.e. why the standard DHCP options for DNS servers are not sufficient. is the claimed need to support non-standard port numbers. Why invent a new standard mechanism for this, especially since the utility is limited to testing/lab/trials? Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 1 16:12:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13527; Thu, 1 Aug 2002 16:12:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19561; Thu, 1 Aug 2002 16:13:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19539 for ; Thu, 1 Aug 2002 16:13:06 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13517 for ; Thu, 1 Aug 2002 16:11:56 -0400 (EDT) Received: from cisco.com (dhcp-128-107-208-82.cisco.com [128.107.208.82]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA19935; Thu, 1 Aug 2002 16:09:29 -0400 (EDT) Message-ID: <3D499578.4020608@cisco.com> Date: Thu, 01 Aug 2002 16:09:28 -0400 From: Josh Littlefield User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Paul Duffy , Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>1. A primary use case is for testing/lab/trial deployments. The only way >>to configure an MTA (a headless, embedded device) for a non standard port >>number would be via the CCC sub-option 4/5 mechanism. > > > That seems like an argument for perhaps an experimental RFC, but > as I understand it the intent is to make this specification a proposed > standard. > Couldn't this also be a reasonable operational feature? The use of DNS in PacketCable (as specified by these sub-options) is quite restricted. Using non-standard ports may, for example, allow deployment of a specific DNS server for PacketCable on the same device as a general nameserver. Or it might just allow extra confidence that the queried server is, in fact, not a general purpose Internet DNS server, but a PacketCable specific one. If CableLabs participants (including operators) have felt the desire to deploy these DNS servers on non-standard ports, why shouldn't they be able to do that? Why shouldn't the DHCP configuration info which is specific to PakcetCable (or similar CableLabs standards) support that? -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-497-8378 fax: same Chelmsford, MA 01824-3627 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 2 14:32:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00057; Fri, 2 Aug 2002 14:32:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01716; Fri, 2 Aug 2002 14:32:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19254 for ; Thu, 1 Aug 2002 16:01:52 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13183 for ; Thu, 1 Aug 2002 16:00:42 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-53.cisco.com [161.44.150.53]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA19370; Thu, 1 Aug 2002 16:01:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20020801154155.0290e050@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Aug 2002 16:01:17 -0400 To: Erik Nordmark From: Paul Duffy Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20020731174815.02675eb8@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Thanks Erik, Re: optional port numbers ... 1. Cablelabs needs it for testing, lab, etc. 2. Some MSO's may decide to deploy DNS on non standard ports. Its a flexibility issue. 3. Not using a standard port makes it slightly less prone to attack by script kiddies. ...I'm out of arguments. What specific suggestions do you have would give us the port configuration control ? Thanks, At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote: > > 1. A primary use case is for testing/lab/trial deployments. The only way > > to configure an MTA (a headless, embedded device) for a non standard port > > number would be via the CCC sub-option 4/5 mechanism. > >That seems like an argument for perhaps an experimental RFC, but >as I understand it the intent is to make this specification a proposed >standard. > > > 2. Permitting protocol servers to run on a non standard port is not > without > > precedence. Its been pointed out that Paul Vixie's "named" server allows > > it to be configured on a specific port. Does this mean that Paul is > > violating Internet Standards ? Come to think of it, I don't think I've > > ever seen a protocol server that did not permit configuration of its > > protocol port. > >I don't think anybody has claimed that servers must always use the >standard port number. > >Instead the issue seems to be that the sole reason that these suboptions >are needed i.e. why the standard DHCP options for DNS servers are not >sufficient. is the claimed need to support non-standard port numbers. > >Why invent a new standard mechanism for this, especially since the utility >is limited to testing/lab/trials? > > Erik -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 2 15:36:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03131; Fri, 2 Aug 2002 15:36:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04221; Fri, 2 Aug 2002 15:36:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04201 for ; Fri, 2 Aug 2002 15:36:39 -0400 (EDT) Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03104 for ; Fri, 2 Aug 2002 15:35:23 -0400 (EDT) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 17aht8-0007wC-00; Fri, 02 Aug 2002 12:15:02 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 12:44:15 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198692F29@homer.incognito.com.> From: "Cosmo, Patrick" To: "'Paul Duffy'" , Erik Nordmark Cc: Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Date: Fri, 2 Aug 2002 12:44:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A5C.FA84E1D0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23A5C.FA84E1D0 Content-Type: text/plain; charset="iso-8859-1" Is the argument that DHCP needs to be used to configure non-standard DNS ports because DHCP occurs at the initial stages of provisioning? That SNMP and/or the MTA configuration file cannot be used to configure non-standard DNS ports because SNMP occurs too late in the provisioning process and/or the config file is downloaded to late in the provisioning process (meaning that DNS may required in order to be able to perform SNMP or to download the configuration file)? Is the argument for sub-options 1/2 that you need to be able to configure one DHCP service such that it will respond to MTA DHCP traffic, but will tell those MTAs to use some other DHCP service (in effect "redirect" the MTA to another DHCP)? Why would you want this? If you can configure the DHCP service to know which MTAs to "redirect", why can't you just configure the DHCP service to ignore those MTAs altogether, instead of "redirecting" them, so that the MTAs only recieve OFFERs from the appropriate DHCP services? I believe that this is the way the rest of the world has always worked up until now: if you don't want a device to get a lease from a particular DHCP service, you configure that DHCP service so it doesn't offer those devices a lease. You don't configure the DHCP service to send an offer that basically says "I'm offering a lease, but you are not allowed to accept any leases from me, you must except leases only from DHCP server X". It could be that I'm misunderstanding the purpose of these options. -----Original Message----- From: Paul Duffy [mailto:paduffy@cisco.com] Sent: Thursday, August 01, 2002 4:01 PM To: Erik Nordmark Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Thanks Erik, Re: optional port numbers ... 1. Cablelabs needs it for testing, lab, etc. 2. Some MSO's may decide to deploy DNS on non standard ports. Its a flexibility issue. 3. Not using a standard port makes it slightly less prone to attack by script kiddies. ...I'm out of arguments. What specific suggestions do you have would give us the port configuration control ? Thanks, At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote: > > 1. A primary use case is for testing/lab/trial deployments. The only way > > to configure an MTA (a headless, embedded device) for a non standard port > > number would be via the CCC sub-option 4/5 mechanism. > >That seems like an argument for perhaps an experimental RFC, but >as I understand it the intent is to make this specification a proposed >standard. > > > 2. Permitting protocol servers to run on a non standard port is not > without > > precedence. Its been pointed out that Paul Vixie's "named" server allows > > it to be configured on a specific port. Does this mean that Paul is > > violating Internet Standards ? Come to think of it, I don't think I've > > ever seen a protocol server that did not permit configuration of its > > protocol port. > >I don't think anybody has claimed that servers must always use the >standard port number. > >Instead the issue seems to be that the sole reason that these suboptions >are needed i.e. why the standard DHCP options for DNS servers are not >sufficient. is the claimed need to support non-standard port numbers. > >Why invent a new standard mechanism for this, especially since the utility >is limited to testing/lab/trials? > > Erik -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C23A5C.FA84E1D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCP Option for CableLabs Client Configuration =

Is the argument that DHCP needs to be used to = configure non-standard DNS ports because DHCP occurs at the initial = stages of provisioning? That SNMP and/or the MTA configuration file = cannot be used to configure non-standard DNS ports because SNMP occurs = too late in the provisioning process and/or the config file is = downloaded to late in the provisioning process (meaning that DNS may = required in order to be able to perform SNMP or to download the = configuration file)?

Is the argument for sub-options 1/2 that you need to = be able to configure one DHCP service such that it will respond to MTA = DHCP traffic, but will tell those MTAs to use some other DHCP service = (in effect "redirect" the MTA to another DHCP)? Why would you = want this? If you can configure the DHCP service to know which MTAs to = "redirect", why can't you just configure the DHCP service to = ignore those MTAs altogether, instead of "redirecting" them, = so that the MTAs only recieve OFFERs from the appropriate DHCP = services? I believe that this is the way the rest of the world has = always worked up until now: if you don't want a device to get a lease = from a particular DHCP service, you configure that DHCP service so it = doesn't offer those devices a lease. You don't configure the DHCP = service to send an offer that basically says "I'm offering a = lease, but you are not allowed to accept any leases from me, you must = except leases only from DHCP server X". It could be that I'm = misunderstanding the purpose of these options.



-----Original Message-----
From: Paul Duffy [mailto:paduffy@cisco.com]
Sent: Thursday, August 01, 2002 4:01 PM
To: Erik Nordmark
Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; = dhcwg@ietf.org;
nrussell@cisco.com; pgrossma@cisco.com; Matt = Osman
Subject: Re: [dhcwg] DHCP Option for CableLabs = Client Configuration


Thanks Erik,

Re: optional port numbers ...

1. Cablelabs needs it for testing, lab, etc.
2. Some MSO's may decide to deploy DNS on non = standard ports.  Its a
flexibility issue.
3. Not using a standard port makes it slightly less = prone to attack by
script kiddies.

...I'm out of arguments.   What specific = suggestions do you have would give
us the port configuration control ?

Thanks,


At 07:12 PM 8/1/2002 +0200, Erik Nordmark = wrote:
> > 1.  A primary use case is for = testing/lab/trial deployments.  The only way
> > to configure an MTA (a headless, embedded = device) for a non standard port
> > number would be via the CCC sub-option 4/5 = mechanism.
>
>That seems like an argument for perhaps an = experimental RFC, but
>as I understand it the intent is to make this = specification a proposed
>standard.
>
> > 2. Permitting protocol servers to run on a = non standard port is not
> without
> > precedence.  Its been pointed out = that Paul Vixie's "named" server allows
> > it to be configured on a specific port. = Does this mean that Paul is
> > violating Internet Standards ?  Come = to think of it, I don't think I've
> > ever seen a protocol server that did not = permit configuration of its
> > protocol port.
>
>I don't think anybody has claimed that servers = must always use the
>standard port number.
>
>Instead the issue seems to be that the sole = reason that these suboptions
>are needed i.e. why the standard DHCP options = for DNS servers are not
>sufficient. is the claimed need to support = non-standard port numbers.
>
>Why invent a new standard mechanism for this, = especially since the utility
>is limited to testing/lab/trials?
>
>   Erik

--

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




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

------_=_NextPart_001_01C23A5C.FA84E1D0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 2 16:11:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04472; Fri, 2 Aug 2002 16:11:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05624; Fri, 2 Aug 2002 16:11:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05594 for ; Fri, 2 Aug 2002 16:11:05 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04437 for ; Fri, 2 Aug 2002 16:09:55 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-53.cisco.com [161.44.150.53]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA08555; Fri, 2 Aug 2002 16:09:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20020802153846.0297d8a0@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Aug 2002 16:09:52 -0400 To: "Cosmo, Patrick" From: Paul Duffy Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: Erik Nordmark , Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198692F29@homer.incognito.com .> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_20746261==_.ALT" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --=====================_20746261==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Thanks Patrick...inline... At 12:44 PM 8/2/2002 -0700, Cosmo, Patrick wrote: >Is the argument that DHCP needs to be used to configure non-standard DNS >ports because DHCP occurs at the initial stages of provisioning? Yes >That SNMP and/or the MTA configuration file cannot be used to configure >non-standard DNS ports because SNMP occurs too late in the provisioning >process and/or the config file is downloaded to late in the provisioning >process (meaning that DNS may required in order to be able to perform SNMP >or to download the configuration file)? Exactly >Is the argument for sub-options 1/2 that you need to be able to configure >one DHCP service such that it will respond to MTA DHCP traffic, but will >tell those MTAs to use some other DHCP service (in effect "redirect" the >MTA to another DHCP)? No. The access provider's DHCP server sends a list of legal telephony DHCP server addresses (CCC sub options 1/2) to the CM. The CM passes this list to the MTA (both devices live in the same physical box). The MTA does a normal discover, but uses the list to restrict the set of DHCP servers from which it will accept DHCP responses. See section 7 http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf You have an access provider who has tight control over its DHCP/DNS infrastructure. The access provider is permitting other business entities to layer services atop its network. The access provider will have less control over the service provider's infrastructure. The 1/2 mechanism explicitly scopes specific devices to specific service provider's infrastructure. It also offers some what more protection from the hacker who is trying to setup a bogus DHCP server behind his cable modem, potentially bringing down the phones. Not good if your house is burning down and you need to call the fire department. >Why would you want this? If you can configure the DHCP service to know >which MTAs to "redirect", why can't you just configure the DHCP service to >ignore those MTAs altogether, instead of "redirecting" them, so that the >MTAs only recieve OFFERs from the appropriate DHCP services? I believe >that this is the way the rest of the world has always worked up until now: >if you don't want a device to get a lease from a particular DHCP service, >you configure that DHCP service so it doesn't offer those devices a lease. >You don't configure the DHCP service to send an offer that basically says >"I'm offering a lease, but you are not allowed to accept any leases from >me, you must except leases only from DHCP server X". It could be that I'm >misunderstanding the purpose of these options. > > >-----Original Message----- >From: Paul Duffy [mailto:paduffy@cisco.com] >Sent: Thursday, August 01, 2002 4:01 PM >To: Erik Nordmark >Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; >nrussell@cisco.com; pgrossma@cisco.com; Matt Osman >Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration > >Thanks Erik, > >Re: optional port numbers ... > >1. Cablelabs needs it for testing, lab, etc. >2. Some MSO's may decide to deploy DNS on non standard ports. Its a >flexibility issue. >3. Not using a standard port makes it slightly less prone to attack by >script kiddies. > >...I'm out of arguments. What specific suggestions do you have would give >us the port configuration control ? > >Thanks, > >At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote: > > > 1. A primary use case is for testing/lab/trial deployments. The > only way > > > to configure an MTA (a headless, embedded device) for a non standard > port > > > number would be via the CCC sub-option 4/5 mechanism. > > > >That seems like an argument for perhaps an experimental RFC, but > >as I understand it the intent is to make this specification a proposed > >standard. > > > > > 2. Permitting protocol servers to run on a non standard port is not > > without > > > precedence. Its been pointed out that Paul Vixie's "named" server > allows > > > it to be configured on a specific port. Does this mean that Paul is > > > violating Internet Standards ? Come to think of it, I don't think I've > > > ever seen a protocol server that did not permit configuration of its > > > protocol port. > > > >I don't think anybody has claimed that servers must always use the > >standard port number. > > > >Instead the issue seems to be that the sole reason that these suboptions > >are needed i.e. why the standard DHCP options for DNS servers are not > >sufficient. is the claimed need to support non-standard port numbers. > > > >Why invent a new standard mechanism for this, especially since the utility > >is limited to testing/lab/trials? > > > > Erik > >-- > >Paul Duffy >Cisco Systems, Inc. >paduffy@cisco.com > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com --=====================_20746261==_.ALT Content-Type: text/html; charset="us-ascii" Thanks Patrick...inline...

At 12:44 PM 8/2/2002 -0700, Cosmo, Patrick wrote:

Is the argument that DHCP needs to be used to configure non-standard DNS ports because DHCP occurs at the initial stages of provisioning?

Yes

That SNMP and/or the MTA configuration file cannot be used to configure non-standard DNS ports because SNMP occurs too late in the provisioning process and/or the config file is downloaded to late in the provisioning process (meaning that DNS may required in order to be able to perform SNMP or to download the configuration file)?

Exactly


Is the argument for sub-options 1/2 that you need to be able to configure one DHCP service such that it will respond to MTA DHCP traffic, but will tell those MTAs to use some other DHCP service (in effect "redirect" the MTA to another DHCP)?

No.  The access provider's DHCP server sends a list of legal telephony DHCP server addresses (CCC sub options 1/2) to the CM.  The CM passes this list to the MTA  (both devices live in the same physical box).  The MTA does a normal discover, but uses the list to restrict the set of DHCP servers from which it will accept DHCP responses.  See section 7 http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf

<key issue>
You have an access provider who has tight control over its DHCP/DNS infrastructure.  The access provider is permitting other business entities to layer services atop its network.  The access provider will have less control over the service provider's infrastructure.
</key issue>

The 1/2 mechanism explicitly scopes specific devices to specific service provider's infrastructure.  It also offers some what more protection from the hacker who is trying to setup a bogus DHCP server behind his cable modem, potentially bringing down the phones.  Not good if your house is burning down and you need to call the fire department.

Why would you want this? If you can configure the DHCP service to know which MTAs to "redirect", why can't you just configure the DHCP service to ignore those MTAs altogether, instead of "redirecting" them, so that the MTAs only recieve OFFERs from the appropriate DHCP services? I believe that this is the way the rest of the world has always worked up until now: if you don't want a device to get a lease from a particular DHCP service, you configure that DHCP service so it doesn't offer those devices a lease. You don't configure the DHCP service to send an offer that basically says "I'm offering a lease, but you are not allowed to accept any leases from me, you must except leases only from DHCP server X". It could be that I'm misunderstanding the purpose of these options.


-----Original Message-----
From: Paul Duffy [mailto:paduffy@cisco.com]
Sent: Thursday, August 01, 2002 4:01 PM
To: Erik Nordmark
Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org;
nrussell@cisco.com; pgrossma@cisco.com; Matt Osman
Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration

Thanks Erik,

Re: optional port numbers ...

1. Cablelabs needs it for testing, lab, etc.
2. Some MSO's may decide to deploy DNS on non standard ports.  Its a
flexibility issue.
3. Not using a standard port makes it slightly less prone to attack by
script kiddies.

...I'm out of arguments.   What specific suggestions do you have would give
us the port configuration control ?

Thanks,

At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote:
> > 1.  A primary use case is for testing/lab/trial deployments.  The only way
> > to configure an MTA (a headless, embedded device) for a non standard port
> > number would be via the CCC sub-option 4/5 mechanism.
>
>That seems like an argument for perhaps an experimental RFC, but
>as I understand it the intent is to make this specification a proposed
>standard.
>
> > 2. Permitting protocol servers to run on a non standard port is not
> without
> > precedence.  Its been pointed out that Paul Vixie's "named" server allows
> > it to be configured on a specific port. Does this mean that Paul is
> > violating Internet Standards ?  Come to think of it, I don't think I've
> > ever seen a protocol server that did not permit configuration of its
> > protocol port.
>
>I don't think anybody has claimed that servers must always use the
>standard port number.
>
>Instead the issue seems to be that the sole reason that these suboptions
>are needed i.e. why the standard DHCP options for DNS servers are not
>sufficient. is the claimed need to support non-standard port numbers.
>
>Why invent a new standard mechanism for this, especially since the utility
>is limited to testing/lab/trials?
>
>   Erik

--

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



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

--

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

--=====================_20746261==_.ALT-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 2 17:25:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07294; Fri, 2 Aug 2002 17:25:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09460; Fri, 2 Aug 2002 17:26:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09405 for ; Fri, 2 Aug 2002 17:26:02 -0400 (EDT) Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07271 for ; Fri, 2 Aug 2002 17:24:50 -0400 (EDT) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 17ajbl-0008MQ-00; Fri, 02 Aug 2002 14:05:13 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 14:34:27 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198692F2D@homer.incognito.com.> From: "Cosmo, Patrick" To: "'Paul Duffy'" , PacketCable Provisioning and OSS Majordomo List Cc: Erik Nordmark , Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Date: Fri, 2 Aug 2002 14:34:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A6C.5CFF9D50" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23A6C.5CFF9D50 Content-Type: text/plain; charset="iso-8859-1" The access provider's DHCP server sends a list of legal telephony DHCP server addresses (CCC sub options 1/2) to the CM. The CM passes this list to the MTA (both devices live in the same physical box). [Cosmo, Patrick] The CM must be completely provisioned before the MTA can (successfully) do DHCP, correct? So why can't you send the sub-option 1/2 data to the CM in its config file or through SNMP, and then let it pass it along to the MTA? You want to ensure that the MTA gets a list of "legal telephony DHCP server addresses". This implies that without opts 1/2, the MTA may get DHCP from a server outside this list. Can anyone say whether there is a mechanism that ensures the CM only gets DHCP from valid servers (does the CMTS ensure this?)? This question has already been posited to Richard Woundy, but perhaps someone else knows? You can't protect the MTA from bogus DHCP servers, if you are trying to do it using data, forwarded from a CM, that originates from those same bogus DHCP servers. Similarly, this opt 1/2 mechanism does not allow the access provider to gain tighter control over its DHCP/DNS infrastructure if the CM can get DHCP from servers outside this infrastructure. The MTA does a normal discover, but uses the list to restrict the set of DHCP servers from which it will accept DHCP responses. See section 7 http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221. pdf You have an access provider who has tight control over its DHCP/DNS infrastructure. The access provider is permitting other business entities to layer services atop its network. The access provider will have less control over the service provider's infrastructure. The 1/2 mechanism explicitly scopes specific devices to specific service provider's infrastructure. It also offers some what more protection from the hacker who is trying to setup a bogus DHCP server behind his cable modem, potentially bringing down the phones. Not good if your house is burning down and you need to call the fire department. Why would you want this? If you can configure the DHCP service to know which MTAs to "redirect", why can't you just configure the DHCP service to ignore those MTAs altogether, instead of "redirecting" them, so that the MTAs only recieve OFFERs from the appropriate DHCP services? I believe that this is the way the rest of the world has always worked up until now: if you don't want a device to get a lease from a particular DHCP service, you configure that DHCP service so it doesn't offer those devices a lease. You don't configure the DHCP service to send an offer that basically says "I'm offering a lease, but you are not allowed to accept any leases from me, you must except leases only from DHCP server X". It could be that I'm misunderstanding the purpose of these options. -----Original Message----- From: Paul Duffy [ mailto:paduffy@cisco.com ] Sent: Thursday, August 01, 2002 4:01 PM To: Erik Nordmark Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Thanks Erik, Re: optional port numbers ... 1. Cablelabs needs it for testing, lab, etc. 2. Some MSO's may decide to deploy DNS on non standard ports. Its a flexibility issue. 3. Not using a standard port makes it slightly less prone to attack by script kiddies. ...I'm out of arguments. What specific suggestions do you have would give us the port configuration control ? Thanks, At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote: > > 1. A primary use case is for testing/lab/trial deployments. The only way > > to configure an MTA (a headless, embedded device) for a non standard port > > number would be via the CCC sub-option 4/5 mechanism. > >That seems like an argument for perhaps an experimental RFC, but >as I understand it the intent is to make this specification a proposed >standard. > > > 2. Permitting protocol servers to run on a non standard port is not > without > > precedence. Its been pointed out that Paul Vixie's "named" server allows > > it to be configured on a specific port. Does this mean that Paul is > > violating Internet Standards ? Come to think of it, I don't think I've > > ever seen a protocol server that did not permit configuration of its > > protocol port. > >I don't think anybody has claimed that servers must always use the >standard port number. > >Instead the issue seems to be that the sole reason that these suboptions >are needed i.e. why the standard DHCP options for DNS servers are not >sufficient. is the claimed need to support non-standard port numbers. > >Why invent a new standard mechanism for this, especially since the utility >is limited to testing/lab/trials? > > Erik -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com ------_=_NextPart_001_01C23A6C.5CFF9D50 Content-Type: text/html; charset="iso-8859-1"
The access provider's DHCP server sends a list of legal telephony DHCP server addresses (CCC sub options 1/2) to the CM.  The CM passes this list to the MTA  (both devices live in the same physical box). 
[Cosmo, Patrick] The CM must be completely provisioned before the MTA can (successfully) do DHCP, correct? So why can't you send the sub-option 1/2 data to the CM in its config file or through SNMP, and then let it pass it along to the MTA?
 
You want to ensure that the MTA gets a list of "legal telephony DHCP server addresses". This implies that without opts 1/2, the MTA may get DHCP from a server outside this list. Can anyone say whether there is a mechanism that ensures the CM only gets DHCP from valid servers (does the CMTS ensure this?)? This question has already been posited to Richard Woundy, but perhaps someone else knows? You can't protect the MTA from bogus DHCP servers, if you are trying to do it using data, forwarded from a CM, that originates from those same bogus DHCP servers. Similarly, this opt 1/2 mechanism does not allow the access provider to gain tighter control over its DHCP/DNS infrastructure if the CM can get DHCP from servers outside this infrastructure.
 
  The MTA does a normal discover, but uses the list to restrict the set of DHCP servers from which it will accept DHCP responses.  See section 7 http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf

<key issue>
You have an access provider who has tight control over its DHCP/DNS infrastructure.  The access provider is permitting other business entities to layer services atop its network.  The access provider will have less control over the service provider's infrastructure.
</key issue>

The 1/2 mechanism explicitly scopes specific devices to specific service provider's infrastructure.  It also offers some what more protection from the hacker who is trying to setup a bogus DHCP server behind his cable modem, potentially bringing down the phones.  Not good if your house is burning down and you need to call the fire department.

Why would you want this? If you can configure the DHCP service to know which MTAs to "redirect", why can't you just configure the DHCP service to ignore those MTAs altogether, instead of "redirecting" them, so that the MTAs only recieve OFFERs from the appropriate DHCP services? I believe that this is the way the rest of the world has always worked up until now: if you don't want a device to get a lease from a particular DHCP service, you configure that DHCP service so it doesn't offer those devices a lease. You don't configure the DHCP service to send an offer that basically says "I'm offering a lease, but you are not allowed to accept any leases from me, you must except leases only from DHCP server X". It could be that I'm misunderstanding the purpose of these options.


-----Original Message-----
From: Paul Duffy [mailto:paduffy@cisco.com]
Sent: Thursday, August 01, 2002 4:01 PM
To: Erik Nordmark
Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org;
nrussell@cisco.com; pgrossma@cisco.com; Matt Osman
Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration

Thanks Erik,

Re: optional port numbers ...

1. Cablelabs needs it for testing, lab, etc.
2. Some MSO's may decide to deploy DNS on non standard ports.  Its a
flexibility issue.
3. Not using a standard port makes it slightly less prone to attack by
script kiddies.

...I'm out of arguments.   What specific suggestions do you have would give
us the port configuration control ?

Thanks,

At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote:
> > 1.  A primary use case is for testing/lab/trial deployments.  The only way
> > to configure an MTA (a headless, embedded device) for a non standard port
> > number would be via the CCC sub-option 4/5 mechanism.
>
>That seems like an argument for perhaps an experimental RFC, but
>as I understand it the intent is to make this specification a proposed
>standard.
>
> > 2. Permitting protocol servers to run on a non standard port is not
> without
> > precedence.  Its been pointed out that Paul Vixie's "named" server allows
> > it to be configured on a specific port. Does this mean that Paul is
> > violating Internet Standards ?  Come to think of it, I don't think I've
> > ever seen a protocol server that did not permit configuration of its
> > protocol port.
>
>I don't think anybody has claimed that servers must always use the
>standard port number.
>
>Instead the issue seems to be that the sole reason that these suboptions
>are needed i.e. why the standard DHCP options for DNS servers are not
>sufficient. is the claimed need to support non-standard port numbers.
>
>Why invent a new standard mechanism for this, especially since the utility
>is limited to testing/lab/trials?
>
>   Erik

--

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



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

--

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

------_=_NextPart_001_01C23A6C.5CFF9D50-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 2 17:44:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08145; Fri, 2 Aug 2002 17:44:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10502; Fri, 2 Aug 2002 17:44:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10480 for ; Fri, 2 Aug 2002 17:44:27 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08088 for ; Fri, 2 Aug 2002 17:43:18 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-53.cisco.com [161.44.150.53]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA14284; Fri, 2 Aug 2002 17:43:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20020802164429.027a0890@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Aug 2002 17:43:52 -0400 To: Thomas Narten From: Paul Duffy Cc: nrussell@cisco.com, Ralph Droms , m.osman@cablelabs.com, "Woundy, Richard" , Erik Nordmark , dhcwg@ietf.org In-Reply-To: <200207291913.g6TJDdC02094@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: draft-ietf-dhc-packetcable-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org At 03:13 PM 7/29/2002 -0400, Thomas Narten wrote: >Hi. > >I understand there is a need to get this document finished very >quickly in order to get it into an RFC. > >Please respond to the messages posted to the mailing list quickly. I >fear this document may need a bit of work, as parts of it are hard to >follow, and I am not sure about the soundness of some aspects of the >ID. > >We need quick discussion and resolution if this document is going to >be completed in time for the August Cablelabs deadline. > >Thomas Folks, In the spirit of Thomas' original request, I'd like to propose the following steps so we can close this out soon... 1. We'll add text, something like the following, near the beginning of the I-D: "Cablelabs client devices will issue DHCP requests that include options 55 and 60. Option 55 will request the CCC option from the DHCP server. Option 60 will specify the specific Cablelabs client type, thus directing the DHCP server to populate specific CCC sub-option content in its responses. The details of which CCC sub-options are populated for each specific client type are spelled out in the various Cablelabs project specifications. For example, the PacketCable MTA Device Provisioning Specification [ref] defines the specific set of CCC sub-options that must be populated in DHCP responses to CMs and MTAs in a PacketCable deployment." 2. We'll change the description of sub-option 6 from "The Kerberos Realm name is an FQDN" to "The Kerberos Realm name is formatted per RFC 1510". 3. Regarding the optional port numbers on sub-options 1-5....Cablelabs has confirmed that we have to have this capability. For testing, for improved security...ultimately... because MSO's/cable operators are going to deploy these servers on non standard ports. We must have a way to configure the devices for the non standard port. If you disagree with our proposals, we ask that you please enlighten us re: a specific alternative. 4. Assuming you see the need for the optional port numbers, we strongly prefer to stick with sub-option 4/5 as defined in the draft. This will leave sub-options 1-5 more symmetrically defined and will be easier to implement. 5. Cablelabs will ECR any specification, referencing this I-D, to bring it into alignment with the RFC (when issued). PacketCable, CableHome, etc. This is normal Cablelabs procedure. We were holding off until the I-D made it to RFC. I hope we can reach agreement soon. There is important inter operability testing coming up at Calblelabs. Best Regards, -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 2 18:22:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09388; Fri, 2 Aug 2002 18:22:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11879; Fri, 2 Aug 2002 18:22:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11794 for ; Fri, 2 Aug 2002 18:19:17 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09302 for ; Fri, 2 Aug 2002 18:18:08 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-122.cisco.com [10.82.240.122]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA16133; Fri, 2 Aug 2002 18:18:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20020802181726.039b95f0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Aug 2002 18:18:03 -0400 To: "Cosmo, Patrick" From: Ralph Droms Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: "'Paul Duffy'" , PacketCable Provisioning and OSS Majordomo List , Erik Nordmark , Thomas Narten , "Bernie Volz (EUD)" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198692F2D@homer.incognito.com .> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: quoted-printable Patrick -

In response to the question at the beginning of your second paragraph, the CMTS is responsible for preventing DHCP server spoofing.  See section 4 of "Cable Modem Termination System =96 Network Side Interface Specification", SP-CMTS-NSII01-960702.

- Ralph

At 02:34 PM 8/2/2002 -0700, Cosmo, Patrick wrote:
The access provider's DHCP server sends a list of legal telephony DHCP server addresses (CCC sub options 1/2) to the CM.  The CM passes this list to the MTA  (both devices live in the same physical box).
[Cosmo, Patrick] The CM must= be completely provisioned before the MTA can (successfully) do DHCP, correct? So why can't you send the sub-option 1/2 data to the CM in its config file or through SNMP, and then let it pass it along to the MTA?
 
You want to ensure that the = MTA gets a list of "legal telephony DHCP server addresses". This implies that without opts 1/2, the MTA may get DHCP from a server outside this list. Can anyone say whether there is a mechanism that ensures the CM only gets DHCP from valid servers (does the CMTS ensure this?)? This question has already been posited to Richard Woundy, but perhaps someone else knows? You can't protect the MTA from bogus DHCP servers, if you are trying to do it using data, forwarded from a CM, that originates from those same bogus DHCP servers. Similarly, this opt 1/2 mechanism does not allow the access provider to gain tighter control over its DHCP/DNS infrastructure if the CM can get DHCP from servers outside this infrastructure.
 
  The MTA does a normal discover, but uses the list to restrict the set of DHCP servers from which it will accept DHCP responses.  See section 7 http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.= pdf

<key issue>
You have an access provider who has tight control over its DHCP/DNS infrastructure.  The access provider is permitting other business entities to layer services atop its network.  The access provider will have less control over the service provider's infrastructure.
</key issue>

The 1/2 mechanism explicitly scopes specific devices to specific service provider's infrastructure.  It also offers some what more protection from the hacker who is trying to setup a bogus DHCP server behind his cable modem, potentially bringing down the phones.  Not good if your house is burning down and you need to call the fire department.
Why would you want this? If you can configure the DHCP service to know which MTAs to "redirect", why can't you just configure the DHCP service to ignore those MTAs altogether, instead of "redirecting" them, so that the MTAs only recieve OFFERs from the appropriate DHCP services? I believe that this is the way the rest of the world has always worked up until now: if you don't want a device to get a lease from a particular DHCP service, you configure that DHCP service so it doesn't offer those devices a lease. You don't configure the DHCP service to send an offer that basically says "I'm offering a lease, but you are not allowed to accept any leases from me, you must except leases only from DHCP server X". It could be that I'm misunderstanding the purpose of these options.

-----Original Message-----
From: Paul Duffy [mailto:paduffy@cisco.com]
Sent: Thursday, August 01, 2002 4:01 PM
To: Erik Nordmark
Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org;
nrussell@cisco.com; pgrossma@cisco.com; Matt Osman
Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration=
Thanks Erik,

Re: optional port numbers ...

1. Cablelabs needs it for testing, lab, etc.
2. Some MSO's may decide to deploy DNS on non standard ports.  Its= a
flexibility issue.
3. Not using a standard port makes it slightly less prone to attack by=
script kiddies.

...I'm out of arguments.   What specific suggestions do you= have would give
us the port configuration control ?

Thanks,

At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote:
> > 1.  A primary use case is for testing/lab/trial= deployments.  The only way
> > to configure an MTA (a headless, embedded device) for a non= standard port
> > number would be via the CCC sub-option 4/5 mechanism.=
>
>That seems like an argument for perhaps an experimental RFC,= but
>as I understand it the intent is to make this specification a= proposed
>standard.
>
> > 2. Permitting protocol servers to run on a non standard port= is not
> without
> > precedence.  Its been pointed out that Paul Vixie's= "named" server allows
> > it to be configured on a specific port. Does this mean that= Paul is
> > violating Internet Standards ?  Come to think of it, I= don't think I've
> > ever seen a protocol server that did not permit configuration= of its
> > protocol port.
>
>I don't think anybody has claimed that servers must always use= the
>standard port number.
>
>Instead the issue seems to be that the sole reason that these= suboptions
>are needed i.e. why the standard DHCP options for DNS servers are= not
>sufficient. is the claimed need to support non-standard port= numbers.
>
>Why invent a new standard mechanism for this, especially since the= utility
>is limited to testing/lab/trials?
>
>   Erik

--

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





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

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com
_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 2 18:22:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09419; Fri, 2 Aug 2002 18:22:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11927; Fri, 2 Aug 2002 18:23:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11904 for ; Fri, 2 Aug 2002 18:23:11 -0400 (EDT) Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09385 for ; Fri, 2 Aug 2002 18:22:01 -0400 (EDT) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 17akV6-0000AO-00; Fri, 02 Aug 2002 15:02:24 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 15:31:38 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198692F2F@homer.incognito.com.> From: "Cosmo, Patrick" To: "'Ralph Droms'" Cc: "'Paul Duffy'" , PacketCable Provisioning and OSS Majordomo List , Erik Nordmark , Thomas Narten , "Bernie Volz (EUD)" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Date: Fri, 2 Aug 2002 15:31:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A74.58C46B00" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23A74.58C46B00 Content-Type: text/plain; charset="iso-8859-1" Thanks Ralph. Does it only prevent DHCP server spoofing for CMs, and not MTAs? -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, August 02, 2002 6:18 PM To: Cosmo, Patrick Cc: 'Paul Duffy'; PacketCable Provisioning and OSS Majordomo List; Erik Nordmark; Thomas Narten; Bernie Volz (EUD); dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Patrick - In response to the question at the beginning of your second paragraph, the CMTS is responsible for preventing DHCP server spoofing. See section 4 of "Cable Modem Termination System - Network Side Interface Specification", SP-CMTS-NSII01-960702. - Ralph At 02:34 PM 8/2/2002 -0700, Cosmo, Patrick wrote: The access provider's DHCP server sends a list of legal telephony DHCP server addresses (CCC sub options 1/2) to the CM. The CM passes this list to the MTA (both devices live in the same physical box). [Cosmo, Patrick] The CM must be completely provisioned before the MTA can (successfully) do DHCP, correct? So why can't you send the sub-option 1/2 data to the CM in its config file or through SNMP, and then let it pass it along to the MTA? You want to ensure that the MTA gets a list of "legal telephony DHCP server addresses". This implies that without opts 1/2, the MTA may get DHCP from a server outside this list. Can anyone say whether there is a mechanism that ensures the CM only gets DHCP from valid servers (does the CMTS ensure this?)? This question has already been posited to Richard Woundy, but perhaps someone else knows? You can't protect the MTA from bogus DHCP servers, if you are trying to do it using data, forwarded from a CM, that originates from those same bogus DHCP servers. Similarly, this opt 1/2 mechanism does not allow the access provider to gain tighter control over its DHCP/DNS infrastructure if the CM can get DHCP from servers outside this infrastructure. The MTA does a normal discover, but uses the list to restrict the set of DHCP servers from which it will accept DHCP responses. See section 7 http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf You have an access provider who has tight control over its DHCP/DNS infrastructure. The access provider is permitting other business entities to layer services atop its network. The access provider will have less control over the service provider's infrastructure. The 1/2 mechanism explicitly scopes specific devices to specific service provider's infrastructure. It also offers some what more protection from the hacker who is trying to setup a bogus DHCP server behind his cable modem, potentially bringing down the phones. Not good if your house is burning down and you need to call the fire department. Why would you want this? If you can configure the DHCP service to know which MTAs to "redirect", why can't you just configure the DHCP service to ignore those MTAs altogether, instead of "redirecting" them, so that the MTAs only recieve OFFERs from the appropriate DHCP services? I believe that this is the way the rest of the world has always worked up until now: if you don't want a device to get a lease from a particular DHCP service, you configure that DHCP service so it doesn't offer those devices a lease. You don't configure the DHCP service to send an offer that basically says "I'm offering a lease, but you are not allowed to accept any leases from me, you must except leases only from DHCP server X". It could be that I'm misunderstanding the purpose of these options. -----Original Message----- From: Paul Duffy [ mailto:paduffy@cisco.com ] Sent: Thursday, August 01, 2002 4:01 PM To: Erik Nordmark Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Thanks Erik, Re: optional port numbers ... 1. Cablelabs needs it for testing, lab, etc. 2. Some MSO's may decide to deploy DNS on non standard ports. Its a flexibility issue. 3. Not using a standard port makes it slightly less prone to attack by script kiddies. ...I'm out of arguments. What specific suggestions do you have would give us the port configuration control ? Thanks, At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote: > > 1. A primary use case is for testing/lab/trial deployments. The only way > > to configure an MTA (a headless, embedded device) for a non standard port > > number would be via the CCC sub-option 4/5 mechanism. > >That seems like an argument for perhaps an experimental RFC, but >as I understand it the intent is to make this specification a proposed >standard. > > > 2. Permitting protocol servers to run on a non standard port is not > without > > precedence. Its been pointed out that Paul Vixie's "named" server allows > > it to be configured on a specific port. Does this mean that Paul is > > violating Internet Standards ? Come to think of it, I don't think I've > > ever seen a protocol server that did not permit configuration of its > > protocol port. > >I don't think anybody has claimed that servers must always use the >standard port number. > >Instead the issue seems to be that the sole reason that these suboptions >are needed i.e. why the standard DHCP options for DNS servers are not >sufficient. is the claimed need to support non-standard port numbers. > >Why invent a new standard mechanism for this, especially since the utility >is limited to testing/lab/trials? > > Erik -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com ------_=_NextPart_001_01C23A74.58C46B00 Content-Type: text/html; charset="iso-8859-1"
Thanks Ralph. Does it only prevent DHCP server spoofing for CMs, and not MTAs?
 
-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, August 02, 2002 6:18 PM
To: Cosmo, Patrick
Cc: 'Paul Duffy'; PacketCable Provisioning and OSS Majordomo List; Erik Nordmark; Thomas Narten; Bernie Volz (EUD); dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman
Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration

Patrick -

In response to the question at the beginning of your second paragraph, the CMTS is responsible for preventing DHCP server spoofing.  See section 4 of "Cable Modem Termination System - Network Side Interface Specification", SP-CMTS-NSII01-960702.

- Ralph

At 02:34 PM 8/2/2002 -0700, Cosmo, Patrick wrote:
The access provider's DHCP server sends a list of legal telephony DHCP server addresses (CCC sub options 1/2) to the CM.  The CM passes this list to the MTA  (both devices live in the same physical box).
[Cosmo, Patrick] The CM must be completely provisioned before the MTA can (successfully) do DHCP, correct? So why can't you send the sub-option 1/2 data to the CM in its config file or through SNMP, and then let it pass it along to the MTA?
 
You want to ensure that the MTA gets a list of "legal telephony DHCP server addresses". This implies that without opts 1/2, the MTA may get DHCP from a server outside this list. Can anyone say whether there is a mechanism that ensures the CM only gets DHCP from valid servers (does the CMTS ensure this?)? This question has already been posited to Richard Woundy, but perhaps someone else knows? You can't protect the MTA from bogus DHCP servers, if you are trying to do it using data, forwarded from a CM, that originates from those same bogus DHCP servers. Similarly, this opt 1/2 mechanism does not allow the access provider to gain tighter control over its DHCP/DNS infrastructure if the CM can get DHCP from servers outside this infrastructure.
 
  The MTA does a normal discover, but uses the list to restrict the set of DHCP servers from which it will accept DHCP responses.  See section 7 http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf

<key issue>
You have an access provider who has tight control over its DHCP/DNS infrastructure.  The access provider is permitting other business entities to layer services atop its network.  The access provider will have less control over the service provider's infrastructure.
</key issue>

The 1/2 mechanism explicitly scopes specific devices to specific service provider's infrastructure.  It also offers some what more protection from the hacker who is trying to setup a bogus DHCP server behind his cable modem, potentially bringing down the phones.  Not good if your house is burning down and you need to call the fire department.
Why would you want this? If you can configure the DHCP service to know which MTAs to "redirect", why can't you just configure the DHCP service to ignore those MTAs altogether, instead of "redirecting" them, so that the MTAs only recieve OFFERs from the appropriate DHCP services? I believe that this is the way the rest of the world has always worked up until now: if you don't want a device to get a lease from a particular DHCP service, you configure that DHCP service so it doesn't offer those devices a lease. You don't configure the DHCP service to send an offer that basically says "I'm offering a lease, but you are not allowed to accept any leases from me, you must except leases only from DHCP server X". It could be that I'm misunderstanding the purpose of these options.

-----Original Message-----
From: Paul Duffy [mailto:paduffy@cisco.com]
Sent: Thursday, August 01, 2002 4:01 PM
To: Erik Nordmark
Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org;
nrussell@cisco.com; pgrossma@cisco.com; Matt Osman
Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration
Thanks Erik,

Re: optional port numbers ...

1. Cablelabs needs it for testing, lab, etc.
2. Some MSO's may decide to deploy DNS on non standard ports.  Its a
flexibility issue.
3. Not using a standard port makes it slightly less prone to attack by
script kiddies.

...I'm out of arguments.   What specific suggestions do you have would give
us the port configuration control ?

Thanks,

At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote:
> > 1.  A primary use case is for testing/lab/trial deployments.  The only way
> > to configure an MTA (a headless, embedded device) for a non standard port
> > number would be via the CCC sub-option 4/5 mechanism.
>
>That seems like an argument for perhaps an experimental RFC, but
>as I understand it the intent is to make this specification a proposed
>standard.
>
> > 2. Permitting protocol servers to run on a non standard port is not
> without
> > precedence.  Its been pointed out that Paul Vixie's "named" server allows
> > it to be configured on a specific port. Does this mean that Paul is
> > violating Internet Standards ?  Come to think of it, I don't think I've
> > ever seen a protocol server that did not permit configuration of its
> > protocol port.
>
>I don't think anybody has claimed that servers must always use the
>standard port number.
>
>Instead the issue seems to be that the sole reason that these suboptions
>are needed i.e. why the standard DHCP options for DNS servers are not
>sufficient. is the claimed need to support non-standard port numbers.
>
>Why invent a new standard mechanism for this, especially since the utility
>is limited to testing/lab/trials?
>
>   Erik

--

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





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

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com
------_=_NextPart_001_01C23A74.58C46B00-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 2 19:52:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11909; Fri, 2 Aug 2002 19:52:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16410; Fri, 2 Aug 2002 19:52:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12006 for ; Fri, 2 Aug 2002 18:28:00 -0400 (EDT) Received: from peacock.tci.com (coral.tci.com [198.178.8.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09555 for ; Fri, 2 Aug 2002 18:26:49 -0400 (EDT) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id g72MRkwS010994; Fri, 2 Aug 2002 16:27:46 -0600 (MDT) Received: from 147.191.89.201 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Fri, 02 Aug 2002 16:27:12 -0600 X-Server-Uuid: 90826C58-91B0-45EB-95A5-46B6D42E456F Received: by entexchimc02.tci.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 2 Aug 2002 16:27:12 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC6666AC@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "PacketCable Provisioning and OSS Majordomo List" , dhcwg@ietf.org cc: "Erik Nordmark" , "Thomas Narten" , "Bernie Volz (EUD)" , "'Ralph Droms'" , nrussell@cisco.com, pgrossma@cisco.com, "Matt Osman" , "'Cosmo, Patrick'" , "'Paul Duffy'" Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Date: Fri, 2 Aug 2002 16:27:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1155D8CA4338-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A73.CC75FDD0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23A73.CC75FDD0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Folks, It does not seem to be good engineering practice to use CCC suboptions 1/2 as an alternative to DHCP message authentication, ala RFC3118. So I do not think it is reasonable to expect these suboptions to protect the MTAs from "bogus DHCP servers" completely. I believe the right way to think about these suboptions is in the context of RFC 2131 section 4.1.1: The client collects DHCPOFFER messages over a period of time, selects one DHCPOFFER message from the (possibly many) incoming DHCPOFFER messages (e.g., the first DHCPOFFER message or the DHCPOFFER message from the previously used server) and extracts the server address from the 'server identifier' option in the DHCPOFFER message. The time over which the client collects messages and the mechanism used to select one DHCPOFFER are implementation dependent. In essense, the value(s) in CCC suboptions 1/2 provide additional criteria for the "mechanism used to select one DHCPOFFER". That is, the values of the suboptions constrain the choice of DHCPOFFERs to messages for which the "server identifier" option matches one of the suboptions values (the value 255.255.255.255 being excepted of course). This isn't as new a concept as it might sound. There is already text in RFC2131 about clients basing their choice of DHCPOFFERs based on the "vendor class identifier" option. Section 4.3.1 says "The server MAY choose to return the 'vendor class identifier' used to determine the parameters in the DHCPOFFER message to assist the client in selecting which DHCPOFFER to accept." The reason this capability exists in PacketCable is because when a device (cable modem, personal computer, MTA) transmits a DHCP broadcast message, the upstream router can relay the DHCP message to multiple DHCP servers in different administrative domains, and the device needs some help in choosing among multiple (legitimate) DHCPOFFERs. The Telephony Service Provider (TSP) might be a different organization than the Access Provider (AP), and there may be multiple TSPs. If a PacketCable MTA ought to receive service from TSP-1, and the MTA sends a DHCP broadcast message that is relayed by the CMTS to both TSP-1 and TSP-2 DHCP servers, the MTA needs to know that it should ignore the DHCP responses from TSP-2. Why would the TSP-2 DHCP server respond, if TSP-1 provides telephony service for the MTA? One possibility is that TSP-2 might enable a self-provisioning service for unknown MTAs -- allow the MTA to boot on TSP-2 with just enough privileges to contact a (real or virtual) service representative to sign up for service. Similar functionality for Internet service has already been deployed in cable networks today. A second possibility is to allow the MTA to boot on a limited TSP network for 911 calls only. -- Rich P.S. There are a number of mechanisms that cable operators leverage to prevent rogue DHCP servers from attacking their customers, i.e. spoofing the operator's DHCP servers. A key mechanism is IP network filtering function provided in routers and cable modems (see RFC 2669 for details). That serves mostly as a perimeter defense. Some scalable form of DHCP message authentication would be preferable, though. P.P.S. Gee, don't I get more than one hour to respond to random emails directed towards me??? -----Original Message----- From: Cosmo, Patrick [mailto:Patrick@incognito.com] Sent: Friday, August 02, 2002 5:34 PM To: 'Paul Duffy'; PacketCable Provisioning and OSS Majordomo List Cc: Erik Nordmark; Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration The access provider's DHCP server sends a list of legal telephony DHCP server addresses (CCC sub options 1/2) to the CM. The CM passes this list to the MTA (both devices live in the same physical box). [Cosmo, Patrick] The CM must be completely provisioned before the MTA can (successfully) do DHCP, correct? So why can't you send the sub-option 1/2 data to the CM in its config file or through SNMP, and then let it pass it along to the MTA? You want to ensure that the MTA gets a list of "legal telephony DHCP server addresses". This implies that without opts 1/2, the MTA may get DHCP from a server outside this list. Can anyone say whether there is a mechanism that ensures the CM only gets DHCP from valid servers (does the CMTS ensure this?)? This question has already been posited to Richard Woundy, but perhaps someone else knows? You can't protect the MTA from bogus DHCP servers, if you are trying to do it using data, forwarded from a CM, that originates from those same bogus DHCP servers. Similarly, this opt 1/2 mechanism does not allow the access provider to gain tighter control over its DHCP/DNS infrastructure if the CM can get DHCP from servers outside this infrastructure. The MTA does a normal discover, but uses the list to restrict the set of DHCP servers from which it will accept DHCP responses. See section 7 http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221. pdf You have an access provider who has tight control over its DHCP/DNS infrastructure. The access provider is permitting other business entities to layer services atop its network. The access provider will have less control over the service provider's infrastructure. The 1/2 mechanism explicitly scopes specific devices to specific service provider's infrastructure. It also offers some what more protection from the hacker who is trying to setup a bogus DHCP server behind his cable modem, potentially bringing down the phones. Not good if your house is burning down and you need to call the fire department. Why would you want this? If you can configure the DHCP service to know which MTAs to "redirect", why can't you just configure the DHCP service to ignore those MTAs altogether, instead of "redirecting" them, so that the MTAs only recieve OFFERs from the appropriate DHCP services? I believe that this is the way the rest of the world has always worked up until now: if you don't want a device to get a lease from a particular DHCP service, you configure that DHCP service so it doesn't offer those devices a lease. You don't configure the DHCP service to send an offer that basically says "I'm offering a lease, but you are not allowed to accept any leases from me, you must except leases only from DHCP server X". It could be that I'm misunderstanding the purpose of these options. -----Original Message----- From: Paul Duffy [ mailto:paduffy@cisco.com ] Sent: Thursday, August 01, 2002 4:01 PM To: Erik Nordmark Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Thanks Erik, Re: optional port numbers ... 1. Cablelabs needs it for testing, lab, etc. 2. Some MSO's may decide to deploy DNS on non standard ports. Its a flexibility issue. 3. Not using a standard port makes it slightly less prone to attack by script kiddies. ...I'm out of arguments. What specific suggestions do you have would give us the port configuration control ? Thanks, At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote: > > 1. A primary use case is for testing/lab/trial deployments. The only way > > to configure an MTA (a headless, embedded device) for a non standard port > > number would be via the CCC sub-option 4/5 mechanism. > >That seems like an argument for perhaps an experimental RFC, but >as I understand it the intent is to make this specification a proposed >standard. > > > 2. Permitting protocol servers to run on a non standard port is not > without > > precedence. Its been pointed out that Paul Vixie's "named" server allows > > it to be configured on a specific port. Does this mean that Paul is > > violating Internet Standards ? Come to think of it, I don't think I've > > ever seen a protocol server that did not permit configuration of its > > protocol port. > >I don't think anybody has claimed that servers must always use the >standard port number. > >Instead the issue seems to be that the sole reason that these suboptions >are needed i.e. why the standard DHCP options for DNS servers are not >sufficient. is the claimed need to support non-standard port numbers. > >Why invent a new standard mechanism for this, especially since the utility >is limited to testing/lab/trials? > > Erik -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com ------_=_NextPart_001_01C23A73.CC75FDD0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Folks,
 
It does not seem to be good engineering practice to use CCC suboptions 1/2 as an alternative to DHCP message authentication, ala RFC3118. So I do not think it is reasonable to expect these suboptions to protect the MTAs from "bogus DHCP servers" completely.
 
I believe the right way to think about these suboptions is in the context of RFC 2131 section 4.1.1:
 
   The client collects DHCPOFFER messages over a period of time, selects
   one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
   messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
   from the previously used server) and extracts the server address from
   the 'server identifier' option in the DHCPOFFER message.  The time
   over which the client collects messages and the mechanism used to
   select one DHCPOFFER are implementation dependent.
 
In essense, the value(s) in CCC suboptions 1/2 provide additional criteria for the "mechanism used to select one DHCPOFFER". That is, the values of the suboptions constrain the choice of DHCPOFFERs to messages for which the "server identifier" option matches one of the suboptions values (the value 255.255.255.255 being excepted of course).
 
This isn't as new a concept as it might sound. There is already text in RFC2131 about clients basing their choice of DHCPOFFERs based on the "vendor class identifier" option. Section 4.3.1 says "The server MAY choose to return the 'vendor class identifier' used to determine the parameters in the DHCPOFFER message to assist the client in selecting which DHCPOFFER to accept."
 
The reason this capability exists in PacketCable is because when a device (cable modem, personal computer, MTA) transmits a DHCP broadcast message, the upstream router can relay the DHCP message to multiple DHCP servers in different administrative domains, and the device needs some help in choosing among multiple (legitimate) DHCPOFFERs. The Telephony Service Provider (TSP) might be a different organization than the Access Provider (AP), and there may be multiple TSPs. If a PacketCable MTA ought to receive service from TSP-1, and the MTA sends a DHCP broadcast message that is relayed by the CMTS to both TSP-1 and TSP-2 DHCP servers, the MTA needs to know that it should ignore the DHCP responses from TSP-2.
 
Why would the TSP-2 DHCP server respond, if TSP-1 provides telephony service for the MTA? One possibility is that TSP-2 might enable a self-provisioning service for unknown MTAs -- allow the MTA to boot on TSP-2 with just enough privileges to contact a (real or virtual) service representative to sign up for service. Similar functionality for Internet service has already been deployed in cable networks today. A second possibility is to allow the MTA to boot on a limited TSP network for 911 calls only.
 
-- Rich
 
P.S. There are a number of mechanisms that cable operators leverage to prevent rogue DHCP servers from attacking their customers, i.e. spoofing the operator's DHCP servers. A key mechanism is IP network filtering function provided in routers and cable modems (see RFC 2669 for details). That serves mostly as a perimeter defense. Some scalable form of DHCP message authentication would be preferable, though.
 
P.P.S. Gee, don't I get more than one hour to respond to random emails directed towards me???
-----Original Message-----
From: Cosmo, Patrick [mailto:Patrick@incognito.com]
Sent: Friday, August 02, 2002 5:34 PM
To: 'Paul Duffy'; PacketCable Provisioning and OSS Majordomo List
Cc: Erik Nordmark; Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman
Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration

The access provider's DHCP server sends a list of legal telephony DHCP server addresses (CCC sub options 1/2) to the CM.  The CM passes this list to the MTA  (both devices live in the same physical box). 
[Cosmo, Patrick] The CM must be completely provisioned before the MTA can (successfully) do DHCP, correct? So why can't you send the sub-option 1/2 data to the CM in its config file or through SNMP, and then let it pass it along to the MTA?
 
You want to ensure that the MTA gets a list of "legal telephony DHCP server addresses". This implies that without opts 1/2, the MTA may get DHCP from a server outside this list. Can anyone say whether there is a mechanism that ensures the CM only gets DHCP from valid servers (does the CMTS ensure this?)? This question has already been posited to Richard Woundy, but perhaps someone else knows? You can't protect the MTA from bogus DHCP servers, if you are trying to do it using data, forwarded from a CM, that originates from those same bogus DHCP servers. Similarly, this opt 1/2 mechanism does not allow the access provider to gain tighter control over its DHCP/DNS infrastructure if the CM can get DHCP from servers outside this infrastructure.
 
  The MTA does a normal discover, but uses the list to restrict the set of DHCP servers from which it will accept DHCP responses.  See section 7 http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf

<key issue>
You have an access provider who has tight control over its DHCP/DNS infrastructure.  The access provider is permitting other business entities to layer services atop its network.  The access provider will have less control over the service provider's infrastructure.
</key issue>

The 1/2 mechanism explicitly scopes specific devices to specific service provider's infrastructure.  It also offers some what more protection from the hacker who is trying to setup a bogus DHCP server behind his cable modem, potentially bringing down the phones.  Not good if your house is burning down and you need to call the fire department.

Why would you want this? If you can configure the DHCP service to know which MTAs to "redirect", why can't you just configure the DHCP service to ignore those MTAs altogether, instead of "redirecting" them, so that the MTAs only recieve OFFERs from the appropriate DHCP services? I believe that this is the way the rest of the world has always worked up until now: if you don't want a device to get a lease from a particular DHCP service, you configure that DHCP service so it doesn't offer those devices a lease. You don't configure the DHCP service to send an offer that basically says "I'm offering a lease, but you are not allowed to accept any leases from me, you must except leases only from DHCP server X". It could be that I'm misunderstanding the purpose of these options.


-----Original Message-----
From: Paul Duffy [mailto:paduffy@cisco.com]
Sent: Thursday, August 01, 2002 4:01 PM
To: Erik Nordmark
Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org;
nrussell@cisco.com; pgrossma@cisco.com; Matt Osman
Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration

Thanks Erik,

Re: optional port numbers ...

1. Cablelabs needs it for testing, lab, etc.
2. Some MSO's may decide to deploy DNS on non standard ports.  Its a
flexibility issue.
3. Not using a standard port makes it slightly less prone to attack by
script kiddies.

...I'm out of arguments.   What specific suggestions do you have would give
us the port configuration control ?

Thanks,

At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote:
> > 1.  A primary use case is for testing/lab/trial deployments.  The only way
> > to configure an MTA (a headless, embedded device) for a non standard port
> > number would be via the CCC sub-option 4/5 mechanism.
>
>That seems like an argument for perhaps an experimental RFC, but
>as I understand it the intent is to make this specification a proposed
>standard.
>
> > 2. Permitting protocol servers to run on a non standard port is not
> without
> > precedence.  Its been pointed out that Paul Vixie's "named" server allows
> > it to be configured on a specific port. Does this mean that Paul is
> > violating Internet Standards ?  Come to think of it, I don't think I've
> > ever seen a protocol server that did not permit configuration of its
> > protocol port.
>
>I don't think anybody has claimed that servers must always use the
>standard port number.
>
>Instead the issue seems to be that the sole reason that these suboptions
>are needed i.e. why the standard DHCP options for DNS servers are not
>sufficient. is the claimed need to support non-standard port numbers.
>
>Why invent a new standard mechanism for this, especially since the utility
>is limited to testing/lab/trials?
>
>   Erik

--

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



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

--

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

------_=_NextPart_001_01C23A73.CC75FDD0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 2 19:52:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11908; Fri, 2 Aug 2002 19:52:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16449; Fri, 2 Aug 2002 19:52:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12154 for ; Fri, 2 Aug 2002 18:30:13 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09610 for ; Fri, 2 Aug 2002 18:29:04 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-122.cisco.com [10.82.240.122]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA16715; Fri, 2 Aug 2002 18:29:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20020802182433.039fee40@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Aug 2002 18:28:55 -0400 To: "Cosmo, Patrick" From: Ralph Droms Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: "'Paul Duffy'" , PacketCable Provisioning and OSS Majordomo List , Erik Nordmark , Thomas Narten , "Bernie Volz (EUD)" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198692F2F@homer.incognito.com .> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_20270527==_.ALT" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --=====================_20270527==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Patrick, At 03:31 PM 8/2/2002 -0700, Cosmo, Patrick wrote: >Thanks Ralph. Does it only prevent DHCP server spoofing for CMs, and not=20 >MTAs? Good question; the text reads: Network layer requirements for the CMTS exist beyond transparency to IP=20 traffic. The CMTS must also support: =B7 variable length subnet masks =B7 classless addressing =B7 IP multicast addressing and forwarding =B7 Internet Group Management Protocol (IGMP) =B7 proxy ARP =B7 filtering of DHCP downstream-bound broadcast packets to protect against= =20 BOOTP server spoofing I would read the text to apply to all DHCP server spoofing. - Ralph > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Friday, August 02, 2002 6:18 PM >To: Cosmo, Patrick >Cc: 'Paul Duffy'; PacketCable Provisioning and OSS Majordomo List; Erik=20 >Nordmark; Thomas Narten; Bernie Volz (EUD); dhcwg@ietf.org;=20 >nrussell@cisco.com; pgrossma@cisco.com; Matt Osman >Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration > >Patrick - > >In response to the question at the beginning of your second paragraph, the= =20 >CMTS is responsible for preventing DHCP server spoofing. See section 4 of= =20 >"Cable Modem Termination System - Network Side Interface Specification",=20 >SP-CMTS-NSII01-960702. > >- Ralph > >At 02:34 PM 8/2/2002 -0700, Cosmo, Patrick wrote: >>The access provider's DHCP server sends a list of legal telephony DHCP=20 >>server addresses (CCC sub options 1/2) to the CM. The CM passes this=20 >>list to the MTA (both devices live in the same physical box). >>[Cosmo, Patrick] The CM must be completely provisioned before the MTA can= =20 >>(successfully) do DHCP, correct? So why can't you send the sub-option 1/2= =20 >>data to the CM in its config file or through SNMP, and then let it pass=20 >>it along to the MTA? >> >>You want to ensure that the MTA gets a list of "legal telephony DHCP=20 >>server addresses". This implies that without opts 1/2, the MTA may get=20 >>DHCP from a server outside this list. Can anyone say whether there is a=20 >>mechanism that ensures the CM only gets DHCP from valid servers (does the= =20 >>CMTS ensure this?)? This question has already been posited to Richard=20 >>Woundy, but perhaps someone else knows? You can't protect the MTA from=20 >>bogus DHCP servers, if you are trying to do it using data, forwarded from= =20 >>a CM, that originates from those same bogus DHCP servers. Similarly, this= =20 >>opt 1/2 mechanism does not allow the access provider to gain tighter=20 >>control over its DHCP/DNS infrastructure if the CM can get DHCP from=20 >>servers outside this infrastructure. >> >> The MTA does a normal discover, but uses the list to restrict the set= =20 >> of DHCP servers from which it will accept DHCP responses. See section 7= =20 >> http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf >> >> >>You have an access provider who has tight control over its DHCP/DNS=20 >>infrastructure. The access provider is permitting other business=20 >>entities to layer services atop its network. The access provider will=20 >>have less control over the service provider's infrastructure. >> >> >>The 1/2 mechanism explicitly scopes specific devices to specific service= =20 >>provider's infrastructure. It also offers some what more protection from= =20 >>the hacker who is trying to setup a bogus DHCP server behind his cable=20 >>modem, potentially bringing down the phones. Not good if your house is=20 >>burning down and you need to call the fire department. >>>Why would you want this? If you can configure the DHCP service to know=20 >>>which MTAs to "redirect", why can't you just configure the DHCP service= =20 >>>to ignore those MTAs altogether, instead of "redirecting" them, so that= =20 >>>the MTAs only recieve OFFERs from the appropriate DHCP services? I=20 >>>believe that this is the way the rest of the world has always worked up= =20 >>>until now: if you don't want a device to get a lease from a particular=20 >>>DHCP service, you configure that DHCP service so it doesn't offer those= =20 >>>devices a lease. You don't configure the DHCP service to send an offer=20 >>>that basically says "I'm offering a lease, but you are not allowed to=20 >>>accept any leases from me, you must except leases only from DHCP server= =20 >>>X". It could be that I'm misunderstanding the purpose of these options. >>>-----Original Message----- >>>From: Paul Duffy [mailto:paduffy@cisco.com] >>>Sent: Thursday, August 01, 2002 4:01 PM >>>To: Erik Nordmark >>>Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; >>>nrussell@cisco.com; pgrossma@cisco.com; Matt Osman >>>Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration >>>Thanks Erik, >>> >>>Re: optional port numbers ... >>> >>>1. Cablelabs needs it for testing, lab, etc. >>>2. Some MSO's may decide to deploy DNS on non standard ports. Its a >>>flexibility issue. >>>3. Not using a standard port makes it slightly less prone to attack by >>>script kiddies. >>> >>>...I'm out of arguments. What specific suggestions do you have would= give >>>us the port configuration control ? >>> >>>Thanks, >>> >>>At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote: >>> > > 1. A primary use case is for testing/lab/trial deployments. The=20 >>> only way >>> > > to configure an MTA (a headless, embedded device) for a non=20 >>> standard port >>> > > number would be via the CCC sub-option 4/5 mechanism. >>> > >>> >That seems like an argument for perhaps an experimental RFC, but >>> >as I understand it the intent is to make this specification a proposed >>> >standard. >>> > >>> > > 2. Permitting protocol servers to run on a non standard port is not >>> > without >>> > > precedence. Its been pointed out that Paul Vixie's "named" server= =20 >>> allows >>> > > it to be configured on a specific port. Does this mean that Paul is >>> > > violating Internet Standards ? Come to think of it, I don't think= =20 >>> I've >>> > > ever seen a protocol server that did not permit configuration of its >>> > > protocol port. >>> > >>> >I don't think anybody has claimed that servers must always use the >>> >standard port number. >>> > >>> >Instead the issue seems to be that the sole reason that these= suboptions >>> >are needed i.e. why the standard DHCP options for DNS servers are not >>> >sufficient. is the claimed need to support non-standard port numbers. >>> > >>> >Why invent a new standard mechanism for this, especially since the=20 >>> utility >>> >is limited to testing/lab/trials? >>> > >>> > Erik >>> >>>-- >>> >>>Paul Duffy >>>Cisco Systems, Inc. >>>paduffy@cisco.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>_______________________________________________ >>>dhcwg mailing list >>>dhcwg@ietf.org >>>https://www1.ietf.org/mailm= an/listinfo/dhcwg=20 >>> >>-- >> >>Paul Duffy >>Cisco Systems, Inc. >>paduffy@cisco.com --=====================_20270527==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Patrick,

At 03:31 PM 8/2/2002 -0700, Cosmo, Patrick wrote:
Thanks Ralph. Does it only prevent DHCP server spoofing for CMs, and not MTAs?

Good question; the text reads:

Network layer requirements for the CMTS exist beyond transparency to IP traffic. The CMTS
must also support:

=B7 variable length subnet masks
=B7 classless addressing
=B7 IP multicast addressing and forwarding
=B7 Internet Group Management Protocol (IGMP)
=B7 proxy ARP
=B7 filtering of DHCP downstream-bound broadcast packets to protect against BOOTP server spoofing

I would read the text to apply to all DHCP server spoofing.

- Ralph


 
-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, August 02, 2002 6:18 PM
To: Cosmo, Patrick
Cc: 'Paul Duffy'; PacketCable Provisioning and OSS Majordomo List; Erik Nordmark; Thomas Narten; Bernie Volz (EUD); dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman
Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration

Patrick -

In response to the question at the beginning of your second paragraph, the CMTS is responsible for preventing DHCP server spoofing.  See section 4 of "Cable Modem Termination System - Network Side Interface Specification", SP-CMTS-NSII01-960702.

- Ralph

At 02:34 PM 8/2/2002 -0700, Cosmo, Patrick wrote:
The access provider's DHCP server sends a list of legal telephony DHCP server addresses (CCC sub options 1/2) to the CM.  The CM passes this list to the MTA  (both devices live in the same physical box).
[Cosmo, Patrick] The CM must be completely provisioned before the MTA can (successfully) do DHCP, correct? So why can't you send the sub-option 1/2 data to the CM in its config file or through SNMP, and then let it pass it along to the MTA?
 
You want to ensure that the MTA gets a list of "legal telephony DHCP server addresses". This implies that without opts 1/2, the MTA may get DHCP from a server outside this list. Can anyone say whether there is a mechanism that ensures the CM only gets DHCP from valid servers (does the CMTS ensure this?)? This question has already been posited to Richard Woundy, but perhaps someone else knows? You can't protect the MTA from bogus DHCP servers, if you are trying to do it using data, forwarded from a CM, that originates from those same bogus DHCP servers. Similarly, this opt 1/2 mechanism does not allow the access provider to gain tighter control over its DHCP/DNS infrastructure if the CM can get DHCP from servers outside this infrastructure.
 
  The MTA does a normal discover, but uses the list to restrict the set of DHCP servers from which it will accept DHCP responses.  See section 7 http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.= pdf

<key issue>
You have an access provider who has tight control over its DHCP/DNS infrastructure.  The access provider is permitting other business entities to layer services atop its network.  The access provider will have less control over the service provider's infrastructure.
</key issue>

The 1/2 mechanism explicitly scopes specific devices to specific service provider's infrastructure.  It also offers some what more protection from the hacker who is trying to setup a bogus DHCP server behind his cable modem, potentially bringing down the phones.  Not good if your house is burning down and you need to call the fire department.
Why would you want this? If you can configure the DHCP service to know which MTAs to "redirect", why can't you just configure the DHCP service to ignore those MTAs altogether, instead of "redirecting" them, so that the MTAs only recieve OFFERs from the appropriate DHCP services? I believe that this is the way the rest of the world has always worked up until now: if you don't want a device to get a lease from a particular DHCP service, you configure that DHCP service so it doesn't offer those devices a lease. You don't configure the DHCP service to send an offer that basically says "I'm offering a lease, but you are not allowed to accept any leases from me, you must except leases only from DHCP server X". It could be that I'm misunderstanding the purpose of these options.
-----Original Message-----
From: Paul Duffy [mailto:paduffy@cisco.com]
Sent: Thursday, August 01, 2002 4:01 PM
To: Erik Nordmark
Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org;
nrussell@cisco.com; pgrossma@cisco.com; Matt Osman
Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration=20
Thanks Erik,

Re: optional port numbers ...

1. Cablelabs needs it for testing, lab, etc.
2. Some MSO's may decide to deploy DNS on non standard ports.  Its= a=20
flexibility issue.
3. Not using a standard port makes it slightly less prone to attack by= =20
script kiddies.

...I'm out of arguments.   What specific suggestions do you= have would give=20
us the port configuration control ?

Thanks,

At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote:
> > 1.  A primary use case is for testing/lab/trial= deployments.  The only way
> > to configure an MTA (a headless, embedded device) for a non= standard port
> > number would be via the CCC sub-option 4/5 mechanism.=
>
>That seems like an argument for perhaps an experimental RFC,= but
>as I understand it the intent is to make this specification a= proposed
>standard.
>
> > 2. Permitting protocol servers to run on a non standard port= is not=20
> without
> > precedence.  Its been pointed out that Paul Vixie's= "named" server allows
> > it to be configured on a specific port. Does this mean that= Paul is
> > violating Internet Standards ?  Come to think of it, I= don't think I've
> > ever seen a protocol server that did not permit configuration= of its
> > protocol port.
>
>I don't think anybody has claimed that servers must always use= the
>standard port number.
>
>Instead the issue seems to be that the sole reason that these= suboptions
>are needed i.e. why the standard DHCP options for DNS servers are= not
>sufficient. is the claimed need to support non-standard port= numbers.
>
>Why invent a new standard mechanism for this, especially since the= utility
>is limited to testing/lab/trials?
>
>   Erik

--

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









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

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com
--=====================_20270527==_.ALT-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 2 19:53:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11995; Fri, 2 Aug 2002 19:53:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16525; Fri, 2 Aug 2002 19:53:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16504 for ; Fri, 2 Aug 2002 19:53:33 -0400 (EDT) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11902 for ; Fri, 2 Aug 2002 19:52:23 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08726; Fri, 2 Aug 2002 17:53:26 -0600 (MDT) Received: from lillen (d-umpk17-99-214.Eng.Sun.COM [129.146.99.214]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g72NrLg25580; Sat, 3 Aug 2002 01:53:22 +0200 (MEST) Date: Sat, 3 Aug 2002 01:51:26 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration To: Josh Littlefield Cc: Erik Nordmark , Paul Duffy , Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: "Your message with ID" <3D499578.4020608@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Couldn't this also be a reasonable operational feature? The use of DNS in > PacketCable (as specified by these sub-options) is quite restricted. Using > non-standard ports may, for example, allow deployment of a specific DNS > server for PacketCable on the same device as a general nameserver. Or it > might just allow extra confidence that the queried server is, in fact, not a > general purpose Internet DNS server, but a PacketCable specific one. How does this relate to RFC 2826 IAB Technical Comment on the Unique DNS Root. I could be wrong bit it seems like folks might be trying to build w alled gardens using this "dns on a different port number" as a tool. I think we in the IETF should focus on designing the right protocols for the Internet and not encourage walled gardens. So why should we add additional complexity for this DNS port number thing? I haven't seen an argument that is convincing to me. (And FWIW, the "security through obscurity" argument about using non-standard port numbers is actually a reason to not allow a mechanism for alternate port numbers; we need to get folks to think about real security.) > If CableLabs participants (including operators) have felt the desire to > deploy these DNS servers on non-standard ports, why shouldn't they be able > to do that? Why shouldn't the DHCP configuration info which is specific to > PakcetCable (or similar CableLabs standards) support that? I thought we were talking about an Internet standard, and not a CableLabs standard. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Aug 3 00:51:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17895; Sat, 3 Aug 2002 00:51:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26406; Sat, 3 Aug 2002 00:50:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26387 for ; Sat, 3 Aug 2002 00:50:38 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17876 for ; Sat, 3 Aug 2002 00:49:27 -0400 (EDT) Received: from paduffy-w2k.cisco.com (che-vpn1-32.cisco.com [10.86.240.32]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA00553; Sat, 3 Aug 2002 00:50:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20020803003222.042cca10@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 03 Aug 2002 00:49:59 -0400 To: Erik Nordmark From: Paul Duffy Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: Josh Littlefield , Erik Nordmark , Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: References: <"Your message with ID" <3D499578.4020608@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org At 01:51 AM 8/3/2002 +0200, Erik Nordmark wrote: > > Couldn't this also be a reasonable operational feature? The use of DNS in > > PacketCable (as specified by these sub-options) is quite > restricted. Using > > non-standard ports may, for example, allow deployment of a specific DNS > > server for PacketCable on the same device as a general nameserver. Or it > > might just allow extra confidence that the queried server is, in fact, > not a > > general purpose Internet DNS server, but a PacketCable specific one. > >How does this relate to > RFC 2826 IAB Technical Comment on the Unique DNS Root. Erik, how exactly does a non standard DNS port violate the unique root ? >I could be wrong bit it seems like folks might be trying to build w >alled gardens using this "dns on a different port number" as a tool. >I think we in the IETF should focus on designing the right protocols >for the Internet and not encourage walled gardens. So why should we add >additional complexity for this DNS port number thing? > >I haven't seen an argument that is convincing to me. >(And FWIW, the "security through obscurity" argument about using non-standard >port numbers is actually a reason to not allow a mechanism for alternate >port numbers; we need to get folks to think about real security. Security is not Cablelab's primary argument here (recall it was #3 in the previous email). The primary argument is to provide flexibility to our customers. > > If CableLabs participants (including operators) have felt the desire to > > deploy these DNS servers on non-standard ports, why shouldn't they be able > > to do that? Why shouldn't the DHCP configuration info which is > specific to > > PakcetCable (or similar CableLabs standards) support that? > >I thought we were talking about an Internet standard, and not >a CableLabs standard. > > Erik > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 5 01:13:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22323; Mon, 5 Aug 2002 01:13:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06089; Mon, 5 Aug 2002 01:11:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06040 for ; Mon, 5 Aug 2002 01:11:31 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22287 for ; Mon, 5 Aug 2002 01:10:18 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27435; Sun, 4 Aug 2002 23:11:22 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g755B8g22791; Mon, 5 Aug 2002 07:11:09 +0200 (MEST) Date: Mon, 5 Aug 2002 07:09:11 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration To: Paul Duffy Cc: Erik Nordmark , Josh Littlefield , Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: "Your message with ID" <4.3.2.7.2.20020803003222.042cca10@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > >How does this relate to > > RFC 2826 IAB Technical Comment on the Unique DNS Root. > > Erik, how exactly does a non standard DNS port violate the unique root ? I asked that question with the hope the proponents would think about it carefully. Seems like that failed :-) It seems to me that the DNS as we know it operates on a well-know port. Being able to run something using the DNS protocol but a different port number sounds like being able to run a different naming system with potentially a different root. > Security is not Cablelab's primary argument here (recall it was #3 in the > previous email). The primary argument is to provide flexibility to our > customers. But ignoring the testing argument (which is an argument for an experimental RFC and not a standard IMHO) the remaining arguments are: >2. Some MSO's may decide to deploy DNS on non standard ports. Its a >flexibility issue. >3. Not using a standard port makes it slightly less prone to attack by >script kiddies. #2 doesn't state why folks see this need. One possibility is definitely walled gardens and in general using a different DNS tree than the rest of us. I've yet to see any other concrete reason for this (and I don't buy flexibility for its own sake). And #3 is just security through obscurity which we IMHO have no business promoting in our standards. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 5 01:37:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22824; Mon, 5 Aug 2002 01:37:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09897; Mon, 5 Aug 2002 01:37:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09873 for ; Mon, 5 Aug 2002 01:37:08 -0400 (EDT) Received: from snowmass.tci.com (coral.tci.com [198.178.8.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22805 for ; Mon, 5 Aug 2002 01:35:55 -0400 (EDT) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id g755axx5025733; Sun, 4 Aug 2002 23:36:59 -0600 (MDT) Received: from 147.191.89.203 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Sun, 04 Aug 2002 23:36:21 -0600 X-Server-Uuid: 4520D425-5A30-451F-8662-E5DDF307F3B1 Received: by entexchimc01.tci.com with Internet Mail Service ( 5.5.2653.19) id ; Sun, 4 Aug 2002 23:37:19 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC6666B7@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Erik Nordmark'" , "Josh Littlefield" cc: "Paul Duffy" , "Thomas Narten" , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, "Matt Osman" Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Date: Sun, 4 Aug 2002 23:36:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1150D15F107579-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Erik, A PacketCable MTA is an interesting Internet host, not quite the same as the computer on which I am composing this email. The MTA provides one or more RJ-11 jacks for standard phone sets to be plugged into. The MTA is (at least in this respect) functional from a subscriber point of view, if the attached phone set(s) can be used to call phone numbers anywhere in the world, typically to contact phone sets connected the global Public Switched Telephone Network (PSTN). In any Voice over IP architecture (including PacketCable), there is an assumption that not every telephony endpoint is reachable over the Internet. That means that the architecture must accommodate the case in which a VoIP endpoint needs to transmit IP datagrams to intermediate systems in order to signal/communicate with a legacy telephony endpoint in the PSTN. The primary intermediate systems in the PacketCable architecture are the "Call Management Server" (for signaling) and the "Media Gateway" (for bearer traffic). The PacketCable 1.0 specifications permit an MTA to communicate with another MTA within the same administrative domain. The specifications do not forbid MTA communication with an MTA in a different domain, but they do not specify the necessary technical infrastructure (e.g. maintaining QoS on a stream of voice traffic between the two backbone networks). The 1.2 specifications provide some of the infrastructure needed for an MTA to talk to another MTA in a different administrative domain, e.g. signaling between call management servers, and enabling interdomain QoS. But at this time, and for the next several years, most cable operators are just starting to deploy telephony services using IP over cable (e.g. DOCSIS), in place of dedicated copper circuits (such as from the local exchange carrier) or other technologies (proprietary circuit switched telephony over cable). That implies that most MTA signaling/communication will be mediated through call management servers and media gateways -- this is a consequence of what operators (and vendors) are ready to deploy today, rather than a limitation of the PacketCable architecture itself. If MTAs communicate at the IP layer only with other systems (MTAs, call management servers, media gateways, etc.) within the same domain, then it makes sense to consider using RFC 1918 private addresses for MTA rather than public addresses. Using private addresses for MTAs is significant in the case of AT&T Broadband, since this cable operator already has 1,200,000 telephony subscribers (over broadband cable) today. Note that CableLabs, in fact, would like cable operators to assign public addresses to MTAs for interdomain communications... but I'm not sure that ARIN would approve of that choice given our current generation of products, our (lack of) interdomain qos expertise, and the large consumption of public addresses that such a decision would entail. I suppose you might consider what I have described as a "walled garden" for MTAs. My first reaction is that the end-goal for the PacketCable architecture is a voice-over-Internet service, not merely a walled garden service. My second reaction is this -- why does the IETF care about whether a particular service deployment is a walled garden or not? Do the IETF standards only support certain business models, and not others? Do the IETF standards FORBID walled gardens? I thought the IETF was a technical standards organization, not a business policy standards body. If you agree that it is reasonable, at least for the next few years, to use private IP addresses for PacketCable MTAs, then the following paragraph from the summary of RFC 2826 applies: This does not preclude private networks from operating their own private name spaces, but if they wish to make use of names uniquely defined for the global Internet, they have to fetch that information from the global DNS naming hierarchy, and in particular from the coordinated root servers of the global DNS naming hierarchy. Further guidance is provided by RFC 1918 section 3: Moving a host from private to public or vice versa involves a change of IP address, changes to the appropriate DNS entries, and changes to configuration files on other hosts that reference the host by IP address. ... Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. It would seem rational that, should it makes sense to assign RFC 1918 private IP addresses to MTAs, and since MTAs require DNS fully qualified host names as VoIP endpoints in PacketCable (and in SGCP/MGCP, and in SIP), then RFC 1918 seems to endorse the operation of a parallel DNS infrastructure for the MTAs and VoIP components. And one way to run a parallel DNS infrastructure is to use different DNS port numbers for the VoIP service. This is particularly true for smaller operators, with more limited capital budgets and smaller VoIP subscriber bases. By the way, I agree with your point on "security through obscurity". Using different port numbers to "protect DNS" would not be a very compelling argument for me, either. -- Rich P.S. It wasn't originally my idea to put DNS port number configuration into the CableLabs Client Configuration option, by the way. For a substantial period of time, I thought it was a "hack". I have only been recently convinced that there were significant operational advantages to this configuration parameter. -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@Sun.COM] Sent: Friday, August 02, 2002 7:51 PM To: Josh Littlefield Cc: Erik Nordmark; Paul Duffy; Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration > Couldn't this also be a reasonable operational feature? The use of DNS in > PacketCable (as specified by these sub-options) is quite restricted. Using > non-standard ports may, for example, allow deployment of a specific DNS > server for PacketCable on the same device as a general nameserver. Or it > might just allow extra confidence that the queried server is, in fact, not a > general purpose Internet DNS server, but a PacketCable specific one. How does this relate to RFC 2826 IAB Technical Comment on the Unique DNS Root. I could be wrong bit it seems like folks might be trying to build w alled gardens using this "dns on a different port number" as a tool. I think we in the IETF should focus on designing the right protocols for the Internet and not encourage walled gardens. So why should we add additional complexity for this DNS port number thing? I haven't seen an argument that is convincing to me. (And FWIW, the "security through obscurity" argument about using non-standard port numbers is actually a reason to not allow a mechanism for alternate port numbers; we need to get folks to think about real security.) > If CableLabs participants (including operators) have felt the desire to > deploy these DNS servers on non-standard ports, why shouldn't they be able > to do that? Why shouldn't the DHCP configuration info which is specific to > PakcetCable (or similar CableLabs standards) support that? I thought we were talking about an Internet standard, and not a CableLabs standard. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 5 11:14:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16864; Mon, 5 Aug 2002 11:14:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07857; Mon, 5 Aug 2002 11:13:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07830 for ; Mon, 5 Aug 2002 11:13:57 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16812 for ; Mon, 5 Aug 2002 11:12:44 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-53.cisco.com [161.44.150.53]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA26883; Mon, 5 Aug 2002 11:13:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20020805111044.027a43e0@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Aug 2002 11:13:22 -0400 To: Erik Nordmark From: Paul Duffy Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: Erik Nordmark , Josh Littlefield , Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20020803003222.042cca10@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org At 07:09 AM 8/5/2002 +0200, Erik Nordmark wrote: > > >How does this relate to > > > RFC 2826 IAB Technical Comment on the Unique DNS Root. > > > > Erik, how exactly does a non standard DNS port violate the unique root ? > >I asked that question with the hope the proponents would think about >it carefully. Seems like that failed :-) My understanding is that the namespace supported by a DNS server and the port the DNS protocol run on are orthogonal. >It seems to me that the DNS as we know it operates on a well-know >port. Being able to run something using the DNS protocol but >a different port number sounds like being able to run >a different naming system with potentially a different root. > > > Security is not Cablelab's primary argument here (recall it was #3 in the > > previous email). The primary argument is to provide flexibility to our > > customers. > >But ignoring the testing argument (which is an argument >for an experimental RFC and not a standard IMHO) >the remaining arguments are: > >2. Some MSO's may decide to deploy DNS on non standard ports. Its a > >flexibility issue. > >3. Not using a standard port makes it slightly less prone to attack by > >script kiddies. > >#2 doesn't state why folks see this need. One possibility is >definitely walled gardens and in general using a different DNS >tree than the rest of us. I've yet to see any other concrete reason >for this (and I don't buy flexibility for its own sake). > >And #3 is just security through obscurity which we IMHO have no >business promoting in our standards. > > Erik -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 5 11:23:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17271; Mon, 5 Aug 2002 11:23:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08457; Mon, 5 Aug 2002 11:22:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08434 for ; Mon, 5 Aug 2002 11:22:09 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17200 for ; Mon, 5 Aug 2002 11:20:57 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-82.cisco.com [161.44.150.82]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA27438; Mon, 5 Aug 2002 11:21:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20020805111758.034cfb18@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Aug 2002 11:21:32 -0400 To: Erik Nordmark From: Ralph Droms Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: Paul Duffy , Erik Nordmark , Josh Littlefield , Thomas Narten , "Bernie Volz (EUD)" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20020803003222.042cca10@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org How does configuring DNS on a specified port number provide any additional ability to provide a DNS service with a different root than configuring the client DNS resolver with a specific set of DNS resolvers through DHCP? - Ralph At 07:09 AM 8/5/2002 +0200, Erik Nordmark wrote: > > >How does this relate to > > > RFC 2826 IAB Technical Comment on the Unique DNS Root. > > > > Erik, how exactly does a non standard DNS port violate the unique root ? > >I asked that question with the hope the proponents would think about >it carefully. Seems like that failed :-) > >It seems to me that the DNS as we know it operates on a well-know >port. Being able to run something using the DNS protocol but >a different port number sounds like being able to run >a different naming system with potentially a different root. [...] > Erik > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 5 13:08:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22484; Mon, 5 Aug 2002 13:08:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16038; Mon, 5 Aug 2002 13:07:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16017 for ; Mon, 5 Aug 2002 13:07:53 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22456 for ; Mon, 5 Aug 2002 13:06:41 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-53.cisco.com [161.44.150.53]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04870; Mon, 5 Aug 2002 13:07:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20020805114944.028e2778@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Aug 2002 13:07:17 -0400 To: Erik Nordmark From: Paul Duffy Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Cc: Erik Nordmark , Josh Littlefield , Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20020803003222.042cca10@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Erik...inline please.... > >2. Some MSO's may decide to deploy DNS on non standard ports. Its a > >flexibility issue. > >3. Not using a standard port makes it slightly less prone to attack by > >script kiddies. > >#2 doesn't state why folks see this need. One possibility is >definitely walled gardens and in general using a different DNS >tree than the rest of us. I've yet to see any other concrete reason >for this (and I don't buy flexibility for its own sake). Rich Woundy has very thoughtfully addressed the "walled garden" issue from a service providers point of view. I have to disagree with you on the flexibility issue. Hundreds of thousands, probably millions, of these "headless" EMTA devices will deployed to the field in the next few years. A conservative approach dictates that it should be possible to remotely configure any device parameter that might reasonably be expected to require configuration. We feel the protocol port numbers fall into this category. Remote software upgrades, recall of devices, or a truck roll to the customers premises are very expensive and to be avoided. >And #3 is just security through obscurity which we IMHO have no >business promoting in our standards. Yes, this is a very weak argument. I don't want to leave you with the impression that non default port numbers are a key ingredient of the PacketCable security architecture (strictly speaking, this is not considered part of PacketCable security). PacketCable makes extensive use of Kerberos to authenticate MTAs to the provider network, and IPSec to secure traffic between PacketCable components. If you're curious, see http://www.packetcable.com/specs/PKT-SP-SEC-I05-020116.pdf. Cheers, > Erik -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 5 17:06:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01991; Mon, 5 Aug 2002 17:06:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00140; Mon, 5 Aug 2002 17:06:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14441 for ; Sat, 3 Aug 2002 20:31:44 -0400 (EDT) Received: from TAPAL.alopa.com ([66.89.107.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13233 for ; Sat, 3 Aug 2002 20:30:32 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Date: Sat, 3 Aug 2002 17:29:32 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23B4E.0087098E" Message-ID: <983A033F5C0DE142867DE56300FED8E255A879@localhost> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [dhcwg] DHCP Option for CableLabs Client Configuration Thread-Index: AcI6awP6zFrS85Z2Q6CCU5imCmQBaQA3+EPD From: "Sumanth Channabasappa" To: "Cosmo, Patrick" , "Paul Duffy" , "PacketCable Provisioning and OSS Majordomo List" Cc: "Erik Nordmark" , "Thomas Narten" , "Bernie Volz (EUD)" , "Ralph Droms" , , , , "Matt Osman" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C23B4E.0087098E Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KCVtDb3NtbywgUGF0cmlja10gVGhlIENNIG11c3QgYmUgY29tcGxldGVseSBwcm92 aXNpb25lZCBiZWZvcmUgdGhlIE1UQSBjYW4gKHN1Y2Nlc3NmdWxseSkgZG8gREhDUCwgY29ycmVj dD8gU28gd2h5IGNhbid0IHlvdSBzZW5kIHRoZSBzdWItb3B0aW9uIDEvMiBkYXRhIHRvIHRoZSBD TSBpbiBpdHMgY29uZmlnIGZpbGUgb3IgdGhyb3VnaCBTTk1QLCBhbmQgdGhlbiBsZXQgaXQgcGFz cyBpdCBhbG9uZyB0byB0aGUgTVRBPyANCglbc3VtYW50aF0gTm90IHN1cmUgaWYgSSBjYW4gYW5z d2VyIHRoaXMgLSB0aGVyZSB3ZXJlIHZhcmlvdXMgcG9zc2libGUgd2F5cyBvZiBkb2luZyBpdCwg aG93ZXZlciwgY2hhbmdpbmcgdGhlIERPQ1NJUyBzcGVjIHdhcyBub3QgYSBzb3VnaHQgYWZ0ZXIg b3B0aW9uIGFuZCB3ZSBoYWQgYSBzdWJvcHRpb24gYmVpbmcgaW50cm9kdWNlZCBmb3IgUENCTCB3 aGljaCBjb3VsZCBiZSBlYXNpbHkgcmUtdXNlZCB3aXRoIG1pbmltYWwgY2hhbmdlcy4gQmVzaWRl cyBpdCB3YXMgbm90IG5lY2Vzc2FyeSB0byAncHJvdGVjdCB0aGlzIGluZm8nIGFzIHdlIGhhdmVu dCBhZGRyZXNzZWQgREhDUCBzZWN1cml0eS4NCgkgDQoJIA0KCVlvdSB3YW50IHRvIGVuc3VyZSB0 aGF0IHRoZSBNVEEgZ2V0cyBhIGxpc3Qgb2YgImxlZ2FsIHRlbGVwaG9ueSBESENQIHNlcnZlciBh ZGRyZXNzZXMiLiBUaGlzIGltcGxpZXMgdGhhdCB3aXRob3V0IG9wdHMgMS8yLCB0aGUgTVRBIG1h eSBnZXQgREhDUCBmcm9tIGEgc2VydmVyIG91dHNpZGUgdGhpcyBsaXN0LiBDYW4gYW55b25lIHNh eSB3aGV0aGVyIHRoZXJlIGlzIGEgbWVjaGFuaXNtIHRoYXQgZW5zdXJlcyB0aGUgQ00gb25seSBn ZXRzIERIQ1AgZnJvbSB2YWxpZCBzZXJ2ZXJzIChkb2VzIHRoZSBDTVRTIGVuc3VyZSB0aGlzPyk/ IFRoaXMgcXVlc3Rpb24gaGFzIGFscmVhZHkgYmVlbiBwb3NpdGVkIHRvIFJpY2hhcmQgV291bmR5 LCBidXQgcGVyaGFwcyBzb21lb25lIGVsc2Uga25vd3M/IFlvdSBjYW4ndCBwcm90ZWN0IHRoZSBN VEEgZnJvbSBib2d1cyBESENQIHNlcnZlcnMsIGlmIHlvdSBhcmUgdHJ5aW5nIHRvIGRvIGl0IHVz aW5nIGRhdGEsIGZvcndhcmRlZCBmcm9tIGEgQ00sIHRoYXQgb3JpZ2luYXRlcyBmcm9tIHRob3Nl IHNhbWUgYm9ndXMgREhDUCBzZXJ2ZXJzLiBTaW1pbGFybHksIHRoaXMgb3B0IDEvMiBtZWNoYW5p c20gZG9lcyBub3QgYWxsb3cgdGhlIGFjY2VzcyBwcm92aWRlciB0byBnYWluIHRpZ2h0ZXIgY29u dHJvbCBvdmVyIGl0cyBESENQL0ROUyBpbmZyYXN0cnVjdHVyZSBpZiB0aGUgQ00gY2FuIGdldCBE SENQIGZyb20gc2VydmVycyBvdXRzaWRlIHRoaXMgaW5mcmFzdHJ1Y3R1cmUuDQoJIA0KCVtzdW1h bnRoXSBJIGd1ZXNzIFJpY2ggYW5zd2VyZWQgdGhlIFEgb24gREhDUCBzZXJ2ZXJzLg0KCSANCglI b3dldmVyLCBpbiBjYXNlIG9mIFBhY2tldGNhYmxlIHRoZSBhcmNoaXRlY3R1cmUga2VwdCBpbiBt aW5kIHRoYXQgdGhlcmUgY291bGQgcG90ZW50aWFsbHkgYmUgJ2RpZmZlcmVudCcgZGF0YSBhbmQg dGVsZXBob255IHNlcnZpY2UgcHJvdmlkZXJzJyB1c2luZyB0aGUgc2FtZSAnZW1iZWRkZWQnIGRl dmljZSAoIEVNVEEgKS4gVGhpcyB3b3VsZCBtZWFuIHRoYXQgdGhlICdkYXRhIHNlcnZpY2UgcHJv dmlkZXInIGFuZCB0aGUgJ3RlbGVwaG9ueSBzZXJ2aWNlIHByb3ZpZGVyJyBjb3VsZCB1c2UgZGlm ZmVyZW50ICdiYWNrb2ZmaWNlIGNvbXBvbmVudHMnIC0gd2hpY2ggbWVhbnMgdGhhdCB2YWxpZCBE SENQIHNlcnZlcnMgY2FuDQoJc3RpbGwgYWZmZWN0IGVhY2ggb3RoZXJzIG4vdyAtIGdpdmVuIHRo YXQgdGhlIE1UQXMgY29tZSBmcm9tIGJlaGluZCB0aGUgc2FtZSBNVEEgYW5kIG1vc3RseSByZWNv Z25pc2VkIGFzICdDUEVzJw0KCS0gbWVhbmluZyBtdWx0aXBsZSBESENQIHNlcnZlcnMgbWlnaHQg aGF2ZSB0aGUgc2FtZSBzY29wZXMuDQoJIA0KCVRvIGF2b2lkIGFueSBzdWNoIHNjZW5hcmlvcyBp dCBpcyBhZHZpc2FibGUgdG8gbGV0IHRoZSBNVEEga25vdyB3aGljaCBzZXJ2ZXJzIGl0IGNvdWxk IGFjY2VwdCB0aGUgT0ZGRVJzIGZyb20gYW5kDQoJb2Zjb3Vyc2UgeW91IGNhbiBoYXZlIHZhbHVl cyBsaWtlIDI1NS4yNTUuMjU1LjI1NSBpZiBpdCBkb2VzIG5vdCBhcHBseS4NCgkoIE9mY291cnNl LCB0aGVyZSBhcmUgb3RoZXIgd2F5cyB0byBhY2NvbXBsaXNoIHRoZSBzYW1lIC0gdGhpcyB3YXMg d2hhdCB3YXMgY2hvc2VuICkuIA0KCSANCglyZWdhcmRzDQoJU3VtYW50aA0KCSANCg0K ------_=_NextPart_001_01C23B4E.0087098E Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRy YW5zaXRpb25hbC8vRU4iPgo8SFRNTD48SEVBRD4KCgoKPE1FVEEgY29udGVudD0iTVNIVE1MIDUu NTAuNDkxNi4yMzAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+CjxCT0RZIGRpcj1sdHI+CjxESVY+ PEZPTlQgc2l6ZT0yPkhpLDwvRk9OVD48L0RJVj4KPEJMT0NLUVVPVEUgZGlyPWx0ciBzdHlsZT0i TUFSR0lOLVJJR0hUOiAwcHgiPgogIDxESVY+PEJSPjxTUEFOIGNsYXNzPTI2NTU4MDQyMS0wMjA4 MjAwMj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgCiAgc2l6ZT0yPltDb3NtbywgUGF0 cmlja10mbmJzcDtUaGUgQ00gbXVzdCBiZSBjb21wbGV0ZWx5IHByb3Zpc2lvbmVkIGJlZm9yZSB0 aGUgCiAgTVRBIGNhbiAoc3VjY2Vzc2Z1bGx5KSBkbyBESENQLCBjb3JyZWN0PyBTbyB3aHkgY2Fu J3QgeW91IHNlbmQgdGhlIHN1Yi1vcHRpb24gCiAgMS8yIGRhdGEgdG8gdGhlIENNIGluIGl0cyBj b25maWcgZmlsZSBvciB0aHJvdWdoIFNOTVAsIGFuZCB0aGVuIGxldCBpdCBwYXNzIGl0IAogIGFs b25nIHRvIHRoZSBNVEE/IDwvRk9OVD48L1NQQU4+PC9ESVY+CiAgPERJVj48U1BBTiBjbGFzcz0y NjU1ODA0MjEtMDIwODIwMDI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIAogIHNpemU9 Mj5bc3VtYW50aF0gTm90IHN1cmUgaWYgSSBjYW4gYW5zd2VyIHRoaXMgLSB0aGVyZSB3ZXJlIHZh cmlvdXMgcG9zc2libGUgCiAgd2F5cyBvZiBkb2luZyBpdCwgaG93ZXZlciwgY2hhbmdpbmcgdGhl IERPQ1NJUyBzcGVjIHdhcyBub3QgYSBzb3VnaHQgYWZ0ZXIgCiAgb3B0aW9uIGFuZCB3ZSBoYWQg YSBzdWJvcHRpb24gYmVpbmcgaW50cm9kdWNlZCBmb3IgUENCTCB3aGljaCBjb3VsZCBiZSBlYXNp bHkgCiAgcmUtdXNlZCB3aXRoIG1pbmltYWwgY2hhbmdlcy4gQmVzaWRlcyBpdCB3YXMgbm90IG5l Y2Vzc2FyeSB0byAncHJvdGVjdCB0aGlzIAogIGluZm8nIGFzIHdlIGhhdmVudCBhZGRyZXNzZWQg REhDUCBzZWN1cml0eS48L0ZPTlQ+PC9TUEFOPjwvRElWPgogIDxESVY+PFNQQU4gY2xhc3M9MjY1 NTgwNDIxLTAyMDgyMDAyPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiAKICBzaXplPTI+ PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4KICA8RElWPjxTUEFOIGNsYXNzPTI2NTU4MDQyMS0w MjA4MjAwMj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgCiAgc2l6ZT0yPjwvRk9OVD48 L1NQQU4+Jm5ic3A7PC9ESVY+CiAgPERJVj48U1BBTiBjbGFzcz0yNjU1ODA0MjEtMDIwODIwMDI+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5Zb3UgCiAgd2FudCB0byBlbnN1 cmUgdGhhdCB0aGUgTVRBIGdldHMgYSBsaXN0IG9mICJsZWdhbCB0ZWxlcGhvbnkgREhDUCBzZXJ2 ZXIgCiAgYWRkcmVzc2VzIi4gVGhpcyBpbXBsaWVzIHRoYXQgd2l0aG91dCBvcHRzIDEvMiwgdGhl IE1UQSBtYXkgZ2V0IERIQ1AgZnJvbSBhIAogIHNlcnZlciBvdXRzaWRlIHRoaXMgbGlzdC4gQ2Fu IGFueW9uZSBzYXkgd2hldGhlciB0aGVyZSBpcyBhIG1lY2hhbmlzbSB0aGF0IAogIGVuc3VyZXMg dGhlIENNIG9ubHkgZ2V0cyBESENQIGZyb20gdmFsaWQgc2VydmVycyAoZG9lcyB0aGUgQ01UUyBl bnN1cmUgdGhpcz8pPyAKICBUaGlzIHF1ZXN0aW9uIGhhcyBhbHJlYWR5IGJlZW4gcG9zaXRlZCB0 byBSaWNoYXJkIFdvdW5keSwgYnV0IHBlcmhhcHMgc29tZW9uZSAKICBlbHNlIGtub3dzPyBZb3Ug Y2FuJ3QgcHJvdGVjdCB0aGUgTVRBIGZyb20gYm9ndXMgREhDUCBzZXJ2ZXJzLCBpZiB5b3UgYXJl IAogIHRyeWluZyB0byBkbyBpdCB1c2luZyBkYXRhLCBmb3J3YXJkZWQgZnJvbSBhIENNLCB0aGF0 IG9yaWdpbmF0ZXMgZnJvbSB0aG9zZSAKICBzYW1lIGJvZ3VzIERIQ1Agc2VydmVycy4gU2ltaWxh cmx5LCB0aGlzIG9wdCAxLzIgbWVjaGFuaXNtIGRvZXMgbm90IGFsbG93IHRoZSAKICBhY2Nlc3Mg cHJvdmlkZXImbmJzcDt0byBnYWluIHRpZ2h0ZXIgY29udHJvbCBvdmVyIGl0cyBESENQL0ROUyBp bmZyYXN0cnVjdHVyZSAKICBpZiB0aGUgQ00gY2FuIGdldCBESENQIGZyb20gc2VydmVycyBvdXRz aWRlIHRoaXMgCiAgaW5mcmFzdHJ1Y3R1cmUuPC9GT05UPjwvU1BBTj48L0RJVj4KICA8RElWPjxT UEFOIGNsYXNzPTI2NTU4MDQyMS0wMjA4MjAwMj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+CiAgPERJVj5bc3VtYW50aF0g SSBndWVzcyBSaWNoIGFuc3dlcmVkIHRoZSBRIG9uIERIQ1Agc2VydmVycy48L0RJVj4KICA8RElW PiZuYnNwOzwvRElWPgogIDxESVY+SG93ZXZlciwgaW4gY2FzZSBvZiBQYWNrZXRjYWJsZSB0aGUg YXJjaGl0ZWN0dXJlIGtlcHQgaW4gbWluZCB0aGF0IHRoZXJlIAogIGNvdWxkIHBvdGVudGlhbGx5 IGJlICdkaWZmZXJlbnQnIGRhdGEgYW5kIHRlbGVwaG9ueSBzZXJ2aWNlIHByb3ZpZGVycycgdXNp bmcgCiAgdGhlIHNhbWUgJ2VtYmVkZGVkJyBkZXZpY2UgKCBFTVRBICkuIFRoaXMgd291bGQgbWVh biB0aGF0IHRoZSAnZGF0YSBzZXJ2aWNlIAogIHByb3ZpZGVyJyBhbmQgdGhlICd0ZWxlcGhvbnkg c2VydmljZSBwcm92aWRlcicgY291bGQgdXNlIGRpZmZlcmVudCAnYmFja29mZmljZSAKICBjb21w b25lbnRzJyAtIHdoaWNoIG1lYW5zIHRoYXQgdmFsaWQgREhDUCBzZXJ2ZXJzIGNhbjwvRElWPgog IDxESVY+c3RpbGwgYWZmZWN0IGVhY2ggb3RoZXJzIG4vdyAtIGdpdmVuIHRoYXQgdGhlIE1UQXMg Y29tZSBmcm9tIGJlaGluZCB0aGUgCiAgc2FtZSBNVEEgYW5kIG1vc3RseSByZWNvZ25pc2VkIGFz ICdDUEVzJzwvRElWPgogIDxESVY+LSBtZWFuaW5nIG11bHRpcGxlIERIQ1Agc2VydmVycyBtaWdo dCBoYXZlIHRoZSBzYW1lIHNjb3Blcy48L0RJVj4KICA8RElWPiZuYnNwOzwvRElWPgogIDxESVY+ VG8gYXZvaWQgYW55IHN1Y2ggc2NlbmFyaW9zIGl0IGlzIGFkdmlzYWJsZSB0byBsZXQgdGhlIE1U QSBrbm93IHdoaWNoIAogIHNlcnZlcnMgaXQgY291bGQgYWNjZXB0IHRoZSBPRkZFUnMgZnJvbSBh bmQ8L0RJVj4KICA8RElWPm9mY291cnNlIHlvdSBjYW4gaGF2ZSB2YWx1ZXMgbGlrZSAyNTUuMjU1 LjI1NS4yNTUgaWYgaXQgZG9lcyBub3QgCiAgYXBwbHkuPC9ESVY+CiAgPERJVj4oIE9mY291cnNl LCB0aGVyZSBhcmUgb3RoZXIgd2F5cyB0byBhY2NvbXBsaXNoIHRoZSBzYW1lIC0gdGhpcyB3YXMg d2hhdCAKICB3YXMgY2hvc2VuICkuIDwvRElWPgogIDxESVY+Jm5ic3A7PC9ESVY+CiAgPERJVj5y ZWdhcmRzPC9ESVY+CiAgPERJVj5TdW1hbnRoPC9ESVY+CiAgPERJVj4mbmJzcDs8L0RJVj48L0JM T0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4= ------_=_NextPart_001_01C23B4E.0087098E-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 6 07:28:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05223; Tue, 6 Aug 2002 07:28:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26376; Tue, 6 Aug 2002 07:28:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26338 for ; Tue, 6 Aug 2002 07:28:16 -0400 (EDT) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05143 for ; Tue, 6 Aug 2002 07:27:02 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29653; Tue, 6 Aug 2002 05:28:08 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g76BS6g15270; Tue, 6 Aug 2002 13:28:07 +0200 (MEST) Date: Tue, 6 Aug 2002 13:26:09 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration To: Ralph Droms Cc: Erik Nordmark , Paul Duffy , Josh Littlefield , Thomas Narten , "Bernie Volz (EUD)" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: "Your message with ID" <4.3.2.7.2.20020805111758.034cfb18@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > How does configuring DNS on a specified port number provide any additional > ability to provide a DNS service with a different root than configuring the > client DNS resolver with a specific set of DNS resolvers through DHCP? Ralph, I'm trying to determine what significant operational benefits there are in being able to run DNS on a different port number. I've yet to see any good explanation of this, hence I'm trying to figure out what folks might have had in mind. Better support for walled gardens might have been one thing that some folks might have had in mind. But I really feel a need to see the significant benefits explained. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 6 07:36:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05773; Tue, 6 Aug 2002 07:36:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28429; Tue, 6 Aug 2002 07:37:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28399 for ; Tue, 6 Aug 2002 07:37:08 -0400 (EDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05694 for ; Tue, 6 Aug 2002 07:35:54 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23249; Tue, 6 Aug 2002 04:36:20 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g76BaJg15748; Tue, 6 Aug 2002 13:36:19 +0200 (MEST) Date: Tue, 6 Aug 2002 13:34:22 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration To: Paul Duffy Cc: Erik Nordmark , Josh Littlefield , Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: "Your message with ID" <4.3.2.7.2.20020805114944.028e2778@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > I have to disagree with you on the flexibility issue. Hundreds of > thousands, probably millions, of these "headless" EMTA devices will > deployed to the field in the next few years. A conservative approach > dictates that it should be possible to remotely configure any device > parameter that might reasonably be expected to require configuration. We > feel the protocol port numbers fall into this category. I wouldn't use the term "conservative" to describe this - "frivilous additional complexity for no real benefits" is closer to the words I would use. Following this line of argument one could also argue that there might be a need to run UDP on a protocol number different than the standard 17, etc. IMHO the criteria should be that the additional flexibility indeed fills a real need; not that it might be useful. If this is so critical, why didn't e.g. 3GPP see the need for this when thinking about deploying hundereds of millions of IP capable mobile phones? And what about the hundered million or so computers already using IP? AFAIK there is no mechanism to override the port number used for DNS even using manual configuration on each box. (E.g. configurable in resolv.conf) Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 6 09:22:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10571; Tue, 6 Aug 2002 09:22:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04693; Tue, 6 Aug 2002 09:22:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25584 for ; Tue, 6 Aug 2002 07:25:22 -0400 (EDT) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04925 for ; Tue, 6 Aug 2002 07:24:08 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19255; Tue, 6 Aug 2002 05:25:12 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g76BPBg15121; Tue, 6 Aug 2002 13:25:11 +0200 (MEST) Date: Tue, 6 Aug 2002 13:23:14 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration To: "Woundy, Richard" Cc: "'Erik Nordmark'" , Josh Littlefield , Paul Duffy , Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: "Your message with ID" <6732623D2548D61193C90002A5C88DCC6666B7@entmaexch02.broadband.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > If MTAs communicate at the IP layer only with other systems (MTAs, call > management servers, media gateways, etc.) within the same domain, then it > makes sense to consider using RFC 1918 private addresses for MTA rather than > public addresses. Using private addresses for MTAs is significant in the > case of AT&T Broadband, since this cable operator already has 1,200,000 > telephony subscribers (over broadband cable) today. Note that CableLabs, in > fact, would like cable operators to assign public addresses to MTAs for > interdomain communications... but I'm not sure that ARIN would approve of > that choice given our current generation of products, our (lack of) > interdomain qos expertise, and the large consumption of public addresses > that such a decision would entail. This is tangential to the issues at hand. But I don't think ARIN summarily rejects requests for IPv4 addresses just because the requester can't specify how to interdomain qos; if so they would have to deny most requests for IPv4 addresses. So I think it would actually make sense for the operators to request IPv4 addresses. Of course, part of them problem might be that the operators think RFC 1918 addresses are actually better than the real thing ("more secure" and other misconceptions). > I suppose you might consider what I have described as a "walled garden" for > MTAs. My first reaction is that the end-goal for the PacketCable > architecture is a voice-over-Internet service, not merely a walled garden > service. My second reaction is this -- why does the IETF care about whether > a particular service deployment is a walled garden or not? Do the IETF > standards only support certain business models, and not others? Do the IETF > standards FORBID walled gardens? I thought the IETF was a technical > standards organization, not a business policy standards body. I think what I said was about doing something which only has useful applicability for a walled garden. As far as I can tell there are no technical reasons for running DNS on a different port (except for testing which I've commented on several times already), hence this seem to me as a technically bad idea. I can understand if folks might want it to make it easier to build walled gardens, but I think the IETF should not try to standardize things which are only applicable to walled gardens. Is that more clear? > It would seem rational that, should it makes sense to assign RFC 1918 > private IP addresses to MTAs, and since MTAs require DNS fully qualified > host names as VoIP endpoints in PacketCable (and in SGCP/MGCP, and in SIP), > then RFC 1918 seems to endorse the operation of a parallel DNS > infrastructure for the MTAs and VoIP components. And one way to run a > parallel DNS infrastructure is to use different DNS port numbers for the > VoIP service. This is particularly true for smaller operators, with more > limited capital budgets and smaller VoIP subscriber bases. I suspect many large organizations (but not all) that sit behind a firewall run a two-faced DNS; the DNS database visible from the inside is different than the DNS database visible from the outside. The point is that it is possible to do this without any extra protocols. Given that this is possible I don't see why the IETF needs to provide an additional mechanism to accomplish the same thing. That implies uneeded complexity but also additional risks for non-interoperability (when one system uses one scheme and another system uses another scheme). > P.S. It wasn't originally my idea to put DNS port number configuration into > the CableLabs Client Configuration option, by the way. For a substantial > period of time, I thought it was a "hack". I have only been recently > convinced that there were significant operational advantages to this > configuration parameter. I'd be interested in finding out the significant advantages. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 6 12:46:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18146; Tue, 6 Aug 2002 12:46:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17260; Tue, 6 Aug 2002 12:46:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17236 for ; Tue, 6 Aug 2002 12:46:03 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18052 for ; Tue, 6 Aug 2002 12:44:50 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-82.cisco.com [161.44.150.82]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA21410 for ; Tue, 6 Aug 2002 12:45:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20020806124444.03a90f08@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Aug 2002 12:45:29 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Minutes from Yokohama meeting Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org DHC WG These minutes were prepared from notes taken by Stuart Cheshire and Ted Lemon. Status report ------------- Ralph started the meeting with a WG status report. Ralph announced the publication of "DHCP Auto-configure Option (Option code 116) Deprecated" . It will go to WG last call after publication of as Proposed Standard. Matt Osman, ----------------------------------------------- Matt Osman presented the "DHCP Option for CableLabs Client Configuration". This option will redefine the option 177 currently in use by CableLabs. Q&A: Narten: Why not use vendor-specific options? Droms: Device can only have one vendor identifier; can't specify both vendor and "CableLabs-compatible" as vendor type. Droms: Two issues from chair's point of view: CableLabs wants to work with IETF to generate Internet Standard for function now deployed in option 177 (note that 177 is from the site-defined option code space); this draft proposes a somewhat different mechanism for sub-option code assignment. Narten: Does this option fundamentally change the way DHCP works? WG members should consider that issue when reading the draft. Woundy: CableLabs is not looking for IETF/DHCWG to rubberstamp this draft. CableLabs wants to go through IETF process and standardize the use of this option. The draft had not been read by the WG. Ralph will give the WG two weeks to read the draft (to begin 7/22), and then start WG last call. -------------------------------------- Ralph pointed out the publication of "The Authentication Suboption for the DHCP Relay Agent Option". This draft is a result of a discussion from the Minneapolis DHC WG meeting. There are open issues in the draft that will be discussed on the WG mailing list: hwo does a device that doesn't set 'giaddr' get the response from the DHCP server so the device cna remove its realy agent options; should the DHCP specification be extended to explicitly allow chaining of relay agents (as in DHCPv6)? ---------------------------------- "DHCP Lease Query" is in WG last call. There have been some comments posted during the last call. WG members were requested to further review the draft. ---------------------------------- "Dynamic Host Configuration Protocol (DHCP) Server MIB" is in WG last call. There have been some comments posted during the last call. The authors will respond to the comments and work with Rich Woundy to revise the draft. Q&A: Narten: Deos this MIB have utility? Droms: Every time Barr Hibbs has asked, WG consensus has been to continue work on the MIB. Narten: Does anyone plaen to implement this MIB? Droms: Cisco does. Woundy: CableLabs wants to build embedded DHCP servers in modems. Some tables from this MIB would be useful. Waters: Version -07 seems to have been lost; will work with Hibbs to get versions straightened out. Scanner: The -06 version is quite ISC-specific. Droms: Please submit comments about that issue to the mailing list. , , ------------------------------------------------------------- The ADs have the token for review of "Encoding Long Options in DHCPv4" , "The Classless Static Route Option for DHCPv4" and "DHCP Domain Search Option" . ------------------------------ Ralph announced the status of the DHCPv6 spec: the -26 rev has been reviewed by some IESG members and the authors are preparing a new rev with responses to those reviews. In particular, the WG was alerted to changes in authentication and reconfiguration machinery. Ralph asked the WG to consider two issues: should the DHCPv6 authentication mechanism be identified as a separate authentication protocol wihtin the RFC3118 framework and should the "reconfiguration nonce" option be merged into the RFC 3118 framework. Some support was expressed for the latter suggestion. Ole Troan, ------------------------------------------------------------ Ole Troan gave an update presentation on "IPv6 Prefix Options for DHCPv6" option. Ralph mentioned that the IPv6 WG is working on a set of requirements and a selectin process for prefix delegation. There was some discussion about modifications to the PD option to solve larger scale problems - spec., make PD look more like Identity Association, with an ID and similar semantics. Authors will revise draft to accommodate tat suggestion. Other DHCPv6 option drafts -------------------------- Ralph asked if the WG had reviewed the other DHCPv6 option drafts: DNS Configuration options for DHCPv6 NIS Configuration Options for DHCPv6 Time Configuration Options for DHCPv6 DSTM Options for DHCP Client Preferred Prefix option for DHCPv6 Some discussion of the use of DHCP for service configuration ensued. Do we need a TTL field for service configuration options? Other server controls? What's the problem to be solved? How does T1/T2 not solve this problem today? What's the overlap with the service discovery protocol space? DHC WG Charter -------------- Ralph led a discussion of the WG charter. He did some real-time edits on the charter. He will wordsmith the edits and continue the discussion on the WG mailing list. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 6 16:00:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26785; Tue, 6 Aug 2002 16:00:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28921; Tue, 6 Aug 2002 16:00:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28876 for ; Tue, 6 Aug 2002 16:00:44 -0400 (EDT) Received: from peacock.tci.com (coral.tci.com [198.178.8.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26747 for ; Tue, 6 Aug 2002 15:59:28 -0400 (EDT) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id g76JuOwe007732; Tue, 6 Aug 2002 13:59:31 -0600 (MDT) Received: from 147.191.89.203 by mms01-relaya with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.0)); Tue, 06 Aug 2002 13:58:46 -0600 X-Server-Uuid: 90826C58-91B0-45EB-95A5-46B6D42E456F Received: by entexchimc01.tci.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 6 Aug 2002 13:59:49 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC6666CA@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Erik Nordmark'" cc: "Josh Littlefield" , "Paul Duffy" , "Thomas Narten" , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, "Matt Osman" Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Date: Tue, 6 Aug 2002 13:59:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 114EF5FC157172-03-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Erik, We have some areas of agreement and disagreement. In summary, I think we should see if a "two-faced DNS" solution is practical for the particular problem at hand. Many comments below on your comments. >This is tangential to the issues at hand. But I don't think ARIN >summarily rejects requests for IPv4 addresses just because >the requester can't specify how to interdomain qos; if so they would have >to deny most requests for IPv4 addresses. Today, cable operators (and many other service providers) offer Internet access services to subscribers with public IPv4 addresses allocated from ARIN. It is a best effort service that does not require interdomain qos. That's not the issue here. I think many people would disagree that voice over IP service is effective over a best effort network service. Particularly note that we are leveraging the same regional backbones where we are offering best effort Internet service. Voice over IP traffic may compete for resources for MP3 downloads, kazaa traffic, etc. Of course, some folks would suggest that we service providers should over-provision the bandwidth of our regional backbone links, so that best effort service can be made to work for VoIP -- which is certainly feasible, given sufficient capital and operational expenses. It's just that the financial expenses might crush any hopes of making voice over IP into a viable business. That's part of the reason why the IETF has folks working on RSVP, DiffServ, COPS, etc. My point is more about whether ARIN would agree that the typical PacketCable MTA needs a public IPv4 address. It's hard to justify the need for a public IPv4 address Note that I am *not* suggesting that MTAs operate behind some sort of corporate firewall. In fact, they will co-exist with cable modems and computers (for subscriber Internet access) on the same cable networks. Note that we assign private IPv4 addresses to cable modems today -- primarily at the request of ARIN. Even though the modems enable full-blown, non-walled-garden access to the Internet to computers behind them, the modems themselves are mostly manageable bridges that do not require Internet access (there are a few clever exceptions). >So I think it would actually make sense for the operators to request IPv4 >addresses. Of course, part of them problem might be that the operators >think RFC 1918 addresses are actually better than the real thing ("more secure" >and other misconceptions). I agree with you that RFC 1918 addresses are not "more secure". But since I *am* a cable operator, and obviously part of "the problem", or part of some hidden conspiracy... Nevermind, this isn't a productive or technical line of discussion; we should take this offline. ;^) >I think what I said was about doing something which only has useful >applicability for a walled garden. As far as I can tell there are no >technical reasons for running DNS on a different port (except for testing which >I've commented on several times already), hence this seem to me as a >technically bad idea. I can understand if folks might want it to make it >easier to build walled gardens, but I think the IETF should not try to >standardize things which are only applicable to walled gardens. >Is that more clear? I guess that is more clear. Are you suggesting that if folks in the cable world still believe that there is a requirement to communicate DNS port numbers to MTAs, then they should define an additional Internet draft that is published as Experimental or Informational? Note that the PacketCable specifications themselves, and the long-term intent of the CableLabs Config option, is to enable VoIP services beyond "walled garden" services. We are just talking about part of the DHCP option information in that draft, no? >I suspect many large organizations (but not all) that sit behind a firewall >run a two-faced DNS; the DNS database visible from the inside is different >than the DNS database visible from the outside. >The point is that it is possible to do this without any extra protocols. One difference is that in the firewall example, it is readily apparent which DNS traffic is "internal" versus "external". All "external" traffic comes in from the firewall, or in from an "external" interface. All "internal" traffic comes from a well-defined set of "internet" IPv4 subnets. In the cable networks, the cable modems, computers with Internet access, and MTAs all co-exist on the same cable/DOCSIS subnets. It *is* possible to assign different IPv4 addresses to these different types of devices, which may be something that a two-faced DNS service could leverage. I need to think about whether this approach will scale. >Given that this is possible I don't see why the IETF needs to provide an >additional mechanism to accomplish the same thing. That implies >uneeded complexity but also additional risks for non-interoperability >(when one system uses one scheme and another system uses another scheme). I understand the need and desire to reduce unneeded complexity. I don't quite understand the issue of non-interoperability. If an RFC explains the expected DNS behavior of the MTA, and there are multiple implementations that support that expected DNS behavior in DNS servers, then... what's the issue again? >I'd be interested in finding out the significant advantages. The biggest advantage is that a cable operator could run multiple DNS servers on the same hardware, with separate administrative tools, run by possibly independent operations folks. There would be no issues about the impacts of one DNS service configuration change on the other DNS service. Both DNS services could be verified independently, without the need of performing DNS queries "from the right location for the right test". A two-faced DNS service might be a better alternative; perhaps more complex, but perhaps more in line with how other folks solve similar DNS problems. Let's explore that technical approach further. At least it allows us to avoid the discussion about whether I am part of some grand cable conspiracy... Sigh. ;^) -- Rich _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 6 17:12:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29043; Tue, 6 Aug 2002 17:12:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03913; Tue, 6 Aug 2002 17:12:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03674 for ; Tue, 6 Aug 2002 17:08:07 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28914; Tue, 6 Aug 2002 17:06:49 -0400 (EDT) Message-Id: <200208062106.RAA28914@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: dhcwg@ietf.org From: The IESG Date: Tue, 06 Aug 2002 17:06:49 -0400 Subject: [dhcwg] Protocol Action: The Classless Static Route Option for DHCP to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The IESG has approved the Internet-Draft 'The Classless Static Route Option for DHCP' as a Proposed Standard. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This document defines a new DHCP option, the Classless Static Route Option. The option allows a DHCP server to specify classeless static routes (i.e., address, mask, next-hop router) that a client should install in its routing table. The option supersedes the Static Route option (option 33) defined in RFC2132, which is only defined for classful addresses. Working Group Summary There was support and consensus for this in the WG, and no issues were raised during Last Call Protocol Quality This document has been reviewed for the IESG by Thomas Narten. Note to RFC Editor: Please change the word "supersedes" to "obsoletes" in the first sentence of the introduction. OLD: This option supersedes the Static Route option (option 33) defined in RFC2132 [2]. NEW: This option obsoletes the Static Route option (option 33) defined in RFC2132 [2]. Please change the words "simply valid" to "simply invalid" in the Security Considerations Section. OLD: This can be either a Denial of Service attack, where the router IP address given is simply valid, or can be used to set up a man-in-the-middle attack by providing the IP address of a potential snooper. NEW: This can be either a Denial of Service attack, where the router IP address given is simply invalid, or can be used to set up a man-in-the-middle attack by providing the IP address of a potential snooper. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 8 09:12:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10424; Thu, 8 Aug 2002 09:12:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00243; Thu, 8 Aug 2002 09:10:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00457 for ; Wed, 7 Aug 2002 01:09:41 -0400 (EDT) Received: from medusa.oit.pdx.edu (medusa.oit.pdx.edu [131.252.120.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12699 for ; Wed, 7 Aug 2002 01:08:27 -0400 (EDT) Received: from tomato.oit.pdx.edu (tomato.oit.pdx.edu [131.252.134.138]) by medusa.oit.pdx.edu (8.11.6/8.11.6) with ESMTP id g7759d128896; Tue, 6 Aug 2002 22:09:39 -0700 (PDT) Received: from odin.cc.pdx.edu (localhost [127.0.0.1]) by tomato.oit.pdx.edu (8.11.6/8.11.6) with ESMTP id g7759cH22251; Tue, 6 Aug 2002 22:09:38 -0700 (PDT) Message-ID: <3D50AB92.8030300@odin.cc.pdx.edu> Date: Tue, 06 Aug 2002 22:09:38 -0700 From: Stephen Sutton User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.0) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] dhcp.conf file and failover Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Have two Solaris boxes running Solaris 8 and have installed dhcp-3.0.1rc9 on them. These machines share a test network with a PC. Have been able to start dhcp without the failover text in the dhcp.conf. find the dhcp.conf.5 file confusing. In the example it shows an include for /etc/dhcpd.master but am not sure what would go in this file. My latest attempt looks something like: subnet 10.0.120.0 netmask 255.255.252.0 { pool { failover peer "findon"; deny dynamic bootp clients; max-lease-time 7600; option subnet-mask 255.255.252.0; option routers 10.0.120.10; default-lease-time 7600; range 10.0.120.100 10.0.120.150; } } failover peer "findon" { secondary; address 10.0.120.28; port 519; peer address 10.0.120.29; peer port 520; max-response-delay 60; max-unacked-updates 10; mclt 3600; split 128; load balance max seconds 3; } On starting dhcp this gives me the error: lightstar.oit.pdx.edu dhcpd: /etc/dhcpd.conf line 44: failover peer findon: not found findon is the host name of the primary server. Am in need of some documentaion on how to set up the "dhcp.conf" file for failover. The best information ,so far, has been in the "dhcpd.conf.5" man page. Is there additional documentation on how to set up the dhcpd.conf for failover? Steve -- ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^ ^ Steve Sutton --- steve@odin.pdx.edu ^ -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 8 09:13:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10454; Thu, 8 Aug 2002 09:13:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00215; Thu, 8 Aug 2002 09:10:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28532 for ; Wed, 7 Aug 2002 05:06:23 -0400 (EDT) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10618 for ; Wed, 7 Aug 2002 05:05:05 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03034; Wed, 7 Aug 2002 03:06:04 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g77962g08810; Wed, 7 Aug 2002 11:06:02 +0200 (MEST) Date: Wed, 7 Aug 2002 11:04:05 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration To: "Woundy, Richard" Cc: "'Erik Nordmark'" , Josh Littlefield , Paul Duffy , Thomas Narten , "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman In-Reply-To: "Your message with ID" <6732623D2548D61193C90002A5C88DCC6666CA@entmaexch02.broadband.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Are you suggesting that if folks in the cable world still believe that there > is a requirement to communicate DNS port numbers to MTAs, then they should > define an additional Internet draft that is published as Experimental or > Informational? Depends on the ellusive details. It would be better if they could clearly communicate the requirement so that the IETF can look at it and try to understand what type of reqirement it is and whether or not it is a requirement specific to the cablelabs type of environment. If the requirement is that for testing purposes or experimentation in the cablelabs environments it is useful to be able to use different port numbers for DNS, then a separate info or experimental document would make sense. But I can't yet tell whether this is the case. > Note that the PacketCable specifications themselves, and the long-term > intent of the CableLabs Config option, is to enable VoIP services beyond > "walled garden" services. We are just talking about part of the DHCP option > information in that draft, no? Yes. Thomas had some issues with the other suboptions, but my concerns is about the DNS. > I don't quite understand the issue of non-interoperability. If an RFC > explains the expected DNS behavior of the MTA, and there are multiple > implementations that support that expected DNS behavior in DNS servers, > then... what's the issue again? There is in theory potential interoperability issues both for DHCP and DNS. DHCP: will things operate correctly if the MTA receives a good ol' DNS name server option instead of this suboption? If not you either get all the DHCP servers on the planet to implement the cablelabs option or you could end up with interoperability problems. DNS: will things operate correctly if the MTA is using the standard DNS port? If not you either get all the DNS resolvers on the planet to be configurable to run on an alternate port, you could end up with interoperability problems. Of course, by careful selection of parts (DHCP servers, DNS resolvers) for a cablelabs environment one can avoid these problems. But part of the benefits of the Internet interoperability story is that it doesn't require special versions of protocols and software; things off the shelf just tend to interoperate. This off-the-shelf aspect and the price of equipment that results is often a key perceived benefit of using the internet protocols. So let's think a bit before embarking on paths that break this. > The biggest advantage is that a cable operator could run multiple DNS > servers on the same hardware, with separate administrative tools, run by > possibly independent operations folks. There would be no issues about the > impacts of one DNS service configuration change on the other DNS service. > Both DNS services could be verified independently, without the need of > performing DNS queries "from the right location for the right test". Thank you!!! It's something concrete like this that I've been looking for all along. Have people been thinking about this when there are only two DNS servers on the box (one for the best-effort IP network and one for the VoIP network), or have people also been thinking about outsourcing cases where a single DNS box might provide DNS service for multiple VoIP networks run by different operators? I think understanding whether it can be more than 2 in a box might be important. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 8 10:55:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14506; Thu, 8 Aug 2002 10:55:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06416; Thu, 8 Aug 2002 10:54:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06377 for ; Thu, 8 Aug 2002 10:54:33 -0400 (EDT) Received: from snowmass.tci.com (coral.tci.com [198.178.8.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14461 for ; Thu, 8 Aug 2002 10:53:18 -0400 (EDT) Received: from wsimc06.broadband.att.com (wsimc06.tci.com [147.191.89.209]) by snowmass.tci.com (8.12.2/8.12.2) with SMTP id g78EFPxo002850; Thu, 8 Aug 2002 08:54:25 -0600 (MDT) Received: from 147.191.89.203 by wsimc06.broadband.att.com with SMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Thu, 08 Aug 2002 08:54:40 -0600 X-Server-Uuid: cda7734f-06b2-11d3-bc59-00805fbb2b22 Received: by entexchimc01.tci.com with Internet Mail Service ( 5.5.2653.19) id ; Thu, 8 Aug 2002 08:54:54 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC6666E4@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: dhcwg@ietf.org cc: "Thomas Narten" , "'Erik Nordmark'" , "Matt Osman" , "Woundy, Richard" Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Date: Thu, 8 Aug 2002 08:54:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 114C59BA866410-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit (I trimmed the cc list somewhat) Erik Nordmark and I had an offline conversation yesterday, where we came to the following conclusion. If a service provider (e.g. cable operator) need to run multiple DNS servers on the same server box/chassis, in order to support independent DNS services (e.g. one for Internet access, another for Voice over IP), then we can assume that the service provider can run multiple DNS servers "bound" to different IP addresses assigned to the box/chassis, rather than "bound" to different UDP ports for DNS services. That is, each new DNS server on the same box/chassis costs another unique IP address. For a concrete instantiation of this assumed functionality, please consider the BIND documentation for the "listen-on" configuration option, e.g. section 6.2.14.4 of . It would be helpful to hear about other DNS servers with this capability. Following this assumption, my understanding is that the authors of the CableLabs Client Configuration DHCP option internet-draft will remove the domain name server address suboptions (4 and 5) from the next version of the draft, and the PacketCable VoIP endpoints (aka MTAs, sorry Ted ;^) will use standard DHCP option 6 to obtain domain name server addresses. If there is a need for many DNS servers to be co-located on the same box/chassis (which does not appear to be the case today), consuming an unreasonable number of unique IP addresses, then the issue of configuring non-standard DNS port numbers for clients might be revisited, perhaps in a wider context than just cable networks. Please respond to this email if these assumptions are incorrect -- especially if this isn't going to work! -- Rich -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Wednesday, August 07, 2002 5:04 AM To: Woundy, Richard Cc: 'Erik Nordmark'; Josh Littlefield; Paul Duffy; Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration > Are you suggesting that if folks in the cable world still believe that there > is a requirement to communicate DNS port numbers to MTAs, then they should > define an additional Internet draft that is published as Experimental or > Informational? Depends on the ellusive details. It would be better if they could clearly communicate the requirement so that the IETF can look at it and try to understand what type of reqirement it is and whether or not it is a requirement specific to the cablelabs type of environment. If the requirement is that for testing purposes or experimentation in the cablelabs environments it is useful to be able to use different port numbers for DNS, then a separate info or experimental document would make sense. But I can't yet tell whether this is the case. > Note that the PacketCable specifications themselves, and the long-term > intent of the CableLabs Config option, is to enable VoIP services beyond > "walled garden" services. We are just talking about part of the DHCP option > information in that draft, no? Yes. Thomas had some issues with the other suboptions, but my concerns is about the DNS. > I don't quite understand the issue of non-interoperability. If an RFC > explains the expected DNS behavior of the MTA, and there are multiple > implementations that support that expected DNS behavior in DNS servers, > then... what's the issue again? There is in theory potential interoperability issues both for DHCP and DNS. DHCP: will things operate correctly if the MTA receives a good ol' DNS name server option instead of this suboption? If not you either get all the DHCP servers on the planet to implement the cablelabs option or you could end up with interoperability problems. DNS: will things operate correctly if the MTA is using the standard DNS port? If not you either get all the DNS resolvers on the planet to be configurable to run on an alternate port, you could end up with interoperability problems. Of course, by careful selection of parts (DHCP servers, DNS resolvers) for a cablelabs environment one can avoid these problems. But part of the benefits of the Internet interoperability story is that it doesn't require special versions of protocols and software; things off the shelf just tend to interoperate. This off-the-shelf aspect and the price of equipment that results is often a key perceived benefit of using the internet protocols. So let's think a bit before embarking on paths that break this. > The biggest advantage is that a cable operator could run multiple DNS > servers on the same hardware, with separate administrative tools, run by > possibly independent operations folks. There would be no issues about the > impacts of one DNS service configuration change on the other DNS service. > Both DNS services could be verified independently, without the need of > performing DNS queries "from the right location for the right test". Thank you!!! It's something concrete like this that I've been looking for all along. Have people been thinking about this when there are only two DNS servers on the box (one for the best-effort IP network and one for the VoIP network), or have people also been thinking about outsourcing cases where a single DNS box might provide DNS service for multiple VoIP networks run by different operators? I think understanding whether it can be more than 2 in a box might be important. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 8 11:01:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14777; Thu, 8 Aug 2002 11:01:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07322; Thu, 8 Aug 2002 11:02:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07291 for ; Thu, 8 Aug 2002 11:02:41 -0400 (EDT) Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14744 for ; Thu, 8 Aug 2002 11:01:26 -0400 (EDT) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 17coTU-0006oH-00; Thu, 08 Aug 2002 07:41:16 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 08:11:34 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198692F6D@homer.incognito.com.> From: "Cosmo, Patrick" To: "'Woundy, Richard'" , dhcwg@ietf.org Cc: Thomas Narten , "'Erik Nordmark'" , Matt Osman Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration Date: Thu, 8 Aug 2002 08:11:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23EED.E13B0CF0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23EED.E13B0CF0 Content-Type: text/plain; charset="iso-8859-1" >For a concrete instantiation of this >assumed functionality, please consider >the BIND documentation for the "listen >-on" configuration option, e.g. >section 6.2.14.4 of >. >It would be helpful to hear about >other DNS servers with this capability. Incognito's DNS Commander has this capability (www.incognito.com) -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Wednesday, August 07, 2002 5:04 AM To: Woundy, Richard Cc: 'Erik Nordmark'; Josh Littlefield; Paul Duffy; Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; nrussell@cisco.com; pgrossma@cisco.com; Matt Osman Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration > Are you suggesting that if folks in the cable world still believe that there > is a requirement to communicate DNS port numbers to MTAs, then they should > define an additional Internet draft that is published as Experimental or > Informational? Depends on the ellusive details. It would be better if they could clearly communicate the requirement so that the IETF can look at it and try to understand what type of reqirement it is and whether or not it is a requirement specific to the cablelabs type of environment. If the requirement is that for testing purposes or experimentation in the cablelabs environments it is useful to be able to use different port numbers for DNS, then a separate info or experimental document would make sense. But I can't yet tell whether this is the case. > Note that the PacketCable specifications themselves, and the long-term > intent of the CableLabs Config option, is to enable VoIP services beyond > "walled garden" services. We are just talking about part of the DHCP option > information in that draft, no? Yes. Thomas had some issues with the other suboptions, but my concerns is about the DNS. > I don't quite understand the issue of non-interoperability. If an RFC > explains the expected DNS behavior of the MTA, and there are multiple > implementations that support that expected DNS behavior in DNS servers, > then... what's the issue again? There is in theory potential interoperability issues both for DHCP and DNS. DHCP: will things operate correctly if the MTA receives a good ol' DNS name server option instead of this suboption? If not you either get all the DHCP servers on the planet to implement the cablelabs option or you could end up with interoperability problems. DNS: will things operate correctly if the MTA is using the standard DNS port? If not you either get all the DNS resolvers on the planet to be configurable to run on an alternate port, you could end up with interoperability problems. Of course, by careful selection of parts (DHCP servers, DNS resolvers) for a cablelabs environment one can avoid these problems. But part of the benefits of the Internet interoperability story is that it doesn't require special versions of protocols and software; things off the shelf just tend to interoperate. This off-the-shelf aspect and the price of equipment that results is often a key perceived benefit of using the internet protocols. So let's think a bit before embarking on paths that break this. > The biggest advantage is that a cable operator could run multiple DNS > servers on the same hardware, with separate administrative tools, run by > possibly independent operations folks. There would be no issues about the > impacts of one DNS service configuration change on the other DNS service. > Both DNS services could be verified independently, without the need of > performing DNS queries "from the right location for the right test". Thank you!!! It's something concrete like this that I've been looking for all along. Have people been thinking about this when there are only two DNS servers on the box (one for the best-effort IP network and one for the VoIP network), or have people also been thinking about outsourcing cases where a single DNS box might provide DNS service for multiple VoIP networks run by different operators? I think understanding whether it can be more than 2 in a box might be important. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C23EED.E13B0CF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCP Option for CableLabs Client = Configuration

>For a concrete instantiation of this
>assumed functionality, please consider
>the BIND documentation for the = "listen
>-on" configuration option, e.g.
>section 6.2.14.4 of
><http://www.nominum.com/resources/documentation/Bv9ARM.= pdf>.
>It would be helpful to hear about
>other DNS servers with this capability.

Incognito's DNS Commander has this capability = (www.incognito.com)




-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]<= /FONT>
Sent: Wednesday, August 07, 2002 5:04 AM
To: Woundy, Richard
Cc: 'Erik Nordmark'; Josh Littlefield; Paul Duffy; = Thomas Narten; Bernie
Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; = nrussell@cisco.com;
pgrossma@cisco.com; Matt Osman
Subject: RE: [dhcwg] DHCP Option for CableLabs = Client Configuration


> Are you suggesting that if folks in the cable = world still believe that
there
> is a requirement to communicate DNS port = numbers to MTAs, then they should
> define an additional Internet draft that is = published as Experimental or
> Informational?

Depends on the ellusive details.

It would be better if they could clearly communicate = the requirement so that
the IETF can look at it and try to understand what = type of reqirement it
is and whether or not it is a requirement specific = to the cablelabs type
of environment.

If the requirement is that for testing purposes or = experimentation
in the cablelabs environments it is useful to be = able to use different port
numbers for DNS, then a separate info or = experimental document would make
sense. But I can't yet tell whether this is the = case.

> Note that the PacketCable specifications = themselves, and the long-term
> intent of the CableLabs Config option, is to = enable VoIP services beyond
> "walled garden" services. We are just = talking about part of the DHCP
option
> information in that draft, no?

Yes. Thomas had some issues with the other = suboptions, but my concerns
is about the DNS.

> I don't quite understand the issue of = non-interoperability. If an RFC
> explains the expected DNS behavior of the MTA, = and there are multiple
> implementations that support that expected DNS = behavior in DNS servers,
> then... what's the issue again?

There is in theory potential interoperability issues = both for DHCP and DNS.
DHCP: will things operate correctly if the MTA = receives a good ol' DNS
name server option instead of this suboption? If not = you either get all
the DHCP servers on the planet to implement the = cablelabs option or you
could
end up with interoperability problems.
DNS: will things operate correctly if the MTA is = using the standard DNS
port?
If not you either get all the DNS resolvers on the = planet to be configurable
to run on an alternate port, you could end up with = interoperability
problems.

Of course, by careful selection of parts (DHCP = servers, DNS resolvers) for
a cablelabs environment one can avoid these = problems. But part of the
benefits
of the Internet interoperability story is that it = doesn't require special
versions of protocols and software; things off the = shelf just tend to
interoperate. This off-the-shelf aspect and the = price of equipment that
results is often a key perceived benefit of using = the internet protocols.
So let's think a bit before embarking on paths that = break this.

> The biggest advantage is that a cable operator = could run multiple DNS
> servers on the same hardware, with separate = administrative tools, run by
> possibly independent operations folks. There = would be no issues about the
> impacts of one DNS service configuration change = on the other DNS service.
> Both DNS services could be verified = independently, without the need of
> performing DNS queries "from the right = location for the right test".

Thank you!!! It's something concrete like this that = I've been looking for
all along.

Have people been thinking about this when there are = only two DNS servers
on the box (one for the best-effort IP network and = one for the VoIP
network),
or have people also been thinking about outsourcing = cases where a
single DNS box might provide DNS service for = multiple VoIP networks run by
different operators? I think understanding whether = it can be more than 2
in a box might be important.

  Erik


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

------_=_NextPart_001_01C23EED.E13B0CF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 8 17:02:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26812; Thu, 8 Aug 2002 17:02:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00676; Thu, 8 Aug 2002 17:02:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15963 for ; Thu, 8 Aug 2002 12:47:27 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19084 for ; Thu, 8 Aug 2002 12:46:11 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g78GkWv19832; Thu, 8 Aug 2002 11:46:32 -0500 (CDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g78Gl8Be000322; Thu, 8 Aug 2002 11:47:08 -0500 (CDT) Date: Thu, 8 Aug 2002 11:47:07 -0500 Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Matt Osman , pgrossma@cisco.com, nrussell@cisco.com, dhcwg@ietf.org, "'Ralph Droms'" , "Bernie Volz (EUD)" , Thomas Narten , Paul Duffy , Josh Littlefield , "Woundy, Richard" To: Erik Nordmark From: Ted Lemon In-Reply-To: Message-Id: <79FE7C86-AAEE-11D6-8B54-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > There is in theory potential interoperability issues both for DHCP and DNS. > DHCP: will things operate correctly if the MTA receives a good ol' DNS > name server option instead of this suboption? If not you either get all > the DHCP servers on the planet to implement the cablelabs option or you > could > end up with interoperability problems. It is always a risk that a DHCP server administrator will configure the DHCP server incorrectly. This is an example of an incorrect configuration. There is nothing that you can do in the protocol to prevent an incorrect configuration. For example, if I configure my DNS server to do TSIG updates, but I put the wrong TSIG key data on the client, the update inexplicably doesn't work. As the administrator, I just have to figure that out and fix it. The protocol can't help me - it has no way to report that the signature didn't verify, because an invalid signature means the packet should be tossed. Is this a bug in the protocol? (I don't think so!) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 9 12:30:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02471; Fri, 9 Aug 2002 12:30:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06856; Fri, 9 Aug 2002 12:31:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03611 for ; Fri, 9 Aug 2002 11:59:05 -0400 (EDT) Received: from web13905.mail.yahoo.com (web13905.mail.yahoo.com [216.136.175.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01228 for ; Fri, 9 Aug 2002 11:57:47 -0400 (EDT) Message-ID: <20020809155901.47933.qmail@web13905.mail.yahoo.com> Received: from [207.193.172.226] by web13905.mail.yahoo.com via HTTP; Fri, 09 Aug 2002 08:59:01 PDT Date: Fri, 9 Aug 2002 08:59:01 -0700 (PDT) From: Ryan Scripps Reply-To: RyanScripps@alumni.utexas.net Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration To: "Woundy, Richard" , dhcwg@ietf.org Cc: Thomas Narten , "'Erik Nordmark'" , Matt Osman , "Woundy, Richard" In-Reply-To: <6732623D2548D61193C90002A5C88DCC6666E4@entmaexch02.broadband.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org (My first mail to this group.) After following this discussion for some time, I have a few opinions. First, if there is a need to run DNS in a manner that differs from the current RFC for DNS then it should be addressed as a DNS issue. DHCP serves to enable hosts to operate on a network and should support the standards for the services that DHCP servers are expected to "tell" their clients about. In regard to altering the DNS standard, I feel that there are plenty of administrative options available in the current implementation to support alternative name queries. (Create a new namespace and assign it to the VoIP administrators.) I have not read much on QoS so I could be way off base here, but perhaps DNS packets could be tagged with a higher priority when coming from a VoIP endpoint or other critical systems. A solution thazt falls within the current standrds is certainly preferable to creating a new standard. Care should be taken when creating a standard specific to a specific implmentation. At the very least condsideration should be made as to the portability of this change to other vendor's systems. Ryan Scripps RyanScripps@alumni.utexas.net --- "Woundy, Richard" wrote: > (I trimmed the cc list somewhat) > > Erik Nordmark and I had an offline conversation > yesterday, where we came to > the following conclusion. If a service provider > (e.g. cable operator) need > to run multiple DNS servers on the same server > box/chassis, in order to > support independent DNS services (e.g. one for > Internet access, another for > Voice over IP), then we can assume that the service > provider can run > multiple DNS servers "bound" to different IP > addresses assigned to the > box/chassis, rather than "bound" to different UDP > ports for DNS services. > That is, each new DNS server on the same box/chassis > costs another unique IP > address. > > For a concrete instantiation of this assumed > functionality, please consider > the BIND documentation for the "listen-on" > configuration option, e.g. > section 6.2.14.4 of > . > It would be > helpful to hear about other DNS servers with this > capability. > > Following this assumption, my understanding is that > the authors of the > CableLabs Client Configuration DHCP option > internet-draft will remove the > domain name server address suboptions (4 and 5) from > the next version of the > draft, and the PacketCable VoIP endpoints (aka MTAs, > sorry Ted ;^) will use > standard DHCP option 6 to obtain domain name server > addresses. > > If there is a need for many DNS servers to be > co-located on the same > box/chassis (which does not appear to be the case > today), consuming an > unreasonable number of unique IP addresses, then the > issue of configuring > non-standard DNS port numbers for clients might be > revisited, perhaps in a > wider context than just cable networks. > > Please respond to this email if these assumptions > are incorrect -- > especially if this isn't going to work! > > -- Rich > > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Wednesday, August 07, 2002 5:04 AM > To: Woundy, Richard > Cc: 'Erik Nordmark'; Josh Littlefield; Paul Duffy; > Thomas Narten; Bernie > Volz (EUD); 'Ralph Droms'; dhcwg@ietf.org; > nrussell@cisco.com; > pgrossma@cisco.com; Matt Osman > Subject: RE: [dhcwg] DHCP Option for CableLabs > Client Configuration > > > > Are you suggesting that if folks in the cable > world still believe that > there > > is a requirement to communicate DNS port numbers > to MTAs, then they should > > define an additional Internet draft that is > published as Experimental or > > Informational? > > Depends on the ellusive details. > > It would be better if they could clearly communicate > the requirement so that > the IETF can look at it and try to understand what > type of reqirement it > is and whether or not it is a requirement specific > to the cablelabs type > of environment. > > If the requirement is that for testing purposes or > experimentation > in the cablelabs environments it is useful to be > able to use different port > numbers for DNS, then a separate info or > experimental document would make > sense. But I can't yet tell whether this is the > case. > > > Note that the PacketCable specifications > themselves, and the long-term > > intent of the CableLabs Config option, is to > enable VoIP services beyond > > "walled garden" services. We are just talking > about part of the DHCP > option > > information in that draft, no? > > Yes. Thomas had some issues with the other > suboptions, but my concerns > is about the DNS. > > > I don't quite understand the issue of > non-interoperability. If an RFC > > explains the expected DNS behavior of the MTA, and > there are multiple > > implementations that support that expected DNS > behavior in DNS servers, > > then... what's the issue again? > > There is in theory potential interoperability issues > both for DHCP and DNS. > DHCP: will things operate correctly if the MTA > receives a good ol' DNS > name server option instead of this suboption? If not > you either get all > the DHCP servers on the planet to implement the > cablelabs option or you > could > end up with interoperability problems. > DNS: will things operate correctly if the MTA is > using the standard DNS > port? > If not you either get all the DNS resolvers on the > planet to be configurable > to run on an alternate port, you could end up with > interoperability > problems. > > Of course, by careful selection of parts (DHCP > servers, DNS resolvers) for > a cablelabs environment one can avoid these > problems. But part of the > benefits > of the Internet interoperability story is that it > doesn't require special > versions of protocols and software; things off the > shelf just tend to > interoperate. This off-the-shelf aspect and the > price of equipment that > results is often a key perceived benefit of using > the internet protocols. > So let's think a bit before embarking on paths that > break this. > > > The biggest advantage is that a cable operator > could run multiple DNS > > servers on the same hardware, with separate > administrative tools, run by > > possibly independent operations folks. There would > be no issues about the > > impacts of one DNS service configuration change on > the other DNS service. > > Both DNS services could be verified independently, > without the need of > > performing DNS queries "from the right location > for the right test". > > Thank you!!! It's something concrete like this that > I've been looking for > all along. > > Have people been thinking about this when there are > only two DNS servers > on the box (one for the best-effort IP network and > one for the VoIP > network), > or have people also been thinking about outsourcing > cases where a > single DNS box might provide DNS service for > multiple VoIP networks run by > different operators? I think understanding whether > it can be more than 2 > in a box might be important. > > Erik > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 15 09:02:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24433; Thu, 15 Aug 2002 09:02:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27794; Thu, 15 Aug 2002 09:01:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24873 for ; Thu, 15 Aug 2002 08:12:48 -0400 (EDT) Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21707 for ; Thu, 15 Aug 2002 08:11:27 -0400 (EDT) Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.9.3/8.9.3) with ESMTP id PAA11629 for ; Thu, 15 Aug 2002 15:11:56 +0300 (EEST) Received: from ele4114 (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with SMTP id PAA00719 for ; Thu, 15 Aug 2002 15:11:54 +0300 (EET DST) Message-ID: <032501c24455$32ff5b60$725ebc82@ele4114.ele.vtt.fi> From: "=?iso-8859-1?B?UGVra2EgUOTka2v2bmVu?=" To: Date: Thu, 15 Aug 2002 15:13:43 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0322_01C2446E.57F3EC10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Subject: [dhcwg] IPv6 prefix options for DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0322_01C2446E.57F3EC10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! I have a few questions about "IPv6 prefix options for DHCPv6" -draft. Has there been consensus about adding these options to the DHCPv6 = protocol? Which kind of discussion took place at IETF 54 in Yokohama concerning = this draft? Pekka =20 ------=_NextPart_000_0322_01C2446E.57F3EC10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi!
 
I have a few questions about "IPv6 prefix = options for=20 DHCPv6" -draft.
Has there been consensus about adding these options = to the=20 DHCPv6 protocol?
Which kind of discussion took place at IETF 54 = in=20 Yokohama concerning this draft?
 
Pekka
  
------=_NextPart_000_0322_01C2446E.57F3EC10-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 16 10:51:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17775; Fri, 16 Aug 2002 10:51:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05545; Fri, 16 Aug 2002 10:52:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05524 for ; Fri, 16 Aug 2002 10:52:20 -0400 (EDT) Received: from ams2eusosrv15.ams.ops.eu.uu.net (ams2eusosrv15.ams.ops.eu.uu.net [146.188.99.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17759 for ; Fri, 16 Aug 2002 10:50:58 -0400 (EDT) Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv15.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: ams2eusosrv20.ams.ops.eu.uu.net [146.188.99.75]) id QQnced29452 for ; Fri, 16 Aug 2002 14:52:17 GMT Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnced06308 for ; Fri, 16 Aug 2002 14:51:32 GMT Received: from anocserve1.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: anocserve1.ams.ops.eu.uu.net [146.188.99.69]) id QQnced06289 for ; Fri, 16 Aug 2002 14:51:32 GMT Date: Fri, 16 Aug 2002 16:51:32 +0200 (MET DST) From: Sam Critchley X-X-Sender: To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Geographic position option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi, Included below is a draft proposing an option to allow a DHCP server to pass its geographic location to a DHCP client. From RFC 2489: "Preferably, the author will submit the Internet Draft to the DHC Working Group,..." and "The specification is reviewed by the DHC WG (if it exists) or by the IETF." So, I'd be interested in people's comments on this document. What should I do with the document now? Many thanks, Sam Here is the draft: ************************************************************************ Network Working Group Sam Critchley Internet Draft Worldcom, Inc August, 2002 Expires January, 2003 The Geographic Position Option for DHCP Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes a DHCP option in which the geographic position of the DHCP server is passed to the DHCP client in order to allow the client to make use of Location-Based Services. 1. Introduction Mobile telephony networks are able to make use of certain technologies which supply the geographic location of a mobile suscriber's handset to a Location-Based Services (LBS) provider. The mobile subscriber is then able to take advantage of such services as point-of-interest (POI) location, mapping, route-determination, traffic services and location-aware mobile instant messaging. There is currently no standardised mechanism in place to supply a geographic location to Internet hosts not connected to mobile telephony network, including, but not limited to, hosts connecting using IEEE 802.11x wireless protocols, and those connected to wire-based networks but configured with non-static IP addresses. Consequently, these hosts are more limited in their ability to take advantage of LBS, including having to manually enter a geographic position or street address in many cases. This document defines a DHCP option by which a DHCP server can pass its geographical location, in the form of a latitude, longitude and altitude position, to its clients. This document does not seek to define a method to allow a host to pass its location to a LBS server, as there are already in place several standards which propose these mechanisms, such as the Mobile Location Protocol (MLP) developed by the Location Interoperability Forum (LIF), although it does make one security recommendation in this area. Furthermore, this document does not attempt to propose a mechanism which would perform in the same manner as critical emergency location services such as the Enhanced 911 (E-911) service being implemented in US mobile telephony networks, nor does it propose a mechanism to be used for highly accurate positioning applications, such as that provided by the Global Positioning System (GPS). However, the Geographic Position Option for DHCP does propose a mechanism which, in many cases, will provide a position to the same degree of accuracy as that provided by mobile telephony networks' geographic location mechanisms. 2. The Geographic Position Option for DHCP 2.1 DHCP Option field definitions. This option contains the following fields: a) Option Code - TBD b) Option length in bytes c) DHCP Server Geographic Position Sentence 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code = TBD | Length | Geographic Position Sentence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Geographic Position Sentence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2 DHCP Server Geographic Position Sentence The DHCP Server Geographic Position Sentence takes the form of a comma-separated ASCII string of position terms. This is in some ways similar to the format used in the National Marine Electronics Association's NMEA 0183 and NMEA 2000 standards, commonly used by GPS navigation devices for passing location information to other devices. The sentence takes the following form: DHCPPS,A,B,C,D,E,F,G,H,I,J,K Where the following are field definitions: - DHCPPS - DHCP Position Sentence. Indicates to the DHCP client that this is a sentence designed to provide the geographic position of the DHCP server to the DHCP client, as opposed to any other information. - A - Latitude. Expressed in decimal degrees, to a maximum of 6 decimal places. - B - Latitude N/S. Whether the latitude figure expressed is North or South of the equator, expressed simply as the letter "N" or the letter "S" in upper case. - C - Longitude. Expressed in decimal degrees, to a maximum of 6 decimal places. - D - Longitude E/W. Whether the longitude figure expressed is East or West of the Greenwhich Meridian, expressed simply as the letter "E" or the letter "W" in upper case. - E - Altitude. The altitude, expressed to a maximum of 2 decimal places, and preceded with a "+" or a "-" symbol to indicate whether the value is above mean sea level (positive) or below mean sea level (negative). - F - Altitude unit. The upper-case letter "M" to indicate that the unit is in Metres, or the upper-case letters "FT" to indicate that the unit is in feet. - G - Horizontal Accuracy. The horizontal accuracy of the latitude and longitude position obtained by the DHCP client from the DHCP server. Intended to represent the maximum horizontal distance that a DHCP client will be from its DHCP server, and useful, for example, in the case of DHCP scenarios such as IEEE 802.11b setups using bridging, and where the DHCP client can expect to be some distance from the DHCP server. Figure given to a maximum of three decimal places. - H - Horizontal Accuracy unit. The upper-case letter "M" to indicate that the unit is in metres, the upper-case letters "KM" to indicate that the unit is in kilometres, the upper-case letters "FT" to indicate that the unit is in feet, or the upper-case letters "ML" to indicate that the unit is in miles. - I - Vertical Accuracy. The vertical accuracy of the Altitude position obtained by the DHCP client from the DHCP server. Intended to represent the maximum vertical distance that a DHCP client will be located from its DHCP server, and useful, for example, in the case of network segments located in tall buildings. - J - Vertical Accuracy unit. The upper-case letter "M" to indicate that the unit is in metres, the upper-case letters "KM" to indicate that the unit is in kilometres, the upper-case letters "FT" to indicate that the unit is in feet, or the upper-case letters "ML" to indicate that the unit is in miles. - K - Geodesic Datum. The standard abbreviated form of the geodesic datum used to calculate position. This term has a default value of "WGS84" should no datum be specified. The DHCP Server Geographic Position Sentence would normally have a maximum length of between 49 and 64 bytes, depending on the values used. Apart from the first term of the DHCP Server Geographic Position Sentence, which always must have a value of "DHCPPS", and must be present, the presence of a value in all other fields is optional. However, all fields, whether a value is present or not, must be comma-separated. Furthermore, it is understood that a DHCPPS containing few or no values might be of little use in determining the position of the DHCP client. 2.2.1 Example of a DHCP Server Geographic Position Sentence DHCPPS,52.3742,N,4.8925,E,+3.12,M,50.9,M,5,M,WGS84 This sentence indicates that the DHCP server is located at 52.3742 degrees North, 4.8925 degrees East, at 3.12 metres above mean sea level, that the DHCP client is a maximum of 50.9 metres horizontally from the DHCP server, a maximum of 5 metres altitude above or below the DHCP server, and that the datum used to calculate this position was WGS-84. 2.3 Security Concerns Whilst this document does not seek to define a method to allow a host to pass its location to a LBS server, it does note that there are possible security concerns involved in the location of an Internet host being passed to an LBS server. In the case of mobile telephony networks, most subscriber locations are passed to an LBS server from a mobile provider's location server, not directly from the mobile handset, and the list of permitted LBS servers is strictly controlled. However, in the case of a Geographic Position option for DHCP, this security infrastructure may not be in place, and it is therefore recommended that any client application supplying a DHCP-acquired position to an LBS server should implement an adequate security mechanism to protect users from any possible wrongdoing. Such mechanisms might include implementing a list of permitted LBS servers, popup alerts when passing a host's location to an LBS server, or the ability to turn on/off the passing of location information. 3. Author's Address Sam Critchley Worldcom EMEA Network Service Joan Muyskenweg 22 1096 CJ Amsterdam The Netherlands Phone: +31 20 711 6082 Email: Sam.Critchley@wcom.com *************************************************************************** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 16 11:13:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18544; Fri, 16 Aug 2002 11:13:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06788; Fri, 16 Aug 2002 11:14:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06730 for ; Fri, 16 Aug 2002 11:14:38 -0400 (EDT) Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18536 for ; Fri, 16 Aug 2002 11:13:15 -0400 (EDT) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 17fiSN-00007Q-00; Fri, 16 Aug 2002 07:52:07 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Aug 2002 08:13:39 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A671D5@homer.incognito.com.> From: "Kostur, Andre" To: "'Sam Critchley'" , dhcwg@ietf.org Subject: RE: [dhcwg] Geographic position option Date: Fri, 16 Aug 2002 08:13:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24537.7FA0FD10" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C24537.7FA0FD10 Content-Type: text/plain; charset="iso-8859-1" Just as a thought. Any reason why you picked a GPS-based format instead of perhaps the DNS format for geographical location? (RFC 1712) I was originally going to suggest that the device simply ask the DNS for this information, but the device may want to use this information in selecting which Offer to accept, and as a result has no IP yet so cannot ask the DNS (yet). > -----Original Message----- > From: Sam Critchley [mailto:Sam.Critchley@wcom.com] > Sent: Friday, August 16, 2002 7:52 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Geographic position option > > > > Hi, > > Included below is a draft proposing an option to allow a DHCP > server to > pass its geographic location to a DHCP client. > > From RFC 2489: > > "Preferably, the author will submit the Internet Draft to the > DHC Working > Group,..." > > and > > "The specification is reviewed by the DHC WG (if it exists) or by the > IETF." > > So, I'd be interested in people's comments on this document. > What should I > do with the document now? > > Many thanks, > > > Sam > > > Here is the draft: > > ************************************************************** > ********** > > Network Working Group > Sam Critchley > Internet Draft > Worldcom, Inc > > > August, 2002 > Expires > January, 2003 > > > The Geographic Position Option for DHCP > > > Status of this Memo > > This document is an Internet-Draft and is subject to all provisions > of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as > Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other > documents at any time. It is inappropriate to use Internet- > Drafts as reference material or to cite them other than as > "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/1id-abstracts.html > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html > > Abstract > > This document describes a DHCP option in which the geographic > position of the DHCP server is passed to the DHCP client in order > to allow the client to make use of Location-Based Services. > > 1. Introduction > > Mobile telephony networks are able to make use of certain > technologies which supply the geographic location of a mobile > suscriber's handset to a Location-Based Services (LBS) > provider. The > mobile subscriber is then able to take advantage of such services > as point-of-interest (POI) location, mapping, route-determination, > traffic services and location-aware mobile instant messaging. > > There is currently no standardised mechanism in place to supply > a geographic location to Internet hosts not connected to mobile > telephony network, including, but not limited to, hosts connecting > using IEEE 802.11x wireless protocols, and those connected to > wire-based networks but configured with non-static IP addresses. > Consequently, these hosts are more limited in their ability to > take advantage of LBS, including having to manually enter a > geographic position or street address in many cases. > > This document defines a DHCP option by which a DHCP server can pass > its geographical location, in the form of a latitude, longitude and > altitude position, to its clients. > > This document does not seek to define a method to allow a host to > pass its location to a LBS server, as there are already in place > several standards which propose these mechanisms, such as > the Mobile > Location Protocol (MLP) developed by the Location Interoperability > Forum (LIF), although it does make one security recommendation in > this area. > > Furthermore, this document does not attempt to propose a mechanism > which would perform in the same manner as critical > emergency location > services such as the Enhanced 911 (E-911) service being implemented > in US mobile telephony networks, nor does it propose a mechanism > to be used for highly accurate positioning applications, > such as that provided by the Global Positioning System (GPS). > > However, the Geographic Position Option for DHCP does propose a > mechanism which, in many cases, will provide a position to the same > degree of accuracy as that provided by mobile telephony networks' > geographic location mechanisms. > > 2. The Geographic Position Option for DHCP > > 2.1 DHCP Option field definitions. > > This option contains the following fields: > > a) Option Code - TBD > b) Option length in bytes > c) DHCP Server Geographic Position Sentence > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Code = TBD | Length | Geographic Position Sentence | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Geographic Position Sentence | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | . . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | . . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 2.2 DHCP Server Geographic Position Sentence > > The DHCP Server Geographic Position Sentence takes the form of a > comma-separated ASCII string of position terms. This is in > some ways > similar to the format used in the National Marine Electronics > Association's NMEA 0183 and NMEA 2000 standards, commonly used by > GPS navigation devices for passing location information to other > devices. > > The sentence takes the following form: > > DHCPPS,A,B,C,D,E,F,G,H,I,J,K > > Where the following are field definitions: > > - DHCPPS - DHCP Position Sentence. Indicates to the DHCP > client that > this is a sentence designed to provide the geographic position of > the DHCP server to the DHCP client, as opposed to any other > information. > > - A - Latitude. Expressed in decimal degrees, to a maximum of 6 > decimal places. > > - B - Latitude N/S. Whether the latitude figure expressed > is North or > South of the equator, expressed simply as the letter "N" or the > letter "S" in upper case. > > - C - Longitude. Expressed in decimal degrees, to a maximum of 6 > decimal places. > > - D - Longitude E/W. Whether the longitude figure expressed is East > or West of the Greenwhich Meridian, expressed simply as the letter > "E" or the letter "W" in upper case. > > - E - Altitude. The altitude, expressed to a maximum of 2 decimal > places, and preceded with a "+" or a "-" symbol to indicate whether > the value is above mean sea level (positive) or below mean > sea level > (negative). > > - F - Altitude unit. The upper-case letter "M" to indicate that the > unit is in Metres, or the upper-case letters "FT" to indicate that > the unit is in feet. > > - G - Horizontal Accuracy. The horizontal accuracy of the latitude > and longitude position obtained by the DHCP client from the DHCP > server. Intended to represent the maximum horizontal distance that > a DHCP client will be from its DHCP server, and useful, > for example, > in the case of DHCP scenarios such as IEEE 802.11b setups using > bridging, and where the DHCP client can expect to be some distance > from the DHCP server. Figure given to a maximum of three decimal > places. > > - H - Horizontal Accuracy unit. The upper-case letter "M" > to indicate > that the unit is in metres, the upper-case letters "KM" to indicate > that the unit is in kilometres, the upper-case letters "FT" to > indicate that the unit is in feet, or the upper-case > letters "ML" to > indicate that the unit is in miles. > > - I - Vertical Accuracy. The vertical accuracy of the Altitude > position obtained by the DHCP client from the DHCP server. Intended > to represent the maximum vertical distance that a DHCP > client will be > located from its DHCP server, and useful, for example, in the case > of network segments located in tall buildings. > > - J - Vertical Accuracy unit. The upper-case letter "M" to indicate > that the unit is in metres, the upper-case letters "KM" to indicate > that the unit is in kilometres, the upper-case letters "FT" to > indicate that the unit is in feet, or the upper-case > letters "ML" to > indicate that the unit is in miles. > > - K - Geodesic Datum. The standard abbreviated form of the geodesic > datum used to calculate position. This term has a default value of > "WGS84" should no datum be specified. > > The DHCP Server Geographic Position Sentence would normally have a > maximum length of between 49 and 64 bytes, depending on the values > used. > > Apart from the first term of the DHCP Server Geographic Position > Sentence, which always must have a value of "DHCPPS", and must be > present, the presence of a value in all other fields is optional. > However, all fields, whether a value is present or not, must be > comma-separated. Furthermore, it is understood that a DHCPPS > containing few or no values might be of little use in determining > the position of the DHCP client. > > > 2.2.1 Example of a DHCP Server Geographic Position Sentence > > DHCPPS,52.3742,N,4.8925,E,+3.12,M,50.9,M,5,M,WGS84 > > This sentence indicates that the DHCP server is located at 52.3742 > degrees North, 4.8925 degrees East, at 3.12 metres above mean sea > level, that the DHCP client is a maximum of 50.9 metres > horizontally > from the DHCP server, a maximum of 5 metres altitude above or below > the DHCP server, and that the datum used to calculate this position > was WGS-84. > > 2.3 Security Concerns > > Whilst this document does not seek to define a method to allow a > host to pass its location to a LBS server, it does note that > there are possible security concerns involved in the location of > an Internet host being passed to an LBS server. In the > case of mobile > telephony networks, most subscriber locations are passed to an LBS > server from a mobile provider's location server, not directly from > the mobile handset, and the list of permitted LBS servers > is strictly > controlled. However, in the case of a Geographic Position > option for > DHCP, this security infrastructure may not be in place, and it is > therefore recommended that any client application supplying a > DHCP-acquired position to an LBS server should implement > an adequate > security mechanism to protect users from any possible wrongdoing. > Such mechanisms might include implementing a list of permitted LBS > servers, popup alerts when passing a host's location to an LBS > server, or the ability to turn on/off the passing of location > information. > > > 3. Author's Address > > Sam Critchley > Worldcom EMEA Network Service > Joan Muyskenweg 22 > 1096 CJ Amsterdam > The Netherlands > > Phone: +31 20 711 6082 > Email: Sam.Critchley@wcom.com > > ************************************************************** > ************* > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C24537.7FA0FD10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Geographic position option

Just as a thought.  Any reason why you picked a = GPS-based format instead of perhaps the DNS format for geographical = location?  (RFC 1712)  I was originally going to suggest that = the device simply ask the DNS for this information, but the device may = want to use this information in selecting which Offer to accept, and as = a result has no IP yet so cannot ask the DNS (yet).

> -----Original Message-----
> From: Sam Critchley [mailto:Sam.Critchley@wcom.com= ]
> Sent: Friday, August 16, 2002 7:52 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Geographic position = option
>
>
>
> Hi,
>
> Included below is a draft proposing an option = to allow a DHCP
> server to
> pass its geographic location to a DHCP = client.
>
> From RFC 2489:
>
> "Preferably, the author will submit the = Internet Draft to the
> DHC Working
> Group,..."
>
> and
>
> "The specification is reviewed by the DHC = WG (if it exists) or by the
> IETF."
>
> So, I'd be interested in people's comments on = this document.
> What should I
> do with the document now?
>
> Many thanks,
>
>
> Sam
>
>
> Here is the draft:
>
> = **************************************************************
> **********
>
> Network Working = Group           &= nbsp;           &= nbsp;           &= nbsp; 
> Sam Critchley
> Internet = Draft           &= nbsp;           &= nbsp;           &= nbsp;        
> Worldcom, Inc
>
>          = ;            = ;            = ;            = ;            = ;  
> August, 2002
>        &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;       Expires
> January, 2003
>
>
>       =      The Geographic Position Option for DHCP
>          = ;  <draft-critchley-dhc-location-option-00.txt>
>
> Status of this Memo
>
>    This document is an = Internet-Draft and is subject to all provisions
>    of Section 10 of = RFC2026.
>
>    Internet-Drafts are working = documents of the Internet Engineering
>    Task Force (IETF), its areas, = and its working groups.  Note that
>    other groups may also = distribute working documents as
>    Internet-Drafts.
>
>    Internet-Drafts are draft = documents valid for a maximum of six
>    months and may be updated, = replaced, or obsoleted by other
>    documents at any time.  = It is inappropriate to use Internet-
>    Drafts as reference material = or to cite them other than as
>    "work in = progress."
>
>    The list of current = Internet-Drafts can be accessed at
>    http://www.ietf.org/1id-abstracts.html
>
>    The list of Internet-Draft = Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html
>
> Abstract
>
>    This document describes a = DHCP option in which the geographic
>    position of the DHCP server = is passed to the DHCP client in order
>    to allow the client to make = use of Location-Based Services.
>
> 1.    Introduction
>
>    Mobile telephony networks are = able to make use of certain
>    technologies which supply the = geographic location of a mobile
>    suscriber's handset to a = Location-Based Services (LBS)
> provider. The
>    mobile subscriber is then = able to take advantage of such services
>    as point-of-interest (POI) = location, mapping, route-determination,
>    traffic services and = location-aware mobile instant messaging.
>
>    There is currently no = standardised mechanism in place to supply
>    a geographic location to = Internet hosts not connected to mobile
>    telephony network, including, = but not limited to, hosts connecting
>    using IEEE 802.11x wireless = protocols, and those connected to
>    wire-based networks but = configured with non-static IP addresses.
>    Consequently, these hosts are = more limited in their ability to
>    take advantage of LBS, = including having to manually enter a
>    geographic position or street = address in many cases.
>
>    This document defines a DHCP = option by which a DHCP server can pass
>    its geographical location, in = the form of a latitude, longitude and
>    altitude position, to its = clients.
>
>    This document does not seek = to define a method to allow a host to
>    pass its location to a LBS = server, as there are already in place
>    several standards which = propose these mechanisms, such as
> the Mobile
>    Location Protocol (MLP) = developed by the Location Interoperability
>    Forum (LIF), although it does = make one security recommendation in
>    this area.
>
>    Furthermore, this document = does not attempt to propose a mechanism
>    which would perform in the = same manner as critical
> emergency location
>    services such as the Enhanced = 911 (E-911) service being implemented
>    in US mobile telephony = networks, nor does it propose a mechanism
>    to be used for highly = accurate positioning applications,
> such as that   provided by the Global = Positioning System (GPS).
>
>    However, the Geographic = Position Option for DHCP does propose a
>    mechanism which, in many = cases, will provide a position to the same
>    degree of accuracy as that = provided by mobile telephony networks'
>    geographic location = mechanisms.
>
> 2.    The Geographic Position Option = for DHCP
>
> 2.1   DHCP Option field = definitions.
>
>    This option contains the = following fields:
>
>    a) Option Code - TBD
>    b) Option length in = bytes
>    c) DHCP Server Geographic = Position Sentence
>
>     = 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
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>    |   Code =3D = TBD  |    Length     |  = Geographic Position Sentence |
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>    = |            = ;     Geographic Position = Sentence          &nbs= p;       |
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>    = |            = ;            = ;    . . . = .           &nbs= p;           &nbs= p;    |
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>    = |            = ;            = ;    . . . = .           &nbs= p;           &nbs= p;    |
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>
> 2.2   DHCP Server Geographic Position = Sentence
>
>    The DHCP Server Geographic = Position Sentence takes the form of a
>    comma-separated ASCII string = of position terms. This is in
> some ways
>    similar to the format used in = the National Marine Electronics
>    Association's NMEA 0183 and = NMEA 2000 standards, commonly used by
>    GPS navigation devices for = passing location information to other
>    devices.
>
>    The sentence takes the = following form:
>
>    = DHCPPS,A,B,C,D,E,F,G,H,I,J,K
>
>    Where the following are field = definitions:
>
>    - DHCPPS - DHCP Position = Sentence. Indicates to the DHCP
> client that
>    this is a sentence designed = to provide the geographic position of
>    the DHCP server to the DHCP = client, as opposed to any other
>    information.
>
>    - A - Latitude. Expressed in = decimal degrees, to a maximum of 6
>    decimal places.
>
>    - B - Latitude N/S. Whether = the latitude figure expressed
> is North or
>    South of the equator, = expressed simply as the letter "N" or the
>    letter "S" in upper = case.
>
>    - C - Longitude. Expressed in = decimal degrees, to a maximum of 6
>    decimal places.
>
>    - D - Longitude E/W. Whether = the longitude figure expressed is East
>    or West of the Greenwhich = Meridian, expressed simply as the letter
>    "E" or the letter = "W" in upper case.
>
>    - E - Altitude. The altitude, = expressed to a maximum of 2 decimal
>    places, and preceded with a = "+" or a "-" symbol to indicate whether
>    the value is above mean sea = level (positive) or below mean
> sea level
>    (negative).
>
>    - F - Altitude unit. The = upper-case letter "M" to indicate that the
>    unit is in Metres, or the = upper-case letters "FT" to indicate that
>    the unit is in feet.
>
>    - G - Horizontal Accuracy. = The horizontal accuracy of the latitude
>    and longitude position = obtained by the DHCP client from the DHCP
>    server. Intended to represent = the maximum horizontal distance that
>    a DHCP client will be from = its DHCP server, and useful,
> for example,
>    in the case of DHCP scenarios = such as IEEE 802.11b setups using
>    bridging, and where the DHCP = client can expect to be some distance
>    from the DHCP server. Figure = given to a maximum of three decimal
>    places.
>
>    - H - Horizontal Accuracy = unit. The upper-case letter "M"
> to indicate
>    that the unit is in metres, = the upper-case letters "KM" to indicate
>    that the unit is in = kilometres, the upper-case letters "FT" to
>    indicate that the unit is in = feet, or the upper-case
> letters "ML" to
>    indicate that the unit is in = miles.
>
>    - I - Vertical Accuracy. The = vertical accuracy of the Altitude
>    position obtained by the DHCP = client from the DHCP server. Intended
>    to represent the maximum = vertical distance that a DHCP
> client will be
>    located from its DHCP server, = and useful, for example, in the case
>    of network segments located = in tall buildings.
>
>    - J - Vertical Accuracy unit. = The upper-case letter "M" to indicate
>    that the unit is in metres, = the upper-case letters "KM" to indicate
>    that the unit is in = kilometres, the upper-case letters "FT" to
>    indicate that the unit is in = feet, or the upper-case
> letters "ML" to
>    indicate that the unit is in = miles.
>
>    - K - Geodesic Datum. The = standard abbreviated form of the geodesic
>    datum used to calculate = position. This term has a default value of
>    "WGS84" should no = datum be specified.
>
>    The DHCP Server Geographic = Position Sentence would normally have a
>    maximum length of between 49 = and 64 bytes, depending on the values
>    used.
>
>    Apart from the first term of = the DHCP Server Geographic Position
>    Sentence, which always must = have a value of "DHCPPS", and must be
>    present, the presence of a = value in all other fields is optional.
>    However, all fields, whether = a value is present or not, must be
>    comma-separated. Furthermore, = it is understood that a DHCPPS
>    containing few or no values = might be of little use in determining
>    the position of the DHCP = client.
>
>
> 2.2.1 =         Example of a DHCP Server = Geographic Position Sentence
>
>    = DHCPPS,52.3742,N,4.8925,E,+3.12,M,50.9,M,5,M,WGS84
>
>    This sentence indicates that = the DHCP server is located at 52.3742
>    degrees North, 4.8925 degrees = East, at 3.12 metres above mean sea
>    level, that the DHCP client = is a maximum of 50.9 metres
> horizontally
>    from the DHCP server, a = maximum of 5 metres altitude above or below
>    the DHCP server, and that the = datum used to calculate this position
>    was WGS-84.
>
> 2.3   Security Concerns
>
>    Whilst this document does not = seek to define a method to allow a
>    host to pass its location to = a LBS server, it does note that
>    there are possible security = concerns involved in the location of
>    an Internet host being passed = to an LBS server. In the
> case of mobile
>    telephony networks, most = subscriber locations are passed to an LBS
>    server from a mobile = provider's location server, not directly from
>    the mobile handset, and the = list of permitted LBS servers
> is strictly
>    controlled. However, in the = case of a Geographic Position
> option for
>    DHCP, this security = infrastructure may not be in place, and it is
>    therefore recommended that = any client application supplying a
>    DHCP-acquired position to an = LBS server should implement
> an adequate
>    security mechanism to protect = users from any possible wrongdoing.
>    Such mechanisms might include = implementing a list of permitted LBS
>    servers, popup alerts when = passing a host's location to an LBS
>    server, or the ability to = turn on/off the passing of location
>    information.
>
>
> 3.    Author's Address
>
>    Sam Critchley
>    Worldcom EMEA Network = Service
>    Joan Muyskenweg 22
>    1096 CJ Amsterdam
>    The Netherlands
>
>    Phone: +31 20 711 6082
>    Email: = Sam.Critchley@wcom.com
>
> = **************************************************************
> *************
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C24537.7FA0FD10-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 16 11:15:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18619; Fri, 16 Aug 2002 11:15:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06982; Fri, 16 Aug 2002 11:16:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06917 for ; Fri, 16 Aug 2002 11:16:11 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18584 for ; Fri, 16 Aug 2002 11:14:48 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g7GFG8l28591; Fri, 16 Aug 2002 10:16:08 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g7GFG8v00198; Fri, 16 Aug 2002 10:16:08 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Fri, 16 Aug 2002 10:16:08 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D81C@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Sam Critchley'" , dhcwg@ietf.org Subject: RE: [dhcwg] Geographic position option Date: Fri, 16 Aug 2002 10:16:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24536.23ED2B12" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C24536.23ED2B12 Content-Type: text/plain; charset="ISO-8859-1" Sam: If you want to submit this, you need to send it to internet-drafts@ietf.org. (I think they'd prefer an attachment - .txt file - rather than embedded text.) If you want this to be a DHC WG item, you need to request that (which is perhaps exactly why you send the email). You can submit the draft (as an individual contribution) in any case. My questions regarding this draft are: 1. What use is the location of the DHCP server? Isn't there some assumption implied here that the server is "close" to the client and hence the client could use the server's location information as an indication of where it is located (and hence use these location based services)? However, I don't see that the location of a client and the location of a server are necessarily related. Sure, there are lots of instances where they are physically close (such as an office building). But there are many other indicates where they are not (for example in a cable modem environment). And, how does a client determine this? 2. More text on what a client does with this information would be useful. For example, does the client use it as in (1) above or could a client use this to chose a DHCP server (for example, one that it is "closest" to it if it knows its own location)? I'm not sure what value this has, but it would be good to be clear about how clients use this option. 3. Is there any assumption that this positioning information might be extended to other devices? For example, could the DHCP server tell the clients where a DNS server or printer is located? (Why this would be of use I have no idea.) Anyway, can more than one Geographic Position Sentence be specified? If so, how? Please note that DHCP doesn't allow multiple options to be present to represent separate instances of the option (all of the option strings are assumed to be concatenatable). The reason I ask is that the first parameter is "DHCPPS", so by implication this could mean others might be possible. Though, you do say "which always must have a value of "DHCPPS"". Personally, I'm not so sure of the importance of this option. - Bernie -----Original Message----- From: Sam Critchley [mailto:Sam.Critchley@wcom.com] Sent: Friday, August 16, 2002 10:52 AM To: dhcwg@ietf.org Subject: [dhcwg] Geographic position option Hi, Included below is a draft proposing an option to allow a DHCP server to pass its geographic location to a DHCP client. From RFC 2489: "Preferably, the author will submit the Internet Draft to the DHC Working Group,..." and "The specification is reviewed by the DHC WG (if it exists) or by the IETF." So, I'd be interested in people's comments on this document. What should I do with the document now? Many thanks, Sam Here is the draft: ************************************************************************ Network Working Group Sam Critchley Internet Draft Worldcom, Inc August, 2002 Expires January, 2003 The Geographic Position Option for DHCP Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes a DHCP option in which the geographic position of the DHCP server is passed to the DHCP client in order to allow the client to make use of Location-Based Services. 1. Introduction Mobile telephony networks are able to make use of certain technologies which supply the geographic location of a mobile suscriber's handset to a Location-Based Services (LBS) provider. The mobile subscriber is then able to take advantage of such services as point-of-interest (POI) location, mapping, route-determination, traffic services and location-aware mobile instant messaging. There is currently no standardised mechanism in place to supply a geographic location to Internet hosts not connected to mobile telephony network, including, but not limited to, hosts connecting using IEEE 802.11x wireless protocols, and those connected to wire-based networks but configured with non-static IP addresses. Consequently, these hosts are more limited in their ability to take advantage of LBS, including having to manually enter a geographic position or street address in many cases. This document defines a DHCP option by which a DHCP server can pass its geographical location, in the form of a latitude, longitude and altitude position, to its clients. This document does not seek to define a method to allow a host to pass its location to a LBS server, as there are already in place several standards which propose these mechanisms, such as the Mobile Location Protocol (MLP) developed by the Location Interoperability Forum (LIF), although it does make one security recommendation in this area. Furthermore, this document does not attempt to propose a mechanism which would perform in the same manner as critical emergency location services such as the Enhanced 911 (E-911) service being implemented in US mobile telephony networks, nor does it propose a mechanism to be used for highly accurate positioning applications, such as that provided by the Global Positioning System (GPS). However, the Geographic Position Option for DHCP does propose a mechanism which, in many cases, will provide a position to the same degree of accuracy as that provided by mobile telephony networks' geographic location mechanisms. 2. The Geographic Position Option for DHCP 2.1 DHCP Option field definitions. This option contains the following fields: a) Option Code - TBD b) Option length in bytes c) DHCP Server Geographic Position Sentence 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code = TBD | Length | Geographic Position Sentence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Geographic Position Sentence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2 DHCP Server Geographic Position Sentence The DHCP Server Geographic Position Sentence takes the form of a comma-separated ASCII string of position terms. This is in some ways similar to the format used in the National Marine Electronics Association's NMEA 0183 and NMEA 2000 standards, commonly used by GPS navigation devices for passing location information to other devices. The sentence takes the following form: DHCPPS,A,B,C,D,E,F,G,H,I,J,K Where the following are field definitions: - DHCPPS - DHCP Position Sentence. Indicates to the DHCP client that this is a sentence designed to provide the geographic position of the DHCP server to the DHCP client, as opposed to any other information. - A - Latitude. Expressed in decimal degrees, to a maximum of 6 decimal places. - B - Latitude N/S. Whether the latitude figure expressed is North or South of the equator, expressed simply as the letter "N" or the letter "S" in upper case. - C - Longitude. Expressed in decimal degrees, to a maximum of 6 decimal places. - D - Longitude E/W. Whether the longitude figure expressed is East or West of the Greenwhich Meridian, expressed simply as the letter "E" or the letter "W" in upper case. - E - Altitude. The altitude, expressed to a maximum of 2 decimal places, and preceded with a "+" or a "-" symbol to indicate whether the value is above mean sea level (positive) or below mean sea level (negative). - F - Altitude unit. The upper-case letter "M" to indicate that the unit is in Metres, or the upper-case letters "FT" to indicate that the unit is in feet. - G - Horizontal Accuracy. The horizontal accuracy of the latitude and longitude position obtained by the DHCP client from the DHCP server. Intended to represent the maximum horizontal distance that a DHCP client will be from its DHCP server, and useful, for example, in the case of DHCP scenarios such as IEEE 802.11b setups using bridging, and where the DHCP client can expect to be some distance from the DHCP server. Figure given to a maximum of three decimal places. - H - Horizontal Accuracy unit. The upper-case letter "M" to indicate that the unit is in metres, the upper-case letters "KM" to indicate that the unit is in kilometres, the upper-case letters "FT" to indicate that the unit is in feet, or the upper-case letters "ML" to indicate that the unit is in miles. - I - Vertical Accuracy. The vertical accuracy of the Altitude position obtained by the DHCP client from the DHCP server. Intended to represent the maximum vertical distance that a DHCP client will be located from its DHCP server, and useful, for example, in the case of network segments located in tall buildings. - J - Vertical Accuracy unit. The upper-case letter "M" to indicate that the unit is in metres, the upper-case letters "KM" to indicate that the unit is in kilometres, the upper-case letters "FT" to indicate that the unit is in feet, or the upper-case letters "ML" to indicate that the unit is in miles. - K - Geodesic Datum. The standard abbreviated form of the geodesic datum used to calculate position. This term has a default value of "WGS84" should no datum be specified. The DHCP Server Geographic Position Sentence would normally have a maximum length of between 49 and 64 bytes, depending on the values used. Apart from the first term of the DHCP Server Geographic Position Sentence, which always must have a value of "DHCPPS", and must be present, the presence of a value in all other fields is optional. However, all fields, whether a value is present or not, must be comma-separated. Furthermore, it is understood that a DHCPPS containing few or no values might be of little use in determining the position of the DHCP client. 2.2.1 Example of a DHCP Server Geographic Position Sentence DHCPPS,52.3742,N,4.8925,E,+3.12,M,50.9,M,5,M,WGS84 This sentence indicates that the DHCP server is located at 52.3742 degrees North, 4.8925 degrees East, at 3.12 metres above mean sea level, that the DHCP client is a maximum of 50.9 metres horizontally from the DHCP server, a maximum of 5 metres altitude above or below the DHCP server, and that the datum used to calculate this position was WGS-84. 2.3 Security Concerns Whilst this document does not seek to define a method to allow a host to pass its location to a LBS server, it does note that there are possible security concerns involved in the location of an Internet host being passed to an LBS server. In the case of mobile telephony networks, most subscriber locations are passed to an LBS server from a mobile provider's location server, not directly from the mobile handset, and the list of permitted LBS servers is strictly controlled. However, in the case of a Geographic Position option for DHCP, this security infrastructure may not be in place, and it is therefore recommended that any client application supplying a DHCP-acquired position to an LBS server should implement an adequate security mechanism to protect users from any possible wrongdoing. Such mechanisms might include implementing a list of permitted LBS servers, popup alerts when passing a host's location to an LBS server, or the ability to turn on/off the passing of location information. 3. Author's Address Sam Critchley Worldcom EMEA Network Service Joan Muyskenweg 22 1096 CJ Amsterdam The Netherlands Phone: +31 20 711 6082 Email: Sam.Critchley@wcom.com *************************************************************************** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C24536.23ED2B12 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Geographic position option

Sam:

If you want to submit this, you need to send it to = internet-drafts@ietf.org. (I think they'd prefer an attachment - .txt = file - rather than embedded text.)

If you want this to be a DHC WG item, you need to = request that (which is perhaps exactly why you send the email). You can = submit the draft (as an individual contribution) in any = case.

My questions regarding this draft are:
1. What use is the location of the DHCP server? = Isn't there some assumption implied here that the server is = "close" to the client and hence the client could use the = server's location information as an indication of where it is located = (and hence use these location based services)?

However, I don't see that the location of a client = and the location of a server are necessarily related. Sure, there are = lots of instances where they are physically close (such as an office = building). But there are many other indicates where they are not (for = example in a cable modem environment). And, how does a client determine = this?

2. More text on what a client does with this = information would be useful. For example, does the client use it as in = (1) above or could a client use this to chose a DHCP server (for = example, one that it is "closest" to it if it knows its own = location)? I'm not sure what value this has, but it would be good to be = clear about how clients use this option.

3. Is there any assumption that this positioning = information might be extended to other devices? For example, could the = DHCP server tell the clients where a DNS server or printer is located? = (Why this would be of use I have no idea.) Anyway, can more than one = Geographic Position Sentence be specified? If so, how? Please note that = DHCP doesn't allow multiple options to be present to represent separate = instances of the option (all of the option strings are assumed to be = concatenatable).

The reason I ask is that the first parameter is = "DHCPPS", so by implication this could mean others might be = possible. Though, you do say "which always must have a value of = "DHCPPS"".


Personally, I'm not so sure of the importance of this = option.

- Bernie


-----Original Message-----
From: Sam Critchley [mailto:Sam.Critchley@wcom.com= ]
Sent: Friday, August 16, 2002 10:52 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Geographic position option



Hi,

Included below is a draft proposing an option to = allow a DHCP server to
pass its geographic location to a DHCP = client.

From RFC 2489:

"Preferably, the author will submit the Internet = Draft to the DHC Working
Group,..."

and

"The specification is reviewed by the DHC WG (if = it exists) or by the
IETF."

So, I'd be interested in people's comments on this = document. What should I
do with the document now?

Many thanks,


Sam


Here is the draft:

***************************************************************= *********

Network Working = Group           &= nbsp;           &= nbsp;           &= nbsp;  Sam Critchley
Internet = Draft           &= nbsp;           &= nbsp;           &= nbsp;         Worldcom, = Inc

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp; August, 2002
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;    Expires January, 2003


             The Geographic Position Option for = DHCP
           = <draft-critchley-dhc-location-option-00.txt>

Status of this Memo

   This document is an Internet-Draft and = is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of = the Internet Engineering
   Task Force (IETF), its areas, and its = working groups.  Note that
   other groups may also distribute = working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents = valid for a maximum of six
   months and may be updated, replaced, or = obsoleted by other
   documents at any time.  It is = inappropriate to use Internet-
   Drafts as reference material or to cite = them other than as
   "work in progress."

   The list of current Internet-Drafts can = be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow = Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   This document describes a DHCP option in = which the geographic
   position of the DHCP server is passed = to the DHCP client in order
   to allow the client to make use of = Location-Based Services.

1.      Introduction

   Mobile telephony networks are able to = make use of certain
   technologies which supply the = geographic location of a mobile
   suscriber's handset to a Location-Based = Services (LBS) provider. The
   mobile subscriber is then able to take = advantage of such services
   as point-of-interest (POI) location, = mapping, route-determination,
   traffic services and location-aware = mobile instant messaging.

   There is currently no standardised = mechanism in place to supply
   a geographic location to Internet hosts = not connected to mobile
   telephony network, including, but not = limited to, hosts connecting
   using IEEE 802.11x wireless protocols, = and those connected to
   wire-based networks but configured with = non-static IP addresses.
   Consequently, these hosts are more = limited in their ability to
   take advantage of LBS, including having = to manually enter a
   geographic position or street address = in many cases.

   This document defines a DHCP option by = which a DHCP server can pass
   its geographical location, in the form = of a latitude, longitude and
   altitude position, to its = clients.

   This document does not seek to define a = method to allow a host to
   pass its location to a LBS server, as = there are already in place
   several standards which propose these = mechanisms, such as the Mobile
   Location Protocol (MLP) developed by = the Location Interoperability
   Forum (LIF), although it does make one = security recommendation in
   this area.

   Furthermore, this document does not = attempt to propose a mechanism
   which would perform in the same manner = as critical emergency location
   services such as the Enhanced 911 = (E-911) service being implemented
   in US mobile telephony networks, nor = does it propose a mechanism
   to be used for highly accurate = positioning applications, such as that   provided by the = Global Positioning System (GPS).

   However, the Geographic Position Option = for DHCP does propose a
   mechanism which, in many cases, will = provide a position to the same
   degree of accuracy as that provided by = mobile telephony networks'
   geographic location mechanisms.

2.      The Geographic Position = Option for DHCP

2.1     DHCP Option field = definitions.

   This option contains the following = fields:

   a) Option Code - TBD
   b) Option length in bytes
   c) DHCP Server Geographic Position = Sentence

    = 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
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   |   Code =3D TBD  = |    Length     |  Geographic = Position Sentence |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   = |            = ;     Geographic Position = Sentence          &nbs= p;       |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   = |            = ;            = ;    . . . = .           &nbs= p;           &nbs= p;    |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   = |            = ;            = ;    . . . = .           &nbs= p;           &nbs= p;    |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

2.2     DHCP Server Geographic = Position Sentence

   The DHCP Server Geographic Position = Sentence takes the form of a
   comma-separated ASCII string of = position terms. This is in some ways
   similar to the format used in the = National Marine Electronics
   Association's NMEA 0183 and NMEA 2000 = standards, commonly used by
   GPS navigation devices for passing = location information to other
   devices.

   The sentence takes the following = form:

   DHCPPS,A,B,C,D,E,F,G,H,I,J,K

   Where the following are field = definitions:

   - DHCPPS - DHCP Position Sentence. = Indicates to the DHCP client that
   this is a sentence designed to provide = the geographic position of
   the DHCP server to the DHCP client, as = opposed to any other
   information.

   - A - Latitude. Expressed in decimal = degrees, to a maximum of 6
   decimal places.

   - B - Latitude N/S. Whether the latitude = figure expressed is North or
   South of the equator, expressed simply = as the letter "N" or the
   letter "S" in upper = case.

   - C - Longitude. Expressed in decimal = degrees, to a maximum of 6
   decimal places.

   - D - Longitude E/W. Whether the = longitude figure expressed is East
   or West of the Greenwhich Meridian, = expressed simply as the letter
   "E" or the letter = "W" in upper case.

   - E - Altitude. The altitude, expressed = to a maximum of 2 decimal
   places, and preceded with a = "+" or a "-" symbol to indicate whether
   the value is above mean sea level = (positive) or below mean sea level
   (negative).

   - F - Altitude unit. The upper-case = letter "M" to indicate that the
   unit is in Metres, or the upper-case = letters "FT" to indicate that
   the unit is in feet.

   - G - Horizontal Accuracy. The = horizontal accuracy of the latitude
   and longitude position obtained by the = DHCP client from the DHCP
   server. Intended to represent the = maximum horizontal distance that
   a DHCP client will be from its DHCP = server, and useful, for example,
   in the case of DHCP scenarios such as = IEEE 802.11b setups using
   bridging, and where the DHCP client can = expect to be some distance
   from the DHCP server. Figure given to a = maximum of three decimal
   places.

   - H - Horizontal Accuracy unit. The = upper-case letter "M" to indicate
   that the unit is in metres, the = upper-case letters "KM" to indicate
   that the unit is in kilometres, the = upper-case letters "FT" to
   indicate that the unit is in feet, or = the upper-case letters "ML" to
   indicate that the unit is in = miles.

   - I - Vertical Accuracy. The vertical = accuracy of the Altitude
   position obtained by the DHCP client = from the DHCP server. Intended
   to represent the maximum vertical = distance that a DHCP client will be
   located from its DHCP server, and = useful, for example, in the case
   of network segments located in tall = buildings.

   - J - Vertical Accuracy unit. The = upper-case letter "M" to indicate
   that the unit is in metres, the = upper-case letters "KM" to indicate
   that the unit is in kilometres, the = upper-case letters "FT" to
   indicate that the unit is in feet, or = the upper-case letters "ML" to
   indicate that the unit is in = miles.

   - K - Geodesic Datum. The standard = abbreviated form of the geodesic
   datum used to calculate position. This = term has a default value of
   "WGS84" should no datum be = specified.

   The DHCP Server Geographic Position = Sentence would normally have a
   maximum length of between 49 and 64 = bytes, depending on the values
   used.

   Apart from the first term of the DHCP = Server Geographic Position
   Sentence, which always must have a = value of "DHCPPS", and must be
   present, the presence of a value in all = other fields is optional.
   However, all fields, whether a value is = present or not, must be
   comma-separated. Furthermore, it is = understood that a DHCPPS
   containing few or no values might be of = little use in determining
   the position of the DHCP client.


2.2.1   Example of a DHCP Server Geographic = Position Sentence

   = DHCPPS,52.3742,N,4.8925,E,+3.12,M,50.9,M,5,M,WGS84

   This sentence indicates that the DHCP = server is located at 52.3742
   degrees North, 4.8925 degrees East, at = 3.12 metres above mean sea
   level, that the DHCP client is a = maximum of 50.9 metres horizontally
   from the DHCP server, a maximum of 5 = metres altitude above or below
   the DHCP server, and that the datum = used to calculate this position
   was WGS-84.

2.3     Security Concerns

   Whilst this document does not seek to = define a method to allow a
   host to pass its location to a LBS = server, it does note that
   there are possible security concerns = involved in the location of
   an Internet host being passed to an LBS = server. In the case of mobile
   telephony networks, most subscriber = locations are passed to an LBS
   server from a mobile provider's = location server, not directly from
   the mobile handset, and the list of = permitted LBS servers is strictly
   controlled. However, in the case of a = Geographic Position option for
   DHCP, this security infrastructure may = not be in place, and it is
   therefore recommended that any client = application supplying a
   DHCP-acquired position to an LBS server = should implement an adequate
   security mechanism to protect users = from any possible wrongdoing.
   Such mechanisms might include = implementing a list of permitted LBS
   servers, popup alerts when passing a = host's location to an LBS
   server, or the ability to turn on/off = the passing of location
   information.


3.      Author's = Address

   Sam Critchley
   Worldcom EMEA Network Service
   Joan Muyskenweg 22
   1096 CJ Amsterdam
   The Netherlands

   Phone: +31 20 711 6082
   Email: Sam.Critchley@wcom.com

***************************************************************= ************


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

------_=_NextPart_001_01C24536.23ED2B12-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 16 11:41:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19551; Fri, 16 Aug 2002 11:41:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08653; Fri, 16 Aug 2002 11:42:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08633 for ; Fri, 16 Aug 2002 11:42:20 -0400 (EDT) Received: from ams2eusosrv15.ams.ops.eu.uu.net (ams2eusosrv15.ams.ops.eu.uu.net [146.188.99.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19536 for ; Fri, 16 Aug 2002 11:40:57 -0400 (EDT) Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv15.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: ams2eusosrv20.ams.ops.eu.uu.net [146.188.99.75]) id QQnceg19916; Fri, 16 Aug 2002 15:42:15 GMT Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnceg25084; Fri, 16 Aug 2002 15:42:03 GMT Received: from anocserve1.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: anocserve1.ams.ops.eu.uu.net [146.188.99.69]) id QQnceg25075; Fri, 16 Aug 2002 15:42:03 GMT Date: Fri, 16 Aug 2002 17:42:02 +0200 (MET DST) From: Sam Critchley X-X-Sender: To: "Bernie Volz (EUD)" cc: Subject: RE: [dhcwg] Geographic position option In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D81C@EAMBUNT705> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi Bernie, Thanks for the help and the comments. On Fri, 16 Aug 2002, Bernie Volz (EUD) wrote: > Sam: > > If you want to submit this, you need to send it to internet-drafts@ietf.org. (I think they'd prefer an attachment - .txt file - rather than embedded text.) > > If you want this to be a DHC WG item, you need to request that (which is perhaps exactly why you send the email). You can submit the draft (as an individual contribution) in any case. Okay, I guess I'll go with the flow here... although I assume that if I send it to internet-drafts@ietf.org as an individual contribution then at least it gets a URL that people can refer to rather than having to include the text in every message... > > My questions regarding this draft are: > 1. What use is the location of the DHCP server? Isn't there some assumption implied here that the server is "close" to the client and hence the client could use the server's location information as an indication of where it is located (and hence use these location based services)? Sure, this assumption is definitely there. For example, if someone with a laptop and a 802.11b card logged on to an 802.11b AP whilst travelling to a city they weren't familiar with, they could use LBS without having to manually configure their computer. > > However, I don't see that the location of a client and the location of a server are necessarily related. Sure, there are lots of instances where they are physically close (such as an office building). But there are many other indicates where they are not (for example in a cable modem environment). And, how does a client determine this? I agree that in many cases the DHCP server and client will not be geographically close (such as in dial-up access or with cable modems as you say), and it may be preferable to manually input the host's location at the application level. The original reason for writing this draft was following some discussion on an LBS mailing-list, as to whether a similar system would be available for 802.11 mobile devices as for mobile telephony-style devices, which use technologies such as E-OTD and A-GPS to derive location. It turned out that there isn't really a standardised technology to do this, and that there were two options: i) Do something in DHCP ii) Use the NAT setup and a browser environment variable. The disadvantages of the second are that not everyone has a NAT setup, and that http isn't the only service which might want to use LBS. > > 2. More text on what a client does with this information would be useful. For example, does the client use it as in (1) above or could a client use this to chose a DHCP server (for example, one that it is "closest" to it if it knows its own location)? I'm not sure what value this has, but it would be good to be clear about how clients use this option. I think probably the first, rather than the second. What I had in mind was that an application running on the client host would have an interface to the location information, and would be able to use that when presented with a "location request" from a LBS server. Unfortunately I'm not really an expert on the stack required to do that but presumably it would be the same as many IP-based applications? > > 3. Is there any assumption that this positioning information might be extended to other devices? For example, could the DHCP server tell the clients where a DNS server or printer is located? (Why this would be of use I have no idea.) Anyway, can more than one Geographic Position Sentence be specified? If so, how? Please note that DHCP doesn't allow multiple options to be present to represent separate instances of the option (all of the option strings are assumed to be concatenatable). > > The reason I ask is that the first parameter is "DHCPPS", so by implication this could mean others might be possible. Though, you do say "which always must have a value of "DHCPPS"". Well, I only really intended this to be used in a DHCP Server -> Client relationship in order to satisfy the question (initially) of how a mobile 802.11 host might make use of LBS without manual input of location such as street address etc. However, it's possible that there would be other uses. That's also why I put in an option to have a sentence other than "DHCPPS", just in case someone comes up with another one in the future. > Personally, I'm not so sure of the importance of this option. Well, I think there would be demand for this mainly for 802.11a/b/g roaming at the moment. One of the differences between cellular-based roaming for mobile devices and 802.11 is that there's no location mechanism in place for 802.11... the kinds of services this enables are very popular in, for example, South Korea, where over 1 million GPS-enabled handsets are in use already on the KDDI CDMA network. Thanks, Sam > > - Bernie > > > -----Original Message----- > From: Sam Critchley [mailto:Sam.Critchley@wcom.com] > Sent: Friday, August 16, 2002 10:52 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Geographic position option > > > > Hi, > > Included below is a draft proposing an option to allow a DHCP server to > pass its geographic location to a DHCP client. > > >From RFC 2489: > > "Preferably, the author will submit the Internet Draft to the DHC Working > Group,..." > > and > > "The specification is reviewed by the DHC WG (if it exists) or by the > IETF." > > So, I'd be interested in people's comments on this document. What should I > do with the document now? > > Many thanks, > > > Sam > > > Here is the draft: > > ************************************************************************ > > Network Working Group Sam Critchley > Internet Draft Worldcom, Inc > > August, 2002 > Expires January, 2003 > > > The Geographic Position Option for DHCP > > > Status of this Memo > > This document is an Internet-Draft and is subject to all provisions > of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as > Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other > documents at any time. It is inappropriate to use Internet- > Drafts as reference material or to cite them other than as > "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/1id-abstracts.html > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html > > Abstract > > This document describes a DHCP option in which the geographic > position of the DHCP server is passed to the DHCP client in order > to allow the client to make use of Location-Based Services. > > 1. Introduction > > Mobile telephony networks are able to make use of certain > technologies which supply the geographic location of a mobile > suscriber's handset to a Location-Based Services (LBS) provider. The > mobile subscriber is then able to take advantage of such services > as point-of-interest (POI) location, mapping, route-determination, > traffic services and location-aware mobile instant messaging. > > There is currently no standardised mechanism in place to supply > a geographic location to Internet hosts not connected to mobile > telephony network, including, but not limited to, hosts connecting > using IEEE 802.11x wireless protocols, and those connected to > wire-based networks but configured with non-static IP addresses. > Consequently, these hosts are more limited in their ability to > take advantage of LBS, including having to manually enter a > geographic position or street address in many cases. > > This document defines a DHCP option by which a DHCP server can pass > its geographical location, in the form of a latitude, longitude and > altitude position, to its clients. > > This document does not seek to define a method to allow a host to > pass its location to a LBS server, as there are already in place > several standards which propose these mechanisms, such as the Mobile > Location Protocol (MLP) developed by the Location Interoperability > Forum (LIF), although it does make one security recommendation in > this area. > > Furthermore, this document does not attempt to propose a mechanism > which would perform in the same manner as critical emergency location > services such as the Enhanced 911 (E-911) service being implemented > in US mobile telephony networks, nor does it propose a mechanism > to be used for highly accurate positioning applications, such as that provided by the Global Positioning System (GPS). > > However, the Geographic Position Option for DHCP does propose a > mechanism which, in many cases, will provide a position to the same > degree of accuracy as that provided by mobile telephony networks' > geographic location mechanisms. > > 2. The Geographic Position Option for DHCP > > 2.1 DHCP Option field definitions. > > This option contains the following fields: > > a) Option Code - TBD > b) Option length in bytes > c) DHCP Server Geographic Position Sentence > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Code = TBD | Length | Geographic Position Sentence | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Geographic Position Sentence | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | . . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | . . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 2.2 DHCP Server Geographic Position Sentence > > The DHCP Server Geographic Position Sentence takes the form of a > comma-separated ASCII string of position terms. This is in some ways > similar to the format used in the National Marine Electronics > Association's NMEA 0183 and NMEA 2000 standards, commonly used by > GPS navigation devices for passing location information to other > devices. > > The sentence takes the following form: > > DHCPPS,A,B,C,D,E,F,G,H,I,J,K > > Where the following are field definitions: > > - DHCPPS - DHCP Position Sentence. Indicates to the DHCP client that > this is a sentence designed to provide the geographic position of > the DHCP server to the DHCP client, as opposed to any other > information. > > - A - Latitude. Expressed in decimal degrees, to a maximum of 6 > decimal places. > > - B - Latitude N/S. Whether the latitude figure expressed is North or > South of the equator, expressed simply as the letter "N" or the > letter "S" in upper case. > > - C - Longitude. Expressed in decimal degrees, to a maximum of 6 > decimal places. > > - D - Longitude E/W. Whether the longitude figure expressed is East > or West of the Greenwhich Meridian, expressed simply as the letter > "E" or the letter "W" in upper case. > > - E - Altitude. The altitude, expressed to a maximum of 2 decimal > places, and preceded with a "+" or a "-" symbol to indicate whether > the value is above mean sea level (positive) or below mean sea level > (negative). > > - F - Altitude unit. The upper-case letter "M" to indicate that the > unit is in Metres, or the upper-case letters "FT" to indicate that > the unit is in feet. > > - G - Horizontal Accuracy. The horizontal accuracy of the latitude > and longitude position obtained by the DHCP client from the DHCP > server. Intended to represent the maximum horizontal distance that > a DHCP client will be from its DHCP server, and useful, for example, > in the case of DHCP scenarios such as IEEE 802.11b setups using > bridging, and where the DHCP client can expect to be some distance > from the DHCP server. Figure given to a maximum of three decimal > places. > > - H - Horizontal Accuracy unit. The upper-case letter "M" to indicate > that the unit is in metres, the upper-case letters "KM" to indicate > that the unit is in kilometres, the upper-case letters "FT" to > indicate that the unit is in feet, or the upper-case letters "ML" to > indicate that the unit is in miles. > > - I - Vertical Accuracy. The vertical accuracy of the Altitude > position obtained by the DHCP client from the DHCP server. Intended > to represent the maximum vertical distance that a DHCP client will be > located from its DHCP server, and useful, for example, in the case > of network segments located in tall buildings. > > - J - Vertical Accuracy unit. The upper-case letter "M" to indicate > that the unit is in metres, the upper-case letters "KM" to indicate > that the unit is in kilometres, the upper-case letters "FT" to > indicate that the unit is in feet, or the upper-case letters "ML" to > indicate that the unit is in miles. > > - K - Geodesic Datum. The standard abbreviated form of the geodesic > datum used to calculate position. This term has a default value of > "WGS84" should no datum be specified. > > The DHCP Server Geographic Position Sentence would normally have a > maximum length of between 49 and 64 bytes, depending on the values > used. > > Apart from the first term of the DHCP Server Geographic Position > Sentence, which always must have a value of "DHCPPS", and must be > present, the presence of a value in all other fields is optional. > However, all fields, whether a value is present or not, must be > comma-separated. Furthermore, it is understood that a DHCPPS > containing few or no values might be of little use in determining > the position of the DHCP client. > > > 2.2.1 Example of a DHCP Server Geographic Position Sentence > > DHCPPS,52.3742,N,4.8925,E,+3.12,M,50.9,M,5,M,WGS84 > > This sentence indicates that the DHCP server is located at 52.3742 > degrees North, 4.8925 degrees East, at 3.12 metres above mean sea > level, that the DHCP client is a maximum of 50.9 metres horizontally > from the DHCP server, a maximum of 5 metres altitude above or below > the DHCP server, and that the datum used to calculate this position > was WGS-84. > > 2.3 Security Concerns > > Whilst this document does not seek to define a method to allow a > host to pass its location to a LBS server, it does note that > there are possible security concerns involved in the location of > an Internet host being passed to an LBS server. In the case of mobile > telephony networks, most subscriber locations are passed to an LBS > server from a mobile provider's location server, not directly from > the mobile handset, and the list of permitted LBS servers is strictly > controlled. However, in the case of a Geographic Position option for > DHCP, this security infrastructure may not be in place, and it is > therefore recommended that any client application supplying a > DHCP-acquired position to an LBS server should implement an adequate > security mechanism to protect users from any possible wrongdoing. > Such mechanisms might include implementing a list of permitted LBS > servers, popup alerts when passing a host's location to an LBS > server, or the ability to turn on/off the passing of location > information. > > > 3. Author's Address > > Sam Critchley > Worldcom EMEA Network Service > Joan Muyskenweg 22 > 1096 CJ Amsterdam > The Netherlands > > Phone: +31 20 711 6082 > Email: Sam.Critchley@wcom.com > > *************************************************************************** > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ****************************************************** Sam Critchley Technology Integration Manager Network Services EMEA Sam.Critchley@wcom.com Worldcom Joan Muyskenweg 22 Tel: +31 20 711 6082 1096 CJ Amsterdam The Netherlands ****************************************************** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 16 11:58:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20241; Fri, 16 Aug 2002 11:58:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09369; Fri, 16 Aug 2002 11:59:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09306 for ; Fri, 16 Aug 2002 11:59:17 -0400 (EDT) Received: from ams2eusosrv15.ams.ops.eu.uu.net (ams2eusosrv15.ams.ops.eu.uu.net [146.188.99.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20231 for ; Fri, 16 Aug 2002 11:57:54 -0400 (EDT) Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv15.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: ams2eusosrv20.ams.ops.eu.uu.net [146.188.99.75]) id QQnceh26336; Fri, 16 Aug 2002 15:59:08 GMT Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnceh20656; Fri, 16 Aug 2002 15:58:40 GMT Received: from anocserve1.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: anocserve1.ams.ops.eu.uu.net [146.188.99.69]) id QQnceh20644; Fri, 16 Aug 2002 15:58:40 GMT Date: Fri, 16 Aug 2002 17:58:40 +0200 (MET DST) From: Sam Critchley X-X-Sender: To: "Kostur, Andre" cc: Subject: RE: [dhcwg] Geographic position option In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A671D5@homer.incognito.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi Andre, Thanks also for your reply and comment. There were immediately a couple of main reasons why RFC1712 wasn't used for this: 1. If the host is on a closed network or the resolver isn't available, then a host can't get its location easily. 2. If the DNS server is not administered by the organisation/person running the DHCP server (for example in the case a small 802.11 AP with roaming users), then there may be procedural issues with getting updates done etc - whilst it's very easy, for example, for an AP administrator to input a latitude, longitude and approximate altitude into the configuration interface of an AP or another machine running the DHCP server. 3. There are security concerns with allowing those with access to the global DNS system (every Internet host) to see the geographic location of all hosts. Granted, you can set up access-lists to restrict who views the information, but this can be complicated and for a client host to set up the LBS server's permissions to obtain the client's position through DNS using this method wouldn't be so practicable. A DHCP-based system should easily allow users to choose which LBS servers are given their location. 4. All DNS servers/resolvers need to be equipped to use this system. I'm not sure I can imagine a scenario where the DHCP client might want to use the information in deciding which Offer to accept though.... can you elaborate? Thanks, Sam On Fri, 16 Aug 2002, Kostur, Andre wrote: > Just as a thought. Any reason why you picked a GPS-based format instead of > perhaps the DNS format for geographical location? (RFC 1712) I was > originally going to suggest that the device simply ask the DNS for this > information, but the device may want to use this information in selecting > which Offer to accept, and as a result has no IP yet so cannot ask the DNS > (yet). > > > -----Original Message----- > > From: Sam Critchley [mailto:Sam.Critchley@wcom.com] > > Sent: Friday, August 16, 2002 7:52 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Geographic position option > > > > > > > > Hi, > > > > Included below is a draft proposing an option to allow a DHCP > > server to > > pass its geographic location to a DHCP client. > > > > From RFC 2489: > > > > "Preferably, the author will submit the Internet Draft to the > > DHC Working > > Group,..." > > > > and > > > > "The specification is reviewed by the DHC WG (if it exists) or by the > > IETF." > > > > So, I'd be interested in people's comments on this document. > > What should I > > do with the document now? > > > > Many thanks, > > > > > > Sam > > > > > > Here is the draft: > > > > ************************************************************** > > ********** > > > > Network Working Group > > Sam Critchley > > Internet Draft > > Worldcom, Inc > > > > > > August, 2002 > > Expires > > January, 2003 > > > > > > The Geographic Position Option for DHCP > > > > > > Status of this Memo > > > > This document is an Internet-Draft and is subject to all provisions > > of Section 10 of RFC2026. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF), its areas, and its working groups. Note that > > other groups may also distribute working documents as > > Internet-Drafts. > > > > Internet-Drafts are draft documents valid for a maximum of six > > months and may be updated, replaced, or obsoleted by other > > documents at any time. It is inappropriate to use Internet- > > Drafts as reference material or to cite them other than as > > "work in progress." > > > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/1id-abstracts.html > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html > > > > Abstract > > > > This document describes a DHCP option in which the geographic > > position of the DHCP server is passed to the DHCP client in order > > to allow the client to make use of Location-Based Services. > > > > 1. Introduction > > > > Mobile telephony networks are able to make use of certain > > technologies which supply the geographic location of a mobile > > suscriber's handset to a Location-Based Services (LBS) > > provider. The > > mobile subscriber is then able to take advantage of such services > > as point-of-interest (POI) location, mapping, route-determination, > > traffic services and location-aware mobile instant messaging. > > > > There is currently no standardised mechanism in place to supply > > a geographic location to Internet hosts not connected to mobile > > telephony network, including, but not limited to, hosts connecting > > using IEEE 802.11x wireless protocols, and those connected to > > wire-based networks but configured with non-static IP addresses. > > Consequently, these hosts are more limited in their ability to > > take advantage of LBS, including having to manually enter a > > geographic position or street address in many cases. > > > > This document defines a DHCP option by which a DHCP server can pass > > its geographical location, in the form of a latitude, longitude and > > altitude position, to its clients. > > > > This document does not seek to define a method to allow a host to > > pass its location to a LBS server, as there are already in place > > several standards which propose these mechanisms, such as > > the Mobile > > Location Protocol (MLP) developed by the Location Interoperability > > Forum (LIF), although it does make one security recommendation in > > this area. > > > > Furthermore, this document does not attempt to propose a mechanism > > which would perform in the same manner as critical > > emergency location > > services such as the Enhanced 911 (E-911) service being implemented > > in US mobile telephony networks, nor does it propose a mechanism > > to be used for highly accurate positioning applications, > > such as that provided by the Global Positioning System (GPS). > > > > However, the Geographic Position Option for DHCP does propose a > > mechanism which, in many cases, will provide a position to the same > > degree of accuracy as that provided by mobile telephony networks' > > geographic location mechanisms. > > > > 2. The Geographic Position Option for DHCP > > > > 2.1 DHCP Option field definitions. > > > > This option contains the following fields: > > > > a) Option Code - TBD > > b) Option length in bytes > > c) DHCP Server Geographic Position Sentence > > > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Code = TBD | Length | Geographic Position Sentence | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Geographic Position Sentence | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | . . . . | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | . . . . | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > 2.2 DHCP Server Geographic Position Sentence > > > > The DHCP Server Geographic Position Sentence takes the form of a > > comma-separated ASCII string of position terms. This is in > > some ways > > similar to the format used in the National Marine Electronics > > Association's NMEA 0183 and NMEA 2000 standards, commonly used by > > GPS navigation devices for passing location information to other > > devices. > > > > The sentence takes the following form: > > > > DHCPPS,A,B,C,D,E,F,G,H,I,J,K > > > > Where the following are field definitions: > > > > - DHCPPS - DHCP Position Sentence. Indicates to the DHCP > > client that > > this is a sentence designed to provide the geographic position of > > the DHCP server to the DHCP client, as opposed to any other > > information. > > > > - A - Latitude. Expressed in decimal degrees, to a maximum of 6 > > decimal places. > > > > - B - Latitude N/S. Whether the latitude figure expressed > > is North or > > South of the equator, expressed simply as the letter "N" or the > > letter "S" in upper case. > > > > - C - Longitude. Expressed in decimal degrees, to a maximum of 6 > > decimal places. > > > > - D - Longitude E/W. Whether the longitude figure expressed is East > > or West of the Greenwhich Meridian, expressed simply as the letter > > "E" or the letter "W" in upper case. > > > > - E - Altitude. The altitude, expressed to a maximum of 2 decimal > > places, and preceded with a "+" or a "-" symbol to indicate whether > > the value is above mean sea level (positive) or below mean > > sea level > > (negative). > > > > - F - Altitude unit. The upper-case letter "M" to indicate that the > > unit is in Metres, or the upper-case letters "FT" to indicate that > > the unit is in feet. > > > > - G - Horizontal Accuracy. The horizontal accuracy of the latitude > > and longitude position obtained by the DHCP client from the DHCP > > server. Intended to represent the maximum horizontal distance that > > a DHCP client will be from its DHCP server, and useful, > > for example, > > in the case of DHCP scenarios such as IEEE 802.11b setups using > > bridging, and where the DHCP client can expect to be some distance > > from the DHCP server. Figure given to a maximum of three decimal > > places. > > > > - H - Horizontal Accuracy unit. The upper-case letter "M" > > to indicate > > that the unit is in metres, the upper-case letters "KM" to indicate > > that the unit is in kilometres, the upper-case letters "FT" to > > indicate that the unit is in feet, or the upper-case > > letters "ML" to > > indicate that the unit is in miles. > > > > - I - Vertical Accuracy. The vertical accuracy of the Altitude > > position obtained by the DHCP client from the DHCP server. Intended > > to represent the maximum vertical distance that a DHCP > > client will be > > located from its DHCP server, and useful, for example, in the case > > of network segments located in tall buildings. > > > > - J - Vertical Accuracy unit. The upper-case letter "M" to indicate > > that the unit is in metres, the upper-case letters "KM" to indicate > > that the unit is in kilometres, the upper-case letters "FT" to > > indicate that the unit is in feet, or the upper-case > > letters "ML" to > > indicate that the unit is in miles. > > > > - K - Geodesic Datum. The standard abbreviated form of the geodesic > > datum used to calculate position. This term has a default value of > > "WGS84" should no datum be specified. > > > > The DHCP Server Geographic Position Sentence would normally have a > > maximum length of between 49 and 64 bytes, depending on the values > > used. > > > > Apart from the first term of the DHCP Server Geographic Position > > Sentence, which always must have a value of "DHCPPS", and must be > > present, the presence of a value in all other fields is optional. > > However, all fields, whether a value is present or not, must be > > comma-separated. Furthermore, it is understood that a DHCPPS > > containing few or no values might be of little use in determining > > the position of the DHCP client. > > > > > > 2.2.1 Example of a DHCP Server Geographic Position Sentence > > > > DHCPPS,52.3742,N,4.8925,E,+3.12,M,50.9,M,5,M,WGS84 > > > > This sentence indicates that the DHCP server is located at 52.3742 > > degrees North, 4.8925 degrees East, at 3.12 metres above mean sea > > level, that the DHCP client is a maximum of 50.9 metres > > horizontally > > from the DHCP server, a maximum of 5 metres altitude above or below > > the DHCP server, and that the datum used to calculate this position > > was WGS-84. > > > > 2.3 Security Concerns > > > > Whilst this document does not seek to define a method to allow a > > host to pass its location to a LBS server, it does note that > > there are possible security concerns involved in the location of > > an Internet host being passed to an LBS server. In the > > case of mobile > > telephony networks, most subscriber locations are passed to an LBS > > server from a mobile provider's location server, not directly from > > the mobile handset, and the list of permitted LBS servers > > is strictly > > controlled. However, in the case of a Geographic Position > > option for > > DHCP, this security infrastructure may not be in place, and it is > > therefore recommended that any client application supplying a > > DHCP-acquired position to an LBS server should implement > > an adequate > > security mechanism to protect users from any possible wrongdoing. > > Such mechanisms might include implementing a list of permitted LBS > > servers, popup alerts when passing a host's location to an LBS > > server, or the ability to turn on/off the passing of location > > information. > > > > > > 3. Author's Address > > > > Sam Critchley > > Worldcom EMEA Network Service > > Joan Muyskenweg 22 > > 1096 CJ Amsterdam > > The Netherlands > > > > Phone: +31 20 711 6082 > > Email: Sam.Critchley@wcom.com > > > > ************************************************************** > > ************* > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > ****************************************************** Sam Critchley Technology Integration Manager Network Services EMEA Sam.Critchley@wcom.com Worldcom Joan Muyskenweg 22 Tel: +31 20 711 6082 1096 CJ Amsterdam The Netherlands ****************************************************** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 16 12:11:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21092; Fri, 16 Aug 2002 12:11:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12067; Fri, 16 Aug 2002 12:12:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12048 for ; Fri, 16 Aug 2002 12:12:24 -0400 (EDT) Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21078 for ; Fri, 16 Aug 2002 12:11:01 -0400 (EDT) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 17fjMI-0000N8-00; Fri, 16 Aug 2002 08:49:54 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Aug 2002 09:11:26 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A671D6@homer.incognito.com.> From: "Kostur, Andre" To: "'Sam Critchley'" , "Kostur, Andre" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Geographic position option Date: Fri, 16 Aug 2002 09:11:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2453F.921CEAA0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2453F.921CEAA0 Content-Type: text/plain; charset="iso-8859-1" Inline.... > Thanks also for your reply and comment. > > There were immediately a couple of main reasons why RFC1712 > wasn't used > for this: Note that I was referring the RFC1712's format for supplying the information, not necessarily using 1712 to obtain the actual location. But if the client won't be using this information until after it has bound to an address, it would make much more sense to me if the client _did_ use 1712 to find out the server's location. > 1. If the host is on a closed network or the resolver isn't available, > then a host can't get its location easily. Presumably if the host can reach a DHCP server, it should be able to reach a DNS too. BTW: are we talking about the client obtaining it's _own_ location? Or the location of the DHCP server? > 2. If the DNS server is not administered by the organisation/person > running the DHCP server (for example in the case a small > 802.11 AP with > roaming users), then there may be procedural issues with > getting updates > done etc - whilst it's very easy, for example, for an AP > administrator to > input a latitude, longitude and approximate altitude into the > configuration interface of an AP or another machine running the DHCP > server. Um, wasn't this an option to inform the client of the geographical position of the server? Presumably that wouldn't be changing very often, so it's only 1 DNS update. > 3. There are security concerns with allowing those with access to the > global DNS system (every Internet host) to see the geographic > location of > all hosts. Granted, you can set up access-lists to restrict > who views the > information, but this can be complicated and for a client > host to set up > the LBS server's permissions to obtain the client's position > through DNS > using this method wouldn't be so practicable. A DHCP-based > system should > easily allow users to choose which LBS servers are given > their location. You can also use private DNSes to supply that information (ie: a DNS only reachable by clients which have obtained an address by your DHCP server). > 4. All DNS servers/resolvers need to be equipped to use this system. Uh, it's just one resource record in the DNS? Most existing DNSes can support this now.... > I'm not sure I can imagine a scenario where the DHCP client > might want to > use the information in deciding which Offer to accept > though.... can you > elaborate? I was thinking mostly theoretically where a client device which knows it's own location (through some other means) may wish to use the location parameter to choose the physically closest server. Or perhaps only servers within a certain geographical area. Although I don't see a whole lot of practical use for this. It would be lousy "security" to use geographical location (which can be spoofed by servers). You might as well use RFC 3118. ------_=_NextPart_001_01C2453F.921CEAA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Geographic position option

Inline....

> Thanks also for your reply and comment.
>
> There were immediately a couple of main reasons = why RFC1712
> wasn't used
> for this:

Note that I was referring the RFC1712's format for = supplying the information, not necessarily using 1712 to obtain the = actual location.  But if the client won't be using this = information until after it has bound to an address, it would make much = more sense to me if the client _did_ use 1712 to find out the server's = location.

 
> 1. If the host is on a closed network or the = resolver isn't available,
> then a host can't get its location = easily.

Presumably if the host can reach a DHCP server, it = should be able to reach a DNS too.  BTW: are we talking about the = client obtaining it's _own_ location?  Or the location of the DHCP = server?

> 2. If the DNS server is not administered by the = organisation/person
> running the DHCP server (for example in the = case a small
> 802.11 AP with
> roaming users), then there may be procedural = issues with
> getting updates
> done etc - whilst it's very easy, for example, = for an AP
> administrator to
> input a latitude, longitude and approximate = altitude into the
> configuration interface of an AP or another = machine running the DHCP
> server.

Um, wasn't this an option to inform the client of the = geographical position of the server?  Presumably that wouldn't be = changing very often, so it's only 1 DNS update.

> 3. There are security concerns with allowing = those with access to the
> global DNS system (every Internet host) to see = the geographic
> location of
> all hosts. Granted, you can set up access-lists = to restrict
> who views the
> information, but this can be complicated and = for a client
> host to set up
> the LBS server's permissions to obtain the = client's position
> through DNS
> using this method wouldn't be so practicable. A = DHCP-based
> system should
> easily allow users to choose which LBS servers = are given
> their location.

You can also use private DNSes to supply that = information (ie: a DNS only reachable by clients which have obtained an = address by your DHCP server).

> 4. All DNS servers/resolvers need to be equipped = to use this system.

Uh, it's just one resource record in the DNS?  = Most existing DNSes can support this now....

> I'm not sure I can imagine a scenario where the = DHCP client
> might want to
> use the information in deciding which Offer to = accept
> though.... can you
> elaborate?

I was thinking mostly theoretically where a client = device which knows it's own location (through some other means) may = wish to use the location parameter to choose the physically closest = server.  Or perhaps only servers within a certain geographical = area.  Although I don't see a whole lot of practical use for = this.  It would be lousy "security" to use geographical = location (which can be spoofed by servers).  You might as well use = RFC 3118.

------_=_NextPart_001_01C2453F.921CEAA0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Aug 18 14:43:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01063; Sun, 18 Aug 2002 14:43:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22550; Sun, 18 Aug 2002 14:44:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08809 for ; Fri, 16 Aug 2002 11:49:44 -0400 (EDT) Received: from web13907.mail.yahoo.com (web13907.mail.yahoo.com [216.136.175.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19719 for ; Fri, 16 Aug 2002 11:48:21 -0400 (EDT) Message-ID: <20020816154942.26115.qmail@web13907.mail.yahoo.com> Received: from [207.193.172.226] by web13907.mail.yahoo.com via HTTP; Fri, 16 Aug 2002 08:49:42 PDT Date: Fri, 16 Aug 2002 08:49:42 -0700 (PDT) From: Ryan Scripps Reply-To: RyanScripps@alumni.utexas.net Subject: Re: [dhcwg] Geographic position option To: dhcwg@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is an interesting option, but I don't understand it's relevance. A DHCP client only talks to a DHCP server when negotiating a lease. Physical location is unimportant in this transaction since physical closeness does not necessarily imply "network closeness". Furthermore, as stated in the draft, other mechanisms exist to query the physical location of a client. I look forward to further discussion. -Ryan Scripps --- Sam Critchley wrote: > > Hi, > > Included below is a draft proposing an option to > allow a DHCP server to > pass its geographic location to a DHCP client. > > From RFC 2489: > > "Preferably, the author will submit the Internet > Draft to the DHC Working > Group,..." > > and > > "The specification is reviewed by the DHC WG (if it > exists) or by the > IETF." > > So, I'd be interested in people's comments on this > document. What should I > do with the document now? > > Many thanks, > > > Sam > > > Here is the draft: > > ************************************************************************ > > Network Working Group > Sam Critchley > Internet Draft > Worldcom, Inc > > > August, 2002 > > Expires January, 2003 > > > The Geographic Position Option for DHCP > > > > Status of this Memo > > This document is an Internet-Draft and is subject > to all provisions > of Section 10 of RFC2026. > > Internet-Drafts are working documents of the > Internet Engineering > Task Force (IETF), its areas, and its working > groups. Note that > other groups may also distribute working > documents as > Internet-Drafts. > > Internet-Drafts are draft documents valid for a > maximum of six > months and may be updated, replaced, or obsoleted > by other > documents at any time. It is inappropriate to > use Internet- > Drafts as reference material or to cite them > other than as > "work in progress." > > The list of current Internet-Drafts can be > accessed at > http://www.ietf.org/1id-abstracts.html > > The list of Internet-Draft Shadow Directories can > be accessed at > http://www.ietf.org/shadow.html > > Abstract > > This document describes a DHCP option in which > the geographic > position of the DHCP server is passed to the DHCP > client in order > to allow the client to make use of Location-Based > Services. > > 1. Introduction > > Mobile telephony networks are able to make use of > certain > technologies which supply the geographic location > of a mobile > suscriber's handset to a Location-Based Services > (LBS) provider. The > mobile subscriber is then able to take advantage > of such services > as point-of-interest (POI) location, mapping, > route-determination, > traffic services and location-aware mobile > instant messaging. > > There is currently no standardised mechanism in > place to supply > a geographic location to Internet hosts not > connected to mobile > telephony network, including, but not limited to, > hosts connecting > using IEEE 802.11x wireless protocols, and those > connected to > wire-based networks but configured with > non-static IP addresses. > Consequently, these hosts are more limited in > their ability to > take advantage of LBS, including having to > manually enter a > geographic position or street address in many > cases. > > This document defines a DHCP option by which a > DHCP server can pass > its geographical location, in the form of a > latitude, longitude and > altitude position, to its clients. > > This document does not seek to define a method to > allow a host to > pass its location to a LBS server, as there are > already in place > several standards which propose these mechanisms, > such as the Mobile > Location Protocol (MLP) developed by the Location > Interoperability > Forum (LIF), although it does make one security > recommendation in > this area. > > Furthermore, this document does not attempt to > propose a mechanism > which would perform in the same manner as > critical emergency location > services such as the Enhanced 911 (E-911) service > being implemented > in US mobile telephony networks, nor does it > propose a mechanism > to be used for highly accurate positioning > applications, such as that provided by the Global > Positioning System (GPS). > > However, the Geographic Position Option for DHCP > does propose a > mechanism which, in many cases, will provide a > position to the same > degree of accuracy as that provided by mobile > telephony networks' > geographic location mechanisms. > > 2. The Geographic Position Option for DHCP > > 2.1 DHCP Option field definitions. > > This option contains the following fields: > > a) Option Code - TBD > b) Option length in bytes > c) DHCP Server Geographic Position Sentence > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Code = TBD | Length | Geographic > Position Sentence | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Geographic Position Sentence > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | . . . . > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | . . . . > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 2.2 DHCP Server Geographic Position Sentence > > The DHCP Server Geographic Position Sentence > takes the form of a > comma-separated ASCII string of position terms. > This is in some ways > similar to the format used in the National Marine > Electronics > Association's NMEA 0183 and NMEA 2000 standards, > commonly === message truncated === __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 19 06:22:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27034; Mon, 19 Aug 2002 06:22:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10469; Mon, 19 Aug 2002 06:20:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10443 for ; Mon, 19 Aug 2002 06:20:49 -0400 (EDT) Received: from ams2eusosrv15.ams.ops.eu.uu.net (ams2eusosrv15.ams.ops.eu.uu.net [146.188.99.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27014 for ; Mon, 19 Aug 2002 06:19:26 -0400 (EDT) Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv15.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: ams2eusosrv20.ams.ops.eu.uu.net [146.188.99.75]) id QQncon27627; Mon, 19 Aug 2002 10:20:44 GMT Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncon09953; Mon, 19 Aug 2002 10:20:27 GMT Received: from anocserve1.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: anocserve1.ams.ops.eu.uu.net [146.188.99.69]) id QQncon09949; Mon, 19 Aug 2002 10:20:27 GMT Date: Mon, 19 Aug 2002 12:20:27 +0200 (MET DST) From: Sam Critchley X-X-Sender: To: "Kostur, Andre" cc: Subject: RE: [dhcwg] Geographic position option In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A671D6@homer.incognito.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi Andre, On Fri, 16 Aug 2002, Kostur, Andre wrote: > Inline.... Same for me. More important stuff towards the bottom.... > Note that I was referring the RFC1712's format for supplying the > information, not necessarily using 1712 to obtain the actual location. But > if the client won't be using this information until after it has bound to an > address, it would make much more sense to me if the client _did_ use 1712 to > find out the server's location. > > > 1. If the host is on a closed network or the resolver isn't available, > > then a host can't get its location easily. > > Presumably if the host can reach a DHCP server, it should be able to reach a > DNS too. BTW: are we talking about the client obtaining it's _own_ > location? Or the location of the DHCP server? Well, what I was proposing was that the client find out the location of the DHCP server. With a DNS-based system it indeed be possible to be more precise, although this would not work in the case of wirelessly connected hosts, where you would again have to rely on the location of some fixed device nearby. [snip] > Um, wasn't this an option to inform the client of the geographical position > of the server? Presumably that wouldn't be changing very often, so it's > only 1 DNS update. True, although someone running, for example, a mom-and-pop (if that term's acceptable) internet cafe with an 802.11b AP might not be able to do that without some confusion, whereas if the initial configuration screen of the AP allowed them to fill in their latitude/longitude etc, it might be more likely to get done. Another point here is that using DNS in these cases does put extra overhead on the upstream ISP... and they might not be geared up to make these changes. > > 3. There are security concerns with allowing those with access to the > > global DNS system (every Internet host) to see the geographic > > location of > > all hosts. Granted, you can set up access-lists to restrict > > who views the > > information, but this can be complicated and for a client > > host to set up > > the LBS server's permissions to obtain the client's position > > through DNS > > using this method wouldn't be so practicable. A DHCP-based > > system should > > easily allow users to choose which LBS servers are given > > their location. > > You can also use private DNSes to supply that information (ie: a DNS only > reachable by clients which have obtained an address by your DHCP server). Ah, that's a possibility, I see. You mean that, instead of the LBS server looking up the GPOS of the host, the host looks up its own GPOS using a private DNS setup, then supplies it to the LBS server if it wants to? In the case of APs running in small cafes etc, this requires either a local resolver/server, or quite a lot of ISP overhead to administer. If your customers are roamers whose subscriptions are from companies like Boingo, iPass, Megabeam etc, then they will expect the system to work the same in every place. Given that the underlying ISPs in each place are different, then this may not be so easy to administer, although no doubt there are ways to improve its efficiency. Another point worth considering is that many 802.11b APs are connected with, for example, DSL or cable connections where a single IP address is assigned by the DSL or cable modem provider using DHCP. This IP address sometimes remains the same for long periods of time, but in many cases you can't guarantee the same address if, for example, you reboot the AP. The AP then uses NAT (and assigns RFC1918 addresses) for its hosts locally. In this case, you'd have to have a clever ISP-based DNS setup to change the GPOS records in individual zones each time DHCP renewed. Do we have anyone from an 802.11b provider or AP vendor reading this mail? If so, I think it would be interesting to hear your comments... I think that, for Location-Based Service, perhaps the most vital go/no-go criterion is whether you can provide adequate security for the end user. I definitely do not want anyone with access to global DNS to be able to find out precisely where I am (and I don't think anyone would want this), but I do want to be click "Yes" or "No" on a popup box that asks the question "Do you want to give this server your location?". I believe that a private DNS system could provide that, but that it would be easier and more likely to happen if it were done in DHCP. > > > 4. All DNS servers/resolvers need to be equipped to use this system. > > Uh, it's just one resource record in the DNS? Most existing DNSes can > support this now.... Okay, I think I didn't quite phrase that one right... plus I probably wasn't quite thinking about it straight... presumably you'd first perform a reverse lookup on the IP address, then a forward lookup on the hostname to get the GPOS record. As I think you imply, only the immediate zone would need to hold this record. > > I'm not sure I can imagine a scenario where the DHCP client > > might want to > > use the information in deciding which Offer to accept > > though.... can you > > elaborate? > > I was thinking mostly theoretically where a client device which knows it's > own location (through some other means) may wish to use the location > parameter to choose the physically closest server. Or perhaps only servers > within a certain geographical area. Although I don't see a whole lot of > practical use for this. It would be lousy "security" to use geographical > location (which can be spoofed by servers). You might as well use RFC 3118. Ah, this is quite interesting, although I agree that I don't see a whole lot of practical use for it. Thanks, Sam PS BTW, what should I do with the draft document? Do I submit it as an individual contribution and say "please notify the DHC WG"? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 19 06:36:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27314; Mon, 19 Aug 2002 06:36:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11472; Mon, 19 Aug 2002 06:35:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11445 for ; Mon, 19 Aug 2002 06:35:45 -0400 (EDT) Received: from ams2eusosrv15.ams.ops.eu.uu.net (ams2eusosrv15.ams.ops.eu.uu.net [146.188.99.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27293 for ; Mon, 19 Aug 2002 06:34:21 -0400 (EDT) Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv15.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: ams2eusosrv20.ams.ops.eu.uu.net [146.188.99.75]) id QQncoo01541; Mon, 19 Aug 2002 10:35:41 GMT Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQncoo27672; Mon, 19 Aug 2002 10:35:34 GMT Received: from anocserve1.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: anocserve1.ams.ops.eu.uu.net [146.188.99.69]) id QQncoo27668; Mon, 19 Aug 2002 10:35:34 GMT Date: Mon, 19 Aug 2002 12:35:34 +0200 (MET DST) From: Sam Critchley X-X-Sender: To: cc: Subject: Re: [dhcwg] Geographic position option In-Reply-To: <20020816154942.26115.qmail@web13907.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi Ryan, Thanks for the comments as well, please see mine inline: On Fri, 16 Aug 2002, Ryan Scripps wrote: > This is an interesting option, but I don't understand > it's relevance. A DHCP client only talks to a DHCP > server when negotiating a lease. Physical location is > unimportant in this transaction since physical > closeness does not necessarily imply "network > closeness". Furthermore, as stated in the draft, > other mechanisms exist to query the physical location > of a client. Well, in the case of growth in mobile access in the future, there currently seem to be two main areas: 1. Mobile telephony-based systems, such as 2.5/3G solutions (GPRS, CDMA 1x, CDMA2000, UMTS etc). Content based a lot on i-Mode, WAP 2.0 etc. For example, i-Mode here in the Netherlands seems to work pretty well and there are a lot of services being developed. 2. 802.11-based access, with roaming across national/international networks in many locations. Roaming agreements are in place, vendors are shipping equipment with 802.11 devices built in, and apparently sales of 802.11b cards for laptops/PDAs etc are running around 1 million per month. There are also combinations of the above, where with one subscription you can have mobile telephony in most places, but switch to higher speed 802.11 when in range. A lot of work is going in LBS mechanisms for the first option (and in South Korea, for example, there are already over a million GPS-enabled mobile phones which use them), but (as far as I can see) little is happening for the second one, and I don't yet see a mechanism in place which will tell me or an LBS server my location adequately, certainly not with the security level I would require. To have a DHCP-based system which would give you your position to, in many cases, a few metres accuracy, would seem to at least be adequate to use many of the LBS services being put together, in the absence of a host being able to acquire its exact location. > > I look forward to further discussion. Me too. :-) Thanks, Sam > > -Ryan Scripps > > --- Sam Critchley wrote: > > > > Hi, > > > > Included below is a draft proposing an option to > > allow a DHCP server to > > pass its geographic location to a DHCP client. > > > > From RFC 2489: > > > > "Preferably, the author will submit the Internet > > Draft to the DHC Working > > Group,..." > > > > and > > > > "The specification is reviewed by the DHC WG (if it > > exists) or by the > > IETF." > > > > So, I'd be interested in people's comments on this > > document. What should I > > do with the document now? > > > > Many thanks, > > > > > > Sam > > > > > > Here is the draft: > > > > > ************************************************************************ > > > > Network Working Group > > Sam Critchley > > Internet Draft > > Worldcom, Inc > > > > > > August, 2002 > > > > Expires January, 2003 > > > > > > The Geographic Position Option for DHCP > > > > > > > > Status of this Memo > > > > This document is an Internet-Draft and is subject > > to all provisions > > of Section 10 of RFC2026. > > > > Internet-Drafts are working documents of the > > Internet Engineering > > Task Force (IETF), its areas, and its working > > groups. Note that > > other groups may also distribute working > > documents as > > Internet-Drafts. > > > > Internet-Drafts are draft documents valid for a > > maximum of six > > months and may be updated, replaced, or obsoleted > > by other > > documents at any time. It is inappropriate to > > use Internet- > > Drafts as reference material or to cite them > > other than as > > "work in progress." > > > > The list of current Internet-Drafts can be > > accessed at > > http://www.ietf.org/1id-abstracts.html > > > > The list of Internet-Draft Shadow Directories can > > be accessed at > > http://www.ietf.org/shadow.html > > > > Abstract > > > > This document describes a DHCP option in which > > the geographic > > position of the DHCP server is passed to the DHCP > > client in order > > to allow the client to make use of Location-Based > > Services. > > > > 1. Introduction > > > > Mobile telephony networks are able to make use of > > certain > > technologies which supply the geographic location > > of a mobile > > suscriber's handset to a Location-Based Services > > (LBS) provider. The > > mobile subscriber is then able to take advantage > > of such services > > as point-of-interest (POI) location, mapping, > > route-determination, > > traffic services and location-aware mobile > > instant messaging. > > > > There is currently no standardised mechanism in > > place to supply > > a geographic location to Internet hosts not > > connected to mobile > > telephony network, including, but not limited to, > > hosts connecting > > using IEEE 802.11x wireless protocols, and those > > connected to > > wire-based networks but configured with > > non-static IP addresses. > > Consequently, these hosts are more limited in > > their ability to > > take advantage of LBS, including having to > > manually enter a > > geographic position or street address in many > > cases. > > > > This document defines a DHCP option by which a > > DHCP server can pass > > its geographical location, in the form of a > > latitude, longitude and > > altitude position, to its clients. > > > > This document does not seek to define a method to > > allow a host to > > pass its location to a LBS server, as there are > > already in place > > several standards which propose these mechanisms, > > such as the Mobile > > Location Protocol (MLP) developed by the Location > > Interoperability > > Forum (LIF), although it does make one security > > recommendation in > > this area. > > > > Furthermore, this document does not attempt to > > propose a mechanism > > which would perform in the same manner as > > critical emergency location > > services such as the Enhanced 911 (E-911) service > > being implemented > > in US mobile telephony networks, nor does it > > propose a mechanism > > to be used for highly accurate positioning > > applications, such as that provided by the Global > > Positioning System (GPS). > > > > However, the Geographic Position Option for DHCP > > does propose a > > mechanism which, in many cases, will provide a > > position to the same > > degree of accuracy as that provided by mobile > > telephony networks' > > geographic location mechanisms. > > > > 2. The Geographic Position Option for DHCP > > > > 2.1 DHCP Option field definitions. > > > > This option contains the following fields: > > > > a) Option Code - TBD > > b) Option length in bytes > > c) DHCP Server Geographic Position Sentence > > > > 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 > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Code = TBD | Length | Geographic > > Position Sentence | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Geographic Position Sentence > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | . . . . > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | . . . . > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > 2.2 DHCP Server Geographic Position Sentence > > > > The DHCP Server Geographic Position Sentence > > takes the form of a > > comma-separated ASCII string of position terms. > > This is in some ways > > similar to the format used in the National Marine > > Electronics > > Association's NMEA 0183 and NMEA 2000 standards, > > commonly > === message truncated === > > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ****************************************************** Sam Critchley Technology Integration Manager Network Services EMEA Sam.Critchley@wcom.com Worldcom Joan Muyskenweg 22 Tel: +31 20 711 6082 1096 CJ Amsterdam The Netherlands ****************************************************** _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 22 08:03:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22568; Thu, 22 Aug 2002 08:03:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7MC3TW21720; Thu, 22 Aug 2002 08:03:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LMcxW12885 for ; Wed, 21 Aug 2002 18:38:59 -0400 Received: from fed1mtao04.cox.net (fed1mtao04.cox.net [68.6.19.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28111 for ; Wed, 21 Aug 2002 18:37:29 -0400 (EDT) Received: from localhost.localdomain ([68.2.221.180]) by fed1mtao04.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020821223821.DJYN1369.fed1mtao04.cox.net@localhost.localdomain>; Wed, 21 Aug 2002 18:38:21 -0400 From: Russ Dill To: Christoph Stueckjuergen Cc: dhcwg@ietf.org In-Reply-To: <200208120637.g7C6bfX28606@mailgate5.cinetic.de> References: <200208120637.g7C6bfX28606@mailgate5.cinetic.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 21 Aug 2002 15:38:44 -0700 Message-Id: <1029969525.18027.131.camel@timmy> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: udhcpd Win98 interoperability Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Hmm... I looked up RFC2131 and found that the server in fact MUST remain silent if it > has no notion of the client AND the network is correct. But if the network is not > correct, the server SHOULD send NAK. > > If you consider a notebook being plugged from time to time to different subnets, the > remain silent behavior is quite ugly. The user would have to wait some days for the > lease to time out before being able to access the network. ok, I'm actually a little confused, here is my parsing of the rfc If the DHCP server detects that the client is on the wrong net, then the server SHOULD send a DHCPNAK message to the client. If the network is correct, then the DHCP server should check if the client's notion of its IP address is correct. If not, then the server SHOULD send a DHCPNAK message to the client. If the DHCP server has no record of this client, then it MUST remain silent, and MAY output a warning to the network administrator. This behavior is necessary for peaceful coexistence of non-communicating DHCP servers on the same wire. at first, everything is simple if (wrong net) { should nak; } else { if (!ok ip) { should nak; } } but then the "If the DHCP server has no record of this client" clause is thrown in. At what stage of the block does this go in? I would say this clause would go *before* 'if (wrong net)'. I'll cc this to the Dynamic Host Configuration working group. Hopefully they'll have some answers. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 22 08:03:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22592; Thu, 22 Aug 2002 08:03:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7MC3gW21743; Thu, 22 Aug 2002 08:03:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7MBiPW20705 for ; Thu, 22 Aug 2002 07:44:25 -0400 Received: from mailgate5.cinetic.de (mailgate5.cinetic.de [217.72.192.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22195 for ; Thu, 22 Aug 2002 07:42:59 -0400 (EDT) From: cstueckjuergen@web.de Received: from web.de (fmomail02.dlan.cinetic.de [172.20.1.46]) by mailgate5.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id g7MBhlX22375; Thu, 22 Aug 2002 13:43:47 +0200 Date: Thu, 22 Aug 2002 13:43:47 +0200 Message-Id: <200208221143.g7MBhlX22375@mailgate5.cinetic.de> MIME-Version: 1.0 Organization: http://freemail.web.de/ To: "ChristophStueckjuergen" , "RussDill" Cc: dhcwg@ietf.org Precedence: fm-user Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id g7MBiPW20706 Subject: [dhcwg] Re: Re: udhcpd Win98 interoperability Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Russ Dill schrieb am 22.08.02 00:38:23: > > Hmm... I looked up RFC2131 and found that the server in fact MUST remain silent if it > > has no notion of the client AND the network is correct. But if the network is not > > correct, the server SHOULD send NAK. > > > > If you consider a notebook being plugged from time to time to different subnets, the > > remain silent behavior is quite ugly. The user would have to wait some days for the > > lease to time out before being able to access the network. > > ok, I'm actually a little confused, here is my parsing of the rfc > > If the DHCP server detects that the client is on the wrong > net, then the server SHOULD send a DHCPNAK message to the > client. > > If the network is correct, then the DHCP server should > check if the client's notion of its IP address is correct. > > If not, then the server SHOULD send a DHCPNAK message to > the client. > > If the DHCP server has no record of this client, then it > MUST remain silent, and MAY output a warning to the > network administrator. This behavior is necessary for > peaceful coexistence of non-communicating DHCP servers on > the same wire. > > at first, everything is simple > > if (wrong net) { > should nak; > } else { > if (!ok ip) { > should nak; > } > } > > but then the "If the DHCP server has no record of this client" clause is > thrown in. At what stage of the block does this go in? I would say this > clause would go *before* 'if (wrong net)'. > > I'll cc this to the Dynamic Host Configuration working group. Hopefully > they'll have some answers. > I would replace (!ok ip) by (requested ip is ours but is no longer/has never been assigned to the requesting client). Then the conditions (wrong net) and (requested ip is ours but...) are mutually exclusive. So my parsing of the RFC would look loke that: if (wrong net) { should nak; } else if (requested ip is ours but...) { should nak; } else { remain silent; } Greetings, Christoph ______________________________________________________________________________ Die clevere Geldreserve: der DiBa-Privatkredit. Funktioniert wie ein Dispo, ist aber viel günstiger! Alle Infos: http://diba.web.de/?mc=021104 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 22 13:12:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03149; Thu, 22 Aug 2002 13:12:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7MHCZo04654; Thu, 22 Aug 2002 13:12:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7MHBFo04606 for ; Thu, 22 Aug 2002 13:11:15 -0400 Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02991 for ; Thu, 22 Aug 2002 13:09:47 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g7MH88v08265; Thu, 22 Aug 2002 12:08:08 -0500 (CDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g7MHB5H5000386; Thu, 22 Aug 2002 12:11:05 -0500 (CDT) Date: Thu, 22 Aug 2002 12:11:04 -0500 Subject: Re: [dhcwg] Re: udhcpd Win98 interoperability Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: dhcwg@ietf.org, Christoph Stueckjuergen To: Russ Dill From: Ted Lemon In-Reply-To: <1029969525.18027.131.camel@timmy> Message-Id: <2442C638-B5F2-11D6-B903-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > but then the "If the DHCP server has no record of this client" clause is > thrown in. At what stage of the block does this go in? I would say this > clause would go *before* 'if (wrong net)'. No, if you do that, then DHCP clients will never get new addresses when they move to new networks where the DHCP server doesn't know them. The purpose of the "no record" clause is to prevent the DHCP server from NAKing simply because the DHCP client has an IP address that the server doesn't know about, but that is on the correct network. I.e., to allow two DHCP servers to serve the same network. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 22 17:13:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11109; Thu, 22 Aug 2002 17:13:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7MLDco19630; Thu, 22 Aug 2002 17:13:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7MIP7o09341 for ; Thu, 22 Aug 2002 14:25:07 -0400 Received: from fed1mtao01.cox.net (fed1mtao01.cox.net [68.6.19.244]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05509 for ; Thu, 22 Aug 2002 14:23:38 -0400 (EDT) Received: from localhost.localdomain ([68.2.221.180]) by fed1mtao01.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020822182418.GJEI1360.fed1mtao01.cox.net@localhost.localdomain>; Thu, 22 Aug 2002 14:24:18 -0400 From: Russ Dill To: cstueckjuergen@web.de Cc: dhcwg@ietf.org In-Reply-To: <200208221143.g7MBhlX22375@mailgate5.cinetic.de> References: <200208221143.g7MBhlX22375@mailgate5.cinetic.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 22 Aug 2002 11:25:05 -0700 Message-Id: <1030040705.7473.1.camel@timmy> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: Re: udhcpd Win98 interoperability Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > if (wrong net) { > > should nak; > > } else { > > if (!ok ip) { > > should nak; > > } > > } > > > > but then the "If the DHCP server has no record of this client" clause is > > thrown in. At what stage of the block does this go in? I would say this > > clause would go *before* 'if (wrong net)'. > > > > I'll cc this to the Dynamic Host Configuration working group. Hopefully > > they'll have some answers. > > > > I would replace (!ok ip) by (requested ip is ours but is no longer/has never been > assigned to the requesting client). Then the conditions (wrong net) and (requested ip > is ours but...) are mutually exclusive. > > So my parsing of the RFC would look loke that: > > if (wrong net) { > should nak; > } else if (requested ip is ours but...) { > should nak; > } else { > remain silent; > } define 'ours' a little better, do you mean if there is a static mapping for the address that we take care of? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 23 10:44:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08171; Fri, 23 Aug 2002 10:44:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7NEiLo08702; Fri, 23 Aug 2002 10:44:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7N70co21472 for ; Fri, 23 Aug 2002 03:00:38 -0400 Received: from mailgate5.cinetic.de (mailgate5.cinetic.de [217.72.192.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29572 for ; Fri, 23 Aug 2002 02:59:02 -0400 (EDT) From: cstueckjuergen@web.de Received: from web.de (fmomail02.dlan.cinetic.de [172.20.1.46]) by mailgate5.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id g7N6xsX23089; Fri, 23 Aug 2002 08:59:54 +0200 Date: Fri, 23 Aug 2002 08:59:54 +0200 Message-Id: <200208230659.g7N6xsX23089@mailgate5.cinetic.de> MIME-Version: 1.0 Organization: http://freemail.web.de/ To: cstueckjuergen@web.de, "RussDill" Cc: dhcwg@ietf.org Precedence: fm-user Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: Re: Re: udhcpd Win98 interoperability Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Russ Dill schrieb am 22.08.02 20:24:34: > > > if (wrong net) { > > > should nak; > > > } else { > > > if (!ok ip) { > > > should nak; > > > } > > > } > > > > > > but then the "If the DHCP server has no record of this client" clause is > > > thrown in. At what stage of the block does this go in? I would say this > > > clause would go *before* 'if (wrong net)'. > > > > > > I'll cc this to the Dynamic Host Configuration working group. Hopefully > > > they'll have some answers. > > > > > > > I would replace (!ok ip) by (requested ip is ours but is no longer/has never been > > assigned to the requesting client). Then the conditions (wrong net) and (requested ip > > is ours but...) are mutually exclusive. > > > > So my parsing of the RFC would look loke that: > > > > if (wrong net) { > > should nak; > > } else if (requested ip is ours but...) { > > should nak; > > } else { > > remain silent; > > } > > define 'ours' a little better, do you mean if there is a static mapping > for the address that we take care of? > OK, I would say the requested address should be NAKed if - we have static mapping for it on another client - it is already assigned to one of our other clients - it was assigned to the requesting client, but the lease has already timed out Do you think this is reasonable? ______________________________________________________________________________ WEB.DE MyPage - Ultimatives Kommunikationstool! Ihre Message sofort online! Domain aenderbar! http://www.das.ist.aber.ne.lustige.sache.ms/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 23 12:40:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11433; Fri, 23 Aug 2002 12:40:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7NGedo16434; Fri, 23 Aug 2002 12:40:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7NGdoo16406 for ; Fri, 23 Aug 2002 12:39:50 -0400 Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11390 for ; Fri, 23 Aug 2002 12:38:19 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g7NGaav06120; Fri, 23 Aug 2002 11:36:36 -0500 (CDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g7NGdgGh000333; Fri, 23 Aug 2002 11:39:42 -0500 (CDT) Date: Fri, 23 Aug 2002 11:39:42 -0500 Subject: Re: [dhcwg] Re: Re: Re: udhcpd Win98 interoperability Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "RussDill" , dhcwg@ietf.org To: cstueckjuergen@web.de From: Ted Lemon In-Reply-To: <200208230659.g7N6xsX23089@mailgate5.cinetic.de> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > OK, I would say the requested address should be NAKed if > - we have static mapping for it on another client > - it is already assigned to one of our other clients > - it was assigned to the requesting client, but the lease has already > timed out I think you already intended this, but just to be sure, you should also send a NAK if the requested network doesn't match the client's current location. In order for this to work properly, though, the DHCP server has to have an accurate understanding of what subnets are connected to what physical networks, since you don't want the server to send a DHCPNAK just because it isn't aware that the client's subnet is valid for the network to which it is attached. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 27 07:53:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18704; Tue, 27 Aug 2002 07:53:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RBrPo04356; Tue, 27 Aug 2002 07:53:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RBpQo04302 for ; Tue, 27 Aug 2002 07:51:26 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18519; Tue, 27 Aug 2002 07:49:54 -0400 (EDT) Message-Id: <200208271149.HAA18519@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 27 Aug 2002 07:49:54 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-packetcable-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 CableLabs Client Configuration Author(s) : B. Beser, P. Duffy Filename : draft-ietf-dhc-packetcable-03.txt Pages : 10 Date : 2002-8-26 This document defines a DHCP option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-packetcable-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-packetcable-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-packetcable-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: <2002-8-26140317.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-packetcable-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-packetcable-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-26140317.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 27 14:33:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06036; Tue, 27 Aug 2002 14:33:19 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RIXno25670; Tue, 27 Aug 2002 14:33:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RI9Xo24920 for ; Tue, 27 Aug 2002 14:09:33 -0400 Received: from fed1mtao04.cox.net (fed1mtao04.cox.net [68.6.19.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04775 for ; Tue, 27 Aug 2002 14:07:59 -0400 (EDT) Received: from localhost.localdomain ([68.2.221.180]) by fed1mtao04.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020827180857.HUGQ4808.fed1mtao04.cox.net@localhost.localdomain>; Tue, 27 Aug 2002 14:08:57 -0400 From: Russ Dill To: cstueckjuergen@web.de Cc: dhcwg@ietf.org In-Reply-To: <200208230659.g7N6xsX23089@mailgate5.cinetic.de> References: <200208230659.g7N6xsX23089@mailgate5.cinetic.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 27 Aug 2002 11:08:56 -0700 Message-Id: <1030471736.4957.18.camel@timmy> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: udhcpd Win98 interoperability Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > define 'ours' a little better, do you mean if there is a static mapping > > for the address that we take care of? > > > > OK, I would say the requested address should be NAKed if > - we have static mapping for it on another client > - it is already assigned to one of our other clients > - it was assigned to the requesting client, but the lease has already timed out > > Do you think this is reasonable? > I'm not sure if nak'ing a lease that timed out is the correct behavior if the address is still available, the lease can just be extended as if it never ran out (apparent disagreement on system clocks). Here is the new behavior my server has if it has no record of the client: lease = find_lease_by_chaddr(packet.chaddr); ... if (lease) { ... /* what to do if we have no record of the client */ } else if (server_id) { /* SELECTING State */ } else if (requested) { /* INIT-REBOOT State */ if ((lease = find_lease_by_yiaddr(requested_align))) { if (lease_expired(lease)) { /* probably best if we drop this lease */ memset(lease->chaddr, 0, 16); /* make some contention for this address */ } else sendNAK(&packet); } else if (requested_align < server_config.start || requested_align > server_config.end) { sendNAK(&packet); } /* else remain silent */ } else { /* RENEWING or REBINDING State */ } note: code is under the terms of the GPL _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 28 07:58:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25370; Wed, 28 Aug 2002 07:58:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SBwVo22927; Wed, 28 Aug 2002 07:58:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SBuwo22877 for ; Wed, 28 Aug 2002 07:56:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24463; Wed, 28 Aug 2002 07:55:24 -0400 (EDT) Message-Id: <200208281155.HAA24463@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org, ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 28 Aug 2002 07:55:23 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-02.txt,.pdf Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Options for Internet Storage Name Service Author(s) : J. Tseng et al. Filename : draft-ietf-dhc-isnsoption-02.txt,.pdf Pages : 11 Date : 2002-8-27 This document describes the DHCP option to allow iSNS clients devices using DHCP to automatically discover the location of the iSNS server. iSNS provides discovery and management capabilities for iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-isnsoption-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-isnsoption-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-8-27144429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-27144429.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 28 17:15:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19521; Wed, 28 Aug 2002 17:15:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SLFdo22996; Wed, 28 Aug 2002 17:15:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RJGeo28122 for ; Tue, 27 Aug 2002 15:16:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Date: Tue, 27 Aug 2002 14:44:44 -0400 Subject: [dhcwg] Nomcom call for volunteers Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 28 17:31:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20267; Wed, 28 Aug 2002 17:31:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SLWKo23790; Wed, 28 Aug 2002 17:32:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SLTco23655 for ; Wed, 28 Aug 2002 17:29:38 -0400 Received: from ams2eusosrv15.ams.ops.eu.uu.net (ams2eusosrv15.ams.ops.eu.uu.net [146.188.99.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20145 for ; Wed, 28 Aug 2002 17:28:01 -0400 (EDT) Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv15.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: ams2eusosrv20.ams.ops.eu.uu.net [146.188.99.75]) id QQndxl24692 for ; Wed, 28 Aug 2002 21:29:30 GMT Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQndxl28486 for ; Wed, 28 Aug 2002 21:28:47 GMT Received: from anocserve1.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: anocserve1.ams.ops.eu.uu.net [146.188.99.69]) id QQndxl28477 for ; Wed, 28 Aug 2002 21:28:47 GMT Date: Wed, 28 Aug 2002 23:28:47 +0200 (MET DST) From: Sam Critchley X-X-Sender: To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Geographic position option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi everyone, Following the thread on this about a week ago, I sent the position draft in as a personal submission (it was written up anyway), and it's now available at: http://www.ietf.org/internet-drafts/draft-critchley-dhc-location-option-00.txt I personally feel there's a requirement for this, initially mainly in order to enable Location-Based Services on non-telephony mobile networks, which isn't easily served by RFC1712, or a DNS-based system. I think, however, that it might be possible to alter the format of the geographic position sentence in order to emulate the GPOS RR, although RFC1712 makes no mention of either geodesic datum or positional accuracy. I'd be interested in hearing more thoughts and opinions, both on the option itself, the requirement for it, and on what should be done with the draft now. Many thanks, Sam _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 29 11:33:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27154; Thu, 29 Aug 2002 11:33:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TFXRo20750; Thu, 29 Aug 2002 11:33:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TFQMo20492 for ; Thu, 29 Aug 2002 11:26:22 -0400 Received: from io.irean.vt.edu (io.irean.vt.edu [128.173.52.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26742 for ; Thu, 29 Aug 2002 11:24:48 -0400 (EDT) Received: (from wells@localhost) by io.irean.vt.edu (8.11.6/8.11.6) id g7TFPnC05783 for dhcwg@ietf.org; Thu, 29 Aug 2002 11:25:49 -0400 Date: Thu, 29 Aug 2002 11:25:49 -0400 From: John Wells To: dhcwg@ietf.org Message-ID: <20020829112549.A5758@io.irean.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: [dhcwg] Address autoconfiguration Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi everyone, Is there a standardized way to trigger an IPv4 DHCP update when a node changes networks similar to Router Advertisements in IPv6? Some operating systems, like Windows, can trigger DHCP updates when they detect a disconnection then reconnection of an interface, but not all can. I thought of RAs in IPv6 or listening to RIP/OSPF packets to trigger updates, but is there any generally agreed method? Thanks, John -- John Wells, Virginia Tech Networking Lab (tel) +1 540 231-8347 (web) http://www.ee.vt.edu/~wells _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 29 18:13:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13188; Thu, 29 Aug 2002 18:13:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TMDio09822; Thu, 29 Aug 2002 18:13:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TMARo09748 for ; Thu, 29 Aug 2002 18:10:27 -0400 Received: from io.irean.vt.edu (io.irean.vt.edu [128.173.52.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13083 for ; Thu, 29 Aug 2002 18:08:50 -0400 (EDT) Received: (from wells@localhost) by io.irean.vt.edu (8.11.6/8.11.6) id g7TM9oJ08039; Thu, 29 Aug 2002 18:09:50 -0400 Date: Thu, 29 Aug 2002 18:09:50 -0400 From: John Wells To: Alexandru Petrescu Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Address autoconfiguration Message-ID: <20020829180950.B8009@io.irean.vt.edu> References: <20020829112549.A5758@io.irean.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from petrescu@crm.mot.com on Thu, Aug 29, 2002 at 06:18:35PM +0200 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Alex, That was precisely the idea I had. It's a good one because it gives optimal routing and sidesteps communicating the home address and care-of address to mobile nodes. Can any DHCP servers do this now? Thanks, John On Thu, Aug 29, 2002 at 06:18:35PM +0200, Alexandru Petrescu wrote: > John Wells writes: > > I thought of RAs in IPv6 or listening to RIP/OSPF packets to trigger > > updates, but is there any generally agreed method? > > I was thinking of RA triggers DHCP Confirm triggers RIP update, as a > way to do local mobility. > > I have some text and slides hidden somewhere. > > Alex -- John Wells, Virginia Tech Networking Lab (tel) +1 540 231-8347 (web) http://www.ee.vt.edu/~wells _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 30 07:37:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11507; Fri, 30 Aug 2002 07:37:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7UBbho25984; Fri, 30 Aug 2002 07:37:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TGIjo24186 for ; Thu, 29 Aug 2002 12:18:45 -0400 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29259 for ; Thu, 29 Aug 2002 12:17:11 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA19741 for ; Thu, 29 Aug 2002 09:18:41 -0700 (MST)] Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA12479 for ; Thu, 29 Aug 2002 09:16:28 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (8.11.6/8.11.6) with ESMTP id g7TGIbW26768; Thu, 29 Aug 2002 11:18:38 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 718732EC86; Thu, 29 Aug 2002 18:19:31 +0200 (CEST) To: John Wells Cc: Subject: Re: [dhcwg] Address autoconfiguration References: <20020829112549.A5758@io.irean.vt.edu> From: Alexandru Petrescu Date: 29 Aug 2002 18:18:35 +0200 In-Reply-To: <20020829112549.A5758@io.irean.vt.edu> Message-ID: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , John Wells writes: > I thought of RAs in IPv6 or listening to RIP/OSPF packets to trigger > updates, but is there any generally agreed method? I was thinking of RA triggers DHCP Confirm triggers RIP update, as a way to do local mobility. I have some text and slides hidden somewhere. Alex _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 30 07:37:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11533; Fri, 30 Aug 2002 07:37:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7UBbuo26006; Fri, 30 Aug 2002 07:37:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7U9BSo18925 for ; Fri, 30 Aug 2002 05:11:28 -0400 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08414 for ; Fri, 30 Aug 2002 05:09:56 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id CAA04611; Fri, 30 Aug 2002 02:11:26 -0700 (MST)] Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id CAA08039; Fri, 30 Aug 2002 02:11:25 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (8.11.6/8.11.6) with ESMTP id g7U9BNj06781; Fri, 30 Aug 2002 04:11:24 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 981852EC8B; Fri, 30 Aug 2002 11:12:16 +0200 (CEST) To: John Wells Cc: Subject: Re: [dhcwg] Address autoconfiguration References: <20020829112549.A5758@io.irean.vt.edu> <20020829180950.B8009@io.irean.vt.edu> From: Alexandru Petrescu Date: 30 Aug 2002 11:11:19 +0200 In-Reply-To: <20020829180950.B8009@io.irean.vt.edu> Message-ID: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi John, John Wells writes: > Hi Alex, > That was precisely the idea I had. It's a good one because it gives > optimal routing and sidesteps communicating the home address and care-of > address to mobile nodes. We can discuss about this, but this is only half DHC. It gives optimal routing but only within that routing domain. No need of HoA and CoA but only if staying in that domain. > Can any DHCP servers do this now? I don't know of any DHCP implementation that interacts with routing daemons. But enhanching a DHCPv6 implementation to send UDP messages to routing daemons, a proof-of-concept like, must not be very difficult. RIP needs some modifications to act well for this. Again, off-topic, but links torn down information propagate badly. Alex _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg