From int-area-bounces@lists.ietf.org Mon Sep 03 10:54:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISDIV-0005f0-SU; Mon, 03 Sep 2007 10:53:03 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1ISDIU-0005ev-Ul for int-area-confirm+ok@megatron.ietf.org; Mon, 03 Sep 2007 10:53:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISDIU-0005en-LE for int-area@ietf.org; Mon, 03 Sep 2007 10:53:02 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISDIS-0005oJ-SO for int-area@ietf.org; Mon, 03 Sep 2007 10:53:02 -0400 Received: from epmmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JNS0049GRYHXF@mailout3.samsung.com> for int-area@ietf.org; Mon, 03 Sep 2007 23:51:53 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JNS003XZRYHA1@mmp2.samsung.com> for int-area@ietf.org; Mon, 03 Sep 2007 23:51:58 +0900 (KST) Date: Mon, 03 Sep 2007 20:22:12 +0530 From: Shubhranshu To: Internet Area Message-id: <02eb01c7ee3a$0ae93d00$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: -4.0 (----) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Ian Chakeres , Thomas Clausen , macker@itd.nrl.navy.mil Subject: [Int-area] Review of draft-ietf-autoconf-manetarch-05.txt X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0545457176==" Errors-To: int-area-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0545457176== Content-type: multipart/alternative; boundary="Boundary_(ID_zEFi/qaDI8A04kPqNmCWPg)" This is a multi-part message in MIME format. --Boundary_(ID_zEFi/qaDI8A04kPqNmCWPg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi All, We'd like to solicit Int-area review of the Autoconf WG document "Mobile Ad hoc Network Architecture", draft-ietf-autoconf-manetarch-05.txt, available at http://tools.ietf.org/id/draft-ietf-autoconf-manetarch-05.txt . We'd especially like to get comments from the Int-area members on Section 5 which presents an architectural model of Mobile Ad Hoc Networks, MANETs preserving the integrity of the conventional IP addressing architecture while allowing for the particularities of MANETs. Please send your comments to int-area@ietf.org & autoconf@ietf.org . This document is in the Working Group Last Call, which ends on Monday, Sept 24. Thanks, Shubhranshu Autoconf WG Co-chair. --Boundary_(ID_zEFi/qaDI8A04kPqNmCWPg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi All,
 
We'd like to solicit Int-area review of the Autoconf WG document
"Mobile Ad hoc Network Architecture", draft-ietf-autoconf-manetarch-05.txt,
especially like to get comments from the Int-area members on Section 5 which
presents an architectural model of Mobile Ad Hoc Networks, MANETs preserving
the integrity of the conventional IP addressing architecture while allowing for the 
particularities of MANETs.  
 
Please send your comments to int-area@ietf.org & autoconf@ietf.org .
 
This document is in the Working Group Last Call, which ends on Monday, Sept 24.
 
Thanks,
Shubhranshu
Autoconf WG Co-chair.
--Boundary_(ID_zEFi/qaDI8A04kPqNmCWPg)-- --===============0545457176== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area --===============0545457176==-- From int-area-bounces@lists.ietf.org Wed Sep 05 03:52:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISpgo-0001UK-7u; Wed, 05 Sep 2007 03:52:42 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1ISpgm-0001U9-PZ for int-area-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 03:52:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISpgm-0001U1-Cp for int-area@ietf.org; Wed, 05 Sep 2007 03:52:40 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISpgk-0002su-Kv for int-area@ietf.org; Wed, 05 Sep 2007 03:52:40 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 73B331986BA for ; Wed, 5 Sep 2007 10:52:37 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2C2E1198680 for ; Wed, 5 Sep 2007 10:52:37 +0300 (EEST) Message-ID: <46DE6045.6090009@piuha.net> Date: Wed, 05 Sep 2007 10:52:37 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Internet Area References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Cc: Subject: [Int-area] Vancouver BOF requests X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Please note the following deadlines: > ----------------------------------------------------------------- > 70th IETF - Vancouver, BC, Canada > Meeting Dates: December 2-7, 2007 > ----------------------------------------------------------------- > We will be accepting scheduling requests for all Working Groups and BOFs > starting today, Tuesday, September 4, 2007. The milestones and deadlines > for scheduling-related activities are as follows: > > -- Cut-off date for requests to schedule Working Group meetings and for > preliminary BOF proposals to ADs: Monday, October 1 at 17:00 ET (21:00 > UTC/GMT). > -- Cut-off date for requests to schedule BoFs: Monday, October 22 at 17:00 > ET (21:00 UTC/GMT). > -- Preliminary agenda published for comment: Friday, October 26 by > midnight ET. > -- Cut-off date for requests to reschedule Working Group and BOF meetings: > Wednesday, November 7 at 09:00 ET (14:00 UTC/GMT). > -- Final agenda published: Monday, November 12 before midnight ET. > -- Draft Working Group agendas due: Wednesday, November 21 at 17:00 ET > (22:00 UTC/GMT). > -- Revised Working Group agendas due: Monday, November 26 at 12:00 ET > (17:00 UTC/GMT), upload using IETF Meeting Materials Management Tool > > Submitting Requests for Working Group and BOF Sessions > > Please submit requests to schedule your Working Group sessions using the > "IETF Meeting Session Request Tool," a Web-based tool for submitting all > of the information that the Secretariat requires to schedule your > sessions. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > Please send requests to schedule your BOF sessions to agenda@ietf.org. > Please include the acronym of your BOF in the subject line of the message, > and include all of the information specified in item (4) of "Requesting > Meeting Sessions at IETF Meetings" in the body. (This document is > included below.) > > Submitting Session Agendas > > For the convenience of meeting attendees, we ask that you submit the > agendas for your Working Group sessions as early as possible. Draft > Working Group agendas are due Wednesday, November 21 by 17:00 ET (22:00 > UTC/GMT). Revised Working Group agendas are due no later than Monday, > November 26 at 12:00 ET (17:00 UTC/GMT). The proposed agenda for a BOF > session should be submitted along with your request for a session. Please > be sure to copy your Area Director on that message. > > Please submit the agendas for your Working Group sessions using the "IETF > Meeting Materials Management Tool," a Web-based tool for making your > meeting agenda, minutes, and presentation slides available to the > community before, during, and after an IETF meeting. If you are a BOF > chair, then you may use the tool to submit a revised agenda as well as > other materials for your BOF once the BOF has been approved. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi > > Additional information about this tool is available at: > > http://www.ietf.org/instructions/meeting_materials_tool.html > > Agendas submitted via the tool will be available to the public on the > "IETF Meeting Materials" Web page as soon as they are submitted. > > The URL for the "IETF 70 Meeting Materials" Web page is: > > https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=70 > > If you are a Working Group chair, then you already have accounts on the > "IETF Meeting Session Request Tool" and the "IETF Meeting Materials > Management Tool." The same User ID and password will work for both tools. > If you are a BOF chair who is not also a Working Group chair, then you > will be given an account on the "IETF Meeting Materials Management Tool" > when your BOF has been approved. If you require assistance in using > either tool, or wish to report a bug, then please send a message to: > ietf-action@ietf.org. > =============================================================== > For your convenience, comprehensive information on requesting meeting > sessions at IETF 70 is presented below: > > 1. Requests to schedule Working Group sessions should be submitted using > the "IETF Meeting Session Request Tool," a Web-based tool for submitting > all of the information required by the Secretariat to schedule your > sessions. The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > If you require an account on this tool, or assistance in using it, then > please send a message to ietf-action@ietf.org. If you are unable to use > the tool, then you may send your request via e-mail to agenda@ietf.org, > with a copy to the appropriate Area Director(s). > > Requests to schedule BOF sessions must be sent to agenda@ietf.org with a > copy to the appropriate Area Director(s). > > When submitting a Working Group or BOF session request by e-mail, please > include the Working Group or BOF acronym in the Subject line. > > 2. BOFs will NOT be scheduled unless the Area Director(s) approved > request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S) > NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL > DESCRIPTION, and the information requested in (4) below. (Please read the > BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before > requesting a session for a BOF.) > > 3. A Working Group may request either one or two sessions. If your > Working Group requires more than two sessions, then your request must be > approved by an Area Director. Additional sessions will be assigned, based > on availability, after Wednesday, November 7 at 09:00 ET (14:00 UTC/GMT), > the cut-off date for requests to reschedule a session. > > 4. You MUST provide the following information before a Working Group or > BOF session will be scheduled: > > a. Working Group or BOF full name with acronym in brackets: > > b. AREA under which Working Group or BOF appears: > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > d. Expected Attendance (figures from the 69th IETF meeting are > included at the end of this message): > > e. Special requests: > > f. Number of sessions: > > g. Length of session: > - 1 hour > - 2 hours > - 2 1/2 hours > > For more information on scheduling Working Group and BOF sessions, please > refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" > (http://www.ietf.org/rfc/rfc2418.txt). > =============================================================== > For your convenience please find here a list of the IETF Area Directors > with their e-mail addresses: > > IETF Chair > Russ Housley > > Applications Area (app) > Lisa Dusseault > Chris Newman > > Internet Area (int) > Jari Arkko > Mark Townsley > > Operations & Management Area (ops) > Ronald Bonica > Dan Romascanu > > Real-time Applications and Infrastructure Area (rai) > Cullen Jennings > Jon Peterson > > Routing Area (rtg) > Ross Callon > David Ward > > Security Area (sec) > Sam Hartman > William Polk > > Transport Area (tsv) > Lars Eggert > Magnus Westerlund > =========================================================== > 69th IETF Meeting Attendance Number > > 16ng 66 > 6lowpan No Blue Sheets > ancp No Blue Sheets > apm (BoF) 93 > apparea (AG) 75 > autoconf 77 > autoconf (2nd session) 63 > avt 94 > avt (2nd session) 73 > behave 53 > biff (BoF) 30 > bliss 123 > bmwg 38 > btns 38 > calcify 14 > capwap 44 > ccamp 112 > ccamp (2nd session) 95 > dccp 33 > dhc 66 > dime 35 > dkim 58 > dnsop 104 > dtnrg 51 > eai 47 > ecrit 93 > emu 39 > enum 82 > forces 17 > geopriv 100 > grow 73 > hiprg/emerg 77 > hokey 87 > httpbis (BoF) 61 > iccrg 52 > idr 112 > intarea (AG) 120 > ipdvb 7 > ipfix 24 > ippm No Blue Sheets > ipr 23 > isis 58 > isms 25 > keyprov 46 > kitten 17 > krb-wg 32 > krb-wg (2nd session) 21 > l1vpn CANCELLED > l2vpn No Blue Sheets > l3vpn 83 > lemonade 35 > lemonade (2nd session) 25 > ltans 16 > manet 77 > mboned 50 > mediactrl 42 > mip4 31 > mip6 101 > mipshop 100 > mmusic 42 > mmusic (2nd session) 77 > mobopts (RG) 85 > monami6 90 > mpls 152 > nea 62 > nee (BoF) 46 > nemo 92 > netconf 38 > netlmm 99 > nfsv4 20 > nsis 36 > ntp 37 > opsawg 66 > ospf 56 > p2psip (adhoc) 36 > p2psip 154 > pana 34 > pce 63 > pcn 79 > pim 32 > pkix 52 > pwe3 127 > radext 39 > rmt 32 > rpsec 50 > rrg 145 > rtgarea (AG) 136 > rtgwg 97 > saag (AG) 149 > samrg 41 > sasl 31 > sidr 89 > sieve 17 > simple 81 > sip 162 > sip (2nd session) 128 > sipping 137 > sipping (2nd session) 135 > smime 17 > softwire 51 > speermint 125 > tam (BoF) 103 > tcpm 35 > tls 54 > trill 44 > trill (2nd session) 27 > tsvarea (AG) 67 > tsvwg 81 > v6ops 130 > vcarddav (BoF) 24 > xcon 45 > xsdmi (BoF) 29 > > > > _______________________________________________ > BOFCHAIRS mailing list > BOFCHAIRS@ietf.org > https://www1.ietf.org/mailman/listinfo/bofchairs > > > > > _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sun Sep 09 17:33:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUUPD-0007vI-Qu; Sun, 09 Sep 2007 17:33:23 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IUUPD-0007vC-2H for int-area-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 17:33:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUUPC-0007v4-O9 for int-area@ietf.org; Sun, 09 Sep 2007 17:33:22 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUUPC-0006AP-2d for int-area@ietf.org; Sun, 09 Sep 2007 17:33:22 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 74D9819865C for ; Mon, 10 Sep 2007 00:33:20 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2C8A5198659 for ; Mon, 10 Sep 2007 00:33:20 +0300 (EEST) Message-ID: <46E466A0.5010301@piuha.net> Date: Mon, 10 Sep 2007 00:33:20 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Internet Area References: <46E1AC01.3050800@qualcomm.com> In-Reply-To: <46E1AC01.3050800@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Int-area] FW: Nomcom 2007-8: Nominations Close on Sep 10, 2007 X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Please see the following message from the chair of Nomcom -- we really need more people to be proposed & available for various IETF management roles. Jari Lakshminath Dondeti wrote: > WGchairs, IESG and IAB members > > Please forward this request to the lists you manage and request > feedback and nominations. > > All, > > Here is the link to nominate: > https://tools.ietf.org/group/nomcom/07/nominate > > You may also send nominations or comments via email to > nomcom07@ietf.org or ldondeti@qualcomm.com. > > We have received very few nominations (1, 2, 2, 2, 3, 4, 8, 8, 19) and > even fewer accepted (1-2 people in each area, IAB acceptances is 4 at > last count). > > I request the community to provide feedback on the incumbents (send > email or send notes via the web page). > > 1) If you think that the incumbent is doing a good job > a) provide feedback AND > b) nominate similar people just in case there is strong negative > feedback on the incumbent > > 2) If you think the incumbent can do somethings better > a) provide feedback AND > b) nominate someone who you think might do better > > Candidates, if time commitment is the only issue, please indicate that > to the nomcom and accept the nominations. > > thanks, > Lakshminath > > > > _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Sep 14 04:49:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW6rW-000734-AG; Fri, 14 Sep 2007 04:49:18 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IW6rU-00072s-NA for int-area-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 04:49:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW6rU-00072j-CA for int-area@ietf.org; Fri, 14 Sep 2007 04:49:16 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IW6rT-0005z8-P9 for int-area@ietf.org; Fri, 14 Sep 2007 04:49:16 -0400 Received: (qmail invoked by alias); 14 Sep 2007 08:49:14 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp028) with SMTP; 14 Sep 2007 10:49:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+osb0F8Y2ofd0+rfIorWU2fn4xf60vrgOWc9hVR4 BZYBaqhLHCMW7N Message-ID: <46EA4B08.1060307@gmx.net> Date: Fri, 14 Sep 2007 10:49:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: int-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Int-area] Discovering a Location Server in the Access Network X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hi all, I would need some feedback regarding work that is currently being done in the GEOPRIV working group. For some time we have been working on an application layer protocol that allows the end host to obtain its own location information (or a reference to it) from a server (called LIS) in the access network. This LIS indeed needs to be located in the access network (and not at an arbitrary place on the Internet) since only the layer 2/layer 3 provider is able to determine the precise location of end point. A year ago I lead a design team that captured the problem statement and requirements. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt The protocol that provides the functionality of the above-mentioned requirements document is HELD: http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery Providing the end host with the address of the LIS is relatively easy if you can use DHCP. However, there are deployment environments (such as DSL networks) where the DSL operator cannot control the DSL home routers and any information that is provided by the DSL operator may not be relayed to the end host via this box. So, to overcome this issue the group had an idea: Let's use a different discovery technique that does not require upgrades to intermediate devices (such as this DSL home router). In short, the current proposal (see http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; ignoring Section 2 which defines the DHCP portion) essentially does the following: * Discover the public IP address of the end point * Perform a reverse DNS lookup to learn the domain * Lookup the LIS for that domain * Contact the LIS We have investigated other solutions as well (see Section 4 of http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt) but the group (or at least a few folks) believes that this is a "good" approach. I had a chat with Jari and we both agree that this topoic falls into the expertise of the Internet Area. Hence, I would like to solicit feedback from you. Ciao Hannes _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Sep 14 10:06:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWBoj-0007fa-9T; Fri, 14 Sep 2007 10:06:45 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IWBoh-0007Za-GD for int-area-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 10:06:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWBog-0007W2-PT for int-area@ietf.org; Fri, 14 Sep 2007 10:06:42 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IWBof-0007Dw-H5 for int-area@ietf.org; Fri, 14 Sep 2007 10:06:42 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1189778799!4183226!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 4701 invoked from network); 14 Sep 2007 14:06:40 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-8.tower-153.messagelabs.com with SMTP; 14 Sep 2007 14:06:40 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l8EE6dKk001608; Fri, 14 Sep 2007 07:06:39 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l8EE6c66008254; Fri, 14 Sep 2007 09:06:38 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l8EE6aqJ008218; Fri, 14 Sep 2007 09:06:37 -0500 (CDT) Message-ID: <46EA956B.1030700@gmail.com> Date: Fri, 14 Sep 2007 16:06:35 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Int-area] Discovering a Location Server in the Access Network References: <46EA4B08.1060307@gmx.net> In-Reply-To: <46EA4B08.1060307@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-5, 13/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hi Hannes, let me try to give some thoughts. But your mail is such a concentrate of information to newcomers to GEOPRIV. I'm not sure I get everything right, but anyways, here goes. Hannes Tschofenig wrote: > > A year ago I lead a design team that captured the problem statement > and requirements. The document is available here: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt draft-ietf-geopriv-l7-lcp-ps-05.txt: > 3.2. Moving Network > > An example of a moving network is [...] (As a side note, I'm happy that the GEOPRIV L7 PS and reqs document mentions moving networks and describes them. I'm already happy with the terminology, because many people I'm talking to seem to refuse to accept this 'moving network' term and prefer 'mobile network' ignoring the potential clash with 'mobile networks' that don't move but support mobility of hosts. One would also maybe cite "mobile network" of RFC4885 "Network Mobility Support Terminology" and "Mobility Terminology" RFC3753 and last but not least rfc2002 Mobile IPv4 probably the first to mention "mobile networks" in its section 4.5. I think MANET documents may too. Technically, the 'moving networks' you describe are a little bit different than the 'mobile networks' which run Mobile IP NEMO extensions. Your movnets have the LFN (your Ethernet laptop) do the PPPoE game and use the MR (your NTE) as a modem I believe. A multi-host WiMax deployment. The 'mobile networks' have the Mobile Router (your NTE) do the dialup, eventually PPPoE but any other PtP or shared media, for the access. But, I think 'moving networks' per your definition and 'mobile networks' per Mobile IP stuff are conceptually the same thing. I'd like to be able to call the Mobile IP NEMO-based 'mobile networks' - 'moving networks'. Anyways, just a digression.) > In short, the current proposal (see > http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; > ignoring Section 2 which defines the DHCP portion) essentially does > the following: > > * Discover the public IP address of the end point I think it should say 'Discover ... address of the LIS', right? And not 'of the end point'(?) [...] > We have investigated other solutions as well (see Section 4 of > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt) > but the group (or at least a few folks) believes that this is a > "good" approach. Section4: > DHCP-based discovery, DNS-based discovery, Redirect [HTTP or AAA] > rule, multicast DNS queries, anycast and Teredo discovery. That's fine it covers all I could think of, but there's (1) the EXPERIMENTAL IPv6 Node Information Queries RFC4620 as well. It's limited to link-local multicast but I think that would be an advantage (and not an inconvenient) because one would want that LIS server to be as close to the querier, for geographical precision, I think. Some IKEv2 extension possibility for discovering parameters too, and BOOTP and last but not least Service Location Protocol RFC2165. draft-thomson-geopriv-lis-discovery-02: > 1.2. U-NAPTR Discovery > > Where DHCP is not available, the DNS might be able to provide a URI. If DHCP is not available then the host doesn't have the DNS Server address either, thus no way to obtain that URI, right? If I can manually configure the DNS Server address then I can manually configure its location info as well, right? Alex > > I had a chat with Jari and we both agree that this topoic falls into > the expertise of the Internet Area. Hence, I would like to solicit > feedback from you. > > Ciao Hannes > > > > _______________________________________________ Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Sep 14 10:59:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWCdJ-0006F7-AC; Fri, 14 Sep 2007 10:59:01 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IWCdI-0006F2-QL for int-area-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 10:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWCdI-0006Eu-GJ for int-area@ietf.org; Fri, 14 Sep 2007 10:59:00 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IWCdG-00005C-VL for int-area@ietf.org; Fri, 14 Sep 2007 10:59:00 -0400 Received: (qmail invoked by alias); 14 Sep 2007 14:58:56 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp035) with SMTP; 14 Sep 2007 16:58:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+V8KJUT7mVDGsEwhlpwY4MmfQooh/2An49XKz+4Q iVGRo322Ex8g9s Message-ID: <46EAA1AF.2000000@gmx.net> Date: Fri, 14 Sep 2007 16:58:55 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Int-area] Discovering a Location Server in the Access Network References: <46EA4B08.1060307@gmx.net> <46EA956B.1030700@gmail.com> In-Reply-To: <46EA956B.1030700@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hi Alex, Alexandru Petrescu wrote: > Hi Hannes, let me try to give some thoughts. But your mail is such a > concentrate of information to newcomers to GEOPRIV. > > I'm not sure I get everything right, but anyways, here goes. > > Hannes Tschofenig wrote: > >> >> A year ago I lead a design team that captured the problem statement >> and requirements. The document is available here: >> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt > draft-ietf-geopriv-l7-lcp-ps-05.txt: >> 3.2. Moving Network >> >> An example of a moving network is [...] > > (As a side note, I'm happy that the GEOPRIV L7 PS and reqs document > mentions moving networks and describes them. I'm already happy with > the terminology, because many people I'm talking to seem to refuse to > accept this 'moving network' term and prefer 'mobile network' ignoring > the potential clash with 'mobile networks' that don't move but support > mobility of hosts. > > One would also maybe cite "mobile network" of RFC4885 "Network > Mobility Support Terminology" and "Mobility Terminology" RFC3753 and > last but not least rfc2002 Mobile IPv4 probably the first to mention > "mobile networks" in its section 4.5. I think MANET documents may too. > Yep. I could cite that RFC. > Technically, the 'moving networks' you describe are a little bit > different than the 'mobile networks' which run Mobile IP NEMO > extensions. Your movnets have the LFN (your Ethernet laptop) do the > PPPoE game and use the MR (your NTE) as a modem I believe. A > multi-host WiMax deployment. The 'mobile networks' have the Mobile > Router (your NTE) do the dialup, eventually PPPoE but any other PtP or > shared media, for the access. > > But, I think 'moving networks' per your definition and 'mobile > networks' per Mobile IP stuff are conceptually the same thing. I'd > like to be able to call the Mobile IP NEMO-based 'mobile networks' - > 'moving networks'. > > Anyways, just a digression.) > >> In short, the current proposal (see >> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; >> ignoring Section 2 which defines the DHCP portion) essentially does >> the following: >> >> * Discover the public IP address of the end point > > I think it should say 'Discover ... address of the LIS', right? And > not 'of the end point'(?) > No; it really means that you learn your own public IP address. That's no problem if you already have one but you might also be behind a NAT (which is extremely common in a DSL network). Hence, knowing your private IP address is not very useful for the discovery of the LIS since you will not find a LIS in your own home network. > [...] >> We have investigated other solutions as well (see Section 4 of >> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt) >> but the group (or at least a few folks) believes that this is a >> "good" approach. > > Section4: >> DHCP-based discovery, DNS-based discovery, Redirect [HTTP or AAA] >> rule, multicast DNS queries, anycast and Teredo discovery. > > That's fine it covers all I could think of, but there's (1) the > EXPERIMENTAL IPv6 Node Information Queries RFC4620 as well. It's > limited to link-local multicast but I think that would be an advantage > (and not an inconvenient) because one would want that LIS server to be > as close to the querier, for geographical precision, I think. I can certainly list it as an option but the fact that it is restricted to a link-local multicast does not make it very attractive for our usage environment. > > Some IKEv2 extension possibility for discovering parameters too, and > BOOTP and last but not least Service Location Protocol RFC2165. Yep. I could also mention these. I have to refresh my memory about SLP but IKEv2 is certainly not very useful in our environment. > > draft-thomson-geopriv-lis-discovery-02: >> 1.2. U-NAPTR Discovery >> >> Where DHCP is not available, the DNS might be able to provide a URI. > > If DHCP is not available then the host doesn't have the DNS Server > address either, thus no way to obtain that URI, right? DHCP is available but you will only learn the information obtained from your DSL router (which plays the role of the DHCP server for your home network). This DSL router will, however, not forward information from the DSL operator. It is somewhat independent. > > If I can manually configure the DNS Server address then I can manually > configure its location info as well, right? Ciao Hannes > > Alex > >> >> I had a chat with Jari and we both agree that this topoic falls into >> the expertise of the Internet Area. Hence, I would like to solicit >> feedback from you. >> >> Ciao Hannes >> >> >> >> _______________________________________________ Int-area mailing list >> Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Sep 14 11:37:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWDF0-0000Jj-31; Fri, 14 Sep 2007 11:37:58 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IWDEz-0000JW-7I for int-area-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 11:37:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWDEy-0000JN-TZ for int-area@ietf.org; Fri, 14 Sep 2007 11:37:56 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IWDEx-0000qx-ON for int-area@ietf.org; Fri, 14 Sep 2007 11:37:56 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1189784274!21311271!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 30762 invoked from network); 14 Sep 2007 15:37:54 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-5.tower-119.messagelabs.com with SMTP; 14 Sep 2007 15:37:54 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8EFbrFg027482; Fri, 14 Sep 2007 08:37:53 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l8EFbqLJ025763; Fri, 14 Sep 2007 10:37:52 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8EFbogl025732; Fri, 14 Sep 2007 10:37:51 -0500 (CDT) Message-ID: <46EAAACD.4000603@gmail.com> Date: Fri, 14 Sep 2007 17:37:49 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Int-area] Discovering a Location Server in the Access Network References: <46EA4B08.1060307@gmx.net> <46EA956B.1030700@gmail.com> <46EAA1AF.2000000@gmx.net> In-Reply-To: <46EAA1AF.2000000@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-5, 13/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hannes Tschofenig wrote: >>> >>> In short, the current proposal (see >>> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; >>> ignoring Section 2 which defines the DHCP portion) essentially does >>> the following: >>> >>> * Discover the public IP address of the end point >> >> I think it should say 'Discover ... address of the LIS', right? And >> not 'of the end point'(?) >> > No; it really means that you learn your own public IP address. That's no > problem if you already have one but you might also be behind a NAT > (which is extremely common in a DSL network). Hence, knowing your > private IP address is not very useful for the discovery of the LIS since > you will not find a LIS in your own home network. But you're sure that it's necessary to discover my IP address when I'm behind NAT? Does the LIS need to contact me without me needing to contact it first? >> [...] >>> We have investigated other solutions as well (see Section 4 of >>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt) >>> but the group (or at least a few folks) believes that this is a >>> "good" approach. >> >> Section4: >>> DHCP-based discovery, DNS-based discovery, Redirect [HTTP or AAA] >>> rule, multicast DNS queries, anycast and Teredo discovery. >> >> That's fine it covers all I could think of, but there's (1) the >> EXPERIMENTAL IPv6 Node Information Queries RFC4620 as well. It's >> limited to link-local multicast but I think that would be an advantage >> (and not an inconvenient) because one would want that LIS server to be >> as close to the querier, for geographical precision, I think. > I can certainly list it as an option but the fact that it is restricted > to a link-local multicast does not make it very attractive for our usage > environment. Ok. I thought the reverse but anyways. >> Some IKEv2 extension possibility for discovering parameters too, and >> BOOTP and last but not least Service Location Protocol RFC2165. > Yep. I could also mention these. > > I have to refresh my memory about SLP but IKEv2 is certainly not very > useful in our environment. Well, at some point you talk using DNS in a secure manner (in the security section)... Anyways, thanks. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Sep 14 20:46:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWLnz-0007Ro-MV; Fri, 14 Sep 2007 20:46:39 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IWLny-0007RZ-Nc for int-area-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 20:46:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWLny-0007RQ-DN for int-area@ietf.org; Fri, 14 Sep 2007 20:46:38 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWLnw-00029j-Fs for int-area@ietf.org; Fri, 14 Sep 2007 20:46:38 -0400 Received: (snipe 5098 invoked by uid 0); 15 Sep 2007 09:47:05 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.802797 secs); Received: from unknown (HELO ?210.107.251.4?) (Z???own@210.107.251.4) by unknown with SMTP; 15 Sep 2007 09:47:04 +0900 X-SNIPER-SENDERIP: 210.107.251.4 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: alexandru.petrescu@gmail.com, Hannes.Tschofenig@gmx.net, int-area@ietf.org, yangwooko@gmail.com Message-ID: <46EB2B75.4000902@icu.ac.kr> Date: Sat, 15 Sep 2007 09:46:45 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Int-area] Discovering a Location Server in the Access Network References: <46EA4B08.1060307@gmx.net> <46EA956B.1030700@gmail.com> <46EAA1AF.2000000@gmx.net> <46EAAACD.4000603@gmail.com> In-Reply-To: <46EAAACD.4000603@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Alexandru Petrescu wrote: > > Hannes Tschofenig wrote: >>>> >>>> In short, the current proposal (see >>>> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; >>>> ignoring Section 2 which defines the DHCP portion) essentially does >>>> the following: >>>> >>>> * Discover the public IP address of the end point >>> >>> I think it should say 'Discover ... address of the LIS', right? And >>> not 'of the end point'(?) >>> >> No; it really means that you learn your own public IP address. That's >> no problem if you already have one but you might also be behind a NAT >> (which is extremely common in a DSL network). Hence, knowing your >> private IP address is not very useful for the discovery of the LIS >> since you will not find a LIS in your own home network. > > But you're sure that it's necessary to discover my IP address when I'm > behind NAT? Does the LIS need to contact me without me needing to > contact it first? What I understood from the first mail sent by Hannes is that discovery of the public address is necessary for the next step (i.e. DNS reverse lookup) to work. If there is other way to get the address of LIS without going through presented steps, then that is just yet another alternative. Regards _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sat Sep 15 04:24:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWSx5-00012Q-96; Sat, 15 Sep 2007 04:24:31 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IWSx3-00012A-QX for int-area-confirm+ok@megatron.ietf.org; Sat, 15 Sep 2007 04:24:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWSx3-00011z-FA for int-area@ietf.org; Sat, 15 Sep 2007 04:24:29 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWSx2-0003q9-I7 for int-area@ietf.org; Sat, 15 Sep 2007 04:24:29 -0400 Received: (qmail invoked by alias); 15 Sep 2007 08:24:26 -0000 Received: from p54987CAB.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.124.171] by mail.gmx.net (mp052) with SMTP; 15 Sep 2007 10:24:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Yc4MBYVEYZ5dVPDVaVkNslEdDiIzok1zdVqNqMJ l6wHI4vx6CKNgY Message-ID: <46EB96BA.7030608@gmx.net> Date: Sat, 15 Sep 2007 10:24:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Int-area] Discovering a Location Server in the Access Network References: <46EA4B08.1060307@gmx.net> <46EA956B.1030700@gmail.com> <46EAA1AF.2000000@gmx.net> <46EAAACD.4000603@gmail.com> In-Reply-To: <46EAAACD.4000603@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hi Alex, Alexandru Petrescu wrote: > Hannes Tschofenig wrote: >>>> >>>> In short, the current proposal (see >>>> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; >>>> ignoring Section 2 which defines the DHCP portion) essentially >>>> does the following: >>>> >>>> * Discover the public IP address of the end point >>> >>> I think it should say 'Discover ... address of the LIS', right? And >>> not 'of the end point'(?) >>> >> No; it really means that you learn your own public IP address. That's >> no problem if you already have one but you might also be behind a NAT >> (which is extremely common in a DSL network). Hence, knowing your >> private IP address is not very useful for the discovery of the LIS >> since you will not find a LIS in your own home network. > > But you're sure that it's necessary to discover my IP address when I'm > behind NAT? Does the LIS need to contact me without me needing to > contact it first? > Yes, you have to find the LIS first. In order to find the LIS in that scenario you need to learn the domain name of the access network (in this case the DSL operator's access network).When you know your own public IP address then you are able to find the domain name of the DSL operator's LIS in that network. >>> [...] >>>> We have investigated other solutions as well (see Section 4 of >>>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt) >>>> >>>> but the group (or at least a few folks) believes that this is a >>>> "good" approach. >>> >>> Section4: >>>> DHCP-based discovery, DNS-based discovery, Redirect [HTTP or AAA] >>>> rule, multicast DNS queries, anycast and Teredo discovery. >>> >>> That's fine it covers all I could think of, but there's (1) the >>> EXPERIMENTAL IPv6 Node Information Queries RFC4620 as well. It's >>> limited to link-local multicast but I think that would be an advantage >>> (and not an inconvenient) because one would want that LIS server to be >>> as close to the querier, for geographical precision, I think. >> I can certainly list it as an option but the fact that it is >> restricted to a link-local multicast does not make it very attractive >> for our usage environment. > > Ok. I thought the reverse but anyways. > >>> Some IKEv2 extension possibility for discovering parameters too, and >>> BOOTP and last but not least Service Location Protocol RFC2165. >> Yep. I could also mention these. >> >> I have to refresh my memory about SLP but IKEv2 is certainly not very >> useful in our environment. > > Well, at some point you talk using DNS in a secure manner (in the > security section)... > Providing channel security between the end host and the LIS is an orthogonal issue. Current requirements indicate that only server-side authentication is realistic to mandate. IKEv2 does not provide a way to execute server-side only authentication; TLS would just be doing a fine job and it is a more natural choice for an application layer protocol (with HELD XML is carried on top of HTTP) Ciao Hannes > Anyways, thanks. > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Sep 17 06:14:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXDaA-0004wr-9M; Mon, 17 Sep 2007 06:11:58 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IXDa8-0004wj-Re for int-area-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 06:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXDa8-0004wb-Hm for int-area@ietf.org; Mon, 17 Sep 2007 06:11:56 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXDa7-0007Ll-AG for int-area@ietf.org; Mon, 17 Sep 2007 06:11:56 -0400 X-IronPort-AV: E=Sophos;i="4.20,263,1186351200"; d="scan'208";a="153316166" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Sep 2007 12:11:52 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8HABqCv014100 for ; Mon, 17 Sep 2007 12:11:52 +0200 Received: from elear-mac.local (ams3-vpn-dhcp114.cisco.com [10.61.64.114]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8HABq8i021784 for ; Mon, 17 Sep 2007 10:11:52 GMT Message-ID: <46EE52D6.8060809@cisco.com> Date: Mon, 17 Sep 2007 12:11:34 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Internet Area Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=665; t=1190023912; x=1190887912; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20draft-fuller-240space-00.txt |Sender:=20; bh=thGJ9YZTrkrSTS0Eu11uIlwdDy9NqUDBxXdzA+DkfMw=; b=dm04OoC99Yg3u+H7IGgxNx2QVzH+0jjePmKf9PGSqtLdnq3pF3q8/j1LceXV2vbDt2wkyMC6 pcSYJC9dkudxeaqloYYKAfE9gMdToJXh2ZBES7UEp0w9xlcowsKTP2bB; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Int-area] draft-fuller-240space-00.txt X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Dear all, I bring to your attention draft-fuller-240space-00.txt. This draft addresses 240.0.0.0/4, which is currently "reserved for future use." The authors believe that the future is rapidly approaching, and that we should begin to think about using this address space. There are a number of potential uses. All currently contemplated uses are for unicast address space. If approved, this draft would require implementors to not generate errors in the face of these addresses. Obviously getting new code out there takes time. During that time we can contemplate appropriate uses. The draft is short. Comments? Thanks, Eliot _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Sep 17 09:23:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXGXH-0007fo-7r; Mon, 17 Sep 2007 09:21:11 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IXGXG-0007fb-7K for int-area-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 09:21:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXGXF-0007fT-PL for int-area@ietf.org; Mon, 17 Sep 2007 09:21:09 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXGXE-0003ft-CR for int-area@ietf.org; Mon, 17 Sep 2007 09:21:09 -0400 Received: from [127.0.0.1] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8HDKb86024927; Mon, 17 Sep 2007 06:20:38 -0700 (PDT) Message-ID: <46EE7F04.6060607@isi.edu> Date: Mon, 17 Sep 2007 06:20:04 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Int-area] draft-fuller-240space-00.txt References: <46EE52D6.8060809@cisco.com> In-Reply-To: <46EE52D6.8060809@cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1862216180==" Errors-To: int-area-bounces@lists.ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1862216180== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB1704A2A363E127F6A483D64" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB1704A2A363E127F6A483D64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > Dear all, >=20 > I bring to your attention draft-fuller-240space-00.txt. This draft > addresses 240.0.0.0/4, which is currently "reserved for future use."=20 > The authors believe that the future is rapidly approaching, and that we= > should begin to think about using this address space. There are a > number of potential uses. All currently contemplated uses are for > unicast address space. If approved, this draft would require > implementors to not generate errors in the face of these addresses.=20 > Obviously getting new code out there takes time. During that time we > can contemplate appropriate uses. >=20 > The draft is short. >=20 > Comments? It doesn't seem appropriate to recommend behavior other than the current until these addresses are actually allocated. They remain "reserved for future use" until actually used, not before. This draft is odd in that it is recommending an action (treat as unicast) without actually defining the behavior of that space. "Partly" defining that behavior isn't, IMO, a useful step forward. Joe --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enigB1704A2A363E127F6A483D64 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG7n8RE5f5cImnZrsRAjPpAKCLhhfLtlfrId+BNLVy9wWelNdTHACgi5MJ LQ+LIMAJ08ADbRKnNCMdxQc= =rAVV -----END PGP SIGNATURE----- --------------enigB1704A2A363E127F6A483D64-- --===============1862216180== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area --===============1862216180==-- From int-area-bounces@lists.ietf.org Mon Sep 17 09:29:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXGdq-0005tF-MZ; Mon, 17 Sep 2007 09:27:58 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IXGdq-0005tA-79 for int-area-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 09:27:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXGdp-0005t2-Sz for int-area@ietf.org; Mon, 17 Sep 2007 09:27:57 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXGdp-0006Iw-GL for int-area@ietf.org; Mon, 17 Sep 2007 09:27:57 -0400 X-IronPort-AV: E=Sophos;i="4.20,265,1186351200"; d="scan'208";a="153343554" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Sep 2007 15:27:12 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8HDRCS9016515; Mon, 17 Sep 2007 15:27:12 +0200 Received: from elear-mac.local (ams3-vpn-dhcp85.cisco.com [10.61.64.85]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8HDR7Aq013536; Mon, 17 Sep 2007 13:27:07 GMT Message-ID: <46EE8099.3050809@cisco.com> Date: Mon, 17 Sep 2007 15:26:49 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Joe Touch Subject: Re: [Int-area] draft-fuller-240space-00.txt References: <46EE52D6.8060809@cisco.com> <46EE7F04.6060607@isi.edu> In-Reply-To: <46EE7F04.6060607@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=786; t=1190035632; x=1190899632; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Int-area]=20draft-fuller-240space-00.txt |Sender:=20; bh=R1td6nuV4fMjUWMZ1hWKNhW8atfVizgHukPQVZ6iUQA=; b=jl58eIxtVF7WMfP3/S+cwikRfEcKQAp7oY/hJ+4PN+TzjRCRR4A4WWmpzaSENLpVl3xFAQVs 5tnbamcKJ3PlbBWrTmathjAIbMtN4jL6hCA2Fo7F1lxV5qebenwlwHqx; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Joe, > It doesn't seem appropriate to recommend behavior other than the current > until these addresses are actually allocated. They remain "reserved for > future use" until actually used, not before. > > This draft is odd in that it is recommending an action (treat as > unicast) without actually defining the behavior of that space. "Partly" > defining that behavior isn't, IMO, a useful step forward. > We claim that the space can and should be used as normal unicast space, just as old Class A, B, or C space. What we don't know is whether it should be public or private, and we claim that there is no need to decide that question today because the coding for either is exactly the same. Is there wording that you think would make this more clear? Eliot _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Mon Sep 17 09:40:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXGnq-0004FT-QT; Mon, 17 Sep 2007 09:38:18 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IXGnp-0004FK-Fr for int-area-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 09:38:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXGnp-0004FC-6C for int-area@ietf.org; Mon, 17 Sep 2007 09:38:17 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXGnn-00045S-TM for int-area@ietf.org; Mon, 17 Sep 2007 09:38:17 -0400 Received: from [127.0.0.1] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8HDc7Cc028925; Mon, 17 Sep 2007 06:38:08 -0700 (PDT) Message-ID: <46EE832B.10708@isi.edu> Date: Mon, 17 Sep 2007 06:37:47 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Int-area] draft-fuller-240space-00.txt References: <46EE52D6.8060809@cisco.com> <46EE7F04.6060607@isi.edu> <46EE8099.3050809@cisco.com> In-Reply-To: <46EE8099.3050809@cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0285819664==" Errors-To: int-area-bounces@lists.ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0285819664== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6238696C93BBDC5D20383A02" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6238696C93BBDC5D20383A02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > Joe, >> It doesn't seem appropriate to recommend behavior other than the curre= nt >> until these addresses are actually allocated. They remain "reserved fo= r >> future use" until actually used, not before. >> >> This draft is odd in that it is recommending an action (treat as >> unicast) without actually defining the behavior of that space. "Partly= " >> defining that behavior isn't, IMO, a useful step forward. >> =20 >=20 > We claim that the space can and should be used as normal unicast space,= > just as old Class A, B, or C space. What we don't know is whether it > should be public or private, and we claim that there is no need to > decide that question today because the coding for either is exactly the= > same. Is there wording that you think would make this more clear? >=20 > Eliot Public and private space are coded differently in some cases - e.g., in firewalls and other configuration software (not at the net layer, though)= =2E Section 4 would need not to say "please allocate this space", not "leave it reserved" (to paraphrase). Other observations - whether IPv4 is the 'future' or not, it doesn't seem appropriate to consume the entirety of the remainder of the space for an existing use. Perhaps not all /4 should be reserved, but some - a /6 or /7 - should be left reserved. - I'll leave to IANA whether the argument therein is sufficient to allocate a /4 (minus a /6 or so); I don't think the case is made very well, FWIW. Joe --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enig6238696C93BBDC5D20383A02 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG7oMrE5f5cImnZrsRAj0RAJ9QwGCmRwP0Oeqb3lO6lV8rX4U1aACgx6k2 n5DKZpSE8faF5DNSWHV80h8= =XB9+ -----END PGP SIGNATURE----- --------------enig6238696C93BBDC5D20383A02-- --===============0285819664== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area --===============0285819664==-- From int-area-bounces@lists.ietf.org Wed Sep 19 12:57:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY2qh-0003oP-Kj; Wed, 19 Sep 2007 12:56:27 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IY2qg-0003kt-IY for int-area-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 12:56:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY2qg-0003fA-0e for int-area@ietf.org; Wed, 19 Sep 2007 12:56:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY2qf-0005zE-5v for int-area@ietf.org; Wed, 19 Sep 2007 12:56:25 -0400 X-IronPort-AV: E=Sophos;i="4.20,274,1186383600"; d="scan'208";a="221155828" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Sep 2007 09:56:24 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8JGuOoV017153; Wed, 19 Sep 2007 09:56:24 -0700 Received: from [128.107.130.83] (naiming-linux.cisco.com [128.107.130.83]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8JGuODr009266; Wed, 19 Sep 2007 16:56:24 GMT Message-ID: <46F154B8.6080506@cisco.com> Date: Wed, 19 Sep 2007 09:56:24 -0700 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Townsley Subject: Re: [Int-area] updated to draft-atlas-icmp-unnumbered-03 References: <6280db520707241021l25d940dka4a64a0561bf889b@mail.gmail.com> <6280db520707241451u54b8190du3e545af6dfb13361@mail.gmail.com> <46A78DA5.2090607@cisco.com> In-Reply-To: <46A78DA5.2090607@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4757; t=1190220984; x=1191084984; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20 |Subject:=20Re=3A=20[Int-area]=20updated=20to=20draft-atlas-icmp-unnumber ed-03 |Sender:=20; bh=tQGyurWx18RS0pC1iukBe2YxsTSarBXpBxucYgvjKd8=; b=X0sJknurL1LnAOlSt4EuXTzsEC3HiAIFbqlqvFYLKIrVMuN5hociXG7YABp4ACkEE/KYKliU naE0emSlCrspPU7Z0mmpNV1+bcEfdyjMdWCRZWju6b0C+0vSsSmc3ZRz; Authentication-Results: sj-dkim-2; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hi Mark, Mark Townsley said the following on 07/25/2007 10:51 AM: > > Please also give us feedback on whether or not this document should be > published, and on what track. I am considering the Standards Track, > shepherded directly by either me or Jari. I think it should be in the Standard Track. thansk. - Naiming > > - Mark > > Alia Atlas wrote: > >> I have updated the draft to reflect its goal of providing better >> identification of the receiving interface to aid in troubleshooting >> with traceroute. >> >> There are a few common scenarios that this draft is intended to help >> with. >> >> First, the receiving interface may be different than the outgoing >> interface (which gives the source IP address in the ICMP packet) >> because of either asymmetric link costs or ECMP. >> >> Second, the receiving interface may be unnumbered, so that the source >> IP address can't identify the interface. This is a problem for >> troubleshooting when there are parallel unnumbered links. >> >> I would welcome any comments or discussion on this draft. >> >> Thanks, >> Alia >> >> >> >> >> On 5/15/07, *Alia Atlas* > > wrote: >> >> On 5/14/07, *Pekka Savola* > > wrote: >> >> On Mon, 14 May 2007, Alia Atlas wrote: >> > In general, I find the specification having features that I >> don't see >> >> necessary. Reporting ifIndex is not necessary (and the >> index is not >> >> very useful as is to a human) if ifName is >> reported. Addresses are >> >> already known from the source address though somewhat less >> reliably so >> >> those need not be reported for outgoing interface use, and >> could also >> >> result in reporting IPv6 link-local addresses (or IPv4 >> private >> >> addresses) which wouldn't necessarily be useful or desired. >> > >> > The idea with reporting the ifIndex is to provide the easy >> ability >> > to correlate that to MIB data. It is a common look-up key >> and I >> > believe it to be useful. >> > >> > Using simply the source address doesn't handle topologies with >> > parallel links between routers. In that case, knowing the >> exact >> > outgoing link for troubleshooting is useful. ... >> >> (A potentially interesting note: at least one implementation >> has an >> internal 'interface index' which is different from 'SNMP >> ifIndex'. >> The intent should be clear in the spec.) >> >> >> Do you have improved phrasing you might suggest? >> >> If ifName is reported, is there significant benefit in reporting >> ifIndex as well? >> >> It could be more easily used for correlation, but that's only >> useful >> for the operators of the network who could know the ifIndexes >> on the >> routers, not outsiders. On the other hand, those network >> operators >> can very well map the ifName to ifIndex using SNMP or similar >> tools as >> well. >> >> >> True - I guess some of it depends whether the name or ifIndex is >> more private >> and how many steps an operator has to take to get decent results. >> On the other hand, normal traceroute gives both the IP address and >> the DNS >> name, if any. I was looking to provide the equivalent. >> >> I'm not strongly against being able to report ifIndex (but I'd >> rather >> that it doesn't get reported by default, at least to >> everyone), but it >> seems like a feature that's more likely to clutter the traceroute >> output with little added value: ifName should already provide >> the same >> benefits and is a more generic mechanism. >> >> >> All of the additional info is optional and an operator could >> determine what >> to show based upon the incoming IP address or such. >> >> Again, I was going for duplicating the information provided if an >> IP address existed. >> >> Alia >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Int-area mailing list >> Int-area@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/int-area >> > > > > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Wed Sep 19 15:28:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY5BR-00047z-SZ; Wed, 19 Sep 2007 15:26:01 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IY5BQ-00047r-WE for int-area-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 15:26:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY5BQ-00047h-K7 for int-area@ietf.org; Wed, 19 Sep 2007 15:26:00 -0400 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY5BP-0002jB-RO for int-area@ietf.org; Wed, 19 Sep 2007 15:26:00 -0400 X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l8JJPvb01334; Wed, 19 Sep 2007 15:25:57 -0400 (EDT) Received: from [10.82.224.29] (rtp-vpn1-29.cisco.com [10.82.224.29]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l8JJPw602084; Wed, 19 Sep 2007 15:25:58 -0400 (EDT) Message-ID: <46F177BB.2000701@cisco.com> Date: Wed, 19 Sep 2007 15:25:47 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Alia Atlas Subject: Re: [Int-area] updated to draft-atlas-icmp-unnumbered-03 References: <6280db520707241021l25d940dka4a64a0561bf889b@mail.gmail.com> <6280db520707241451u54b8190du3e545af6dfb13361@mail.gmail.com> <46A78DA5.2090607@cisco.com> <46A8D9F4.3070001@castlepoint.net> <6280db520707261112w38a36cd2x957ccf0868e78886@mail.gmail.com> In-Reply-To: <6280db520707261112w38a36cd2x957ccf0868e78886@mail.gmail.com> X-Enigmail-Version: 0.95.3 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org On 7/26/2007 2:12 PM, Alia Atlas said the following: > On 7/26/07, *Shane Amante* > wrote: > > Mark, > > Mark Townsley wrote: > > > > Please also give us feedback on whether or not this document should be > > published, and on what track. I am considering the Standards Track, > > shepherded directly by either me or Jari. > > I would support Standards Track. I also support publishing this document in Standards Track. > > In addition, Alia and I have been speaking about another use case for > this draft. In particular, I would like to see it extended to account > for identification of component-links inside ECMP and LAG's, which > should be a straightforward use case given what's already specified in > this draft. This use case has become prevalent over the last several > years and will become even more so in the future. > > > I believe that these cases can be handled by the router deciding which > ifIndex or IP address to include. For instance, a router might include the > ifIndex of the member interface of a LAG. I agree that the document is much more aligned with and structured around solving the problem of identifying the incoming interface of an undeliverable datagram, and that's a very useful troubleshooting tool. It also cleaned some of the issues previously identified. Please find a couple of comments: I think that the "Usage" section can use some finer/stricter definition; the report of the "numberedness" of the interface in question can also help (and is currently not directly covered). In the bitfield definition of the C-Type, one bit can be saved by merging together the IPv4 and IPv6 bits in a single field, since only one is meaningful for a given ICMP. It may also help to discuss what a NAT should do with extension fields containing addresses, if anything. Finally, regarding ECMPs and LAGs, I think that the router behavior should be deterministic in always including the same interface, (e.g., the LAG and not individual members), so that the receiving end can interpret it a given way. Thanks, --Carlos. > > Alia > > > -shane > > > > - Mark > > > > Alia Atlas wrote: > >> I have updated the draft to reflect its goal of providing better > >> identification of the receiving interface to aid in troubleshooting > >> with traceroute. > >> > >> There are a few common scenarios that this draft is intended to help > >> with. > >> > >> First, the receiving interface may be different than the outgoing > >> interface (which gives the source IP address in the ICMP packet) > >> because of either asymmetric link costs or ECMP. > >> > >> Second, the receiving interface may be unnumbered, so that the source > >> IP address can't identify the interface. This is a problem for > >> troubleshooting when there are parallel unnumbered links. > >> > >> I would welcome any comments or discussion on this draft. > >> > >> Thanks, > >> Alia > >> > >> > >> > >> > >> On 5/15/07, *Alia Atlas* < akatlas@gmail.com > > >> >> wrote: > >> > >> On 5/14/07, *Pekka Savola* < pekkas@netcore.fi > > >> >> wrote: > >> > >> On Mon, 14 May 2007, Alia Atlas wrote: > >> > In general, I find the specification having features > that I > >> don't see > >> >> necessary. Reporting ifIndex is not necessary (and the > >> index is not > >> >> very useful as is to a human) if ifName is > >> reported. Addresses are > >> >> already known from the source address though somewhat > less > >> reliably so > >> >> those need not be reported for outgoing interface > use, and > >> could also > >> >> result in reporting IPv6 link-local addresses (or IPv4 > >> private > >> >> addresses) which wouldn't necessarily be useful or > desired. > >> > > >> > The idea with reporting the ifIndex is to provide the easy > >> ability > >> > to correlate that to MIB data. It is a common look-up key > >> and I > >> > believe it to be useful. > >> > > >> > Using simply the source address doesn't handle > topologies with > >> > parallel links between routers. In that case, knowing the > >> exact > >> > outgoing link for troubleshooting is useful. ... > >> > >> (A potentially interesting note: at least one implementation > >> has an > >> internal 'interface index' which is different from 'SNMP > >> ifIndex'. > >> The intent should be clear in the spec.) > >> > >> > >> Do you have improved phrasing you might suggest? > >> > >> If ifName is reported, is there significant benefit in > reporting > >> ifIndex as well? > >> > >> It could be more easily used for correlation, but that's only > >> useful > >> for the operators of the network who could know the > ifIndexes > >> on the > >> routers, not outsiders. On the other hand, those network > >> operators > >> can very well map the ifName to ifIndex using SNMP or similar > >> tools as > >> well. > >> > >> > >> True - I guess some of it depends whether the name or ifIndex is > >> more private > >> and how many steps an operator has to take to get decent > results. > >> On the other hand, normal traceroute gives both the IP > address and > >> the DNS > >> name, if any. I was looking to provide the equivalent. > >> > >> I'm not strongly against being able to report ifIndex > (but I'd > >> rather > >> that it doesn't get reported by default, at least to > >> everyone), but it > >> seems like a feature that's more likely to clutter the > traceroute > >> output with little added value: ifName should already provide > >> the same > >> benefits and is a more generic mechanism. > >> > >> > >> All of the additional info is optional and an operator could > >> determine what > >> to show based upon the incoming IP address or such. > >> > >> Again, I was going for duplicating the information provided if an > >> IP address existed. > >> > >> Alia > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Int-area mailing list > >> Int-area@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/int-area > >> > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Wed Sep 19 23:29:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYCfB-0000bb-BM; Wed, 19 Sep 2007 23:25:13 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IYCfA-0000bT-E7 for int-area-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 23:25:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYCf9-0000aj-U6; Wed, 19 Sep 2007 23:25:12 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYCf9-0007PX-4G; Wed, 19 Sep 2007 23:25:11 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JON00DV1DGSBB@szxga02-in.huawei.com>; Thu, 20 Sep 2007 11:24:28 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JON003A7DGSDG@szxga02-in.huawei.com>; Thu, 20 Sep 2007 11:24:28 +0800 (CST) Received: from J66104 ([10.111.12.51]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JON00GREDGHWO@szxml04-in.huawei.com>; Thu, 20 Sep 2007 11:24:28 +0800 (CST) Date: Thu, 20 Sep 2007 11:24:13 +0800 From: Sheng Jiang To: cga-ext-request@ietf.org Message-id: <003401c7fb35$bad83b00$330c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf7NbeolzHkCf0ZQlihsEee1LcTsQ== X-Spam-Score: 0.7 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Int Area Subject: [Int-area] no more work to do for DHCP with CGAs? X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Dear all, I am recently going over the charter of SEND and CGA Extensions BOF. It lists an item for DHCP support for CGAs. It recalls me there was a discussion that DHCP IA option could be used to meet the network management purpose. DHCP IA option can be used to assign the CGA that is proposed by the host. It concluded that there is no more work to do for DHCP with CGAs. However, in my opinion, DHCP could do more to support CGAs. See http://www.ietf.org/internet-drafts/draft-jiang-sendcgaext-cga-config-00.txt There are at least two more things DHCP can do for CGAs: a, to propagate the configuration information that CGA needed, such as the public key of proxy; b, to delegate the large computational burden of generating CGAs with high sec value. There are still a lot works to do to make the above requirement feasible. Best regards, Dr. Sheng JIANG IP Research Department, Networking Research Department, Network Product Line, Huawei Technologies Co. Ltd. _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Sep 20 11:40:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYO7C-00062c-51; Thu, 20 Sep 2007 11:38:54 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IYO7A-00062M-Aj for int-area-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 11:38:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYO7A-00062E-0u for int-area@ietf.org; Thu, 20 Sep 2007 11:38:52 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYO73-0000Cl-NV for int-area@ietf.org; Thu, 20 Sep 2007 11:38:51 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l8KFcUQH028837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Sep 2007 10:38:30 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l8KFcToH024570 for ; Thu, 20 Sep 2007 10:38:29 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l8KFcInv024077 for ; Thu, 20 Sep 2007 10:38:29 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 08:38:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7FB9C.4A277A5A" Date: Thu, 20 Sep 2007 08:38:28 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDA84@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <003401c7fb35$bad83b00$330c6f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tunnel MTU Thread-Index: Acf7NbeolzHkCf0ZQlihsEee1LcTsQAZbwGQ References: <003401c7fb35$bad83b00$330c6f0a@china.huawei.com> From: "Templin, Fred L" To: "Int Area" X-OriginalArrivalTime: 20 Sep 2007 15:38:28.0176 (UTC) FILETIME=[4A344D00:01C7FB9C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: Subject: [Int-area] Tunnel MTU X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FB9C.4A277A5A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see attached for a proposal that addresses the MTU issues for *-in-IPv4 tunnels. It also addresses the multi-mtu subnet issue, since it does not rely on ICMP "packet too big" messages from the last-hop router. Elements of the proposal include: - trailing "footer" and data as part of encapsulation - tiny echo requests wrapped in encapsulation headers and trailing padding - used as probes to elicit tiny echo replies - tunnel endpoint discovers tunnel far end EMTU_R and reassemby timeout values in initial probes=20 - periodic probing to discover the tunnel path MTU, plus EMTU_R; reassembly timeout fluctuations - inner fragmentation to create inner packets no larger than EMTU_R - outer fragmentation to create outer packets no larger than the tunnel path MTU - coservative use of fragmentation to avoid packet loss within the tunnel - TE drops unfragmentable packets larger than EMTU_R and sends ICMP PTB w/o wasting tunnel resources - protection against fragment misassociations - protection against off-path attacks - protection against wrapped ip_id - backwards compatibility - incremental deployment - NAT traversal Please review and send comments.=20 Thanks - Fred fred.l.templin@boeing.com ------_=_NextPart_001_01C7FB9C.4A277A5A Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from XCH-NWBH-10.nw.nos.boeing.com ([130.247.55.83]) by XCH-NW-7V2.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 12:39:03 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C7FA2B.91342580" Received: from slb-smtpin-02.ns.cs.boeing.com ([129.172.13.17]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 12:39:00 -0700 Received: from slb-smtpin-02.ns.cs.boeing.com (localhost [127.0.0.1]) by slb-smtpin-02.ns.cs.boeing.com (8.14.0/8.14.0/DOWNSTREAM_SMTPIN) with ESMTP id l8IJd0E6019388; Tue, 18 Sep 2007 12:39:00 -0700 (PDT) Received: from megatron.ietf.org ([156.154.16.145])by slb-smtpin-02.ns.cs.boeing.com (8.14.0/8.14.0/UPSTREAM_SMTPIN) with ESMTP id l8IJcxC9019373(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 12:38:59 -0700 (PDT) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)by megatron.ietf.org with esmtp (Exim 4.43)id 1IXiXw-0007qt-Lp; Tue, 18 Sep 2007 15:15:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)by megatron.ietf.org with esmtp (Exim 4.43) id 1IXiXv-0007qg-3Pfor i-d-announce@ietf.org; Tue, 18 Sep 2007 15:15:43 -0400 Received: from ns3.neustar.com ([156.154.24.138])by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXiXu-00049U-NPfor i-d-announce@ietf.org; Tue, 18 Sep 2007 15:15:43 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 6AFC5175A7for ; Tue, 18 Sep 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)id 1IXiXF-0002mA-Uzfor i-d-announce@ietf.org; Tue, 18 Sep 2007 15:15:01 -0400 Content-class: urn:content-classes:message Subject: I-D ACTION:draft-templin-inetmtu-00.txt Date: Tue, 18 Sep 2007 12:15:01 -0700 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-templin-inetmtu-00.txt Thread-Index: Acf6K5Gd1qGs0kXuRxiaOReNzlQ7WQ== List-Help: List-Subscribe: , List-Unsubscribe: , From: To: Reply-To: This is a multi-part message in MIME format. ------_=_NextPart_002_01C7FA2B.91342580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Packetization Layer Path MTU Discovery for=20 IP/*/IPv4 Tunnels Author(s) : F. Templin Filename : draft-templin-inetmtu-00.txt Pages : 20 Date : 2007-9-18 =09 The nominal Maximum Transmission Unit (MTU) MTU of the Internet has become 1500 bytes, but existing IP/*/IPv4 tunneling mechanisms impose an encapsulation overhead that can reduce the effective path MTU to smaller values. Additionally, existing IP/*/IPv4 tunneling mechanisms are limited in their ability to discover and utilize larger MTUs. This document specifies new mechanisms for conveying packets over IP/*/IPv4 tunnels that address these issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-templin-inetmtu-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-templin-inetmtu-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-templin-inetmtu-00.txt". =09 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_002_01C7FA2B.91342580 Content-Type: application/octet-stream; name="ATT8176442.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT8176442.TXT Content-Disposition: attachment; filename="ATT8176442.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy05LTE4MTQzNDEwLkktREBpZXRmLm9yZz4NCg0KRU5D T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRlbXBsaW4taW5ldG10dS0w MC50eHQNCg== ------_=_NextPart_002_01C7FA2B.91342580 Content-Type: application/octet-stream; name="draft-templin-inetmtu-00.TXT" Content-Transfer-Encoding: base64 Content-Description: draft-templin-inetmtu-00.TXT Content-Disposition: attachment; filename="draft-templin-inetmtu-00.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IG5hbWU9ImRyYWZ0LXRlbXBsaW4t aW5ldG10dS0wMC50eHQiOw0KCXNpdGU9ImZ0cC5pZXRmLm9yZyI7IGFjY2Vzcy10eXBlPSJhbm9u LWZ0cCI7DQoJZGlyZWN0b3J5PSJpbnRlcm5ldC1kcmFmdHMiDQoNCkNvbnRlbnQtVHlwZTogdGV4 dC9wbGFpbg0KQ29udGVudC1JRDogPDIwMDctOS0xODE0MzQxMC5JLURAaWV0Zi5vcmc+DQoNCg== ------_=_NextPart_002_01C7FA2B.91342580 Content-Type: text/plain; name="ATT8176443.txt" Content-Transfer-Encoding: base64 Content-Description: ATT8176443.txt Content-Disposition: attachment; filename="ATT8176443.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_002_01C7FA2B.91342580-- ------_=_NextPart_001_01C7FB9C.4A277A5A Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area ------_=_NextPart_001_01C7FB9C.4A277A5A-- From int-area-bounces@lists.ietf.org Fri Sep 21 07:13:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYgQA-0006vG-DF; Fri, 21 Sep 2007 07:11:42 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IYgQ9-0006vA-Df for int-area-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 07:11:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYgQ8-0006Yg-CX for int-area@ietf.org; Fri, 21 Sep 2007 07:11:40 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYgPz-0007hA-Cv for int-area@ietf.org; Fri, 21 Sep 2007 07:11:31 -0400 Received: (qmail invoked by alias); 21 Sep 2007 11:11:30 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp023) with SMTP; 21 Sep 2007 13:11:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xzDx2qR0xPCVKE1Ge0kTaf61Bl3vkc1nP87l08T sAsYZNLvOdCPoO Message-ID: <46F3A6E1.10803@gmx.net> Date: Fri, 21 Sep 2007 13:11:29 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig References: <46EA4B08.1060307@gmx.net> In-Reply-To: <46EA4B08.1060307@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: int-area@ietf.org Subject: [Int-area] Re: Discovering a Location Server in the Access Network X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hi all, I haven't received concerns regarding the suggested discovery approach. May I assume from the lack of feedback that the suggested approach is reasonable? Ciao Hannes Hannes Tschofenig wrote: > Hi all, > > I would need some feedback regarding work that is currently being done > in the GEOPRIV working group. > For some time we have been working on an application layer protocol > that allows the end host to obtain its own location information (or a > reference to it) from a server (called LIS) in the access network. > This LIS indeed needs to be located in the access network (and not at > an arbitrary place on the Internet) since only the layer 2/layer 3 > provider is able to determine the precise location of end point. > > A year ago I lead a design team that captured the problem statement > and requirements. The document is available here: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt > > The protocol that provides the functionality of the above-mentioned > requirements document is HELD: > http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery > > Providing the end host with the address of the LIS is relatively easy > if you can use DHCP. However, there are deployment environments (such > as DSL networks) where the DSL operator cannot control the DSL home > routers and any information that is provided by the DSL operator may > not be relayed to the end host via this box. > > So, to overcome this issue the group had an idea: Let's use a > different discovery technique that does not require upgrades to > intermediate devices (such as this DSL home router). > > In short, the current proposal (see > http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; > ignoring Section 2 which defines the DHCP portion) essentially does > the following: > > * Discover the public IP address of the end point > * Perform a reverse DNS lookup to learn the domain > * Lookup the LIS for that domain > * Contact the LIS > > We have investigated other solutions as well (see Section 4 of > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt) > but the group (or at least a few folks) believes that this is a "good" > approach. > > I had a chat with Jari and we both agree that this topoic falls into > the expertise of the Internet Area. Hence, I would like to solicit > feedback from you. > > Ciao > Hannes > > _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Sep 21 12:25:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYlIT-0003qH-Up; Fri, 21 Sep 2007 12:24:05 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IYlIS-0003nn-9q for int-area-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 12:24:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYlIR-0003my-TX for int-area@ietf.org; Fri, 21 Sep 2007 12:24:03 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYlIR-0000cu-91 for int-area@ietf.org; Fri, 21 Sep 2007 12:24:03 -0400 Received: from [127.0.0.1] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8LGNk1b004689; Fri, 21 Sep 2007 09:23:47 -0700 (PDT) Message-ID: <46F3EFFD.9080109@isi.edu> Date: Fri, 21 Sep 2007 09:23:25 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Int-area] Re: Discovering a Location Server in the Access Network References: <46EA4B08.1060307@gmx.net> <46F3A6E1.10803@gmx.net> In-Reply-To: <46F3A6E1.10803@gmx.net> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0210742347==" Errors-To: int-area-bounces@lists.ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0210742347== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1285942273028368AE69476C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1285942273028368AE69476C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: > Hi all, >=20 > I haven't received concerns regarding the suggested discovery approach.= > May I assume from the lack of feedback that the suggested approach is > reasonable? I have seen this sort of conclusion claimed before, and it is incorrect. Silence is not a hum in favor. I don't have a position on this per se, but if nobody can step forward and claim this is a reasonable solution, all we have is 'lack of feedback', not 'consensus'. Joe =2E.. >> In short, the current proposal (see >> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt;= >> ignoring Section 2 which defines the DHCP portion) essentially does >> the following: >> >> * Discover the public IP address of the end point >> * Perform a reverse DNS lookup to learn the domain >> * Lookup the LIS for that domain >> * Contact the LIS --------------enig1285942273028368AE69476C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8+/9E5f5cImnZrsRAsuIAJ9mYwLg1PFvkWRhEliW24G8P+2wqQCdEc4f OGyPwuCe3ik4Rir7q9bXkGA= =2WVl -----END PGP SIGNATURE----- --------------enig1285942273028368AE69476C-- --===============0210742347== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area --===============0210742347==-- From int-area-bounces@lists.ietf.org Fri Sep 21 13:54:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYmi1-0006f9-F0; Fri, 21 Sep 2007 13:54:33 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IYmhz-0006aa-Ib for int-area-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 13:54:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYmhx-0006Vz-OG for int-area@ietf.org; Fri, 21 Sep 2007 13:54:31 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYmhx-0004kS-1A for int-area@ietf.org; Fri, 21 Sep 2007 13:54:29 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1190397267!6576987!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 2851 invoked from network); 21 Sep 2007 17:54:27 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-15.tower-153.messagelabs.com with SMTP; 21 Sep 2007 17:54:27 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8LHsRlq003347; Fri, 21 Sep 2007 10:54:27 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l8LHsQGk010453; Fri, 21 Sep 2007 12:54:26 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-127.corp.mot.com [10.169.4.127]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8LHsG4n010372; Fri, 21 Sep 2007 12:54:19 -0500 (CDT) Message-ID: <46F40546.3010005@gmail.com> Date: Fri, 21 Sep 2007 19:54:14 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch Subject: Re: [Int-area] Re: Discovering a Location Server in the Access Network References: <46EA4B08.1060307@gmx.net> <46F3A6E1.10803@gmx.net> <46F3EFFD.9080109@isi.edu> In-Reply-To: <46F3EFFD.9080109@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-4, 20/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Joe Touch wrote: > > Hannes Tschofenig wrote: >> Hi all, >> >> I haven't received concerns regarding the suggested discovery >> approach. May I assume from the lack of feedback that the suggested >> approach is reasonable? > > I have seen this sort of conclusion claimed before, and it is > incorrect. > > Silence is not a hum in favor. > > I don't have a position on this per se, but if nobody can step > forward and claim this is a reasonable solution, all we have is 'lack > of feedback', not 'consensus'. I think I can agree. I'm interested in all discovery mechanisms existing out there, and then making some new... But at some point one can easily wonder whether there aren't too many of them those discovery mechanisms, and maybe some more reuse can be possible. So can I turn your (Hannes) question: how much does your new discovery protocol reuse? Of what? Please don't argument that that and that group believes the requirements eliminate all existing discovery mechanisms, because I'm speechless in front of these requirements because I haven't followed them, sorry :-) Then of course another question to you (Hannes) is whether we have any IPR issues around this new method of discovery, any entanglement. If there's IPR, on which side would one prefer to err, and so. But without at least these little things one can say little, and even less call it 'consensus', In My Humble Oppinion. Alex > > Joe > > ... >>> In short, the current proposal (see >>> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; >>> ignoring Section 2 which defines the DHCP portion) essentially >>> does the following: >>> >>> * Discover the public IP address of the end point * Perform a >>> reverse DNS lookup to learn the domain * Lookup the LIS for that >>> domain * Contact the LIS > > > ------------------------------------------------------------------------ > > > > _______________________________________________ Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Sep 21 14:11:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYmxe-0004TK-0q; Fri, 21 Sep 2007 14:10:42 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IYmxb-0004PY-RT for int-area-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 14:10:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYmxb-0004J9-Hj for int-area@ietf.org; Fri, 21 Sep 2007 14:10:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYmxR-0001Wd-6l for int-area@ietf.org; Fri, 21 Sep 2007 14:10:35 -0400 Received: (qmail invoked by alias); 21 Sep 2007 18:10:10 -0000 Received: from p5498485F.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.72.95] by mail.gmx.net (mp019) with SMTP; 21 Sep 2007 20:10:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18liiojSf4lbglNNwzLJy/N9zbJxT4RurU4yOcuTz +w8tnn0C15yUB6 Message-ID: <46F40902.2040405@gmx.net> Date: Fri, 21 Sep 2007 20:10:10 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch Subject: Re: [Int-area] Re: Discovering a Location Server in the Access Network References: <46EA4B08.1060307@gmx.net> <46F3A6E1.10803@gmx.net> <46F3EFFD.9080109@isi.edu> In-Reply-To: <46F3EFFD.9080109@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org My mail was a new (and different) attempt to receive some feedback. So far, didn't work. Just bad luck. Ciao Hannes Joe Touch wrote: > Hannes Tschofenig wrote: > >> Hi all, >> >> I haven't received concerns regarding the suggested discovery approach. >> May I assume from the lack of feedback that the suggested approach is >> reasonable? >> > > I have seen this sort of conclusion claimed before, and it is incorrect. > > Silence is not a hum in favor. > > I don't have a position on this per se, but if nobody can step forward > and claim this is a reasonable solution, all we have is 'lack of > feedback', not 'consensus'. > > Joe > > ... > >>> In short, the current proposal (see >>> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; >>> ignoring Section 2 which defines the DHCP portion) essentially does >>> the following: >>> >>> * Discover the public IP address of the end point >>> * Perform a reverse DNS lookup to learn the domain >>> * Lookup the LIS for that domain >>> * Contact the LIS >>> > > _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Sep 21 14:19:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYn5W-0005jr-4v; Fri, 21 Sep 2007 14:18:50 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IYn5V-0005jl-69 for int-area-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 14:18:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYn5U-0005jW-OF for int-area@ietf.org; Fri, 21 Sep 2007 14:18:48 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYn5U-0005RC-1z for int-area@ietf.org; Fri, 21 Sep 2007 14:18:48 -0400 Received: from [127.0.0.1] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8LIIYGs002051; Fri, 21 Sep 2007 11:18:34 -0700 (PDT) Message-ID: <46F40AE4.9010702@isi.edu> Date: Fri, 21 Sep 2007 11:18:12 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Int-area] Re: Discovering a Location Server in the Access Network References: <46EA4B08.1060307@gmx.net> <46F3A6E1.10803@gmx.net> <46F3EFFD.9080109@isi.edu> <46F40902.2040405@gmx.net> In-Reply-To: <46F40902.2040405@gmx.net> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1580497539==" Errors-To: int-area-bounces@lists.ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1580497539== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF579DFC7F72317C164044028" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF579DFC7F72317C164044028 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Hannes, I appreciate the idea of a 'ping' to the group. I also appreciate that everyone has their area of focus, and not all things brought to a WG receive the attention that's needed to move them forward. IETFers have discussed incentive systems to encourage people to read things that 'need to be reviewed', but let's not discuss that here. Until we have that or an alternative - in the absence of positive feedback - items should not move forward in a WG based on silence as implicit approval. If there is an absence of positive community support - either explicit, or implicit by the community's lack of interest and silence - IMO, the best path forward is to *revert* an item to individual submission, even if it's on the WG charter. Joe Hannes Tschofenig wrote: > My mail was a new (and different) attempt to receive some feedback. > So far, didn't work. Just bad luck. >=20 > Ciao > Hannes >=20 > Joe Touch wrote: >> Hannes Tschofenig wrote: >> =20 >>> Hi all, >>> >>> I haven't received concerns regarding the suggested discovery approac= h. >>> May I assume from the lack of feedback that the suggested approach is= >>> reasonable? >>> =20 >> >> I have seen this sort of conclusion claimed before, and it is incorrec= t. >> >> Silence is not a hum in favor. >> >> I don't have a position on this per se, but if nobody can step forward= >> and claim this is a reasonable solution, all we have is 'lack of >> feedback', not 'consensus'. >> >> Joe >> >> ... >> =20 >>>> In short, the current proposal (see >>>> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.tx= t; >>>> ignoring Section 2 which defines the DHCP portion) essentially does >>>> the following: >>>> >>>> * Discover the public IP address of the end point >>>> * Perform a reverse DNS lookup to learn the domain >>>> * Lookup the LIS for that domain >>>> * Contact the LIS >>>> =20 >> >> =20 --=20 ---------------------------------------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment Postel Center Director & Research Assoc. Prof., USC/ISI --------------enigF579DFC7F72317C164044028 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG9ArlE5f5cImnZrsRAnNfAKCUVFv7+IEj002Ji/ay5zpICtK0vwCdHgrW TQBW2xQrcRpAZ8TG33yJZI4= =iSf+ -----END PGP SIGNATURE----- --------------enigF579DFC7F72317C164044028-- --===============1580497539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area --===============1580497539==-- From int-area-bounces@lists.ietf.org Fri Sep 21 14:22:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYn8g-0001rZ-8X; Fri, 21 Sep 2007 14:22:06 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IYn8e-0001nl-P9 for int-area-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 14:22:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYn8e-0001lD-0P for int-area@ietf.org; Fri, 21 Sep 2007 14:22:04 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYn8d-0005Wq-4o for int-area@ietf.org; Fri, 21 Sep 2007 14:22:03 -0400 Received: (qmail invoked by alias); 21 Sep 2007 18:22:01 -0000 Received: from p5498485F.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.72.95] by mail.gmx.net (mp046) with SMTP; 21 Sep 2007 20:22:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19d92B//BhdSzXVw0LpLNvLquwFUukekhPXkc5Yi3 5vMdJWocgQBFG1 Message-ID: <46F40BC9.6050009@gmx.net> Date: Fri, 21 Sep 2007 20:22:01 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Int-area] Re: Discovering a Location Server in the Access Network References: <46EA4B08.1060307@gmx.net> <46F3A6E1.10803@gmx.net> <46F3EFFD.9080109@isi.edu> <46F40546.3010005@gmail.com> In-Reply-To: <46F40546.3010005@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: int-area@ietf.org, Joe Touch X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hi Alex, Alexandru Petrescu wrote: > Joe Touch wrote: >> >> Hannes Tschofenig wrote: >>> Hi all, >>> >>> I haven't received concerns regarding the suggested discovery >>> approach. May I assume from the lack of feedback that the suggested >>> approach is reasonable? >> >> I have seen this sort of conclusion claimed before, and it is incorrect. >> >> Silence is not a hum in favor. >> >> I don't have a position on this per se, but if nobody can step >> forward and claim this is a reasonable solution, all we have is 'lack >> of feedback', not 'consensus'. > > I think I can agree. > > I'm interested in all discovery mechanisms existing out there, and then > making some new... But at some point one can easily wonder whether > there aren't too many of them those discovery mechanisms, and maybe some > more reuse can be possible. If we can re-use something existing then that's great for me as well. The usage of DNS based discovery is not extremely new either. The special case here is just to consideration of the fact that there are NATs out there. > > So can I turn your (Hannes) question: how much does your new discovery > protocol reuse? Actually, it is not MY discovery mechanism. I am just a long-time participant of the GEOPRIV working group and would like to see some progress. In this particular case cross-area review seemed to be an appropriate way to receive feedback "early" in the process. > Of what? Please don't argument that that and that > group believes the requirements eliminate all existing discovery > mechanisms, because I'm speechless in front of these requirements > because I haven't followed them, sorry :-) That's a basic problem if one working group is working on a subject and another group or community is providing input to selected parts. I have some (bad) experience with these type of interactions and so far I learned that soliciting feedback later than earlier is causing more problems in the end. For some recurring problems (such as XML issues) there are separate review groups that provide feedback in a timely fashion. This case is a bit too special and there is no such group available. > > Then of course another question to you (Hannes) is whether we have any > IPR issues around this new method of discovery, any entanglement. If > there's IPR, on which side would one prefer to err, and so. There were no IPRs disclosures posted to the respective GEOPRIV documents. Since I am not the author of the specs I don't really know. > > But without at least these little things one can say little, and even > less call it 'consensus', In My Humble Oppinion. > Ciao Hannes > Alex > >> >> Joe >> >> ... >>>> In short, the current proposal (see >>>> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; >>>> ignoring Section 2 which defines the DHCP portion) essentially >>>> does the following: >>>> >>>> * Discover the public IP address of the end point * Perform a >>>> reverse DNS lookup to learn the domain * Lookup the LIS for that >>>> domain * Contact the LIS >> >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ Int-area mailing list >> Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Fri Sep 21 14:29:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYnFK-0002du-G2; Fri, 21 Sep 2007 14:28:58 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IYnFI-0002dB-7q for int-area-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 14:28:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYnFH-0002Wh-UT for int-area@ietf.org; Fri, 21 Sep 2007 14:28:55 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYnFA-00020I-In for int-area@ietf.org; Fri, 21 Sep 2007 14:28:49 -0400 Received: (qmail invoked by alias); 21 Sep 2007 18:28:37 -0000 Received: from p5498485F.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.72.95] by mail.gmx.net (mp056) with SMTP; 21 Sep 2007 20:28:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/dEX9r+ADdDRDfbfvemwA/IOTmDYmvXXAGtSrULP 0+UsFDpqpCZFE7 Message-ID: <46F40D55.9050209@gmx.net> Date: Fri, 21 Sep 2007 20:28:37 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch Subject: Re: [Int-area] Re: Discovering a Location Server in the Access Network References: <46EA4B08.1060307@gmx.net> <46F3A6E1.10803@gmx.net> <46F3EFFD.9080109@isi.edu> <46F40902.2040405@gmx.net> <46F40AE4.9010702@isi.edu> In-Reply-To: <46F40AE4.9010702@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hi Joe, Joe Touch wrote: > Hi, Hannes, > > I appreciate the idea of a 'ping' to the group. I also appreciate that > everyone has their area of focus, and not all things brought to a WG > receive the attention that's needed to move them forward. > > Agree. > IETFers have discussed incentive systems to encourage people to read > things that 'need to be reviewed', but let's not discuss that here. > > Certainly a complicated subject. > Until we have that or an alternative - in the absence of positive > feedback - items should not move forward in a WG based on silence as > implicit approval. > So far this issue is non-blocking. I just fear that this issue will surface again during IETF Last Call. > If there is an absence of positive community support - either explicit, > or implicit by the community's lack of interest and silence - IMO, the > best path forward is to *revert* an item to individual submission, even > if it's on the WG charter. > There is another discovery mechanism, namely based on DHCP, that is pretty uncontroversial. I believe that it will progress quite smoothly in the group. Hence, the HELD specification itself would not be blocked since there is this other discovery mechanism. I do, however, believe that it is important to consider real world constraints that might slow down the deployment of certain mechanisms. If there is a way todo something about them then (in my believe) we should be looking at them. Ciao Hannes > Joe > > Hannes Tschofenig wrote: > >> My mail was a new (and different) attempt to receive some feedback. >> So far, didn't work. Just bad luck. >> >> Ciao >> Hannes >> >> Joe Touch wrote: >> >>> Hannes Tschofenig wrote: >>> >>> >>>> Hi all, >>>> >>>> I haven't received concerns regarding the suggested discovery approach. >>>> May I assume from the lack of feedback that the suggested approach is >>>> reasonable? >>>> >>>> >>> I have seen this sort of conclusion claimed before, and it is incorrect. >>> >>> Silence is not a hum in favor. >>> >>> I don't have a position on this per se, but if nobody can step forward >>> and claim this is a reasonable solution, all we have is 'lack of >>> feedback', not 'consensus'. >>> >>> Joe >>> >>> ... >>> >>> >>>>> In short, the current proposal (see >>>>> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; >>>>> ignoring Section 2 which defines the DHCP portion) essentially does >>>>> the following: >>>>> >>>>> * Discover the public IP address of the end point >>>>> * Perform a reverse DNS lookup to learn the domain >>>>> * Lookup the LIS for that domain >>>>> * Contact the LIS >>>>> >>>>> >>> >>> > > _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sat Sep 22 00:57:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYx0W-0006W4-Dm; Sat, 22 Sep 2007 00:54:20 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IYx0V-0006Vx-41 for int-area-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 00:54:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYx0U-0006U2-QO for int-area@ietf.org; Sat, 22 Sep 2007 00:54:18 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYx0O-0001rw-Ec for int-area@ietf.org; Sat, 22 Sep 2007 00:54:13 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l8M4rpKA021653; Sat, 22 Sep 2007 07:53:52 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l8M4rp9b021650; Sat, 22 Sep 2007 07:53:51 +0300 Date: Sat, 22 Sep 2007 07:53:51 +0300 (EEST) From: Pekka Savola To: Hannes Tschofenig Subject: Re: [Int-area] Discovering a Location Server in the Access Network In-Reply-To: <46EA4B08.1060307@gmx.net> Message-ID: References: <46EA4B08.1060307@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4357/Fri Sep 21 12:55:46 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: -1.4 (-) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org On Fri, 14 Sep 2007, Hannes Tschofenig wrote: > In short, the current proposal (see > http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; > ignoring Section 2 which defines the DHCP portion) essentially does the > following: > > * Discover the public IP address of the end point > * Perform a reverse DNS lookup to learn the domain > * Lookup the LIS for that domain > * Contact the LIS 2-3 years ago we had the similar problem with IPv6-in-IPv4 tunnel endpoint discovery, only that the endpoint could reside outside the L2/L3 network as well. The approaches identified then were described at: http://tools.ietf.org/html/draft-palet-v6ops-tun-auto-disc-03 Personally, I thought anycast made most sense. Some other folks preferred reverse DNS population (e.g. [1]), but that also has problems with private address use of a more recent approach to try to push the NAT boxes to act as authoritative for private address spaces [2] in which case the ISP could not populate its DNS resolvers for private addresses either. In your case where the L2/L3 provider is required to provide this information in order for the methodology could work, though personally I'm somewhat concerned about 1) how reliable the public IP address discovery could be, 2) what happens if the ISP doesn't provide reverse DNS entry for the public IP, and 3) whether the operator who's providing L3 service and public IP does in fact even know where the user is located (if the user's ADSL session is provided by a L2 provider and just tunneled - in bulk - using L2TP to L3 provider). The last issue is probably the biggest and you may need to consider in more detail how such "L2 different from L3" network would work. Realistically any solution I could think of that doesn't involve DHCP or PPP is likely to require coordination in this case. Would it required that the local regular requires L3 provider to also keep track of the physical location? [1] http://tools.ietf.org/html/draft-yamamoto-naptr-service-discovery-01 [2] http://tools.ietf.org/html/draft-ietf-dnsop-default-local-zones-02 -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sat Sep 22 08:56:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4UD-0005B2-D7; Sat, 22 Sep 2007 08:53:29 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IYPtJ-00045q-ER for int-area-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 13:32:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPtJ-00045i-4m for int-area@ietf.org; Thu, 20 Sep 2007 13:32:41 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYPtH-0004Mb-Lm for int-area@ietf.org; Thu, 20 Sep 2007 13:32:41 -0400 X-IronPort-AV: E=Sophos;i="4.20,279,1186383600"; d="scan'208";a="526253984" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2007 10:32:39 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8KHWdJM009202 for ; Thu, 20 Sep 2007 10:32:39 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8KHWcDr004756 for ; Thu, 20 Sep 2007 17:32:38 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 13:32:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Int-area] updated to draft-atlas-icmp-unnumbered-03] Date: Thu, 20 Sep 2007 13:32:16 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B6041890A4@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <46F168CF.6040305@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] updated to draft-atlas-icmp-unnumbered-03] Thread-Index: Acf66f1/pC2OOIMbTsq2MZgcItBc+AAwXUcw From: "Rajiv Asati \(rajiva\)" To: X-OriginalArrivalTime: 20 Sep 2007 17:32:37.0867 (UTC) FILETIME=[3CF033B0:01C7FBAC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5730; t=1190309559; x=1191173559; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20\(rajiva\)=22=20 |Subject:=20Re=3A=20[Int-area]=20updated=20to=20draft-atlas-icmp-unnumber ed-03] |Sender:=20; bh=9la1j/L640H1npplerOtERtZ3pqNPVVidP9dZPoSYmw=; b=icKto2iCiKjonRl+/9IHsvjnmLtkOx13pdGPVI7+Lxz74C3iTqSeKfEpfIX6LE4vG50De9aA E1oIdn2JWKMbmCQOS3ZxF32IRt5/5X4il6CY86JfXDsjIgYY2HiwnxGu; Authentication-Results: sj-dkim-4; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c X-Mailman-Approved-At: Sat, 22 Sep 2007 08:53:27 -0400 Cc: X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org =20 This document should be in the standards track. Cheers, Rajiv > -------- Original Message -------- > Subject: Re: [Int-area] updated to draft-atlas-icmp-unnumbered-03 > Date: Wed, 19 Sep 2007 09:56:24 -0700 > From: Naiming Shen > To: Mark Townsley > CC: int-area@ietf.org >=20 >=20 > Hi Mark, >=20 > Mark Townsley said the following on 07/25/2007 10:51 AM: > >=20 > > Please also give us feedback on whether or not this=20 > document should be=20 > > published, and on what track. I am considering the Standards Track,=20 > > shepherded directly by either me or Jari. >=20 > I think it should be in the Standard Track. >=20 > thansk. > - Naiming >=20 > >=20 > > - Mark > >=20 > > Alia Atlas wrote: > >=20 > >> I have updated the draft to reflect its goal of providing better > >> identification of the receiving interface to aid in troubleshooting > >> with traceroute. > >> > >> There are a few common scenarios that this draft is=20 > intended to help > >> with. > >> > >> First, the receiving interface may be different than the outgoing > >> interface (which gives the source IP address in the ICMP packet) > >> because of either asymmetric link costs or ECMP. > >> > >> Second, the receiving interface may be unnumbered, so that=20 > the source > >> IP address can't identify the interface. This is a problem for > >> troubleshooting when there are parallel unnumbered links. > >> > >> I would welcome any comments or discussion on this draft. > >> > >> Thanks, > >> Alia > >> > >> > >> > >> > >> On 5/15/07, *Alia Atlas* >> > wrote: > >> > >> On 5/14/07, *Pekka Savola* >> > wrote: > >> > >> On Mon, 14 May 2007, Alia Atlas wrote: > >> > In general, I find the specification having=20 > features that I > >> don't see > >> >> necessary. Reporting ifIndex is not necessary (and the > >> index is not > >> >> very useful as is to a human) if ifName is > >> reported. Addresses are > >> >> already known from the source address though=20 > somewhat less > >> reliably so > >> >> those need not be reported for outgoing=20 > interface use, and > >> could also > >> >> result in reporting IPv6 link-local addresses (or IPv4=20 > >> private > >> >> addresses) which wouldn't necessarily be=20 > useful or desired. > >> > > >> > The idea with reporting the ifIndex is to=20 > provide the easy > >> ability > >> > to correlate that to MIB data. It is a common=20 > look-up key=20 > >> and I > >> > believe it to be useful. > >> > > >> > Using simply the source address doesn't handle=20 > topologies with > >> > parallel links between routers. In that case,=20 > knowing the=20 > >> exact > >> > outgoing link for troubleshooting is useful. ... > >> > >> (A potentially interesting note: at least one=20 > implementation > >> has an > >> internal 'interface index' which is different from 'SNMP=20 > >> ifIndex'. > >> The intent should be clear in the spec.) > >> > >> > >> Do you have improved phrasing you might suggest? > >> > >> If ifName is reported, is there significant=20 > benefit in reporting > >> ifIndex as well? > >> > >> It could be more easily used for correlation, but=20 > that's only > >> useful > >> for the operators of the network who could know=20 > the ifIndexes > >> on the > >> routers, not outsiders. On the other hand, those network > >> operators > >> can very well map the ifName to ifIndex using SNMP=20 > or similar > >> tools as > >> well. > >> > >> > >> True - I guess some of it depends whether the name or=20 > ifIndex is > >> more private > >> and how many steps an operator has to take to get=20 > decent results. > >> On the other hand, normal traceroute gives both the IP=20 > address and > >> the DNS > >> name, if any. I was looking to provide the equivalent. > >> > >> I'm not strongly against being able to report=20 > ifIndex (but I'd > >> rather > >> that it doesn't get reported by default, at least to > >> everyone), but it > >> seems like a feature that's more likely to clutter=20 > the traceroute > >> output with little added value: ifName should=20 > already provide > >> the same > >> benefits and is a more generic mechanism. > >> > >> > >> All of the additional info is optional and an operator could > >> determine what > >> to show based upon the incoming IP address or such. > >> > >> Again, I was going for duplicating the information=20 > provided if an > >> IP address existed. > >> > >> Alia > >> > >> > >>=20 > -------------------------------------------------------------- > ---------- > >> > >> _______________________________________________ > >> Int-area mailing list > >> Int-area@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/int-area > >> =20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Int-area mailing list > > Int-area@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/int-area >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area >=20 _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sat Sep 22 10:14:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ5iU-0004U4-Pp; Sat, 22 Sep 2007 10:12:18 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IZ5iT-0004Tj-Tu for int-area-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 10:12:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ5iT-0004TN-0Y for int-area@ietf.org; Sat, 22 Sep 2007 10:12:17 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZ5iS-00045u-5a for int-area@ietf.org; Sat, 22 Sep 2007 10:12:16 -0400 Received: (qmail invoked by alias); 22 Sep 2007 14:12:15 -0000 Received: from p54987604.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.118.4] by mail.gmx.net (mp042) with SMTP; 22 Sep 2007 16:12:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18cswBb6vwcTwPftAV8shgYs9WjttGGNZswTceova FCuFcQDIUjb2n7 Message-ID: <46F522BE.5060608@gmx.net> Date: Sat, 22 Sep 2007 16:12:14 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [Int-area] Discovering a Location Server in the Access Network References: <46EA4B08.1060307@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hi Pekka, thanks for your response. Pekka Savola wrote: > On Fri, 14 Sep 2007, Hannes Tschofenig wrote: >> In short, the current proposal (see >> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; >> ignoring Section 2 which defines the DHCP portion) essentially does >> the following: >> >> * Discover the public IP address of the end point >> * Perform a reverse DNS lookup to learn the domain >> * Lookup the LIS for that domain >> * Contact the LIS > > 2-3 years ago we had the similar problem with IPv6-in-IPv4 tunnel > endpoint discovery, only that the endpoint could reside outside the > L2/L3 network as well. The approaches identified then were described at: > > http://tools.ietf.org/html/draft-palet-v6ops-tun-auto-disc-03 Thanks for the pointer to this document. I will go through it. > > Personally, I thought anycast made most sense. I will evaluate whether it can be used for our usage scenario. > > Some other folks preferred reverse DNS population (e.g. [1]), but that > also has problems with private address use of a more recent approach > to try to push the NAT boxes to act as authoritative for private > address spaces [2] in which case the ISP could not populate its DNS > resolvers for private addresses either. > > In your case where the L2/L3 provider is required to provide this > information in order for the methodology could work, though personally > I'm somewhat concerned about 1) how reliable the public IP address > discovery could be, That's something I was concerned about as well. > 2) what happens if the ISP doesn't provide reverse DNS entry for the > public IP, Obviously if you don't implement important parts of the solution then the solution will not work. > and 3) whether the operator who's providing L3 service and public IP > does in fact even know where the user is located (if the user's ADSL > session is provided by a L2 provider and just tunneled - in bulk - > using L2TP to L3 provider). The ISP may, in some cases, not be able to know it. There is also a story for this, see. http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-lis2lis-req-00.txt http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-identity-extensions-02.txt * * > > The last issue is probably the biggest and you may need to consider in > more detail how such "L2 different from L3" network would work. > Realistically any solution I could think of that doesn't involve DHCP > or PPP is likely to require coordination in this case. Would it > required that the local regular requires L3 provider to also keep > track of the physical location? So far, I haven't mentioned the usage scenarios. Some of us are particularly interested in emergency services. The regulator is already in the progress of placing requirements on the access network provider to make location information available (in case of emergency services). Ciao Hannes > > [1] > http://tools.ietf.org/html/draft-yamamoto-naptr-service-discovery-01 > [2] http://tools.ietf.org/html/draft-ietf-dnsop-default-local-zones-02 > _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sat Sep 22 11:13:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ6eP-0000Ap-Do; Sat, 22 Sep 2007 11:12:09 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IZ6eO-0000AT-OF for int-area-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 11:12:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ6eO-0000AL-Ep for int-area@ietf.org; Sat, 22 Sep 2007 11:12:08 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZ6eI-00083r-5M for int-area@ietf.org; Sat, 22 Sep 2007 11:12:08 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l8MF7q14060005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Sep 2007 17:07:53 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <46EE52D6.8060809@cisco.com> References: <46EE52D6.8060809@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [Int-area] draft-fuller-240space-00.txt Date: Sat, 22 Sep 2007 17:10:28 +0200 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org On 17-sep-2007, at 12:11, Eliot Lear wrote: > Comments? At the present time, most IP implementation consider any IP address in the range 240.0.0.0 through 255.255.255.255 to be invalid as the source or destination of a datagram. This is untrue. _Most_ implementations have no problem with it. I've thought about writing a draft like this myself and given the use for these addresses some thought. They'd be useful for things that do need global uniqueness, but can do without global reachability. A good example of that would be the numbering of network equipment. In ISP networks this can eat up a decent chunk of address space. Most of the devices in such networks are updated regularly so the addresses could be useful here relatively soon. _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sat Sep 22 11:30:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ6v5-000609-RL; Sat, 22 Sep 2007 11:29:23 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IZ6v4-0005zz-3R for int-area-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 11:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ6v3-0005zr-QC for int-area@ietf.org; Sat, 22 Sep 2007 11:29:21 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZ6v2-0008Up-GJ for int-area@ietf.org; Sat, 22 Sep 2007 11:29:21 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l8MFPNhU061498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Sep 2007 17:25:24 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <46F3A6E1.10803@gmx.net> References: <46EA4B08.1060307@gmx.net> <46F3A6E1.10803@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49972ACB-BCE8-47AC-B76B-D6FE63E2779F@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [Int-area] Re: Discovering a Location Server in the Access Network Date: Sat, 22 Sep 2007 17:27:59 +0200 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: int-area@ietf.org X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org On 21-sep-2007, at 13:11, Hannes Tschofenig wrote: > I haven't received concerns regarding the suggested discovery > approach. May I assume from the lack of feedback that the suggested > approach is reasonable? Not so fast... I've given the draft a quick read and I find myself with some questions: - what would be the resolution of the geography information? - how sensitive is this information from a privacy standpoint? The answers to these questions will determine what approaches are workable. As for the discovery mechanisms: STUN -> reverse DNS -> location server seems convoluted to me. If you look at DNS service discovery (also known as wide area bonjour in some circles) you'll see something that's a lot easier: forward DNS - > server. The advantage here is that DHCP supplies a domain name that can be used for the forward lookup, and home gateways tend to push the domain name they learn from an upstream server out to local hosts so this would work fairly well in an IPv4/NAT setup. And it can piggy back on the DNS service discovery that already happens if applicable. But there are two issues: IPv6, which is typically deployed without DHCP and also often without a working reverse DNS. Apart from that, there is no built-in limitation on who gets to discover the server address. This can be fixed by letting the location server handle privacy limitations. Although anycast was widely shut down for DNS resolver discovery, I think it fits really well here, because it works both for IPv4 and IPv6 and doesn't require additional infrastructure such as the DNS or DHCP. Also, the anycast mechanism automatically limits who gets to talk to the server. Last but not least, the draft seems to assume a centralized model where there is one authoritative server and clients need to talk to that server. I'm not entirely comfortable with that. In general, it's always preferable to be in charge of your own destiny as a user. A more practical problem could be that service providers don't set up servers. We've seen that there are groups who will spend time and money to discover information like this independently. It would be great if that information could be used if there is no other choice and/or the user prefers this. It would also be great if home gateways could (re)transmit location information, which is either learned from an upstream server or entered by a local administrator. But in these cases it's important to consider the possibility of having wrong or conflicting information. (I.e., user moves and forgets to change location setting in a wifi base station.) _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Thu Sep 27 07:36:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iarcw-0001nS-66; Thu, 27 Sep 2007 07:33:54 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1Iarcu-0001h6-6Z for int-area-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 07:33:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iarcs-0001WY-BG; Thu, 27 Sep 2007 07:33:50 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iarck-00033e-3k; Thu, 27 Sep 2007 07:33:48 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5686120B72; Thu, 27 Sep 2007 13:33:31 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-90-46fb950b7cdf Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3455720B6C; Thu, 27 Sep 2007 13:33:31 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 13:33:31 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 13:33:30 +0200 Message-ID: <46FB950A.6020401@ericsson.com> Date: Thu, 27 Sep 2007 13:33:30 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Internet Area , ops-area@ietf.org, discuss@apps.ietf.org, routing-discussion@ietf.org, SAAG X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2007 11:33:30.0993 (UTC) FILETIME=[3AE46610:01C800FA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tsvwg Subject: [Int-area] Guidelines for protocol designers using UDP X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsvwg List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hi, In the TSVWG we have been developing a guidelines document for UDP. It is intended for protocol designers that consider using UDP in their protocol. We do hope that it will help remove some of the misconception that UDP is a simple protocol to use. It might look that way because most of the features necessary for being acceptable to deploy on the general internet needs to be specified by the one using UDP. It is also something that the Transport ADs already started using as help in explaining why and what to fix when we put a DISCUSS on your document that is using UDP. http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-03.txt So TSVWG is still working on this document but we are now considering it quite complete. So we are looking for feedback from you. Are there things that are unclear, missing, wrong, etc. Please provide your feedback to TSVWG (tsvwg@ietf.org). Thanks Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sun Sep 30 11:11:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic0Q6-0003jd-NO; Sun, 30 Sep 2007 11:09:22 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1Ic0Q5-0003jH-3i for int-area-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 11:09:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic0Q4-0003iU-Pb; Sun, 30 Sep 2007 11:09:20 -0400 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ic0Q0-00072f-NP; Sun, 30 Sep 2007 11:09:17 -0400 Received: from [192.168.1.129] (54.44.217.87.dynamic.jazztel.es [87.217.44.54])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp.uc3m.es (Postfix) with ESMTP id 69C12E3F7C;Sun, 30 Sep 2007 17:09:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28F63372-A3AF-40A2-909B-82AAEB4D8319@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Sun, 30 Sep 2007 17:09:25 +0200 To: cga-ext@ietf.org X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.048 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.0615 TC:1F TRN:71 TV:5.0.1023(15452.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: Gabriel Montenegro , Internet Area Subject: [Int-area] Cga and Send extensIons (CSI) bof requested X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hi all, We have requested a slot for Vancouver for a bof on Cga and Send extensIons. The proposed charter is the following: Comments are welcome, and are preferred in the cga-ext ml Regards, marcelo Proposed charter for Cga & Send extensIons (CSI) BOF The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971 provides security mechanisms protecting different functions of the Neighbor Discovery (ND) protocol defined by RFC 2461. This includes address resolution (discovering link layer address of another node attached to the link), router discovery (discovering routers attached to the link), and neighbor unreachability detection (detecting that a node attached to the link is no longer reachable). SEND protection of address resolution and neighbor unreachability detection functions relies on IPv6 address proof-of-ownership and message integrity protection provided respectively via Cryptographically Generated Addresses (CGAs) and RSA Digital Signatures. However, the current SEND specification lacks support for ND Proxies defined by RFC 3775 and RFC 4389. CGAs are defined in RFC 3972, and are extended with a CGA extension format defined in RFC 4581, and a support for multiple hash functions defined in the to-be-RFC draft-bagnulo-multiple-hash-cga-03.txt. While CGAs were originally defined for the SEND protocol, they have proved to be a useful security tool in other environments too, and its usage has been proposed to secure other protocols such as the Shim6 multihoming protocol and the Mobile IPv6 protocol. As CGAs become more widely used for various purposes, it is desirable to define extensions that would support such new usages. The objective of this working group is to define extensions related to both to the SEND protocol and to CGAs. The following are charter items for the working group: - Specify standards-track SEND Extensions to support Neighbor Discovery Proxies: SEND protocol as currently defined in RFC 3971 lacks of support for ND Proxies defined in RFC 3775 and RFC 4389. Extensions to the SEND protocol will be defined in order to provide equivalent SEND security capabilities to ND Proxies. - Specify as required standards-track extensions to IKE and IPsec SPD and PAD to support creation of IPSec SAs authenticated via CGA public-private key pairs of their endpoints. Because of their cryptographic nature, CGAs are inherently bound to the public-private key pair that was used for their generation. This is used in existent protocols for proving address ownership. However, it is also possible to use the CGA cryptographic material held by two peers to create between them a security association which is bound to that material. The key benefit of such an approach is that the resulting security association can be cryptographically bound to the IP address of the endpoints without exclusive recourse to certificates and public key infrastructure. - Develop an informational document analysing different approaches to the use of the DHCP protocol to assign CGAs, and making recommandations on which are the best suited. The analysis will be provided as an input to the DHC working group where the actual DHCP extensions required to implemented the recommended approaches will be defined. - Specify a standards-track CGA extension to support multiple public key algorithms. As currently defined CGAs can only use RSA keys in the CGA Parameter Data Structure, and thus cannot be generated using other public key algorithms (e.g. Elliptic Curve Cryptography -- ECC). The main motivation for this work is that RSA keys are not well suited for environments with resource restrictions (CPU, storage, power) such as the ones considered by the 6lowpan working group. ECC is much well suited for such environments and the lack of support of ECC in CGAs and SeND is a deployment blocker in these environments. - Specify standard-track extensions to RFC 4620 (IPv6 Node Information Queries) to support CGA-based authentication of the information provided. RFC4620 describes a protocol for asking an IPV6 node to supply some network information. On this extension, by the use of CGAs, protection against spoofing attacks and packet authentication mechanisms are provided. - Definition of X.509 Extended Key Usage for SeND. SeND utilizes X.509v3 certificates for performing router authorization. It uses the X.509 extension for IP addresses to verify whether the router is authorized to advertise the mentioned IP addresses. Since the IP addresses extension does not explicitly mention what functions the node can perform for the IP addresses it becomes impossible to know the reason for which the certificate was allowed. In order to facilitate issuance of certificates for specific functions, we need to encode the functions permitted for the certificate into the certificate itself. - Update Cryptographically Generated Addresses (CGA) specification (i.e. RFC3972) based on the existent experience and publish as draft standard. - Update SEcure Neighbor Discovery (SEND) specification (i.e. RFC3971) based on the existent experience and publish as draft standard. - Define the MIB modules for SeND and CGAs and publish them as a Proposed Standard. Related drafts: draft-kempf-cgaext-ringsig-ndproxy-00.txt draft-laganier-ike-ipv6-cga-02.txt draft-jiang-sendcgaext-cga-config-00.txt _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sun Sep 30 12:34:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic1iY-0000GD-1F; Sun, 30 Sep 2007 12:32:30 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1Ic1iV-0000BZ-Ca for int-area-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 12:32:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic1iV-0008MQ-2y; Sun, 30 Sep 2007 12:32:27 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20] helo=mail.tcs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ic1iE-0002mc-Ns; Sun, 30 Sep 2007 12:32:17 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 8D28E2C020DD0; Sun, 30 Sep 2007 19:31:54 +0300 (EEST) Date: Sun, 30 Sep 2007 19:31:54 +0300 (EEST) From: Wassim Haddad To: marcelo bagnulo braun In-Reply-To: <28F63372-A3AF-40A2-909B-82AAEB4D8319@it.uc3m.es> Message-ID: References: <28F63372-A3AF-40A2-909B-82AAEB4D8319@it.uc3m.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: cga-ext@ietf.org, Internet Area , Gabriel Montenegro Subject: [Int-area] Re: [CGA-EXT] Cga and Send extensIons (CSI) bof requested X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org Hi Marcelo, I'd like also to mention draft-haddad-cgaext-optisend-00.txt. Comments appreciated! Regards, Wassim H. On Sun, 30 Sep 2007, marcelo bagnulo braun wrote: > Hi all, > > We have requested a slot for Vancouver for a bof on Cga and Send extensIons. > > The proposed charter is the following: > > Comments are welcome, and are preferred in the cga-ext ml > > Regards, marcelo > > > Proposed charter for Cga & Send extensIons (CSI) BOF > > The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971 > provides security mechanisms protecting different functions of the > Neighbor Discovery (ND) protocol defined by RFC 2461. This includes > address resolution (discovering link layer address of another node > attached to the link), router discovery (discovering routers attached > to the link), and neighbor unreachability detection (detecting that a > node attached to the link is no longer reachable). SEND protection of > address resolution and neighbor unreachability detection functions > relies on IPv6 address proof-of-ownership and message integrity > protection provided respectively via Cryptographically Generated > Addresses (CGAs) and RSA Digital Signatures. However, the current > SEND specification lacks support for ND Proxies defined by RFC 3775 > and RFC 4389. > > CGAs are defined in RFC 3972, and are extended with a CGA extension > format defined in RFC 4581, and a support for multiple hash functions > defined in the to-be-RFC draft-bagnulo-multiple-hash-cga-03.txt. > While CGAs were originally defined for the SEND protocol, they have > proved to be a useful security tool in other environments too, and its > usage has been proposed to secure other protocols such as the Shim6 > multihoming protocol and the Mobile IPv6 protocol. As CGAs become > more widely used for various purposes, it is desirable to define > extensions that would support such new usages. > > The objective of this working group is to define extensions related to > both to the SEND protocol and to CGAs. The following are charter items > for the working group: > > - Specify standards-track SEND Extensions to support Neighbor > Discovery Proxies: SEND protocol as currently defined in RFC 3971 > lacks of support for ND Proxies defined in RFC 3775 and RFC 4389. > Extensions to the SEND protocol will be defined in order to provide > equivalent SEND security capabilities to ND Proxies. > > - Specify as required standards-track extensions to IKE and IPsec > SPD and PAD to support creation of IPSec SAs authenticated via CGA > public-private key pairs of their endpoints. Because of their > cryptographic nature, CGAs are inherently bound to the > public-private key pair that was used for their generation. This is > used in existent protocols for proving address ownership. However, > it is also possible to use the CGA cryptographic material held by > two peers to create between them a security association which is > bound to that material. The key benefit of such an approach is that > the resulting security association can be cryptographically bound > to the IP address of the endpoints without exclusive recourse to > certificates and public key infrastructure. > > - Develop an informational document analysing different approaches to > the use of the DHCP protocol to assign CGAs, and making > recommandations on which are the best suited. The analysis will be > provided as an input to the DHC working group where the actual DHCP > extensions required to implemented the recommended approaches will > be defined. > > - Specify a standards-track CGA extension to support multiple public > key algorithms. As currently defined CGAs can only use RSA keys in > the CGA Parameter Data Structure, and thus cannot be generated using > other public key algorithms (e.g. Elliptic Curve Cryptography -- > ECC). The main motivation for this work is that RSA keys are not > well suited for environments with resource restrictions (CPU, storage, > power) such as the ones considered by the 6lowpan working group. ECC > is much well suited for such environments and the lack of support of ECC > in CGAs and SeND is a deployment blocker in these environments. > > - Specify standard-track extensions to RFC 4620 (IPv6 Node Information > Queries) to support CGA-based authentication of the information > provided. RFC4620 describes a protocol for asking an IPV6 node to supply > some network information. On this extension, by the use of CGAs, > protection against spoofing attacks and packet authentication mechanisms > are provided. > > - Definition of X.509 Extended Key Usage for SeND. SeND utilizes X.509v3 > certificates for performing router authorization. It uses the X.509 > extension for IP addresses to verify whether the router is authorized > to advertise the mentioned IP addresses. Since the IP addresses > extension does not explicitly mention what functions the node can > perform for the IP addresses it becomes impossible to know the reason > for which the certificate was allowed. In order to facilitate issuance > of certificates for specific functions, we need to encode the functions > permitted for the certificate into the certificate itself. > > - Update Cryptographically Generated Addresses (CGA) specification > (i.e. RFC3972) based on the existent experience and publish as > draft standard. > > - Update SEcure Neighbor Discovery (SEND) specification > (i.e. RFC3971) based on the existent experience and publish as > draft standard. > > - Define the MIB modules for SeND and CGAs and publish them > as a Proposed Standard. > > Related drafts: > > draft-kempf-cgaext-ringsig-ndproxy-00.txt > draft-laganier-ike-ipv6-cga-02.txt > draft-jiang-sendcgaext-cga-config-00.txt > > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www1.ietf.org/mailman/listinfo/cga-ext > _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sun Sep 30 23:48:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcCDV-0006ll-3z; Sun, 30 Sep 2007 23:45:09 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IcCDU-0006kS-D2 for int-area-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 23:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcCDU-0006kK-3Q for int-area@ietf.org; Sun, 30 Sep 2007 23:45:08 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcCDO-0001It-Py for int-area@ietf.org; Sun, 30 Sep 2007 23:45:08 -0400 Received: by dog.tcb.net (Postfix, from userid 0) id 8EDBC2680F1; Sun, 30 Sep 2007 21:45:02 -0600 (MDT) Received: from [192.168.1.7] (VDSL-151-118-145-60.DNVR.QWEST.NET [151.118.145.60]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 30 Sep 2007 21:45:02 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=151.118.145.60; client-port=50173; syn-fingerprint=65535:56:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8; data-bytes=0 In-Reply-To: <46A78DA5.2090607@cisco.com> References: <6280db520707241021l25d940dka4a64a0561bf889b@mail.gmail.com> <6280db520707241451u54b8190du3e545af6dfb13361@mail.gmail.com> <46A78DA5.2090607@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Int-area] updated to draft-atlas-icmp-unnumbered-03 Date: Sun, 30 Sep 2007 21:44:46 -0600 To: Alia Atlas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Area Internet X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org On Jul 25, 2007, at 11:51 AM, Mark Townsley wrote: > > Please also give us feedback on whether or not this document should > be published, and on what track. I am considering the Standards > Track, shepherded directly by either me or Jari. I also believe Standards Track is appropriate. I do have a couple of comments rather random comments for the Alia and the rest of the authors. -danny ------- Section 4.1: Interface Role Value 2-3 : "Undefined by this memo and to be assigned by IANA" I think you mean "Reserved"? Bits 4 & 5 of the Interface Information Object you say they MUST be set to zero. Why not SHOULD be, this will provide more flexibility with deployment of new functions that might employ those bits? In section 4 item "4." you say an interface name string of no more than 31 bytes may be included. In section 4.2 you say the interface name Sub-Object must have a length that is a multiple of 4 bytes and MUST NOT exceed 32 bytes. Clarifying that a one octet "charset type" is required, and that the entire field be aligned on 32-bit boundaries, with trailing zero padding if necessary, would perhaps remove any confusion. Also, your use of "An interface name string" may introduce confusion, you might consider rewording section 4 bullet 4. to something like this: 4. An Interface Name Sub-Object, a string of no more than 31 bytes, MAY be included "Figure 3" is the only diagram you seem to have labeled and referenced. Consistency with the others would be useful. In the Security Considerations section tightening up the use of "destination IP address" is important. You should be very clear about the ICMP message destination IP address versus the triggering packets destination IP address. Also, I think the example should be that interface names and ifIndex values should NOT be available outside of the local administrative domain, while the IPv4 addresses may be. Also, the fact that this could be used to identify egress interfaces that may have drop by policy on ingress (e.g., Dest Unreah, Admin Prohibit) should be strongly considered, both from a descriptive and IP address perspective. I could see this information being exploit for reconnaissance and other activities. Providing a few tables for each object in the IANA considerations section might make things more clear. I'd tighten up the wording around the Interface Name Sub-Object bits 4 & 5 as well, as mentioned above. Same for values 2 & 3 if Interface role. Given that this is Standards Track, perhaps something besides FCFS for charset type allocation worthwhile? I also have some concerns about there only being two RSVD bits for included information, I suspect we could very quickly exhaust that. Any thoughts there? I realize we're bounded by C-Type Object subtype bit some other encoding might be useful here? I'm not sure why you have a reference to RFC 2328 in the references section? A general application of this as well may be to identify which egress interface triggered a given function for the original datagram. For example, if an ACL drops the packet and Dest Unreac/Admin Pro denies the packet, being able to identify that might be useful.. Another example there would be that of P MTU, to identify which egress interface can't support a given MTU size - or to obtain a bit of intelligence data from a given router on that front. If you thought of such an implementation on a firewall, for example, you might drop and even provide corresponding policy numbers on a trusted side, and nothing on an untrusted side, etc.. Your text here: Included Information: This 6-bit field [0:5] indicates what information is included in the object. The information must be included in the same order as the bits (from highest to lowest). Might be better clarified by either using highest-order or "leftmost", as opposed to "from highest to lowest". Also, why do you have this constraint? Why is the interface name Sub-Object limited to 32 octets total length? _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area From int-area-bounces@lists.ietf.org Sun Sep 30 23:50:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcCIV-0001DQ-2C; Sun, 30 Sep 2007 23:50:19 -0400 Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1IcCIU-0001By-4V for int-area-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 23:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcCIT-0001Bq-RH for int-area@ietf.org; Sun, 30 Sep 2007 23:50:17 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcCIS-0001OM-Mc for int-area@ietf.org; Sun, 30 Sep 2007 23:50:17 -0400 Received: by dog.tcb.net (Postfix, from userid 0) id 8273E2680F1; Sun, 30 Sep 2007 21:50:16 -0600 (MDT) Received: from [192.168.1.7] (VDSL-151-118-145-60.DNVR.QWEST.NET [151.118.145.60]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 30 Sep 2007 21:50:16 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=151.118.145.60; client-port=50179; syn-fingerprint=65535:56:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8; data-bytes=0 In-Reply-To: References: <46EE52D6.8060809@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <55C66440-29A8-4CB8-A90A-9784EFCF5E4A@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Int-area] draft-fuller-240space-00.txt Date: Sun, 30 Sep 2007 21:50:00 -0600 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Internet Area X-BeenThere: int-area@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: int-area-bounces@lists.ietf.org On Sep 22, 2007, at 9:10 AM, Iljitsch van Beijnum wrote: > On 17-sep-2007, at 12:11, Eliot Lear wrote: > >> Comments? > > At the present time, most IP implementation consider any IP address > in the range 240.0.0.0 through 255.255.255.255 to be invalid as the > source or destination of a datagram. > > This is untrue. _Most_ implementations have no problem with it. Iljitsch, I'd be quite interested in any empirical evidence you might have in support of this statement. Pointers welcome. Thanks! -danny _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area