From owner-ipng@sunroof.eng.sun.com Thu Feb 1 19:11:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1238iU23614 for ipng-dist; Thu, 1 Feb 2001 19:08:44 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1238e223607 for ; Thu, 1 Feb 2001 19:08:40 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f1236W406716 for ipng@sunroof.eng.sun.com; Thu, 1 Feb 2001 19:06:32 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f119tI222970 for ; Thu, 1 Feb 2001 01:55:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07393 for ; Thu, 1 Feb 2001 01:55:17 -0800 (PST) Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05238 for ; Thu, 1 Feb 2001 01:55:16 -0800 (PST) Received: from zeppo.hut.fi (jlundber@zeppo.hut.fi [130.233.249.90]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id LAA26675; Thu, 1 Feb 2001 11:51:33 +0200 (EET) Date: Thu, 1 Feb 2001 11:51:33 +0200 (EET) From: Janne Lundberg To: Pekka Nikander cc: kwang1@email.mot.com, ipng@sunroof.eng.sun.com, janne.lundberg@hut.fi Subject: Re: Java 2 and IPv6? In-Reply-To: <3A785133.76F2E7C1@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 31 Jan 2001, Pekka Nikander wrote: > Kevin Wang wrote: > > I am going to move from Network layer to Transport layer. Any one can > > tell if I can use Sun Java 2 for IPv6 programming? I mean does Java 2 > > support IPv6? > > Any pointer to the resources will be greatly appreciated. > > As far as I know, Sun is considering IPv6 support for JDK 1.4. > Unfortunately, I don't know anything about its schedule. > > On the other hand, Janne Lundberg of HUT created experimental > IPv6 support for Linux JDK 1.3 (or was it JDK1.2.2) last summer. > I don't know if he has made it publicly available, but maybe > he could comment the state of the work himself. The IPv6 support was done for JDK1.2.2, and the original source file was called jdk1_2_2-L-src-linux-09_Mar.zip. The patch was written for RedHat 6.2, and can be downloaded from http://www.tml.hut.fi/~jlu/jdkpatch.tar.gz. I no longer use 1.2.2 so I don't know whether or not it works on anything else than RH6.2 (or even if it compiles...) - Janne -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 1 23:08:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1276kA23733 for ipng-dist; Thu, 1 Feb 2001 23:06:46 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1276b223726 for ; Thu, 1 Feb 2001 23:06:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA16257 for ; Thu, 1 Feb 2001 23:06:38 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA22730 for ; Thu, 1 Feb 2001 23:06:37 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA07252 for ; Thu, 1 Feb 2001 23:06:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f1276Ye17639 for ; Thu, 1 Feb 2001 23:06:34 -0800 X-Virus-Scanned: Thu, 1 Feb 2001 23:06:34 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdhdXJFs; Thu, 01 Feb 2001 23:06:30 PST Message-ID: <3A7A5C77.4C9C1287@Kniveton.com> Date: Thu, 01 Feb 2001 23:06:31 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: IPv6 Prefix Deprecation Problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am looking through the Address Autoconfig (RFC 2462) and Neighbor Discovery (RFC 2461) drafts, and there seems to be a bit of discrepancy about deprecating prefixes. Specifically, let's consider the scenario described in RFC 2461 on page 78-79. A prefix has been advertised with a lifetime of two months, a machine is turned off on July 31st, then on Aug. 1st, it's decided the prefix should expire on Sep 1st. The host is turned back during September, at which point the prefix is deprecated, but the node's last received advertisement indicates the prefix is valid until the end of September. 2461 states: The only way to force a node to stop using a prefix that was previously advertised with a long Lifetime is to have that node receive an advertisement for that prefix that changes the lifetime downward. The solution in this example is simple: continue advertising the prefix with a lifetime of 0 from September 1st until October 1st. However, RFC 2462 has stated that unless router advertisements are authenticated, any router advertisement trying to expire the prefix (which still has a few days, to most of a month, of validity left), will just lower it to two hours. Is it OK with everyone that a node that has been turned off for a while, could possibly be *unusable* on a network for two hours? We can not say that an admin will log into this machine and manually remove the prefix, or that router advertisements after a network renumber will be authenticated. Both of these make far too many assumptions. Aside from whether this is "OK," there is inconsistency between these drafts. 2461 does not seem to account for the DoS attack which 2462 is trying to avoid. Comments? -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 2 05:29:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f12DRl423961 for ipng-dist; Fri, 2 Feb 2001 05:27:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f12DRc223954 for ; Fri, 2 Feb 2001 05:27:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA03747 for ; Fri, 2 Feb 2001 05:27:38 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06513 for ; Fri, 2 Feb 2001 05:27:37 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:260:8ff:fe8b:23e6]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id WAA10643; Fri, 2 Feb 2001 22:11:31 +0900 (JST) Date: Fri, 02 Feb 2001 22:26:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "T.J. Kniveton" Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Prefix Deprecation Problem In-Reply-To: In your message of "Thu, 01 Feb 2001 23:06:31 -0800" <3A7A5C77.4C9C1287@Kniveton.com> References: <3A7A5C77.4C9C1287@Kniveton.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000414(IM141) Lines: 43 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 01 Feb 2001 23:06:31 -0800, >>>>> "T.J. Kniveton" said: > However, RFC 2462 has stated that unless router advertisements are > authenticated, any router advertisement trying to expire the prefix > (which still has a few days, to most of a month, of validity left), will > just lower it to two hours. > Is it OK with everyone that a node that has been turned off for a while, > could possibly be *unusable* on a network for two hours? We can not say > that an admin will log into this machine and manually remove the prefix, > or that router advertisements after a network renumber will be > authenticated. Both of these make far too many assumptions. In this case, we can reasonably assume that a new prefix (with positive valid and preferred lifetimes) is being advertised. Thus, we have at least one preferred address. Also, in the scenario above, the old prefix is being advertised with zero lifetimes, the old address is immediately deprecated (note that the "two hours" protection described in RFC 2462 is not applied to preferred lifetime.) Consequently, we would just use the (only) preferred address when we start a new communication by the definition of the "deprecated" address, and would not see any problems in a normal operation. > Aside from whether this is "OK," there is inconsistency between these > drafts. 2461 does not seem to account for the DoS attack which 2462 is > trying to avoid. No, we don't care about zero-lifetime attack in prefix (i.e on-link) manipulation, which RFC 2461 describes. We only care about the attack that attemps to make a victim's *address* invalid. Note that we can still send packets to default routers even if we don't have any known on-link prefixes, while we can't make any off-link communications if all the global addresses are invalidated. Of course, you could say that this policy is "wrong", but at least the two policies are not inconsistent. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 2 07:43:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f12FfVV24092 for ipng-dist; Fri, 2 Feb 2001 07:41:31 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f12FfK224085 for ; Fri, 2 Feb 2001 07:41:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22867 for ; Fri, 2 Feb 2001 07:41:20 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05302 for ; Fri, 2 Feb 2001 08:41:18 -0700 (MST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA11329; Fri, 2 Feb 2001 09:41:16 -0600 (CST) Message-Id: <200102021541.JAA11329@gungnir.fnal.gov> To: "T.J. Kniveton" Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: IPv6 Prefix Deprecation Problem In-reply-to: Your message of Thu, 01 Feb 2001 23:06:31 PST. <3A7A5C77.4C9C1287@Kniveton.com> Date: Fri, 02 Feb 2001 09:41:15 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is it OK with everyone that a node that has been turned off for a while, could possibly be *unusable* on a network for two hours? We can not say I think "unusuable" is too strong. There will presumably be newer prefixes advertised and no rule makes the node ignore those. Also, doesn't the node's stack need to allow for the possibility that when it is powered back on, it is connected to a different link entirely? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 2 08:36:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f12GZ5i24236 for ipng-dist; Fri, 2 Feb 2001 08:35:05 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f12GYu224229 for ; Fri, 2 Feb 2001 08:34:57 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09341 for ; Fri, 2 Feb 2001 08:34:56 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04211 for ; Fri, 2 Feb 2001 08:34:55 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f12GYmg26328 for ; Fri, 2 Feb 2001 10:34:58 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 2 Feb 2001 10:34:44 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <1C0LBF33>; Fri, 2 Feb 2001 10:29:39 -0600 Message-ID: To: ipng@sunroof.eng.sun.com Subject: Base API draft-ietf-ipngwg-rfc2553bis-02.txt Date: Fri, 2 Feb 2001 10:24:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk folks, we submitted the above draft. over 15 implementors have worked on this final version too. there are some minor edits to be done and before I submit that I want you to know that next Friday I will ask the chairs to submit this to last call and get new rfc to replace rfc2553. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 2 09:14:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f12HCgr24315 for ipng-dist; Fri, 2 Feb 2001 09:12:42 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f12HCV224308 for ; Fri, 2 Feb 2001 09:12:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18851 for ; Fri, 2 Feb 2001 09:12:31 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28793 for ; Fri, 2 Feb 2001 10:12:30 -0700 (MST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA05399; Fri, 2 Feb 2001 09:11:32 -0800 (PST) Message-Id: <200102021711.JAA05399@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3041 on Extensions to IPv6 Address Autoconfiguration Cc: rfc-ed@ISI.EDU, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 02 Feb 2001 09:11:32 -0800 From: RFC Editor Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3041 Title: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s): T. Narten, R. Draves Status: Standards Track Date: January 2001 Mailbox: narten@raleigh.ibm.com, richdr@microsoft.com Pages: 17 Characters: 44446 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipngwg-addrconf-privacy-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3041.txt Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host Configuration Protocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. This document is a product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010202090706.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3041 --OtherAccess Content-Type: Message/External-body; name="rfc3041.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010202090706.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 2 10:59:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f12IwB024416 for ipng-dist; Fri, 2 Feb 2001 10:58:11 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f12Iw2224409 for ; Fri, 2 Feb 2001 10:58:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23919 for ; Fri, 2 Feb 2001 10:58:01 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA22253 for ; Fri, 2 Feb 2001 10:58:00 -0800 (PST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 30 Jan 2001 07:56:35 -0800 (Pacific Standard Time) content-class: urn:content-classes:message Subject: RE: src addr sel (was: A6 unreliability) (fwd) Date: Wed, 24 Jan 2001 13:06:24 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9C24@red-msg-06.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: src addr sel (was: A6 unreliability) (fwd) Thread-Index: AcCDRVpd4OjysLnVQmmvOiCOJ3H0HwDAhavw X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.12 From: "Richard Draves" To: "Mauro Tortonesi" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f12Iw3224410 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > i wonder if there is a working implementation of dest/src address > selection that is fully conformant to this spec. i'd really like to > know how the implementation issues have been solved. Yes, I have implemented it. It's pretty easy to implement. Basically when getaddrinfo gets more than one address back from DNS, it uses an ioctl to call down to the IPv6 stack to sort the addresses. Then all the real work is in the IPv6 stack, where there is direct access to information like the interfaces, addresses, routing table, etc. > The destination address selection algorithm needs information about > potential source addresses. One possible implementation strategy is > for getipnodebyname() and getaddrinfo() to call down to the IPv6 > network layer with a list of destination addresses, sort > the list in > the network layer with full current knowledge of available source > addresses, and return the sorted list to getipnodebyname() or > getaddrinfo(). This is simple and gives the best results but it > introduces the overhead of another system call. One way to reduce > this overhead is to cache the sorted address list in the resolver, > so that subsequent calls for the same name do not need to > resort the > list. > > imho this is not so simple to implement. it requires a tight coupling > between the network layer (kernel space) and the networking stuff of > the C library (user space), and a very careful design of the caching > policy (especially if we have to handle temporary, preferred and > deprecated addresses). It is in fact simple to implement. One simple strategy for having the resolver cache a sorted list is to resort the list if it was last sorted more than some short time ago, like a second. > Another implementation strategy is to call down to the > network layer > to retrieve source address information and then sort the list of > addresses directly in the context of getipnodebyname() or > getaddrinfo(). To reduce overhead in this approach, the source > address information can be cached, amortizing the overhead of > retrieving it across multiple calls to getipnodebyname() and > getaddrinfo(). > > this is a simpler solution, as it requires only a minor interaction > between kernel- and user-space. but the complexity of the caching > algorithm is not reduced, and this implementation introduces another > problem: I disagree, I think this is a much more complicated implementation strategy because you have to pull lots of information into the user space context to do the sort there. But to each his own: the draft is explicitly not mandating an implementation strategy. > In this approach, the implementation may not have > knowledge of the outgoing interface for each destination, so it MAY > use a looser definition of the candidate set during destination > address ordering. > > and this is surely a negative point. Yes, another reason I didn't choose this implementation strategy myself. > moreover, there are lots of other problems to be solved. in > particular: > > 1) performance. it cannot be allowed by using cached data, as caching > is very difficult to do. and the spec says: > > In any case, if the implementation uses cached and possibly stale > information in its implementation of destination address selection, > or if the ordering of a cached list of destination addresses is > possibly stale, then it should ensure that the destination address > ordering returned to the application is no more than one second out > of date. For example, an implementation might make a system call to > check if any routing table entries or source address assignments > that might affect these algorithms have changed. > > because cached data is valid for no more than 1 sec., and the > implementation of a correct caching algorithm is VERY difficult, > caching is more a problem than a solution. There are many ways to implement this. One solution is just to resort if more than one second has gone by, in other words assume that any information more than one second old is stale. Another solution is to keep an invalidation counter in the stack. The counter is incremented any time there is change in relevant state, like the routing table or address assignments. Then when you cache information dependent on that state, you save a copy of the counter. You can later check the cached counter value against the current value to see if the cached computation result is stale. > 2) handling the policy table. it should be kept in kernel-space, but > designing a simple and safe way to edit it is surely not a trivial > task. It was a trivial task. The policy table is much like a routing table and I based the ioctls that retrieve/update the policy table on the routing table ioctls. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 2 11:19:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f12JHp024444 for ipng-dist; Fri, 2 Feb 2001 11:17:51 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f12JHg224437 for ; Fri, 2 Feb 2001 11:17:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09842 for ; Fri, 2 Feb 2001 11:17:37 -0800 (PST) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09738 for ; Fri, 2 Feb 2001 12:17:35 -0700 (MST) Received: from [192.168.1.42] (qool.kniveton.com [192.168.1.42]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f12JGwa67350 for ; Fri, 2 Feb 2001 11:16:58 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 02 Feb 2001 11:17:32 -0800 Subject: Re: IPv6 Prefix Deprecation Problem From: "T.J. Kniveton" To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk on 2/2/01 5:26 AM, JINMEI Tatuya / ???? wrote: >>>>>> On Thu, 01 Feb 2001 23:06:31 -0800, >>>>>> "T.J. Kniveton" said: > >> However, RFC 2462 has stated that unless router advertisements are >> authenticated, any router advertisement trying to expire the prefix >> (which still has a few days, to most of a month, of validity left), will >> just lower it to two hours. > >> Is it OK with everyone that a node that has been turned off for a while, >> could possibly be *unusable* on a network for two hours? We can not say >> that an admin will log into this machine and manually remove the prefix, >> or that router advertisements after a network renumber will be >> authenticated. Both of these make far too many assumptions. > > In this case, we can reasonably assume that a new prefix (with positive > valid and preferred lifetimes) is being advertised. Thus, we have at > least one preferred address. Also, in the scenario above, the old > prefix is being advertised with zero lifetimes, the old address is > immediately deprecated (note that the "two hours" protection described > in RFC 2462 is not applied to preferred lifetime.) Consequently, we > would just use the (only) preferred address when we start a new > communication by the definition of the "deprecated" address, and would > not see any problems in a normal operation. OK, thanks, that is clearer. Isn't this still vulnerable to a desnial of service attack? If I only have one global address and a malicious node deprecates my address, I can not open any new connections. Granted, I can continue using the connections that are open, but it still prevents further communication. I would assume that whenever there are no valid prefixes, the node would send a router solicitation. But if the attacking node is fast, it can deprecate prefixes as soon as they're advertised. > >> Aside from whether this is "OK," there is inconsistency between these >> drafts. 2461 does not seem to account for the DoS attack which 2462 is >> trying to avoid. > > No, we don't care about zero-lifetime attack in prefix (i.e on-link) > manipulation, which RFC 2461 describes. We only care about the attack > that attemps to make a victim's *address* invalid. > > Note that we can still send packets to default routers even if we > don't have any known on-link prefixes, while we can't make any > off-link communications if all the global addresses are invalidated. > > Of course, you could say that this policy is "wrong", but at least the > two policies are not inconsistent. The distinction between deprecating a prefix and invalidating it was what I was missing in my read of the draft. I still see a problem vis a vis the zero-lifetime attack. Am I missing something? -- TJ Kniveton NOKIA Research > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 2 11:59:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f12Jvr424492 for ipng-dist; Fri, 2 Feb 2001 11:57:53 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f12Jvh224485 for ; Fri, 2 Feb 2001 11:57:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07622 for ; Fri, 2 Feb 2001 11:57:42 -0800 (PST) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21828 for ; Fri, 2 Feb 2001 11:57:42 -0800 (PST) Received: from [192.168.1.42] (qool.kniveton.com [192.168.1.42]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f12Jv4a67413; Fri, 2 Feb 2001 11:57:04 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 02 Feb 2001 11:57:39 -0800 Subject: Re: IPv6 Prefix Deprecation Problem From: "T.J. Kniveton" To: Matt Crawford CC: , Message-ID: In-Reply-To: <200102021541.JAA11329@gungnir.fnal.gov> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I am crossposting to Mobile-IP since I am throwing in some info about mobiles] on 2/2/01 7:41 AM, Matt Crawford wrote: > Is it OK with everyone that a node that has been turned off for a while, > could possibly be *unusable* on a network for two hours? We can not say > > I think "unusuable" is too strong. There will presumably be newer > prefixes advertised and no rule makes the node ignore those. OK, here is why I posted the message. We can certainly imagine good implementations that handle this renumbering case without a hitch. However, in reading the rules of the draft, I can imagine correct, and possibly even reasonable, implementations that choke at this point. For instance, if my implementation has a strong affinity for my primary global address as long as it remains valid, and it thinks the address is valid for a couple more hours, it might continue to try to use that address. Some layer above IP is choosing the source address -- either the application, or an upper network layer on its behalf. This layer "should" [2462] choose a prefix that has a positive preferred lifetime remaining when it opens a connection. Perhaps that "should" should change to "must". What bothers me boils down to the fact that we have a VALID prefix, though it may not be preferred. A deprecated address is still a valid address and MAY be used to start new communication. Yet the autoconfig rules do not have any way to remove this invalid address/prefix. > > Also, doesn't the node's stack need to allow for the possibility that > when it is powered back on, it is connected to a different link entirely? Good point. I didn't even get into the problems with mobile nodes. Imagine, for instance the following twist: The mobile node had one global address based on its home prefix. It was turned off on July 31st. The mobile's Home Network was renumbered, as described in RFC 2461, between August 1st and September 1st. Mappings from the old prefix to the new prefix were removed from routers on September 15th. The old prefix is dead. Now the mobile node is turned on, on September 25th, in a visited network. It starts receiving router advertisements for the local link. It configures a link-local care-of address. It wants to contact its Home Agent to register a binding for its care-of address. "I can't contact my home agent." "I can't contact any routers on my home network to do Home Agent Discovery." "My cached home address has not expired...but my home network has disappeared." "Help!" Hmmm. This could be a problem. I am writing a draft to address possible courses of action at this point..unless anyone can provide a good, clear, obvious answer. -- TJ Kniveton NOKIA Research -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 2 22:43:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f136gPt24963 for ipng-dist; Fri, 2 Feb 2001 22:42:25 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f136gD224956 for ; Fri, 2 Feb 2001 22:42:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA03856 for ; Fri, 2 Feb 2001 22:42:11 -0800 (PST) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA18009 for ; Fri, 2 Feb 2001 23:42:08 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 0DC587E46; Sat, 3 Feb 2001 14:36:33 +0900 (JST) To: "T.J. Kniveton" Cc: Matt Crawford , ipng@sunroof.eng.sun.com, mobile-ip@standards.nortelnetworks.com In-reply-to: TJ's message of Fri, 02 Feb 2001 11:57:39 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 Prefix Deprecation Problem From: Jun-ichiro itojun Hagino Date: Sat, 03 Feb 2001 14:36:32 +0900 Message-Id: <20010203053633.0DC587E46@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Now the mobile node is turned on, on September 25th, in a visited network. >It starts receiving router advertisements for the local link. It configures >a link-local care-of address. It wants to contact its Home Agent to register >a binding for its care-of address. link-local care-of address? are you sure you want to do that? I hope this is typo of "global care-of address". (note that you can only contact correspondent nodes that is on-link to the mobile node) scope issue with mobile-ip6 is hairy... itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 3 13:40:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f13LdHH25328 for ipng-dist; Sat, 3 Feb 2001 13:39:17 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f13Ld7225321 for ; Sat, 3 Feb 2001 13:39:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17992 for ; Sat, 3 Feb 2001 13:39:06 -0800 (PST) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23771 for ; Sat, 3 Feb 2001 13:39:05 -0800 (PST) Received: from Kniveton.com (nachos.kniveton.com [192.168.1.69]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f13LcFa70892; Sat, 3 Feb 2001 13:38:15 -0800 (PST) Message-ID: <3A7C7A6B.C7EFC7E9@Kniveton.com> Date: Sat, 03 Feb 2001 13:38:51 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: ipng@sunroof.eng.sun.com, mobile-ip@standards.nortelnetworks.com Subject: Re: IPv6 Prefix Deprecation Problem References: <20010203053633.0DC587E46@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino wrote: > > >Now the mobile node is turned on, on September 25th, in a visited network. > >It starts receiving router advertisements for the local link. It configures > >a link-local care-of address. It wants to contact its Home Agent to register > >a binding for its care-of address. > > link-local care-of address? are you sure you want to do that? I hope > this is typo of "global care-of address". > (note that you can only contact correspondent nodes that is on-link > to the mobile node) > > scope issue with mobile-ip6 is hairy... > > itojun You caught me typing too fast. Instead of "link-local care-of address," I meant to say simply "care-of address," which would obviously be a globally routable autoconfigured address using a prefix advertised on the visited network link. TJ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 4 17:49:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f151lm025829 for ipng-dist; Sun, 4 Feb 2001 17:47:48 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f151lc225822 for ; Sun, 4 Feb 2001 17:47:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26540 for ; Sun, 4 Feb 2001 17:47:38 -0800 (PST) Received: from m018.com ([210.112.11.138]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08104 for ; Sun, 4 Feb 2001 17:47:36 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:24:22 +0900 Received: from patan.sun.com ([192.18.98.43]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:56:06 +0900 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24783; Sat, 3 Feb 2001 13:41:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18099; Sat, 3 Feb 2001 13:41:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f13LdHH25328 for ipng-dist; Sat, 3 Feb 2001 13:39:17 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f13Ld7225321 for ; Sat, 3 Feb 2001 13:39:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17992 for ; Sat, 3 Feb 2001 13:39:06 -0800 (PST) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23771 for ; Sat, 3 Feb 2001 13:39:05 -0800 (PST) Received: from Kniveton.com (nachos.kniveton.com [192.168.1.69]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f13LcFa70892; Sat, 3 Feb 2001 13:38:15 -0800 (PST) Message-ID: <3A7C7A6B.C7EFC7E9@Kniveton.com> Date: Sat, 03 Feb 2001 13:38:51 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: ipng@sunroof.eng.sun.com, mobile-ip@standards.nortelnetworks.com Subject: Re: IPv6 Prefix Deprecation Problem References: <20010203053633.0DC587E46@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino wrote: > > >Now the mobile node is turned on, on September 25th, in a visited network. > >It starts receiving router advertisements for the local link. It configures > >a link-local care-of address. It wants to contact its Home Agent to register > >a binding for its care-of address. > > link-local care-of address? are you sure you want to do that? I hope > this is typo of "global care-of address". > (note that you can only contact correspondent nodes that is on-link > to the mobile node) > > scope issue with mobile-ip6 is hairy... > > itojun You caught me typing too fast. Instead of "link-local care-of address," I meant to say simply "care-of address," which would obviously be a globally routable autoconfigured address using a prefix advertised on the visited network link. TJ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 5 00:11:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f158AYs26169 for ipng-dist; Mon, 5 Feb 2001 00:10:34 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f158AP226162 for ; Mon, 5 Feb 2001 00:10:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27022 for ; Mon, 5 Feb 2001 00:10:26 -0800 (PST) Received: from shaku.v6.linux.or.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26107 for ; Mon, 5 Feb 2001 00:10:25 -0800 (PST) Received: from YUMIKO.sfc.wide.ad.jp (dhcpw233.nc.u-tokyo.ac.jp [133.11.123.233]) by shaku.v6.linux.or.jp (8.11.0/3.7W) with ESMTP id f1588so27982 for ; Mon, 5 Feb 2001 17:08:54 +0900 Date: Mon, 05 Feb 2001 17:10:09 +0900 Message-ID: From: USAGI Project To: ipng@sunroof.eng.sun.com Subject: [ANN] 2nd STABLE release of USAGI Project Reply-To: usagi-core@linux-ipv6.org User-Agent: Wanderlust/1.1.1 (Purple Rain) REMI/1.14.1 (=?ISO-8859-4?Q?Mus?= =?ISO-8859-4?Q?higawa=F2sugi?=) Chao/1.14.0 (Momoyama) APEL/10.2 Emacs/20.7 (i386-*-nt5.0.2195) MULE/4.1 (AOI) Meadow/IPv6-1.13 Beta1++ (TANAHASHI:61) Organization: Keio University MIME-Version: 1.0 (generated by REMI 1.14.1 - =?ISO-8859-4?Q?=22Mushigawa=F2?= =?ISO-8859-4?Q?sugi=22?=) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello ! We are glad that we can announce the 2nd STABLE RELEASE of USAGI (UniverSAl playGround for Ipv6) on February 5th, 2001. On this release, we provide only kernel, but two kernels. One is linux-2.2.18-usagi kernel and the other is linux-2.4.0-usagi kernel. The USAGI Project is managed by volunteers and aims to provide better IPv6 environment on Linux freely. We try to improve Linux kernel, IPv6 related libraries and IPv6 applications. Please visit http://www.linux-ipv6.org/ for further details of USAGI project. The improved features are listed below. - Linux kernel-2.2.18-usagi-20010205 Based on Linux kernel-2.2.18, we have improved and impremented + better source address selection, + ICMPv6 Node Information Queries, + SNMP statistics per device, + IPv6 khttpd, + re-joining all-node multicast address on network devices, + enabling double bind on the same port, + support backward compatibility of sin6_scope_id with old glibc, + enabling default route when ipv6 forwarding is enabled, + rejecting invalid ICMPs, + more compliance with RFC regarding Neighbor Discovery Protocol, Stateless Autoaddress Configuration, Multicast Listener Discovery Protocol, + processing extension headers, + INSTALL and Configuration documentation and + bug fixes against original kernel. - Linux kernel-2.4.0-usagi-20010205 Based on Linux kernel-2.4.0, we have improved and implemented same as kernel-2.2.18-usagi-20010205. You can get above source codes from the following URL. ftp://ftp.linux-ipv6.org/pub/usagi/stable/patch/ USAGI Project will release snapshot codes on each two weeks and stable codes on several times a year. We will announce latest information via web page. Please check our web page. BTW, we also provide the binary packages for some distributions. The binary packages will appear after February 12th, 2001. We will provide the packages for the following distribution. RedHat debian Turbo Linux Vine Linux Kondara/MNU Linux By the way, we manage the mailing list for USAGI users. If you have questions or advices, please join the mailing list. For more details, please see http://www.linux-ipv6.org/ml/ . Thanks. Related Web sites. WIDE Project http://www.wide.ad.jp/ KAME Project http://www.kame.net/ TAHI Project http://www.tahi.org/ -- USAGI Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 5 06:47:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f15Ejbm26395 for ipng-dist; Mon, 5 Feb 2001 06:45:37 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f15EjQ226388 for ; Mon, 5 Feb 2001 06:45:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28741 for ; Mon, 5 Feb 2001 06:45:26 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02694 for ; Mon, 5 Feb 2001 06:45:25 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:6928:fa09:573c:7bc4]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA03948; Mon, 5 Feb 2001 23:29:26 +0900 (JST) Date: Mon, 05 Feb 2001 23:44:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "T.J. Kniveton" Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Prefix Deprecation Problem In-Reply-To: In your message of "Fri, 02 Feb 2001 11:17:32 -0800" References: User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000414(IM141) Lines: 72 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 02 Feb 2001 11:17:32 -0800, >>>>> "T.J. Kniveton" said: >> In this case, we can reasonably assume that a new prefix (with positive >> valid and preferred lifetimes) is being advertised. Thus, we have at >> least one preferred address. Also, in the scenario above, the old >> prefix is being advertised with zero lifetimes, the old address is >> immediately deprecated (note that the "two hours" protection described >> in RFC 2462 is not applied to preferred lifetime.) Consequently, we >> would just use the (only) preferred address when we start a new >> communication by the definition of the "deprecated" address, and would >> not see any problems in a normal operation. > OK, thanks, that is clearer. > Isn't this still vulnerable to a desnial of service attack? If I only have > one global address and a malicious node deprecates my address, I can not > open any new connections. Granted, I can continue using the connections that > are open, but it still prevents further communication. I would assume that > whenever there are no valid prefixes, the node would send a router > solicitation. But if the attacking node is fast, it can deprecate prefixes > as soon as they're advertised. If you only have one global address, you can just use the address even if the address has been deprecated. RFC2462 says A deprecated address SHOULD continue to be used as a source address in existing communications, but SHOULD NOT be used in new communications if an alternate (non-deprecated) address is available and has sufficient scope. (Section 5.5.4) Note that the if-clause at the end of the sentence. >>> Aside from whether this is "OK," there is inconsistency between these >>> drafts. 2461 does not seem to account for the DoS attack which 2462 is >>> trying to avoid. >> >> No, we don't care about zero-lifetime attack in prefix (i.e on-link) >> manipulation, which RFC 2461 describes. We only care about the attack >> that attemps to make a victim's *address* invalid. >> >> Note that we can still send packets to default routers even if we >> don't have any known on-link prefixes, while we can't make any >> off-link communications if all the global addresses are invalidated. >> >> Of course, you could say that this policy is "wrong", but at least the >> two policies are not inconsistent. > The distinction between deprecating a prefix and invalidating it was what I > was missing in my read of the draft. I still see a problem vis a vis the > zero-lifetime attack. Am I missing something? Which zero-lifetime attack did you mean? For the address lifetime, the attacker can only make the address deprecated. This is not a significant attack as I said in the previous message and above. For the prefix (on-link) lifetime, the attacker can make all the prefixes of a victim off-link. However, since the victim still knows default routers, it can just send packets to a router, and (if it is lucky enough,) can make any on-link and off-link communications. However, the attacker can also - make all valid routers' lifetimes zero, or - be a "blackhole" router. I admit these attacks can be a real threat, and are diffcult to protect. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 5 08:23:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f15GM6m26490 for ipng-dist; Mon, 5 Feb 2001 08:22:06 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f15GLt226483 for ; Mon, 5 Feb 2001 08:21:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07712 for ; Mon, 5 Feb 2001 08:21:55 -0800 (PST) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29785 for ; Mon, 5 Feb 2001 09:21:54 -0700 (MST) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id D0D06967; Mon, 5 Feb 2001 10:21:53 -0600 (CST) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 99EBF97D for ; Mon, 5 Feb 2001 10:21:53 -0600 (CST) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 5 Feb 2001 11:21:53 -0500 Message-ID: From: "Powell, Ken" To: "'T.J. Kniveton'" Cc: ipng@sunroof.eng.sun.com, mobile-ip@standards.nortelnetworks.com Subject: RE: IPv6 Prefix Deprecation Problem Date: Mon, 5 Feb 2001 11:21:49 -0500 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > Sent: Friday, February 02, 2001 2:58 PM > To: Matt Crawford > Cc: ipng@sunroof.eng.sun.com; mobile-ip@standards.nortelnetworks.com > Subject: Re: IPv6 Prefix Deprecation Problem > > Some layer above IP is choosing the source address -- either the > application, or an upper network layer on its behalf. This > layer "should" > [2462] choose a prefix that has a positive preferred lifetime > remaining when > it opens a connection. Perhaps that "should" should change to "must". There are other considerations that go into source address selection, some of which have a worse impact than selecting an address with preferred lifetime of zero. See Richard Draves' draft-ietf-ipngwg-default-addr-select-02 for more details. > > > > > Also, doesn't the node's stack need to allow for the > possibility that > > when it is powered back on, it is connected to a different > link entirely? > > Good point. I didn't even get into the problems with mobile > nodes. Imagine, > for instance the following twist: > > The mobile node had one global address based on its home > prefix. It was > turned off on July 31st. The mobile's Home Network was renumbered, as > described in RFC 2461, between August 1st and September 1st. > Mappings from > the old prefix to the new prefix were removed from routers on > September > 15th. The old prefix is dead. > > Now the mobile node is turned on, on September 25th, in a > visited network. > It starts receiving router advertisements for the local link. > It configures > a link-local care-of address. It wants to contact its Home > Agent to register > a binding for its care-of address. > > "I can't contact my home agent." > "I can't contact any routers on my home network to do Home > Agent Discovery." > "My cached home address has not expired...but my home network has > disappeared." > "Help!" I've had this same concern. We discussed it on the mobility list last year, and as Mattias said, the procedure for initializing a mobile node is beyond the scope of the Mobile IPv6 draft. We did however discuss some possible initialization techniques to verify that the mobile IPv6 protocol had sufficient features to support initialization, particularly where stateless address autoconfiguration is used on the home network. Appendix A of draft-ietf-mobileip-ipv6-13 describes one of these techniques. It starts by retrieving the home agent anycast address from DNS. One problem with the appendix A approach is that it does not account for IPsec. We need a procedure that describes how to establish the security associations between the mobile node and the home agent in addition to initializing home addresses and creating bindings. Perhaps something that uses a AAA server? > > Hmmm. This could be a problem. I am writing a draft to > address possible > courses of action at this point..unless anyone can provide a > good, clear, > obvious answer. I'm looking forward to seeing your draft. Ken -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 5 15:14:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f15NCvx27120 for ipng-dist; Mon, 5 Feb 2001 15:12:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f15NCm227113 for ; Mon, 5 Feb 2001 15:12:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26159 for ; Mon, 5 Feb 2001 15:12:45 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26363 for ; Mon, 5 Feb 2001 15:12:44 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA13078; Mon, 5 Feb 2001 15:12:42 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f15NCeg16741; Mon, 5 Feb 2001 15:12:40 -0800 X-Virus-Scanned: Mon, 5 Feb 2001 15:12:40 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdIipmf7; Mon, 05 Feb 2001 15:12:34 PST Message-ID: <3A7F3365.9DBB43A6@Nokia.com> Date: Mon, 05 Feb 2001 15:12:37 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, mobile-ip@STANDARDS.NORTELNETWORKS.COM Subject: Re: IPv6 Prefix Deprecation Problem References: <034BEFD03799D411A59F00508BDF75465B6979@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 5 15:15:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f15NDu127129 for ipng-dist; Mon, 5 Feb 2001 15:13:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f15NDh227122 for ; Mon, 5 Feb 2001 15:13:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15733 for ; Mon, 5 Feb 2001 15:13:43 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06345 for ; Mon, 5 Feb 2001 16:13:42 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA13134; Mon, 5 Feb 2001 15:13:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f15NDcF17844; Mon, 5 Feb 2001 15:13:38 -0800 X-Virus-Scanned: Mon, 5 Feb 2001 15:13:38 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdBatH4b; Mon, 05 Feb 2001 15:13:34 PST Message-ID: <3A7F33A0.27D39D01@Kniveton.com> Date: Mon, 05 Feb 2001 15:13:36 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, mobile-ip@standards.nortelnetworks.com Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 5 16:11:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f160AIg27269 for ipng-dist; Mon, 5 Feb 2001 16:10:18 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f160AE227262 for ; Mon, 5 Feb 2001 16:10:14 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f16083o07889 for ipng@sunroof.eng.sun.com; Mon, 5 Feb 2001 16:08:03 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1274S223714 for ; Thu, 1 Feb 2001 23:04:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA15921 for ; Thu, 1 Feb 2001 23:04:28 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA15225 for ; Fri, 2 Feb 2001 00:04:28 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA07184 for ; Thu, 1 Feb 2001 23:04:27 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f1274Q416788 for ; Thu, 1 Feb 2001 23:04:26 -0800 X-Virus-Scanned: Thu, 1 Feb 2001 23:04:26 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdsAMzM1; Thu, 01 Feb 2001 23:04:22 PST Message-ID: <3A7A5BF7.5CF23099@Nokia.com> Date: Thu, 01 Feb 2001 23:04:23 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: IPv6 Prefix Deprecation Problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am looking through the Address Autoconfig (RFC 2462) and Neighbor Discovery (RFC 2461) drafts, and there seems to be a bit of discrepancy about deprecating prefixes. Specifically, let's consider the scenario described in RFC 2461 on page 78-79. A prefix has been advertised with a lifetime of two months, a machine is turned off on July 31st, then on Aug. 1st, it's decided the prefix should expire on Sep 1st. The host is turned back during September, at which point the prefix is deprecated, but the node's last received advertisement indicates the prefix is valid until the end of September. 2461 states: The only way to force a node to stop using a prefix that was previously advertised with a long Lifetime is to have that node receive an advertisement for that prefix that changes the lifetime downward. The solution in this example is simple: continue advertising the prefix with a lifetime of 0 from September 1st until October 1st. However, RFC 2462 has stated that unless router advertisements are authenticated, any router advertisement trying to expire the prefix (which still has a few days, to most of a month, of validity left), will just lower it to two hours. Is it OK with everyone that a node that has been turned off for a while, could possibly be *unusable* on a network for two hours? We can not say that an admin will log into this machine and manually remove the prefix, or that router advertisements after a network renumber will be authenticated. Both of these make far too many assumptions. Aside from whether this is "OK," there is inconsistency between these drafts. 2461 does not seem to account for the DoS attack which 2462 is trying to avoid. Comments? -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 5 16:14:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f160DlD27338 for ipng-dist; Mon, 5 Feb 2001 16:13:47 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f160De227326 for ; Mon, 5 Feb 2001 16:13:41 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f160BT107926 for ipng@sunroof.eng.sun.com; Mon, 5 Feb 2001 16:11:29 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f14JMj225667 for ; Sun, 4 Feb 2001 11:22:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15651 for ; Sun, 4 Feb 2001 11:22:44 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12230 for ; Sun, 4 Feb 2001 11:22:43 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f14JMgC10906 for ; Sun, 4 Feb 2001 20:22:42 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sun Feb 04 20:22:41 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id <1CVMXY49>; Sun, 4 Feb 2001 20:22:42 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6979@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'T.J. Kniveton'" , Matt Crawford Cc: ipng@sunroof.eng.sun.com, mobile-ip@STANDARDS.NORTELNETWORKS.COM Subject: RE: IPv6 Prefix Deprecation Problem Date: Sun, 4 Feb 2001 20:22:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > Also, doesn't the node's stack need to allow for the possibility that > > when it is powered back on, it is connected to a different link entirely? > > Good point. I didn't even get into the problems with mobile nodes. Imagine, > for instance the following twist: > > The mobile node had one global address based on its home prefix. It was > turned off on July 31st. The mobile's Home Network was renumbered, as > described in RFC 2461, between August 1st and September 1st. Mappings from > the old prefix to the new prefix were removed from routers on September > 15th. The old prefix is dead. > > Now the mobile node is turned on, on September 25th, in a visited network. > It starts receiving router advertisements for the local link. It configures > a link-local care-of address. It wants to contact its Home Agent to register > a binding for its care-of address. > > "I can't contact my home agent." > "I can't contact any routers on my home network to do Home Agent Discovery." > "My cached home address has not expired...but my home network has > disappeared." > "Help!" > > Hmmm. This could be a problem. I am writing a draft to address possible > courses of action at this point..unless anyone can provide a good, clear, > obvious answer. > => I don't have a concrete proposal but basically the problem here is manual configuration of the Home address / prefix. If the MN can decouple its identity from the Home prefix and use something more abstract (eg. NAI) then the problem can be solved. - The MN starts in a foreign network - It discovers its home address (By looking up the NAI is some location management database. eg DNS) - The MN does dynamic HA discovery - The MN sends a BU to the HA. In general manually configuring the Home address seems to be a bad approach IMO. The above approach is implementation dependant and would not require modifications to MIPv6. Another alternative would be to use AAAH to get a home address but I'd rather not use AAA for this since MIPv6 already has a mechanism for finding the HA. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 5 16:18:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f160HVc27398 for ipng-dist; Mon, 5 Feb 2001 16:17:31 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f160HR227391 for ; Mon, 5 Feb 2001 16:17:27 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f160FG207956 for ipng@sunroof.eng.sun.com; Mon, 5 Feb 2001 16:15:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f159LX226244 for ; Mon, 5 Feb 2001 01:21:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02152 for ; Mon, 5 Feb 2001 01:21:33 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA16788 for ; Mon, 5 Feb 2001 01:21:31 -0800 (PST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f159LAC13901; Mon, 5 Feb 2001 10:21:14 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA29719; Mon, 5 Feb 2001 10:21:10 +0100 Message-ID: <3A7E6C58.55A01CA@era.ericsson.se> Date: Mon, 05 Feb 2001 10:03:20 +0100 From: Mattias Pettersson Organization: Ericsson Radio Systems AB X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en, sv MIME-Version: 1.0 To: "T.J. Kniveton" CC: Matt Crawford , ipng@sunroof.eng.sun.com, mobile-ip@standards.nortelnetworks.com Subject: Re: IPv6 Prefix Deprecation Problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "T.J. Kniveton" wrote: > > [I am crossposting to Mobile-IP since I am throwing in some info about > mobiles] > > > > Also, doesn't the node's stack need to allow for the possibility that > > when it is powered back on, it is connected to a different link entirely? > > Good point. I didn't even get into the problems with mobile nodes. Imagine, > for instance the following twist: > > The mobile node had one global address based on its home prefix. It was > turned off on July 31st. The mobile's Home Network was renumbered, as > described in RFC 2461, between August 1st and September 1st. Mappings from > the old prefix to the new prefix were removed from routers on September > 15th. The old prefix is dead. > > Now the mobile node is turned on, on September 25th, in a visited network. > It starts receiving router advertisements for the local link. It configures > a link-local care-of address. It wants to contact its Home Agent to register > a binding for its care-of address. > > "I can't contact my home agent." > "I can't contact any routers on my home network to do Home Agent Discovery." > "My cached home address has not expired...but my home network has > disappeared." > "Help!" > > Hmmm. This could be a problem. I am writing a draft to address possible > courses of action at this point..unless anyone can provide a good, clear, > obvious answer. Are your prefix lifetimes not supposed to be in the same order as the renumbering period? If your renumbering takes one month, set valid lifetime to one month for prefixes announces long before the renumbering phase starts. In this way you won't end up in situations like this. Next, I wouldn't be sure that a Mobile Node would remember it's home prefix lifetime if it was switched off. One requirement that we came up to when writing Mobile IPv6 i-d v13 was that the Mobile Node must somehow know its home prefix or a DNS name representing the home prefix or home agents anycast address. How the Mobile Node learns this is out of scope of the draft. Thus, the upper layer that provides the Mobile Node with the home prefix in the first place, must also provide the new renumbered home prefix in cases like this when the Mobile Node is switched off during renumbering. /Mattias -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 5 16:48:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f160lDd27505 for ipng-dist; Mon, 5 Feb 2001 16:47:13 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f160l4227498 for ; Mon, 5 Feb 2001 16:47:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07547 for ; Mon, 5 Feb 2001 16:47:05 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA17432 for ; Mon, 5 Feb 2001 16:47:04 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Feb 2001 16:45:38 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <111GD9XH>; Mon, 5 Feb 2001 16:47:05 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA801FB4BED@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "T.J. Kniveton" Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Prefix Deprecation Problem Date: Mon, 5 Feb 2001 16:46:58 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Specifically, let's consider the scenario described in RFC > 2461 on page > 78-79. A prefix has been advertised with a lifetime of two months, a > machine is turned off on July 31st, then on Aug. 1st, it's decided the > prefix should expire on Sep 1st. The host is turned back during > September, at which point the prefix is deprecated, but the > node's last > received advertisement indicates the prefix is valid until the end of > September. I don't know of any implementations that keep prefixes in a persistent store. My expectaction would be that when the host is turned back on in September, it will send an RS and get RAs and auto-configure itself without any memory of the old prefix. Furthermore, I think the site administrator has screwed up by advertising a two month lifetime and then trying to remove the prefix in one month. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 5 17:35:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f161XUr27670 for ipng-dist; Mon, 5 Feb 2001 17:33:30 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f161XK227663 for ; Mon, 5 Feb 2001 17:33:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25564 for ; Mon, 5 Feb 2001 17:33:20 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29776 for ; Mon, 5 Feb 2001 17:33:20 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA27124; Mon, 5 Feb 2001 17:33:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f161XIO08711; Mon, 5 Feb 2001 17:33:18 -0800 X-Virus-Scanned: Mon, 5 Feb 2001 17:33:18 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdmPVuq5; Mon, 05 Feb 2001 17:33:10 PST Message-ID: <3A7F5457.60992CC@Kniveton.com> Date: Mon, 05 Feb 2001 17:33:11 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Richard Draves CC: mobile-ip@standards.nortelnetworks.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Prefix Deprecation Problem References: <7695E2F6903F7A41961F8CF888D87EA801FB4BED@red-msg-06.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Draves wrote: > > > Specifically, let's consider the scenario described in RFC > > 2461 on page > > 78-79. A prefix has been advertised with a lifetime of two months, a > > machine is turned off on July 31st, then on Aug. 1st, it's decided the > > prefix should expire on Sep 1st. The host is turned back during > > September, at which point the prefix is deprecated, but the > > node's last > > received advertisement indicates the prefix is valid until the end of > > September. > > I don't know of any implementations that keep prefixes in a persistent > store. My expectaction would be that when the host is turned back on in > September, it will send an RS and get RAs and auto-configure itself without > any memory of the old prefix. No, the mobile node is not on its home network; it is away from home. RSs sent on the VISITED link will allow auto-configuration of a COA. Getting RAs from the HOME link would require tunneling a RS to the home network. And to tunnel this RA, you need the HA's address (the first n bits of your cached copy are now bogus). Back to square 1. > Furthermore, I think the site administrator has screwed up by advertising a > two month lifetime and then trying to remove the prefix in one month. Maybe true. Which leaves the questions, why does 2462 give this as an example of network renumbering, why are lifetimes 32 bits and why does the RFC allow infinite lifetimes on network prefixes? This is academic anyway. The problem isn't necessarily that the old prefix doesn't go away fast enough. The problem is that a mobile node, away from home, may wake up from being turned off during a renumbering event, and have NO WAY to contact its home agent or even home network. Either it has stale prefix info, or NO prefix info, but with no binding at its home agent, and thus no tunneled router advertisements at any point during the renumbering, it doesn't have CURRENT prefix info. Whether the renumbering took place over a day, month, or year is immaterial - the mobile simply has to be away from home and not register with the HA when the renumbering starts, and then start using Mobile IPv6 after the network renumbering for the problem to arise. This was my original point, which perhaps I have not effectively described. There is a way around this, using DNS, but that requires services that may not be available on the visited network. I can not see a general and acceptable way to avoid this problem, but I remain open to suggestions. Thanks, -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 5 20:26:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f164P8Q27798 for ipng-dist; Mon, 5 Feb 2001 20:25:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f164Ox227791 for ; Mon, 5 Feb 2001 20:24:59 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA09025 for ; Mon, 5 Feb 2001 20:24:55 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA18641 for ; Mon, 5 Feb 2001 20:24:54 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Feb 2001 20:23:28 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <111G1XDX>; Mon, 5 Feb 2001 20:24:55 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA801FB4C13@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "T.J. Kniveton" Cc: mobile-ip@standards.nortelnetworks.com, ipng@sunroof.eng.sun.com Subject: RE: IPv6 Prefix Deprecation Problem Date: Mon, 5 Feb 2001 20:24:50 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I don't know of any implementations that keep prefixes in a > persistent > > store. My expectaction would be that when the host is > turned back on in > > September, it will send an RS and get RAs and > auto-configure itself without > > any memory of the old prefix. > > No, the mobile node is not on its home network; it is away from home. Ah, I didn't understand from your first message that you were asking about a mobile node's home address. I thought you were asking about ordinary auto-configured prefixes. Sorry. > > Furthermore, I think the site administrator has screwed up > by advertising a > > two month lifetime and then trying to remove the prefix in > one month. > > Maybe true. Which leaves the questions, why does 2462 give this as an > example of network renumbering, why are lifetimes 32 bits and why does > the RFC allow infinite lifetimes on network prefixes? > > This is academic anyway. The problem isn't necessarily that the old > prefix doesn't go away fast enough. The problem is that a mobile node, > away from home, may wake up from being turned off during a renumbering > event, and have NO WAY to contact its home agent or even home network. > Either it has stale prefix info, or NO prefix info, but with > no binding > at its home agent, and thus no tunneled router advertisements at any > point during the renumbering, it doesn't have CURRENT prefix info. > Whether the renumbering took place over a day, month, or year is > immaterial - the mobile simply has to be away from home and > not register > with the HA when the renumbering starts, and then start using Mobile > IPv6 after the network renumbering for the problem to arise. > > This was my original point, which perhaps I have not effectively > described. There is a way around this, using DNS, but that requires > services that may not be available on the visited network. I > can not see > a general and acceptable way to avoid this problem, but I > remain open to > suggestions. I suspect people are willing to punt on this problem (of mobile nodes away from home & turned off for an arbitrarily long time, while the home network undergoes arbitrary reconfiguration). Do you think it's an important scenario for some reason? As you hint, if the mobile node has a DNS name for itself which is stable, then perhaps the DNS can provide the bootstrap. (If the mobile node doesn't have a home DNS name, then what functionality is Mobile IPv6 supposed to provide in this situation?) More generally, the Mobile IPv6 spec doesn't solve the mobile node configuration problem. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 6 01:50:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f169mkJ27971 for ipng-dist; Tue, 6 Feb 2001 01:48:46 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f169mW227964 for ; Tue, 6 Feb 2001 01:48:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20296 for ; Tue, 6 Feb 2001 01:48:31 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11835 for ; Tue, 6 Feb 2001 02:48:29 -0700 (MST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f169mQd29716; Tue, 6 Feb 2001 10:48:27 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA08084; Tue, 6 Feb 2001 10:48:26 +0100 Message-ID: <3A7FC35D.B3568780@era.ericsson.se> Date: Tue, 06 Feb 2001 10:26:53 +0100 From: Mattias Pettersson Organization: Ericsson Radio Systems AB X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en, sv MIME-Version: 1.0 To: "T.J. Kniveton" CC: ipng@sunroof.eng.sun.com, mobile-ip@STANDARDS.NORTELNETWORKS.COM Subject: Re: IPv6 Prefix Deprecation Problem References: <034BEFD03799D411A59F00508BDF75465B6979@esealnt448.al.sw.ericsson.se> <3A7F3365.9DBB43A6@Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "T.J. Kniveton" wrote: > > Mattias Pettersson wrote: > > Are your prefix lifetimes not supposed to be in the same order as the > > renumbering period? If your renumbering takes one month, set valid > > lifetime to one month for prefixes announces long before the renumbering > > phase starts. In this way you won't end up in situations like this. > > It may or may not be possible to have enough a priori knowledge of the > renumbering to start advertising shortened lifetimes "long" before the > renumbering. Regardless, wouldn't it be better to have a spec that > handles possible and reasonable situations, rather than saying things > will work if you implement and configure just-so? Along with what Richard Draves I think that the site administrator has to plan things already when the site is constructed. Also, since ND is un-acknowledged when it comes to RAs, this can happen: - The router sends RAs with lifetime of one year. - A host configures itself with this. - The router decreases RA lifetime to one week. - The host misses all RAs from this point. - After one week the old prefix is invalid on the link. - The host still sees it valid for almost one year unless it's being advertised with lifetime 0. Unlikely, but still possible. So the initial lifetime of one year is a bad choice. > > To me, it is not a far stretch of the imagination to picture a laptop > that is a MN running MIPv6, which sits for a long period of time on a > foreign network, and is switched off for a few months. I mean, maybe > it's not the common case..but it should still work! Right? I agree with you to 100% that it should work. The MN should not be useless after such an event. > > > Next, I wouldn't be sure that a Mobile Node would remember it's home > > prefix lifetime if it was switched off. > > OK.. But if the state this machine is keeping around is its home network > prefix, it could be toast. If it is keeping its home address, home agent > address, and home network prefix without any lifetimes, it still may not > be able to communicate with its home network or any correspondents using > its home address. The lifetime is not really the problem. It's how much > information and support you need to determine your identity and origins. Sure, please see below. > > > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > > that the Mobile Node must somehow know its home prefix or a DNS name > > representing the home prefix or home agents anycast address. How the > > Well, DNS is the option that's most likely to survive a network > renumbering. But, can we really mandate that DNS is available for a > mobile node when it's configuring on a foreign network?... > > > Mobile Node learns this is out of scope of the draft. Thus, the upper > > Appendix A deals with it in a limited situation as Hesham denoted above. > What if DNS is not available? It may also be able to continue supporting > mobility at the IP layer, but without use of the Home Address, if the > home network can not be resolved. I.e. what if the visited network > becomes your new, temporary "home network" and you can continue to roam, > keeping open TCP connections, using your COA as your "home address". Nobody can contact you, since they don't know your new home address. Does the foreign network want to give you this service? > > Is there any interest in exploring the issue (beyond the scope of the > draft, if need be)? > > > layer that provides the Mobile Node with the home prefix in the first > > place, must also provide the new renumbered home prefix in cases like > > this when the Mobile Node is switched off during renumbering. > > Good point. > I think we should not put any futher requirements on Mobile IPv6 itself. The bootstrapping sequence described in Appendix A takes care of everything, with one requirement: Mobile IPv6 needs the home prefix. Some function has to find out this current home prefix on every invocation of Mobile IPv6. Example: while (1) { if (stored_home_prefix == NULL) { stored_home_prefix = magic_function(magic_ID); } error = invoke_mobile_ipv6(stored_home_prefix); if (error) { stored_home_prefix = NULL; } } So Mobile IPv6 would complain if stored_home_prefix wouldn't work and thus need to fall back on some other (magic) function, e.g. - function = DNS, ID = home agents anycast address name, for instance - function = AAA, ID = NAI (?) - function = manual... user has to find the new home prefix. - ... Whatever this function is it is needed when we create a system using Mobile IPv6. However, Mobile IPv6 itself doesn't need this. If the foreign network doesn't support AAA or DNS, maybe we have to stick to manual intervention. Or do we want to agree upon a new method, in addition to the ones listed above? The problem is to make every foreign network support them. /Mattias -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 6 05:06:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f16D5J928119 for ipng-dist; Tue, 6 Feb 2001 05:05:19 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f16D57228112 for ; Tue, 6 Feb 2001 05:05:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA27400 for ; Tue, 6 Feb 2001 05:05:06 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA10792 for ; Tue, 6 Feb 2001 05:05:05 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f16D54C20243 for ; Tue, 6 Feb 2001 14:05:04 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Feb 06 14:06:06 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZPCBG>; Tue, 6 Feb 2001 14:01:37 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6992@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: RE: [MOBILE-IP] IPv6 Prefix Deprecation Problem Date: Tue, 6 Feb 2001 14:02:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > > that the Mobile Node must somehow know its home prefix or a DNS name > > representing the home prefix or home agents anycast address. How the > > Well, DNS is the option that's most likely to survive a network > renumbering. But, can we really mandate that DNS is available for a > mobile node when it's configuring on a foreign network?... > > > Mobile Node learns this is out of scope of the draft. Thus, the upper > > Appendix A deals with it in a limited situation as Hesham denoted above. > What if DNS is not available? > => The assumption here is that as a MN you want to be reached. If you do want to be reached then the mapping of your name to an IP address must be stored "somewhere". Unless of course you will only give your IP address to people in some other way. So whether it is a DNS or some other database, you need to be able to query that database for your home address/prefix. Of course you also need to make sure that it survives renumbering. That's why a DNS seems quite reasonable. > It may also be able to continue supporting > mobility at the IP layer, but without use of the Home Address, if the > home network can not be resolved. I.e. what if the visited network > becomes your new, temporary "home network" and you can continue to roam, > keeping open TCP connections, using your COA as your "home address". > => You need some support from AAA to be able to do that. In that case you would get a home prefix, perform HA discovery, and then register with the HA. But still to be reached you would have to update a database/server somewhere. > Is there any interest in exploring the issue (beyond the scope of the > draft, if need be)? > => Sure. Also if you're statement above is implying having MNs that do not have any fixed home addresses then you might want to look into the Homeless MIPv6 draft to see the impacts of this approach and how they solved it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 6 05:19:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f16DHgF28164 for ipng-dist; Tue, 6 Feb 2001 05:17:42 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f16DHV228157 for ; Tue, 6 Feb 2001 05:17:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28279 for ; Tue, 6 Feb 2001 05:17:30 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24707 for ; Tue, 6 Feb 2001 05:17:29 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12908; Tue, 6 Feb 2001 08:17:30 -0500 (EST) Message-Id: <200102061317.IAA12908@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-addr-arch-v3-04.txt Date: Tue, 06 Feb 2001 08:17:29 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-04.txt Pages : 25 Date : 05-Feb-01 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-v3-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010205140423.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v3-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010205140423.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 6 16:26:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f170OKg29120 for ipng-dist; Tue, 6 Feb 2001 16:24:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f170OA229113 for ; Tue, 6 Feb 2001 16:24:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08215 for ; Tue, 6 Feb 2001 16:24:11 -0800 (PST) Received: from c000.snv.cp.net (c000-h002.c000.snv.cp.net [209.228.32.66]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA15245 for ; Tue, 6 Feb 2001 16:24:11 -0800 (PST) Received: (cpmta 8094 invoked from network); 6 Feb 2001 16:24:10 -0800 Received: from unknown (HELO dellchan) (208.135.49.132) by smtp.francis.com (209.228.32.66) with SMTP; 6 Feb 2001 16:24:10 -0800 X-Sent: 7 Feb 2001 00:24:10 GMT Message-ID: <006b01c0909c$528dda60$1300a8c0@dellchan> From: "Paul Francis" To: References: <034BEFD03799D411A59F00508BDF75465B6979@esealnt448.al.sw.ericsson.se> <3A7F3365.9DBB43A6@Nokia.com> <3A7FC35D.B3568780@era.ericsson.se> Subject: another renumbering question Date: Tue, 6 Feb 2001 16:24:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I recall having once read in some internet-draft that, in order not to disrupt intra-site communications during renumbering, that intra-site communications should use site-local addresses. But I can't recall how it is a host decides when another host can be reached via a site-local address, nor can I find where I read that text. Can anyone point me to the IDs/RFCs that talk about this? Thanks, PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 6 21:22:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f175KiL29391 for ipng-dist; Tue, 6 Feb 2001 21:20:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f175KZ229384 for ; Tue, 6 Feb 2001 21:20:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA09305 for ; Tue, 6 Feb 2001 21:20:35 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA26659 for ; Tue, 6 Feb 2001 21:20:27 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id MAA27913; Wed, 7 Feb 2001 12:20:16 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f175Ma901544; Wed, 7 Feb 2001 12:22:38 +0700 (ICT) From: Robert Elz To: "Paul Francis" cc: ipng@sunroof.eng.sun.com Subject: Re: another renumbering question In-reply-to: Your message of "Tue, 06 Feb 2001 16:24:23 PST." <006b01c0909c$528dda60$1300a8c0@dellchan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Feb 2001 12:22:36 +0700 Message-ID: <1542.981523356@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 6 Feb 2001 16:24:23 -0800 From: "Paul Francis" Message-ID: <006b01c0909c$528dda60$1300a8c0@dellchan> | But I can't recall how it is a host decides when another host can be reached | via a site-local address, nor can I find where I read that text. This is still one of life's mysteries I think - several ideas have been floated, but nothing yet committed to a draft that I'm aware of. The include placing the site locals in the DNS, and having clients do a match on the global addresses to see if the site local should refer to the same site (one that finds no attraction to me at all). And having the client send from its site local addr (so the packet cannot leave the site) to the remote global addr an ICMP saying "tell me your addresses", and receiving a list that includes the site locals for the destination (or receiving an ICMP error indicating an attempt to cross the site boundary with a site local source addr). (If the source doesn't have, or doesn't want to use, its site local addr, then there's no point doing any of this, may as well just use global addr of the dest a well). This one I like - it adds a small delay in communications the first time a connection is attempted to a new node (only for connections initiated, responses would never do this) but that is bounded by the RTT to the edge of the site, which is usually of the order of a couple of ms. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 00:59:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f178uAp29500 for ipng-dist; Wed, 7 Feb 2001 00:56:10 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f178tx229493 for ; Wed, 7 Feb 2001 00:55:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA13056 for ; Wed, 7 Feb 2001 00:55:59 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA13815 for ; Wed, 7 Feb 2001 01:55:59 -0700 (MST) Received: (qmail 12691 invoked by uid 1001); 7 Feb 2001 08:56:16 -0000 Date: 7 Feb 2001 08:56:16 -0000 Message-ID: <20010207085616.169.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: The case against A6 and DNAME Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I recommend that the A6 and DNAME proposals be terminated. I've set up a web page on this topic: http://cr.yp.to/djbdns/killa6.html ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 01:33:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f179W1O29610 for ipng-dist; Wed, 7 Feb 2001 01:32:01 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f179Vo229603 for ; Wed, 7 Feb 2001 01:31:52 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA09780 for ; Wed, 7 Feb 2001 01:31:50 -0800 (PST) Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15752 for ; Wed, 7 Feb 2001 01:31:49 -0800 (PST) Received: from duplo.sm.sony.co.jp (onoe@localhost) by onoe2.sm.sony.co.jp (8.9.0/3.7W) with ESMTP id SAA10851 for ; Wed, 7 Feb 2001 18:31:47 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.2/8.10.2) id f179XSO05095; Wed, 7 Feb 2001 18:33:28 +0900 (JST) Date: Wed, 7 Feb 2001 18:33:28 +0900 (JST) From: Atsushi Onoe Message-Id: <200102070933.f179XSO05095@duplo.sm.sony.co.jp> To: ipng@sunroof.eng.sun.com Subject: IPv6 over IEEE1394 X-Mailer: Cue version 0.6 (010116-0953/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Norten pointed out to authors that doesn't clearly describe if the MCAP (Multicast Channel Allocation Protocol) is required (MUST) or not. Since IEEE1394 has only 63 channels for multicast, both IPv4 over IEEE1394 (RFC2734) and IPv6 over IEEE1394 define all multicast addresses MUST be share single broadcast channel by default. The intention of MCAP is to split high rate data traffic from the default broadcast channel. For this reason, RFC2734 says 224.0.0.1 and 224.0.0.2 MUST use broadcast channel. >From RFC2734 (IPv4 over IEEE 1394) "9. IP MULTICAST": | By default, all best-effort IP multicast SHALL use asynchronous | stream packets whose channel number is equal to the channel field | from the BROADCAST_CHANNEL register. In particular, datagrams | addressed to 224.0.0.1 and 224.0.0.2 SHALL use this channel number. | Best-effort IP multicast for other IP multicast group addresses may | utilize a different channel number if such a channel number is | allocated and advertised prior to use, as described below. Similarly, we, authors, would like to change the text of IPv6 over IEEE1394 as follows: | 9. IPv6 MULTICAST | | By default, all best-effort IPv6 multicast MUST use asynchronous | stream packets whose channel number is equal to the channel field | from the BROADCAST_CHANNEL register. In particular, datagrams | addressed to all-nodes multicast addresses, all-routers multicast | addresses, and solicited-node multicast addresses [AARCH] MUST use | the default channel specified by the BROADCAST_CHANNEL register. | | Best-effort IPv6 multicast for other multicast group addresses may | utilize a different channel number if such a channel number is | allocated and advertised prior to use, by a multicast channel | allocation protocol (MCAP), as described in [IP1394]. The | implementors are encouraged to use this protocol when transmitting | high-rate multicast streams. When a node wishes to receive multicast | data addressed to other than all-nodes multicast addresses, all- | routers multicast addresses, and solicited-node multicast addresses, | it MUST confirm if the channel mapping between a multicast group | address and a channel number exists using MCAP, as described in "9.3 | Multicast Receive" in [IP1394]. | | The MCAP 'type' value for IPv6 group address descriptor is {to be | assigned by IANA}. Comments? Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 02:08:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17A7Rq29673 for ipng-dist; Wed, 7 Feb 2001 02:07:27 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17A7I229666 for ; Wed, 7 Feb 2001 02:07:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06782 for ; Wed, 7 Feb 2001 02:07:18 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA12745 for ; Wed, 7 Feb 2001 03:07:17 -0700 (MST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA03144 for ipng@sunroof.eng.sun.com; Wed, 7 Feb 2001 11:07:15 +0100 (MET) Date: Wed, 7 Feb 2001 11:07:15 +0100 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: The case against A6 and DNAME Message-ID: <20010207110715.A2549@theory.cs.uni-bonn.de> References: <20010207085616.169.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010207085616.169.qmail@cr.yp.to>; from djb@cr.yp.to on Wed, Feb 07, 2001 at 08:56:16AM -0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 07, 2001 at 08:56:16AM -0000, D. J. Bernstein wrote: > I recommend that the A6 and DNAME proposals be terminated. I've set up a > web page on this topic: >=20 > http://cr.yp.to/djbdns/killa6.html Yes, read, and understood. How is the example you show different from what is warned against in RFC 2874, paragraph 5.1.2 ? OTOH, if you want to eliminate protocol-(cache-) level indirection altogether, (including CNAMEs (and NS) records pointing to names), you'd need to write a draft of all of it up. (This includes an address-valued NS replacement.) And by providing a formal description of how the servers resolve the indirections, and how renaming has to happen if this is implemented, we will be able to check whether this will work, and what requirements are needed to make this work (e.g., how to ensure convergence when renaming or renumbering happens for one of the components). I'm not yet convinced that moving the indirection from the caches to the servers helps in all cases. Regards, -is --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOoEd8zCn4om+4LhpAQFphgf/VuWaUEVNEV5bv2QhA+mF2DC9GcCr3b4C 3G5gtMkxXIOMKrRl/PVWqDAVJDBfCCuPS8dX24mKydsWZZ84mdRXqsZF3sBHOMLl NeVtVHoCBqgnlknKN8Kcew7Lw+SSOfLwFZdrMVKVnHavzMQoBtyJsTvQuvT34OUq EqARiQrJz2bG/6eQOuCbr4i47A8fMdTBxAmRHOyt0rIFhrb35biUVIMQfmJf0yTR ui3oCFxAy7B7BVwcb9SrFNjuRNQ6iVj23EVPTiazyCq/aWUWwGUD9lbSFlOmklhc pKiu0HefUov17L03TffigkGV1SzkQyWxpspWnjTyIia9qzXClWNawQ== =wGyG -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 07:23:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17FLar29855 for ipng-dist; Wed, 7 Feb 2001 07:21:36 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17FLR229848 for ; Wed, 7 Feb 2001 07:21:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15688 for ; Wed, 7 Feb 2001 07:21:27 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09971 for ; Wed, 7 Feb 2001 07:21:27 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA54358; Wed, 7 Feb 2001 07:21:19 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA19790; Wed, 7 Feb 2001 07:21:02 -0800 Message-ID: <3A816765.F7069C25@hursley.ibm.com> Date: Wed, 07 Feb 2001 09:19:01 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Robert Elz CC: Paul Francis , ipng@sunroof.eng.sun.com Subject: Re: another renumbering question References: <1542.981523356@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Once you *know* that a host has a site local address, the address selection draft tells you when to use it. I've always assumed that they would be in the DNS along with global addresses. Presumably large sites will be running two-faced DNS anyway, so these addresses will never go outside. Brian Robert Elz wrote: > > Date: Tue, 6 Feb 2001 16:24:23 -0800 > From: "Paul Francis" > Message-ID: <006b01c0909c$528dda60$1300a8c0@dellchan> > > | But I can't recall how it is a host decides when another host can be reached > | via a site-local address, nor can I find where I read that text. > > This is still one of life's mysteries I think - several ideas have > been floated, but nothing yet committed to a draft that I'm aware of. > > The include placing the site locals in the DNS, and having clients > do a match on the global addresses to see if the site local should > refer to the same site (one that finds no attraction to me at all). > > And having the client send from its site local addr (so the packet cannot > leave the site) to the remote global addr an ICMP saying "tell me your > addresses", and receiving a list that includes the site locals for the > destination (or receiving an ICMP error indicating an attempt to cross > the site boundary with a site local source addr). (If the source doesn't > have, or doesn't want to use, its site local addr, then there's no point > doing any of this, may as well just use global addr of the dest a well). > This one I like - it adds a small delay in communications the first time > a connection is attempted to a new node (only for connections initiated, > responses would never do this) but that is bounded by the RTT to the edge > of the site, which is usually of the order of a couple of ms. > > kre > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 08:28:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17GQSx29975 for ipng-dist; Wed, 7 Feb 2001 08:26:28 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17GQH229968 for ; Wed, 7 Feb 2001 08:26:17 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f17GQFR660460; Wed, 7 Feb 2001 08:26:15 -0800 (PST) Date: Wed, 7 Feb 2001 17:25:56 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IPv6 Prefix Deprecation Problem To: Richard Draves Cc: "T.J. Kniveton" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <7695E2F6903F7A41961F8CF888D87EA801FB4BED@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't know of any implementations that keep prefixes in a persistent > store. My expectaction would be that when the host is turned back on in > September, it will send an RS and get RAs and auto-configure itself without > any memory of the old prefix. The Solaris 8 IPv6 implementation retains the IPv6 addresses configured through stateless autoconfig in stable storage (together with the prefix lifetimes). This is only used as a fallback should the node reboot and find no routers on the link (i.e. no response after 3 RSs). The implementation does not retain the on-link prefixes - just the addrconf prefixes. This helps in the power failure scenario when the hosts on a link might reboot before the routers. While they can't communicate off-link until the routers appear there is some benefit in being able to communicate on-link using the same addresses (global or site-local) that they had before the power failure. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 08:46:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17GivB00011 for ipng-dist; Wed, 7 Feb 2001 08:44:57 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17Gik200004 for ; Wed, 7 Feb 2001 08:44:46 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f17GijR663629; Wed, 7 Feb 2001 08:44:45 -0800 (PST) Date: Wed, 7 Feb 2001 17:44:27 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: another renumbering question To: Paul Francis Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <006b01c0909c$528dda60$1300a8c0@dellchan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I recall having once read in some internet-draft that, in order not to > disrupt intra-site communications during renumbering, that intra-site > communications should use site-local addresses. > > But I can't recall how it is a host decides when another host can be reached > via a site-local address, nor can I find where I read that text. > > Can anyone point me to the IDs/RFCs that talk about this? draft-ietf-ipngwg-site-prefixes-nn.txt, which has expired. The secretariat is getting too efficient :-( I just reposted the I-D. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 09:22:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17HLQD00094 for ipng-dist; Wed, 7 Feb 2001 09:21:26 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17HLH200085 for ; Wed, 7 Feb 2001 09:21:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05794 for ; Wed, 7 Feb 2001 09:21:16 -0800 (PST) Received: from alpha.dante.org.uk (alpha.dante.org.uk [193.63.211.19]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01024 for ; Wed, 7 Feb 2001 10:21:10 -0700 (MST) Received: from eilat.dante.org.uk ([193.63.211.55] helo=eilat) by alpha.dante.org.uk with esmtp (Exim 3.12 #4) id 14QYGj-0006uk-00; Wed, 07 Feb 2001 17:20:37 +0000 Message-Id: <4.2.2.20010207171723.04d27ba0@alpha.dante.org.uk> X-Sender: david@alpha.dante.org.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 07 Feb 2001 17:21:35 +0000 To: "D. J. Bernstein" , ipng@sunroof.eng.sun.com From: David Harmelin Subject: Re: The case against A6 and DNAME In-Reply-To: <20010207085616.169.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, In your "AOL committing A6 suicide" scenario, you describe how the protection against poison may break A6 chains. Now, what if AOL did configure verything like this: At 08:56 AM 2/7/01 +0000, D. J. Bernstein wrote: >I recommend that the A6 and DNAME proposals be terminated. I've set up a >web page on this topic: > > http://cr.yp.to/djbdns/killa6.html > >---Dan >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- ___________________________________________________________________ * * David Harmelin Network Engineer * * DANCERT Representative * Francis House * 112 Hills Road Tel +44 1223 302992 * Cambridge CB2 1PQ Fax +44 1223 303005 D A N T E United Kingdom WWW http://www.dante.net ____________________________________________________________________ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 09:43:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17Hfkf00170 for ipng-dist; Wed, 7 Feb 2001 09:41:46 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17HfX200162 for ; Wed, 7 Feb 2001 09:41:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13610 for ; Wed, 7 Feb 2001 09:41:33 -0800 (PST) Received: from alpha.dante.org.uk (alpha.dante.org.uk [193.63.211.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27537 for ; Wed, 7 Feb 2001 09:41:32 -0800 (PST) Received: from eilat.dante.org.uk ([193.63.211.55] helo=eilat) by alpha.dante.org.uk with esmtp (Exim 3.12 #4) id 14QYYu-00070E-00; Wed, 07 Feb 2001 17:39:24 +0000 Message-Id: <4.2.2.20010207172304.04d35390@alpha.dante.org.uk> X-Sender: david@alpha.dante.org.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 07 Feb 2001 17:40:24 +0000 To: "D. J. Bernstein" , ipng@sunroof.eng.sun.com From: David Harmelin Subject: Re: The case against A6 and DNAME In-Reply-To: <20010207085616.169.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (hm.. apparently hit the wrong button in the previous mail) Dan, In your "AOL committing A6 suicide" scenario, you describe how the protection against poison may break A6 chains. Now, what would happen if AOL did configure everything like this: For its aol.net zone: dns-01.ns.aol.com A6 ... prefix.aol.com dns-02.ns.aol.com A6 ... prefix.aol.com prefix.aol.com A6 For its aol.com zone: dns-01.ns.aol.net A6 ... prefix.aol.net dns-02.ns.aol.net A6 ... prefix.aol.net prefix.aol.net A6 (same prefix1) My point is, if poison is susceptible of breaking A6 chains, DNS admins (possibly enforced by the DNS server implementation) should make sure that locally, A6 chains are defined under the same domain. In the case above, dns-01.ns.aol.com and dns-01.ns.aol.net could even lead to the same IPv6 address, if AOL wants to maintain their .net and .com servers on the same machine. Now it does require more records to define/maintain/.. Best regards, DH. At 08:56 AM 2/7/01 +0000, D. J. Bernstein wrote: >I recommend that the A6 and DNAME proposals be terminated. I've set up a >web page on this topic: > > http://cr.yp.to/djbdns/killa6.html > >---Dan >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- ___________________________________________________________________ * * David Harmelin Network Engineer * * DANCERT Representative * Francis House * 112 Hills Road Tel +44 1223 302992 * Cambridge CB2 1PQ Fax +44 1223 303005 D A N T E United Kingdom WWW http://www.dante.net ____________________________________________________________________ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 10:05:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17I43i00238 for ipng-dist; Wed, 7 Feb 2001 10:04:03 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17I3s200231 for ; Wed, 7 Feb 2001 10:03:54 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13165 for ; Wed, 7 Feb 2001 10:03:45 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21527 for ; Wed, 7 Feb 2001 10:03:33 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f17I3Vg28173 for ; Wed, 7 Feb 2001 12:03:31 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 7 Feb 2001 12:03:31 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <1PCJFZ4N>; Wed, 7 Feb 2001 11:58:22 -0600 Message-ID: To: brian@hursley.ibm.com, kre@munnari.OZ.AU Cc: paul@francis.com, ipng@sunroof.eng.sun.com Subject: RE: another renumbering question Date: Wed, 7 Feb 2001 11:53:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I disagree that we can assume any site will have two face DNS. Thats a bad assumption. /jim > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday,February 07,2001 10:19 AM > To: Robert Elz > Cc: Paul Francis; ipng@sunroof.eng.sun.com > Subject: Re: another renumbering question > > > Once you *know* that a host has a site local address, the > address selection draft tells you when to use it. I've always > assumed that they would be in the DNS along with global addresses. > Presumably large sites will be running two-faced DNS anyway, so > these addresses will never go outside. > > Brian > > Robert Elz wrote: > > > > Date: Tue, 6 Feb 2001 16:24:23 -0800 > > From: "Paul Francis" > > Message-ID: <006b01c0909c$528dda60$1300a8c0@dellchan> > > > > | But I can't recall how it is a host decides when > another host can be reached > > | via a site-local address, nor can I find where I read that text. > > > > This is still one of life's mysteries I think - several ideas have > > been floated, but nothing yet committed to a draft that I'm > aware of. > > > > The include placing the site locals in the DNS, and having clients > > do a match on the global addresses to see if the site local should > > refer to the same site (one that finds no attraction to me at all). > > > > And having the client send from its site local addr (so the > packet cannot > > leave the site) to the remote global addr an ICMP saying > "tell me your > > addresses", and receiving a list that includes the site > locals for the > > destination (or receiving an ICMP error indicating an > attempt to cross > > the site boundary with a site local source addr). (If the > source doesn't > > have, or doesn't want to use, its site local addr, then > there's no point > > doing any of this, may as well just use global addr of the > dest a well). > > This one I like - it adds a small delay in communications > the first time > > a connection is attempted to a new node (only for > connections initiated, > > responses would never do this) but that is bounded by the > RTT to the edge > > of the site, which is usually of the order of a couple of ms. > > > > kre > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 10:09:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17I8qo00275 for ipng-dist; Wed, 7 Feb 2001 10:08:53 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17I8h200268; Wed, 7 Feb 2001 10:08:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19918; Wed, 7 Feb 2001 10:08:43 -0800 (PST) Received: from [207.77.157.2] ([207.77.157.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA28327; Wed, 7 Feb 2001 10:08:42 -0800 (PST) Received: from MAIL by [207.77.157.2] via smtpd (for saturn.Sun.COM [192.9.25.2]) with SMTP; 7 Feb 2001 18:08:43 UT Received: from pc80 [192.168.1.80] by mail.targetlogistics.com (SMTPD32-6.05) id AF1923D010A; Wed, 07 Feb 2001 10:08:25 -0800 Message-ID: <001701c09130$fd020680$5001a8c0@targetlogistics.com> From: "Ed McKnight" To: "David Harmelin" , Cc: References: <4.2.2.20010207171723.04d27ba0@alpha.dante.org.uk> Subject: How do I opt out of this group Date: Wed, 7 Feb 2001 10:08:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "David Harmelin" To: "D. J. Bernstein" ; Sent: Wednesday, February 07, 2001 9:21 AM Subject: Re: The case against A6 and DNAME > Dan, > > In your "AOL committing A6 suicide" scenario, you describe how the > protection against poison may break A6 chains. > > Now, what if AOL did configure verything like this: > > > At 08:56 AM 2/7/01 +0000, D. J. Bernstein wrote: > >I recommend that the A6 and DNAME proposals be terminated. I've set up a > >web page on this topic: > > > > http://cr.yp.to/djbdns/killa6.html > > > >---Dan > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > ___________________________________________________________________ > * * David Harmelin Network Engineer > * * DANCERT Representative > * Francis House > * 112 Hills Road Tel +44 1223 302992 > * Cambridge CB2 1PQ Fax +44 1223 303005 > D A N T E United Kingdom WWW http://www.dante.net > ____________________________________________________________________ > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 10:14:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17IDjt00318 for ipng-dist; Wed, 7 Feb 2001 10:13:45 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17IDW200309 for ; Wed, 7 Feb 2001 10:13:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24623 for ; Wed, 7 Feb 2001 10:13:32 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA28578 for ; Wed, 7 Feb 2001 11:13:31 -0700 (MST) Received: (qmail 8368 invoked by uid 1001); 7 Feb 2001 18:13:50 -0000 Date: 7 Feb 2001 18:13:50 -0000 Message-ID: <20010207181350.31162.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: The case against A6 and DNAME References: <20010207085616.169.qmail@cr.yp.to> <4.2.2.20010207172304.04d35390@alpha.dante.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Harmelin writes: > dns-01.ns.aol.com A6 ... prefix.aol.com > dns-02.ns.aol.com A6 ... prefix.aol.com > prefix.aol.com A6 Right. In-bailiwick A6 records don't trigger the reliability problems. But then why bother with A6? Use AAAA. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 10:28:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17IQke00406 for ipng-dist; Wed, 7 Feb 2001 10:26:46 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17IQa200399 for ; Wed, 7 Feb 2001 10:26:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20702 for ; Wed, 7 Feb 2001 10:26:36 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06042 for ; Wed, 7 Feb 2001 10:26:35 -0800 (PST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA35012; Wed, 7 Feb 2001 13:26:28 -0500 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA36452; Wed, 7 Feb 2001 13:26:31 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id NAA27416; Wed, 7 Feb 2001 13:24:34 -0500 Message-Id: <200102071824.NAA27416@rotala.raleigh.ibm.com> To: Atsushi Onoe cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 over IEEE1394 In-Reply-To: Message from Atsushi Onoe of "Wed, 07 Feb 2001 18:33:28 +0900." <200102070933.f179XSO05095@duplo.sm.sony.co.jp> Date: Wed, 07 Feb 2001 13:24:34 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Atsushi Onoe writes: > Similarly, we, authors, would like to change the text of IPv6 over IEEE1394 > as follows: > | 9. IPv6 MULTICAST > | > | By default, all best-effort IPv6 multicast MUST use asynchronous > | stream packets whose channel number is equal to the channel field > | from the BROADCAST_CHANNEL register. In particular, datagrams > | addressed to all-nodes multicast addresses, all-routers multicast > | addresses, and solicited-node multicast addresses [AARCH] MUST use > | the default channel specified by the BROADCAST_CHANNEL register. > | > | Best-effort IPv6 multicast for other multicast group addresses may > | utilize a different channel number if such a channel number is > | allocated and advertised prior to use, by a multicast channel > | allocation protocol (MCAP), as described in [IP1394]. The > | implementors are encouraged to use this protocol when transmitting > | high-rate multicast streams. When a node wishes to receive multicast > | data addressed to other than all-nodes multicast addresses, all- > | routers multicast addresses, and solicited-node multicast addresses, > | it MUST confirm if the channel mapping between a multicast group > | address and a channel number exists using MCAP, as described in "9.3 > | Multicast Receive" in [IP1394]. > | > | The MCAP 'type' value for IPv6 group address descriptor is {to be > | assigned by IANA}. I think this text is much better. It is clear now that all nodes must implement at least enough of the MCAP protocol to properly process receives from channels other than the broadcast. Send-only nodes (do they exist?) could presumably not implement any of MCAP and still be compliant. Is this the intent? Or is the intent really to require it for both senders and receivers, but then encourage senders to actually use MCAP? One of the things that is unspecified in RFC 2734 is when to allocate a separate multicast channel and when to use the broadcast one. I gather that experimentation/experience is needed in this space. One other nit. I would suggest changing one sentence as follows: > | Best-effort IPv6 multicast for other multicast group addresses may > | utilize a different channel number if such a channel number is > | allocated and advertised prior to use, by a multicast channel s/by a/by the/ I.e., there is only one such protocol, and it is MCAP. > | allocation protocol (MCAP), as described in [IP1394]. The Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 11:19:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17JHcF00582 for ipng-dist; Wed, 7 Feb 2001 11:17:38 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17JHT200575 for ; Wed, 7 Feb 2001 11:17:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05501 for ; Wed, 7 Feb 2001 11:17:28 -0800 (PST) Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA24864 for ; Wed, 7 Feb 2001 11:17:28 -0800 (PST) Received: (cpmta 1891 invoked from network); 7 Feb 2001 11:17:27 -0800 Received: from unknown (HELO dellchan) (208.135.49.132) by smtp.francis.com (209.228.32.71) with SMTP; 7 Feb 2001 11:17:27 -0800 X-Sent: 7 Feb 2001 19:17:27 GMT Message-ID: <003101c0913a$a52267c0$1300a8c0@dellchan> From: "Paul Francis" To: "Brian E Carpenter" Cc: References: <1542.981523356@brandenburg.cs.mu.OZ.AU> <3A816765.F7069C25@hursley.ibm.com> Subject: Re: another renumbering question Date: Wed, 7 Feb 2001 11:17:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Once you *know* that a host has a site local address, the > address selection draft tells you when to use it. I've always > assumed that they would be in the DNS along with global addresses. > Presumably large sites will be running two-faced DNS anyway, so > these addresses will never go outside. > The other think I recall, though, is that somehow the reason for using site-local addresses is explicitly to avoid using two-faced DNS. (If one were using two-faced DNS, then the better approach would be to use some kind of globally-unique but non-ISP assigned prefix. You'd use this prefix for internal traffic only, but since it is globally unique, you wouldn't have the renumbering problem you have when using site-local addresses when you merge two sites.) PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 11:34:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17JX2600651 for ipng-dist; Wed, 7 Feb 2001 11:33:02 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17JWr200644 for ; Wed, 7 Feb 2001 11:32:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05700 for ; Wed, 7 Feb 2001 11:32:53 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18069 for ; Wed, 7 Feb 2001 11:32:52 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA71866; Wed, 7 Feb 2001 11:32:34 -0800 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA18532; Wed, 7 Feb 2001 11:32:12 -0800 Message-ID: <3A81A240.8DA0E111@hursley.ibm.com> Date: Wed, 07 Feb 2001 13:30:08 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jim.Bound@nokia.com CC: kre@munnari.OZ.AU, paul@francis.com, ipng@sunroof.eng.sun.com Subject: Re: another renumbering question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I didn't mean to say it is required. But I think it is so common these days that it's fair to regard it as normal for large intranets. Brian Jim.Bound@nokia.com wrote: > > I disagree that we can assume any site will have two face DNS. Thats a bad > assumption. > /jim > > > -----Original Message----- > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday,February 07,2001 10:19 AM > > To: Robert Elz > > Cc: Paul Francis; ipng@sunroof.eng.sun.com > > Subject: Re: another renumbering question > > > > > > Once you *know* that a host has a site local address, the > > address selection draft tells you when to use it. I've always > > assumed that they would be in the DNS along with global addresses. > > Presumably large sites will be running two-faced DNS anyway, so > > these addresses will never go outside. > > > > Brian > > > > Robert Elz wrote: > > > > > > Date: Tue, 6 Feb 2001 16:24:23 -0800 > > > From: "Paul Francis" > > > Message-ID: <006b01c0909c$528dda60$1300a8c0@dellchan> > > > > > > | But I can't recall how it is a host decides when > > another host can be reached > > > | via a site-local address, nor can I find where I read that text. > > > > > > This is still one of life's mysteries I think - several ideas have > > > been floated, but nothing yet committed to a draft that I'm > > aware of. > > > > > > The include placing the site locals in the DNS, and having clients > > > do a match on the global addresses to see if the site local should > > > refer to the same site (one that finds no attraction to me at all). > > > > > > And having the client send from its site local addr (so the > > packet cannot > > > leave the site) to the remote global addr an ICMP saying > > "tell me your > > > addresses", and receiving a list that includes the site > > locals for the > > > destination (or receiving an ICMP error indicating an > > attempt to cross > > > the site boundary with a site local source addr). (If the > > source doesn't > > > have, or doesn't want to use, its site local addr, then > > there's no point > > > doing any of this, may as well just use global addr of the > > dest a well). > > > This one I like - it adds a small delay in communications > > the first time > > > a connection is attempted to a new node (only for > > connections initiated, > > > responses would never do this) but that is bounded by the > > RTT to the edge > > > of the site, which is usually of the order of a couple of ms. > > > > > > kre > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 11:58:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17JvLo00749 for ipng-dist; Wed, 7 Feb 2001 11:57:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17JvC200742 for ; Wed, 7 Feb 2001 11:57:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09782 for ; Wed, 7 Feb 2001 11:57:12 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27194 for ; Wed, 7 Feb 2001 11:57:11 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f17JvAg13959 for ; Wed, 7 Feb 2001 13:57:10 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 7 Feb 2001 13:57:10 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS67GA>; Wed, 7 Feb 2001 13:57:10 -0600 Message-ID: To: brian@hursley.ibm.com, Jim.Bound@nokia.com Cc: kre@munnari.OZ.AU, paul@francis.com, ipng@sunroof.eng.sun.com Subject: RE: another renumbering question Date: Wed, 7 Feb 2001 13:47:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Common where? Yes for firewalls and extranets I agree. But that is not the same paradigm as two face dns for sitelocal addresses as an implementation. Two different beasts all together. And the world is not good today to with all the NAT and Tunnels it is horrible we should be careful to not propogate such behavior whenever possible with IPv6. /jim > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday,February 07,2001 2:30 PM > To: Jim.Bound@nokia.com > Cc: kre@munnari.OZ.AU; paul@francis.com; ipng@sunroof.eng.sun.com > Subject: Re: another renumbering question > > > I didn't mean to say it is required. But I think it is so > common these days that > it's fair to regard it as normal for large intranets. > > Brian > > Jim.Bound@nokia.com wrote: > > > > I disagree that we can assume any site will have two face > DNS. Thats a bad > > assumption. > > /jim > > > > > -----Original Message----- > > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Wednesday,February 07,2001 10:19 AM > > > To: Robert Elz > > > Cc: Paul Francis; ipng@sunroof.eng.sun.com > > > Subject: Re: another renumbering question > > > > > > > > > Once you *know* that a host has a site local address, the > > > address selection draft tells you when to use it. I've always > > > assumed that they would be in the DNS along with global addresses. > > > Presumably large sites will be running two-faced DNS anyway, so > > > these addresses will never go outside. > > > > > > Brian > > > > > > Robert Elz wrote: > > > > > > > > Date: Tue, 6 Feb 2001 16:24:23 -0800 > > > > From: "Paul Francis" > > > > Message-ID: <006b01c0909c$528dda60$1300a8c0@dellchan> > > > > > > > > | But I can't recall how it is a host decides when > > > another host can be reached > > > > | via a site-local address, nor can I find where I > read that text. > > > > > > > > This is still one of life's mysteries I think - several > ideas have > > > > been floated, but nothing yet committed to a draft that I'm > > > aware of. > > > > > > > > The include placing the site locals in the DNS, and > having clients > > > > do a match on the global addresses to see if the site > local should > > > > refer to the same site (one that finds no attraction to > me at all). > > > > > > > > And having the client send from its site local addr (so the > > > packet cannot > > > > leave the site) to the remote global addr an ICMP saying > > > "tell me your > > > > addresses", and receiving a list that includes the site > > > locals for the > > > > destination (or receiving an ICMP error indicating an > > > attempt to cross > > > > the site boundary with a site local source addr). (If the > > > source doesn't > > > > have, or doesn't want to use, its site local addr, then > > > there's no point > > > > doing any of this, may as well just use global addr of the > > > dest a well). > > > > This one I like - it adds a small delay in communications > > > the first time > > > > a connection is attempted to a new node (only for > > > connections initiated, > > > > responses would never do this) but that is bounded by the > > > RTT to the edge > > > > of the site, which is usually of the order of a couple of ms. > > > > > > > > kre > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home Page: > http://playground.sun.com/ipng > > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 13:31:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17LSgp00956 for ipng-dist; Wed, 7 Feb 2001 13:28:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17LSW200949 for ; Wed, 7 Feb 2001 13:28:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10482 for ; Wed, 7 Feb 2001 13:28:32 -0800 (PST) Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA23546 for ; Wed, 7 Feb 2001 13:28:31 -0800 (PST) Received: (cpmta 28591 invoked from network); 7 Feb 2001 13:28:30 -0800 Received: from unknown (HELO dellchan) (208.135.49.132) by smtp.francis.com (209.228.32.71) with SMTP; 7 Feb 2001 13:28:30 -0800 X-Sent: 7 Feb 2001 21:28:30 GMT Message-ID: <005c01c0914c$ed1cbf00$1300a8c0@dellchan> From: "Paul Francis" To: Cc: References: Subject: Re: another renumbering question Date: Wed, 7 Feb 2001 13:28:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Common where? Yes for firewalls and extranets I agree. But that is not the > same paradigm as two face dns for sitelocal addresses as an implementation. > Two different beasts all together. And the world is not good today to with > all the NAT and Tunnels it is horrible we should be careful to not propogate > such behavior whenever possible with IPv6. > So Jim, in the absense of two-faced DNS how do you think a host should decide whether it should use site-local for another host, or do you think using site-local addresses is a bad idea? PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 14:52:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17Mom901100 for ipng-dist; Wed, 7 Feb 2001 14:50:48 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17Moc201093 for ; Wed, 7 Feb 2001 14:50:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29723 for ; Wed, 7 Feb 2001 14:50:34 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17470 for ; Wed, 7 Feb 2001 14:50:33 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA26904; Wed, 7 Feb 2001 14:50:25 -0800 Received: from hursley.ibm.com (lig32-225-115-81.us.lig-dial.ibm.com [32.225.115.81]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA20472; Wed, 7 Feb 2001 14:50:20 -0800 Message-ID: <3A81CB87.16435A4F@hursley.ibm.com> Date: Wed, 07 Feb 2001 16:26:15 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jim.Bound@nokia.com CC: kre@munnari.OZ.AU, paul@francis.com, ipng@sunroof.eng.sun.com Subject: Re: another renumbering question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Common because of firewalls, even without NATs which I hate as much as you. Why would any enterprise publish the A record of internalserver.example.com outside the firewall? But this is a bit beside the point of Paul's question. Brian Jim.Bound@nokia.com wrote: > > Common where? Yes for firewalls and extranets I agree. But that is not the > same paradigm as two face dns for sitelocal addresses as an implementation. > Two different beasts all together. And the world is not good today to with > all the NAT and Tunnels it is horrible we should be careful to not propogate > such behavior whenever possible with IPv6. > > /jim > > > -----Original Message----- > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday,February 07,2001 2:30 PM > > To: Jim.Bound@nokia.com > > Cc: kre@munnari.OZ.AU; paul@francis.com; ipng@sunroof.eng.sun.com > > Subject: Re: another renumbering question > > > > > > I didn't mean to say it is required. But I think it is so > > common these days that > > it's fair to regard it as normal for large intranets. > > > > Brian > > > > Jim.Bound@nokia.com wrote: > > > > > > I disagree that we can assume any site will have two face > > DNS. Thats a bad > > > assumption. > > > /jim > > > > > > > -----Original Message----- > > > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > Sent: Wednesday,February 07,2001 10:19 AM > > > > To: Robert Elz > > > > Cc: Paul Francis; ipng@sunroof.eng.sun.com > > > > Subject: Re: another renumbering question > > > > > > > > > > > > Once you *know* that a host has a site local address, the > > > > address selection draft tells you when to use it. I've always > > > > assumed that they would be in the DNS along with global addresses. > > > > Presumably large sites will be running two-faced DNS anyway, so > > > > these addresses will never go outside. > > > > > > > > Brian > > > > > > > > Robert Elz wrote: > > > > > > > > > > Date: Tue, 6 Feb 2001 16:24:23 -0800 > > > > > From: "Paul Francis" > > > > > Message-ID: <006b01c0909c$528dda60$1300a8c0@dellchan> > > > > > > > > > > | But I can't recall how it is a host decides when > > > > another host can be reached > > > > > | via a site-local address, nor can I find where I > > read that text. > > > > > > > > > > This is still one of life's mysteries I think - several > > ideas have > > > > > been floated, but nothing yet committed to a draft that I'm > > > > aware of. > > > > > > > > > > The include placing the site locals in the DNS, and > > having clients > > > > > do a match on the global addresses to see if the site > > local should > > > > > refer to the same site (one that finds no attraction to > > me at all). > > > > > > > > > > And having the client send from its site local addr (so the > > > > packet cannot > > > > > leave the site) to the remote global addr an ICMP saying > > > > "tell me your > > > > > addresses", and receiving a list that includes the site > > > > locals for the > > > > > destination (or receiving an ICMP error indicating an > > > > attempt to cross > > > > > the site boundary with a site local source addr). (If the > > > > source doesn't > > > > > have, or doesn't want to use, its site local addr, then > > > > there's no point > > > > > doing any of this, may as well just use global addr of the > > > > dest a well). > > > > > This one I like - it adds a small delay in communications > > > > the first time > > > > > a connection is attempted to a new node (only for > > > > connections initiated, > > > > > responses would never do this) but that is bounded by the > > > > RTT to the edge > > > > > of the site, which is usually of the order of a couple of ms. > > > > > > > > > > kre > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > IETF IPng Working Group Mailing List > > > > > IPng Home Page: > > http://playground.sun.com/ipng > > > > > FTP archive: > > ftp://playground.sun.com/pub/ipng > > > > > Direct all administrative requests to > > majordomo@sunroof.eng.sun.com > > > > > > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 15:29:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f17NRm401147 for ipng-dist; Wed, 7 Feb 2001 15:27:48 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f17NRb201140; Wed, 7 Feb 2001 15:27:37 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01729; Wed, 7 Feb 2001 15:27:38 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13515; Wed, 7 Feb 2001 15:27:29 -0800 (PST) Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.1/8.11.1) with ESMTP id f17NR3N10655; Thu, 8 Feb 2001 10:27:06 +1100 (EST) (envelope-from marka@nominum.com) Message-Id: <200102072327.f17NR3N10655@drugs.dv.isc.org> To: "Ed McKnight" Cc: "David Harmelin" , majordomo@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com From: Mark.Andrews@nominum.com Subject: Re: How do I opt out of this group In-reply-to: Your message of "Wed, 07 Feb 2001 10:08:35 -0800." <001701c09130$fd020680$5001a8c0@targetlogistics.com> Date: Thu, 08 Feb 2001 10:27:03 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Someone hand me a clue bat. Read the bottom of this message. Mark > > ----- Original Message ----- > From: "David Harmelin" > To: "D. J. Bernstein" ; > Sent: Wednesday, February 07, 2001 9:21 AM > Subject: Re: The case against A6 and DNAME > > > > Dan, > > > > In your "AOL committing A6 suicide" scenario, you describe how the > > protection against poison may break A6 chains. > > > > Now, what if AOL did configure verything like this: > > > > > > At 08:56 AM 2/7/01 +0000, D. J. Bernstein wrote: > > >I recommend that the A6 and DNAME proposals be terminated. I've set up a > > >web page on this topic: > > > > > > http://cr.yp.to/djbdns/killa6.html > > > > > >---Dan > > >-------------------------------------------------------------------- > > >IETF IPng Working Group Mailing List > > >IPng Home Page: http://playground.sun.com/ipng > > >FTP archive: ftp://playground.sun.com/pub/ipng > > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > > >-------------------------------------------------------------------- > > > > ___________________________________________________________________ > > * * David Harmelin Network Engineer > > * * DANCERT Representative > > * Francis House > > * 112 Hills Road Tel +44 1223 302992 > > * Cambridge CB2 1PQ Fax +44 1223 303005 > > D A N T E United Kingdom WWW http://www.dante.net > > ____________________________________________________________________ > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 17:02:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1810RH01268 for ipng-dist; Wed, 7 Feb 2001 17:00:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1810G201261 for ; Wed, 7 Feb 2001 17:00:16 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22644 for ; Wed, 7 Feb 2001 17:00:16 -0800 (PST) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [195.224.76.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA18021 for ; Wed, 7 Feb 2001 17:00:13 -0800 (PST) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14QfRU-0007t0-00 (Debian); Thu, 08 Feb 2001 01:00:12 +0000 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14QfRT-0006On-00 (Debian); Thu, 08 Feb 2001 01:00:11 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14977.61337.913723.260473@davenant.relativity.greenend.org.uk> Date: Thu, 8 Feb 2001 01:00:09 +0000 (GMT) To: ipng@sunroof.eng.sun.com Subject: Re: The case against A6 and DNAME Newsgroups: chiark.mail.ietf.ipng In-Reply-To: <20010207085616.169.qmail@cr.yp.to> References: <20010207085616.169.qmail@cr.yp.to> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk D. J. Bernstein writes ("The case against A6 and DNAME"): > I recommend that the A6 and DNAME proposals be terminated. I've set up a > web page on this topic: > > http://cr.yp.to/djbdns/killa6.html As I've stated before, I strongly agree. I asked here what the purpose of A6 and DNAME are, and the end result has been that we're told that they're a fancy macro scheme to save zone administrators having to write trivial perl scripts. Ian. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 17:04:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18138a01290 for ipng-dist; Wed, 7 Feb 2001 17:03:08 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1812t201283 for ; Wed, 7 Feb 2001 17:02:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00751 for ; Wed, 7 Feb 2001 17:02:56 -0800 (PST) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [195.224.76.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22827 for ; Wed, 7 Feb 2001 17:02:55 -0800 (PST) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14QfU5-0007w2-00 (Debian); Thu, 08 Feb 2001 01:02:54 +0000 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14QfU5-0006Pm-00 (Debian); Thu, 08 Feb 2001 01:02:53 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14977.61500.974264.291464@davenant.relativity.greenend.org.uk> Date: Thu, 8 Feb 2001 01:02:52 +0000 (GMT) To: ipng@sunroof.eng.sun.com Subject: Bitstring labels, the rationale X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm obviously missing something here, so perhaps someone could enlighten me with an appropriate reference. I'm sure that this must have been discussed previously on ipng when bitstring labels were first invented, but my searches of the archives aren't turning up the goods. Could someone please explain briefly why the nybble-based reverse lookup wasn't considered adequate and/or provide a reference into the ipng archives ? Thanks, Ian. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 18:00:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f181wt201379 for ipng-dist; Wed, 7 Feb 2001 17:58:55 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f181wj201369 for ; Wed, 7 Feb 2001 17:58:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03531 for ; Wed, 7 Feb 2001 17:58:45 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00683 for ; Wed, 7 Feb 2001 17:58:45 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f181wig15535 for ; Wed, 7 Feb 2001 19:58:44 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 7 Feb 2001 19:58:44 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <1PCJGAJN>; Wed, 7 Feb 2001 19:53:35 -0600 Message-ID: To: ian@davenant.greenend.org.uk, ipng@sunroof.eng.sun.com Subject: RE: The case against A6 and DNAME Date: Wed, 7 Feb 2001 19:48:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk nicely put. Or we are told. This was already discussed before. I was here Dan's postulate argument and the idea of perl scripts was not discussed before. regards, /jim > -----Original Message----- > From: ext Ian Jackson [mailto:ian@davenant.greenend.org.uk] > Sent: Wednesday,February 07,2001 8:00 PM > To: ipng@sunroof.eng.sun.com > Subject: Re: The case against A6 and DNAME > > > D. J. Bernstein writes ("The case against A6 and DNAME"): > > I recommend that the A6 and DNAME proposals be terminated. > I've set up a > > web page on this topic: > > > > http://cr.yp.to/djbdns/killa6.html > > As I've stated before, I strongly agree. I asked here what the > purpose of A6 and DNAME are, and the end result has been that we're > told that they're a fancy macro scheme to save zone administrators > having to write trivial perl scripts. > > Ian. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 18:27:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f182PZ601495 for ipng-dist; Wed, 7 Feb 2001 18:25:35 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f182PQ201488 for ; Wed, 7 Feb 2001 18:25:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA06396 for ; Wed, 7 Feb 2001 18:25:26 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10134 for ; Wed, 7 Feb 2001 18:25:26 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f182Qow05887 for ; Wed, 7 Feb 2001 20:26:50 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 7 Feb 2001 20:24:54 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS7AT4>; Wed, 7 Feb 2001 20:24:54 -0600 Message-ID: To: paul@francis.com, Jim.Bound@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: another renumbering question Date: Wed, 7 Feb 2001 20:15:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hello paul (long time since we have talked), > > Common where? Yes for firewalls and extranets I agree. > But that is not > the > > same paradigm as two face dns for sitelocal addresses as an > implementation. > > Two different beasts all together. And the world is not > good today to > with > > all the NAT and Tunnels it is horrible we should be careful to not > propogate > > such behavior whenever possible with IPv6. > > > > So Jim, in the absense of two-faced DNS how do you think a host should > decide whether it should use site-local for another host, or > do you think > using site-local addresses is a bad idea? > Its no secret I think site-local addresses are a bad idea and have not decided how to even find something good about them in the book I am writing about IPv6. But we are stuck with them and we need to use them very carefully and put limitations on there use like we do handguns in the U.S. or have health warnings for them for users like the sign I have in the back of my woods "Nevermind the Dog beware of the Owner". They should only be exposed within a site. They should never be used as a source address to any dst address of greater scope under any circumstances. If we could get all to follow these simple precepts they may not poison the innocent users adopting IPv6 who are duped to use them under the guise of the ill-begotten mantra of dynamic renumbering, who should be able to use global IPv6 addresses without ever having to use anything else for peer to peer application communications. But the solution I would provide to a customer if I was an IPv6 Consultant who insisted on using them is to not permit multisited servers across site boundaries for DNS at all. Any multisited DNS servers (or DHCPv6 servers) should never be deployed and support site-local addresses as RRs or IP addresses for assignment. If a server is multisited (wire to two different site logical points) it only supports global thingees. This just eliminates the problem. I do think site-local addresses may be useful for traffic engineering or routing exchanges within a site or multisite boundary but that is work for further study. But for peer to peer apps end-2-end, etc for applications folks run their business on they are unacceptable just so folks have renumbering. The business and administrative trade-offs are not worth and also I could show same customer how to renumber their network with global IPv6 addresses with tools and specs we have today so saying there useful for renumbering is bogus for me. But as an engineer who builds products I will have to support this garbage in the IPv6 architecture just like abusive tunneling protocols and NAT in IPv4. But this garbage should not be propogated to customers servers that are multisited. Using the firewall and NAT argument is naive and not the same. I know this from building shipping products and to support gateway mechanics at one point in a network in a controlled box at the ingress/egress point of the Intranet is far far different than supporting multisited servers across many sites within an Intranet and control it. In theory and 10,000 foot level discussions and maybe on some powerpoint weak architecture slideware it appears to the the same but down where the grunts live building server software and maintaing state machines for the database and shipping this stuff its not the same thing at all. regards, /jim regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 19:01:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f182wZ501571 for ipng-dist; Wed, 7 Feb 2001 18:58:35 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f182wQ201564 for ; Wed, 7 Feb 2001 18:58:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA17613 for ; Wed, 7 Feb 2001 18:58:26 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06423 for ; Wed, 7 Feb 2001 18:58:25 -0800 (PST) Received: from yuri.dns.microsoft.com ([172.30.236.11]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 7 Feb 2001 18:29:11 -0800 Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Wed, 7 Feb 2001 18:30:01 -0800 content-class: urn:content-classes:message Subject: RE: The case against A6 and DNAME MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 7 Feb 2001 18:30:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4643.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The case against A6 and DNAME Thread-Index: AcCRayq8tS4RvlW+Rmm0Pn7mWT1MnAACAsNg From: "Christian Huitema" To: X-OriginalArrivalTime: 08 Feb 2001 02:30:01.0522 (UTC) FILETIME=[09A38120:01C09177] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f182wR201565 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think we are hearing the same argument over and over again, so let's repeat the other side of the story: 1) Perl script don't help you if you must compute RSA signatures for 10,000 records -- or 10 millions. Having to sign one record instead of 10,000, on the other hand, is very beneficial. 2) If your site has 4 prefixes and 10,000 hosts, then A6 allows you to have four times less DNS records to handle. 3) With A6, you can exercize "site redirection" by publishing short lived A6 records for your site, while leaving the host and server records unchanged. The argument in the page is essentially an argument against dependency loops. The dependency loop occurs when one needs to contact a nameserver in order to get the address of that same nameserver. The problem is aggravated by "anti-poison" protections that essentially prevent serving cached records from domains for which the local server is not authoritative. May I observe that if "zone administrators (could) write trivial perl scripts", then they could just has well write a trivial perl script that checks for dependency loops? In any case, it is fairly easy to write reasonable guidelines on how to use the technology without creating loops -- the AOL example is a great way to explain what to do and what not to do. As for deprecating or otherwise removing standards, we have a clear IETF process. A standard progresses if it is implemented and used, and if we can demonstrate successful inter-operation between independent implementations. Let's just follow the process... -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 19:14:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f183CC701598 for ipng-dist; Wed, 7 Feb 2001 19:12:12 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f183Ba201591 for ; Wed, 7 Feb 2001 19:11:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14831 for ; Wed, 7 Feb 2001 19:11:35 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA24183 for ; Wed, 7 Feb 2001 19:11:35 -0800 (PST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Feb 2001 19:11:33 -0800 (Pacific Standard Time) Received: by inet-imc-04.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <1PNPFRJA>; Wed, 7 Feb 2001 19:11:37 -0800 Message-ID: From: Brian Zill To: "'Brian E Carpenter'" , Jim.Bound@nokia.com Cc: kre@munnari.OZ.AU, paul@francis.com, ipng@sunroof.eng.sun.com Subject: RE: another renumbering question Date: Wed, 7 Feb 2001 19:12:27 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik's draft doesn't require a two-faced DNS. If I recall correctly, you simply don't use the site-local addresses unless you recognize the global prefix as being in your site (which you know from site-prefix advertisements). --Brian > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, 07 February, 2001 11:30 > To: Jim.Bound@nokia.com > Cc: kre@munnari.OZ.AU; paul@francis.com; ipng@sunroof.eng.sun.com > Subject: Re: another renumbering question > > > I didn't mean to say it is required. But I think it is so > common these days that > it's fair to regard it as normal for large intranets. > > Brian > > Jim.Bound@nokia.com wrote: > > > > I disagree that we can assume any site will have two face > DNS. Thats a bad > > assumption. > > /jim > > > > > -----Original Message----- > > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Wednesday,February 07,2001 10:19 AM > > > To: Robert Elz > > > Cc: Paul Francis; ipng@sunroof.eng.sun.com > > > Subject: Re: another renumbering question > > > > > > > > > Once you *know* that a host has a site local address, the > > > address selection draft tells you when to use it. I've always > > > assumed that they would be in the DNS along with global addresses. > > > Presumably large sites will be running two-faced DNS anyway, so > > > these addresses will never go outside. > > > > > > Brian > > > > > > Robert Elz wrote: > > > > > > > > Date: Tue, 6 Feb 2001 16:24:23 -0800 > > > > From: "Paul Francis" > > > > Message-ID: <006b01c0909c$528dda60$1300a8c0@dellchan> > > > > > > > > | But I can't recall how it is a host decides when > > > another host can be reached > > > > | via a site-local address, nor can I find where I > read that text. > > > > > > > > This is still one of life's mysteries I think - several > ideas have > > > > been floated, but nothing yet committed to a draft that I'm > > > aware of. > > > > > > > > The include placing the site locals in the DNS, and > having clients > > > > do a match on the global addresses to see if the site > local should > > > > refer to the same site (one that finds no attraction to > me at all). > > > > > > > > And having the client send from its site local addr (so the > > > packet cannot > > > > leave the site) to the remote global addr an ICMP saying > > > "tell me your > > > > addresses", and receiving a list that includes the site > > > locals for the > > > > destination (or receiving an ICMP error indicating an > > > attempt to cross > > > > the site boundary with a site local source addr). (If the > > > source doesn't > > > > have, or doesn't want to use, its site local addr, then > > > there's no point > > > > doing any of this, may as well just use global addr of the > > > dest a well). > > > > This one I like - it adds a small delay in communications > > > the first time > > > > a connection is attempted to a new node (only for > > > connections initiated, > > > > responses would never do this) but that is bounded by the > > > RTT to the edge > > > > of the site, which is usually of the order of a couple of ms. > > > > > > > > kre > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home Page: > http://playground.sun.com/ipng > > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 19:21:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f183K2p01617 for ipng-dist; Wed, 7 Feb 2001 19:20:02 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f183Jo201610 for ; Wed, 7 Feb 2001 19:19:51 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16516 for ; Wed, 7 Feb 2001 19:19:50 -0800 (PST) Received: from marduk.litech.org (gale.cs.cornell.edu [128.84.154.54]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA13496 for ; Wed, 7 Feb 2001 19:19:46 -0800 (PST) Received: from lutchann by marduk.litech.org with local (Exim 3.20 #3) id 14QhcV-0005El-00 for ipng@sunroof.eng.sun.com; Wed, 07 Feb 2001 22:19:43 -0500 Date: Wed, 7 Feb 2001 22:19:43 -0500 From: Nathan Lutchansky To: ipng@sunroof.eng.sun.com Subject: Re: The case against A6 and DNAME Message-ID: <20010207221943.A18000@litech.org> References: <20010207085616.169.qmail@cr.yp.to> <14977.61337.913723.260473@davenant.relativity.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14977.61337.913723.260473@davenant.relativity.greenend.org.uk>; from ian@davenant.greenend.org.uk on Thu, Feb 08, 2001 at 01:00:09AM +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Feb 08, 2001 at 01:00:09AM +0000, Ian Jackson wrote: > D. J. Bernstein writes ("The case against A6 and DNAME"): > > I recommend that the A6 and DNAME proposals be terminated. I've set up a > > web page on this topic: > > > > http://cr.yp.to/djbdns/killa6.html > > As I've stated before, I strongly agree. I asked here what the > purpose of A6 and DNAME are, and the end result has been that we're > told that they're a fancy macro scheme to save zone administrators > having to write trivial perl scripts. FWIW, I agree too. The DNS system is already struggling with too many poorly-configured zones and too much gluelessness to handle increasing indirection by two or three fold. The argument that A6 avoids signature problems with DNSSEC does not provide a suitable incentive to adopt A6, as a renumbering event is likely to require significant administrative work anyway, albeit less than IPv4 renumbering. However, if A6 and DNAME become the standard when IPv6 takes off commercially, either it will work or it won't. If it causes problems, as Dan predicts, people will simply revert to AAAA records in their zones. Unlike NS/MX indirection, there is an alternative to A6/DNAME. -Nathan -- +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 19:32:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f183UN101636 for ipng-dist; Wed, 7 Feb 2001 19:30:23 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f183UE201629 for ; Wed, 7 Feb 2001 19:30:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17690 for ; Wed, 7 Feb 2001 19:30:14 -0800 (PST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10158 for ; Wed, 7 Feb 2001 19:30:14 -0800 (PST) Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.11.0) id f183U5U05377; Wed, 7 Feb 2001 19:30:05 -0800 From: Bill Manning Message-Id: <200102080330.f183U5U05377@zed.isi.edu> Subject: Re: Bitstring labels, the rationale To: ian@davenant.greenend.org.uk (Ian Jackson) Date: Wed, 7 Feb 2001 19:30:05 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <14977.61500.974264.291464@davenant.relativity.greenend.org.uk> from "Ian Jackson" at Feb 08, 2001 01:02:52 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % I'm obviously missing something here, so perhaps someone could % enlighten me with an appropriate reference. I'm sure that this must % have been discussed previously on ipng when bitstring labels were % first invented, but my searches of the archives aren't turning up the % goods. % % Could someone please explain briefly why the nybble-based reverse % lookup wasn't considered adequate and/or provide a reference into the % ipng archives ? % % Thanks, % Ian. First off, I don't think this was initally held in the IPng wg. As a DNS activity, this was bounced around in precursor WGs to the existant DNSEXT mismash. There was some expectation that IPv6 could/ought to be able to be CIDRised and there was no desire to extend the abomination that is RFC 2317. Two proposals were floated after the Memphis IETF and the selected proposal became RFC 2673. In some sense, its OBE based on the IPv6 addressing conventions that have evolved after RFC 2673 was released. Still, we have a very powerful tool... but I'm not sure it has a practical use anymore. -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 19:34:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f183X7F01654 for ipng-dist; Wed, 7 Feb 2001 19:33:07 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f183Wo201640 for ; Wed, 7 Feb 2001 19:32:50 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17953 for ; Wed, 7 Feb 2001 19:32:49 -0800 (PST) Received: from starfruit.itojun.org (kame204.kame.net [203.178.141.204]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11225 for ; Wed, 7 Feb 2001 19:32:48 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 7BC337E2A; Thu, 8 Feb 2001 12:32:17 +0900 (JST) To: Brian Zill Cc: ipng@sunroof.eng.sun.com In-reply-to: bzill's message of Wed, 07 Feb 2001 19:12:27 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: another renumbering question From: Jun-ichiro itojun Hagino Date: Thu, 08 Feb 2001 12:32:17 +0900 Message-Id: <20010208033217.7BC337E2A@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Erik's draft doesn't require a two-faced DNS. If I recall correctly, you >simply don't use the site-local addresses unless you recognize the global >prefix as being in your site (which you know from site-prefix >advertisements). if i understand correctly, Erik's draft requires (or a "should") every resolver to implement Eric's way of identifying local/remote sitelocal peers on DNS. if a naive client implementation (without support for Eric's draft) queries DNS and got site-local address from remote, the client will try to contact the address in its own site, to get no response. I understand that Eric's draft is an additional MUST to IPv6 nodes, if we want it to get deployed. i'm not really sure if we can do it at this stage. at least BIND4/8/9(lwres) do not seem to implement it. it is rather unlucky, but two-faced DNS server is easier to deploy (since it only impacts server side, not resolver side) (to clarify: it matters only if you want to resolve site-locals in your site by DNS. if you just want site-locals for admin purposes like router renumber, you don't really need to populate site-locals in your DNS database) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 19:40:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f183dAm01672 for ipng-dist; Wed, 7 Feb 2001 19:39:10 -0800 (PST) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f183d1201665 for ; Wed, 7 Feb 2001 19:39:01 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA28563; Wed, 7 Feb 2001 22:39:01 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.10.2) with ESMTP id f183cx903649; Wed, 7 Feb 2001 22:38:59 -0500 (EST) Message-Id: <200102080338.f183cx903649@thunk.east.sun.com> From: Bill Sommerfeld To: "Christian Huitema" cc: ipng@sunroof.eng.sun.com Subject: Re: The case against A6 and DNAME In-reply-to: Your message of "Wed, 07 Feb 2001 18:30:01 PST." Reply-to: sommerfeld@east.sun.com Date: Wed, 07 Feb 2001 22:38:59 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The problem is aggravated by "anti-poison" protections that essentially prevent serving cached records from domains for which the local server is not authoritative. With DNSSEC and signed entries, it doesn't matter who gives you the data, it's who signs it.. I haven't looked at it that closely but it would seem at first glance that appropriate use of SIG records could allow for some relaxation of the "anti-poisoning" checks (though SIG's are somewhat bulky). - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 19:47:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f183kR901695 for ipng-dist; Wed, 7 Feb 2001 19:46:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f183kJ201688 for ; Wed, 7 Feb 2001 19:46:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24411 for ; Wed, 7 Feb 2001 19:46:19 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04728 for ; Wed, 7 Feb 2001 19:46:18 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f183kIg17750 for ; Wed, 7 Feb 2001 21:46:18 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 7 Feb 2001 21:46:18 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS7A62>; Wed, 7 Feb 2001 21:46:18 -0600 Message-ID: To: huitema@exchange.microsoft.com, ipng@sunroof.eng.sun.com Subject: RE: The case against A6 and DNAME Date: Wed, 7 Feb 2001 21:36:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk uh..thats two independent implementations at a minimum. I am hearing two complain BIND and DENT. The complexity for what you say is to complex. So what we need to do is revisit it. So we are following the process sir. /jim > -----Original Message----- > From: ext Christian Huitema [mailto:huitema@exchange.microsoft.com] > Sent: Wednesday,February 07,2001 9:30 PM > To: ipng@sunroof.eng.sun.com > Subject: RE: The case against A6 and DNAME > > > I think we are hearing the same argument over and over again, so let's > repeat the other side of the story: > > 1) Perl script don't help you if you must compute RSA signatures for > 10,000 records -- or 10 millions. Having to sign one record instead of > 10,000, on the other hand, is very beneficial. > > 2) If your site has 4 prefixes and 10,000 hosts, then A6 allows you to > have four times less DNS records to handle. > > 3) With A6, you can exercize "site redirection" by publishing short > lived A6 records for your site, while leaving the host and server > records unchanged. > > The argument in the page is essentially an argument against dependency > loops. The dependency loop occurs when one needs to contact a > nameserver > in order to get the address of that same nameserver. The problem is > aggravated by "anti-poison" protections that essentially > prevent serving > cached records from domains for which the local server is not > authoritative. May I observe that if "zone administrators > (could) write > trivial perl scripts", then they could just has well write a trivial > perl script that checks for dependency loops? In any case, it > is fairly > easy to write reasonable guidelines on how to use the > technology without > creating loops -- the AOL example is a great way to explain what to do > and what not to do. > > As for deprecating or otherwise removing standards, we have a > clear IETF > process. A standard progresses if it is implemented and used, > and if we > can demonstrate successful inter-operation between independent > implementations. Let's just follow the process... > > -- Christian Huitema > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 19:53:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f183qC301713 for ipng-dist; Wed, 7 Feb 2001 19:52:12 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f183q0201706 for ; Wed, 7 Feb 2001 19:52:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24363 for ; Wed, 7 Feb 2001 19:52:00 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA23462 for ; Wed, 7 Feb 2001 19:52:00 -0800 (PST) Received: (qmail 12368 invoked by uid 1001); 8 Feb 2001 03:52:20 -0000 Date: 8 Feb 2001 03:52:20 -0000 Message-ID: <20010208035220.10594.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: The cost of signing records References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk System administrators insist on being able to change their records with at most a few days notice---typically one day. See my ``Extremely long TTLs'' message for further discussion of this point. With DNSSEC, those records would have to be signed again every day. It is not acceptable from a security perspective to have signatures last longer than this; otherwise an attacker would be able to interfere with changes by forging an old DNS response under the old signature. Occasional renumbering is not going to add noticeably to this cost. In fact, unless renumbering has to happen with less than a day's notice, the extra cost is zero. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 20:32:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f184Ua901779 for ipng-dist; Wed, 7 Feb 2001 20:30:36 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f184UO201772 for ; Wed, 7 Feb 2001 20:30:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA23808 for ; Wed, 7 Feb 2001 20:30:24 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA18662 for ; Wed, 7 Feb 2001 21:30:24 -0700 (MST) Received: (qmail 4473 invoked by uid 1001); 8 Feb 2001 04:30:45 -0000 Date: 8 Feb 2001 04:30:45 -0000 Message-ID: <20010208043045.7364.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: The case against A6 and DNAME References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema writes: > A standard progresses if it is implemented and used, and if we > can demonstrate successful inter-operation between independent > implementations. Let's just follow the process... AAAA has independent interoperable implementations, but I don't see you supporting it. I don't see you saying ``follow the process'' when some people say that AAAA is deprecated in favor of A6 and should go away. Well, I'm saying that A6 and DNAME should go away. The relevant process is specified in section 6.4 of RFC 2026. > 2) If your site has 4 prefixes and 10,000 hosts, then A6 allows you to > have four times less DNS records to handle. So what? It's a tiny database either way. > 3) With A6, you can exercize "site redirection" by publishing short > lived A6 records for your site, while leaving the host and server > records unchanged. I can't figure out what practical problem you're talking about. ``Site indirection'' normally refers to a bunch of http-equiv="refresh" web pages pointing to a new location. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 22:23:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f186Lk601850 for ipng-dist; Wed, 7 Feb 2001 22:21:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f186Lb201843 for ; Wed, 7 Feb 2001 22:21:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA13071 for ; Wed, 7 Feb 2001 22:21:21 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA06974 for ; Wed, 7 Feb 2001 23:21:17 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id NAA10427; Thu, 8 Feb 2001 13:20:35 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f186MYP01894; Thu, 8 Feb 2001 13:22:39 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: Jim.Bound@nokia.com, paul@francis.com, ipng@sunroof.eng.sun.com Subject: Re: another renumbering question In-reply-to: Your message of "Wed, 07 Feb 2001 16:26:15 CST." <3A81CB87.16435A4F@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Feb 2001 13:22:34 +0700 Message-ID: <1892.981613354@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 07 Feb 2001 16:26:15 -0600 From: Brian E Carpenter Message-ID: <3A81CB87.16435A4F@hursley.ibm.com> | Common because of firewalls, even without NATs which I hate as much as you. Firewalls are no reason for a two faced DNS. Those are forced upon us by NAT, because of the re-use of addresses. With IPv6 we will have no need to re-use addresses, and so no reason to bother with two faced DNS (which isn't to say that they may not still be people who would prefer to use it). | Why would any enterprise publish the A record of internalserver.example.com | outside the firewall? Why wouldn't they? Doing so at least allows others to know that they have been given the correct name of the server, and simply cannot communicate with it, rather than getting "no such host" from the DNS, and then making wondering what the cause of that was (maybe the name I was supposed to use was internal-server.example.com, or maybe it was internal.server.example.com, or maybe it was intrnlsrvr.example.com and was just read out over the phone as "internal server"). In any case, two faced DNS is simply not an option to solve the site local issue - no matter how many large enterprises might happen to use the things. The most benefit for site locals will come to those who renumber most often, not those who hardly ever do. And those who renumber most often are the very small sites. What's more, those are the sites who hardly ever run their own DNS, it is mostly run for them (outside of their net) by their ISP. Two faced DNS simply doesn't scale to that kind of situation. Eric's draft at least has the feature that it is mostly feasible, and (save a couple of hard cases) could possibly work, at the cost of up to twice as many addresses to return from the DNS [Aside on another issue: using A6 would certainly help there, with the assumption that all the internal addressing is the same for the site locals and globals, only one more "upper level" A6 prefix record needs to be added to cover a whole site of site-local addresses...] Two faced DNS has nothing going for it at all, other than that it kind of looks like what we do now for NAT. And that's what we should be trying to avoid, not entrench. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 22:24:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f186NiH01877 for ipng-dist; Wed, 7 Feb 2001 22:23:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f186NN201863 for ; Wed, 7 Feb 2001 22:23:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA07415 for ; Wed, 7 Feb 2001 22:23:23 -0800 (PST) Received: from fdpnmailgw5.dpn.deere.com ([192.43.73.42]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA26363 for ; Wed, 7 Feb 2001 22:23:22 -0800 (PST) Received: from 192.43.73.42 by fdpnmailgw5.dpn.deere.com with SMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 07 Feb 2001 20:54:13 -0600 X-Server-Uuid: 2d3b7162-db1d-11d3-b8ee-0008c7dfb6f1 Received: from 192.9.25.1 by fdpnmailgw2.dpn.deere.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Tue, 06 Feb 2001 18:30:30 -0600 X-Server-Uuid: 2d3b7162-db1d-11d3-b8ee-0008c7dfb6f1 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA28662; Tue, 6 Feb 2001 16:30:19 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88] ) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08808; Tue, 6 Feb 2001 16:27:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com ( 8.11.2+Sun/8.11.2) id f170OKg29120 for ipng-dist; Tue, 6 Feb 2001 16: 24:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f170OA229113 for ; Tue, 6 Feb 2001 16:24:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08215 for ; Tue, 6 Feb 2001 16:24:11 -0800 (PST) Received: from c000.snv.cp.net (c000-h002.c000.snv.cp.net [209.228.32.66]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA15245 for ; Tue, 6 Feb 2001 16:24:11 -0800 (PST) Received: (cpmta 8094 invoked from network); 6 Feb 2001 16:24:10 -0800 Received: from unknown (HELO dellchan) (208.135.49.132) by smtp.francis.com (209.228.32.66) with SMTP; 6 Feb 2001 16:24:10 -0800 X-Sent: 7 Feb 2001 00:24:10 GMT Message-ID: <006b01c0909c$528dda60$1300a8c0@dellchan> From: "Paul Francis" To: ipng@sunroof.eng.sun.com References: <034BEFD03799D411A59F00508BDF75465B6979@esealnt448.al.sw.ericsson.se> <3A7F3365.9DBB43A6@Nokia.com> <3A7FC35D.B3568780@era.ericsson.se> Subject: another renumbering question Date: Tue, 6 Feb 2001 16:24:23 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-WSS-ID: 169CD5DF163709-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I recall having once read in some internet-draft that, in order not to disrupt intra-site communications during renumbering, that intra-site communications should use site-local addresses. But I can't recall how it is a host decides when another host can be reached via a site-local address, nor can I find where I read that text. Can anyone point me to the IDs/RFCs that talk about this? Thanks, PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 7 22:25:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f186Nhh01876 for ipng-dist; Wed, 7 Feb 2001 22:23:43 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f186NM201861 for ; Wed, 7 Feb 2001 22:23:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA07409 for ; Wed, 7 Feb 2001 22:23:22 -0800 (PST) Received: from fdpnmailgw5.dpn.deere.com ([192.43.73.42]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA26357 for ; Wed, 7 Feb 2001 22:23:21 -0800 (PST) Received: from 192.43.73.42 by fdpnmailgw5.dpn.deere.com with SMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 07 Feb 2001 20:39:29 -0600 X-Server-Uuid: 2d3b7162-db1d-11d3-b8ee-0008c7dfb6f1 Received: from 192.9.25.1 by fdpnmailgw2.dpn.deere.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Mon, 05 Feb 2001 17:17:36 -0600 X-Server-Uuid: 2d3b7162-db1d-11d3-b8ee-0008c7dfb6f1 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16435; Mon, 5 Feb 2001 15:17:15 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88] ) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26953; Mon, 5 Feb 2001 15:16:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com ( 8.11.2+Sun/8.11.2) id f15NDu127129 for ipng-dist; Mon, 5 Feb 2001 15: 13:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f15NDh227122 for ; Mon, 5 Feb 2001 15:13:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15733 for ; Mon, 5 Feb 2001 15:13:43 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06345 for ; Mon, 5 Feb 2001 16:13:42 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA13134; Mon, 5 Feb 2001 15:13:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com ( 8.11.0/8.11.0-DARKSTAR) id f15NDcF17844; Mon, 5 Feb 2001 15:13:38 -0800 X-Virus-Scanned: Mon, 5 Feb 2001 15:13:38 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdBatH4b; Mon, 05 Feb 2001 15:13:34 PST Message-ID: <3A7F33A0.27D39D01@Kniveton.com> Date: Mon, 05 Feb 2001 15:13:36 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, mobile-ip@standards.nortelnetworks.com Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] X-WSS-ID: 169CD96B156619-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 04:20:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18CJ4N03202 for ipng-dist; Thu, 8 Feb 2001 04:19:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18CIo203193 for ; Thu, 8 Feb 2001 04:18:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14135 for ; Thu, 8 Feb 2001 04:18:43 -0800 (PST) Received: from un.cct.ydc.co.jp (ydcspingw.ydc.co.jp [202.33.211.252]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA27728 for ; Thu, 8 Feb 2001 05:18:41 -0700 (MST) Received: from odin.cct.ydc.co.jp ([10.21.0.196]) by un.cct.ydc.co.jp (8.9.1+3.1W/3.7W) with SMTP id VAA27002 for ; Thu, 8 Feb 2001 21:22:00 +0900 (JST) Date: Thu, 8 Feb 2001 21:18:37 +0900 From: Yukiyo Akisada To: ipng@sunroof.eng.sun.com Subject: TAHI IPv6 Interoperability Test Packages Message-Id: <20010208211837.1cf6c16a.yukiyo_akisada@ydc.co.jp> X-Mailer: Sylpheed version 0.4.61 (GTK+ 1.2.8; Linux 2.4.0; i686) Organization: YDC Corporation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi there, TAHI Project has released the IPv6 Interoperability Test Packages at the following web site: http://www.tahi.org/ Changes from the previous release of the IPv6 Interoperability Test Packages: - Does not support FreeBSD2.2.8 any more. - Ported : FreeBSD 4.X - pa (Packet Analyze Tools) support MIP6 - echo6 (IPv6 UDP echo program) rewrite all code based on ping6 - rpdump (IPv6 Routing Protocol Packet Analyze Tool) rewirte all code by C. use shared library libpcap. support RIPv1/v2, Cluster list attribute of BGP UPDATE and IPv4 BGP-4 packets. show attribue flags of BGP UPDATE. convert port numbers to names. many bugs fix. - and all interoperability test utilities are included. Thanks, --- Yukiyo Akisada @ TAHI Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 06:15:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18EDcc03311 for ipng-dist; Thu, 8 Feb 2001 06:13:38 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18EDR203304 for ; Thu, 8 Feb 2001 06:13:27 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24314 for ; Thu, 8 Feb 2001 06:13:27 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18489 for ; Thu, 8 Feb 2001 06:13:27 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA05267; Thu, 8 Feb 2001 08:13:19 -0600 (CST) Message-Id: <200102081413.IAA05267@gungnir.fnal.gov> To: Ian Jackson Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: The case against A6 and DNAME In-reply-to: Your message of Thu, 08 Feb 2001 01:00:09 GMT. <14977.61337.913723.260473@davenant.relativity.greenend.org.uk> Date: Thu, 08 Feb 2001 08:13:19 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > purpose of A6 and DNAME are, and the end result has been that we're > told that they're a fancy macro scheme to save zone administrators > having to write trivial perl scripts. Oh, who told "us" that? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 06:38:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18EZTd03338 for ipng-dist; Thu, 8 Feb 2001 06:35:29 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18EZG203331 for ; Thu, 8 Feb 2001 06:35:17 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26041 for ; Thu, 8 Feb 2001 06:35:09 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28460 for ; Thu, 8 Feb 2001 06:35:08 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA05394; Thu, 8 Feb 2001 08:35:06 -0600 (CST) Message-Id: <200102081435.IAA05394@gungnir.fnal.gov> To: Nathan Lutchansky Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: The case against A6 and DNAME In-reply-to: Your message of Wed, 07 Feb 2001 22:19:43 EST. <20010207221943.A18000@litech.org> Date: Thu, 08 Feb 2001 08:35:06 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > However, if A6 and DNAME become the standard when IPv6 takes off > commercially, either it will work or it won't. If it causes problems, as > Dan predicts, people will simply revert to AAAA records in their zones. You don't even need to worry about the transition reaching the point where some servers or clients drop support for AAAA -- A6 records can be use like AAAA with one waste byte. And as long as you don't ditch DNAME + binary labels, you can put your reverse data in the same zone. Now there's a job for a perl script. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 07:49:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18FmBA03388 for ipng-dist; Thu, 8 Feb 2001 07:48:11 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18Fm2203381 for ; Thu, 8 Feb 2001 07:48:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05605 for ; Thu, 8 Feb 2001 07:48:02 -0800 (PST) Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08049 for ; Thu, 8 Feb 2001 07:47:58 -0800 (PST) Received: from duplo.sm.sony.co.jp (onoe@localhost) by onoe2.sm.sony.co.jp (8.9.0/3.7W) with ESMTP id AAA06577; Fri, 9 Feb 2001 00:47:56 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.2/8.10.2) id f18Flp809382; Fri, 9 Feb 2001 00:47:51 +0900 (JST) Date: Fri, 9 Feb 2001 00:47:51 +0900 (JST) From: Atsushi Onoe Message-Id: <200102081547.f18Flp809382@duplo.sm.sony.co.jp> To: narten@raleigh.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 over IEEE1394 In-Reply-To: Your message of "Wed, 07 Feb 2001 13:24:34 -0500" <200102071824.NAA27416@rotala.raleigh.ibm.com> References: <200102071824.NAA27416@rotala.raleigh.ibm.com> X-Mailer: Cue version 0.6 (010116-0953/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think this text is much better. It is clear now that all nodes must > implement at least enough of the MCAP protocol to properly process > receives from channels other than the broadcast. Send-only nodes (do > they exist?) could presumably not implement any of MCAP and still be > compliant. Is this the intent? Or is the intent really to require it > for both senders and receivers, but then encourage senders to actually > use MCAP? Send-only nodes MUST use MCAP to determine whether or not the multicast group has been already mapped to a channel other than the default broadcast channel. So the text should be as follows: | high-rate multicast streams. When a node wishes to receive or | transmit multicast data addressed to other than all-nodes multicast | addresses, all-routers multicast addresses, and solicited-node | multicast addresses, it MUST confirm if the channel mapping between | a multicast group address and a channel number exists using MCAP, | as described in "9. IP MULTICAST" in [IP1394]. Only a node which never send nor receive any multicast group address other than all-nodes multicast addresses, all-routers multicast addresses, and solicited-node multicast addresses, can omit to implement MCAP. > One of the things that is unspecified in RFC 2734 is when to > allocate a separate multicast channel and when to use the broadcast > one. I gather that experimentation/experience is needed in this space. Since it doesn't affect interoperability, it can be left to implementation for now, IMO. Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 08:32:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18GUlR03466 for ipng-dist; Thu, 8 Feb 2001 08:30:47 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18GUc203459 for ; Thu, 8 Feb 2001 08:30:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11383 for ; Thu, 8 Feb 2001 08:30:22 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26452 for ; Thu, 8 Feb 2001 09:30:21 -0700 (MST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA15304; Thu, 8 Feb 2001 08:29:54 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA18378; Thu, 8 Feb 2001 08:29:49 -0800 Message-ID: <3A82C8F6.E14F02F8@hursley.ibm.com> Date: Thu, 08 Feb 2001 10:27:34 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Robert Elz CC: Jim.Bound@nokia.com, paul@francis.com, ipng@sunroof.eng.sun.com Subject: Re: another renumbering question References: <1892.981613354@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > | Why would any enterprise publish the A record of internalserver.example.com > | outside the firewall? > > Why wouldn't they? Truly, you are out of touch with the way large corporate intranets are run. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 08:35:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18GYbR03487 for ipng-dist; Thu, 8 Feb 2001 08:34:37 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18GYS203480 for ; Thu, 8 Feb 2001 08:34:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20394 for ; Thu, 8 Feb 2001 08:34:28 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06368 for ; Thu, 8 Feb 2001 08:34:12 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f18GZbw18823 for ; Thu, 8 Feb 2001 10:35:37 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 8 Feb 2001 10:34:12 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS71Y8>; Thu, 8 Feb 2001 10:34:12 -0600 Message-ID: To: kre@munnari.OZ.AU, brian@hursley.ibm.com Cc: Jim.Bound@nokia.com, paul@francis.com, ipng@sunroof.eng.sun.com Subject: RE: another renumbering question Date: Thu, 8 Feb 2001 10:24:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Firewalls are no reason for a two faced DNS. Those are > forced upon us by > NAT, because of the re-use of addresses. With IPv6 we will > have no need > to re-use addresses, and so no reason to bother with two > faced DNS (which > isn't to say that they may not still be people who would > prefer to use it). good point at dec we did this with our net 16 address exactly and two face dns was not required. so the firewall argument is bogus here. /jim > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 08:36:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18GZL303496 for ipng-dist; Thu, 8 Feb 2001 08:35:21 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18GZ5203489 for ; Thu, 8 Feb 2001 08:35:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15155 for ; Thu, 8 Feb 2001 08:35:04 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07272 for ; Thu, 8 Feb 2001 08:35:04 -0800 (PST) Received: from yuri.dns.microsoft.com ([172.30.236.11]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 8 Feb 2001 08:04:23 -0800 Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Thu, 8 Feb 2001 08:05:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4643.0 content-class: urn:content-classes:message Subject: =?iso-8859-1?Q?RE=3A_The_case_against_na=EFve_anti-poison_=28was_A6_and?= =?iso-8859-1?Q?_DNAME=29?= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 8 Feb 2001 08:05:12 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?iso-8859-1?Q?The_case_against_na=EFve_anti-poison_=28was_A6_and_DNAME=29?= Thread-Index: AcCRiGBpqsKaaZeNQsmXJrHkFdLPNwAX5emg From: "Christian Huitema" To: X-OriginalArrivalTime: 08 Feb 2001 16:05:13.0397 (UTC) FILETIME=[EB635650:01C091E8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f18GZ6203490 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk May I observe that most of the issues Dan are rising result from a specific approach to anti-poison, which is to rely strictly on the name hierarchy? I don't know who decided on that approach, but it clearly has the consequence of breaking existing practice, such as name servers located in another domain. That existing practice had been going on for quite a long time -- back in 1988, many of the name servers for "inria.fr" were located in ".edu". There is no mention anywhere that name server have to belong to the same hierarchy as the served domain. So, instead of asking everybody on earth to revise their delegation, it is probably avisable to make the anti-poison code a little bit smarter. Now, this is probably a subject for the DNS group, not IPNG. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 08:38:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18Gbbh03523 for ipng-dist; Thu, 8 Feb 2001 08:37:37 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18GbR203516 for ; Thu, 8 Feb 2001 08:37:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15552 for ; Thu, 8 Feb 2001 08:37:27 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09499 for ; Thu, 8 Feb 2001 08:37:26 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f18GbLg18447 for ; Thu, 8 Feb 2001 10:37:21 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 8 Feb 2001 10:37:21 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <1PCJG172>; Thu, 8 Feb 2001 10:32:12 -0600 Message-ID: To: brian@hursley.ibm.com, kre@munnari.OZ.AU Cc: Jim.Bound@nokia.com, paul@francis.com, ipng@sunroof.eng.sun.com Subject: RE: another renumbering question Date: Thu, 8 Feb 2001 10:27:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk no he is not. I know three large corporations using the fact that they got nice large ipv4 address space and do this in totally secure manner. the evil here is nat your concerned about and site local addresses can cause that evil again. also many of the ietf mantras are getting trashed in the real world. we need to update our mantras. /jim > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday,February 08,2001 11:28 AM > To: Robert Elz > Cc: Jim.Bound@nokia.com; paul@francis.com; ipng@sunroof.eng.sun.com > Subject: Re: another renumbering question > > > Robert Elz wrote: > > > | Why would any enterprise publish the A record of > internalserver.example.com > > | outside the firewall? > > > > Why wouldn't they? > > Truly, you are out of touch with the way large corporate > intranets are run. > > Brian > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 09:01:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18H0Bh03573 for ipng-dist; Thu, 8 Feb 2001 09:00:11 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18H00203566 for ; Thu, 8 Feb 2001 09:00:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23684 for ; Thu, 8 Feb 2001 08:59:58 -0800 (PST) Received: from mochila.martin.fl.us (mochila.martin.fl.us [198.136.32.118]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11144 for ; Thu, 8 Feb 2001 08:59:57 -0800 (PST) Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id LAA14031; Thu, 8 Feb 2001 11:58:26 -0500 (EST) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with SMTP id LAA15847; Thu, 8 Feb 2001 11:57:33 -0500 (EST) Date: Thu, 8 Feb 2001 11:57:33 -0500 (EST) From: Greg Maxwell X-Sender: gmaxwell@da1server To: Brian E Carpenter cc: Robert Elz , Jim.Bound@nokia.com, paul@francis.com, ipng@sunroof.eng.sun.com Subject: Re: another renumbering question In-Reply-To: <3A82C8F6.E14F02F8@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 8 Feb 2001, Brian E Carpenter wrote: > Robert Elz wrote: > > > | Why would any enterprise publish the A record of internalserver.example.com > > | outside the firewall? > > > > Why wouldn't they? > > Truly, you are out of touch with the way large corporate intranets are run. Only because large corporations are out of touch with reality. Such retarded behavior provides them with no additional security, theoritically or practically, no matter what the 'security consultants' sell them on. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 09:07:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18H6n503603 for ipng-dist; Thu, 8 Feb 2001 09:06:49 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18H6c203596 for ; Thu, 8 Feb 2001 09:06:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25328 for ; Thu, 8 Feb 2001 09:06:37 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17350 for ; Thu, 8 Feb 2001 10:06:34 -0700 (MST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id LAA07168 for ; Thu, 8 Feb 2001 11:06:31 -0600 (CST) Message-Id: <200102081706.LAA07168@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: another renumbering question In-reply-to: Your message of Thu, 08 Feb 2001 10:27:24 CST. Date: Thu, 08 Feb 2001 11:06:31 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > Why would any enterprise publish the A record of > > > > internalserver.example.com > > > > outside the firewall? > > > > > > Why wouldn't they? > > > > Truly, you are out of touch with the way large corporate > > intranets are run. > > no he is not. I know three large corporations using the fact that they got > nice large ipv4 address space and do this in totally secure manner. Putting aside who said what, the second person may or may not be out of touch with they way many large (and small) organizational (not just corporate) networks are run, but may just be more *in* touch than those organizations are with what consititutes Real(TM) Security. We here all know that hiding names and addresses isn't "real" security. But it's on a lot of checklists. People with the smarts and backbone to criticize the checklists are often not in the right organizational place to get them changed. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 09:13:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18HBip03625 for ipng-dist; Thu, 8 Feb 2001 09:11:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18HBZ203618 for ; Thu, 8 Feb 2001 09:11:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26209 for ; Thu, 8 Feb 2001 09:11:35 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20269 for ; Thu, 8 Feb 2001 10:11:33 -0700 (MST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA53430; Thu, 8 Feb 2001 09:11:24 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA06716; Thu, 8 Feb 2001 09:11:27 -0800 Message-ID: <3A82D2AF.38159E24@hursley.ibm.com> Date: Thu, 08 Feb 2001 11:09:04 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jim.Bound@nokia.com CC: kre@munnari.OZ.AU, paul@francis.com, ipng@sunroof.eng.sun.com Subject: Re: another renumbering question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I really think you're missing my point, which is that this is nothing to do with NAT; people were hiding internal-only hosts for years before NAT came along, and they always will. This is nothing to do with address space. Your border router doesn't route unsolicited packets to the hidden host and your external DNS doesn't propagate its RRs. Hiding site-local addresses is no different. Brian Jim.Bound@nokia.com wrote: > > no he is not. I know three large corporations using the fact that they got > nice large ipv4 address space and do this in totally secure manner. the > evil here is nat your concerned about and site local addresses can cause > that evil again. also many of the ietf mantras are getting trashed in the > real world. we need to update our mantras. > > /jim > > > -----Original Message----- > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Thursday,February 08,2001 11:28 AM > > To: Robert Elz > > Cc: Jim.Bound@nokia.com; paul@francis.com; ipng@sunroof.eng.sun.com > > Subject: Re: another renumbering question > > > > > > Robert Elz wrote: > > > > > | Why would any enterprise publish the A record of > > internalserver.example.com > > > | outside the firewall? > > > > > > Why wouldn't they? > > > > Truly, you are out of touch with the way large corporate > > intranets are run. > > > > Brian > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 09:18:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18HHKH03651 for ipng-dist; Thu, 8 Feb 2001 09:17:20 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18HHB203644 for ; Thu, 8 Feb 2001 09:17:11 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27247 for ; Thu, 8 Feb 2001 09:17:11 -0800 (PST) Received: from mochila.martin.fl.us (mochila.martin.fl.us [198.136.32.118]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02526 for ; Thu, 8 Feb 2001 09:17:10 -0800 (PST) Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id MAA14283; Thu, 8 Feb 2001 12:16:43 -0500 (EST) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with SMTP id MAA16665; Thu, 8 Feb 2001 12:15:50 -0500 (EST) Date: Thu, 8 Feb 2001 12:15:50 -0500 (EST) From: Greg Maxwell X-Sender: gmaxwell@da1server To: Matt Crawford cc: ipng@sunroof.eng.sun.com Subject: Re: another renumbering question In-Reply-To: <200102081706.LAA07168@gungnir.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 8 Feb 2001, Matt Crawford wrote: [snip] > We here all know that hiding names and addresses isn't "real" > security. But it's on a lot of checklists. People with the smarts > and backbone to criticize the checklists are often not in the right > organizational place to get them changed. .. and there are quite a few 'security professionals' with a vested financial intresting in selling security solution packages that include such useless protections especially once which increase support and maintance expenses. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 09:21:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18HKiB03673 for ipng-dist; Thu, 8 Feb 2001 09:20:44 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18HKZ203666 for ; Thu, 8 Feb 2001 09:20:35 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24005 for ; Thu, 8 Feb 2001 09:20:35 -0800 (PST) From: danziger@pacifier.com Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19391 for ; Thu, 8 Feb 2001 09:20:34 -0800 (PST) Received: from thundar (ip154.hdr1.pacifier.com [216.65.133.154]) by eclipse.pacifier.com (8.11.2/8.11.1) with SMTP id f18HKRE15822 for ; Thu, 8 Feb 2001 09:20:28 -0800 (PST) Message-Id: <3.0.1.32.20010208091808.00696c8c@mail.pacifier.com> X-Sender: danziger@mail.pacifier.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 08 Feb 2001 09:18:08 -0800 To: ipng@sunroof.eng.sun.com Subject: remove Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk remove -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 09:31:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18HUfx03700 for ipng-dist; Thu, 8 Feb 2001 09:30:41 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18HUP203693 for ; Thu, 8 Feb 2001 09:30:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25772 for ; Thu, 8 Feb 2001 09:30:20 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11246 for ; Thu, 8 Feb 2001 09:30:15 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 70B704CE62; Thu, 8 Feb 2001 12:30:13 -0500 (EST) Received: from berkshire.research.att.com (secure.research.att.com [135.207.24.10]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id MAA27293; Thu, 8 Feb 2001 12:30:10 -0500 (EST) Received: from berkshire.research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 4714135C42; Thu, 8 Feb 2001 12:30:06 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: ipng From: "Steven M. Bellovin" To: Jim.Bound@nokia.com Cc: kre@munnari.oz.au, brian@hursley.ibm.com, paul@francis.com, ipng@sunroof.eng.sun.com Subject: Re: another renumbering question Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 08 Feb 2001 12:30:05 -0500 Message-Id: <20010208173006.4714135C42@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Jim.Bound@nok ia.com writes: > > >> >> Firewalls are no reason for a two faced DNS. Those are >> forced upon us by >> NAT, because of the re-use of addresses. With IPv6 we will >> have no need >> to re-use addresses, and so no reason to bother with two >> faced DNS (which >> isn't to say that they may not still be people who would >> prefer to use it). > >good point at dec we did this with our net 16 address exactly and two face >dns was not >required. > >so the firewall argument is bogus here. There are several reasons for using two-faced DNS with firewalls. First, there's the desire to hide inside hosts. A domain name such as myhost.supersecretproject.somecompany.com is rather revealing. Second, there's the risk of DNS cache contamination. DNSSEC will solve that problem, but of course DNSSEC isn't deployed yet. You also tend to need different name servers internally for subdomains -- and hence different NS records -- because internal name servers are inside the firewall, and not reachable from the outside. (The recent set of BIND security holes is ample evidence for the wisdom of this policy. One of the main reasons for firewalls is to shield all the myriad services running on the inside from the consequences of as-yet unknown bugs.) The same can be said of MX records -- I want internal mail to stay internal, but I also don't want externally- originating mail to have to wait for several minutes of futile attempts to contact internal MX designees. You may disagree with some of the above reasons. Lots of folks buy in to some of them, enough that there's a lot of two-faced DNS setups out there, and I don't see anything in v6 that will make them go away. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 09:33:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18HWB203711 for ipng-dist; Thu, 8 Feb 2001 09:32:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18HVt203702 for ; Thu, 8 Feb 2001 09:31:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00610 for ; Thu, 8 Feb 2001 09:31:55 -0800 (PST) Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12321 for ; Thu, 8 Feb 2001 09:31:53 -0800 (PST) Received: from duplo.sm.sony.co.jp (onoe@localhost) by onoe2.sm.sony.co.jp (8.9.0/3.7W) with ESMTP id CAA07848; Fri, 9 Feb 2001 02:31:51 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.2/8.10.2) id f18HVnZ09623; Fri, 9 Feb 2001 02:31:49 +0900 (JST) Date: Fri, 9 Feb 2001 02:31:49 +0900 (JST) From: Atsushi Onoe Message-Id: <200102081731.f18HVnZ09623@duplo.sm.sony.co.jp> To: narten@raleigh.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 over IEEE1394 In-Reply-To: Your message of "Fri, 9 Feb 2001 00:47:51 +0900 (JST)" <200102081547.f18Flp809382@duplo.sm.sony.co.jp> References: <200102081547.f18Flp809382@duplo.sm.sony.co.jp> X-Mailer: Cue version 0.6 (010116-0953/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Send-only nodes MUST use MCAP to determine whether or not the multicast > group has been already mapped to a channel other than the default broadcast > channel. Oops! Sorry, I was wrong. Kenji Fujisawa pointed out that I misread the text in "9.4 Multicast transmit" of RFC2734 (IPv4 over 1394). The above should be read: "If a node wishes to transmit the multicast data to other than default channel, it MUST confirm whether or not the multicast group has been already allocated to the channel." The correct text to be included should be: | When a node wishes to receive multicast data addressed to other | than all-nodes multicast addresses, all-routers multicast addresses, | and solicited-node multicast addresses, it MUST confirm if the | channel mapping between a multicast group address and a channel | number exists using MCAP, as described in "9.3 Multicast Receive" | in [IP1394]. | | The implementation of MCAP is optional for send-only nodes. A node | MAY transmit multicast data addressed to any multicast addresses | into the default broadcast channel regardless of the existing | allocation of the channel. If a node wishes to transmit multicast | data on other than the default channel, it MUST first confirm by | MCAP whether or not a channel number for the group address has been | already allocated. Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 09:44:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18HhI303810 for ipng-dist; Thu, 8 Feb 2001 09:43:18 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18Hh8203803 for ; Thu, 8 Feb 2001 09:43:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02548 for ; Thu, 8 Feb 2001 09:43:07 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08275 for ; Thu, 8 Feb 2001 10:43:06 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f18Hh5g28536 for ; Thu, 8 Feb 2001 11:43:05 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 8 Feb 2001 11:43:05 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS7GBN>; Thu, 8 Feb 2001 11:43:05 -0600 Message-ID: To: brian@hursley.ibm.com, Jim.Bound@nokia.com Cc: kre@munnari.OZ.AU, paul@francis.com, ipng@sunroof.eng.sun.com Subject: RE: another renumbering question Date: Thu, 8 Feb 2001 11:33:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am passing on talking to you on this one we can't seem to connect. I don't agree with you and your chanting mantras and belief systems at me and I am trying to bring you down to the implementation details. site locals will be managed and controlled. as one person I will not advocate them. pretty simple really. good bye on this thread. /jim > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday,February 08,2001 12:09 PM > To: Jim.Bound@nokia.com > Cc: kre@munnari.OZ.AU; paul@francis.com; ipng@sunroof.eng.sun.com > Subject: Re: another renumbering question > > > I really think you're missing my point, which is that this is > nothing to do > with NAT; people were hiding internal-only hosts for years > before NAT came along, > and they always will. This is nothing to do with address > space. Your border > router doesn't route unsolicited packets to the hidden host > and your external > DNS doesn't propagate its RRs. Hiding site-local addresses is > no different. > > Brian > > Jim.Bound@nokia.com wrote: > > > > no he is not. I know three large corporations using the > fact that they got > > nice large ipv4 address space and do this in totally secure > manner. the > > evil here is nat your concerned about and site local > addresses can cause > > that evil again. also many of the ietf mantras are getting > trashed in the > > real world. we need to update our mantras. > > > > /jim > > > > > -----Original Message----- > > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Thursday,February 08,2001 11:28 AM > > > To: Robert Elz > > > Cc: Jim.Bound@nokia.com; paul@francis.com; > ipng@sunroof.eng.sun.com > > > Subject: Re: another renumbering question > > > > > > > > > Robert Elz wrote: > > > > > > > | Why would any enterprise publish the A record of > > > internalserver.example.com > > > > | outside the firewall? > > > > > > > > Why wouldn't they? > > > > > > Truly, you are out of touch with the way large corporate > > > intranets are run. > > > > > > Brian > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 12:45:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18KgP704740 for ipng-dist; Thu, 8 Feb 2001 12:42:25 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18KgF204733 for ; Thu, 8 Feb 2001 12:42:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07682 for ; Thu, 8 Feb 2001 12:42:07 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06402 for ; Thu, 8 Feb 2001 12:42:06 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA27868; Thu, 8 Feb 2001 12:41:57 -0800 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA18658; Thu, 8 Feb 2001 12:42:05 -0800 Message-ID: <3A8303F6.88F78F3C@hursley.ibm.com> Date: Thu, 08 Feb 2001 14:39:18 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Greg Maxwell CC: ipng@sunroof.eng.sun.com Subject: Re: another renumbering question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Did I say people did it for security? Do you really want DNS to contain tens of millions of RRs for unreachable hosts? Brian Greg Maxwell wrote: > > On Thu, 8 Feb 2001, Matt Crawford wrote: > > [snip] > > We here all know that hiding names and addresses isn't "real" > > security. But it's on a lot of checklists. People with the smarts > > and backbone to criticize the checklists are often not in the right > > organizational place to get them changed. > > .. and there are quite a few 'security professionals' with a vested > financial intresting in selling security solution packages that include > such useless protections especially once which increase support and > maintance expenses. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 12:45:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f18KiDB04753 for ipng-dist; Thu, 8 Feb 2001 12:44:13 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f18Ki2204746 for ; Thu, 8 Feb 2001 12:44:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15423 for ; Thu, 8 Feb 2001 12:44:01 -0800 (PST) Received: from mochila.martin.fl.us (mochila.martin.fl.us [198.136.32.118]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19002 for ; Thu, 8 Feb 2001 13:43:59 -0700 (MST) Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id PAA17214; Thu, 8 Feb 2001 15:43:31 -0500 (EST) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with SMTP id PAA27868; Thu, 8 Feb 2001 15:42:39 -0500 (EST) Date: Thu, 8 Feb 2001 15:42:39 -0500 (EST) From: Greg Maxwell X-Sender: gmaxwell@da1server To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: another renumbering question In-Reply-To: <3A8303F6.88F78F3C@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 8 Feb 2001, Brian E Carpenter wrote: [snip] > Do you really want DNS to contain tens of millions of RRs for unreachable hosts? No, I really want people not to break network connectivity for tens of millions of hosts for unreasonable reasons. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 19:39:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f193cTd05137 for ipng-dist; Thu, 8 Feb 2001 19:38:29 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f193cK205130 for ; Thu, 8 Feb 2001 19:38:21 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28496 for ; Thu, 8 Feb 2001 19:38:20 -0800 (PST) Received: from arianne.in.ishoni.com ([164.164.83.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA11990 for ; Thu, 8 Feb 2001 19:38:06 -0800 (PST) Received: from leonoid.ishoni.com (leonoid [192.168.1.12]) by arianne.in.ishoni.com (8.11.2/8.11.2) with ESMTP id f193d7m23390 for ; Fri, 9 Feb 2001 09:09:08 +0530 Received: by LEONOID with Internet Mail Service (5.5.2650.21) id <1LB89DB3>; Fri, 9 Feb 2001 09:08:57 +0530 Message-ID: From: Sujith Kumar To: "'Ipng (E-mail)" Subject: Date: Fri, 9 Feb 2001 09:08:55 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk remove -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 8 19:50:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f193n4j05164 for ipng-dist; Thu, 8 Feb 2001 19:49:04 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f193mt205157 for ; Thu, 8 Feb 2001 19:48:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA00706 for ; Thu, 8 Feb 2001 19:48:54 -0800 (PST) Received: from smtp1b.mail.yahoo.com (smtp3.mail.yahoo.com [128.11.68.135]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA25775 for ; Thu, 8 Feb 2001 19:48:54 -0800 (PST) Received: from ool-18bf4fb3.dyn.optonline.net (HELO yahoo.com) (24.191.79.179) by smtp.mail.vip.suc.yahoo.com with SMTP; 9 Feb 2001 04:56:30 -0000 X-Apparently-From: Message-ID: <3A8368A2.EE312309@yahoo.com> Date: Thu, 08 Feb 2001 22:48:50 -0500 From: Vincent Wright Organization: Wright Enterprises X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sujith Kumar CC: "'Ipng (E-mail)" Subject: Re: References: Content-Type: multipart/mixed; boundary="------------5A3CA266153E151D1B2C5242" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------5A3CA266153E151D1B2C5242 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Your remove request went out to individual members. Please make the request the appropriate way. Sujith Kumar wrote: > remove > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------5A3CA266153E151D1B2C5242 Content-Type: text/x-vcard; charset=us-ascii; name="vmwusa_2000.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Vincent Wright Content-Disposition: attachment; filename="vmwusa_2000.vcf" begin:vcard n:Wright;Vincent tel;fax:801-217-8918 tel;work:203-846-0372 x-mozilla-html:TRUE url:http://card.netscape.com/vmwnow org:Wright Enterprises;Recruitment adr:;;28 Adams Avenue;Norwalk;CT;06851;USA version:2.1 email;internet:vmwusa_2000@yahoo.com title:Recruitment Consultant note;quoted-printable:Yahoo ID: vmwusa_2000=0D=0A877-301-6116 toll free fax/messaging=0D=0AICQ# 97996288=0D=0AMediaRing ID 1398605=0D=0A"Call Today! - Your Career Will THANK You!"=0D=0APlease suggest best times to reach you.=0D=0ANOTE: we offer substantial referral fees for quality professionals ($500 to $15,000) fn:Vincent Wright end:vcard --------------5A3CA266153E151D1B2C5242-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 9 01:11:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1998UH05445 for ipng-dist; Fri, 9 Feb 2001 01:08:31 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1998M205438 for ; Fri, 9 Feb 2001 01:08:22 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29463 for ; Fri, 9 Feb 2001 01:08:21 -0800 (PST) Received: from web3406.mail.yahoo.com (web3406.mail.yahoo.com [204.71.203.60]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA24754 for ; Fri, 9 Feb 2001 01:08:21 -0800 (PST) Message-ID: <20010209090817.17802.qmail@web3406.mail.yahoo.com> Received: from [63.68.248.197] by web3406.mail.yahoo.com; Fri, 09 Feb 2001 01:08:17 PST Date: Fri, 9 Feb 2001 01:08:17 -0800 (PST) From: nilesh modi Subject: is ipv6 supported in linux? To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does linux redhat support ipv6 address ? When i tried to give my network card the ipv6 address , it gave me the error that INET6 not supported . Please guide. Nilesh. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 9 01:36:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f199Ykq05537 for ipng-dist; Fri, 9 Feb 2001 01:34:46 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f199Ya205530 for ; Fri, 9 Feb 2001 01:34:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07030 for ; Fri, 9 Feb 2001 01:34:36 -0800 (PST) Received: from mail.arc.net.my (nagano.arc.net.my [203.115.225.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA00335 for ; Fri, 9 Feb 2001 02:34:34 -0700 (MST) Received: from SEAN1 ([203.115.227.130]) by mail.arc.net.my (Netscape Messaging Server 4.15) with SMTP id G8HH9L00.9E1 for ; Fri, 9 Feb 2001 17:34:33 +0800 Message-ID: <009701c0927b$c66f9cd0$a46ea8c0@SEAN1> From: "Sean Lim" To: Subject: Flow label Date: Fri, 9 Feb 2001 17:36:27 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0094_01C092BE.D4823B00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0094_01C092BE.D4823B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good day, I am a Researcher in NTT MSC , Malaysia . I am working on the = implementation of QOS in IPv6 Network. Is RFC 1809 the latest = information regarding Flow Label in IPv6? What is the latest = development on the usage of the flow label in IPv6. Thanks Sean Lim=20 Researher NTT MSC SDN BHD 43000, Jalan APEC, 63300 Cyberjaya Selangor , Malaysia ------=_NextPart_000_0094_01C092BE.D4823B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good day, I am a Researcher in NTT MSC = , Malaysia .=20 I am working on the implementation of QOS in IPv6 Network. Is RFC 1809 = the=20 latest information regarding Flow Label in IPv6?  What is the=20 latest development on the usage of the flow label in = IPv6. =20 Thanks
 
 
 
 
 
Sean Lim
Researher
NTT MSC SDN BHD
43000, Jalan APEC, 63300 = Cyberjaya
Selangor , Malaysia
 
------=_NextPart_000_0094_01C092BE.D4823B00-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 9 02:41:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f19Add805593 for ipng-dist; Fri, 9 Feb 2001 02:39:39 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f19AdU205586 for ; Fri, 9 Feb 2001 02:39:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA03749 for ; Fri, 9 Feb 2001 02:39:29 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18706 for ; Fri, 9 Feb 2001 02:39:29 -0800 (PST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA28229; Fri, 9 Feb 2001 11:39:20 +0100 (MET) Date: Fri, 9 Feb 2001 11:39:20 +0100 From: Ignatios Souvatzis To: nilesh modi Cc: ipng@sunroof.eng.sun.com Subject: Re: is ipv6 supported in linux? Message-ID: <20010209113920.B28084@theory.cs.uni-bonn.de> Reply-To: ipng@sunroof.eng.sun.com References: <20010209090817.17802.qmail@web3406.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="hHWLQfXTYDoKhP50" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010209090817.17802.qmail@web3406.mail.yahoo.com>; from nilesham38@yahoo.com on Fri, Feb 09, 2001 at 01:08:17AM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 09, 2001 at 01:08:17AM -0800, nilesh modi wrote: > Does linux redhat support ipv6 address ? >=20 >=20 > When i tried to give my network card the ipv6 address > , it gave me the error that INET6 not supported . >=20 >=20 > Please guide. I have no idea myself, but there are links to a few IPv6 on Linux=20 introductions at: http://www.ipv6.org/impl/linux.html I also suggest that you ask your OS vendor (RedHat). Good luck! -is --hHWLQfXTYDoKhP50 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOoPI1DCn4om+4LhpAQHIAwf+JiBcIaM9InV6HPxEtG0YhRLlE+qy27ef sYpihbfpZtWJ0nf199ZsxLokmoO1h2h30XwN0gGQzPrN4Fp2hsH2SkDZjj/CgkEg 9gN7h00xyEzkmcCqUJ0K6aL2xlWs+yiMTmuG2ihMfoAiuHdwg/1IJ3SUuB6v/ubD SPXCdVSdQ6GHb1DRpQ84s16dVIINJumZmN2VXJox1A0LGTAE5T4vZJ94Nwgeh+K5 eMByolPsy9cVYnmDeYtilvvxsFd4MhYDRMgsKdw3D1w+Jf84T76WjbN0XowY+Nkh LSLR5jUNja6aKLRJgkpdvZIAHiKENMw+EUbmWpFlhTjJpAEGsN+0kw== =FlEm -----END PGP SIGNATURE----- --hHWLQfXTYDoKhP50-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 9 04:26:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f19COls05659 for ipng-dist; Fri, 9 Feb 2001 04:24:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f19COb205652 for ; Fri, 9 Feb 2001 04:24:37 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA12158 for ; Fri, 9 Feb 2001 04:24:35 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24509 for ; Fri, 9 Feb 2001 04:24:35 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13887; Fri, 9 Feb 2001 07:24:34 -0500 (EST) Message-Id: <200102091224.HAA13887@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-site-prefixes-05.txt Date: Fri, 09 Feb 2001 07:24:34 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Site prefixes in Neighbor Discovery Author(s) : E. Nordmark Filename : draft-ietf-ipngwg-site-prefixes-05.txt Pages : 22 Date : 08-Feb-01 This document specifies extensions to IPv6 Neighbor Discovery to carry site prefixes. The site prefixes are used to reduce the effect of site renumbering by ensuring that the communication inside a site uses site-local addresses. This protocol requires that all IPv6 implementations, even those that do not implement this protocol, ignore all site-local addresses that they retrieve from the DNS when the AAAA or A6 RRset contain both global and site-local addresses. If the RRset contains only site- local addresses those addresses can be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-site-prefixes-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-site-prefixes-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-site-prefixes-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010208140027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-site-prefixes-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-site-prefixes-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010208140027.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 9 06:53:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f19EpOj06090 for ipng-dist; Fri, 9 Feb 2001 06:51:24 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f19Ep0206083 for ; Fri, 9 Feb 2001 06:51:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03407 for ; Fri, 9 Feb 2001 06:50:59 -0800 (PST) Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13510 for ; Fri, 9 Feb 2001 06:50:58 -0800 (PST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f19En0j01138; Fri, 9 Feb 2001 09:49:01 -0500 Message-Id: <200102091449.f19En0j01138@hygro.adsl.duke.edu> To: "Sean Lim" cc: ipng@sunroof.eng.sun.com Subject: Re: Flow label In-Reply-To: Message from "Sean Lim" of "Fri, 09 Feb 2001 17:36:27 +0800." <009701c0927b$c66f9cd0$a46ea8c0@SEAN1> Date: Fri, 09 Feb 2001 09:49:00 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Good day, I am a Researcher in NTT MSC , Malaysia . I am working on the = > implementation of QOS in IPv6 Network. Is RFC 1809 the latest = > information regarding Flow Label in IPv6? What is the latest = > development on the usage of the flow label in IPv6. Thanks Check the mailing list archives starting around Nov 15, 2000. There was a recent thread on the Flow Label. Having said that, does anyone maintain an archive of this mailing list that is threaded per-message? It would be useful to have such an archive to refer to specific messages, as in this case. Note that I am not asking that the current archive at ftp://playground.sun.com/pub/ipng/mail-archive/ipng.200011 be changed. But a supplemental archive would be a nice value-add. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 9 07:25:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f19FNkK06167 for ipng-dist; Fri, 9 Feb 2001 07:23:46 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f19FNb206160 for ; Fri, 9 Feb 2001 07:23:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25435 for ; Fri, 9 Feb 2001 07:23:37 -0800 (PST) Received: from hotmail.com (f49.law3.hotmail.com [209.185.241.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA20876 for ; Fri, 9 Feb 2001 07:23:37 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 9 Feb 2001 07:23:37 -0800 Received: from 210.214.144.15 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 09 Feb 2001 15:23:36 GMT X-Originating-IP: [210.214.144.15] From: "Sriram Dittakavi" To: ipng@sunroof.eng.sun.com Subject: Information on linux Date: Fri, 09 Feb 2001 20:53:36 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Feb 2001 15:23:37.0025 (UTC) FILETIME=[45D8F310:01C092AC] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i am interested in installing a linux server with redhat 7.0, in my lab and i want t0 experiment for working with IPv6. Please let me know the process through which i can do this. From where can i get all the binaris required. please help me. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 9 08:14:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f19GD2x06287 for ipng-dist; Fri, 9 Feb 2001 08:13:02 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f19GCr206280 for ; Fri, 9 Feb 2001 08:12:53 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08607 for ; Fri, 9 Feb 2001 08:12:53 -0800 (PST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11107 for ; Fri, 9 Feb 2001 08:12:52 -0800 (PST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA11819; Fri, 9 Feb 2001 17:12:37 +0100 (MET) Received: from demchh2msx.icn.siemens.de (root@ss-aladin.mchh.siemens.de [139.21.149.125]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA26833; Fri, 9 Feb 2001 17:12:37 +0100 (MET) Received: from icn.siemens.de (spider.mchh.siemens.de [139.21.37.111]) by demchh2msx.icn.siemens.de (8.9.1/8.9.1) with ESMTP id RAA04485; Fri, 9 Feb 2001 17:12:31 +0100 (MET) Message-ID: <3A8416F2.3B36D636@icn.siemens.de> Date: Fri, 09 Feb 2001 17:12:34 +0100 From: Wilhelm Methfessel Organization: Siemens AG X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sriram Dittakavi CC: ipng@sunroof.eng.sun.com Subject: Re: Information on linux References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sriram Dittakavi wrote: > > i am interested in installing a linux server with redhat 7.0, in my lab and > i want t0 experiment for working with IPv6. Please let me know the process > through which i can do this. From where can i get all the binaris required. > please help me. Are you sure that you want to use redhat 7.0? I did that and found, that the C compiler is broken in a way, that I could't compile a lot of the V6 tools. So I'm now using xinetd and ftpd-BSD compiled on redhat6.2. Wilhelm Methfessel Siemens AG, ICN OI IT 21 E-Mail: Wilhelm.Methfessel@icn.siemens.de Hofmannstrasse 51 Phone: +49 89 722 42351 81359 Muenchen FAX: +49 89 722 23771 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 9 19:51:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1A3o8306717 for ipng-dist; Fri, 9 Feb 2001 19:50:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1A3nv206710 for ; Fri, 9 Feb 2001 19:49:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA00842 for ; Fri, 9 Feb 2001 19:48:54 -0800 (PST) Received: from web3403.mail.yahoo.com (web3403.mail.yahoo.com [204.71.203.57]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA23815 for ; Fri, 9 Feb 2001 19:48:53 -0800 (PST) Message-ID: <20010210034853.29605.qmail@web3403.mail.yahoo.com> Received: from [202.164.96.71] by web3403.mail.yahoo.com; Fri, 09 Feb 2001 19:48:53 PST Date: Fri, 9 Feb 2001 19:48:53 -0800 (PST) From: nilesh modi Subject: implementation of translator To: ipng@sunroof.eng.sun.com Cc: doron.hirsch@SeabridgeNetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I want to know the implementation details of ipv4/ipv6 translator. do i need to use raw socket for accessing network layer? or any other way , please guide. nilesh. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 10 02:50:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1AAnMO06902 for ipng-dist; Sat, 10 Feb 2001 02:49:22 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1AAnD206895 for ; Sat, 10 Feb 2001 02:49:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26319 for ; Sat, 10 Feb 2001 02:49:12 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22835 for ; Sat, 10 Feb 2001 02:49:05 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id RAA24254; Sat, 10 Feb 2001 17:48:26 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1AAmIh03357; Sat, 10 Feb 2001 17:48:25 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: another renumbering question In-reply-to: Your message of "Thu, 08 Feb 2001 14:39:18 CST." <3A8303F6.88F78F3C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Feb 2001 17:48:18 +0700 Message-ID: <3355.981802098@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 08 Feb 2001 14:39:18 -0600 From: Brian E Carpenter Message-ID: <3A8303F6.88F78F3C@hursley.ibm.com> This whole discussion has veered somewhere so far off into left field that it has ceased to become relevant to anything. There's no way the IETF (or ipngwg) is going to mandate two faced DNS for anything - and only that would allow any ipngwg solution which used two faced DNS to make site local addressing work, so that simply isn't going to happen. Beyond that it simply doesn't matter what sites decide, for good or bad, reasons to do on their own networks, if they want to spend lots, and increase maintenance problems, for no rational benefit that I can find - there's no way I can stop them. Nor do I care much. But there's no way you are going to ever convince me to do such a dumb thing... But ... | Do you really want DNS to contain tens of millions of RRs for | unreachable hosts? The short answer to that is "yes". A slightly longer answer is that the DNS would already have all that information if two-faced DNS is how the private namespace is being managed (rather than NIS or something). It is just that some of it isn't being made visible to most of the world. It is still all there. Having it there and visible makes no difference. If I can't reach the host, I'm unlikely to be racing about looking up its name either, so whether those tens of millions of hosts are there & visible or not is going to be irrelevant to me, but they are there anyway (but with more headaches for the site if the site is using two faced DNS to "hide" them). If you can really find a site that is running two faced DNS in order to be nice to the rest of us by keeping the overall DNS size smaller, then give them a plaque for effort, tell them while appreciated, they're wasting their time, and to just let the rest of us ignore their huge local DNS space, they don't need to hide it. That is if you can find anyone doing it for that motive... But can we possibly return to the more relevant question of just how we are going to discover the site local address of a node which is reachable that way, so it can be used... And to give this message just a small amount of on-point content, I don't think the method in Erik's draft will work as is, as - as was pointed out before - it requires all nodes to know the method, and I suspect we have already gone too far with v6 deployment for that. We're already at the stage where only incremental changes can be made now (that's a good thing!) There are a couple of other minor problems as well, but compared to that one, I don't think they matter. So, I suggest that we keep all of the draft, except for the site local addresses in the DNS (other than for isolated sites of course). Instead, when a node has determined that its partner node is in the same site (using the mechanisms from the draft), and if it implements this method, and if it has not been configured (globally, or by the application for this particular connection) to use only global addresses, then have it send an ICMP "tell me your site local addresses" to the partner node, and wait a short time (should be configurable, but let's say bounded at 20ms to give an idea). That packet it sends from its own site-local address. If it gets a response, and the response contains any site local addresses, then it uses (one of) those addresses for the connection (for the packet) (and caches the result for a while as well). If it gets no response, or gets an ICMP "site local source exiting the site" then it simply uses the global address. Most often, what this will do is add one RTT to the startup time for known local nodes, the first time that a connection is to be initiated to the node (incoming connections don't do any of this, only when initiating one, it would likely be done in the "translate name to address" routines - just as Erik postulates). The requirement for this to work, is that all nodes have global addresses, if any nodes at the site do (ie: except for isolated sites, which would simply stick their site-locals in the DNS). Nothing at a connected site can have only a site local address (or there would be nothing to find in the DNS in the first place). [Aside: it doesn't matter if the global address is found in a "private" DNS or the regular global one]. A site local that is found in the DNS ought be treated just as if it was a global address (for the purposes of connection establishment) - that makes isolated sites work transparently (no need for any special config to know if a site is isolated or not), and even allows people to site site locals in their private DNS if they feel inclined. Obviously the "tell me your site local" address would never be used when starting with a site-local. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 10 14:13:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1AMCEm07161 for ipng-dist; Sat, 10 Feb 2001 14:12:14 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1AMBu207145 for ; Sat, 10 Feb 2001 14:11:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17136 for ; Sat, 10 Feb 2001 14:11:56 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24719 for ; Sat, 10 Feb 2001 14:11:56 -0800 (PST) Received: from smtprch2.nortelnetworks.com (erchg0k.us.nortel.com [47.113.64.104]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1AMBD328704; Sat, 10 Feb 2001 17:11:14 -0500 (EST) Received: by smtprch2.nortelnetworks.com (SMI-8.6/SMI-SVR4) id QAA06399; Sat, 10 Feb 2001 16:07:04 -0600 Date: Sat, 10 Feb 2001 16:07:04 -0600 Message-Id: <200102102207.QAA06399@smtprch2.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 10 14:13:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1AMC8V07160 for ipng-dist; Sat, 10 Feb 2001 14:12:08 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1AMBu207147 for ; Sat, 10 Feb 2001 14:11:57 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17146 for ; Sat, 10 Feb 2001 14:11:57 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18684 for ; Sat, 10 Feb 2001 14:11:56 -0800 (PST) Received: from smtprch2.nortelnetworks.com (erchg0k.us.nortel.com [47.113.64.104]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1AMBE328712; Sat, 10 Feb 2001 17:11:14 -0500 (EST) Received: by smtprch2.nortelnetworks.com (SMI-8.6/SMI-SVR4) id QAA06414; Sat, 10 Feb 2001 16:07:05 -0600 Date: Sat, 10 Feb 2001 16:07:05 -0600 Message-Id: <200102102207.QAA06414@smtprch2.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 10 17:28:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1B1Rdo07243 for ipng-dist; Sat, 10 Feb 2001 17:27:39 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1B1RS207236 for ; Sat, 10 Feb 2001 17:27:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25034 for ; Sat, 10 Feb 2001 17:27:28 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA15826 for ; Sat, 10 Feb 2001 18:27:27 -0700 (MST) Received: (qmail 24295 invoked by uid 1001); 11 Feb 2001 01:27:44 -0000 Date: 11 Feb 2001 01:27:44 -0000 Message-ID: <20010211012744.13596.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: The case against naive anti-poison (was A6 and DNAME) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Huitema's assignment of blame is completely incorrect. This is not a subtle issue; there is a fundamental difference between the server knowing addresses and the server not knowing addresses. Let's take his inria.fr example. A cache contacts ns-ext.vix.com, one of the .fr servers, and learns inria.fr NS dns.cs.wisc.edu without the address of dns.cs.wisc.edu. It has to put the query on hold while it looks for the address of dns.cs.wisc.edu. Why doesn't this .fr server provide the address of dns.cs.wisc.edu? Because IT DOES NOT KNOW THE ADDRESS. Huitema is wrong when he says that the current anti-poison mechanism--- clients don't accept .edu records from .fr servers---created this problem. The protocol does not require .fr servers to know the address of dns.cs.wisc.edu! See RFC 1034, end of section 4.2.1. (See also the part of section 5.3.3 that screams yes-we-know-this-design-is-garbage.) Do you think the .fr server should provide the dns.cs.wisc.edu address? That's server-side indirection. It works with current servers and caches if the name is changed from dns.cs.wisc.edu to whatever.ns.inria.fr, as I recommend. The inria.fr server is responsible for copying the address and notifying the .fr server of any changes. Everything works. Of course, with this fix, the name in the NS record serves no purpose. A better protocol would have put the address directly into the NS record: easier for servers, easier for caches, and no reliability problems. These are the same reasons that AAAA is better than A6. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 11 01:21:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1B9JMM07385 for ipng-dist; Sun, 11 Feb 2001 01:19:22 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1B9J8207378 for ; Sun, 11 Feb 2001 01:19:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27478 for ; Sun, 11 Feb 2001 01:19:06 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA18485 for ; Sun, 11 Feb 2001 01:19:03 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA15629; Sun, 11 Feb 2001 16:18:55 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1B9Itx01337; Sun, 11 Feb 2001 16:19:01 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com Subject: Re: The case against naive anti-poison (was A6 and DNAME) In-reply-to: Your message of "11 Feb 2001 01:27:44 GMT." <20010211012744.13596.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Feb 2001 16:18:55 +0700 Message-ID: <1335.981883135@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 11 Feb 2001 01:27:44 -0000 From: "D. J. Bernstein" Message-ID: <20010211012744.13596.qmail@cr.yp.to> | The inria.fr server is responsible for copying the address | and notifying the .fr server of any changes. Everything works. Assuming that the inria.fr server (or management of the server) ever find out about the change. Currently if dns.cs.wisc.edu changes its address, there's nothing the inria.fr people need to do. The change is local to wisc.edu (and the .edu server). With your scheme, every other zone that is hosted by the dns.cs.wisc.edu server has to be notified of the change of address, and all at once they all need to send off to their parent zones DNS updates, to change the addresses. And all this so resolvers don't need to know how to put a query on hold while they go look up some other information (which they have to be able to do to handle CNAME in the general case anyway, or are you planning on abolishing aliases as well?) kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 11 20:53:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1C4qBC07794 for ipng-dist; Sun, 11 Feb 2001 20:52:11 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1C4q1207787 for ; Sun, 11 Feb 2001 20:52:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA21766 for ; Sun, 11 Feb 2001 20:52:01 -0800 (PST) Received: from ns.opicom.co.kr ([211.181.218.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA13478 for ; Sun, 11 Feb 2001 20:52:00 -0800 (PST) Received: from opicom3 (unverified [129.254.165.143]) by ns.opicom.co.kr (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 12 Feb 2001 13:41:54 +0900 Message-ID: <02a101c094af$9b781620$8fa5fe81@etri.re.kr> From: "Soo-Hong PARK" To: "IPng" Subject: Fw: is ipv6 supported in linux? Date: Mon, 12 Feb 2001 13:52:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f1C4q2207788 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk refer to www.bieringer.de/linux/IPv6/IPv6-HOWTO +-------------------------------------------------------- + Soo-Hong PARK + Engineer/OPICOM Inc. + OPtical Integrated COMmunication + 5F,Rose Dale Bldg.,724 Suseo-Dong, + Kangnam-Ku, Seoul, KOREA 135-220 + TEL:+82-42-860-1062 || FAX:+82-42-861-5404 + UMS:+0303-1509-9209 || MOBILE:+016-221-9209 + E-mail:sh_park@opicom.co.kr || URL:www.opicom.co.kr +--------------------------------------------------------- ----- Original Message ----- From: "nilesh modi" To: Sent: Friday, February 09, 2001 6:08 PM Subject: is ipv6 supported in linux? > Does linux redhat support ipv6 address ? > > > When i tried to give my network card the ipv6 address > , it gave me the error that INET6 not supported . > > > Please guide. > > Nilesh. > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 12 09:52:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1CHpMw08518 for ipng-dist; Mon, 12 Feb 2001 09:51:22 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1CHpI208511 for ; Mon, 12 Feb 2001 09:51:18 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f1CHn1m10016 for ipng@sunroof.eng.sun.com; Mon, 12 Feb 2001 09:49:01 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f199Si205517 for ; Fri, 9 Feb 2001 01:28:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01120 for ; Fri, 9 Feb 2001 01:28:43 -0800 (PST) Received: from zmailer.org (mail.zmailer.org [194.252.70.162]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA28095 for ; Fri, 9 Feb 2001 02:28:42 -0700 (MST) Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org)) by mail.zmailer.org id ; Fri, 9 Feb 2001 11:28:21 +0200 Date: Fri, 9 Feb 2001 11:28:21 +0200 From: Matti Aarnio To: nilesh modi Cc: ipng@sunroof.eng.sun.com Subject: Re: is ipv6 supported in linux? Message-ID: <20010209112821.Q15688@mea-ext.zmailer.org> References: <20010209090817.17802.qmail@web3406.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010209090817.17802.qmail@web3406.mail.yahoo.com>; from nilesham38@yahoo.com on Fri, Feb 09, 2001 at 01:08:17AM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Feb 09, 2001 at 01:08:17AM -0800, nilesh modi wrote: > Does linux redhat support ipv6 address ? No. RedHat (6.2, 7.0) are not coming with IPv6 module compiled and ready to load. You have to roll your own kernel. Also the utilities (telnet, ftp, ping, etc.) are not guaranteed to work with IPv6 even when the kernel is supporting it. There is at least one Linux distribution in Poland, which does come with IPv6 enabled and utilities checked to support it, but try as I might, I don't remember its name. What other distributions contain, that I don't know. (SuSE, Mandrake, Slackware, Debian, ...) > When i tried to give my network card the ipv6 address > , it gave me the error that INET6 not supported . > > Please guide. > > Nilesh. /Matti Aarnio -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 12 09:53:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1CHqOT08531 for ipng-dist; Mon, 12 Feb 2001 09:52:24 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1CHqJ208524 for ; Mon, 12 Feb 2001 09:52:19 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f1CHo2v10046 for ipng@sunroof.eng.sun.com; Mon, 12 Feb 2001 09:50:02 -0800 (PST) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f19F4Q206114 for ; Fri, 9 Feb 2001 07:04:27 -0800 (PST) Received: from quasimodo.east.sun.com (quasimodo.East.Sun.COM [129.148.174.94]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17482; Fri, 9 Feb 2001 10:04:25 -0500 (EST) From: sowmini@quasimodo.east.sun.com Received: (from sowmini@localhost) by quasimodo.east.sun.com (8.9.3+Sun/8.9.3) id KAA11407; Fri, 9 Feb 2001 10:04:19 -0500 (EST) Date: Fri, 9 Feb 2001 10:04:19 -0500 (EST) Message-Id: <200102091504.KAA11407@quasimodo.east.sun.com> To: narten@raleigh.ibm.com, sean@arc.net.my Cc: ipng@sunroof.eng.sun.com Subject: Re: Flow label Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Having said that, does anyone maintain an archive of this mailing list > that is threaded per-message? It would be useful to have such an > archive to refer to specific messages, as in this case. Note that I am > not asking that the current archive at > ftp://playground.sun.com/pub/ipng/mail-archive/ipng.200011 be > changed. But a supplemental archive would be a nice value-add. There's one at http://www.wcug.wwu.edu/lists/ipng/ that is created using MHonArc, but I think (?) it might not be reliable for threads that go over several months. Also, I'm not sure how frequently it gets updated- in the past, I've seen messages show up in playground.sun.com sooner than in www.wcug.wwu.edu. --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 12 09:54:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1CHr7608542 for ipng-dist; Mon, 12 Feb 2001 09:53:07 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1CHqv208535 for ; Mon, 12 Feb 2001 09:52:57 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f1CHoel10076 for ipng@sunroof.eng.sun.com; Mon, 12 Feb 2001 09:50:40 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f19G29206268 for ; Fri, 9 Feb 2001 08:02:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00382 for ; Fri, 9 Feb 2001 08:02:08 -0800 (PST) Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03107 for ; Fri, 9 Feb 2001 08:02:07 -0800 (PST) Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241]) by dolk.extundo.com (8.11.2/8.11.2) with ESMTP id f19G23S30223; Fri, 9 Feb 2001 17:02:05 +0100 To: mmacgowa@yahoo.com Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-site-prefixes-05.txt References: <200102091224.HAA13887@ietf.org> From: Simon Josefsson In-Reply-To: <200102091224.HAA13887@ietf.org> (Internet-Drafts@ietf.org's message of "Fri, 09 Feb 2001 07:24:34 -0500") Date: 09 Feb 2001 17:02:02 +0100 Message-ID: Lines: 7 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/21.0.97 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Internet-Drafts@ietf.org writes: > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-site-prefixes-05.txt Interesting, but the file seem to've been garbled. Is the complete document available somewhere? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 12 16:02:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1D00lg09004 for ipng-dist; Mon, 12 Feb 2001 16:00:47 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1D00b208997 for ; Mon, 12 Feb 2001 16:00:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06813 for ; Mon, 12 Feb 2001 16:00:38 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01037 for ; Mon, 12 Feb 2001 16:00:37 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA09262; Mon, 12 Feb 2001 16:00:37 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f1D00aA14478; Mon, 12 Feb 2001 16:00:36 -0800 X-mProtect: Mon, 12 Feb 2001 16:00:36 -0800 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdggyfa8; Mon, 12 Feb 2001 16:00:32 PST Message-Id: <4.3.2.7.2.20010212155502.020268e8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Feb 2001 15:57:02 -0800 To: IPng List From: Bob Hinden Subject: Request for Agenda Items for Minneapolis IPng Sessions Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng working group has been tentatively scheduled for two sessions at the Minneapolis IETF. They are: Monday, March 19 at 900-1130 AM Wednesday, March 21 at 900-1130 AM. Please send us requests for agenda items. When we put together the agenda we plan to give priority to current working group activities and documents, new individual submissions, and last to status reports. Also, at the last meeting we announced that we might organize an interim meeting prior to the Minneapolis meeting. Due to the relatively short time between meetings we were not able to do this. We plan to organize an interim meeting between the March Minneapolis and the August London IETF meetings. Bob Hinden / Steve Deering IPng Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 12 18:14:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1D2CG909097 for ipng-dist; Mon, 12 Feb 2001 18:12:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1D2C0209086 for ; Mon, 12 Feb 2001 18:12:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA04775 for ; Mon, 12 Feb 2001 18:12:01 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA20312 for ; Mon, 12 Feb 2001 19:12:00 -0700 (MST) Received: from smtprch2.nortelnetworks.com (erchg0k.us.nortel.com [47.113.64.104]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1D2BG316028; Mon, 12 Feb 2001 21:11:16 -0500 (EST) Received: by smtprch2.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA26865; Mon, 12 Feb 2001 20:07:08 -0600 Date: Mon, 12 Feb 2001 20:07:08 -0600 Message-Id: <200102130207.UAA26865@smtprch2.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 12 18:14:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1D2CEO09096 for ipng-dist; Mon, 12 Feb 2001 18:12:14 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1D2Bw209081 for ; Mon, 12 Feb 2001 18:11:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03033 for ; Mon, 12 Feb 2001 18:11:58 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA20296 for ; Mon, 12 Feb 2001 19:11:57 -0700 (MST) Received: from smtprch2.nortelnetworks.com (erchg0k.us.nortel.com [47.113.64.104]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1D2BD316002; Mon, 12 Feb 2001 21:11:14 -0500 (EST) Received: by smtprch2.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA26839; Mon, 12 Feb 2001 20:07:05 -0600 Date: Mon, 12 Feb 2001 20:07:05 -0600 Message-Id: <200102130207.UAA26839@smtprch2.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 12 18:14:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1D2CdK09114 for ipng-dist; Mon, 12 Feb 2001 18:12:39 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1D2CJ209099 for ; Mon, 12 Feb 2001 18:12:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03065 for ; Mon, 12 Feb 2001 18:12:20 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA20449 for ; Mon, 12 Feb 2001 19:12:19 -0700 (MST) Received: from smtprch2.nortelnetworks.com (erchg0k.us.nortel.com [47.113.64.104]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1D2BX316198; Mon, 12 Feb 2001 21:11:34 -0500 (EST) Received: by smtprch2.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA27115; Mon, 12 Feb 2001 20:07:25 -0600 Date: Mon, 12 Feb 2001 20:07:25 -0600 Message-Id: <200102130207.UAA27115@smtprch2.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 12 18:14:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1D2CpV09115 for ipng-dist; Mon, 12 Feb 2001 18:12:51 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1D2CL209102 for ; Mon, 12 Feb 2001 18:12:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03071 for ; Mon, 12 Feb 2001 18:12:21 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA20458 for ; Mon, 12 Feb 2001 19:12:20 -0700 (MST) Received: from smtprch2.nortelnetworks.com (erchg0k.us.nortel.com [47.113.64.104]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1D2BZ316214; Mon, 12 Feb 2001 21:11:35 -0500 (EST) Received: by smtprch2.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA27130; Mon, 12 Feb 2001 20:07:26 -0600 Date: Mon, 12 Feb 2001 20:07:26 -0600 Message-Id: <200102130207.UAA27130@smtprch2.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 12 20:18:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1D4HdI09516 for ipng-dist; Mon, 12 Feb 2001 20:17:39 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1D4HU209509 for ; Mon, 12 Feb 2001 20:17:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17367 for ; Mon, 12 Feb 2001 20:17:30 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13824 for ; Mon, 12 Feb 2001 20:17:29 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA28548; Mon, 12 Feb 2001 20:17:23 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f1D4HMw22601; Mon, 12 Feb 2001 20:17:22 -0800 X-mProtect: Mon, 12 Feb 2001 20:17:22 -0800 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdLjWeH0; Mon, 12 Feb 2001 20:17:18 PST Message-ID: <3A88B54F.156C26B9@Kniveton.com> Date: Mon, 12 Feb 2001 20:17:19 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, mobile-ip@standards.nortelnetworks.com Subject: Repeat messages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To the members of the IPNG list: I apologize for the repeat sending of the "Prefix Deprecation" message on the list. After looking at the message headers, it appears this message is originating from within Nortel Networks, and may be related to a Mobile IP list misconfiguration/problem last week. I have no control over Nortel Networks. If someone believes there is a misconfiguration at my mail domain, please let me know and I will fix it as soon as possible. Right now, I can't see any evidence of a misconfiguration on my end. Here's a snip of the headers... > Return-Path: > X-Sieve: cmu-sieve 2.0 > Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f1D2KXb01036 for ; Mon, 12 Feb 2001 18:20:33 -0800 (PST) > Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14636; Mon, 12 Feb 2001 18:18:32 -0800 (PST) > Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA20861; Mon, 12 Feb 2001 18:18:03 -0800 (PST) > Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1D2CdK09114 for ipng-dist; Mon, 12 Feb 2001 18:12:39 -0800 (PST) > Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1D2CJ209099 for ; Mon, 12 Feb 2001 18:12:20 -0800 (PST) > Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03065 for ; Mon, 12 Feb 2001 18:12:20 -0800 (PST) > Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA20449 for ; Mon, 12 Feb 2001 19:12:19 -0700 (MST) > Received: from smtprch2.nortelnetworks.com (erchg0k.us.nortel.com [47.113.64.104]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1D2BX316198; Mon, 12 Feb 2001 21:11:34 -0500 (EST) > Received: by smtprch2.nortelnetworks.com (SMI-8.6/SMI-SVR4) id UAA27115; Mon, 12 Feb 2001 20:07:25 -0600 > Date: Mon, 12 Feb 2001 20:07:25 -0600 > Message-ID: <200102130207.UAA27115@smtprch2.nortelnetworks.com> > To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com > From: "T.J. Kniveton" > Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Sender: owner-ipng@sunroof.eng.sun.com > Precedence: bulk > Thanks, -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 13 04:01:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1DBxkx09863 for ipng-dist; Tue, 13 Feb 2001 03:59:46 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1DBxZ209856 for ; Tue, 13 Feb 2001 03:59:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13881 for ; Tue, 13 Feb 2001 03:59:35 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA25413 for ; Tue, 13 Feb 2001 04:59:33 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15354; Tue, 13 Feb 2001 06:59:33 -0500 (EST) Message-Id: <200102131159.GAA15354@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-03.txt Date: Tue, 13 Feb 2001 06:59:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-03.txt Pages : 31 Date : 12-Feb-01 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2553bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010212125026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2553bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010212125026.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 13 05:01:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1DCxtv09904 for ipng-dist; Tue, 13 Feb 2001 04:59:55 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1DCxj209896 for ; Tue, 13 Feb 2001 04:59:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18885 for ; Tue, 13 Feb 2001 04:59:44 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07024 for ; Tue, 13 Feb 2001 04:59:43 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f1DCxg923755 for ; Tue, 13 Feb 2001 13:59:42 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA28951 for ; Tue, 13 Feb 2001 13:59:41 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f1DCxfO07208 for ; Tue, 13 Feb 2001 13:59:41 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200102131259.f1DCxfO07208@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: Radius for IPv6 Date: Tue, 13 Feb 2001 13:59:41 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The RADIUS and IPv6 document is in last call for proposed standard. I don't believe it is a good thing to have some mods for IPv6 in Radius when we ask for a full AAA for IPv6, ie. Radius for IPv6 can slow down the deployment of IPv6 because it provides a transient solution... Of course this is *not* a technical concern. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 13 05:23:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1DDMZ109931 for ipng-dist; Tue, 13 Feb 2001 05:22:35 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1DDMO209924 for ; Tue, 13 Feb 2001 05:22:24 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1DDMMR939901; Tue, 13 Feb 2001 05:22:22 -0800 (PST) Date: Tue, 13 Feb 2001 14:21:50 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Radius for IPv6 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200102131259.f1DCxfO07208@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The RADIUS and IPv6 document > is in last call for proposed standard. I don't believe it is a good > thing to have some mods for IPv6 in Radius when we ask for a full > AAA for IPv6, ie. Radius for IPv6 can slow down the deployment of > IPv6 because it provides a transient solution... Of course this is > *not* a technical concern. I think the opposite is the case. Currently nobody can build an IPv6 PPP NAS since the Diameter protocol is nor specified neither implemented. Being able to build such a thing using Radius seems like a good thing instead of requiring that Diameter be finished before you can get dial-in IPv6 access. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 13 07:56:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1DFsq010123 for ipng-dist; Tue, 13 Feb 2001 07:54:52 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1DFsg210116 for ; Tue, 13 Feb 2001 07:54:43 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02006 for ; Tue, 13 Feb 2001 07:54:38 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00086 for ; Tue, 13 Feb 2001 07:54:07 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id HAA44586 for ; Tue, 13 Feb 2001 07:54:01 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id HAA17456 for ; Tue, 13 Feb 2001 07:54:06 -0800 Message-ID: <3A895822.3224A197@hursley.ibm.com> Date: Tue, 13 Feb 2001 09:52:02 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Radius for IPv6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk fwiw I agree with Erik. Radius is the deployed solution and we should be glad that it will support IPv6. (Everything should support IPv6:-) Brian Erik Nordmark wrote: > > > The RADIUS and IPv6 document > > is in last call for proposed standard. I don't believe it is a good > > thing to have some mods for IPv6 in Radius when we ask for a full > > AAA for IPv6, ie. Radius for IPv6 can slow down the deployment of > > IPv6 because it provides a transient solution... Of course this is > > *not* a technical concern. > > I think the opposite is the case. > > Currently nobody can build an IPv6 PPP NAS since the Diameter protocol > is nor specified neither implemented. > Being able to build such a thing using Radius seems like a good thing > instead of requiring that Diameter be finished before you can get > dial-in IPv6 access. > > Erik > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 13 08:46:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1DGiQ210202 for ipng-dist; Tue, 13 Feb 2001 08:44:26 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1DGiF210195 for ; Tue, 13 Feb 2001 08:44:15 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1DGiDR967066; Tue, 13 Feb 2001 08:44:13 -0800 (PST) Date: Tue, 13 Feb 2001 17:43:42 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-ietf-ipngwg-site-prefixes-05.txt To: Simon Josefsson Cc: mmacgowa@yahoo.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Internet-Drafts@ietf.org writes: > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-site-prefixes-05.txt > > Interesting, but the file seem to've been garbled. Is the complete > document available somewhere? I just downloaded the above URL and it looks like the document I submitted. What was wrong with your copy? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 14 15:12:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1ENAdV11854 for ipng-dist; Wed, 14 Feb 2001 15:10:39 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1ENAT211847 for ; Wed, 14 Feb 2001 15:10:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23990 for ; Wed, 14 Feb 2001 15:10:27 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06491 for ; Wed, 14 Feb 2001 15:10:26 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA02119; Wed, 14 Feb 2001 15:10:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f1ENAL832595; Wed, 14 Feb 2001 15:10:21 -0800 X-mProtect: Wed, 14 Feb 2001 15:10:21 -0800 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdCHrAEk; Wed, 14 Feb 2001 15:10:10 PST Message-ID: <3A8B1054.68209661@Kniveton.com> Date: Wed, 14 Feb 2001 15:10:12 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@marvin.corpeast.baynetworks.com, ipng@sunroof.eng.sun.com CC: "Powell, Ken" Subject: New idea for Router Sol/Adv and Mobility References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Intro ----- This post addresses section 9.8.3 and 10.{16,17} in the Mobile IPv6 draft,concerning Tunneled Router Solicitations and Advertisements. As I posted on the Mobile IP mailing list, the procedure proposed in these sections will not work when a MN is in the process of configuration and without a Home Address. Below, I will recommend an alternate solution which will cover this possibility. Since I am posting this to the IPng mailing list, I will reiterate some of the problem. Background of Problem --------------------- A Mobile Node, when configuring itself, may first configure its (global) COA, then find its Home Agent's address, and send a Tunneled Router Solicitation, in order to get prefix info to configure its normal Home Address(es). In 10.16, the MN without a HAddr encapsulates a RS using an inner source address of 0::0 (unspecified). The HA receiving this packet is justified in removing the outer layer without saving any state, meaning it would then be presented with a packet coming from an unspecified address. This is, at the least, problematic and annoying. The HA could be forced to keep the outer source address (COA) around, which would solve this. In 9.8.3, the draft instructs Home Agents to tunnel the RA to the MN using the MN's COA using a routing header containing the address 0::0. As Ken Powell pointed out: > This also violates the addressing architecture, RFC 2373 section > 2.5.2: > > The unspecified address must not be used as the destination address > of IPv6 packets or in IPv6 Routing Headers. One possible solution is forming a temporary Home Address; however, there is no advantage to doing this other than to provide routability. If the temporary HAddr is already in use, the HA can not send a packet to that address with a Routing Hdr, and so it does not solve the problem. Solution -------- The solution to this problem involves two steps: relaxing a Neighbor Discovery rule on the HA and MN, and creating a mobility processing rule on the HA and MN. Now RS/RA can be sent without any special Mobile IP headers, and look very similar to normal RS/RA, except that they are routed unicast packets. This solution is very general, and uses the COA and HA addr only, so it does not matter whether the MN does, or does not, have an HAddr. RELAXING TTL: 1. An unicast Router Solicitation arriving at an Home Agent is NOT discarded if the TTL < 255 (off-link, from MN). 2. An unicast Router Advertisement arriving at a Mobile Node is NOT discarded if the TTL < 255 (off-link, from HA) MOBILITY PROCESSING: 1. The Home Agent receiving a Router Solicitation with TTL<255 (from off link) knows that this is a request from a MN, and will include extra Prefix Information as per the draft. 2. The Mobile Node receiving a Router Advertisement with TTL<255 knows that this was sent from a HA and contains HA prefix info and it should be processed differently by Mobile IP code to create HAddr(s). Recap Of Changes From Current Draft ----------------------------------- We are removing - encapsulation on RS - routing header on RA We are adding - a rule that TTL<255 is allowed and specifies mobility signaling - RS and RA come into/out of COA on MN. HAddr is not used for this info. This buys us - mobile nodes without an HAddr are now routable - simplification and shortening of messages - Open Issues ----------- SECURITY: The Router Solicitation must be protected by an Authentication Header. This is already a requirement. The Router Advertisement should/may be encrypted. If it is not, note that prefix information about the home network will be available for inspection along the path the RA travels. This security issue is the same as what exists in the current version. I am open for comments on this idea. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 14 20:08:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1F47MV11993 for ipng-dist; Wed, 14 Feb 2001 20:07:22 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1F47D211986 for ; Wed, 14 Feb 2001 20:07:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA28359 for ; Wed, 14 Feb 2001 20:07:13 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA24881 for ; Wed, 14 Feb 2001 21:07:12 -0700 (MST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1F46Qs08909; Wed, 14 Feb 2001 23:06:26 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id EAA25975; Thu, 15 Feb 2001 04:07:09 GMT Date: Thu, 15 Feb 2001 04:07:09 GMT Message-Id: <200102150407.EAA25975@qnsgs000.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 14 23:25:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1F7NwS12116 for ipng-dist; Wed, 14 Feb 2001 23:23:58 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1F7Nn212109 for ; Wed, 14 Feb 2001 23:23:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAB01218 for ; Wed, 14 Feb 2001 23:23:50 -0800 (PST) Received: from aphelion.csl.sony.co.jp (aphelion.csl.sony.co.jp [133.138.1.94]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA25911 for ; Thu, 15 Feb 2001 00:23:49 -0700 (MST) Received: from leo (leo.csl.sony.co.jp [43.27.100.62]) by aphelion.csl.sony.co.jp (8.9.3/3.7W) with ESMTP id QAA47700 for ; Thu, 15 Feb 2001 16:23:47 +0900 (JST) Message-Id: <4.2.0.58.J.20010215162420.02021470@aphelion.csl.sony.co.jp> X-Sender: tera@aphelion.csl.sony.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 15 Feb 2001 16:25:39 +0900 To: ipng@sunroof.eng.sun.com From: Fumio Teraoka Subject: Follow up on LIN6 I-D Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We made a presentation of our internet draft: draft-teraoka-mobility-lin6-00.txt at the last IETF. However, we were criticized in various forums that Section 8 on intellectual property rights was insufficient. We regret that it has taken very much time to resolve this issue, due to the involvement of two companies. However, it is not our intension to ignore IETF policies regarding patent issues and will change this section accordingly to satisfy RFC2026 in the next revision. This next revision will be made available soon at the latest before the next IETF. Fumio Teraoka Sony Computer Science Labs., Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 00:10:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1F87jw12188 for ipng-dist; Thu, 15 Feb 2001 00:07:45 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1F87E212151 for ; Thu, 15 Feb 2001 00:07:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11076 for ; Thu, 15 Feb 2001 00:07:16 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA29367 for ; Thu, 15 Feb 2001 00:07:11 -0800 (PST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1F86Ns24309; Thu, 15 Feb 2001 03:06:26 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id IAA04379; Thu, 15 Feb 2001 08:07:06 GMT Date: Thu, 15 Feb 2001 08:07:06 GMT Message-Id: <200102150807.IAA04379@qnsgs000.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 00:10:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1F87sS12189 for ipng-dist; Thu, 15 Feb 2001 00:07:54 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1F87E212149 for ; Thu, 15 Feb 2001 00:07:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20759 for ; Thu, 15 Feb 2001 00:07:15 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05305 for ; Thu, 15 Feb 2001 00:07:11 -0800 (PST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1F86Ns24314; Thu, 15 Feb 2001 03:06:26 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id IAA04384; Thu, 15 Feb 2001 08:07:06 GMT Date: Thu, 15 Feb 2001 08:07:06 GMT Message-Id: <200102150807.IAA04384@qnsgs000.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 00:10:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1F881M12191 for ipng-dist; Thu, 15 Feb 2001 00:08:01 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1F87F212155 for ; Thu, 15 Feb 2001 00:07:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11084 for ; Thu, 15 Feb 2001 00:07:16 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05326 for ; Thu, 15 Feb 2001 00:07:12 -0800 (PST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1F86Ns24317; Thu, 15 Feb 2001 03:06:27 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id IAA04390; Thu, 15 Feb 2001 08:07:07 GMT Date: Thu, 15 Feb 2001 08:07:07 GMT Message-Id: <200102150807.IAA04390@qnsgs000.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 00:10:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1F886612192 for ipng-dist; Thu, 15 Feb 2001 00:08:07 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1F87G212157 for ; Thu, 15 Feb 2001 00:07:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05053 for ; Thu, 15 Feb 2001 00:07:17 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA29399 for ; Thu, 15 Feb 2001 00:07:16 -0800 (PST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1F86Vs24416; Thu, 15 Feb 2001 03:06:31 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id IAA04511; Thu, 15 Feb 2001 08:07:14 GMT Date: Thu, 15 Feb 2001 08:07:14 GMT Message-Id: <200102150807.IAA04511@qnsgs000.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 00:10:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1F87vD12190 for ipng-dist; Thu, 15 Feb 2001 00:07:57 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1F87H212163 for ; Thu, 15 Feb 2001 00:07:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05061 for ; Thu, 15 Feb 2001 00:07:17 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05373 for ; Thu, 15 Feb 2001 00:07:17 -0800 (PST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1F86Ws24425; Thu, 15 Feb 2001 03:06:32 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id IAA04524; Thu, 15 Feb 2001 08:07:15 GMT Date: Thu, 15 Feb 2001 08:07:15 GMT Message-Id: <200102150807.IAA04524@qnsgs000.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 00:11:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1F899r12201 for ipng-dist; Thu, 15 Feb 2001 00:09:09 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1F88U212194 for ; Thu, 15 Feb 2001 00:08:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01849 for ; Thu, 15 Feb 2001 00:08:30 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07121 for ; Thu, 15 Feb 2001 00:08:30 -0800 (PST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1F86Qs24349; Thu, 15 Feb 2001 03:06:29 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id IAA04436; Thu, 15 Feb 2001 08:07:09 GMT Date: Thu, 15 Feb 2001 08:07:09 GMT Message-Id: <200102150807.IAA04436@qnsgs000.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 01:01:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1F90E812460 for ipng-dist; Thu, 15 Feb 2001 01:00:14 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1F902212453 for ; Thu, 15 Feb 2001 01:00:03 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA09474 for ; Thu, 15 Feb 2001 01:00:03 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA24114 for ; Thu, 15 Feb 2001 01:00:02 -0800 (PST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f1F8xxd07052; Thu, 15 Feb 2001 09:59:59 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id JAA13799; Thu, 15 Feb 2001 09:59:58 +0100 Message-ID: <3A8B9ABC.62D321C3@era.ericsson.se> Date: Thu, 15 Feb 2001 10:00:44 +0100 From: Mattias Pettersson Organization: Ericsson Radio Systems AB X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en, sv MIME-Version: 1.0 To: "T.J. Kniveton" CC: mobile-ip@marvin.corpeast.baynetworks.com, ipng@sunroof.eng.sun.com, "Powell, Ken" Subject: Re: New idea for Router Sol/Adv and Mobility References: <3A8B1054.68209661@Kniveton.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, "T.J. Kniveton" wrote: > Open Issues > ----------- > SECURITY: > The Router Solicitation must be protected by an Authentication Header. > This is already a requirement. Is it? Where do you find that requirement? The RA needs authentication though. > The Router Advertisement should/may be encrypted. If it is not, note > that prefix information about the home network will be available for > inspection along the path the RA travels. This security issue is the > same as what exists in the current version. > > I am open for comments on this idea. I think this is a good way. Start-up procedure is a mess right now. The basic arguments against a special solution for bootstrapping was that the MN-HA RS/RA mechanism is used in other places too: 1. MN sends an RS at any point in time to sync its prefix list with the HA. 2. RA pushes an RA to the MN due to changed information in the home network. Can we move to non-tunneled RSes/RAs for these cases as well? Will we open up a security hole or possible denial-of service attack by let's say flood a HA with RSes (that don't require authentication), now that we can send them over multiple hops? /Mattias -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 03:48:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1FBlBp12650 for ipng-dist; Thu, 15 Feb 2001 03:47:11 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1FBl0212643 for ; Thu, 15 Feb 2001 03:47:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05312 for ; Thu, 15 Feb 2001 03:46:59 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA28293 for ; Thu, 15 Feb 2001 04:46:58 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12716; Thu, 15 Feb 2001 06:46:58 -0500 (EST) Message-Id: <200102151146.GAA12716@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-1394-01.txt Date: Thu, 15 Feb 2001 06:46:58 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over IEEE 1394 Networks Author(s) : K. Fujisawa, A. Onoe Filename : draft-ietf-ipngwg-1394-01.txt Pages : 8 Date : 14-Feb-01 IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. This document describes the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. It also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on an IEEE1394 network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-1394-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-1394-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-1394-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010214135015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-1394-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-1394-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010214135015.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 13:49:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1FLkd013112 for ipng-dist; Thu, 15 Feb 2001 13:46:39 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1FLkR213105 for ; Thu, 15 Feb 2001 13:46:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16594 for ; Thu, 15 Feb 2001 13:46:25 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21038 for ; Thu, 15 Feb 2001 13:46:25 -0800 (PST) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id A9F76A8C5; Thu, 15 Feb 2001 16:46:24 -0500 (EST) Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 9AF619348 for ; Thu, 15 Feb 2001 16:46:24 -0500 (EST) Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id <15PNHJN4>; Thu, 15 Feb 2001 16:46:24 -0500 Message-ID: From: "Powell, Ken" To: "'T.J. Kniveton'" , "'mobile-ip@standards.nortelnetworks.com'" , ipng@sunroof.eng.sun.com Subject: RE: New idea for Router Sol/Adv and Mobility Date: Thu, 15 Feb 2001 16:46:22 -0500 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > Sent: Wednesday, February 14, 2001 6:10 PM > To: mobile-ip@marvin.corpeast.baynetworks.com; > ipng@sunroof.eng.sun.com > Cc: Powell, Ken > Subject: New idea for Router Sol/Adv and Mobility > Solution > -------- > The solution to this problem involves two steps: relaxing a Neighbor > Discovery rule on the HA and MN, and creating a mobility > processing rule > on the HA and MN. Now RS/RA can be sent without any special Mobile IP > headers, and look very similar to normal RS/RA, except that they are > routed unicast packets. This solution is very general, and > uses the COA > and HA addr only, so it does not matter whether the MN does, or does > not, have an HAddr. > > RELAXING TTL: > 1. An unicast Router Solicitation arriving at an Home Agent is NOT > discarded if the TTL < 255 (off-link, from MN). > 2. An unicast Router Advertisement arriving at a Mobile Node is NOT > discarded if the TTL < 255 (off-link, from HA) > > MOBILITY PROCESSING: > 1. The Home Agent receiving a Router Solicitation with > TTL<255 (from off > link) knows that this is a request from a MN, and will include extra > Prefix Information as per the draft. > 2. The Mobile Node receiving a Router Advertisement with TTL<255 knows > that this was sent from a HA and contains HA prefix info and it should > be processed differently by Mobile IP code to create HAddr(s). > > Recap Of Changes From Current Draft > ----------------------------------- > We are removing > - encapsulation on RS > - routing header on RA > > We are adding > - a rule that TTL<255 is allowed and specifies mobility signaling > - RS and RA come into/out of COA on MN. HAddr is not used for this > info. > > This buys us > - mobile nodes without an HAddr are now routable > - simplification and shortening of messages > - Under this proposal, the Mobile Node will have to re-establish the Security Association between the Home Agent and its Care-Of Address every time it moves to support IPsec requirements for Router Advertisements. How does this fit in with the process of forming the new care-of address and updating bindings? Will this cause additional hand-off delays? How does the home agent determine which mobile node sent the Router Solicitation? Can the Care-of address on a mobile node be relied on for this? > -----Original Message----- > From: Mattias Pettersson [mailto:mattias.pettersson@era.ericsson.se] > Sent: Thursday, February 15, 2001 4:01 AM > To: T.J. Kniveton > Cc: mobile-ip@marvin.corpeast.baynetworks.com; > ipng@sunroof.eng.sun.com; > Powell, Ken > Subject: Re: New idea for Router Sol/Adv and Mobility > > > Hi, > > "T.J. Kniveton" wrote: > > > Open Issues > > ----------- > > SECURITY: > > The Router Solicitation must be protected by an Authentication > > Header. This is already a requirement. > > Is it? Where do you find that requirement? The RA needs authentication > though. > > > Will we open up a security hole or possible denial-of service > attack by let's say flood a HA with RSes (that don't require > authentication), now that we can send them over multiple hops? > Yes, this does look like a problem, but I think its just as serious in draft 13. Any node could repeatedly send router solicits with the mobile node's care-of address (and home address). The home agent would send a complete Router Advertisement to the mobile node for each Router Solicit, possibly eating up expensive wireless bandwidth. Perhaps the Router Solicit should be IPsec protected? Ken -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 15:12:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1FN9hZ13219 for ipng-dist; Thu, 15 Feb 2001 15:09:43 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1FN9Y213212 for ; Thu, 15 Feb 2001 15:09:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26367 for ; Thu, 15 Feb 2001 15:09:34 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19947 for ; Thu, 15 Feb 2001 15:09:34 -0800 (PST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 15 Feb 2001 14:31:21 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Feb 2001 14:32:08 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Thu, 15 Feb 2001 14:32:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: IPv6 addresses with embedded private IPv4 addresses Date: Thu, 15 Feb 2001 14:32:07 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657420FD73@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 addresses with embedded private IPv4 addresses Thread-Index: AcCXnxKwLvttf1sKQXKb8xajRwwG/Q== From: "Dave Thaler" To: X-OriginalArrivalTime: 15 Feb 2001 22:32:08.0645 (UTC) FILETIME=[21A54F50:01C0979F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1FN9Z213213 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd like to ask for some general consensus on the following questions: 1) Are "::10.1.1.1" and "::169.254.1.1" legal IPv6 addresses? (They look like global IPv6 addresses, but aren't globally unique.) RFC 2373 does not mention any such restriction, and so implies "yes". 2) Similarly, is "2002:0A01:0101:..." a legal IPv6 address? The current 6to4 draft implies "no". 3) Is it reasonable that the answers to the above two questions could be different? (I'd personally rather the answer be the same for both, that answer probably being "no", as this avoids a lot of ugly problems.) And before anyone responds saying that "::10.1.1.1" should be allowed so that you can talk between two hosts in a private IPv4 network, keep in mind that draft-templin-ngtrans-v6v4compat-*.txt allows you to do the same thing with "fe80::200:5efe:10.1.1.1", which is clearly a link-local address (on an encapsulation link covering the private area) and so avoids the ugly problems "::10.1.1.1" has. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 15:17:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1FNH1m13250 for ipng-dist; Thu, 15 Feb 2001 15:17:01 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1FNGp213243 for ; Thu, 15 Feb 2001 15:16:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16248 for ; Thu, 15 Feb 2001 15:16:52 -0800 (PST) Received: from china.com (TCE-E-7-182-13.bta.net.cn [202.106.182.13]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA13473 for ; Thu, 15 Feb 2001 15:16:36 -0800 (PST) Received: from china.com([10.1.0.100]) by china.com(JetMail 2.5.3.0) with SMTP id jm1603a8c9e7e; Thu, 15 Feb 2001 23:13:31 -0000 Received: from mercury.Sun.COM([192.9.25.1]) by china.com(JetMail 2.5.3.0) with SMTP id jm2a3a8bcac7; Thu, 15 Feb 2001 08:11:39 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA25269; Thu, 15 Feb 2001 00:14:21 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA02853; Thu, 15 Feb 2001 00:14:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1F87jw12188 for ipng-dist; Thu, 15 Feb 2001 00:07:45 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1F87E212151 for ; Thu, 15 Feb 2001 00:07:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11076 for ; Thu, 15 Feb 2001 00:07:16 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA29367 for ; Thu, 15 Feb 2001 00:07:11 -0800 (PST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1F86Ns24309; Thu, 15 Feb 2001 03:06:26 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id IAA04379; Thu, 15 Feb 2001 08:07:06 GMT Date: Thu, 15 Feb 2001 08:07:06 GMT Message-Id: <200102150807.IAA04379@qnsgs000.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 17:32:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G1UNo13877 for ipng-dist; Thu, 15 Feb 2001 17:30:23 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G1UD213870 for ; Thu, 15 Feb 2001 17:30:13 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA11765 for ; Thu, 15 Feb 2001 17:30:13 -0800 (PST) Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA13380 for ; Thu, 15 Feb 2001 17:30:13 -0800 (PST) Received: from camaleon.ee.calpoly.edu (HELO pebbles) (129.65.26.37) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Feb 2001 01:30:12 -0000 X-Apparently-From: Message-ID: <020401c097b8$5f5115a0$251a4181@bedrock.calpoly.edu> From: "Jose Melara" To: "Matti Aarnio" Cc: References: <20010209090817.17802.qmail@web3406.mail.yahoo.com> <20010209112821.Q15688@mea-ext.zmailer.org> Subject: Re: is ipv6 supported in linux? Date: Thu, 15 Feb 2001 17:32:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > No. RedHat (6.2, 7.0) are not coming with IPv6 module > compiled and ready to load. > > You have to roll your own kernel. Q1. You mean going through the menuconfig and changing the option to support IPv6 right? Q2. Is there any documentation on how to make an address translator IP4 to IP6? I have a couple of machines running linux on IPv4 with the kernel 2.4.1 compiled to support IPv6. I also have a server which is supposed to support IPv6. Do you, or anyone knows of any documentation on how to make an address translator? Thanks, Jose _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 19:35:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G3YC614060 for ipng-dist; Thu, 15 Feb 2001 19:34:12 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G3Y2214051 for ; Thu, 15 Feb 2001 19:34:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15516 for ; Thu, 15 Feb 2001 19:34:01 -0800 (PST) Received: from sina.com ([202.106.187.167]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA16614 for ; Thu, 15 Feb 2001 19:33:58 -0800 (PST) Received: (qmail 22000 invoked by uid 99); 16 Feb 2001 03:34:06 -0000 Message-ID: <20010216033406.21999.qmail@sina.com> From: wdnxy To: ipng@sunroof.eng.sun.com Cc: wdnxy@sina.com Subject: need help Date: Fri, 16 Feb 2001 11:34:06 +0800 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hello, I have a experiment network including 4 PCs in which Linux with IPv6 runs. Now I want to join the 6Bone network. But from the introduction of 6Bone homepage, I can't get all thepro infomation I need, especially the following 3 points. 1, How can I get a point to allow me to connect? I have tried several times and several hosts, but on any response at all. The location I prefer is North America. Who can give me a hand? 2, After this, I know that there are some "serious" work to do. But it seems too difficult for a laypeople (like me) to do such professional things. So I need the more details here. 3, For some reasons, I have to connect my network to the 6Bone through a firewall, I don't know if having any influence on the connection. Yours, W.N. Feb.16, 2001 ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn) ÐÂÀËÁÄÌì´ó½±-MP3ÉÌÎñͨDVDÊÖ»ú×ê½äµÈ×ÅÄú£»²¢ÌṩÁÄÓÑËÙÅä·þÎñ (http://newchat.sina.com.cn/love/) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 19:38:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G3bcF14092 for ipng-dist; Thu, 15 Feb 2001 19:37:38 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G3bR214085 for ; Thu, 15 Feb 2001 19:37:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15859 for ; Thu, 15 Feb 2001 19:37:26 -0800 (PST) Received: from china.com (TCE-E-7-182-12.bta.net.cn [202.106.182.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA18273 for ; Thu, 15 Feb 2001 19:37:24 -0800 (PST) Received: from china.com([10.1.7.101]) by china.com(JetMail 2.5.3.0) with SMTP id jm43a8cac6a; Fri, 16 Feb 2001 03:30:19 -0000 Received: from loki.ietf.org([132.151.1.177]) by china.com(JetMail 2.5.3.0) with SMTP id jm143a8be98e; Thu, 15 Feb 2001 12:17:23 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA12145 for ietf-123-outbound.02@ietf.org; Thu, 15 Feb 2001 07:05:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA11984 for ; Thu, 15 Feb 2001 06:46:57 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12716; Thu, 15 Feb 2001 06:46:58 -0500 (EST) Message-Id: <200102151146.GAA12716@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-1394-01.txt Date: Thu, 15 Feb 2001 06:46:58 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over IEEE 1394 Networks Author(s) : K. Fujisawa, A. Onoe Filename : draft-ietf-ipngwg-1394-01.txt Pages : 8 Date : 14-Feb-01 IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. This document describes the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. It also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on an IEEE1394 network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-1394-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-1394-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-1394-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010214135015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-1394-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-1394-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010214135015.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 21:28:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G5QjK14189 for ipng-dist; Thu, 15 Feb 2001 21:26:45 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G5QS214174 for ; Thu, 15 Feb 2001 21:26:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA09207 for ; Thu, 15 Feb 2001 21:26:27 -0800 (PST) Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA10532 for ; Thu, 15 Feb 2001 22:26:26 -0700 (MST) Received: (cpmta 18742 invoked from network); 15 Feb 2001 21:26:25 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.71) with SMTP; 15 Feb 2001 21:26:25 -0800 X-Sent: 16 Feb 2001 05:26:25 GMT Message-ID: <000e01c097d9$04efdda0$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Robert Elz" , "Brian E Carpenter" Cc: , References: <1892.981613354@brandenburg.cs.mu.OZ.AU> Subject: Re: another renumbering question Date: Thu, 15 Feb 2001 12:36:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Firewalls are no reason for a two faced DNS. Those are forced upon us by > NAT, because of the re-use of addresses. With IPv6 we will have no need > to re-use addresses, and so no reason to bother with two faced DNS (which > isn't to say that they may not still be people who would prefer to use it). > It is funny for you to say that with IPv6 we don't need to use re-used addresses, because a site local address *is* a kind of re-used address. There is a lot of similarity architecturally between net 10 in IPv4 and site local addresses in IPv6. Niether can be globally routed. Both spaces are re-used by large numbers of sites, and from casual inspection of a site-local address, outside the context of the inspection point, you can't tell what site it belongs to. And clearly people feel a need to use them or we wouldn't be having this discussion. The reason we aren't forced into two-faced DNS with IPv6 is that *in addition to* the re-used (aka site-local) addresses, IPv6 nodes also have global addresses, and these can be leveraged to determine if a given re-used address is in the same site or a different site. On a separate note, I know this is probably just digging up dead discussions, but have people considered creating a new IPv6 space which is "globally unique but not globally routable" for use in this sort of internal site communications? Such an address space would be useful, for instance, when merging two sites (which, if using site-local addresses, will require renumbering of one of the sites). Such addresses (lets call them unique-local addresses) could be put in DNS without concern for thier being mis-interpreted by other nodes. Granted when a node did a DNS lookup, it wouldn't know if a given unique-local address was in the same site, but it could learn easily by just sending a packet to that address and either succeeding or getting an ICMP dest unreachable. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 21:28:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G5Qlg14190 for ipng-dist; Thu, 15 Feb 2001 21:26:47 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G5QU214179 for ; Thu, 15 Feb 2001 21:26:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA09205 for ; Thu, 15 Feb 2001 21:26:26 -0800 (PST) Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA15956 for ; Thu, 15 Feb 2001 21:26:26 -0800 (PST) Received: (cpmta 18733 invoked from network); 15 Feb 2001 21:26:25 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.71) with SMTP; 15 Feb 2001 21:26:24 -0800 X-Sent: 16 Feb 2001 05:26:24 GMT Message-ID: <000d01c097d9$049d77e0$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Robert Elz" , "Brian E Carpenter" Cc: References: <3355.981802098@brandenburg.cs.mu.OZ.AU> Subject: summary of Re: another renumbering question Date: Thu, 15 Feb 2001 01:37:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just an attempt to summarize this thread: Jim Bound thinks the use of site-local addresses is bad. Robert Elz things that the use of site-local addresses is ok, but that two-faced DNS is bad. Other folks don't think two-faced DNS is so bad. (I'm in this camp too...) Robert Elz also made a good suggestion as to how hosts can learn the site-local addresses of other hosts in the site (least-wise it seemed good to me). But the state of this suggestion is that it exists in an email and nowhere else (i.e., no internet draft), so unless someone writes it up nothing will happen to it? (By the way Robert, are the ICMP "tell me your site local addresses" and ICMP "site local source exiting the site" messages you mention in your suggestion in existing drafts, or are these new messages you are making up?) In the absense of Robert's suggestion or Erik's draft (draft-ietf-ipngwg-site-prefixes-05.txt) (both of which require changes to existing implementations), I gather that there are only two possibilities: 1. Don't use site-local addresses at all. 2. Use site-local addresses and two-faced DNS. Is this a reasonable summary? PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 15 22:46:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G6jVQ14234 for ipng-dist; Thu, 15 Feb 2001 22:45:31 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G6jM214227 for ; Thu, 15 Feb 2001 22:45:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21515 for ; Thu, 15 Feb 2001 22:45:20 -0800 (PST) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA21809 for ; Thu, 15 Feb 2001 22:45:20 -0800 (PST) Received: from [192.168.1.42] (qool.kniveton.com [192.168.1.42]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f1G6ehb06122; Thu, 15 Feb 2001 22:40:43 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 15 Feb 2001 22:40:47 -0800 Subject: Re: New idea for Router Sol/Adv and Mobility From: "T.J. Kniveton" To: "Powell, Ken" , "'mobile-ip@standards.nortelnetworks.com'" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk on 2/15/01 1:46 PM, Powell, Ken wrote: > Under this proposal, the Mobile Node will have to re-establish the > Security Association between the Home Agent and its Care-Of Address > every time it moves to support IPsec requirements for Router > Advertisements. How does this fit in with the process of > forming the new care-of address and updating bindings? Will > this cause additional hand-off delays? > Good question. Where this question leads is, how can the HA trust an MN when the MN does not have a trustable identity based on a Home network IP address? Does it make sense to base security associations on IP addresses when the addresses themselves are ephemeral and can't be associated to Identity without the involvement of an outside entity? Clearly this is already a hot topic. Rather than trying to solve it here, perhaps I can offer a compromise which allows for the possibility of future elaboration. Here's the recipe: start with Draft 13. Now remove encapsulation from RSs (this is unnecessary and inconsistent). Add the rules for TTL<255 and mobility processing, as stated in my previous message. Stir in addressing as follows: 1. The RS is sent with a HAddr option. The HAddr contains the MN's Home Address (naturally), EXCEPT if the MN has not configured one, in which case it MAY insert the COA instead. 2. The HA sends an RA using a routing header, as usual. The RHdr contains whatever was in the HAddr option - namely, the Home Address, EXCEPT if the COA was in the RS's HAddr option, it goes in the routing header (we could just leave the routing header off, alternatively). This RA is still protected by IPsec as in the draft. This is the best of both worlds: - In the steady-state case, where a MN has a HAddr, and it needs updated prefix info, it just sends an RS and the RA is protected with the existing security association - If the MN does not yet have a HAddr, it uses the COA, *assuming you have a way to generate a security association between the HA and the COA*. If you can not do this, there is no way to get an IPSEC-protected RA. This is part of the "bootstrap problem." As soon as the MN gets a home address, it can use the HAddr in all future RSs, so this does not suffer from the problem Ken brought up, of having to update the HA/COA sec.assoc. every time you handover. Using the COA is a one-time thing while bootstrapping. This leaves room open for developing a dynamic security architecture where trust is based on something other than strictly the IP address. For instance, an NAI, signed key, (whatever) might be used instead. > How does the home agent determine which mobile node sent the > Router Solicitation? Can the Care-of address on a mobile node > be relied on for this? I contend it doesn't matter. You just need to know that it was sent from a mobile node. The information you include in a solicited RA consists of the prefixes from your own AdvPrefixList, and the prefixes advertised (and therefore served) by all other HAs on the link. No other prefixes will be Mobile-IP-routable, and so they don't matter while the MN is off-link. The MN should be able to configure any/all of these prefixes and be served by any of these HAs, so you must send them all to any node who solicits. >[Mattias Pettersson wrote:] >> >> Will we open up a security hole or possible denial-of service >> attack by let's say flood a HA with RSes (that don't require >> authentication), now that we can send them over multiple hops? >> > > Yes, this does look like a problem, but I think its just as > serious in draft 13. Any node could repeatedly send router > solicits with the mobile node's care-of address (and home > address). The home agent would send a complete Router > Advertisement to the mobile node for each Router Solicit, > possibly eating up expensive wireless bandwidth. Perhaps > the Router Solicit should be IPsec protected? The problem isn't bandwidth here. The security issue is that anyone can see the prefix information about that potentially private network. You are thereby exposing the fact that a certain IP address is a router, that it's also a home agent, and what some or all of the prefixes on that link are. And you're exposing it to anyone along the path to the MN. Regarding the bandwidth issue, who cares that the HA will send RAs to the mobile? If you want to use the MN's bandwidth, nothing stops you from just sending it packets yourself! Anyway, the HA could protect against this by limiting the rate at which it sends RAs. > > Ken > So I am interested in your comments on my compromise proposal. -- TJ Kniveton NOKIA Research -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 00:06:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G84kC14304 for ipng-dist; Fri, 16 Feb 2001 00:04:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G84b214297 for ; Fri, 16 Feb 2001 00:04:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA26687 for ; Fri, 16 Feb 2001 00:04:37 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24170 for ; Fri, 16 Feb 2001 00:04:31 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id PAA16016; Fri, 16 Feb 2001 15:04:22 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1G84Fn00611; Fri, 16 Feb 2001 15:04:21 +0700 (ICT) From: Robert Elz To: "Paul Francis" cc: ipng@sunroof.eng.sun.com Subject: Re: another renumbering question In-reply-to: Your message of "Thu, 15 Feb 2001 12:36:25 PST." <000e01c097d9$04efdda0$8cc90518@smateo1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 15:04:15 +0700 Message-ID: <609.982310655@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 15 Feb 2001 12:36:25 -0800 From: "Paul Francis" Message-ID: <000e01c097d9$04efdda0$8cc90518@smateo1.sfba.home.com> | It is funny for you to say that with IPv6 we don't need to use re-used | addresses, because a site local address *is* a kind of re-used address. Yes, I know, as often occurs, my wording was not very good. I agree with your summary of the way things are (or will be)... | On a separate note, I know this is probably just digging up dead | discussions, but have people considered creating a new IPv6 space which is | "globally unique but not globally routable" for use in this sort of internal | site communications? Yes there has been a bunch of discussion about that from time to time, it is a topic Christian Huitema raises from time to time... There's no reason these need to be different from site locals though (all the attributes are there - if only site locals could have a field in them to add the "globally unique" part). The chief objection to this, as I understand it, has always been how such things would get assigned, who would do that, on what basis, etc. I can't actually see the difficulty in assigning consecutive integers to anyone who asks (perhaps using an automated system much like many mailing lists use for subscriptions - you fill in the template, send it in, get back e-mail containing a token/passwd send that back, and your site ID gets returned). There's 38 bits of empty space in site locals (250 billion numbers close enough) which would do for this, and '0' could continue to mean the "undetermined" (not globally unique) site local. | Such an address space would be useful, for instance, There are lots of uses - it would provide a stable I-D for security associations, ... | Such addresses (lets call them unique-local addresses) could be put in DNS | without concern for thier being mis-interpreted by other nodes. Yes, though they still add to the DNS payload when for the vast majority of users (everyone non-local) they're useless information. | Granted | when a node did a DNS lookup, it wouldn't know if a given unique-local | address was in the same site, No, considering aggregated sites (with multiple I-Ds) but a simple compare of her site ID token against mine would catch the majority of cases. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 00:23:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G8LhG14335 for ipng-dist; Fri, 16 Feb 2001 00:21:43 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G8LY214328 for ; Fri, 16 Feb 2001 00:21:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA28574 for ; Fri, 16 Feb 2001 00:21:34 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01402 for ; Fri, 16 Feb 2001 00:20:38 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id PAA17614; Fri, 16 Feb 2001 15:19:59 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1G8K0n00636; Fri, 16 Feb 2001 15:20:00 +0700 (ICT) From: Robert Elz To: "Paul Francis" cc: ipng@sunroof.eng.sun.com Subject: Re: summary of Re: another renumbering question In-reply-to: Your message of "Thu, 15 Feb 2001 01:37:57 PST." <000d01c097d9$049d77e0$8cc90518@smateo1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 15:20:00 +0700 Message-ID: <634.982311600@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 15 Feb 2001 01:37:57 -0800 From: "Paul Francis" Message-ID: <000d01c097d9$049d77e0$8cc90518@smateo1.sfba.home.com> | Robert Elz also made a good suggestion as to how hosts can learn the | site-local addresses of other hosts in the site (least-wise it seemed good | to me). But the state of this suggestion is that it exists in an email and | nowhere else (i.e., no internet draft), Yes. | so unless someone writes it up nothing will happen to it? I suspect that's true, and yes, it should get made into a draft. | (By the way Robert, are the ICMP "tell me your | site local addresses" and ICMP "site local source exiting the site" messages | you mention in your suggestion in existing drafts, or are these new messages | you are making up?) The former is certainly new. I thought that the latter existed already (and may in the form of destination unreachable code 3), but this is one which probably deserves an ICMP code of its own (that is: packet attempting to exit limited scope"). The same thing would be used for a link local source addr sent to a global address that is of link. These kinds of packet errors can exist now (without actually provoking them by suggesting they be used deliberately) can those who have router implementations indicate what you're using to report the error when you drop a packet because its source address would not be legal on the outgoing link? (code 2, "admin prohibited" is another possibility, but to me that implies more of it being a local policy issue, rather than a protocol violation). In any case, any "that packet didn't make it" return would cause the sending node to skip the site-local and try global. If that also fails then the host is just unreachable, whatever address is used. | In the absense of Robert's suggestion or Erik's draft | (draft-ietf-ipngwg-site-prefixes-05.txt) (both of which require changes to | existing implementations), Yes, the difference between the two is that mine only requires changes to implementations that want to use site-local - so can be phased into implementations over time. Erik's requires that everyone understand how to deal with site locals in the DNS before any are added. | I gather that there are only two possibilities: | | 1. Don't use site-local addresses at all. | 2. Use site-local addresses and two-faced DNS. | | Is this a reasonable summary? I think so. The first is a pretty simple outcome. The second probably means that only the larger sites, who can afford full time private DNS maintainers (ie: not outsourcing their DNS to a public server) will be able to use site-local - which is really the wrong outcome. Site locals are most needed by the smallest of sites which are most likely to renumber (like: to use on your home net, in an environment when you get a different global address every time you dial (or even just every month when you switch to a cheaper, r less overloaded, provider)). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 00:24:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G8Naa14353 for ipng-dist; Fri, 16 Feb 2001 00:23:36 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G8NK214339 for ; Fri, 16 Feb 2001 00:23:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27945 for ; Fri, 16 Feb 2001 00:23:20 -0800 (PST) Received: from audrey.enst-bretagne.fr (audrey.enst-bretagne.fr [192.108.115.9]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA13265 for ; Fri, 16 Feb 2001 00:23:19 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by audrey.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f1G8NH422648; Fri, 16 Feb 2001 09:23:17 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA03403; Fri, 16 Feb 2001 09:23:16 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f1G8NGO20667; Fri, 16 Feb 2001 09:23:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200102160823.f1G8NGO20667@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Dave Thaler" cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 addresses with embedded private IPv4 addresses In-reply-to: Your message of Thu, 15 Feb 2001 14:32:07 PST. <5B90AD65A9E8934987DB0C8C0762657420FD73@DF-BOWWOW.platinum.corp.microsoft.com> Date: Fri, 16 Feb 2001 09:23:16 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'd like to ask for some general consensus on the following questions: 1) Are "::10.1.1.1" and "::169.254.1.1" legal IPv6 addresses? (They look like global IPv6 addresses, but aren't globally unique.) RFC 2373 does not mention any such restriction, and so implies "yes". => no 2) Similarly, is "2002:0A01:0101:..." a legal IPv6 address? The current 6to4 draft implies "no". => no 3) Is it reasonable that the answers to the above two questions could be different? => no The argument is: even if these addresses seem legal in an internet *NOT* connected to the Internet, IPv6 provides local scoped and not ambiguous addresses which have none of RFC 1918 problems. Regards Francis.Dupont@enst-bretagne.fr PS: what is your purpose? Add this in BCP filters? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 00:27:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G8QYK14375 for ipng-dist; Fri, 16 Feb 2001 00:26:34 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G8QO214368 for ; Fri, 16 Feb 2001 00:26:24 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA29156 for ; Fri, 16 Feb 2001 00:26:24 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA24811 for ; Fri, 16 Feb 2001 00:26:23 -0800 (PST) Received: from 157.54.1.52 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Feb 2001 22:56:46 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 15 Feb 2001 22:56:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.12 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: summary of Re: another renumbering question Date: Thu, 15 Feb 2001 22:56:45 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9C3D@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: summary of Re: another renumbering question Thread-Index: AcCX2ZVL/T0r7XKwTCKC3GDum/gKxgACe4GQ From: "Richard Draves" To: "Paul Francis" , "Robert Elz" , "Brian E Carpenter" Cc: X-OriginalArrivalTime: 16 Feb 2001 06:56:45.0753 (UTC) FILETIME=[A0355A90:01C097E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1G8QP214369 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A good summary but let me add a few points. The Microsoft IPv6 implementation supports Erik's draft. It also puts site-local addresses in the DNS. And in normal home gateway scenarios (requires some administrative action to stop this) it will send RAs with a site-local prefix as well as a global prefix. Suppose a host X, not implementing Erik's draft, resolves a DNS name and gets back a global and a site-local address. If host X does not have a site-local address itself, and host X implements draft-ietf-ipngwg-default-addr-select-02, then the name resolver function will return the global address before the site-local address. So host X will use the right address. Suppose host X does not implement Erik's draft and does not implement draft-ietf-ipngwg-default-addr-select-02. Perhaps the name resolver function always returns addresses in the order it gets them from DNS. Then it's unpredictable which address host X will use. If it uses the site-local address it will probably have a lengthy timeout before falling back to the global address, but in the worst case the application/user might give up, or it might even end up communicating with the wrong host. Another possibility is that a DNS server can look at the source address of the DNS request. If the source adress is an IPv6 site-local address, then the DNS server can include site-local addresses in its reply. If the source address is an IPv6 global address, or an IPv4 address, then the DNS server can filter out site-local addresses. This introduces the constraint that a site has to contain a DNS server to use site-local addresses. This technique could be used in conjunction with Erik's draft. Rich > -----Original Message----- > From: Paul Francis [mailto:paul@francis.com] > Sent: Thursday, February 15, 2001 1:38 AM > To: Robert Elz; Brian E Carpenter > Cc: ipng@sunroof.eng.sun.com > Subject: summary of Re: another renumbering question > > > > Just an attempt to summarize this thread: > > Jim Bound thinks the use of site-local addresses is bad. > > Robert Elz things that the use of site-local addresses is ok, but that > two-faced DNS is bad. > > Other folks don't think two-faced DNS is so bad. (I'm in > this camp too...) > > Robert Elz also made a good suggestion as to how hosts can learn the > site-local addresses of other hosts in the site (least-wise > it seemed good > to me). But the state of this suggestion is that it exists > in an email and > nowhere else (i.e., no internet draft), so unless someone writes it up > nothing will happen to it? (By the way Robert, are the ICMP > "tell me your > site local addresses" and ICMP "site local source exiting the > site" messages > you mention in your suggestion in existing drafts, or are > these new messages > you are making up?) > > In the absense of Robert's suggestion or Erik's draft > (draft-ietf-ipngwg-site-prefixes-05.txt) (both of which > require changes to > existing implementations), I gather that there are only two > possibilities: > > 1. Don't use site-local addresses at all. > 2. Use site-local addresses and two-faced DNS. > > Is this a reasonable summary? > > PF > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 00:58:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G8ua114448 for ipng-dist; Fri, 16 Feb 2001 00:56:36 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G8uP214441 for ; Fri, 16 Feb 2001 00:56:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17005 for ; Fri, 16 Feb 2001 00:56:26 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA04947 for ; Fri, 16 Feb 2001 00:56:23 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id AAA01851; Fri, 16 Feb 2001 00:49:13 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <634.982311600@brandenburg.cs.mu.OZ.AU> References: <634.982311600@brandenburg.cs.mu.OZ.AU> Date: Fri, 16 Feb 2001 00:49:10 -0800 To: Robert Elz From: Steve Deering Subject: Re: summary of Re: another renumbering question Cc: "Paul Francis" , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:20 PM +0700 2/16/01, Robert Elz wrote: > From: "Paul Francis" > | (By the way Robert, are the ICMP "tell me your site local addresses" > | and ICMP "site local source exiting the site" messages > | you mention in your suggestion in existing drafts, or are these new > | messages you are making up?) > >The former is certainly new. I thought that the latter existed already >(and may in the form of destination unreachable code 3), but this is >one which probably deserves an ICMP code of its own (that is: packet >attempting to exit limited scope"). Yes, we did add a code point to ICMP Destination Unreachable for "beyond scope of source address" (Code 2). However, just now when I went to look for it, I discovered that the ICMPv6 update ID in which that code point was added has timed out of the ID directory. Ooops. >(code 2, "admin prohibited" is another possibility,... "admin prohibited" is Code 1. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 01:30:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G9TAK14510 for ipng-dist; Fri, 16 Feb 2001 01:29:10 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G9Sx214503 for ; Fri, 16 Feb 2001 01:29:00 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05043 for ; Fri, 16 Feb 2001 01:28:59 -0800 (PST) Received: from china.com (TCE-E-7-182-13.bta.net.cn [202.106.182.13]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA16764 for ; Fri, 16 Feb 2001 01:28:47 -0800 (PST) Received: from china.com([10.1.0.100]) by china.com(JetMail 2.5.3.0) with SMTP id jm23a8d624f; Fri, 16 Feb 2001 09:25:48 -0000 Received: from mercury.Sun.COM([192.9.25.1]) by china.com(JetMail 2.5.3.0) with SMTP id jm03a8c82ac; Thu, 15 Feb 2001 18:24:21 -0000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA25453; Thu, 15 Feb 2001 00:14:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05698; Thu, 15 Feb 2001 00:14:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1F899r12201 for ipng-dist; Thu, 15 Feb 2001 00:09:09 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1F88U212194 for ; Thu, 15 Feb 2001 00:08:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01849 for ; Thu, 15 Feb 2001 00:08:30 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07121 for ; Thu, 15 Feb 2001 00:08:30 -0800 (PST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1F86Qs24349; Thu, 15 Feb 2001 03:06:29 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id IAA04436; Thu, 15 Feb 2001 08:07:09 GMT Date: Thu, 15 Feb 2001 08:07:09 GMT Message-Id: <200102150807.IAA04436@qnsgs000.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 01:36:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G9ZDD14749 for ipng-dist; Fri, 16 Feb 2001 01:35:13 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G9Yx214734 for ; Fri, 16 Feb 2001 01:35:03 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21053 for ; Fri, 16 Feb 2001 01:34:59 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA16660 for ; Fri, 16 Feb 2001 01:34:58 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id BAA04331; Fri, 16 Feb 2001 01:28:10 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <609.982310655@brandenburg.cs.mu.OZ.AU> References: <609.982310655@brandenburg.cs.mu.OZ.AU> Date: Fri, 16 Feb 2001 01:28:07 -0800 To: Robert Elz From: Steve Deering Subject: Re: another renumbering question Cc: "Paul Francis" , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:04 PM +0700 2/16/01, Robert Elz wrote: > From: "Paul Francis" > > | On a separate note, I know this is probably just digging up dead > | discussions, but have people considered creating a new IPv6 space > | which is "globally unique but not globally routable" for use in > | this sort of internal site communications? > >The chief objection to this, as I understand it, has always been >how such things would get assigned, who would do that, on what >basis, etc. Exactly. The last thing we want to do is establish yet another numbering space that needs to be globally administered, which then becomes another ICANN political football (like our existing global name and numbering spaces), and for which we have to figure out some sort of allocation mechanism/policy to prevent anyone from coming along and grabbing such site IDs by the millions ("Hey, I'm going to be the next McDonalds, so I'm going to need a million site IDs! Trust me."), and for which we'll get dragged into the issue of charging money for site IDs (initially just to cover the cost of running the allocation service, of course, but then as a disincentive to grabbing a million addresses, eventually degrading into a fight to get a piece of the site ID allocator's revenue stream). And the other thing that would likely happen is that sites would obtain these non-globally-routable site IDs and then a few months later some of them would shop around to find an ISP who would agree to inject their (unaggregated) site IDs into the global routing system. Now maybe these fears are overblown, but looking at the current state of IP address allocation, DNS name allocation, and the growth of unaggregated prefixes in the BGP tables sure makes me wary about going in that direction. One could possibly finesse the problems of establishing a new numbering bureaucracy by exploiting an existing one, e.g., by saying that site can choose, say, one of its own Ethernet addresses (that is, a globally unique number from a space managed by the existing IEEE bureaucracy) to stick into the empty field of its site-locals -- unfortunately, there aren't enough free bits there to hold an Ethernet address. How about using IPv4 addresses for that purpose? Well, some sites today can't get even one IPv4 address, and that's likely to get worse. Besides, we already have half a dozen IPv6 address formats that have IPv4 addresses embedded in them somewhere, and I shudder to have to explain yet another one. Use a random number generator? Well, someone would have to figure out the Birthday Probability of duplicates and understand how bad the consequences would be if two sites with the same site ID got accidentally or intentionally merged, even if it were a very unlikely event. And then there may be other counter arguments I've forgotten. It's certainly true that we've been over this question a number of times in the past, so if we're really going to dredge it up again, we should at least do some digging in the archives to make sure we don't spend a lot of time rediscovering (or worse, failing to rediscover) previously identified issues. Steve the Wet Blanket -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 01:43:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G9fix14863 for ipng-dist; Fri, 16 Feb 2001 01:41:44 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G9fX214856 for ; Fri, 16 Feb 2001 01:41:33 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1G9fQL688024; Fri, 16 Feb 2001 01:41:26 -0800 (PST) Date: Fri, 16 Feb 2001 10:40:44 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: New idea for Router Sol/Adv and Mobility To: "T.J. Kniveton" Cc: mobile-ip@marvin.corpeast.baynetworks.com, ipng@sunroof.eng.sun.com, "Powell, Ken" In-Reply-To: "Your message with ID" <3A8B1054.68209661@Kniveton.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Solution > -------- > The solution to this problem involves two steps: relaxing a Neighbor > Discovery rule on the HA and MN, and creating a mobility processing rule > on the HA and MN. Now RS/RA can be sent without any special Mobile IP > headers, and look very similar to normal RS/RA, except that they are > routed unicast packets. This solution is very general, and uses the COA > and HA addr only, so it does not matter whether the MN does, or does > not, have an HAddr. Are you proposing using these rules solely for the initial configuration of the home addresses or do you see these as new rules as something that would apply to all information carried in RAs and RSs between the HA and the mobile away from home? If it is the latter it might be cleaner to make this been different ICMP types (e.g. Home Agent Solicitation and Home Agent Advertisement) that would carry the ND options like the prefixes. > RELAXING TTL: > 1. An unicast Router Solicitation arriving at an Home Agent is NOT > discarded if the TTL < 255 (off-link, from MN). > 2. An unicast Router Advertisement arriving at a Mobile Node is NOT > discarded if the TTL < 255 (off-link, from HA) > > MOBILITY PROCESSING: > 1. The Home Agent receiving a Router Solicitation with TTL<255 (from off > link) knows that this is a request from a MN, and will include extra > Prefix Information as per the draft. This is were having a different ICMP type would make things cleaner. > 2. The Mobile Node receiving a Router Advertisement with TTL<255 knows > that this was sent from a HA and contains HA prefix info and it should > be processed differently by Mobile IP code to create HAddr(s). > SECURITY: > The Router Solicitation must be protected by an Authentication Header. > This is already a requirement. > The Router Advertisement should/may be encrypted. If it is not, note > that prefix information about the home network will be available for > inspection along the path the RA travels. This security issue is the > same as what exists in the current version. Encrypting the RA doesn't seem to be useful unless you restrict the COAs that can be used to talk to the HA. If somebody wants to discover the RA content they can just 1. set up an ESP security association between their address (COA) and the HA. 2. send a RS to the HA. 3. The HA will send the encrypted RA back to them and they decrypt it. Thus I think it is a fundamental aspect of the problem (trying to allocate a home address before doing a secured BU with the HA) that anybody can discover whatever you send to a claimed COA for a mobile node. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 01:49:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G9mue14902 for ipng-dist; Fri, 16 Feb 2001 01:48:56 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G9mk214895 for ; Fri, 16 Feb 2001 01:48:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22335 for ; Fri, 16 Feb 2001 01:48:46 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03537 for ; Fri, 16 Feb 2001 01:48:43 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA25521; Fri, 16 Feb 2001 16:48:04 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1G9m4n01146; Fri, 16 Feb 2001 16:48:04 +0700 (ICT) From: Robert Elz To: Steve Deering cc: "Paul Francis" , ipng@sunroof.eng.sun.com Subject: Re: summary of Re: another renumbering question In-reply-to: Your message of "Fri, 16 Feb 2001 00:49:10 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 16:48:04 +0700 Message-ID: <1144.982316884@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 16 Feb 2001 00:49:10 -0800 From: Steve Deering Message-ID: | Yes, we did add a code point to ICMP Destination Unreachable for | "beyond scope of source address" (Code 2). I thought I remembered that one... | >(code 2, "admin prohibited" is another possibility,... | "admin prohibited" is Code 1. Oops yes - I read down to code three, and just assumed that the preceding one would be 2, without checking properly... kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 02:00:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1G9x8w14940 for ipng-dist; Fri, 16 Feb 2001 01:59:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1G9wx214933 for ; Fri, 16 Feb 2001 01:58:59 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06779 for ; Fri, 16 Feb 2001 01:58:58 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA29338 for ; Fri, 16 Feb 2001 01:58:51 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA26053; Fri, 16 Feb 2001 16:58:45 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1G9wSn01165; Fri, 16 Feb 2001 16:58:33 +0700 (ICT) From: Robert Elz To: "Richard Draves" cc: "Paul Francis" , "Brian E Carpenter" , ipng@sunroof.eng.sun.com Subject: Re: summary of Re: another renumbering question In-reply-to: Your message of "Thu, 15 Feb 2001 22:56:45 PST." <7695E2F6903F7A41961F8CF888D87EA81C9C3D@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 16:58:28 +0700 Message-ID: <1163.982317508@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 15 Feb 2001 22:56:45 -0800 From: "Richard Draves" Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9C3D@red-msg-06.redmond.corp.microsoft.com> | The Microsoft IPv6 implementation supports Erik's draft. I'm not sure that implementing a draft which had (until last week) expired is a wonderful idea (other than for a limited test of the mechanisms anyway). | It also puts site-local addresses in the DNS. Grunge. | And in normal home gateway scenarios | (requires some administrative action to stop this) it will send RAs with | a site-local prefix as well as a global prefix. That one I don't mind - the "normal home gateway" is exactly where site locals are most needed. | If it uses the | site-local address it will probably have a lengthy timeout before | falling back to the global address, but in the worst case the | application/user might give up, or it might even end up communicating | with the wrong host. Yes, it is because this can happen to nodes that haven't implemented Erik's draft that I don't think that the mechanisms proposed there can work (and ideally never be let loose on an unsuspecting world). | Another possibility is that a DNS server can look at the source address | of the DNS request. That's just two faced DNS, which doesn't work in general, and in particular doesn't work here... | If the source adress is an IPv6 site-local address, | then the DNS server can include site-local addresses in its reply. Typically the resolver in a node sends a query to a local cache. Chances are it will always use site local for that if it can. The cache then tries to find the authoritative server, that means (in general, even to find your own local servers) starting at the root and climbing down the chain. The root gives A records for the COM servers (those won't be site local one hopes). The COM servers give A records for the microsoft.com servers (they won't be site local either), your cache then sends to one of those servers, using the address you have just been handed, so your cache sends to a global addr, and hence uses a global source addr, and thus gets back only global addresses. To make two faced DNS work requires a lot of local configuration and careful planning and management - which is exactly what your typical home network is not going to have (nor is it typically going to have a DNS server at all). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 02:01:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GA0xj14959 for ipng-dist; Fri, 16 Feb 2001 02:00:59 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GA0m214945 for ; Fri, 16 Feb 2001 02:00:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07523 for ; Fri, 16 Feb 2001 02:00:47 -0800 (PST) Received: from mail.gsut.edu.cn (mail.gsut.edu.cn [202.201.32.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21009 for ; Fri, 16 Feb 2001 03:00:40 -0700 (MST) Message-Id: <200102161000.DAA21009@lukla.Sun.COM> Received: from TMD ([202.201.47.10]) by mail.gsut.edu.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id 1033RXDY; Fri, 16 Feb 2001 17:57:14 +0800 Date: Fri, 16 Feb 2001 18:7:16 +0800 From: ÂÀµÂÐñ Reply-To: ludx@gsut.edu.cn To: "ipng@sunroof.eng.sun.com" CC: "users@ipv6.org" , "snap-users@kame.net" , "6bone@ISI.EDU" <6bone@ISI.EDU> Subject: Who has the experience in configurating the wu-ftpd+IPv6patch. Organization: Gansu University of Technology NIC tel:(0931£­2757939) X-mailer: FoxMail 3.1 beta [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Who has the experience in configurating the wu-ftpd+IPv6patch.Can you give me a configuration example. Thanks. rex.lv ludx@gsut.edu.cn -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 02:53:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GApkH15056 for ipng-dist; Fri, 16 Feb 2001 02:51:46 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GApX215049 for ; Fri, 16 Feb 2001 02:51:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13021 for ; Fri, 16 Feb 2001 02:51:33 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18424 for ; Fri, 16 Feb 2001 02:51:32 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1GApVC22815 for ; Fri, 16 Feb 2001 11:51:31 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Feb 16 11:51:30 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZ6B2M>; Fri, 16 Feb 2001 11:47:57 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6A4D@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'T.J. Kniveton'" , "Powell, Ken" , "'mobile-ip@standards.nortelnetworks.com'" , ipng Subject: RE: New idea for Router Sol/Adv and Mobility Date: Fri, 16 Feb 2001 11:51:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello I basically like the idea of not tunnelling. Tunnelling doesn't do anything for you actually. But I have some comments on the details you mentioned below. I'll send a separate mail with a similar proposal to yours but with small modifications and attempt to give some hints for the authorisation problem. Regards, Hesham > > Under this proposal, the Mobile Node will have to re-establish the > > Security Association between the Home Agent and its Care-Of Address > > every time it moves to support IPsec requirements for Router > > Advertisements. How does this fit in with the process of > > forming the new care-of address and updating bindings? Will > > this cause additional hand-off delays? > > > > Good question. Where this question leads is, how can the HA trust an MN > when > the MN does not have a trustable identity based on a Home network IP > address? Does it make sense to base security associations on IP addresses > when the addresses themselves are ephemeral and can't be associated to > Identity without the involvement of an outside entity? > > Clearly this is already a hot topic. Rather than trying to solve it here, > perhaps I can offer a compromise which allows for the possibility of > future > elaboration. > => I'm afraid we can't skip this one. After all this is one of the seeds for the authorisation discussion. Which is one of the reasons holding the draft as far as I know. > Here's the recipe: start with Draft 13. Now remove encapsulation from RSs > (this is unnecessary and inconsistent). Add the rules for TTL<255 and > mobility processing, as stated in my previous message. Stir in addressing > as > follows: > > 1. The RS is sent with a HAddr option. The HAddr contains the MN's Home > Address (naturally), EXCEPT if the MN has not configured one, in which > case > it MAY insert the COA instead. > => Well, we're talking about a start up procedure here. So let's assume the MN doesn't have a home address yet. Therefore there is no need to have a HAddress option. I'll explain in a second email how I thought we could replace this. > 2. The HA sends an RA using a routing header, as usual. The RHdr contains > whatever was in the HAddr option - namely, the Home Address, EXCEPT if the > COA was in the RS's HAddr option, it goes in the routing header (we could > just leave the routing header off, alternatively). > => Yeah. I think you can leave off the routing header for sure. > > How does the home agent determine which mobile node sent the > > Router Solicitation? Can the Care-of address on a mobile node > > be relied on for this? > > I contend it doesn't matter. You just need to know that it was sent from a > mobile node. > => But how can the HA verify that based on your proposal ? Anyone can include a Home address option in their packets. > >[Mattias Pettersson wrote:] > >> > >> Will we open up a security hole or possible denial-of service > >> attack by let's say flood a HA with RSes (that don't require > >> authentication), now that we can send them over multiple hops? > >> > > > > Yes, this does look like a problem, but I think its just as > > serious in draft 13. Any node could repeatedly send router > > solicits with the mobile node's care-of address (and home > > address). The home agent would send a complete Router > > Advertisement to the mobile node for each Router Solicit, > > possibly eating up expensive wireless bandwidth. Perhaps > > the Router Solicit should be IPsec protected? > > The problem isn't bandwidth here. The security issue is that anyone can > see > the prefix information about that potentially private network. > => Is that an issue really ? I mean after all _everyone_ will see that prefix when they do a DNS lookup on the MN. I don't think this would be a problem. Unless I missed your point ? > You are > thereby exposing the fact that a certain IP address is a router, that it's > also a home agent, and what some or all of the prefixes on that link are. > And you're exposing it to anyone along the path to the MN. > => You expose your home link's prefix as soon as you start communicating with anyone. > Regarding the bandwidth issue, who cares that the HA will send RAs to the > mobile? If you want to use the MN's bandwidth, nothing stops you from just > sending it packets yourself! Anyway, the HA could protect against this by > limiting the rate at which it sends RAs. > => Agreed. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 03:14:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GBDAw15103 for ipng-dist; Fri, 16 Feb 2001 03:13:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GBCv215092 for ; Fri, 16 Feb 2001 03:12:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12659 for ; Fri, 16 Feb 2001 03:12:53 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA29158 for ; Fri, 16 Feb 2001 04:12:52 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1GBCpC13034 for ; Fri, 16 Feb 2001 12:12:51 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Feb 16 12:12:51 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1CVZ6CG2>; Fri, 16 Feb 2001 12:09:17 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6A4E@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'T.J. Kniveton'" , "Powell, Ken" , "'mobile-ip@standards.nortelnetworks.com'" , ipng Subject: RE: New idea for Router Sol/Adv and Mobility Date: Fri, 16 Feb 2001 12:12:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello again, There is a number of problems that need to be solved I think to get the right proposal. - ND does not allow you to send an RS outside your subnet. - MNs need to get the Home network prefix to configure themselves with a Home address. - To be able to send an RS with TTL <255 you need to be authorised to do so. So based on this list, I don't think that tunnelling the RS from the MN to the HA will buy us anything. Strictly speaking the HA can drop the packet anyway if he MN is not authorised to send an RS across subnets. So I think one way to solve this is to send the RS as follows: Src_addr : MN CoA Dst_addr : HA address TTL < 255 Obviously secured by AH or ESP. Now we're faced with difficult task of authorising this user to send this message. There are two options that I can think of: 1. PKI If the MN has a PK and the HA is aware of all PKs for all MNs that it serves, then all the HA needs to do is be able to verify the identity of the sender. Ie. verify that the sender is actually _one_of its MNs. This verification is obviously based on using the PK as an identifier for the MN. Associated with that Key is the level of authorisation. 2. AAA The MN already has a secret key with AAAH. AAAH can be used to generate a temporary SA between the MN and the HA so that the MN can authenticate itself o the HA. The MN can identify itself to the AAAH based on the NAI and NOT the Home address, as it clearly doesn't know that yet. When the AAAH establishes this temporary SA, it can provide the HA with the MN's NAI, authorisation level ...etc so that the HA can be sure it is one of it's nodes. This proposal (for AAAH to establish SAs) was already prsented in San Diego. http://search.ietf.org/internet-drafts/draft-soliman-mobileip-routeopt-mipv6 -00.txt Comments ? Regards, Hesham PS: After writing this mail I saw Erik's mail ! I should have read it first and saved myself some typing :) I think the model is very similar but I'm sending this anyway for the authorisation part. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 06:09:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GE7dP15313 for ipng-dist; Fri, 16 Feb 2001 06:07:39 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GE7T215306 for ; Fri, 16 Feb 2001 06:07:30 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25209 for ; Fri, 16 Feb 2001 06:07:30 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07385 for ; Fri, 16 Feb 2001 06:07:30 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA19458; Fri, 16 Feb 2001 06:07:26 -0800 Received: from hursley.ibm.com (lig32-226-108-140.us.lig-dial.ibm.com [32.226.108.140]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA20450; Fri, 16 Feb 2001 06:07:23 -0800 Message-ID: <3A8D3387.BD08A95D@hursley.ibm.com> Date: Fri, 16 Feb 2001 08:04:55 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dave Thaler CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 addresses with embedded private IPv4 addresses References: <5B90AD65A9E8934987DB0C8C0762657420FD73@DF-BOWWOW.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 6to4 is meant to do more than imply it: > The V4ADDR MUST be > a duly allocated global IPv4 address, which MUST be unique within the > private network. The Intranet thereby obtains globally unique IPv6 > addresses even if it is internally using private IPv4 addresses [RFC > 1918]. And BTW it isn't a draft; it's an RFC. I don't know if the announcement is out, because I don't seem to be able to receive email this morning, only send it, but the authors' 48 hour check on the RFC just finished. Personally I think the answer should be to insist on global addresses in IPv4-compatible addresses too. The scenarios using NAT addresses here are too horrible to contemplate. Brian Dave Thaler wrote: > > I'd like to ask for some general consensus on the following questions: > > 1) Are "::10.1.1.1" and "::169.254.1.1" legal IPv6 addresses? > (They look like global IPv6 addresses, but aren't globally unique.) > RFC 2373 does not mention any such restriction, and so > implies "yes". > > 2) Similarly, is "2002:0A01:0101:..." a legal IPv6 address? > The current 6to4 draft implies "no". > > 3) Is it reasonable that the answers to the above two questions > could be different? > > (I'd personally rather the answer be the same for both, that > answer probably being "no", as this avoids a lot of ugly problems.) > > And before anyone responds saying that "::10.1.1.1" should be > allowed so that you can talk between two hosts in a private IPv4 > network, keep in mind that draft-templin-ngtrans-v6v4compat-*.txt > allows you to do the same thing with "fe80::200:5efe:10.1.1.1", which > is clearly a link-local address (on an encapsulation link covering the > private area) and so avoids the ugly problems "::10.1.1.1" has. > > -Dave > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 06:11:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GEAJ815349 for ipng-dist; Fri, 16 Feb 2001 06:10:19 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GEA9215342 for ; Fri, 16 Feb 2001 06:10:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25455 for ; Fri, 16 Feb 2001 06:10:10 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05445 for ; Fri, 16 Feb 2001 06:10:08 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id QAA04562; Fri, 16 Feb 2001 16:20:40 +0200 Date: Fri, 16 Feb 2001 16:20:40 +0200 Message-Id: <200102161420.QAA04562@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: RA and Default routes? Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While implement Host side of RA, I suddently noticed that my code makes no difference for RA with Router Lifetime = 600 and RA with Prefix ::0/0, L=0, A=0, Lifetime = 600 Both create effectively a default route pointing to this router. Am I doing something wrong? A default route could be deleted by having a prefix option ::0/0 with lifetime = 0. Additionally in RFC-2461, 6.3.5 says... Whenever the Lifetime of an entry in the Default Router List expires, that entry is discarded. When removing a router from the Default Router list, the node MUST update the Destination Cache in such a way that all entries using the router perform next-hop determination again rather than continue sending traffic to the (deleted) router. Suppose we had RA with Router Lifetime = 600 Prefix X/48, L=0, A=0, Lifetime = 1200 The way 6.3.5 is written, seems to say that both ::0/0 and X/48 should be removed. However, I think only default route should exipire, but router continues to be available for X/48 still (another 600 secods). The same question arises also, when router sends RA with Router Lifetime=0. Should only default route disappear or all routes? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 07:02:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GExqS15441 for ipng-dist; Fri, 16 Feb 2001 06:59:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GExh215434 for ; Fri, 16 Feb 2001 06:59:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02197 for ; Fri, 16 Feb 2001 06:59:44 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22856 for ; Fri, 16 Feb 2001 06:59:43 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f1GEx3226935; Fri, 16 Feb 2001 15:59:04 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA19270; Fri, 16 Feb 2001 15:58:57 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f1GEwqO23381; Fri, 16 Feb 2001 15:58:56 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200102161458.f1GEwqO23381@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: RA and Default routes? In-reply-to: Your message of Fri, 16 Feb 2001 16:20:40 +0200. <200102161420.QAA04562@burp.tkv.asdf.org> Date: Fri, 16 Feb 2001 15:58:52 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: While implement Host side of RA, I suddently noticed that my code makes no difference for RA with Router Lifetime = 600 and RA with Prefix ::0/0, L=0, A=0, Lifetime = 600 Both create effectively a default route pointing to this router. Am I doing something wrong? => perhaps, Prefix ::0/0 is an illegal prefix... Suppose we had RA with Router Lifetime = 600 Prefix X/48, L=0, A=0, Lifetime = 1200 The way 6.3.5 is written, seems to say that both ::0/0 and X/48 should be removed. => you mix up router lifetime (which is in fact the lifetime as a default router) and prefix lifetimes (which are the lifetimes of the prefix). The router is removed from the default router list when *its* lifetime is expired, this should have no effect on the prefix list. The same question arises also, when router sends RA with Router Lifetime=0. => this *only* means the router is not suitable as a default router, nothing more. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 07:20:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GFIko15469 for ipng-dist; Fri, 16 Feb 2001 07:18:46 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GFIb215462 for ; Fri, 16 Feb 2001 07:18:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04763 for ; Fri, 16 Feb 2001 07:18:33 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA10112 for ; Fri, 16 Feb 2001 07:18:31 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA04707; Fri, 16 Feb 2001 17:28:56 +0200 Date: Fri, 16 Feb 2001 17:28:56 +0200 Message-Id: <200102161528.RAA04707@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: ipng@sunroof.eng.sun.com In-reply-to: <200102161458.f1GEwqO23381@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Fri, 16 Feb 2001 15:58:52 +0100) Subject: Re: RA and Default routes? Reply-to: Markku.Savela@iki.fi References: <200102161458.f1GEwqO23381@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => you mix up router lifetime (which is in fact the lifetime as a default > router) and prefix lifetimes (which are the lifetimes of the prefix). > The router is removed from the default router list when *its* lifetime > is expired, this should have no effect on the prefix list. Actually, I had the misunderstanding that RA prefix option with L=0 and A=0 was a useful way for router to inform, that it is willing to route the matching addresses. I though this was a nice feature... So, if I see prefix option with L=0 and A=0, it should be totally ignored? (and not give the useful semantics to it?). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 07:51:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GFoA215564 for ipng-dist; Fri, 16 Feb 2001 07:50:10 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GFo2215557 for ; Fri, 16 Feb 2001 07:50:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11323 for ; Fri, 16 Feb 2001 07:50:01 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12274 for ; Fri, 16 Feb 2001 07:49:41 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1GFnTg12024 for ; Fri, 16 Feb 2001 09:49:39 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 16 Feb 2001 09:49:30 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <16XNBG4F>; Fri, 16 Feb 2001 09:49:30 -0600 Message-ID: To: paul@francis.com, kre@munnari.OZ.AU, brian@hursley.ibm.com Cc: Jim.Bound@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: another renumbering question Date: Fri, 16 Feb 2001 09:49:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > On a separate note, I know this is probably just digging up dead > discussions, but have people considered creating a new IPv6 > space which is > "globally unique but not globally routable" for use in this > sort of internal > site communications? Such an address space would be useful, > for instance, > when merging two sites (which, if using site-local addresses, > will require > renumbering of one of the sites). > > Such addresses (lets call them unique-local addresses) could > be put in DNS > without concern for thier being mis-interpreted by other > nodes. Granted > when a node did a DNS lookup, it wouldn't know if a given unique-local > address was in the same site, but it could learn easily by > just sending a > packet to that address and either succeeding or getting an ICMP dest > unreachable. I was thinking on this too the other day. We have room for additional scopes. Would an organizational scope fit your model which would be > than site-local. Then multisited servers would only hold organizational and avoid the global address if they want to. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 09:43:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GHfD915820 for ipng-dist; Fri, 16 Feb 2001 09:41:13 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GHev215803 for ; Fri, 16 Feb 2001 09:40:57 -0800 (PST) Received: from lillen (gbl-dhcp-212-200.France.Sun.COM [129.157.212.200]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1GHenL742475; Fri, 16 Feb 2001 09:40:49 -0800 (PST) Date: Fri, 16 Feb 2001 14:04:49 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: another renumbering question To: Paul Francis Cc: Robert Elz , Brian E Carpenter , Jim.Bound@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <000e01c097d9$04efdda0$8cc90518@smateo1.sfba.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is a lot of similarity architecturally between net 10 in IPv4 and site > local addresses > in IPv6. Niether can be globally routed. Both spaces are re-used by large > numbers > of sites, and from casual inspection of a site-local address, outside the > context of the inspection point, you can't tell what site it belongs to. > And clearly people feel a need to use them or we wouldn't be > having this discussion. I think there are two motivations for site-locals (that not everybody agrees with): 1. For sites that are isolated i.e. do not have a global prefix. 2. To completely isolate traffic local to a site from site-renumbering events. I think most people agree with #1, but some think that #1 alone isn't necessarily a good enough reason to have site-local addresses in the architecture. If we had a mechanism to handle #2 without using site-locals we could avoid a lot of complexity. But handling #2, in my opinion, requires not only being able to make long-running TCP connections survive renumbering, but also somehow dealing with UDP (and TCP) applications which retain IP addresses longer than the ttl indicated by DNS. While fixing the applications might be easy in priciple, tracking down all the places where an application might store an IP address for a longish time, is quite difficult; much more difficult than the semi-automatic porting of an application from IPv4 to IPv6. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 09:43:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GHfVH15830 for ipng-dist; Fri, 16 Feb 2001 09:41:31 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GHf4215811 for ; Fri, 16 Feb 2001 09:41:04 -0800 (PST) Received: from lillen (gbl-dhcp-212-200.France.Sun.COM [129.157.212.200]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1GHf0L742519; Fri, 16 Feb 2001 09:41:00 -0800 (PST) Date: Fri, 16 Feb 2001 14:12:34 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: summary of Re: another renumbering question To: Richard Draves Cc: Paul Francis , Robert Elz , Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <7695E2F6903F7A41961F8CF888D87EA81C9C3D@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Another possibility is that a DNS server can look at the source address > of the DNS request. If the source adress is an IPv6 site-local address, > then the DNS server can include site-local addresses in its reply. If > the source address is an IPv6 global address, or an IPv4 address, then > the DNS server can filter out site-local addresses. This introduces the > constraint that a site has to contain a DNS server to use site-local > addresses. This technique could be used in conjunction with Erik's > draft. This runs into trouble with DNSsec since DNSsec signs RRsets. Thus the DNS server would need a SIG for AAAA/A6 with site locals and another SIG for AAAA/A6 without the site-locals. Also, this has problem with recursive queries at least when the recursing name server runs on a box that belongs to two different site-local zones. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 09:43:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GHfiB15838 for ipng-dist; Fri, 16 Feb 2001 09:41:44 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GHfC215819 for ; Fri, 16 Feb 2001 09:41:12 -0800 (PST) Received: from lillen (gbl-dhcp-212-200.France.Sun.COM [129.157.212.200]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1GHf7L742547; Fri, 16 Feb 2001 09:41:08 -0800 (PST) Date: Fri, 16 Feb 2001 14:15:03 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: summary of Re: another renumbering question To: Paul Francis Cc: Robert Elz , Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <000d01c097d9$049d77e0$8cc90518@smateo1.sfba.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In the absense of Robert's suggestion or Erik's draft > (draft-ietf-ipngwg-site-prefixes-05.txt) (both of which require changes to > existing implementations), I gather that there are only two possibilities: > > 1. Don't use site-local addresses at all. with the exception that an isolated site (with no global addresses) can use site-local addresses all it wants. > 2. Use site-local addresses and two-faced DNS. > > Is this a reasonable summary? I think so. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 10:31:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GITnX16051 for ipng-dist; Fri, 16 Feb 2001 10:29:49 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GITe216044 for ; Fri, 16 Feb 2001 10:29:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20319 for ; Fri, 16 Feb 2001 10:29:40 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA14657 for ; Fri, 16 Feb 2001 10:29:39 -0800 (PST) Received: from 157.54.1.52 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Feb 2001 10:08:04 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 16 Feb 2001 10:07:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.12 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: another renumbering question Date: Fri, 16 Feb 2001 10:07:42 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9C3E@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: another renumbering question Thread-Index: AcCYQDnij4LFE4/WSp6FJOR4zkiNPgAApT4g From: "Richard Draves" To: "Erik Nordmark" , "Paul Francis" Cc: "Robert Elz" , "Brian E Carpenter" , , X-OriginalArrivalTime: 16 Feb 2001 18:07:43.0153 (UTC) FILETIME=[5B7D1A10:01C09843] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1GITf216045 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think there are two motivations for site-locals (that not everybody > agrees with): > 1. For sites that are isolated i.e. do not have a global prefix. > 2. To completely isolate traffic local to a site from > site-renumbering events. Let me add a third motivation - site-local addresses allow for very simple security policies or filters. For example the default configuration for a file server might be to provide service only to site-local clients. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 10:44:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GIhAa16110 for ipng-dist; Fri, 16 Feb 2001 10:43:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GIh1216103 for ; Fri, 16 Feb 2001 10:43:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23489 for ; Fri, 16 Feb 2001 10:43:01 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA24367 for ; Fri, 16 Feb 2001 10:43:00 -0800 (PST) Received: from 157.54.1.52 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Feb 2001 10:20:49 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 16 Feb 2001 10:20:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.12 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: RA and Default routes? Date: Fri, 16 Feb 2001 10:20:31 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80130CC3D@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RA and Default routes? Thread-Index: AcCYLBx7BCImkmXQTE+uxdlbUs7/PwAGMewg From: "Richard Draves" To: Cc: X-OriginalArrivalTime: 16 Feb 2001 18:20:31.0647 (UTC) FILETIME=[258BFAF0:01C09845] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1GIh2216104 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => you mix up router lifetime (which is in fact the > lifetime as a default > > router) and prefix lifetimes (which are the lifetimes of > the prefix). > > The router is removed from the default router list when > *its* lifetime > > is expired, this should have no effect on the prefix list. > > Actually, I had the misunderstanding that RA prefix option with L=0 > and A=0 was a useful way for router to inform, that it is willing to > route the matching addresses. I though this was a nice feature... > > So, if I see prefix option with L=0 and A=0, it should be totally > ignored? (and not give the useful semantics to it?). Yes, your processing of a prefix option should be based on which flag bits are enabled. If all the flag bits are off, then the prefix option is totally ignored. See draft-draves-ipngwg-router-selection-00 for the functionality you were thinking about. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 10:48:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GIlgG16129 for ipng-dist; Fri, 16 Feb 2001 10:47:42 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GIlV216122 for ; Fri, 16 Feb 2001 10:47:32 -0800 (PST) Received: from lillen (gbl-dhcp-212-200.France.Sun.COM [129.157.212.200]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1GIlNL757007; Fri, 16 Feb 2001 10:47:23 -0800 (PST) Date: Fri, 16 Feb 2001 19:46:44 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RA and Default routes? To: Markku.Savela@iki.fi Cc: Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200102161528.RAA04707@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So, if I see prefix option with L=0 and A=0, it should be totally > ignored? (and not give the useful semantics to it?). Yes, such a prefix doesn't carry any semantics for Neighbor discovery and stateless addrconf purposes. But I believe Mobile IPv6 defines a 3rd flag for the prefix options (R) thus one might see prefixes with L=0, A=0, R=1. And there might be other future additions of flags, Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 11:03:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GJ1dj16151 for ipng-dist; Fri, 16 Feb 2001 11:01:39 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GJ1U216144 for ; Fri, 16 Feb 2001 11:01:30 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08627 for ; Fri, 16 Feb 2001 11:01:29 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07322 for ; Fri, 16 Feb 2001 11:01:08 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1GJ2Uw19166 for ; Fri, 16 Feb 2001 13:02:35 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 16 Feb 2001 13:00:57 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <16XNBKHR>; Fri, 16 Feb 2001 13:00:57 -0600 Message-ID: To: richdr@microsoft.com, Erik.Nordmark@eng.sun.com, paul@francis.com Cc: kre@munnari.OZ.AU, brian@hursley.ibm.com, Jim.Bound@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: another renumbering question Date: Fri, 16 Feb 2001 13:00:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk rich, but unlike the other two uses yours has alternatives like using IPsec. yours is a weaker reason for them as the reason was for private addresses in IPv4. /jim > -----Original Message----- > From: ext Richard Draves [mailto:richdr@microsoft.com] > Sent: Friday,February 16,2001 1:08 PM > To: Erik Nordmark; Paul Francis > Cc: Robert Elz; Brian E Carpenter; Jim.Bound@nokia.com; > ipng@sunroof.eng.sun.com > Subject: RE: another renumbering question > > > > I think there are two motivations for site-locals (that not > everybody > > agrees with): > > 1. For sites that are isolated i.e. do not have a global prefix. > > 2. To completely isolate traffic local to a site from > > site-renumbering events. > > Let me add a third motivation - site-local addresses allow for very > simple security policies or filters. For example the default > configuration for a file server might be to provide service only to > site-local clients. > > Rich > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 11:11:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GJAMi16218 for ipng-dist; Fri, 16 Feb 2001 11:10:22 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GJAI216211 for ; Fri, 16 Feb 2001 11:10:18 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f1GJ7v312619 for ipng@sunroof.eng.sun.com; Fri, 16 Feb 2001 11:07:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1EJG3211507 for ; Wed, 14 Feb 2001 11:16:04 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11740 for ; Wed, 14 Feb 2001 11:16:02 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03246 for ; Wed, 14 Feb 2001 11:15:44 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id CB88B76346; Wed, 14 Feb 2001 21:15:27 +0200 (EET) Message-ID: <3A8AD9CA.8040604@piuha.net> Date: Wed, 14 Feb 2001 21:17:30 +0200 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-icclin i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com Cc: jari.arkko@ericsson.com, pekka.nikander@nomadiclab.com, kivinen@ssh.fi, mtr@ssh.fi Subject: ICMPv6 and IPsec drafts Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi. We've published two internet drafts around the use of IPsec in the context of ICMPv6. Here are the URLs to the drafts as well as the abstracts. Feedback and comments would be greatly appreciated! In particular, we'd be interested in hearing how other folks who have implemented IPsec in an IPv6 environment have dealt with the issues discussed in the first draft. Title: Effects of ICMPv6 on IKE and IPsec Policies Author: J. Arkko Abstract: The ICMPv6 protocol provides many functions which in IPv4 were either non-existent or provided by lower layers. IPv6 architecture also makes it possible to secure all IP packets using IPsec, even ICMPv6 messages. IPsec architecture has a Security Policy Database that specifies which traffic is protected, and how. It turns out that the specification of policies in the presence of ICMPv6 traffic is hard. Sound looking policies may easily lead to loops: The establishment of security requires ICMPv6 messages which can't be sent since security hasn't been established yet. The purpose of this draft is to inform system administrators and IPsec implementors in which manner they can handle the ICMPv6 messages. Common understanding of the way that these messages are handled is also necessary for interoperability, in case vendors hardcode such rules in to products. http://search.ietf.org/internet-drafts/draft-arkko-icmpv6-ike-effects-00.txt Title: Manual SA Configuration for IPv6 Link Local Messages Authors: J. Arkko, P. Nikander, T. Kivinen, M. Rossi Abstract: This draft discusses the use of manually configured IPsec SAs to protect ICMPv6 messages such as router discovery and address resolution on the local link. IPsec SAs are generally identified by the triple . For the ICMPv6 messages configuring the SAs requires some effort, however, since there are multiple known destination addresses plus a number of addresses that depend on the physical link addresses. This draft describes the security implications of protecting or not protecting the link local ICMPv6 messages, lists the SAs that must be configured manually, and discusses some approaches for reducing configuration effort. http://search.ietf.org/internet-drafts/draft-arkko-manual-icmpv6-sas-00.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 11:12:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GJBGO16245 for ipng-dist; Fri, 16 Feb 2001 11:11:16 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GJB9216238 for ; Fri, 16 Feb 2001 11:11:09 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f1GJ8mT12650 for ipng@sunroof.eng.sun.com; Fri, 16 Feb 2001 11:08:48 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GJ7L216185 for ; Fri, 16 Feb 2001 11:07:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10185 for ; Fri, 16 Feb 2001 11:07:21 -0800 (PST) Received: from dr-evil.shagadelic.org ([208.176.2.162]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05733 for ; Fri, 16 Feb 2001 11:07:21 -0800 (PST) Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 5BD54D203; Fri, 16 Feb 2001 11:07:20 -0800 (PST) Date: Fri, 16 Feb 2001 11:07:20 -0800 From: Jason R Thorpe To: ipng@sunroof.eng.sun.com Subject: definition of gai_strerror() Message-ID: <20010216110720.R3145@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Zembu Labs, Inc. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In section 6.1, draft-ietf-ipngwg-rfc2553bis-03.txt defines gai_strerror() as: char *gai_strerror(int ecode); Is it intended that gai_strerror() return writeable strings, or are they intended to be string constants? If the latter, then it seems prudent to change the definition to: const char *gai_strerror(int ecode); ...and if we do want to change it, then we should notify the POSIX guys ASAP. -- -- Jason R. Thorpe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 11:23:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GJMfN16273 for ipng-dist; Fri, 16 Feb 2001 11:22:41 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GJMS216266 for ; Fri, 16 Feb 2001 11:22:28 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02217 for ; Fri, 16 Feb 2001 11:22:23 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05329 for ; Fri, 16 Feb 2001 11:22:21 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1GJMKC17658 for ; Fri, 16 Feb 2001 20:22:20 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Feb 16 20:23:34 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id <1CVNG3VV>; Fri, 16 Feb 2001 20:22:53 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6A5B@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Richard Draves'" , Erik Nordmark , Paul Francis Cc: Robert Elz , Brian E Carpenter , Jim.Bound@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: another renumbering question Date: Fri, 16 Feb 2001 20:22:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I think there are two motivations for site-locals (that not everybody > > agrees with): > > 1. For sites that are isolated i.e. do not have a global prefix. > > 2. To completely isolate traffic local to a site from > > site-renumbering events. > > Let me add a third motivation - site-local addresses allow for very > simple security policies or filters. For example the default > configuration for a file server might be to provide service only to > site-local clients. > => Another reason, is the ability to discover some "basic" services within a site. The DNS discovery draft has recommended the Site-local anycast address for this purpose. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 11:26:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GJPod16291 for ipng-dist; Fri, 16 Feb 2001 11:25:50 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GJPd216284 for ; Fri, 16 Feb 2001 11:25:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14285 for ; Fri, 16 Feb 2001 11:25:39 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25913 for ; Fri, 16 Feb 2001 11:25:38 -0800 (PST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1GJPag14945 for ; Fri, 16 Feb 2001 13:25:36 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 16 Feb 2001 13:25:29 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <10X74DFY>; Fri, 16 Feb 2001 13:25:29 -0600 Message-ID: To: thorpej@zembu.com, ipng@sunroof.eng.sun.com Subject: RE: definition of gai_strerror() Date: Fri, 16 Feb 2001 13:25:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk good catch Jason...and your right (yes it is constant).. I will fix things like this before the last draft for the rfc editor. I will find someone to go talk to austin. I don't now that I am at nokia. but I still know the austin folks. /jim > -----Original Message----- > From: ext Jason R Thorpe [mailto:thorpej@zembu.com] > Sent: Friday,February 16,2001 2:07 PM > To: ipng@sunroof.eng.sun.com > Subject: definition of gai_strerror() > > > In section 6.1, draft-ietf-ipngwg-rfc2553bis-03.txt defines > gai_strerror() as: > > char *gai_strerror(int ecode); > > Is it intended that gai_strerror() return writeable strings, or are > they intended to be string constants? If the latter, then it seems > prudent to change the definition to: > > const char *gai_strerror(int ecode); > > ...and if we do want to change it, then we should notify the POSIX > guys ASAP. > > -- > -- Jason R. Thorpe > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 13:14:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GLCUD16411 for ipng-dist; Fri, 16 Feb 2001 13:12:30 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GLCF216404 for ; Fri, 16 Feb 2001 13:12:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28481 for ; Fri, 16 Feb 2001 13:12:14 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07478 for ; Fri, 16 Feb 2001 13:12:12 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id PAA29612; Fri, 16 Feb 2001 15:05:16 -0600 (CST) Message-Id: <200102162105.PAA29612@gungnir.fnal.gov> To: Robert Elz Cc: Paul Francis , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: summary of Re: another renumbering question In-reply-to: Your message of Fri, 16 Feb 2001 15:20:00 +0700. <634.982311600@brandenburg.cs.mu.OZ.AU> Date: Fri, 16 Feb 2001 15:05:15 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | (By the way Robert, are the ICMP "tell me your > | site local addresses" and ICMP "site local source exiting the site" messages > | you mention [...]? > > The former is certainly new. No -- draft-ietf-ipngwg-icmp-name-lookups-07.txt. > I thought that the latter existed already > (and may in the form of destination unreachable code 3), but this is > one which probably deserves an ICMP code of its own (that is: packet > attempting to exit limited scope"). I too thought "scope exceeded" existed, but I can't find it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 13:14:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GLC8P16402 for ipng-dist; Fri, 16 Feb 2001 13:12:08 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GLBu216395 for ; Fri, 16 Feb 2001 13:11:57 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1GLBtL787458; Fri, 16 Feb 2001 13:11:55 -0800 (PST) Message-Id: <200102162111.f1GLBtL787458@jurassic.eng.sun.com> Date: Fri, 16 Feb 2001 13:12:48 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: RE: another renumbering question To: richdr@microsoft.com, Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com, paul@francis.com, kre@munnari.OZ.AU, brian@hursley.ibm.com, Jim.Bound@nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /VbLvk/ToV3gWgqgPvrJPA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I think there are two motivations for site-locals (that not everybody > > agrees with): > > 1. For sites that are isolated i.e. do not have a global prefix. > > 2. To completely isolate traffic local to a site from > > site-renumbering events. > > Let me add a third motivation - site-local addresses allow for very > simple security policies or filters. For example the default > configuration for a file server might be to provide service only to > site-local clients. > Another good example for this is an admistrative domain which does not want to expose it's internal ipv6-address topology to outside world. The nodes within this administrative domain communicate with each other only and do not require to communicate with outside world or communicate through only one node (in that domain) which maintains global addresses. Site-local addresses are appropriate choice in this scenario. This may be a scenario when we envision IPv6 in the operator's access network. -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 14:57:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GMthJ16507 for ipng-dist; Fri, 16 Feb 2001 14:55:43 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GMtV216500 for ; Fri, 16 Feb 2001 14:55:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29783 for ; Fri, 16 Feb 2001 14:55:32 -0800 (PST) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17149 for ; Fri, 16 Feb 2001 14:55:31 -0800 (PST) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 22454908; Fri, 16 Feb 2001 16:55:31 -0600 (CST) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 842C092A for ; Fri, 16 Feb 2001 16:55:30 -0600 (CST) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id <15PWY9PS>; Fri, 16 Feb 2001 17:55:30 -0500 Message-ID: From: "Powell, Ken" To: "'T.J. Kniveton'" , "'mobile-ip@standards.nortelnetworks.com'" , ipng@sunroof.eng.sun.com Subject: RE: New idea for Router Sol/Adv and Mobility Date: Fri, 16 Feb 2001 17:55:28 -0500 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham's response helped greatly to resolve the security questions I had. At first, I thought the RS/RA exchange between the mobile node's COA and the home agent during initialization shouldn't use the home address or routing header options. That was until I discussed this with Vlad Yasevich today. We don't have any reasons for the initial router advertisement sent back to the mobile node's COA to have a routing header, but there is a reason for keeping the home address option on the router solicitation. Vlad pointed out that the Home Agent needs a way to tell that a router solicitation was sent by a mobile node. This is important because the home agent needs to send the aggregate prefix list as defined in section 9.7.1 instead of just the home agent's own locally defined prefix list. Without some flag, a home agent would be forced to assume that any IPsec protected router solicitation with a global source address came from a mobile node. Reliance on this assumption could cause problems with some future application that may also need RS/RA exchanges with non-linklocal addresses. Attaching the home address option to the router solicit solves this problem. Assuming that the home address option is needed, what address should it contain before the mobile node generates its home address? On first glance, the unspecified address seems best. It is a clear signal that the mobile node has no home address and that there is no binding. The other choice is to repeat the care-of address as you suggested. This might be easier to implement by requiring less special logic in the protocol stack for IPsec and home address option handling. I haven't thought through all the details. Both these options are going to require some special handling. I suppose another option would be to add a "request aggregate prefix list" flag bit to the router solicitation message. Such a flag bit would be easier to implement in that it would only impact the part of the stack that deals with router solicitation/advertisement processing. What do others prefer? On to another concern... I've been trying to sort out how this proposal impacts section 9.7.2 which specifies the rules for when the home agent sends Router Advertisements to the mobile node. These rules require the home agent keep track of which router advertisement information was sent to each mobile node. It seems natural that this state information be stored with the binding cache entry. I couldn't see how the home agent could track the information from the RS/RA exchange before a binding is created. I think the home agent should treat RS/RA exchanges between HA and Mobile node's COA as a completely separate situation and make no attempt to associate them with a particular mobile node or binding. When a mobile node sends an IPsec protected RS to a home agent from its COA, the home agent should reply with an ipsec protected RA to the mobile node's COA and no routing header. The home agent may rate limit the RA's sent to a particular COA. This should be done independently from the procedure to send RA's to the mobile node's home address. To summarize, I think the current draft should: 1) Use home address option when the mobile node sends router solicitations from its home address to the home agent instead of fully encapsulating the router solicitation. 2) Protect router solicitations from the mobile node with IPsec, the same as router advertisements are protected. 3) Add a new mechanism for an IPsec protected RS/RA exchange between the mobile node's COA and home agent for possible use during initialization. This gets rid of any need for a temporary home address as mentioned in appendix A. I'm still undecided how to handle the home address option here. I'm going to be off-line next week and won't be able to respond to any questions till I get back. Ken > -----Original Message----- > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > Sent: Friday, February 16, 2001 1:41 AM > To: Powell, Ken; 'mobile-ip@standards.nortelnetworks.com'; > ipng@sunroof.eng.sun.com > Subject: Re: New idea for Router Sol/Adv and Mobility > > > on 2/15/01 1:46 PM, Powell, Ken wrote: > > > Under this proposal, the Mobile Node will have to re-establish the > > Security Association between the Home Agent and its Care-Of Address > > every time it moves to support IPsec requirements for Router > > Advertisements. How does this fit in with the process of > > forming the new care-of address and updating bindings? Will > > this cause additional hand-off delays? > > > > Good question. Where this question leads is, how can the HA > trust an MN when > the MN does not have a trustable identity based on a Home network IP > address? Does it make sense to base security associations on > IP addresses > when the addresses themselves are ephemeral and can't be associated to > Identity without the involvement of an outside entity? > > Clearly this is already a hot topic. Rather than trying to > solve it here, > perhaps I can offer a compromise which allows for the > possibility of future > elaboration. > > Here's the recipe: start with Draft 13. Now remove > encapsulation from RSs > (this is unnecessary and inconsistent). Add the rules for TTL<255 and > mobility processing, as stated in my previous message. Stir > in addressing as > follows: > > 1. The RS is sent with a HAddr option. The HAddr contains the > MN's Home > Address (naturally), EXCEPT if the MN has not configured one, > in which case > it MAY insert the COA instead. > > 2. The HA sends an RA using a routing header, as usual. The > RHdr contains > whatever was in the HAddr option - namely, the Home Address, > EXCEPT if the > COA was in the RS's HAddr option, it goes in the routing > header (we could > just leave the routing header off, alternatively). This RA is still > protected by IPsec as in the draft. > > This is the best of both worlds: > - In the steady-state case, where a MN has a HAddr, and it > needs updated > prefix info, it just sends an RS and the RA is protected with > the existing > security association > > - If the MN does not yet have a HAddr, it uses the COA, > *assuming you have a > way to generate a security association between the HA and the > COA*. If you > can not do this, there is no way to get an IPSEC-protected > RA. This is part > of the "bootstrap problem." > As soon as the MN gets a home address, it can use the HAddr > in all future > RSs, so this does not suffer from the problem Ken brought up, > of having to > update the HA/COA sec.assoc. every time you handover. Using > the COA is a > one-time thing while bootstrapping. > > This leaves room open for developing a dynamic security > architecture where > trust is based on something other than strictly the IP address. For > instance, an NAI, signed key, (whatever) might be used instead. > > > > How does the home agent determine which mobile node sent the > > Router Solicitation? Can the Care-of address on a mobile node > > be relied on for this? > > I contend it doesn't matter. You just need to know that it > was sent from a > mobile node. The information you include in a solicited RA > consists of the > prefixes from your own AdvPrefixList, and the prefixes advertised (and > therefore served) by all other HAs on the link. No other > prefixes will be > Mobile-IP-routable, and so they don't matter while the MN is > off-link. The > MN should be able to configure any/all of these prefixes and > be served by > any of these HAs, so you must send them all to any node who solicits. > > > >[Mattias Pettersson wrote:] > >> > >> Will we open up a security hole or possible denial-of service > >> attack by let's say flood a HA with RSes (that don't require > >> authentication), now that we can send them over multiple hops? > >> > > > > Yes, this does look like a problem, but I think its just as > > serious in draft 13. Any node could repeatedly send router > > solicits with the mobile node's care-of address (and home > > address). The home agent would send a complete Router > > Advertisement to the mobile node for each Router Solicit, > > possibly eating up expensive wireless bandwidth. Perhaps > > the Router Solicit should be IPsec protected? > > The problem isn't bandwidth here. The security issue is that > anyone can see > the prefix information about that potentially private network. You are > thereby exposing the fact that a certain IP address is a > router, that it's > also a home agent, and what some or all of the prefixes on > that link are. > And you're exposing it to anyone along the path to the MN. > > Regarding the bandwidth issue, who cares that the HA will > send RAs to the > mobile? If you want to use the MN's bandwidth, nothing stops > you from just > sending it packets yourself! Anyway, the HA could protect > against this by > limiting the rate at which it sends RAs. > > > > Ken > > > > > So I am interested in your comments on my compromise proposal. > -- > TJ Kniveton > NOKIA Research > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 18:05:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1H23uM16702 for ipng-dist; Fri, 16 Feb 2001 18:03:56 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1H23X216695 for ; Fri, 16 Feb 2001 18:03:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03760 for ; Fri, 16 Feb 2001 18:03:33 -0800 (PST) Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16308 for ; Fri, 16 Feb 2001 18:03:32 -0800 (PST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.132.204]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA64246; Fri, 16 Feb 2001 19:57:35 -0600 Received: from f5n79e (d03nm111h.boulder.ibm.com [9.99.140.79]) by westrelay01.boulder.ibm.com (8.11.2/NCO v4.95) with ESMTP id f1H22Fs142894; Fri, 16 Feb 2001 19:02:15 -0700 Received: from southrelay03.raleigh.ibm.com ([9.37.3.210]) by D03NH004.boulder.ibm.com (Lotus Domino Build V504_06062000) with ESMTP id 2000071117050039:169108 ; Tue, 11 Jul 2000 17:05:00 -0600 Received: from gateway.sequent.com ([138.95.180.1]) by southrelay03.raleigh.ibm.com (8.8.8m3/NCO v4.9) with ESMTP id TAA23412 for ; Tue, 11 Jul 2000 19:04:43 -0400 Received: from chaos.sequent.com (chaos.sequent.com [138.95.19.10]) by gateway.sequent.com (8.9.3/8.8.5) with ESMTP id QAA24188 for ; Tue, 11 Jul 2000 16:04:56 -0700 (PDT) Received: by chaos.sequent.com with Internet Mail Service (5.5.2651.58) id <3T28V48M>; Tue, 11 Jul 2000 16:04:55 -0700 Received: from gateway.sequent.com ([138.95.180.1]) by order.sequent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id 33K7YXF9; Tue, 11 Jul 2000 16:04:52 -0700 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by gateway.sequent.com (8.9.3/8.8.5) with ESMTP id QAA24173 for ; Tue, 11 Jul 2000 16:04:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA07457; Tue, 11 Jul 2000 17:02:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA19984; Tue, 11 Jul 2000 15:49:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6BMl7C03037 for ipng-dist; Tue, 11 Jul 2000 15:47:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6BMkw603030 for ; Tue, 11 Jul 2000 15:46:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA10220 for ; Tue, 11 Jul 2000 15:46:58 -0700 (PDT) Received: from zrtps06s.us.nortel.com ([47.140.48.50]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA17369 for ; Tue, 11 Jul 2000 15:46:57 -0700 (PDT) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 11 Jul 2000 18:46:00 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Jul 2000 18:46:00 -0400 Subject: RE: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-MIMETrack: Itemize by SMTP Server on D03NH004/03/H/IBM(Build V504_06062000 |June 6, 2000) at 07/11/2000 05:05:00 PM, MIME-CD by Router on D03NH004/03/H/IBM(Build V504_06062000 |June 6, 2000) at 07/11/2000 05:05:01 PM, MIME-CD complete at 07/11/2000 05:05:02 PM, Serialize by Router on D03NM111/03/M/IBM(Release 5.0.6 |December 14, 2000) at 02/16/2001 07:02:15 PM To: Alex Conta Cc: ipng@sunroof.eng.sun.com Message-ID: Date: Fri, 16 Feb 2001 18:02:13 -0800 From: "Peter Tam" Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1H23Y216696 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex: I can live with your clarifications. Thanks ...Peter -----Original Message----- From:   Alex Conta [SMTP:aconta@txc.com] Sent:   Monday, July 10, 2000 6:43 PM To:     Tam, Peter [NORSE:6L73:EXCH] Cc:     ipng@sunroof.eng.sun.com Subject:        Re: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for  Inverse Discovery Specification" Peter, Thanks for a more detailed list of comments. Your reviewing is going to be acknowledged in the I-D. As I am preparing the text for a new version of the draft,  my thoughts related to your comments are: Regarding your first suggestion, whose ramifications I understand now better than before: >      >... > >      >> Currently, the draft does not restrict the types of addresses >      within the Source/Target Address Lists in the IND >      Solicitation/Advertisement messages. Thus, it implies that both >      unicast and multicast addresses are legitimate. This address >      information is used to build the Neighbor cache, which I believe >      can contain only unicast addresses.If unicast-only addresses are >      imposed (as I suggested), then Sections 4.3.1 and 4.3.2 should >      discard IND messages containing multicast addresses, so that they >      will not be entered into the cache. After all, resolution should >      be between link layer addresses and unicast network addresses. > the text in the current draft is aligned with the original intentions in specifying the protocol:   - do not make strong implementation requirements      the I-D specifies that  the Neighbor Discovery Cache MAY be      populated with address information acquired via IND.  Which is      to say strongly that the Protocol for populating the ND cache      is and remains ND.   - allow a certain level of generality and flexibility to the address discovery mechanism, which may be useful for the type of links to which the protocol applies.       for links that do not have an algorithmic mapping of  IP      multicast addresses into link addresses, there is - I think -      a need for storing/caching the address information used in      resolution. What is, or how  the place for storing multicast      address information is called, is an implementation issue.  A      mechanism to convey the information used in resolution is also      useful . In saying this, as I did in the I-D,  I am trying to      stay away though from making implementation suggestions. As I still do not see any particular bad side effects, I think the original goals as followed by the text are worth maintaining,  In that sense,  I think,  RFC 2390 sets also an example. >      >.... > >      >   1. Appendix A: Frame Relay (FR) as a link-layer address. But >      it >      >      should have a note up front that the DLCI applies to the >      member >      >      DLCI in the case of a Multi-link Frame Relay. >      > > >      The appendix was intended to contain one simple example to >      illustrate >      the use of the protocol. Some particular details of the link in >      the >      example were considered out of scope. >      >> Out-of/in scope is an artificial line. In this case, all it >      takes is only 1 line of clarification. > Let me rephrase my thoughts on this: the example in Appendix A is not a Multi-link Frame Relay example, and Multi-link Frame Relay is not mentioned at all. If Multi-link would have been mentioned, in one way or another, then I could have better seen a reason for confusion, and a need for clarification, but without that, this is a way to not extend the scope beyond what was intended, and also minimize the number of words or sentences. Thanks again for your input. and regards, Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page:                      http://playground.sun.com/ipng FTP archive:                      ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 18:25:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1H2Lcj17502 for ipng-dist; Fri, 16 Feb 2001 18:21:38 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1H2F8217341 for ; Fri, 16 Feb 2001 18:19:57 -0800 (PST) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24337 for ; Fri, 16 Feb 2001 18:15:02 -0800 (PST) Received: from china.com (TCE-E-7-182-13.bta.net.cn [202.106.182.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA20652 for ; Fri, 16 Feb 2001 18:14:42 -0800 (PST) Received: from china.com([10.1.0.100]) by china.com(JetMail 2.5.3.0) with SMTP id jm23a8e1cdd; Sat, 17 Feb 2001 02:11:43 -0000 Received: from patan.sun.com([192.18.98.43]) by china.com(JetMail 2.5.3.0) with SMTP id jm33a8d41b2; Fri, 16 Feb 2001 11:10:16 -0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10404; Thu, 15 Feb 2001 15:19:32 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02748; Thu, 15 Feb 2001 15:19:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1FNH1m13250 for ipng-dist; Thu, 15 Feb 2001 15:17:01 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1FNGp213243 for ; Thu, 15 Feb 2001 15:16:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16248 for ; Thu, 15 Feb 2001 15:16:52 -0800 (PST) Received: from china.com (TCE-E-7-182-13.bta.net.cn [202.106.182.13]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA13473 for ; Thu, 15 Feb 2001 15:16:36 -0800 (PST) Received: from china.com([10.1.0.100]) by china.com(JetMail 2.5.3.0) with SMTP id jm1603a8c9e7e; Thu, 15 Feb 2001 23:13:31 -0000 Received: from mercury.Sun.COM([192.9.25.1]) by china.com(JetMail 2.5.3.0) with SMTP id jm2a3a8bcac7; Thu, 15 Feb 2001 08:11:39 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA25269; Thu, 15 Feb 2001 00:14:21 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA02853; Thu, 15 Feb 2001 00:14:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1F87jw12188 for ipng-dist; Thu, 15 Feb 2001 00:07:45 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1F87E212151 for ; Thu, 15 Feb 2001 00:07:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11076 for ; Thu, 15 Feb 2001 00:07:16 -0800 (PST) Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA29367 for ; Thu, 15 Feb 2001 00:07:11 -0800 (PST) Received: from qnsgs000.nortelnetworks.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with SMTP id f1F86Ns24309; Thu, 15 Feb 2001 03:06:26 -0500 (EST) Received: by qnsgs000.nortelnetworks.com (SMI-8.6/SMI-SVR4) id IAA04379; Thu, 15 Feb 2001 08:07:06 GMT Date: Thu, 15 Feb 2001 08:07:06 GMT Message-Id: <200102150807.IAA04379@qnsgs000.nortelnetworks.com> To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com From: "T.J. Kniveton" Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 19:37:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1H3ZvV20858 for ipng-dist; Fri, 16 Feb 2001 19:35:58 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1H3XU220635 for ; Fri, 16 Feb 2001 19:34:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01523 for ; Fri, 16 Feb 2001 19:33:25 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA23501 for ; Fri, 16 Feb 2001 20:33:18 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id KAA25134; Sat, 17 Feb 2001 10:32:32 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1H3WSp02782; Sat, 17 Feb 2001 10:32:30 +0700 (ICT) From: Robert Elz To: "Matt Crawford" cc: Paul Francis , ipng@sunroof.eng.sun.com Subject: Re: summary of Re: another renumbering question In-reply-to: Your message of "Fri, 16 Feb 2001 15:05:15 CST." <200102162105.PAA29612@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Feb 2001 10:32:28 +0700 Message-ID: <2780.982380748@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 16 Feb 2001 15:05:15 -0600 From: "Matt Crawford" Message-ID: <200102162105.PAA29612@gungnir.fnal.gov> | > The former is certainly new. | No -- draft-ietf-ipngwg-icmp-name-lookups-07.txt. Ah yes, of course, I had forgotten the Node Addresses request was in there along with names. Good, that makes life simpler... And apologies... kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 19:44:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1H3hct21082 for ipng-dist; Fri, 16 Feb 2001 19:43:38 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1H3hT221075 for ; Fri, 16 Feb 2001 19:43:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02504; Fri, 16 Feb 2001 19:43:29 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05622; Fri, 16 Feb 2001 19:43:21 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id KAA25268; Sat, 17 Feb 2001 10:42:38 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1H3gJp02800; Sat, 17 Feb 2001 10:42:24 +0700 (ICT) From: Robert Elz To: Jim.Bound@nokia.com cc: richdr@microsoft.com, Erik.Nordmark@eng.sun.com, paul@francis.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: another renumbering question In-reply-to: Your message of "Fri, 16 Feb 2001 13:00:55 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Feb 2001 10:42:19 +0700 Message-ID: <2798.982381339@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 16 Feb 2001 13:00:55 -0600 From: Jim.Bound@nokia.com Message-ID: | butunlike the other two uses yours has alternatives like using IPsec. | yours is a weaker reason for them as the reason was for private addresses in | IPv4. Jim, I agree with you on that. I also half suspect though that it will be the dominant reason, weak or not. That is, for the vast majority of sites, that kind of "security" is so simple that it is attractive, and while security by filtering isn't generally nearly as good as security by authentication, in this particular case (making a couple of semi-reasonable assumptions) it might almost be better. That is, the assumption is that anyone within the site is entitled to get access to the fileserver, and that the information there is generally (within the site) public - but it isn't supposed to be available outside the site (if you want, imagine the reason for this is that the server cannot handle the load). Using ipsec techniques requires key distribution, with the possibility that the key might be made known more widely than had been intended, allowing outsiders access to the server. Site local addresses require none of that (simpler to administer) and the routers (with no special configuration at all) enforce access. Furthermore, the usual problem with firewall security - that once security is broken anywhere it is broken everywhere isn't relevant here, as even using ipsec, everyone inside the site is allowed access to the server anyway, so if an intruder manages to get an an internal host, then whatever security method is being used, they have access to the server. With all this, I kind of suspect that Rich may have hit the most pressing demand for site locals right on the head - and I also guess that's why his implementation has (slightly) jumped the gun and picked a method to use the things, even if it probably isn't really a good choice. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 19:54:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1H3rOs21185 for ipng-dist; Fri, 16 Feb 2001 19:53:24 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1H3rF221178 for ; Fri, 16 Feb 2001 19:53:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03168 for ; Fri, 16 Feb 2001 19:53:15 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA29727 for ; Fri, 16 Feb 2001 20:53:08 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.253]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id KAA25490; Sat, 17 Feb 2001 10:52:30 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1H3qTp02818; Sat, 17 Feb 2001 10:52:29 +0700 (ICT) From: Robert Elz To: Steve Deering cc: "Paul Francis" , ipng@sunroof.eng.sun.com Subject: Re: another renumbering question In-reply-to: Your message of "Fri, 16 Feb 2001 01:28:07 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Feb 2001 10:52:29 +0700 Message-ID: <2816.982381949@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 16 Feb 2001 01:28:07 -0800 From: Steve Deering Message-ID: Dear Dr Blanket... | Exactly. The last thing we want to do is establish yet another numbering | space that needs to be globally administered, | And then there may be other counter arguments I've forgotten. It's | certainly true that we've been over this question a number of times | in the past, so if we're really going to dredge it up again, we | should at least do some digging in the archives to make sure we | don't spend a lot of time rediscovering (or worse, failing to | rediscover) previously identified issues. I remember the arguments, and I don't recall a technical one among them. They're all this FUD. What's more, this stuff is an even weaker argument than the arguments made by those opposed to requiring security (encryption in particular) in IPv6 - at least there were real (non-technical) problems to be overcome in that case, rather than just the fear of potential political problems here. Now it is probably also true that the technical arguments in favour of having globally unique non-routable addresses (in addition to the routable ones) aren't as strong as the technical arguments in favour of security, but it would be nice if we (more or less technical people) could confine ourselves to the technical arguments, and ignore this nonsense about how difficult it will be to assign consecutive integers. Even more so, if they would not actually be required for anything to operate (just an enhancement that a site might prefer to have). kre ps: but yes, the archives should be checked... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 21:34:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1H5XZm21565 for ipng-dist; Fri, 16 Feb 2001 21:33:35 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1H5XM221551 for ; Fri, 16 Feb 2001 21:33:22 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA20545 for ; Fri, 16 Feb 2001 21:33:21 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA24167 for ; Fri, 16 Feb 2001 21:33:21 -0800 (PST) Received: (cpmta 9659 invoked from network); 16 Feb 2001 21:33:20 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.64) with SMTP; 16 Feb 2001 21:33:20 -0800 X-Sent: 17 Feb 2001 05:33:20 GMT Message-ID: <006301c098a3$26d29500$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Steve Deering" Cc: References: <609.982310655@brandenburg.cs.mu.OZ.AU> Subject: Re: another renumbering question Date: Fri, 16 Feb 2001 11:25:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Exactly. The last thing we want to do is establish yet another numbering > space that needs to be globally administered, which then becomes another > ICANN political football (like our existing global name and numbering > spaces), and for which we have to figure out some sort of allocation > mechanism/policy to prevent anyone from coming along and grabbing > such site IDs by the millions ("Hey, I'm going to be the next McDonalds, > so I'm going to need a million site IDs! Trust me."), and for which Speaking rationally, 38 bits of address would allow ICANN to give out 100 prefixes per second for the next 90 years. They could give them out almost freely (say, in chunks of 10000 to virtually anyone who asked) without any concern for running out. Since the numbers don't have the same value as DNS names, and since they are not scarce like TLDs, then speaking rationally, there should be no issue. Of course there will be issues, but one can't but hope it wouldn't be near the political football as the other ICANN assignments. > allocator's revenue stream). And the other thing that would likely > happen is that sites would obtain these non-globally-routable site IDs > and then a few months later some of them would shop around to find an > ISP who would agree to inject their (unaggregated) site IDs into the This requires collusion between the ISPs (they would have to explicitly agree to advertise "local" addresses). This would probably be harder than getting ISPs to advertise longer prefixes of the existing globally aggretable addresses, so we probably aren't making the likelihood any worse. > > One could possibly finesse the problems of establishing a new > numbering bureaucracy by exploiting an existing one, e.g., by > saying that site can choose, say, one of its own Ethernet addresses > (that is, a globally unique number from a space managed by the > existing IEEE bureaucracy) to stick into the empty field of its > site-locals -- unfortunately, there aren't enough free bits > there to hold an Ethernet address. You could do this if you really wanted. You need 46 bits (take away the group bit and the global bit). If you use two of the unassigned 3-bit prefixes for this purpose, then you'd have enough space. But what a waste! > How about using IPv4 addresses > for that purpose? Well, some sites today can't get even one IPv4 > address, and that's likely to get worse. Besides, we already have > half a dozen IPv6 address formats that have IPv4 addresses embedded > in them somewhere, and I shudder to have to explain yet another one. IPv4 addresses can't be used this way because they are not owned by sites. The sites need a number they can own forever no questions asked. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 21:34:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1H5Xhw21566 for ipng-dist; Fri, 16 Feb 2001 21:33:43 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1H5XM221552 for ; Fri, 16 Feb 2001 21:33:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA20547 for ; Fri, 16 Feb 2001 21:33:21 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA29032 for ; Fri, 16 Feb 2001 22:33:21 -0700 (MST) Received: (cpmta 9658 invoked from network); 16 Feb 2001 21:33:20 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.64) with SMTP; 16 Feb 2001 21:33:20 -0800 X-Sent: 17 Feb 2001 05:33:20 GMT Message-ID: <006201c098a3$268f7180$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Robert Elz" Cc: References: <609.982310655@brandenburg.cs.mu.OZ.AU> Subject: Re: another renumbering question Date: Fri, 16 Feb 2001 08:59:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | Granted > | when a node did a DNS lookup, it wouldn't know if a given unique-local > | address was in the same site, > > No, considering aggregated sites (with multiple I-Ds) but a simple compare > of her site ID token against mine would catch the majority of cases. > It might catch the majority, but there would be enough that it wouldn't catch that you'd need mechanisms similar to the ones used with site-locals (ie, compare global prefixes to decide if you are in the same site, or even have router advertisements or DHCP advertise the prefixes that are within the site.") There'd also be the case where a node that was normally reachable intra-site is temporally not reachable that way, but it reachable through the global address, so you'd want to be able to catch that too. So globally-unique-locally-routable prefixes aren't trivial to operate. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 21:52:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1H5pWn21650 for ipng-dist; Fri, 16 Feb 2001 21:51:32 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1H5pN221643 for ; Fri, 16 Feb 2001 21:51:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA11858 for ; Fri, 16 Feb 2001 21:51:22 -0800 (PST) Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA29803 for ; Fri, 16 Feb 2001 21:51:22 -0800 (PST) Received: (cpmta 1313 invoked from network); 16 Feb 2001 21:51:21 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.72) with SMTP; 16 Feb 2001 21:51:21 -0800 X-Sent: 17 Feb 2001 05:51:21 GMT Message-ID: <009a01c098a5$ab1b6920$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Richard Draves" Cc: References: <7695E2F6903F7A41961F8CF888D87EA81C9C3E@red-msg-06.redmond.corp.microsoft.com> Subject: Re: another renumbering question Date: Fri, 16 Feb 2001 21:51:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Let me add a third motivation - site-local addresses allow for very > simple security policies or filters. For example the default > configuration for a file server might be to provide service only to > site-local clients. > The very thing that scares me about site-locals is that, if for some reason your site perimeter is accidently breached, suddenly a bunch of subnets are attached to yours and you have no way of easily distinguishing them from yours. This characteristic says to me that site-locals weaken security rather than strengthen it (in the same way that any auto-config weakens security). If you've got a file server that provides service only to clients with site-local prefixes, then that means what you've got is a file server that is happy to provide service to just 'bout every IPv6 host in the entire internet. Now you have to be damn careful that those hosts don't get access to your network. Of course you have to anyway, but at least accidental breaches are easier to detect if you've explicitly said what client address prefixes can and cannot access your box. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 16 21:54:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1H5rSW21668 for ipng-dist; Fri, 16 Feb 2001 21:53:28 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1H5rH221661 for ; Fri, 16 Feb 2001 21:53:17 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA09055 for ; Fri, 16 Feb 2001 21:53:16 -0800 (PST) Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA00496 for ; Fri, 16 Feb 2001 21:53:16 -0800 (PST) Received: (cpmta 29573 invoked from network); 16 Feb 2001 21:53:15 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.65) with SMTP; 16 Feb 2001 21:53:15 -0800 X-Sent: 17 Feb 2001 05:53:15 GMT Message-ID: <00a001c098a5$ef023920$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Hesham Soliman \(ERA\)" Cc: References: <034BEFD03799D411A59F00508BDF75465B6A5B@esealnt448.al.sw.ericsson.se> Subject: Re: another renumbering question Date: Fri, 16 Feb 2001 21:53:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > => Another reason, is the ability to discover > some "basic" services within a site. The DNS discovery > draft has recommended the Site-local anycast address > for this purpose. > Yeah, anycast with site scope strikes me as a good use of site locals. On the other hand, DHCP provides an example of discovery with link-locals, so there are other ways of doing it. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 17 01:55:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1H9sX222591 for ipng-dist; Sat, 17 Feb 2001 01:54:33 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1H9sN222584 for ; Sat, 17 Feb 2001 01:54:23 -0800 (PST) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21959 for ; Sat, 17 Feb 2001 01:54:22 -0800 (PST) Received: from china.com (TCE-E-7-182-13.bta.net.cn [202.106.182.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA23979 for ; Sat, 17 Feb 2001 01:54:15 -0800 (PST) Received: from china.com([10.1.0.100]) by china.com(JetMail 2.5.3.0) with SMTP id jm83a8e8871; Sat, 17 Feb 2001 09:50:44 -0000 Received: from mercury.Sun.COM([192.9.25.1]) by china.com(JetMail 2.5.3.0) with SMTP id jm443a8ddabe; Fri, 16 Feb 2001 18:46:29 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA08369; Fri, 16 Feb 2001 06:13:00 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29721; Fri, 16 Feb 2001 06:11:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1GE7dP15313 for ipng-dist; Fri, 16 Feb 2001 06:07:39 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1GE7T215306 for ; Fri, 16 Feb 2001 06:07:30 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25209 for ; Fri, 16 Feb 2001 06:07:30 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07385 for ; Fri, 16 Feb 2001 06:07:30 -0800 (PST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA19458; Fri, 16 Feb 2001 06:07:26 -0800 Received: from hursley.ibm.com (lig32-226-108-140.us.lig-dial.ibm.com [32.226.108.140]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA20450; Fri, 16 Feb 2001 06:07:23 -0800 Message-ID: <3A8D3387.BD08A95D@hursley.ibm.com> Date: Fri, 16 Feb 2001 08:04:55 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Dave Thaler CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 addresses with embedded private IPv4 addresses References: <5B90AD65A9E8934987DB0C8C0762657420FD73@DF-BOWWOW.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 6to4 is meant to do more than imply it: > The V4ADDR MUST be > a duly allocated global IPv4 address, which MUST be unique within the > private network. The Intranet thereby obtains globally unique IPv6 > addresses even if it is internally using private IPv4 addresses [RFC > 1918]. And BTW it isn't a draft; it's an RFC. I don't know if the announcement is out, because I don't seem to be able to receive email this morning, only send it, but the authors' 48 hour check on the RFC just finished. Personally I think the answer should be to insist on global addresses in IPv4-compatible addresses too. The scenarios using NAT addresses here are too horrible to contemplate. Brian Dave Thaler wrote: > > I'd like to ask for some general consensus on the following questions: > > 1) Are "::10.1.1.1" and "::169.254.1.1" legal IPv6 addresses? > (They look like global IPv6 addresses, but aren't globally unique.) > RFC 2373 does not mention any such restriction, and so > implies "yes". > > 2) Similarly, is "2002:0A01:0101:..." a legal IPv6 address? > The current 6to4 draft implies "no". > > 3) Is it reasonable that the answers to the above two questions > could be different? > > (I'd personally rather the answer be the same for both, that > answer probably being "no", as this avoids a lot of ugly problems.) > > And before anyone responds saying that "::10.1.1.1" should be > allowed so that you can talk between two hosts in a private IPv4 > network, keep in mind that draft-templin-ngtrans-v6v4compat-*.txt > allows you to do the same thing with "fe80::200:5efe:10.1.1.1", which > is clearly a link-local address (on an encapsulation link covering the > private area) and so avoids the ugly problems "::10.1.1.1" has. > > -Dave > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 17 03:10:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1HB9nv23150 for ipng-dist; Sat, 17 Feb 2001 03:09:49 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1HB9b223143 for ; Sat, 17 Feb 2001 03:09:38 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06595 for ; Sat, 17 Feb 2001 03:09:33 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA23886 for ; Sat, 17 Feb 2001 03:09:27 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f1HB9Qd09069 for ; Sat, 17 Feb 2001 12:09:26 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sat Feb 17 12:10:42 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id <1CVNG4FM>; Sat, 17 Feb 2001 12:09:26 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6A60@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Paul Francis'" Cc: ipng@sunroof.eng.sun.com Subject: RE: another renumbering question Date: Sat, 17 Feb 2001 12:09:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > > => Another reason, is the ability to discover > > some "basic" services within a site. The DNS discovery > > draft has recommended the Site-local anycast address > > for this purpose. > > > > Yeah, anycast with site scope strikes me as a good use of site locals. On > the other hand, DHCP provides an example of discovery with link-locals, so > there are other ways of doing it. > => Sure, we also have stateful and stateless address configuration. I'd rather not have a DHCP server if I can. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 18 04:22:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1ICLLx28380 for ipng-dist; Sun, 18 Feb 2001 04:21:21 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1ICL7228373 for ; Sun, 18 Feb 2001 04:21:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA00195 for ; Sun, 18 Feb 2001 04:21:07 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA16470 for ; Sun, 18 Feb 2001 05:21:05 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f1ICL4d23800 for ; Sun, 18 Feb 2001 13:21:04 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Sun Feb 18 13:22:21 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Sun, 18 Feb 2001 13:22:21 +0100 Message-ID: <034BEFD03799D411A59F00508BDF75465B6A61@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@standards.nortelnetworks.com'" , ipng@sunroof.eng.sun.com Subject: RE: New idea for Router Sol/Adv and Mobility Date: Sun, 18 Feb 2001 13:21:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Ken, Erik suggested in his email definnig a new type for the RS. The use of this new type should be enough to show the HA that the request is coming from a MN and that it is not a normal RS. I think doing that removes the need for the Home address option and the additional complication that comes with that (what should be in the option ...etc). Also it would be a much cleaner approach IMO. Cheers, Hesham > -----Original Message----- > From: Powell, Ken [SMTP:Ken.Powell@compaq.com] > Sent: Saturday, 17 February 2001 9:55 > To: 'T.J. Kniveton'; mobile-ip@marvin.corpeast.baynetworks.com; ipng@sunroof.eng.sun.com > Subject: RE: New idea for Router Sol/Adv and Mobility > > Hesham's response helped greatly to resolve the > security questions I had. > > At first, I thought the RS/RA exchange between the > mobile node's COA and the home agent during > initialization shouldn't use the home address or > routing header options. That was until I discussed > this with Vlad Yasevich today. > > We don't have any reasons for the initial > router advertisement sent back to the mobile > node's COA to have a routing header, but > there is a reason for keeping the home > address option on the router solicitation. > > Vlad pointed out that the Home Agent needs a > way to tell that a router solicitation was sent by > a mobile node. This is important because the home > agent needs to send the aggregate prefix list as > defined in section 9.7.1 instead of just the home > agent's own locally defined prefix list. Without some > flag, a home agent would be forced to assume that any > IPsec protected router solicitation with a global > source address came from a mobile node. Reliance on > this assumption could cause problems with some future > application that may also need RS/RA exchanges with > non-linklocal addresses. Attaching the home address > option to the router solicit solves this problem. > > Assuming that the home address option is needed, > what address should it contain before the mobile > node generates its home address? On first > glance, the unspecified address seems best. It is > a clear signal that the mobile node has no home > address and that there is no binding. The other > choice is to repeat the care-of address as you > suggested. This might be easier to implement by > requiring less special logic in the protocol stack > for IPsec and home address option handling. > I haven't thought through all the details. > Both these options are going to require some > special handling. > > I suppose another option would be to add a > "request aggregate prefix list" flag bit to > the router solicitation message. Such a flag > bit would be easier to implement in that > it would only impact the part of the stack > that deals with router solicitation/advertisement > processing. > > What do others prefer? > > On to another concern... > > I've been trying to sort out how this proposal impacts > section 9.7.2 which specifies the rules for when the > home agent sends Router Advertisements to the mobile > node. These rules require the home agent keep track > of which router advertisement information was sent > to each mobile node. It seems natural that this > state information be stored with the binding cache > entry. I couldn't see how the home agent could > track the information from the RS/RA exchange before > a binding is created. > > I think the home agent should treat RS/RA exchanges > between HA and Mobile node's COA as a completely > separate situation and make no attempt to associate > them with a particular mobile node or binding. > > When a mobile node sends an IPsec protected RS to a > home agent from its COA, the home agent should reply > with an ipsec protected RA to the mobile node's COA and > no routing header. The home agent may rate limit the RA's > sent to a particular COA. This should be done independently > from the procedure to send RA's to the mobile node's home> > address. > > To summarize, I think the current draft should: > > 1) Use home address option when the mobile node > sends router solicitations from its home address > to the home agent instead of fully encapsulating > the router solicitation. > > 2) Protect router solicitations from the mobile > node with IPsec, the same as router advertisements > are protected. > > 3) Add a new mechanism for an IPsec protected > RS/RA exchange between the mobile node's COA > and home agent for possible use during > initialization. This gets rid of any need > for a temporary home address as mentioned > in appendix A. I'm still undecided how > to handle the home address option here. > > I'm going to be off-line next week and won't be > able to respond to any questions till I get back. > > Ken > > > -----Original Message----- > > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > > Sent: Friday, February 16, 2001 1:41 AM > > To: Powell, Ken; 'mobile-ip@standards.nortelnetworks.com'; > > ipng@sunroof.eng.sun.com > > Subject: Re: New idea for Router Sol/Adv and Mobility > > > > > > on 2/15/01 1:46 PM, Powell, Ken wrote: > > > > > Under this proposal, the Mobile Node will have to re-establish the > > > Security Association between the Home Agent and its Care-Of Address > > > every time it moves to support IPsec requirements for Router > > > Advertisements. How does this fit in with the process of > > > forming the new care-of address and updating bindings? Will > > > this cause additional hand-off delays? > > > > > > > Good question. Where this question leads is, how can the HA > > trust an MN when > > the MN does not have a trustable identity based on a Home network IP > > address? Does it make sense to base security associations on > > IP addresses > > when the addresses themselves are ephemeral and can't be associated to > > Identity without the involvement of an outside entity? > > > > Clearly this is already a hot topic. Rather than trying to > > solve it here, > > perhaps I can offer a compromise which allows for the > > possibility of future > > elaboration. > > > > Here's the recipe: start with Draft 13. Now remove > > encapsulation from RSs > > (this is unnecessary and inconsistent). Add the rules for TTL<255 and > > mobility processing, as stated in my previous message. Stir > > in addressing as > > follows: > > > > 1. The RS is sent with a HAddr option. The HAddr contains the > > MN's Home > > Address (naturally), EXCEPT if the MN has not configured one, > > in which case > > it MAY insert the COA instead. > > > > 2. The HA sends an RA using a routing header, as usual. The > > RHdr contains > > whatever was in the HAddr option - namely, the Home Address, > > EXCEPT if the > > COA was in the RS's HAddr option, it goes in the routing > > header (we could > > just leave the routing header off, alternatively). This RA is still > > protected by IPsec as in the draft. > > > > This is the best of both worlds: > > - In the steady-state case, where a MN has a HAddr, and it > > needs updated > > prefix info, it just sends an RS and the RA is protected with > > the existing > > security association > > > > - If the MN does not yet have a HAddr, it uses the COA, > > *assuming you have a > > way to generate a security association between the HA and the > > COA*. If you > > can not do this, there is no way to get an IPSEC-protected > > RA. This is part > > of the "bootstrap problem." > > As soon as the MN gets a home address, it can use the HAddr > > in all future > > RSs, so this does not suffer from the problem Ken brought up, > > of having to > > update the HA/COA sec.assoc. every time you handover. Using > > the COA is a > > one-time thing while bootstrapping. > > > > This leaves room open for developing a dynamic security > > architecture where > > trust is based on something other than strictly the IP address. For> > > instance, an NAI, signed key, (whatever) might be used instead. > > > > > > > How does the home agent determine which mobile node sent the > > > Router Solicitation? Can the Care-of address on a mobile node > > > be relied on for this? > > > > I contend it doesn't matter. You just need to know that it > > was sent from a > > mobile node. The information you include in a solicited RA > > consists of the > > prefixes from your own AdvPrefixList, and the prefixes advertised (and > > therefore served) by all other HAs on the link. No other > > prefixes will be > > Mobile-IP-routable, and so they don't matter while the MN is > > off-link. The > > MN should be able to configure any/all of these prefixes and > > be served by > > any of these HAs, so you must send them all to any node who solicits. > > > > > > >[Mattias Pettersson wrote:] > > >> > > >> Will we open up a security hole or possible denial-of service > > >> attack by let's say flood a HA with RSes (that don't require > > >> authentication), now that we can send them over multiple hops? > > >> > > > > > > Yes, this does look like a problem, but I think its just as > > > serious in draft 13. Any node could repeatedly send router > > > solicits with the mobile node's care-of address (and home > > > address). The home agent would send a complete Router > > > Advertisement to the mobile node for each Router Solicit, > > > possibly eating up expensive wireless bandwidth. Perhaps > > > the Router Solicit should be IPsec protected? > > > > The problem isn't bandwidth here. The security issue is that > > anyone can see > > the prefix information about that potentially private network. You are > > thereby exposing the fact that a certain IP address is a > > router, that it's > > also a home agent, and what some or all of the prefixes on > > that link are. > > And you're exposing it to anyone along the path to the MN. > > > > Regarding the bandwidth issue, who cares that the HA will > > send RAs to the > > mobile? If you want to use the MN's bandwidth, nothing stops > > you from just > > sending it packets yourself! Anyway, the HA could protect > > against this by > > limiting the rate at which it sends RAs. > > > > > > Ken > > > > > > > > > So I am interested in your comments on my compromise proposal. > > -- > > TJ Kniveton > > NOKIA Research > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 18 16:05:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1J04Te00806 for ipng-dist; Sun, 18 Feb 2001 16:04:29 -0800 (PST) Received: from kebe.Eng.Sun.COM (kebe [129.146.86.51]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1J04L200799 for ; Sun, 18 Feb 2001 16:04:21 -0800 (PST) Received: (from danmcd@localhost) by kebe.Eng.Sun.COM (8.11.2+Sun/8.11.2) id f1J04ZD24527 for ipng@sunroof; Sun, 18 Feb 2001 16:04:35 -0800 (PST) Message-Id: <200102190004.f1J04ZD24527@kebe.Eng.Sun.COM> Subject: IPv6 destination options questions... To: ipng@sunroof.eng.sun.com Date: Sun, 18 Feb 2001 16:04:35 -0800 (PST) From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This sort of minutiae begs for reality checking. In the IPv6 spec (RFC 2460), you can see "destination options" occur in TWO places in an unprotected packet. The first place is the obvious place of just-before-the-transport-header. The second place is the more subtle just-before-the-routing-header, which has the semantic of making every node specified in the routing header process the destination options. My questions are: 1.) In the routing header case, can those specified nodes change destination options inside that header between routing header hops? 2.) If #1's answer is "yes", must those options have the "mutable" bit set in them? 3.) In the just-before-transport case, is there any reason for any "mutable" options to be in that dest-opts bag? (The correct answer for the second part (IMHO) is "yes". The correct answer for the third part (again, IMHO) is "no".) Clear, precise answers to these questions makes AH for IPv6 implementable. These answers should also appear in the sucessor spec to RFC 2460 (and probably 2402 as well, but that's for another list). Thanks, Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 18 17:23:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1J1MH301104 for ipng-dist; Sun, 18 Feb 2001 17:22:17 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1J1M8201097 for ; Sun, 18 Feb 2001 17:22:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18210 for ; Sun, 18 Feb 2001 17:22:08 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA10486 for ; Sun, 18 Feb 2001 17:22:08 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 16 Feb 2001 19:34:42 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Feb 2001 19:35:27 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 16 Feb 2001 19:34:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 addresses with embedded private IPv4 addresses Date: Fri, 16 Feb 2001 19:34:35 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657420FD7A@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 addresses with embedded private IPv4 addresses Thread-Index: AcCYQ+yhJtsjLlQBQiCx2n6EDHyqPgATLwjQ From: "Dave Thaler" To: "Brian E Carpenter" Cc: X-OriginalArrivalTime: 17 Feb 2001 03:34:36.0198 (UTC) FILETIME=[8CD7E460:01C09892] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1J1M8201098 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Carpenter writes: > 6to4 is meant to do more than imply it: [...] You're right. > And BTW it isn't a draft; it's an RFC. I don't know if the > announcement is > out, because I don't seem to be able to receive email this > morning, only > send it, but the authors' 48 hour check on the RFC just finished. I didn't get the announcement until after I sent the email. > Personally I think the answer should be to insist on global addresses > in IPv4-compatible addresses too. The scenarios using NAT > addresses here are too horrible to contemplate. Sounds like emerging consensus... If we all agree this is the right thing (and it's sounding so far like we do) then I'd like to ask that section 2.5.4 of draft-ietf-ipngwg-addr-arch-v3-*.txt be updated to explicitly state this restriction. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 18 17:24:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1J1ODC01138 for ipng-dist; Sun, 18 Feb 2001 17:24:13 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1J1O3201131 for ; Sun, 18 Feb 2001 17:24:03 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16404; Sun, 18 Feb 2001 17:24:03 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16778; Sun, 18 Feb 2001 17:23:59 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (sw11.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id IAA11519; Mon, 19 Feb 2001 08:23:55 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1J1Nrd01201; Mon, 19 Feb 2001 08:23:54 +0700 (ICT) From: Robert Elz To: Dan McDonald cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 destination options questions... In-reply-to: Your message of "Sun, 18 Feb 2001 16:04:35 PST." <200102190004.f1J04ZD24527@kebe.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Feb 2001 08:23:53 +0700 Message-ID: <1199.982545833@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 18 Feb 2001 16:04:35 -0800 (PST) From: Dan McDonald Message-ID: <200102190004.f1J04ZD24527@kebe.Eng.Sun.COM> | (The correct answer for the second part (IMHO) is "yes". The correct answer | for the third part (again, IMHO) is "no".) I agree, and that also assumes that the answer to the first question is yes as well. This was all discussed on the list a few months ago (in amongst the big debate on what the API ought be like for setting the multiple possible DO headers) kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 18 21:43:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1J5gWN01976 for ipng-dist; Sun, 18 Feb 2001 21:42:32 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1J5gM201969 for ; Sun, 18 Feb 2001 21:42:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA29782 for ; Sun, 18 Feb 2001 21:42:22 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA19341 for ; Sun, 18 Feb 2001 21:42:20 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:5db5:bab9:f757:5e42]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA06515; Mon, 19 Feb 2001 14:23:59 +0900 (JST) Date: Mon, 19 Feb 2001 14:37:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Matt Crawford Cc: Robert Elz , Paul Francis , ipng@sunroof.eng.sun.com Subject: Re: summary of Re: another renumbering question In-Reply-To: In your message of "Fri, 16 Feb 2001 15:05:15 -0600" <200102162105.PAA29612@gungnir.fnal.gov> References: <634.982311600@brandenburg.cs.mu.OZ.AU> <200102162105.PAA29612@gungnir.fnal.gov> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000414(IM141) Lines: 51 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 16 Feb 2001 15:05:15 -0600, >>>>> "Matt Crawford" said: >> | (By the way Robert, are the ICMP "tell me your >> | site local addresses" and ICMP "site local source exiting the site" messages >> | you mention [...]? >> >> The former is certainly new. > No -- draft-ietf-ipngwg-icmp-name-lookups-07.txt. Is this really enough? For example, I'm not sure if icmp-name-lookups works in the following scenario: Consider a mult-sited node A, that has 3 interfaces from I1 to I3. I1 and I2 belong to a site X, and I3 belongs to another site Y. I1| |I2 (site X) node A |I3 (site Y) Let's assume that - I1 has 1 global address (G). I2 has no site-local addresses. - I2 has 1 site-local address (S2). I2 has no global addresses. - I3 has 1 site-local address (S3). I3 has no global addresses. Now, is it possible for a node B in the site X wants to know the node A's site-local address(es) within the site X? If B sends a type 3 node information query with the "A-flag" being set, A will return both S2 and S3. But B would not able to tell which one belongs to the site X. If B sends a type 3 node information query without the "A-flag" being set and with the Subject Address being G, B will return no site-local addresses. If B sends a type 3 node information query without the "A-flag" being set and with the Subject Address being S2, B will return S2 (and S2 only). This result would be desirable, but is this really meaningful? IMO, if we care about multi-sited nodes, the icmp-name-lookups spec should be more scope-aware. For example, we should add another bit (or change the semantics of the A flag) so that the responder could return all addresses of a given scope in the same scope of the Subject Address. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Feb 18 22:36:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1J6ZVl02221 for ipng-dist; Sun, 18 Feb 2001 22:35:31 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1J6ZM202214 for ; Sun, 18 Feb 2001 22:35:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA04314 for ; Sun, 18 Feb 2001 22:35:21 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA18472 for ; Sun, 18 Feb 2001 23:35:21 -0700 (MST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA07225; Sun, 18 Feb 2001 22:28:30 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <2816.982381949@brandenburg.cs.mu.OZ.AU> References: <2816.982381949@brandenburg.cs.mu.OZ.AU> Date: Sun, 18 Feb 2001 22:28:28 -0800 To: Robert Elz From: Steve Deering Subject: Re: another renumbering question Cc: "Paul Francis" , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:52 AM +0700 2/17/01, Robert Elz wrote: >...it would be nice if we (more or less technical people) could >confine ourselves to the technical arguments, and ignore this >nonsense about how difficult it will be to assign consecutive integers. Those who ignore history.... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 00:34:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1J8VB002578 for ipng-dist; Mon, 19 Feb 2001 00:31:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1J8V2202571 for ; Mon, 19 Feb 2001 00:31:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA10993 for ; Mon, 19 Feb 2001 00:31:03 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26313 for ; Mon, 19 Feb 2001 00:30:59 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (sw11.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id PAA21735; Mon, 19 Feb 2001 15:30:51 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1J8UYd04031; Mon, 19 Feb 2001 15:30:38 +0700 (ICT) From: Robert Elz To: Steve Deering cc: "Paul Francis" , ipng@sunroof.eng.sun.com Subject: Re: another renumbering question In-reply-to: Your message of "Sun, 18 Feb 2001 22:28:28 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Feb 2001 15:30:34 +0700 Message-ID: <4029.982571434@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 18 Feb 2001 22:28:28 -0800 From: Steve Deering Message-ID: | Those who ignore history.... There's a difference between noting history, and the attitude "we tried this once, we had problems, so we will never try anything like it again" kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 00:40:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1J8cn502649 for ipng-dist; Mon, 19 Feb 2001 00:38:49 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1J8ca202633 for ; Mon, 19 Feb 2001 00:38:36 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11468 for ; Mon, 19 Feb 2001 00:38:36 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA16223 for ; Mon, 19 Feb 2001 00:38:29 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (sw11.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id PAA26454; Mon, 19 Feb 2001 15:38:10 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1J8c7d04048; Mon, 19 Feb 2001 15:38:09 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: summary of Re: another renumbering question In-reply-to: Your message of "Mon, 19 Feb 2001 14:37:59 +0900." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Feb 2001 15:38:07 +0700 Message-ID: <4046.982571887@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 Feb 2001 14:37:59 +0900 From: JINMEI Tatuya Message-ID: | IMO, if we care about multi-sited nodes, the icmp-name-lookups spec | should be more scope-aware. Yes, if we want to handle that scenario. And it may be a good thing to add that extra bit of generality anyway. However, if, in your example, I1 had also had only site local addresses, then this scheme could not work in the first place. The assumption is that all nodes have to have global addresses. If we insist upon that, we may as well also insist that all interfaces on all nodes have global addresses (to be accurate here, this applies really only to nodes that are to be the targets of a DNS initiated conversation - nodes that only ever initiate connections, and never receive any, would not need global addresses. We should probably ignore that.) If I2 has a global address (G2), then the node info request using G2 would find the site local (S2). And it may be that that is the desired result - if there's no site local corresponding to I1 (G) then someone who wants to communicate with G (ie: I1) probably should be using the global address (there had to be a reason I1 wasn't issued a site local addr after all). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 02:03:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JA2Au02998 for ipng-dist; Mon, 19 Feb 2001 02:02:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JA1x202991 for ; Mon, 19 Feb 2001 02:01:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18945 for ; Mon, 19 Feb 2001 02:01:59 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18358 for ; Mon, 19 Feb 2001 02:01:57 -0800 (PST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f1JA1md18895; Mon, 19 Feb 2001 11:01:52 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA19161; Mon, 19 Feb 2001 11:01:40 +0100 Message-ID: <3A90EF17.C7114389@era.ericsson.se> Date: Mon, 19 Feb 2001 11:01:59 +0100 From: Mattias Pettersson Organization: Ericsson Radio Systems AB X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en, sv MIME-Version: 1.0 To: "Powell, Ken" CC: "'T.J. Kniveton'" , mobile-ip@marvin.corpeast.baynetworks.com, ipng@sunroof.eng.sun.com Subject: Re: New idea for Router Sol/Adv and Mobility References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Powell, Ken" wrote: > I suppose another option would be to add a > "request aggregate prefix list" flag bit to > the router solicitation message. Such a flag > bit would be easier to implement in that > it would only impact the part of the stack > that deals with router solicitation/advertisement > processing. > > What do others prefer? I prefer this new RS type. If the HA needs to know what home _link_ is in question, in case there are more than one, it can use the destination address of the RS. Thus, one fewer purpose for the home address option. > I think the home agent should treat RS/RA exchanges > between HA and Mobile node's COA as a completely > separate situation and make no attempt to associate > them with a particular mobile node or binding. Yes. /Mattias -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 02:08:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JA7vl03036 for ipng-dist; Mon, 19 Feb 2001 02:07:57 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JA7m203029 for ; Mon, 19 Feb 2001 02:07:49 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19336 for ; Mon, 19 Feb 2001 02:07:48 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26331 for ; Mon, 19 Feb 2001 02:07:47 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA19914; Mon, 19 Feb 2001 12:18:51 +0200 Date: Mon, 19 Feb 2001 12:18:51 +0200 Message-Id: <200102191018.MAA19914@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com In-reply-to: <7695E2F6903F7A41961F8CF888D87EA80130CC3D@red-msg-06.redmond.corp.microsoft.com> (richdr@microsoft.com) Subject: Re: RA and Default routes? References: <7695E2F6903F7A41961F8CF888D87EA80130CC3D@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Continuing my "explanations" on prefix option handling. What I had coded, did basicly for each prefix option something like (for L-bit): if (L == 1) AddRoute(prefix, ONLINK); else AddRoute(prefix, GATEWAY, router); That is, I assumed that each router advertising a prefix without specifying it onlink, also was willing to route to all destinations matching this prefix. The plus side of this logic was - you could have multihomed network where routers come and go advertising different or same prefixes (WLAN with mobile client?). Routers can be configured independently (even if one client sees two routers, routers could be too far away and not see each other). The minus is of course, that above implicit gateway route will not work, if router is not also a default router (if it does not support "my little extension" :-). However, yes, I will change my implementation to match the RFC (by removing the "else" part :-). > See draft-draves-ipngwg-router-selection-00 for the functionality you > were thinking about. Yes, appears that the same effect can be achieved. I'm still unsure whether a separate option is really needed. Prefix option could just have a separate bit (instead of my implicit L==0), and preference bits (maybe into Reserved2). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 02:38:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JAbBZ03179 for ipng-dist; Mon, 19 Feb 2001 02:37:11 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JAb2203172 for ; Mon, 19 Feb 2001 02:37:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA17914; Mon, 19 Feb 2001 02:37:01 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06292; Mon, 19 Feb 2001 02:37:00 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f1JAas209950; Mon, 19 Feb 2001 11:36:55 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA08371; Mon, 19 Feb 2001 11:36:54 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f1JAarO35502; Mon, 19 Feb 2001 11:36:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200102191036.f1JAarO35502@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Dan McDonald cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 destination options questions... In-reply-to: Your message of Sun, 18 Feb 2001 16:04:35 PST. <200102190004.f1J04ZD24527@kebe.Eng.Sun.COM> Date: Mon, 19 Feb 2001 11:36:53 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: This sort of minutiae begs for reality checking. => do you know the discussion about this at the last IETF meeting? In the IPv6 spec (RFC 2460), you can see "destination options" occur in TWO places in an unprotected packet. The first place is the obvious place of just-before-the-transport-header. The second place is the more subtle just-before-the-routing-header, which has the semantic of making every node specified in the routing header process the destination options. => no, an application (like mobile IPv6) can specify another place (like just-after-the-routing-header (if any) and just-before- the-fragmentation-header (if any)). My questions are: 1.) In the routing header case, can those specified nodes change destination options inside that header between routing header hops? => yes 2.) If #1's answer is "yes", must those options have the "mutable" bit set in them? => yes 3.) In the just-before-transport case, is there any reason for any "mutable" options to be in that dest-opts bag? => no (The correct answer for the second part (IMHO) is "yes". The correct answer for the third part (again, IMHO) is "no".) => I agree. I suggested to fix the last point in (future) definitions of mutable options because to ask for support of mutable options after an AH is *silly*. Clear, precise answers to these questions makes AH for IPv6 implementable. These answers should also appear in the sucessor spec to RFC 2460 (and probably 2402 as well, but that's for another list). => I tried to fix the whole issue with destination options (read draft-dupont-destoptupd-00.txt) but the decision at the last IETF was not to add new name/type in order to manage the different destination option header positions but was to change the advanced API in order to express this complexity. Thanks Francis.Dupont@enst-bretagne.fr PS: ask Eric about advanced API proposed changes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 04:28:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JCRCU03574 for ipng-dist; Mon, 19 Feb 2001 04:27:12 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JCR3203567 for ; Mon, 19 Feb 2001 04:27:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA26985 for ; Mon, 19 Feb 2001 04:27:03 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13085 for ; Mon, 19 Feb 2001 04:27:02 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA20125; Mon, 19 Feb 2001 14:38:06 +0200 Date: Mon, 19 Feb 2001 14:38:06 +0200 Message-Id: <200102191238.OAA20125@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: Redirect ICMP and TAHI test? Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In RFC-2461 "8.1 Validation of Redirect Messages" there is "- The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address." In TAHI Neighbor Discovery test 62, it introduces two routers, then sends a redirect from "one" of them, and expects the redirect to have an effect... ...and in my code it doesn't, because I currently coded the validation literally in respect to the above entry. I take the destination address and check from the routing table which router would actually be getting this destination. And, as it happens, I pick the "other" and validation declares the redirect as invalid (e.g. I get a redirect from router, to wich I would not have sent the packet in question...) So, I assume I have to loosen the test, and accept redirects from any router, which potentially might be valid for the destination (for example, any of the default routers), even if it is not my "current first-hop router for the destination"? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 06:19:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JEIap03954 for ipng-dist; Mon, 19 Feb 2001 06:18:36 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JEIR203947 for ; Mon, 19 Feb 2001 06:18:27 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06306 for ; Mon, 19 Feb 2001 06:18:28 -0800 (PST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28456 for ; Mon, 19 Feb 2001 06:18:27 -0800 (PST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Mon, 19 Feb 2001 09:16:00 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 10JJ92LN; Mon, 19 Feb 2001 09:16:00 -0500 Received: from nortelnetworks.com (DEATHVALLEY [132.245.252.116]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM8L9; Mon, 19 Feb 2001 09:15:58 -0500 Message-ID: <3A912A6F.1365003D@nortelnetworks.com> Date: Mon, 19 Feb 2001 09:15:12 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: Host-based anycast Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, Dave Thaler and I just submitted an individual draft that describes a mechanism for allowing hosts to be members of anycast groups. It is available via the web at ftp://standards.nortelnetworks.com/ipv6/draft-haberman-ipngwg-host-anycast-00.txt Comments should be addressed to the authors or the mailing list. A supporting anycast services draft is in the works. Regards, Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 06:28:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JERNZ04012 for ipng-dist; Mon, 19 Feb 2001 06:27:23 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JERC204005 for ; Mon, 19 Feb 2001 06:27:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06974 for ; Mon, 19 Feb 2001 06:27:13 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28042 for ; Mon, 19 Feb 2001 06:27:12 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA12899 for ; Mon, 19 Feb 2001 08:27:11 -0600 (CST) Message-Id: <200102191427.IAA12899@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: another renumbering question In-reply-to: Your message of Fri, 16 Feb 2001 11:25:00 PST. <006301c098a3$26d29500$8cc90518@smateo1.sfba.home.com> Date: Mon, 19 Feb 2001 08:27:11 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Speaking rationally, 38 bits of address would allow ICANN to give out 100 > prefixes per second for the next 90 years. They could give them out ... And when those lazy stick-in-the-mud routing geeks finally figure out how to route a trillion unaggregatable prefixes, you're all set to go! :-) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 06:34:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JEWT004050 for ipng-dist; Mon, 19 Feb 2001 06:32:29 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JEWI204043 for ; Mon, 19 Feb 2001 06:32:18 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1JEWHL187342; Mon, 19 Feb 2001 06:32:18 -0800 (PST) Date: Mon, 19 Feb 2001 15:31:33 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Redirect ICMP and TAHI test? To: Markku Savela Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200102191238.OAA20125@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sounds like the TAHI test might be making an invalid assumption. The idea behind the validity test is that a node should only accept a redirect from router R1 if the node very recently sent a packet to R1 that was for the destination. In your implementation do you have something similar to a "destination cache" which retains the next hop where you last sent packet? Or do you always do a lookup and find the default route(s)? Erik >----- Begin Included Message -----< Date: Mon, 19 Feb 2001 14:38:06 +0200 From: "Markku Savela" Subject: Redirect ICMP and TAHI test? To: ipng@sunroof.eng.sun.com In RFC-2461 "8.1 Validation of Redirect Messages" there is "- The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address." In TAHI Neighbor Discovery test 62, it introduces two routers, then sends a redirect from "one" of them, and expects the redirect to have an effect... ...and in my code it doesn't, because I currently coded the validation literally in respect to the above entry. I take the destination address and check from the routing table which router would actually be getting this destination. And, as it happens, I pick the "other" and validation declares the redirect as invalid (e.g. I get a redirect from router, to wich I would not have sent the packet in question...) So, I assume I have to loosen the test, and accept redirects from any router, which potentially might be valid for the destination (for example, any of the default routers), even if it is not my "current first-hop router for the destination"? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- >----- End Included Message -----< -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 08:49:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JGmcw04628 for ipng-dist; Mon, 19 Feb 2001 08:48:38 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JGmK204615 for ; Mon, 19 Feb 2001 08:48:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28318 for ; Mon, 19 Feb 2001 08:48:21 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA16896 for ; Mon, 19 Feb 2001 08:48:20 -0800 (PST) Received: from 157.54.1.52 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 08:25:44 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 19 Feb 2001 08:25:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Redirect ICMP and TAHI test? Date: Mon, 19 Feb 2001 08:25:44 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8022560B5@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Redirect ICMP and TAHI test? Thread-Index: AcCab5yZxUhzXhKOS/eRq/dTEKZ2RgAILWnw From: "Richard Draves" To: "Markku Savela" Cc: X-OriginalArrivalTime: 19 Feb 2001 16:25:44.0648 (UTC) FILETIME=[9BD09480:01C09A90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1JGmM204616 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, the Redirect TAHI tests fail on the MS implementation, for the same reason. I think the test is broken. Rich > -----Original Message----- > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > Sent: Monday, February 19, 2001 4:38 AM > To: ipng@sunroof.eng.sun.com > Subject: Redirect ICMP and TAHI test? > > > In RFC-2461 "8.1 Validation of Redirect Messages" there is > > "- The IP source address of the Redirect is the same as the current > first-hop router for the specified ICMP Destination Address." > > In TAHI Neighbor Discovery test 62, it introduces two routers, then > sends a redirect from "one" of them, and expects the redirect to have > an effect... > > ...and in my code it doesn't, because I currently coded the validation > literally in respect to the above entry. I take the destination > address and check from the routing table which router would actually > be getting this destination. And, as it happens, I pick the "other" > and validation declares the redirect as invalid (e.g. I get a redirect > from router, to wich I would not have sent the packet in question...) > > So, I assume I have to loosen the test, and accept redirects from any > router, which potentially might be valid for the destination (for > example, any of the default routers), even if it is not my "current > first-hop router for the destination"? > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 08:49:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JGmd504629 for ipng-dist; Mon, 19 Feb 2001 08:48:39 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JGmK204614 for ; Mon, 19 Feb 2001 08:48:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28314 for ; Mon, 19 Feb 2001 08:48:20 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA16885 for ; Mon, 19 Feb 2001 08:48:20 -0800 (PST) Received: from 157.54.1.52 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 08:24:13 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 19 Feb 2001 08:25:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Redirect ICMP and TAHI test? Date: Mon, 19 Feb 2001 08:25:44 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8022560B6@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Redirect ICMP and TAHI test? Thread-Index: AcCagVC6Na1bNhrgR1qlM8VNm8mcuQADzcFA From: "Richard Draves" To: "Erik Nordmark" , "Markku Savela" Cc: X-OriginalArrivalTime: 19 Feb 2001 16:25:45.0054 (UTC) FILETIME=[9C0E87E0:01C09A90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1JGmM204617 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The idea behind the validity test is that a node should only accept > a redirect from router R1 if the node very recently sent a packet > to R1 that was for the destination. > > In your implementation do you have something similar to a > "destination cache" > which retains the next hop where you last sent packet? > Or do you always do a lookup and find the default route(s)? You're supposed to accept Redirects even if there is no Destination Cache entry... Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 08:51:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JGp9604659 for ipng-dist; Mon, 19 Feb 2001 08:51:09 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JGos204652 for ; Mon, 19 Feb 2001 08:50:54 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1JGopL204022; Mon, 19 Feb 2001 08:50:52 -0800 (PST) Date: Mon, 19 Feb 2001 17:50:05 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Redirect ICMP and TAHI test? To: Richard Draves Cc: Erik Nordmark , Markku Savela , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <7695E2F6903F7A41961F8CF888D87EA8022560B6@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > You're supposed to accept Redirects even if there is no Destination > Cache entry... Where does it say so? Or stated differently, this is already covered by rfc 2461 stating that conceptually there is a destination cache entry for all recently used destination addresses: Destination Cache - A set of entries about destinations to which traffic has been sent recently. The Destination Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 11:36:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JJZlF05267 for ipng-dist; Mon, 19 Feb 2001 11:35:47 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JJZb205260 for ; Mon, 19 Feb 2001 11:35:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10550 for ; Mon, 19 Feb 2001 11:35:37 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA05215 for ; Mon, 19 Feb 2001 11:35:37 -0800 (PST) Received: from 157.54.1.52 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 11:07:41 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 19 Feb 2001 11:08:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Redirect ICMP and TAHI test? Date: Mon, 19 Feb 2001 11:08:57 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA802256106@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Redirect ICMP and TAHI test? Thread-Index: AcCalCKfaR+16QOORd+pOXLWYSNA9QAEz+aw From: "Richard Draves" To: "Erik Nordmark" Cc: "Markku Savela" , X-OriginalArrivalTime: 19 Feb 2001 19:08:58.0242 (UTC) FILETIME=[69406E20:01C09AA7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1JJZc205261 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > You're supposed to accept Redirects even if there is no Destination > > Cache entry... > > Where does it say so? In RFC 2461: 8.3. Host Specification A host receiving a valid redirect SHOULD update its Destination Cache accordingly so that subsequent traffic goes to the specified target. If no Destination Cache entry exists for the destination, an implementation SHOULD create such an entry. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 11:51:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JJoVC05328 for ipng-dist; Mon, 19 Feb 2001 11:50:31 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JJoH205321 for ; Mon, 19 Feb 2001 11:50:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16016 for ; Mon, 19 Feb 2001 11:50:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02722 for ; Mon, 19 Feb 2001 11:50:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13183; Mon, 19 Feb 2001 14:50:14 -0500 (EST) Message-Id: <200102191950.OAA13183@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: Transmission of IPv6 Packets over IEEE 1394 Networks to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 19 Feb 2001 14:50:14 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider Transmission of IPv6 Packets over IEEE 1394 Networks as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 5, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-1394-01.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 14:44:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JMhNO05984 for ipng-dist; Mon, 19 Feb 2001 14:43:23 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JMhC205973 for ; Mon, 19 Feb 2001 14:43:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13320 for ; Mon, 19 Feb 2001 14:43:14 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA03277 for ; Mon, 19 Feb 2001 14:43:13 -0800 (PST) Received: (cpmta 71 invoked from network); 19 Feb 2001 14:36:32 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.64) with SMTP; 19 Feb 2001 14:36:32 -0800 X-Sent: 19 Feb 2001 22:36:32 GMT Message-ID: <01bd01c09ac4$6023cb80$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: References: <200102191427.IAA12899@gungnir.fnal.gov> Subject: Wade through the archives (was Re: another renumbering question) Date: Mon, 19 Feb 2001 14:36:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I took Steve up on his suggestion of looking through the archives on this topic. With some effort I found three threads, all initiated by Christian, in May '97, Dec '97, and Nov '99. I saved the relevent messages...you can find them at http://www.aciri.org/francis/IPv6_site_id_threads.txt if you are so inclined. This is probably not exhaustive, so if anyone can point me to other threads that would be helpful. I didn't see any major ideas in the previous threads that weren't in the latest thread. A problem I found when looking over the threads is that a complete picture of what a site ID would be and how it would work was never generated, with the end result that different people were talking about different things and to some extent talking past each other. Having read the arguments, I still believe that there is something to be said for the site-ID notion. The site-ID would be for sites that want to have their own number space for internal communications, with reasonable assurance that nobody else is using the same space. The site-ID would not supplant the use of site-locals by other sites who wanted to use them. Site-locals would remain as defined. A site-ID would also not by itself identify what is and is not in a given "site". In other words, one couldn't take two addresses with site-IDs and, in the absense of any other information (DNS entries or routing tables) say definitively whether they could or could not reach each other using the site-ID addresses. I'm inclined to write a draft specifying this so that we can have a focused and consistent (and dare I say difinitive?) discussion about it. Is there anyone out there who in principle likes the idea of site-IDs and would care to work with me on this? Thanks, PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 17:37:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K1aHY06631 for ipng-dist; Mon, 19 Feb 2001 17:36:17 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K1a8206624 for ; Mon, 19 Feb 2001 17:36:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19172 for ; Mon, 19 Feb 2001 17:36:08 -0800 (PST) Received: from mx02.melco.co.jp (mx01.melco.co.jp [192.218.140.41]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28789 for ; Mon, 19 Feb 2001 17:35:48 -0800 (PST) Received: by mx02.melco.co.jp (mx02) id KAA06590; Tue, 20 Feb 2001 10:35:43 +0900 (JST) Received: by mr02.melco.co.jp (mr02) id KAA29814; Tue, 20 Feb 2001 10:35:42 +0900 (JST) Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id KAA21390; Tue, 20 Feb 2001 10:35:41 +0900 (JST) Received: from ishitp570 by islgw.isl.melco.co.jp (8.8.8/3.6W) id KAA17112; Tue, 20 Feb 2001 10:35:40 +0900 (JST) Message-ID: <00ec01c09add$8d7c08e0$1a084a0a@ishitp570> From: "Koichi Ishibashi" To: "Hesham Soliman \(ERA\)" , , References: <034BEFD03799D411A59F00508BDF75465B6A61@esealnt448.al.sw.ericsson.se> Subject: Re: New idea for Router Sol/Adv and Mobility Date: Tue, 20 Feb 2001 10:36:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Hesham Soliman (ERA)" To: ; Sent: Sunday, February 18, 2001 9:21 PM Subject: RE: New idea for Router Sol/Adv and Mobility > Hello Ken, > > Erik suggested in his email definnig a new type for > the RS. The use of this new type should be enough > to show the HA that the request is coming from a MN > and that it is not a normal RS. > > I think doing that removes the need for the Home address > option and the additional complication that comes > with that (what should be in the option ...etc). > Also it would be a much cleaner approach IMO. > > Cheers, > Hesham > > > > -----Original Message----- > > From: Powell, Ken [SMTP:Ken.Powell@compaq.com] > > Sent: Saturday, 17 February 2001 9:55 > > To: 'T.J. Kniveton'; mobile-ip@marvin.corpeast.baynetworks.com; ipng@sunroof.eng.sun.com > > Subject: RE: New idea for Router Sol/Adv and Mobility > > > > Hesham's response helped greatly to resolve the > > security questions I had. > > > > At first, I thought the RS/RA exchange between the > > mobile node's COA and the home agent during > > initialization shouldn't use the home address or > > routing header options. That was until I discussed > > this with Vlad Yasevich today. > > > > We don't have any reasons for the initial > > router advertisement sent back to the mobile > > node's COA to have a routing header, but > > there is a reason for keeping the home > > address option on the router solicitation. > > > > Vlad pointed out that the Home Agent needs a > > way to tell that a router solicitation was sent by > > a mobile node. This is important because the home > > agent needs to send the aggregate prefix list as > > defined in section 9.7.1 instead of just the home > > agent's own locally defined prefix list. Without some > > flag, a home agent would be forced to assume that any > > IPsec protected router solicitation with a global > > source address came from a mobile node. Reliance on > > this assumption could cause problems with some future > > application that may also need RS/RA exchanges with > > non-linklocal addresses. Attaching the home address > > option to the router solicit solves this problem. > > > > Assuming that the home address option is needed, > > what address should it contain before the mobile > > node generates its home address? On first > > glance, the unspecified address seems best. It is > > a clear signal that the mobile node has no home > > address and that there is no binding. The other > > choice is to repeat the care-of address as you > > suggested. This might be easier to implement by > > requiring less special logic in the protocol stack > > for IPsec and home address option handling. > > I haven't thought through all the details. > > Both these options are going to require some > > special handling. > > > > I suppose another option would be to add a > > "request aggregate prefix list" flag bit to > > the router solicitation message. Such a flag > > bit would be easier to implement in that > > it would only impact the part of the stack > > that deals with router solicitation/advertisement > > processing. > > > > What do others prefer? > > > > On to another concern... > > > > I've been trying to sort out how this proposal impacts > > section 9.7.2 which specifies the rules for when the > > home agent sends Router Advertisements to the mobile > > node. These rules require the home agent keep track > > of which router advertisement information was sent > > to each mobile node. It seems natural that this > > state information be stored with the binding cache > > entry. I couldn't see how the home agent could > > track the information from the RS/RA exchange before > > a binding is created. > > > > I think the home agent should treat RS/RA exchanges > > between HA and Mobile node's COA as a completely > > separate situation and make no attempt to associate > > them with a particular mobile node or binding. > > > > When a mobile node sends an IPsec protected RS to a > > home agent from its COA, the home agent should reply > > with an ipsec protected RA to the mobile node's COA and > > no routing header. The home agent may rate limit the RA's > > sent to a particular COA. This should be done independently > > from the procedure to send RA's to the mobile node's home> > > address. > > > > To summarize, I think the current draft should: > > > > 1) Use home address option when the mobile node > > sends router solicitations from its home address > > to the home agent instead of fully encapsulating > > the router solicitation. > > > > 2) Protect router solicitations from the mobile > > node with IPsec, the same as router advertisements > > are protected. > > > > 3) Add a new mechanism for an IPsec protected > > RS/RA exchange between the mobile node's COA > > and home agent for possible use during > > initialization. This gets rid of any need > > for a temporary home address as mentioned > > in appendix A. I'm still undecided how > > to handle the home address option here. > > > > I'm going to be off-line next week and won't be > > able to respond to any questions till I get back. > > > > Ken > > > > > -----Original Message----- > > > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > > > Sent: Friday, February 16, 2001 1:41 AM > > > To: Powell, Ken; 'mobile-ip@standards.nortelnetworks.com'; > > > ipng@sunroof.eng.sun.com > > > Subject: Re: New idea for Router Sol/Adv and Mobility > > > > > > > > > on 2/15/01 1:46 PM, Powell, Ken wrote: > > > > > > > Under this proposal, the Mobile Node will have to re-establish the > > > > Security Association between the Home Agent and its Care-Of Address > > > > every time it moves to support IPsec requirements for Router > > > > Advertisements. How does this fit in with the process of > > > > forming the new care-of address and updating bindings? Will > > > > this cause additional hand-off delays? > > > > > > > > > > Good question. Where this question leads is, how can the HA > > > trust an MN when > > > the MN does not have a trustable identity based on a Home network IP > > > address? Does it make sense to base security associations on > > > IP addresses > > > when the addresses themselves are ephemeral and can't be associated to > > > Identity without the involvement of an outside entity? > > > > > > Clearly this is already a hot topic. Rather than trying to > > > solve it here, > > > perhaps I can offer a compromise which allows for the > > > possibility of future > > > elaboration. > > > > > > Here's the recipe: start with Draft 13. Now remove > > > encapsulation from RSs > > > (this is unnecessary and inconsistent). Add the rules for TTL<255 and > > > mobility processing, as stated in my previous message. Stir > > > in addressing as > > > follows: > > > > > > 1. The RS is sent with a HAddr option. The HAddr contains the > > > MN's Home > > > Address (naturally), EXCEPT if the MN has not configured one, > > > in which case > > > it MAY insert the COA instead. > > > > > > 2. The HA sends an RA using a routing header, as usual. The > > > RHdr contains > > > whatever was in the HAddr option - namely, the Home Address, > > > EXCEPT if the > > > COA was in the RS's HAddr option, it goes in the routing > > > header (we could > > > just leave the routing header off, alternatively). This RA is still > > > protected by IPsec as in the draft. > > > > > > This is the best of both worlds: > > > - In the steady-state case, where a MN has a HAddr, and it > > > needs updated > > > prefix info, it just sends an RS and the RA is protected with > > > the existing > > > security association > > > > > > - If the MN does not yet have a HAddr, it uses the COA, > > > *assuming you have a > > > way to generate a security association between the HA and the > > > COA*. If you > > > can not do this, there is no way to get an IPSEC-protected > > > RA. This is part > > > of the "bootstrap problem." > > > As soon as the MN gets a home address, it can use the HAddr > > > in all future > > > RSs, so this does not suffer from the problem Ken brought up, > > > of having to > > > update the HA/COA sec.assoc. every time you handover. Using > > > the COA is a > > > one-time thing while bootstrapping. > > > > > > This leaves room open for developing a dynamic security > > > architecture where > > > trust is based on something other than strictly the IP address. For> > > > instance, an NAI, signed key, (whatever) might be used instead. > > > > > > > > > > How does the home agent determine which mobile node sent the > > > > Router Solicitation? Can the Care-of address on a mobile node > > > > be relied on for this? > > > > > > I contend it doesn't matter. You just need to know that it > > > was sent from a > > > mobile node. The information you include in a solicited RA > > > consists of the > > > prefixes from your own AdvPrefixList, and the prefixes advertised (and > > > therefore served) by all other HAs on the link. No other > > > prefixes will be > > > Mobile-IP-routable, and so they don't matter while the MN is > > > off-link. The > > > MN should be able to configure any/all of these prefixes and > > > be served by > > > any of these HAs, so you must send them all to any node who solicits. > > > > > > > > > >[Mattias Pettersson wrote:] > > > >> > > > >> Will we open up a security hole or possible denial-of service > > > >> attack by let's say flood a HA with RSes (that don't require > > > >> authentication), now that we can send them over multiple hops? > > > >> > > > > > > > > Yes, this does look like a problem, but I think its just as > > > > serious in draft 13. Any node could repeatedly send router > > > > solicits with the mobile node's care-of address (and home > > > > address). The home agent would send a complete Router > > > > Advertisement to the mobile node for each Router Solicit, > > > > possibly eating up expensive wireless bandwidth. Perhaps > > > > the Router Solicit should be IPsec protected? > > > > > > The problem isn't bandwidth here. The security issue is that > > > anyone can see > > > the prefix information about that potentially private network. You are > > > thereby exposing the fact that a certain IP address is a > > > router, that it's > > > also a home agent, and what some or all of the prefixes on > > > that link are. > > > And you're exposing it to anyone along the path to the MN. > > > > > > Regarding the bandwidth issue, who cares that the HA will > > > send RAs to the > > > mobile? If you want to use the MN's bandwidth, nothing stops > > > you from just > > > sending it packets yourself! Anyway, the HA could protect > > > against this by > > > limiting the rate at which it sends RAs. > > > > > > > > Ken > > > > > > > > > > > > > So I am interested in your comments on my compromise proposal. > > > -- > > > TJ Kniveton > > > NOKIA Research > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 18:39:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K2biD06852 for ipng-dist; Mon, 19 Feb 2001 18:37:44 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K2bZ206845 for ; Mon, 19 Feb 2001 18:37:35 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01604 for ; Mon, 19 Feb 2001 18:37:34 -0800 (PST) Received: from perilla.nov.tahi.org (oxalis.nezu.wide.ad.jp [203.178.142.208]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18901 for ; Mon, 19 Feb 2001 18:37:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by perilla.nov.tahi.org (8.9.3/8.9.3) with ESMTP id LAA46144; Tue, 20 Feb 2001 11:37:26 +0900 (JST) (envelope-from nov@tahi.org) To: msa@burp.tkv.asdf.org Cc: ipng@sunroof.eng.sun.com Subject: Re: Redirect ICMP and TAHI test? From: OKABE Nobuo In-Reply-To: <200102191238.OAA20125@burp.tkv.asdf.org> References: <200102191238.OAA20125@burp.tkv.asdf.org> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010220113725N.nov@tahi.org> Date: Tue, 20 Feb 2001 11:37:25 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Markku, Thank you for your feedback. I need your help to start examining the test that you pointed. Could you give me a name of the test instead of number? ex. ncStateByRedirect4Reachable.seq Test number is frequently changed. I would appreciate your help. From: Markku Savela Subject: Redirect ICMP and TAHI test? Date: Mon, 19 Feb 2001 14:38:06 +0200 > In RFC-2461 "8.1 Validation of Redirect Messages" there is > > "- The IP source address of the Redirect is the same as the current > first-hop router for the specified ICMP Destination Address." > > In TAHI Neighbor Discovery test 62, it introduces two routers, then > sends a redirect from "one" of them, and expects the redirect to have > an effect... > > ...and in my code it doesn't, because I currently coded the validation > literally in respect to the above entry. I take the destination > address and check from the routing table which router would actually > be getting this destination. And, as it happens, I pick the "other" > and validation declares the redirect as invalid (e.g. I get a redirect > from router, to wich I would not have sent the packet in question...) > > So, I assume I have to loosen the test, and accept redirects from any > router, which potentially might be valid for the destination (for > example, any of the default routers), even if it is not my "current > first-hop router for the destination"? --- nobuo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 19:18:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K3HQv07015 for ipng-dist; Mon, 19 Feb 2001 19:17:26 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K3HG207008 for ; Mon, 19 Feb 2001 19:17:16 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02918 for ; Mon, 19 Feb 2001 19:17:16 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA08505 for ; Mon, 19 Feb 2001 19:17:16 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 19 Feb 2001 19:17:36 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 19:16:43 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 19 Feb 2001 19:16:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Wade through the archives (was Re: another renumbering question) Date: Mon, 19 Feb 2001 19:16:42 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wade through the archives (was Re: another renumbering question) Thread-Index: AcCaxb/9/xF2iXSETma1F+l5vhIUtAADaxlA From: "Christian Huitema" To: "Paul Francis" , X-OriginalArrivalTime: 20 Feb 2001 03:16:43.0053 (UTC) FILETIME=[8C7035D0:01C09AEB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1K3HH207009 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The discussions always ended up on the same kind of conclusion: in theory it is a fine idea, but we would have to change existing implementation, and besides it is not easy to allocate unique numbers. There are basically four ways to allocate random numbers, and none of them is particularly attractive: 1) Picking numbers at random is easy, but you need a good random generator, and besides you hit the birthday paradox with 2^^19 entries, i.e. less than a million. There are way more than 1 million potential sites. 2) Deriving numbers from other pre-established registries is tempting, but there are not very many suitable pre-existing registries. IEEE-802 numbers are too large too fit; IPv4 addresses have the right size but not the right stability. 3) Starting a new registry looks simple on paper, but the practical problem are not so small -- for example, decide who will be king; find the right balance between automation and reliability; etc. 4) Combining random allocation with duplicate detection would go past the birthday paradox, but is almost impossible to conduct at the scale of the Internet... Now, if you can change that... -- Christian Huitema > -----Original Message----- > From: Paul Francis [mailto:paul@francis.com] > Sent: Monday, February 19, 2001 2:36 PM > To: ipng@sunroof.eng.sun.com > Subject: Wade through the archives (was Re: another > renumbering question) > > > > I took Steve up on his suggestion of looking through the > archives on this topic. > > With some effort I found three threads, all initiated by > Christian, in May '97, Dec '97, and Nov '99. I saved the > relevent messages...you can find them at > http://www.aciri.org/francis/IPv6> _site_id_threads.txt if you > are so inclined. This is > probably not exhaustive, so if anyone can point me to other > threads that would be helpful. > > I didn't see any major ideas in the previous threads that > weren't in the latest thread. > > A problem I found when looking over the threads is that a > complete picture of what a site ID would be and how it would > work was never generated, with the end result that different > people were talking about different things and to some extent > talking past each other. > > Having read the arguments, I still believe that there is > something to be said for the site-ID notion. The site-ID > would be for sites that want to have their own number space > for internal communications, with reasonable assurance that > nobody else is using the same space. > > The site-ID would not supplant the use of site-locals by > other sites who wanted to use them. Site-locals would remain > as defined. > > A site-ID would also not by itself identify what is and is > not in a given "site". In other words, one couldn't take two > addresses with site-IDs and, in the absense of any other > information (DNS entries or routing tables) say definitively > whether they could or could not reach each other using the > site-ID addresses. > > I'm inclined to write a draft specifying this so that we can > have a focused and consistent (and dare I say difinitive?) > discussion about it. Is there anyone out there who in > principle likes the idea of site-IDs and would care to work > with me on this? > > Thanks, > > PF > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 20:16:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K4GAt07251 for ipng-dist; Mon, 19 Feb 2001 20:16:10 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K4Fx207240 for ; Mon, 19 Feb 2001 20:16:00 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11495 for ; Mon, 19 Feb 2001 20:15:39 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA21337 for ; Mon, 19 Feb 2001 20:15:39 -0800 (PST) Received: (cpmta 23644 invoked from network); 19 Feb 2001 20:15:38 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO sony) (24.5.201.140) by smtp.francis.com (209.228.32.64) with SMTP; 19 Feb 2001 20:15:38 -0800 X-Sent: 20 Feb 2001 04:15:38 GMT Message-ID: <004101c09af4$14f879a0$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Christian Huitema" , References: Subject: Re: Wade through the archives (was Re: another renumbering question) Date: Mon, 19 Feb 2001 20:17:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The discussions always ended up on the same kind of conclusion: in > theory it is a fine idea, but we would have to change existing > implementation, Assuming implementations have to be changed, then this means that it'll take a few years for the functionality to get out there, but otherwise this is not a good reason not to do it per se. But speaking of existing implementations, what would happen if an existing router advertised to an existing host that one of the host's prefixes contained a site ID (that is, a site-local with a non-zero 38-bit number). Presumably the host would accept it? And, if you were running two-faced DNS, then when the host did a DNS lookup on another host in the same site (apologies to those of you who hate two-faced DNS, but lots of folks use it so this would be valuable for at least some of the community), it would get back a site-ID-based address and all would be fine, yes? Same as with site-IDs. For those sites that don't want to run two-faced DNS but do want site-IDs, they'd have to wait a few years. (As it stands today with existing implementaitons if you don'trun two-faced DNS you can't use site-locals anyway.) > and besides it is not easy to allocate unique numbers. > There are basically four ways to allocate random numbers, and none of > them is particularly attractive: > Agreed that it isn't easy to allocate unique numbers. Is that a good enough reason not to pursue this? I mean, lets say we design how to do site-IDs and get buy-in from the gang. Then we go off to ICANN or whoever, and they screw it up. Ok then it was a failure and too bad. (Or, we go off and create a renegade registry...that'd be interesting :-) (Or, do the renegade registry first and force ICANN's hand...) Either way, the exercise would be a learning experience for the IPv6 group, and the time wasted would mainly be just the poor disillusioned souls that worked on the draft... PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 20:35:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K4YHn07311 for ipng-dist; Mon, 19 Feb 2001 20:34:17 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K4Y8207304 for ; Mon, 19 Feb 2001 20:34:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA13845 for ; Mon, 19 Feb 2001 20:34:08 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA21211 for ; Mon, 19 Feb 2001 20:34:06 -0800 (PST) Received: from 157.54.1.52 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 20:30:52 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 19 Feb 2001 20:30:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Wade through the archives (was Re: another renumbering question) Date: Mon, 19 Feb 2001 20:30:52 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80225620F@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wade through the archives (was Re: another renumbering question) Thread-Index: AcCa9CDtcjXKMCk1RoClodtSTS96XwAAYK2Q From: "Richard Draves" To: "Paul Francis" , "Christian Huitema" , X-OriginalArrivalTime: 20 Feb 2001 04:30:53.0335 (UTC) FILETIME=[E9035A70:01C09AF5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1K4Y9207305 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But speaking of existing implementations, what would happen > if an existing > router advertised to an existing host that one of the host's prefixes > contained a site ID (that is, a site-local with a non-zero > 38-bit number). > Presumably the host would accept it? I haven't tried this, but I believe the MS implementation would accept a non-zero 38-bit number in a site-local prefix. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 19 21:19:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K5IkG07483 for ipng-dist; Mon, 19 Feb 2001 21:18:46 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K5Ib207476 for ; Mon, 19 Feb 2001 21:18:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12983 for ; Mon, 19 Feb 2001 21:18:36 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA12875 for ; Mon, 19 Feb 2001 22:18:34 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:88d7:bffc:a103:967d]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA14648; Tue, 20 Feb 2001 14:00:42 +0900 (JST) Date: Tue, 20 Feb 2001 14:14:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: summary of Re: another renumbering question In-Reply-To: In your message of "Mon, 19 Feb 2001 15:38:07 +0700" <4046.982571887@brandenburg.cs.mu.OZ.AU> References: <4046.982571887@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000414(IM141) Lines: 35 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 19 Feb 2001 15:38:07 +0700, >>>>> Robert Elz said: > | IMO, if we care about multi-sited nodes, the icmp-name-lookups spec > | should be more scope-aware. > Yes, if we want to handle that scenario. And it may be a good thing > to add that extra bit of generality anyway. > However, if, in your example, I1 had also had only site local addresses, > then this scheme could not work in the first place. The assumption is > that all nodes have to have global addresses. If we insist upon that, > we may as well also insist that all interfaces on all nodes have global > addresses (to be accurate here, this applies really only to nodes that > are to be the targets of a DNS initiated conversation - nodes that only > ever initiate connections, and never receive any, would not need global > addresses. We should probably ignore that.) > If I2 has a global address (G2), then the node info request using G2 > would find the site local (S2). And it may be that that is the desired > result - if there's no site local corresponding to I1 (G) then someone > who wants to communicate with G (ie: I1) probably should be using the > global address (there had to be a reason I1 wasn't issued a site local addr > after all). Basically, I agree on all the points above, but I did not intend to insist anything. I just would like to point out that it's not so trivial to use icmp-name-lookups as a protocol of "tell me your site local addresses". It is sometimes meaningless, and it sometimes does not work... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 00:57:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K8tur08292 for ipng-dist; Tue, 20 Feb 2001 00:55:56 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K8ti208281 for ; Tue, 20 Feb 2001 00:55:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA07833 for ; Tue, 20 Feb 2001 00:55:45 -0800 (PST) Received: from m018.com ([210.112.11.138]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA22780 for ; Tue, 20 Feb 2001 00:55:43 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 20 Feb 2001 17:48:39 +0900 Received: from patan.sun.com ([192.18.98.43]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 20 Feb 2001 13:31:12 +0900 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA27773; Mon, 19 Feb 2001 20:37:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA14098; Mon, 19 Feb 2001 20:36:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K4YHn07311 for ipng-dist; Mon, 19 Feb 2001 20:34:17 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K4Y8207304 for ; Mon, 19 Feb 2001 20:34:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA13845 for ; Mon, 19 Feb 2001 20:34:08 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA21211 for ; Mon, 19 Feb 2001 20:34:06 -0800 (PST) Received: from 157.54.1.52 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 20:30:52 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 19 Feb 2001 20:30:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Wade through the archives (was Re: another renumbering question) Date: Mon, 19 Feb 2001 20:30:52 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80225620F@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wade through the archives (was Re: another renumbering question) Thread-Index: AcCa9CDtcjXKMCk1RoClodtSTS96XwAAYK2Q From: "Richard Draves" To: "Paul Francis" , "Christian Huitema" , X-OriginalArrivalTime: 20 Feb 2001 04:30:53.0335 (UTC) FILETIME=[E9035A70:01C09AF5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1K4Y9207305 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But speaking of existing implementations, what would happen > if an existing > router advertised to an existing host that one of the host's prefixes > contained a site ID (that is, a site-local with a non-zero > 38-bit number). > Presumably the host would accept it? I haven't tried this, but I believe the MS implementation would accept a non-zero 38-bit number in a site-local prefix. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 00:58:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K8v3508318 for ipng-dist; Tue, 20 Feb 2001 00:57:03 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K8ud208310 for ; Tue, 20 Feb 2001 00:56:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA21084 for ; Tue, 20 Feb 2001 00:56:40 -0800 (PST) Received: from m018.com ([210.112.11.138]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA08414 for ; Tue, 20 Feb 2001 01:56:39 -0700 (MST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 20 Feb 2001 17:50:09 +0900 Received: from patan.sun.com ([192.18.98.43]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 20 Feb 2001 13:13:01 +0900 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22093; Mon, 19 Feb 2001 20:18:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA08014; Mon, 19 Feb 2001 20:18:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K4GAt07251 for ipng-dist; Mon, 19 Feb 2001 20:16:10 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K4Fx207240 for ; Mon, 19 Feb 2001 20:16:00 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11495 for ; Mon, 19 Feb 2001 20:15:39 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA21337 for ; Mon, 19 Feb 2001 20:15:39 -0800 (PST) Received: (cpmta 23644 invoked from network); 19 Feb 2001 20:15:38 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO sony) (24.5.201.140) by smtp.francis.com (209.228.32.64) with SMTP; 19 Feb 2001 20:15:38 -0800 X-Sent: 20 Feb 2001 04:15:38 GMT Message-ID: <004101c09af4$14f879a0$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Christian Huitema" , References: Subject: Re: Wade through the archives (was Re: another renumbering question) Date: Mon, 19 Feb 2001 20:17:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The discussions always ended up on the same kind of conclusion: in > theory it is a fine idea, but we would have to change existing > implementation, Assuming implementations have to be changed, then this means that it'll take a few years for the functionality to get out there, but otherwise this is not a good reason not to do it per se. But speaking of existing implementations, what would happen if an existing router advertised to an existing host that one of the host's prefixes contained a site ID (that is, a site-local with a non-zero 38-bit number). Presumably the host would accept it? And, if you were running two-faced DNS, then when the host did a DNS lookup on another host in the same site (apologies to those of you who hate two-faced DNS, but lots of folks use it so this would be valuable for at least some of the community), it would get back a site-ID-based address and all would be fine, yes? Same as with site-IDs. For those sites that don't want to run two-faced DNS but do want site-IDs, they'd have to wait a few years. (As it stands today with existing implementaitons if you don'trun two-faced DNS you can't use site-locals anyway.) > and besides it is not easy to allocate unique numbers. > There are basically four ways to allocate random numbers, and none of > them is particularly attractive: > Agreed that it isn't easy to allocate unique numbers. Is that a good enough reason not to pursue this? I mean, lets say we design how to do site-IDs and get buy-in from the gang. Then we go off to ICANN or whoever, and they screw it up. Ok then it was a failure and too bad. (Or, we go off and create a renegade registry...that'd be interesting :-) (Or, do the renegade registry first and force ICANN's hand...) Either way, the exercise would be a learning experience for the IPv6 group, and the time wasted would mainly be just the poor disillusioned souls that worked on the draft... PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 00:58:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K8uqu08317 for ipng-dist; Tue, 20 Feb 2001 00:56:52 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K8uV208302 for ; Tue, 20 Feb 2001 00:56:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01580 for ; Tue, 20 Feb 2001 00:56:32 -0800 (PST) Received: from m018.com ([210.112.11.138]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA23117 for ; Tue, 20 Feb 2001 00:56:31 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 20 Feb 2001 17:48:15 +0900 Received: from mercury.Sun.COM ([192.9.25.1]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 20 Feb 2001 14:14:49 +0900 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA11033; Mon, 19 Feb 2001 21:20:39 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA16822; Mon, 19 Feb 2001 21:20:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K5IkG07483 for ipng-dist; Mon, 19 Feb 2001 21:18:46 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K5Ib207476 for ; Mon, 19 Feb 2001 21:18:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12983 for ; Mon, 19 Feb 2001 21:18:36 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA12875 for ; Mon, 19 Feb 2001 22:18:34 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:88d7:bffc:a103:967d]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA14648; Tue, 20 Feb 2001 14:00:42 +0900 (JST) Date: Tue, 20 Feb 2001 14:14:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: summary of Re: another renumbering question In-Reply-To: In your message of "Mon, 19 Feb 2001 15:38:07 +0700" <4046.982571887@brandenburg.cs.mu.OZ.AU> References: <4046.982571887@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000414(IM141) Lines: 35 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 19 Feb 2001 15:38:07 +0700, >>>>> Robert Elz said: > | IMO, if we care about multi-sited nodes, the icmp-name-lookups spec > | should be more scope-aware. > Yes, if we want to handle that scenario. And it may be a good thing > to add that extra bit of generality anyway. > However, if, in your example, I1 had also had only site local addresses, > then this scheme could not work in the first place. The assumption is > that all nodes have to have global addresses. If we insist upon that, > we may as well also insist that all interfaces on all nodes have global > addresses (to be accurate here, this applies really only to nodes that > are to be the targets of a DNS initiated conversation - nodes that only > ever initiate connections, and never receive any, would not need global > addresses. We should probably ignore that.) > If I2 has a global address (G2), then the node info request using G2 > would find the site local (S2). And it may be that that is the desired > result - if there's no site local corresponding to I1 (G) then someone > who wants to communicate with G (ie: I1) probably should be using the > global address (there had to be a reason I1 wasn't issued a site local addr > after all). Basically, I agree on all the points above, but I did not intend to insist anything. I just would like to point out that it's not so trivial to use icmp-name-lookups as a protocol of "tell me your site local addresses". It is sometimes meaningless, and it sometimes does not work... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 01:08:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K91t408659 for ipng-dist; Tue, 20 Feb 2001 01:01:57 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K906208454 for ; Tue, 20 Feb 2001 01:00:07 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1K903L295314; Tue, 20 Feb 2001 01:00:03 -0800 (PST) Date: Tue, 20 Feb 2001 09:59:16 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Redirect ICMP and TAHI test? To: Richard Draves Cc: Erik Nordmark , Markku Savela , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <7695E2F6903F7A41961F8CF888D87EA802256106@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 8.3. Host Specification > > A host receiving a valid redirect SHOULD update its Destination Cache > accordingly so that subsequent traffic goes to the specified target. > If no Destination Cache entry exists for the destination, an > implementation SHOULD create such an entry. But the above is a SHOULD and the validity checks in section 8.1 say MUST discard when this fails: - The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address. If there is only one default route pointing at the link from which the redirect was received (or for implementations with a richer routing table, the lookup of the destination address only finds one routing table entry that points at that link), then the redirect can be safely used to create a destination cache entry. But when the lookup finds more than one possible next hops that might have been used to send the original packet, it seems a bit dangerous to accept the redirect. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 01:08:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K94TC08786 for ipng-dist; Tue, 20 Feb 2001 01:05:01 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K90u208584 for ; Tue, 20 Feb 2001 01:00:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01970 for ; Tue, 20 Feb 2001 01:00:54 -0800 (PST) Received: from m018.com ([210.112.11.138]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09606 for ; Tue, 20 Feb 2001 01:00:53 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 20 Feb 2001 17:53:41 +0900 Received: from patan.sun.com ([192.18.98.43]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 20 Feb 2001 01:47:09 +0900 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19604; Mon, 19 Feb 2001 08:53:29 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19934; Mon, 19 Feb 2001 08:53:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JGp9604659 for ipng-dist; Mon, 19 Feb 2001 08:51:09 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JGos204652 for ; Mon, 19 Feb 2001 08:50:54 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1JGopL204022; Mon, 19 Feb 2001 08:50:52 -0800 (PST) Date: Mon, 19 Feb 2001 17:50:05 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Redirect ICMP and TAHI test? To: Richard Draves Cc: Erik Nordmark , Markku Savela , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <7695E2F6903F7A41961F8CF888D87EA8022560B6@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > You're supposed to accept Redirects even if there is no Destination > Cache entry... Where does it say so? Or stated differently, this is already covered by rfc 2461 stating that conceptually there is a destination cache entry for all recently used destination addresses: Destination Cache - A set of entries about destinations to which traffic has been sent recently. The Destination Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 01:08:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K94Uq08778 for ipng-dist; Tue, 20 Feb 2001 01:05:03 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K90g208545 for ; Tue, 20 Feb 2001 01:00:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA08260 for ; Tue, 20 Feb 2001 01:00:42 -0800 (PST) Received: from m018.com ([210.112.11.138]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08588 for ; Tue, 20 Feb 2001 01:00:41 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 20 Feb 2001 17:53:58 +0900 Received: from mercury.Sun.COM ([192.9.25.1]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 20 Feb 2001 01:46:43 +0900 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15647; Mon, 19 Feb 2001 08:52:57 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24791; Mon, 19 Feb 2001 08:51:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JGmcw04628 for ipng-dist; Mon, 19 Feb 2001 08:48:38 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JGmK204615 for ; Mon, 19 Feb 2001 08:48:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28318 for ; Mon, 19 Feb 2001 08:48:21 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA16896 for ; Mon, 19 Feb 2001 08:48:20 -0800 (PST) Received: from 157.54.1.52 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 08:25:44 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 19 Feb 2001 08:25:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Redirect ICMP and TAHI test? Date: Mon, 19 Feb 2001 08:25:44 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8022560B5@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Redirect ICMP and TAHI test? Thread-Index: AcCab5yZxUhzXhKOS/eRq/dTEKZ2RgAILWnw From: "Richard Draves" To: "Markku Savela" Cc: X-OriginalArrivalTime: 19 Feb 2001 16:25:44.0648 (UTC) FILETIME=[9BD09480:01C09A90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1JGmM204616 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, the Redirect TAHI tests fail on the MS implementation, for the same reason. I think the test is broken. Rich > -----Original Message----- > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > Sent: Monday, February 19, 2001 4:38 AM > To: ipng@sunroof.eng.sun.com > Subject: Redirect ICMP and TAHI test? > > > In RFC-2461 "8.1 Validation of Redirect Messages" there is > > "- The IP source address of the Redirect is the same as the current > first-hop router for the specified ICMP Destination Address." > > In TAHI Neighbor Discovery test 62, it introduces two routers, then > sends a redirect from "one" of them, and expects the redirect to have > an effect... > > ...and in my code it doesn't, because I currently coded the validation > literally in respect to the above entry. I take the destination > address and check from the routing table which router would actually > be getting this destination. And, as it happens, I pick the "other" > and validation declares the redirect as invalid (e.g. I get a redirect > from router, to wich I would not have sent the packet in question...) > > So, I assume I have to loosen the test, and accept redirects from any > router, which potentially might be valid for the destination (for > example, any of the default routers), even if it is not my "current > first-hop router for the destination"? > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 01:09:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K964V08931 for ipng-dist; Tue, 20 Feb 2001 01:06:07 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K92e208796 for ; Tue, 20 Feb 2001 01:02:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02252 for ; Tue, 20 Feb 2001 01:02:24 -0800 (PST) Received: from m018.com ([210.112.11.138]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11230 for ; Tue, 20 Feb 2001 02:02:22 -0700 (MST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 20 Feb 2001 17:55:58 +0900 Received: from patan.sun.com ([192.18.98.43]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 20 Feb 2001 04:47:54 +0900 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03722; Mon, 19 Feb 2001 11:52:39 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16275; Mon, 19 Feb 2001 11:52:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JJoVC05328 for ipng-dist; Mon, 19 Feb 2001 11:50:31 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JJoH205321 for ; Mon, 19 Feb 2001 11:50:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16016 for ; Mon, 19 Feb 2001 11:50:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02722 for ; Mon, 19 Feb 2001 11:50:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13183; Mon, 19 Feb 2001 14:50:14 -0500 (EST) Message-Id: <200102191950.OAA13183@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: Transmission of IPv6 Packets over IEEE 1394 Networks to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 19 Feb 2001 14:50:14 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider Transmission of IPv6 Packets over IEEE 1394 Networks as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 5, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-1394-01.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 01:18:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K9Bxs09332 for ipng-dist; Tue, 20 Feb 2001 01:11:59 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K9A6209202 for ; Tue, 20 Feb 2001 01:10:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02773 for ; Tue, 20 Feb 2001 01:10:01 -0800 (PST) Received: from m018.com ([210.112.11.138]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA15337 for ; Tue, 20 Feb 2001 02:09:59 -0700 (MST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 20 Feb 2001 18:02:31 +0900 Received: from mercury.Sun.COM ([192.9.25.1]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 20 Feb 2001 10:33:23 +0900 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA08664; Mon, 19 Feb 2001 17:39:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24514; Mon, 19 Feb 2001 17:39:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K1aHY06631 for ipng-dist; Mon, 19 Feb 2001 17:36:17 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K1a8206624 for ; Mon, 19 Feb 2001 17:36:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19172 for ; Mon, 19 Feb 2001 17:36:08 -0800 (PST) Received: from mx02.melco.co.jp (mx01.melco.co.jp [192.218.140.41]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28789 for ; Mon, 19 Feb 2001 17:35:48 -0800 (PST) Received: by mx02.melco.co.jp (mx02) id KAA06590; Tue, 20 Feb 2001 10:35:43 +0900 (JST) Received: by mr02.melco.co.jp (mr02) id KAA29814; Tue, 20 Feb 2001 10:35:42 +0900 (JST) Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id KAA21390; Tue, 20 Feb 2001 10:35:41 +0900 (JST) Received: from ishitp570 by islgw.isl.melco.co.jp (8.8.8/3.6W) id KAA17112; Tue, 20 Feb 2001 10:35:40 +0900 (JST) Message-ID: <00ec01c09add$8d7c08e0$1a084a0a@ishitp570> From: "Koichi Ishibashi" To: "Hesham Soliman \(ERA\)" , , References: <034BEFD03799D411A59F00508BDF75465B6A61@esealnt448.al.sw.ericsson.se> Subject: Re: New idea for Router Sol/Adv and Mobility Date: Tue, 20 Feb 2001 10:36:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Hesham Soliman (ERA)" To: ; Sent: Sunday, February 18, 2001 9:21 PM Subject: RE: New idea for Router Sol/Adv and Mobility > Hello Ken, > > Erik suggested in his email definnig a new type for > the RS. The use of this new type should be enough > to show the HA that the request is coming from a MN > and that it is not a normal RS. > > I think doing that removes the need for the Home address > option and the additional complication that comes > with that (what should be in the option ...etc). > Also it would be a much cleaner approach IMO. > > Cheers, > Hesham > > > > -----Original Message----- > > From: Powell, Ken [SMTP:Ken.Powell@compaq.com] > > Sent: Saturday, 17 February 2001 9:55 > > To: 'T.J. Kniveton'; mobile-ip@marvin.corpeast.baynetworks.com; ipng@sunroof.eng.sun.com > > Subject: RE: New idea for Router Sol/Adv and Mobility > > > > Hesham's response helped greatly to resolve the > > security questions I had. > > > > At first, I thought the RS/RA exchange between the > > mobile node's COA and the home agent during > > initialization shouldn't use the home address or > > routing header options. That was until I discussed > > this with Vlad Yasevich today. > > > > We don't have any reasons for the initial > > router advertisement sent back to the mobile > > node's COA to have a routing header, but > > there is a reason for keeping the home > > address option on the router solicitation. > > > > Vlad pointed out that the Home Agent needs a > > way to tell that a router solicitation was sent by > > a mobile node. This is important because the home > > agent needs to send the aggregate prefix list as > > defined in section 9.7.1 instead of just the home > > agent's own locally defined prefix list. Without some > > flag, a home agent would be forced to assume that any > > IPsec protected router solicitation with a global > > source address came from a mobile node. Reliance on > > this assumption could cause problems with some future > > application that may also need RS/RA exchanges with > > non-linklocal addresses. Attaching the home address > > option to the router solicit solves this problem. > > > > Assuming that the home address option is needed, > > what address should it contain before the mobile > > node generates its home address? On first > > glance, the unspecified address seems best. It is > > a clear signal that the mobile node has no home > > address and that there is no binding. The other > > choice is to repeat the care-of address as you > > suggested. This might be easier to implement by > > requiring less special logic in the protocol stack > > for IPsec and home address option handling. > > I haven't thought through all the details. > > Both these options are going to require some > > special handling. > > > > I suppose another option would be to add a > > "request aggregate prefix list" flag bit to > > the router solicitation message. Such a flag > > bit would be easier to implement in that > > it would only impact the part of the stack > > that deals with router solicitation/advertisement > > processing. > > > > What do others prefer? > > > > On to another concern... > > > > I've been trying to sort out how this proposal impacts > > section 9.7.2 which specifies the rules for when the > > home agent sends Router Advertisements to the mobile > > node. These rules require the home agent keep track > > of which router advertisement information was sent > > to each mobile node. It seems natural that this > > state information be stored with the binding cache > > entry. I couldn't see how the home agent could > > track the information from the RS/RA exchange before > > a binding is created. > > > > I think the home agent should treat RS/RA exchanges > > between HA and Mobile node's COA as a completely > > separate situation and make no attempt to associate > > them with a particular mobile node or binding. > > > > When a mobile node sends an IPsec protected RS to a > > home agent from its COA, the home agent should reply > > with an ipsec protected RA to the mobile node's COA and > > no routing header. The home agent may rate limit the RA's > > sent to a particular COA. This should be done independently > > from the procedure to send RA's to the mobile node's home> > > address. > > > > To summarize, I think the current draft should: > > > > 1) Use home address option when the mobile node > > sends router solicitations from its home address > > to the home agent instead of fully encapsulating > > the router solicitation. > > > > 2) Protect router solicitations from the mobile > > node with IPsec, the same as router advertisements > > are protected. > > > > 3) Add a new mechanism for an IPsec protected > > RS/RA exchange between the mobile node's COA > > and home agent for possible use during > > initialization. This gets rid of any need > > for a temporary home address as mentioned > > in appendix A. I'm still undecided how > > to handle the home address option here. > > > > I'm going to be off-line next week and won't be > > able to respond to any questions till I get back. > > > > Ken > > > > > -----Original Message----- > > > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > > > Sent: Friday, February 16, 2001 1:41 AM > > > To: Powell, Ken; 'mobile-ip@standards.nortelnetworks.com'; > > > ipng@sunroof.eng.sun.com > > > Subject: Re: New idea for Router Sol/Adv and Mobility > > > > > > > > > on 2/15/01 1:46 PM, Powell, Ken wrote: > > > > > > > Under this proposal, the Mobile Node will have to re-establish the > > > > Security Association between the Home Agent and its Care-Of Address > > > > every time it moves to support IPsec requirements for Router > > > > Advertisements. How does this fit in with the process of > > > > forming the new care-of address and updating bindings? Will > > > > this cause additional hand-off delays? > > > > > > > > > > Good question. Where this question leads is, how can the HA > > > trust an MN when > > > the MN does not have a trustable identity based on a Home network IP > > > address? Does it make sense to base security associations on > > > IP addresses > > > when the addresses themselves are ephemeral and can't be associated to > > > Identity without the involvement of an outside entity? > > > > > > Clearly this is already a hot topic. Rather than trying to > > > solve it here, > > > perhaps I can offer a compromise which allows for the > > > possibility of future > > > elaboration. > > > > > > Here's the recipe: start with Draft 13. Now remove > > > encapsulation from RSs > > > (this is unnecessary and inconsistent). Add the rules for TTL<255 and > > > mobility processing, as stated in my previous message. Stir > > > in addressing as > > > follows: > > > > > > 1. The RS is sent with a HAddr option. The HAddr contains the > > > MN's Home > > > Address (naturally), EXCEPT if the MN has not configured one, > > > in which case > > > it MAY insert the COA instead. > > > > > > 2. The HA sends an RA using a routing header, as usual. The > > > RHdr contains > > > whatever was in the HAddr option - namely, the Home Address, > > > EXCEPT if the > > > COA was in the RS's HAddr option, it goes in the routing > > > header (we could > > > just leave the routing header off, alternatively). This RA is still > > > protected by IPsec as in the draft. > > > > > > This is the best of both worlds: > > > - In the steady-state case, where a MN has a HAddr, and it > > > needs updated > > > prefix info, it just sends an RS and the RA is protected with > > > the existing > > > security association > > > > > > - If the MN does not yet have a HAddr, it uses the COA, > > > *assuming you have a > > > way to generate a security association between the HA and the > > > COA*. If you > > > can not do this, there is no way to get an IPSEC-protected > > > RA. This is part > > > of the "bootstrap problem." > > > As soon as the MN gets a home address, it can use the HAddr > > > in all future > > > RSs, so this does not suffer from the problem Ken brought up, > > > of having to > > > update the HA/COA sec.assoc. every time you handover. Using > > > the COA is a > > > one-time thing while bootstrapping. > > > > > > This leaves room open for developing a dynamic security > > > architecture where > > > trust is based on something other than strictly the IP address. For> > > > instance, an NAI, signed key, (whatever) might be used instead. > > > > > > > > > > How does the home agent determine which mobile node sent the > > > > Router Solicitation? Can the Care-of address on a mobile node > > > > be relied on for this? > > > > > > I contend it doesn't matter. You just need to know that it > > > was sent from a > > > mobile node. The information you include in a solicited RA > > > consists of the > > > prefixes from your own AdvPrefixList, and the prefixes advertised (and > > > therefore served) by all other HAs on the link. No other > > > prefixes will be > > > Mobile-IP-routable, and so they don't matter while the MN is > > > off-link. The > > > MN should be able to configure any/all of these prefixes and > > > be served by > > > any of these HAs, so you must send them all to any node who solicits. > > > > > > > > > >[Mattias Pettersson wrote:] > > > >> > > > >> Will we open up a security hole or possible denial-of service > > > >> attack by let's say flood a HA with RSes (that don't require > > > >> authentication), now that we can send them over multiple hops? > > > >> > > > > > > > > Yes, this does look like a problem, but I think its just as > > > > serious in draft 13. Any node could repeatedly send router > > > > solicits with the mobile node's care-of address (and home > > > > address). The home agent would send a complete Router > > > > Advertisement to the mobile node for each Router Solicit, > > > > possibly eating up expensive wireless bandwidth. Perhaps > > > > the Router Solicit should be IPsec protected? > > > > > > The problem isn't bandwidth here. The security issue is that > > > anyone can see > > > the prefix information about that potentially private network. You are > > > thereby exposing the fact that a certain IP address is a > > > router, that it's > > > also a home agent, and what some or all of the prefixes on > > > that link are. > > > And you're exposing it to anyone along the path to the MN. > > > > > > Regarding the bandwidth issue, who cares that the HA will > > > send RAs to the > > > mobile? If you want to use the MN's bandwidth, nothing stops > > > you from just > > > sending it packets yourself! Anyway, the HA could protect > > > against this by > > > limiting the rate at which it sends RAs. > > > > > > > > Ken > > > > > > > > > > > > > So I am interested in your comments on my compromise proposal. > > > -- > > > TJ Kniveton > > > NOKIA Research > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 01:19:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K9FHg09589 for ipng-dist; Tue, 20 Feb 2001 01:15:22 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K9CS209399 for ; Tue, 20 Feb 2001 01:12:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22361 for ; Tue, 20 Feb 2001 01:12:26 -0800 (PST) Received: from m018.com ([210.112.11.138]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13868 for ; Tue, 20 Feb 2001 01:12:25 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 20 Feb 2001 18:05:58 +0900 Received: from patan.sun.com ([192.18.98.43]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 20 Feb 2001 11:35:15 +0900 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20277; Mon, 19 Feb 2001 18:40:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05327; Mon, 19 Feb 2001 18:40:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K2biD06852 for ipng-dist; Mon, 19 Feb 2001 18:37:44 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K2bZ206845 for ; Mon, 19 Feb 2001 18:37:35 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01604 for ; Mon, 19 Feb 2001 18:37:34 -0800 (PST) Received: from perilla.nov.tahi.org (oxalis.nezu.wide.ad.jp [203.178.142.208]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18901 for ; Mon, 19 Feb 2001 18:37:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by perilla.nov.tahi.org (8.9.3/8.9.3) with ESMTP id LAA46144; Tue, 20 Feb 2001 11:37:26 +0900 (JST) (envelope-from nov@tahi.org) To: msa@burp.tkv.asdf.org Cc: ipng@sunroof.eng.sun.com Subject: Re: Redirect ICMP and TAHI test? From: OKABE Nobuo In-Reply-To: <200102191238.OAA20125@burp.tkv.asdf.org> References: <200102191238.OAA20125@burp.tkv.asdf.org> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010220113725N.nov@tahi.org> Date: Tue, 20 Feb 2001 11:37:25 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Markku, Thank you for your feedback. I need your help to start examining the test that you pointed. Could you give me a name of the test instead of number? ex. ncStateByRedirect4Reachable.seq Test number is frequently changed. I would appreciate your help. From: Markku Savela Subject: Redirect ICMP and TAHI test? Date: Mon, 19 Feb 2001 14:38:06 +0200 > In RFC-2461 "8.1 Validation of Redirect Messages" there is > > "- The IP source address of the Redirect is the same as the current > first-hop router for the specified ICMP Destination Address." > > In TAHI Neighbor Discovery test 62, it introduces two routers, then > sends a redirect from "one" of them, and expects the redirect to have > an effect... > > ...and in my code it doesn't, because I currently coded the validation > literally in respect to the above entry. I take the destination > address and check from the routing table which router would actually > be getting this destination. And, as it happens, I pick the "other" > and validation declares the redirect as invalid (e.g. I get a redirect > from router, to wich I would not have sent the packet in question...) > > So, I assume I have to loosen the test, and accept redirects from any > router, which potentially might be valid for the destination (for > example, any of the default routers), even if it is not my "current > first-hop router for the destination"? --- nobuo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 01:19:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K9FRn09598 for ipng-dist; Tue, 20 Feb 2001 01:15:33 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K9Cs209441 for ; Tue, 20 Feb 2001 01:12:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA09745 for ; Tue, 20 Feb 2001 01:12:53 -0800 (PST) Received: from m018.com ([210.112.11.138]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16838 for ; Tue, 20 Feb 2001 02:12:51 -0700 (MST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 20 Feb 2001 18:06:17 +0900 Received: from patan.sun.com ([192.18.98.43]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 20 Feb 2001 12:16:17 +0900 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02880; Mon, 19 Feb 2001 19:21:39 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA06778; Mon, 19 Feb 2001 19:21:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K3HQv07015 for ipng-dist; Mon, 19 Feb 2001 19:17:26 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K3HG207008 for ; Mon, 19 Feb 2001 19:17:16 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02918 for ; Mon, 19 Feb 2001 19:17:16 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA08505 for ; Mon, 19 Feb 2001 19:17:16 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 19 Feb 2001 19:17:36 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 19:16:43 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 19 Feb 2001 19:16:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Wade through the archives (was Re: another renumbering question) Date: Mon, 19 Feb 2001 19:16:42 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wade through the archives (was Re: another renumbering question) Thread-Index: AcCaxb/9/xF2iXSETma1F+l5vhIUtAADaxlA From: "Christian Huitema" To: "Paul Francis" , X-OriginalArrivalTime: 20 Feb 2001 03:16:43.0053 (UTC) FILETIME=[8C7035D0:01C09AEB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1K3HH207009 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The discussions always ended up on the same kind of conclusion: in theory it is a fine idea, but we would have to change existing implementation, and besides it is not easy to allocate unique numbers. There are basically four ways to allocate random numbers, and none of them is particularly attractive: 1) Picking numbers at random is easy, but you need a good random generator, and besides you hit the birthday paradox with 2^^19 entries, i.e. less than a million. There are way more than 1 million potential sites. 2) Deriving numbers from other pre-established registries is tempting, but there are not very many suitable pre-existing registries. IEEE-802 numbers are too large too fit; IPv4 addresses have the right size but not the right stability. 3) Starting a new registry looks simple on paper, but the practical problem are not so small -- for example, decide who will be king; find the right balance between automation and reliability; etc. 4) Combining random allocation with duplicate detection would go past the birthday paradox, but is almost impossible to conduct at the scale of the Internet... Now, if you can change that... -- Christian Huitema > -----Original Message----- > From: Paul Francis [mailto:paul@francis.com] > Sent: Monday, February 19, 2001 2:36 PM > To: ipng@sunroof.eng.sun.com > Subject: Wade through the archives (was Re: another > renumbering question) > > > > I took Steve up on his suggestion of looking through the > archives on this topic. > > With some effort I found three threads, all initiated by > Christian, in May '97, Dec '97, and Nov '99. I saved the > relevent messages...you can find them at > http://www.aciri.org/francis/IPv6> _site_id_threads.txt if you > are so inclined. This is > probably not exhaustive, so if anyone can point me to other > threads that would be helpful. > > I didn't see any major ideas in the previous threads that > weren't in the latest thread. > > A problem I found when looking over the threads is that a > complete picture of what a site ID would be and how it would > work was never generated, with the end result that different > people were talking about different things and to some extent > talking past each other. > > Having read the arguments, I still believe that there is > something to be said for the site-ID notion. The site-ID > would be for sites that want to have their own number space > for internal communications, with reasonable assurance that > nobody else is using the same space. > > The site-ID would not supplant the use of site-locals by > other sites who wanted to use them. Site-locals would remain > as defined. > > A site-ID would also not by itself identify what is and is > not in a given "site". In other words, one couldn't take two > addresses with site-IDs and, in the absense of any other > information (DNS entries or routing tables) say definitively > whether they could or could not reach each other using the > site-ID addresses. > > I'm inclined to write a draft specifying this so that we can > have a focused and consistent (and dare I say difinitive?) > discussion about it. Is there anyone out there who in > principle likes the idea of site-IDs and would care to work > with me on this? > > Thanks, > > PF > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 01:17:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K99Hn09118 for ipng-dist; Tue, 20 Feb 2001 01:09:17 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K94k208929 for ; Tue, 20 Feb 2001 01:06:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02450 for ; Tue, 20 Feb 2001 01:04:38 -0800 (PST) Received: from m018.com ([210.112.11.138]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11701 for ; Tue, 20 Feb 2001 01:04:37 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 20 Feb 2001 17:57:49 +0900 Received: from mercury.Sun.COM ([192.9.25.1]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 20 Feb 2001 04:32:34 +0900 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15790; Mon, 19 Feb 2001 11:37:41 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17023; Mon, 19 Feb 2001 11:37:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JJZlF05267 for ipng-dist; Mon, 19 Feb 2001 11:35:47 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JJZb205260 for ; Mon, 19 Feb 2001 11:35:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10550 for ; Mon, 19 Feb 2001 11:35:37 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA05215 for ; Mon, 19 Feb 2001 11:35:37 -0800 (PST) Received: from 157.54.1.52 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 11:07:41 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 19 Feb 2001 11:08:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Redirect ICMP and TAHI test? Date: Mon, 19 Feb 2001 11:08:57 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA802256106@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Redirect ICMP and TAHI test? Thread-Index: AcCalCKfaR+16QOORd+pOXLWYSNA9QAEz+aw From: "Richard Draves" To: "Erik Nordmark" Cc: "Markku Savela" , X-OriginalArrivalTime: 19 Feb 2001 19:08:58.0242 (UTC) FILETIME=[69406E20:01C09AA7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1JJZc205261 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > You're supposed to accept Redirects even if there is no Destination > > Cache entry... > > Where does it say so? In RFC 2461: 8.3. Host Specification A host receiving a valid redirect SHOULD update its Destination Cache accordingly so that subsequent traffic goes to the specified target. If no Destination Cache entry exists for the destination, an implementation SHOULD create such an entry. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 01:31:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K992o09112 for ipng-dist; Tue, 20 Feb 2001 01:09:02 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K91n208731 for ; Tue, 20 Feb 2001 01:02:03 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02167 for ; Tue, 20 Feb 2001 01:01:48 -0800 (PST) Received: from m018.com ([210.112.11.138]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10261 for ; Tue, 20 Feb 2001 01:01:47 -0800 (PST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 20 Feb 2001 17:55:15 +0900 Received: from patan.sun.com ([192.18.98.43]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 20 Feb 2001 01:46:02 +0900 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18866; Mon, 19 Feb 2001 08:52:22 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29007; Mon, 19 Feb 2001 08:52:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JGmd504629 for ipng-dist; Mon, 19 Feb 2001 08:48:39 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JGmK204614 for ; Mon, 19 Feb 2001 08:48:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28314 for ; Mon, 19 Feb 2001 08:48:20 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA16885 for ; Mon, 19 Feb 2001 08:48:20 -0800 (PST) Received: from 157.54.1.52 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 08:24:13 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 19 Feb 2001 08:25:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Redirect ICMP and TAHI test? Date: Mon, 19 Feb 2001 08:25:44 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8022560B6@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Redirect ICMP and TAHI test? Thread-Index: AcCagVC6Na1bNhrgR1qlM8VNm8mcuQADzcFA From: "Richard Draves" To: "Erik Nordmark" , "Markku Savela" Cc: X-OriginalArrivalTime: 19 Feb 2001 16:25:45.0054 (UTC) FILETIME=[9C0E87E0:01C09A90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1JGmM204617 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The idea behind the validity test is that a node should only accept > a redirect from router R1 if the node very recently sent a packet > to R1 that was for the destination. > > In your implementation do you have something similar to a > "destination cache" > which retains the next hop where you last sent packet? > Or do you always do a lookup and find the default route(s)? You're supposed to accept Redirects even if there is no Destination Cache entry... Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 01:52:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1K99GA09115 for ipng-dist; Tue, 20 Feb 2001 01:09:16 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1K978209031 for ; Tue, 20 Feb 2001 01:07:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21950 for ; Tue, 20 Feb 2001 01:07:06 -0800 (PST) Received: from m018.com ([210.112.11.138]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA13807 for ; Tue, 20 Feb 2001 02:07:05 -0700 (MST) Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Tue, 20 Feb 2001 18:00:41 +0900 Received: from mercury.Sun.COM ([192.9.25.1]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 20 Feb 2001 07:40:06 +0900 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14965; Mon, 19 Feb 2001 14:45:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13507; Mon, 19 Feb 2001 14:45:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1JMhNO05984 for ipng-dist; Mon, 19 Feb 2001 14:43:23 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JMhC205973 for ; Mon, 19 Feb 2001 14:43:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13320 for ; Mon, 19 Feb 2001 14:43:14 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA03277 for ; Mon, 19 Feb 2001 14:43:13 -0800 (PST) Received: (cpmta 71 invoked from network); 19 Feb 2001 14:36:32 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.64) with SMTP; 19 Feb 2001 14:36:32 -0800 X-Sent: 19 Feb 2001 22:36:32 GMT Message-ID: <01bd01c09ac4$6023cb80$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: References: <200102191427.IAA12899@gungnir.fnal.gov> Subject: Wade through the archives (was Re: another renumbering question) Date: Mon, 19 Feb 2001 14:36:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I took Steve up on his suggestion of looking through the archives on this topic. With some effort I found three threads, all initiated by Christian, in May '97, Dec '97, and Nov '99. I saved the relevent messages...you can find them at http://www.aciri.org/francis/IPv6_site_id_threads.txt if you are so inclined. This is probably not exhaustive, so if anyone can point me to other threads that would be helpful. I didn't see any major ideas in the previous threads that weren't in the latest thread. A problem I found when looking over the threads is that a complete picture of what a site ID would be and how it would work was never generated, with the end result that different people were talking about different things and to some extent talking past each other. Having read the arguments, I still believe that there is something to be said for the site-ID notion. The site-ID would be for sites that want to have their own number space for internal communications, with reasonable assurance that nobody else is using the same space. The site-ID would not supplant the use of site-locals by other sites who wanted to use them. Site-locals would remain as defined. A site-ID would also not by itself identify what is and is not in a given "site". In other words, one couldn't take two addresses with site-IDs and, in the absense of any other information (DNS entries or routing tables) say definitively whether they could or could not reach each other using the site-ID addresses. I'm inclined to write a draft specifying this so that we can have a focused and consistent (and dare I say difinitive?) discussion about it. Is there anyone out there who in principle likes the idea of site-IDs and would care to work with me on this? Thanks, PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 02:17:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KAG4v12604 for ipng-dist; Tue, 20 Feb 2001 02:16:04 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KAFi212589 for ; Tue, 20 Feb 2001 02:15:50 -0800 (PST) Received: from lillen (gbl-dhcp-212-208.France.Sun.COM [129.157.212.208]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f1KAFgL304354; Tue, 20 Feb 2001 02:15:42 -0800 (PST) Date: Tue, 20 Feb 2001 11:14:54 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Wade through the archives (was Re: another renumbering question) To: Paul Francis Cc: Christian Huitema , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <004101c09af4$14f879a0$8cc90518@smateo1.sfba.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But speaking of existing implementations, what would happen if an existing > router advertised to an existing host that one of the host's prefixes > contained a site ID (that is, a site-local with a non-zero 38-bit number). > Presumably the host would accept it? They should since the site-local prefix is fec0::0/10, but there is some risk that implemetors think that the site-local prefix is fec0::0/48 (since all those bits are mandated to be zero). Thus it would make sense to do a quick survey of existing implementations. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 07:05:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KF4Ao13605 for ipng-dist; Tue, 20 Feb 2001 07:04:10 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KF40213598 for ; Tue, 20 Feb 2001 07:04:00 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05600 for ; Tue, 20 Feb 2001 07:04:01 -0800 (PST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04344 for ; Tue, 20 Feb 2001 07:04:00 -0800 (PST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 20 Feb 2001 08:04:01 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 10JJ9KB5; Tue, 20 Feb 2001 08:04:00 -0500 Received: from nortelnetworks.com (deathvalley.corpeast.baynetworks.com [132.245.252.116]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM911; Tue, 20 Feb 2001 08:04:00 -0500 Message-ID: <3A926B10.D524A3E9@nortelnetworks.com> Date: Tue, 20 Feb 2001 08:03:12 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Francis CC: ipng Subject: Re: Wade through the archives (was Re: another renumbering question) References: <200102191427.IAA12899@gungnir.fnal.gov> <01bd01c09ac4$6023cb80$8cc90518@smateo1.sfba.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul, A couple of points in-lined... Paul Francis wrote: > > I took Steve up on his suggestion of looking through the archives on this > topic. > > With some effort I found three threads, all initiated by Christian, in May > '97, Dec '97, and Nov '99. I saved the relevent messages...you can find > them at http://www.aciri.org/francis/IPv6_site_id_threads.txt if you are so > inclined. This is probably not exhaustive, so if anyone can point me to > other threads that would be helpful. > > I didn't see any major ideas in the previous threads that weren't in the > latest thread. > > A problem I found when looking over the threads is that a complete picture > of what a site ID would be and how it would work was never generated, with > the end result that different people were talking about different things and > to some extent talking past each other. The definition of what a site ID would be was intentionally undefined. That is, a site ID was supposed to be implementation dependent. However, we found in developing the APIs and the InetAddress TC that we needed something a little more concrete. Now, the site ID is, in essence, a 32-bit integer. > > Having read the arguments, I still believe that there is something to be > said for the site-ID notion. The site-ID would be for sites that want to > have their own number space for internal communications, with reasonable > assurance that nobody else is using the same space. What exactly will be reasonable assurance? If your "site ID registry" allocates you a unique site ID, why would the site local address created with that site ID not be globally routable? > > The site-ID would not supplant the use of site-locals by other sites who > wanted to use them. Site-locals would remain as defined. > > A site-ID would also not by itself identify what is and is not in a given > "site". In other words, one couldn't take two addresses with site-IDs and, > in the absense of any other information (DNS entries or routing tables) say > definitively whether they could or could not reach each other using the > site-ID addresses. If a "site ID registry" is giving out the ID's, I would think it would be in their best interest to allocate unique numbers. If two site local addresses have the same ID in them, why would they not be in the same site, given the above assumption? > > I'm inclined to write a draft specifying this so that we can have a focused > and consistent (and dare I say difinitive?) discussion about it. Is there > anyone out there who in principle likes the idea of site-IDs and would care > to work with me on this? I used to think that having a unique ID in the site local addresses would be useful. However, I gave that up a few years ago after thinking about what it would take to come up with and manage that number space. If anything, I could see allowing an administrator to specify his/her own ID's. This would allow the NOC to map its site local addresses to some administratively controlled "space". Regards, Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 08:04:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KG3vv13813 for ipng-dist; Tue, 20 Feb 2001 08:03:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KG3m213806 for ; Tue, 20 Feb 2001 08:03:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09128 for ; Tue, 20 Feb 2001 08:03:48 -0800 (PST) Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA19724 for ; Tue, 20 Feb 2001 08:03:47 -0800 (PST) Received: (cpmta 12284 invoked from network); 20 Feb 2001 08:03:46 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.65) with SMTP; 20 Feb 2001 08:03:46 -0800 X-Sent: 20 Feb 2001 16:03:46 GMT Message-ID: <023a01c09b56$b1e15040$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Brian Haberman" Cc: "ipng" References: <200102191427.IAA12899@gungnir.fnal.gov> <01bd01c09ac4$6023cb80$8cc90518@smateo1.sfba.home.com> <3A926B10.D524A3E9@nortelnetworks.com> Subject: Re: Wade through the archives (was Re: another renumbering question) Date: Tue, 20 Feb 2001 08:03:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The definition of what a site ID would be was intentionally undefined. > That is, a site ID was supposed to be implementation dependent. > However, we found in developing the APIs and the InetAddress TC that > we needed something a little more concrete. Now, the site ID is, > in essence, a 32-bit integer. Heh! When I first read this last sentence, I thought "I didn't know it was that clearly defined", went off to RFC2373 to check it out, but once again found no concept of site ID. So I looked again at your paragraph and saw that you are talking about the API. I didn't realize that there was a notion of site ID in the API, so my apologies for using that term incorrectly. I picked it up from one of Deering's recent messages, not realizing its specific meaning. (Even having read through some of the archives, I didn't catch that the term site id refered to a number that crosses the API.) [..... time elapsed as I look at the API documents to check up on this ....] Well, I looket at the latest versions of RFCs 2553 and 2292, and I still don't see anything about a well-defined 32-bit site id. RFC2253 says: "The mapping of sin6_scope_id to an interface or set of interfaces is left to implementation and future specifications on the subject of site identifiers." and RFC2292, in a section labeled "Open issues" says: "What about site names and site ids? Need for interfaces to map? Requires that site-prefixes pass name - does name need to use DNS format to handle character sets?" So I remain more confused than ever. Could you please tell me where I can read about 32-bit site IDs, and after I've read up I'll try to address your comments. Thanks, PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 08:19:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KGIwD13900 for ipng-dist; Tue, 20 Feb 2001 08:18:58 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KGIl213893 for ; Tue, 20 Feb 2001 08:18:47 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26631 for ; Tue, 20 Feb 2001 08:18:32 -0800 (PST) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27552 for ; Tue, 20 Feb 2001 08:18:31 -0800 (PST) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.20 #3) id 14VFUh-00051Q-00 for ipng@sunroof.eng.sun.com; Tue, 20 Feb 2001 11:18:27 -0500 Date: Tue, 20 Feb 2001 11:18:27 -0500 (EST) From: Nathan Lutchansky To: ipng mailing list Subject: RE: Wade through the archives (was Re: another renumbering question) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk First, I can see a lot of advantages to having unique, non-routable site prefixes. One big advantage I can see is that VPNs can be created between arbitrary sites without worry of renumbering either site. If we can find a way to implement site IDs in a reasonable manner, it would be a big win for IPv6. On Mon, 19 Feb 2001, Christian Huitema wrote: > 4) Combining random allocation with duplicate detection would go past > the birthday paradox, but is almost impossible to conduct at the scale > of the Internet... Why not leverage the global DNS system to do this? DNS can be used to assign ownership and do duplicate detection, and can also solve the two-faced DNS problem. Here's how: Say company.foo. wants one of the 38-bit site-local IDs for their site. They randomly generate a number (or pick their favorite integer) and register it as a domain name with a specially-designated suffix. Let's say the suffix is -site-ipv6.net, and let's say they chose the nice random number 0x0012345678, so they would register the domain "x0012345678-site-ipv6.net". If somebody else was using that unique prefix, company.foo would find this out when they went to register it, and would be forced to choose a different number. This guarantees uniqueness. Company.foo can now stack the prefix fec0:1234:5678::/48 on all their subnets in addition to their provider-based addresses. Now all the hosts at the site know the site ID. This is how the site-local DNS problem is solved too. For every lookup that each host does, it first looks up the same name inside the site-local DNS zone. To resolve the host www.yahoo.com, a node would first look up www.yahoo.com.x0012345678-site-ipv6.net. to try and find a site-local address, but failing that, would look up www.yahoo.com. Presumably, there wouldn't be a site-local address for www.yahoo.com, but there would be one for internal-fileserver.company.foo. Essentially what this scheme does is sequester all of a site's site-local IP addresses into their own zone, which clients discover by looking at the prefixes on their link. By registering the zone in global DNS, uniqueness is preserved. Some observations: This wouldn't impact most home/SOHO/unmanaged nodes, because this doesn't affect behavior when no site-local prefix is present on the link. Every lookup would cause two DNS resolutions, but presumably this shouldn't be a big issue because the authoritative servers for the site-ID zones would be very close to the clients. This extra lookup is the *only* additional overhead for this scheme. The only changes required in protocol stacks would be the DNS lookup functions, getaddrinfo() and friends. Possibly a change would need to be made if the IPv6 layer didn't accept fec0:: addresses with non-zero reserved bits. *Any* domain names could be assigned site-local addresses at each site, not just ones in the local zones. This has nice implications for selective proxying systems and private links between sites. VPNs between arbitrary companies could easily be created. Each company could add routes for the other company's site-local addresses through the VPN. For example, company.foo would tunnel using some sort of strong encryption to partner.foo who has site prefix fec0:8765:4321::/48. Company.foo could add entries for partner.foo's site-local server IPs into partner.foo.x0012345678-site-ipv6.net, and partner.foo could add entries for company.foo's site-local server IPs into company.foo.x0087654321-site-ipv6.net. Nodes on both networks would use the VPN transparently with the other site's site-local addresses, and all connections between the companies would survive global renumbering of both sites. Nobody would go and grab a significant portion of the address space for the same reason that nobody grabs 10^6 domains. And speculating on site-IDs makes even less sense than speculating on domain names. Two-faced DNS is optional. If company.foo wanted to hide their site-local addresses, they would serve x0012345678-site-ipv6.net only to clients at their site. If they didn't care, they'd simply have their -site-ipv6.net as an additional zone on their DNS servers. The point is that nodes outside the site would *never* see the site-local addresses, because site-local addresses would only be stored in the -site-ipv6.net zones. If, heaven forbid, we should ever need more than 275 billion site IDs, we could allocate another prefix besides fec0::/10 for site-locals. This applies to any scheme that assignes unique site-IDs, however. The only possible unfortunate side effect that this may have is that, as Steve pointed out, some unscrupulous ISP may begin advertising site-local prefixes into the global routing tables. But shouldn't filters on default-free routers refuse to route to addresses in the fec0::/10 block? I think the remote possibility of unique site prefixes overloading the world's routing table is a risk worth taking, since such prefixes might very well give sites peace of mind that renumbering wouldn't interrupt local service on their network. This system is probably the most flexible and low-overhead of all those proposed in the last week, and requires relatively few changes in existing code. My apologies if this scheme has been proposed already, but I'm on a slow link and searching the archives is rather painful. -Nathan -- +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 08:38:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KGboT14004 for ipng-dist; Tue, 20 Feb 2001 08:37:50 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KGbc213997 for ; Tue, 20 Feb 2001 08:37:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29579 for ; Tue, 20 Feb 2001 08:37:33 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02057 for ; Tue, 20 Feb 2001 08:37:31 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id KAA21020; Tue, 20 Feb 2001 10:37:22 -0600 (CST) Message-Id: <200102201637.KAA21020@gungnir.fnal.gov> To: Christian Huitema Cc: Paul Francis , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Wade through the archives (was Re: another renumbering question) In-reply-to: Your message of Mon, 19 Feb 2001 19:16:42 PST. Date: Tue, 20 Feb 2001 10:37:22 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) Picking numbers at random is easy, but you need a good random > generator, and besides you hit the birthday paradox with 2^^19 entries, > i.e. less than a million. There are way more than 1 million potential > sites. You don't care about the existence of any pair of duplicates -- only about a duplication with a site you eventually expose your private address space to. If everyone picks an unbiased random site id, and you connect in that way to N sites, the chance of a duplication is only around N^2 / 2^19. If you reserved half the space for the number-tsar to allocate uniquely and half for random picks, the chance of hitting a duplication problem (including by connecting to someone with the same site id as your site and connecting to two which chose the same) is not more than about N^2 / 2^18 -- 0.1% if you connect 16 sites -- and far less if you and they are mostly from the unique-numbered camp. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 08:41:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KGeSu14022 for ipng-dist; Tue, 20 Feb 2001 08:40:28 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KGeI214015 for ; Tue, 20 Feb 2001 08:40:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01803 for ; Tue, 20 Feb 2001 08:40:19 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04890 for ; Tue, 20 Feb 2001 09:40:18 -0700 (MST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1KGfrw26760 for ; Tue, 20 Feb 2001 10:41:53 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 20 Feb 2001 10:40:17 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 20 Feb 2001 10:40:17 -0600 Message-ID: To: paul@francis.com, haberman@nortelnetworks.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Wade through the archives (was Re: another renumbering questi on) Date: Tue, 20 Feb 2001 10:40:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk paul, I am confused too. I always thought of it as 16bits????? also for the api that is an "identifier" not the site-id. Like le0 for interface. /jim > -----Original Message----- > From: ext Paul Francis [mailto:paul@francis.com] > Sent: Tuesday,February 20,2001 11:04 AM > To: Brian Haberman > Cc: ipng > Subject: Re: Wade through the archives (was Re: another renumbering > question) > > > > > > The definition of what a site ID would be was intentionally > undefined. > > That is, a site ID was supposed to be implementation dependent. > > However, we found in developing the APIs and the InetAddress TC that > > we needed something a little more concrete. Now, the site ID is, > > in essence, a 32-bit integer. > > Heh! When I first read this last sentence, I thought "I > didn't know it was > that clearly defined", went off to RFC2373 to check it out, > but once again > found no concept of site ID. So I looked again at your > paragraph and saw > that you are talking about the API. I didn't realize that there was a > notion of site ID in the API, so my apologies for using that term > incorrectly. I picked it up from one of Deering's recent > messages, not > realizing its specific meaning. (Even having read through some of the > archives, I didn't catch that the term site id refered to a > number that > crosses the API.) > > [..... time elapsed as I look at the API documents to check > up on this ....] > > Well, I looket at the latest versions of RFCs 2553 and 2292, > and I still > don't see anything about a well-defined 32-bit site id. > > RFC2253 says: > > "The mapping of sin6_scope_id to an interface or set of > interfaces is left > to implementation and future specifications on the subject of site > identifiers." > > and RFC2292, in a section labeled "Open issues" says: > > "What about site names and site ids? Need for interfaces to > map? Requires > that site-prefixes pass name - does name need to use DNS > format to handle > character sets?" > > > So I remain more confused than ever. Could you please tell > me where I can > read about 32-bit site IDs, and after I've read up I'll try > to address your > comments. > > Thanks, > > PF > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 09:03:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KH2YW14118 for ipng-dist; Tue, 20 Feb 2001 09:02:34 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KH2O214111 for ; Tue, 20 Feb 2001 09:02:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24233 for ; Tue, 20 Feb 2001 09:02:24 -0800 (PST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21039 for ; Tue, 20 Feb 2001 09:02:22 -0800 (PST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 20 Feb 2001 11:52:51 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FCZGRTXL; Tue, 20 Feb 2001 11:52:50 -0500 Received: from nortelnetworks.com (deathvalley.corpeast.baynetworks.com [132.245.252.116]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DXCAM931; Tue, 20 Feb 2001 11:52:50 -0500 Message-ID: <3A92A0B2.8A71DF95@nortelnetworks.com> Date: Tue, 20 Feb 2001 11:52:02 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim.Bound@nokia.com, paul@francis.com CC: ipng@sunroof.eng.sun.com Subject: Re: Wade through the archives (was Re: another renumbering questi on) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I based my comments more on the definition of the InetAddress TC found in RFC 2851. The InetAddressIPv6 definition explicitly defines the scope identifier as a 4 byte value. My comments about the API came from the discussions we had in creating RFC 2851. Regards, Brian Jim.Bound@nokia.com wrote: > > paul, > > I am confused too. I always thought of it as 16bits????? > also for the api that is an "identifier" not the site-id. Like le0 for > interface. > > /jim > > > -----Original Message----- > > From: ext Paul Francis [mailto:paul@francis.com] > > Sent: Tuesday,February 20,2001 11:04 AM > > To: Brian Haberman > > Cc: ipng > > Subject: Re: Wade through the archives (was Re: another renumbering > > question) > > > > > > > > > > The definition of what a site ID would be was intentionally > > undefined. > > > That is, a site ID was supposed to be implementation dependent. > > > However, we found in developing the APIs and the InetAddress TC that > > > we needed something a little more concrete. Now, the site ID is, > > > in essence, a 32-bit integer. > > > > Heh! When I first read this last sentence, I thought "I > > didn't know it was > > that clearly defined", went off to RFC2373 to check it out, > > but once again > > found no concept of site ID. So I looked again at your > > paragraph and saw > > that you are talking about the API. I didn't realize that there was a > > notion of site ID in the API, so my apologies for using that term > > incorrectly. I picked it up from one of Deering's recent > > messages, not > > realizing its specific meaning. (Even having read through some of the > > archives, I didn't catch that the term site id refered to a > > number that > > crosses the API.) > > > > [..... time elapsed as I look at the API documents to check > > up on this ....] > > > > Well, I looket at the latest versions of RFCs 2553 and 2292, > > and I still > > don't see anything about a well-defined 32-bit site id. > > > > RFC2253 says: > > > > "The mapping of sin6_scope_id to an interface or set of > > interfaces is left > > to implementation and future specifications on the subject of site > > identifiers." > > > > and RFC2292, in a section labeled "Open issues" says: > > > > "What about site names and site ids? Need for interfaces to > > map? Requires > > that site-prefixes pass name - does name need to use DNS > > format to handle > > character sets?" > > > > > > So I remain more confused than ever. Could you please tell > > me where I can > > read about 32-bit site IDs, and after I've read up I'll try > > to address your > > comments. > > > > Thanks, > > > > PF > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 11:17:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KJGMw14636 for ipng-dist; Tue, 20 Feb 2001 11:16:22 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KJGC214628 for ; Tue, 20 Feb 2001 11:16:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02857 for ; Tue, 20 Feb 2001 11:16:12 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09022 for ; Tue, 20 Feb 2001 11:16:10 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1KJG7g20897 for ; Tue, 20 Feb 2001 13:16:08 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 20 Feb 2001 13:16:09 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 20 Feb 2001 13:16:08 -0600 Message-ID: To: haberman@nortelnetworks.com, Jim.Bound@nokia.com, paul@francis.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Wade through the archives (was Re: another renumbering questi on) Date: Tue, 20 Feb 2001 13:16:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ok now I see. Yes bytes 17-20 are the identifier and as sin6_scope_id its 32bits. but my point is that only 16bits of any ipv6 address can differentiate a site local address without duplication. which is a lot of sitelocal addresses. /jim > -----Original Message----- > From: ext Brian Haberman [mailto:haberman@nortelnetworks.com] > Sent: Tuesday,February 20,2001 11:52 AM > To: Jim.Bound@nokia.com; paul@francis.com > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Wade through the archives (was Re: another renumbering > questi on) > > > I based my comments more on the definition of the InetAddress TC found > in RFC 2851. The InetAddressIPv6 definition explicitly defines the > scope identifier as a 4 byte value. My comments about the API came > from the discussions we had in creating RFC 2851. > > Regards, > Brian > > Jim.Bound@nokia.com wrote: > > > > paul, > > > > I am confused too. I always thought of it as 16bits????? > > also for the api that is an "identifier" not the site-id. > Like le0 for > > interface. > > > > /jim > > > > > -----Original Message----- > > > From: ext Paul Francis [mailto:paul@francis.com] > > > Sent: Tuesday,February 20,2001 11:04 AM > > > To: Brian Haberman > > > Cc: ipng > > > Subject: Re: Wade through the archives (was Re: another > renumbering > > > question) > > > > > > > > > > > > > > The definition of what a site ID would be was intentionally > > > undefined. > > > > That is, a site ID was supposed to be implementation dependent. > > > > However, we found in developing the APIs and the > InetAddress TC that > > > > we needed something a little more concrete. Now, the > site ID is, > > > > in essence, a 32-bit integer. > > > > > > Heh! When I first read this last sentence, I thought "I > > > didn't know it was > > > that clearly defined", went off to RFC2373 to check it out, > > > but once again > > > found no concept of site ID. So I looked again at your > > > paragraph and saw > > > that you are talking about the API. I didn't realize > that there was a > > > notion of site ID in the API, so my apologies for using that term > > > incorrectly. I picked it up from one of Deering's recent > > > messages, not > > > realizing its specific meaning. (Even having read > through some of the > > > archives, I didn't catch that the term site id refered to a > > > number that > > > crosses the API.) > > > > > > [..... time elapsed as I look at the API documents to check > > > up on this ....] > > > > > > Well, I looket at the latest versions of RFCs 2553 and 2292, > > > and I still > > > don't see anything about a well-defined 32-bit site id. > > > > > > RFC2253 says: > > > > > > "The mapping of sin6_scope_id to an interface or set of > > > interfaces is left > > > to implementation and future specifications on the subject of site > > > identifiers." > > > > > > and RFC2292, in a section labeled "Open issues" says: > > > > > > "What about site names and site ids? Need for interfaces to > > > map? Requires > > > that site-prefixes pass name - does name need to use DNS > > > format to handle > > > character sets?" > > > > > > > > > So I remain more confused than ever. Could you please tell > > > me where I can > > > read about 32-bit site IDs, and after I've read up I'll try > > > to address your > > > comments. > > > > > > Thanks, > > > > > > PF > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: > http://playground.sun.com/ipng > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 12:28:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KKRvV14968 for ipng-dist; Tue, 20 Feb 2001 12:27:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KKRm214961 for ; Tue, 20 Feb 2001 12:27:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22592 for ; Tue, 20 Feb 2001 12:27:47 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14953 for ; Tue, 20 Feb 2001 13:27:46 -0700 (MST) Received: from [171.70.83.15] (dhcp-1sjc13-2-83-15.cisco.com [171.70.83.15]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA02122; Tue, 20 Feb 2001 12:05:32 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <023a01c09b56$b1e15040$8cc90518@smateo1.sfba.home.com> References: <200102191427.IAA12899@gungnir.fnal.gov> <01bd01c09ac4$6023cb80$8cc90518@smateo1.sfba.home.com> <3A926B10.D524A3E9@nortelnetworks.com> <023a01c09b56$b1e15040$8cc90518@smateo1.sfba.home.com> Date: Tue, 20 Feb 2001 12:05:37 -0800 To: "Paul Francis" From: Steve Deering Subject: Re: Wade through the archives (was Re: another renumbering question) Cc: "Brian Haberman" , "ipng" Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:03 AM -0800 2/20/01, Paul Francis wrote: >Heh! When I first read this last sentence, I thought "I didn't know it was >that clearly defined", went off to RFC2373 to check it out, but once again >found no concept of site ID. So I looked again at your paragraph and saw >that you are talking about the API. I didn't realize that there was a >notion of site ID in the API, so my apologies for using that term >incorrectly. I picked it up from one of Deering's recent messages, not >realizing its specific meaning. My fault. In my email, I used the term site ID to refer to what you were proposing, i.e., a value to stick into site-local addresses between the 10-bit format prefix and the SLA field. I had overlooked the fact that we have also used the term site ID for the local identifier that a multi-sited node uses to distinguish between the different sites to which it is attached (an identifier that is never sent outside a node; a particular case of a scope zone identifier). Brian was referring to the latter. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 12:40:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KKd1V15026 for ipng-dist; Tue, 20 Feb 2001 12:39:01 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KKcL215019 for ; Tue, 20 Feb 2001 12:38:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04648 for ; Tue, 20 Feb 2001 12:38:20 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21888 for ; Tue, 20 Feb 2001 13:37:57 -0700 (MST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id OAA22471; Tue, 20 Feb 2001 14:37:48 -0600 (CST) Message-Id: <200102202037.OAA22471@gungnir.fnal.gov> To: Steve Deering Cc: ipng From: "Matt Crawford" Subject: Re: Wade through the archives (was Re: another renumbering question) In-reply-to: Your message of Tue, 20 Feb 2001 12:05:37 PST. Date: Tue, 20 Feb 2001 14:37:48 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I had overlooked the fact that we have also used the term site ID > for ... a particular case of a scope zone identifier If we're going to worry about overloaded terminology, let's back up and worry about "scope". :-/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 12:42:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KKfkF15044 for ipng-dist; Tue, 20 Feb 2001 12:41:46 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KKfa215037 for ; Tue, 20 Feb 2001 12:41:36 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26351 for ; Tue, 20 Feb 2001 12:41:20 -0800 (PST) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06061 for ; Tue, 20 Feb 2001 12:41:19 -0800 (PST) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id PAA05696; Tue, 20 Feb 2001 15:41:17 -0500 (EST) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id PAA28600; Tue, 20 Feb 2001 15:41:17 -0500 (EST) Date: Tue, 20 Feb 2001 15:41:17 -0500 (EST) Message-Id: <200102202041.PAA28600@endor.deas.harvard.edu> To: ipng@sunroof.eng.sun.com, lutchann@litech.org Subject: RE: Wade through the archives (was Re: another renumbering question) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nathan Lutchansky wrote: |First, I can see a lot of advantages to having unique, non-routable site |prefixes. One big advantage I can see is that VPNs can be created between |arbitrary sites without worry of renumbering either site. If we can find |a way to implement site IDs in a reasonable manner, it would be a big win |for IPv6. [...] |Why not leverage the global DNS system to do this? DNS can be used to |assign ownership and do duplicate detection, and can also solve the |two-faced DNS problem. Here's how: [...] |VPNs between arbitrary companies could easily be created. [...] |The only possible unfortunate side effect that this may have is that, as |Steve pointed out, some unscrupulous ISP may begin advertising site-local |prefixes into the global routing tables. Or, turning this into a positive, when the (supposed) routing problem is solved and large routing tables can be accommodated, such advertising could be allowed. This would make for a smooth transition away from non-portable address space at some later time. |This system is probably the most flexible and low-overhead of all those |proposed in the last week, and requires relatively few changes in existing |code. My apologies if this scheme has been proposed already, but I'm on a |slow link and searching the archives is rather painful. -Nathan I don't know if your specific scheme has been proposed but, with a little tweaking to support automatic VPNs, it becomes essentially equivalent to my proposal for identity addresses (addresses that you can actually own without depending on the ISP not to pull the rug out from under you). I think your proposal exposes a bit more of the implementation to the application (or at least application-level resolver code), but I'd happily support it anyway. Either approach sidesteps the large-routing-table issues by pushing the initial lookups onto the DNS (a system which must be able to handle the load if IPv6 is to work at all) and distributing the rest of the routing decisions. I'm not sure that your approach would help with multi-homed sites as much as mine would, but that's probably a small price to pay for keeping the addresses in a form which could later simply be injected into the core routers when/if that becomes supportable. In the past there has been strong objection to allowing end users to own any kind of global (provider-independent) unique address (or address-like object) even if it is not directly routable. Perhaps now that 6to4 has let the genie out of the bottle it will be more palatable to allow users not fortunate enough to own any IPv4 space to play as well... Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 13:40:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KLdOI15350 for ipng-dist; Tue, 20 Feb 2001 13:39:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KLdF215343 for ; Tue, 20 Feb 2001 13:39:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10612 for ; Tue, 20 Feb 2001 13:39:14 -0800 (PST) Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA05801 for ; Tue, 20 Feb 2001 13:39:14 -0800 (PST) Received: (cpmta 8574 invoked from network); 20 Feb 2001 13:39:12 -0800 Received: from unknown (HELO dellchan) (208.135.49.132) by smtp.francis.com (209.228.32.72) with SMTP; 20 Feb 2001 13:39:12 -0800 X-Sent: 20 Feb 2001 21:39:12 GMT Message-ID: <02c601c09b85$8db9e5e0$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Christian Huitema" , "Matt Crawford" Cc: References: <200102201637.KAA21020@gungnir.fnal.gov> Subject: Re: Wade through the archives (was Re: another renumbering question) Date: Tue, 20 Feb 2001 13:39:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, Your point is good, but there must be something wrong with your math. Christian's point is (I assume) that with a number space of 2^36, when you select 2^19 random values you start running into a reasonable risk of two of those random values being the same. Your equation (N^2/2^18) doesn't seem to take into account the 2^36 number, and concludes with a probability (0.1%) that strikes me as very high. It would mean that of Christian's 1,000,000 sites, 1000 of them would have this problem, which is a lot of sites... Am I not getting something? PF ----- Original Message ----- From: "Matt Crawford" To: "Christian Huitema" Cc: "Paul Francis" ; Sent: Tuesday, February 20, 2001 8:37 AM Subject: Re: Wade through the archives (was Re: another renumbering question) > > 1) Picking numbers at random is easy, but you need a good random > > generator, and besides you hit the birthday paradox with 2^^19 entries, > > i.e. less than a million. There are way more than 1 million potential > > sites. > > You don't care about the existence of any pair of duplicates -- only > about a duplication with a site you eventually expose your private > address space to. If everyone picks an unbiased random site id, and > you connect in that way to N sites, the chance of a duplication is > only around N^2 / 2^19. > > If you reserved half the space for the number-tsar to allocate > uniquely and half for random picks, the chance of hitting a > duplication problem (including by connecting to someone with the same > site id as your site and connecting to two which chose the same) is > not more than about N^2 / 2^18 -- 0.1% if you connect 16 sites -- and > far less if you and they are mostly from the unique-numbered camp. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 14:06:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KM5O015460 for ipng-dist; Tue, 20 Feb 2001 14:05:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KM5C215453 for ; Tue, 20 Feb 2001 14:05:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17263 for ; Tue, 20 Feb 2001 14:05:12 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27254 for ; Tue, 20 Feb 2001 14:05:09 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id QAA23365; Tue, 20 Feb 2001 16:05:01 -0600 (CST) Message-Id: <200102202205.QAA23365@gungnir.fnal.gov> To: Paul Francis Cc: Christian Huitema , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Wade through the archives (was Re: another renumbering question) In-reply-to: Your message of Tue, 20 Feb 2001 13:39:06 PST. <02c601c09b85$8db9e5e0$8cc90518@smateo1.sfba.home.com> Date: Tue, 20 Feb 2001 16:05:01 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Your point is good, but there must be something wrong with your math. No, with my eyes. > Christian's point is (I assume) that with a number space of 2^36, when you > select 2^19 random values you start running into a reasonable risk of two of > those random values being the same. > > Your equation (N^2/2^18) doesn't seem to take into account the 2^36 number, It doesn't. My eye seized upon the wrong number. 2^19 should have been 2^38 throughout. And then making private-space connections to 16 sites gives you a <= one-in-500-million chance of collision, and connecting to 256 sites gives <= one-in-2-million. > Am I not getting something? Yes, presbyopia. Lucky you. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 14:10:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KM9pg15514 for ipng-dist; Tue, 20 Feb 2001 14:09:51 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KM9g215506 for ; Tue, 20 Feb 2001 14:09:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18533 for ; Tue, 20 Feb 2001 14:09:42 -0800 (PST) Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA27551 for ; Tue, 20 Feb 2001 14:09:41 -0800 (PST) Received: (cpmta 12962 invoked from network); 20 Feb 2001 14:09:39 -0800 Received: from unknown (HELO dellchan) (208.135.49.132) by smtp.francis.com (209.228.32.71) with SMTP; 20 Feb 2001 14:09:39 -0800 X-Sent: 20 Feb 2001 22:09:39 GMT Message-ID: <02ff01c09b89$cf065f20$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Brian Haberman" Cc: "ipng" References: <200102191427.IAA12899@gungnir.fnal.gov> <01bd01c09ac4$6023cb80$8cc90518@smateo1.sfba.home.com> <3A926B10.D524A3E9@nortelnetworks.com> Subject: Re: Wade through the archives (was Re: another renumbering question) Date: Tue, 20 Feb 2001 14:09:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > What exactly will be reasonable assurance? If your "site ID registry" > allocates you a unique site ID, why would the site local address > created with that site ID not be globally routable? > It would not be globally routable "by definition"... That is, the prefix would be recognized by routers as non-globally routable and they would refuse to route them. But as you are suggesting since they are in fact globally unique, ISPs could decide some day to route on them. But they'd pretty much all have to agree to do it. By the same token they could agree to route on larger globally aggregatable prefixes if they so desired, so the potentiallity of huge routing tables is there whether or not a site-id registry is created. > > If a "site ID registry" is giving out the ID's, I would think it would > be in their best interest to allocate unique numbers. If two site > local addresses have the same ID in them, why would they not be in > the same site, given the above assumption? Because they might be from a previous single site that split, for instance. Conversely, if two different sites merged you would have a situation where two machines with different "site ids" were in fact in the same site. So you'd need other mechanisms to determine when in fact two nodes were in the same site. In this regard, "site id" is the wrong term (and not the term I originally started with). A better term is "globally unique locally routable" address, or GULR address. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 14:12:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KMC2o15536 for ipng-dist; Tue, 20 Feb 2001 14:12:02 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KMBp215529 for ; Tue, 20 Feb 2001 14:11:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26973 for ; Tue, 20 Feb 2001 14:11:52 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA03438 for ; Tue, 20 Feb 2001 15:11:51 -0700 (MST) Received: from 157.54.1.52 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Feb 2001 14:05:41 -0800 (Pacific Standard Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 20 Feb 2001 14:05:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Redirect ICMP and TAHI test? Date: Tue, 20 Feb 2001 14:05:24 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8024EF2EA@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Redirect ICMP and TAHI test? Thread-Index: AcCbG36dv263vSs1RSmv8CgVsR93mgAbUtJA From: "Richard Draves" To: "Erik Nordmark" Cc: "Markku Savela" , X-OriginalArrivalTime: 20 Feb 2001 22:05:32.0027 (UTC) FILETIME=[3E0D7CB0:01C09B89] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1KMBq215530 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But the above is a SHOULD and the validity checks in section 8.1 > say MUST discard when this fails: > > - The IP source address of the Redirect is the same as > the current > first-hop router for the specified ICMP Destination Address. > > If there is only one default route pointing at the link > from which the redirect was received > (or for implementations with a richer routing table, > the lookup of the destination address only finds one routing > table entry that points at that link), then the redirect can > be safely used to create a destination cache entry. > > But when the lookup finds more than one possible next hops > that might have > been used to send the original packet, it seems a bit dangerous to > accept the redirect. The "current first-hop router for a destination" is a well-defined concept in our implementation, even if there are multiple default routers and no current destination cache entry. I don't see the danger in accepting the redirect under those circumstances. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 14:17:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1KMGw815586 for ipng-dist; Tue, 20 Feb 2001 14:16:58 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KMGn215579 for ; Tue, 20 Feb 2001 14:16:49 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17257 for ; Tue, 20 Feb 2001 14:16:50 -0800 (PST) Received: from c000.snv.cp.net (c000-h002.c000.snv.cp.net [209.228.32.66]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA28765 for ; Tue, 20 Feb 2001 14:16:50 -0800 (PST) Received: (cpmta 24598 invoked from network); 20 Feb 2001 14:16:49 -0800 Received: from unknown (HELO dellchan) (208.135.49.132) by smtp.francis.com (209.228.32.66) with SMTP; 20 Feb 2001 14:16:49 -0800 X-Sent: 20 Feb 2001 22:16:49 GMT Message-ID: <031e01c09b8a$ced60ae0$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Matt Crawford" Cc: "Christian Huitema" , References: <200102202205.QAA23365@gungnir.fnal.gov> Subject: Re: Wade through the archives (was Re: another renumbering question) Date: Tue, 20 Feb 2001 14:16:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > It doesn't. My eye seized upon the wrong number. 2^19 should have > been 2^38 throughout. And then making private-space connections to > 16 sites gives you a <= one-in-500-million chance of collision, and > connecting to 256 sites gives <= one-in-2-million. > This is a better number, and one I feel I could live with (by which I mean, one that would justify the use of random number selection as one of the alternative methods of assigning these identifiers...) And I would literally specify, as per Christian's suggestion, that the number MUST be created by flipping a coin 38 times... PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 19:09:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1L37uL16989 for ipng-dist; Tue, 20 Feb 2001 19:07:56 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1L37p216982 for ; Tue, 20 Feb 2001 19:07:51 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f1L35QJ13885 for ipng@sunroof.eng.sun.com; Tue, 20 Feb 2001 19:05:26 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1KALp212663 for ; Tue, 20 Feb 2001 02:21:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09609 for ; Tue, 20 Feb 2001 02:21:51 -0800 (PST) Received: from iibm-w2ks007 ([203.199.75.230]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21207 for ; Tue, 20 Feb 2001 03:21:46 -0700 (MST) Received: from indiainfo.com ([203.199.75.248]) by iibm-w2ks007 with Microsoft SMTPSVC(5.0.2172.1); Tue, 20 Feb 2001 15:51:45 +0530 Received: from [203.197.138.194] (account ) by indiainfo.com (CommuniGate Pro WebUser 3.4b8) with HTTP id 14112680; Tue, 20 Feb 2001 15:48:37 +0530 From: "Niveda Monyvannan" Subject: Clarification in Tunnel To: users@ipv6.org, ipng@sunroof.eng.sun.com X-Mailer: CommuniGate Pro Web Mailer v.3.4b8 Date: Tue, 20 Feb 2001 15:48:37 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Feb 2001 10:21:45.0281 (UTC) FILETIME=[ECF36310:01C09B26] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Should configured tunnel always be a duplex one? A-------------B========C--------------------D Let us say B is configured to encaptulate v6 packet to C. Should C have a configured tunnel interface towards B to receive a encaptulated packets from B? take a look at the following scenario u still have reachability from D to A. A D F | | | B======>======C======>=====E and THERE IS A CONFIGURED TUNNEL HALF-DUPLEX ONE, FROM E TO B. This way packets from D can reach A right ? Regards, Niveda ---------------------------------------- http://mail.indiainfo.com First you had 10MB of free mail space. Now you can send mails in your own language !!! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 20 21:03:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1L52TA17522 for ipng-dist; Tue, 20 Feb 2001 21:02:30 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1L52F217497 for ; Tue, 20 Feb 2001 21:02:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07341 for ; Tue, 20 Feb 2001 21:02:15 -0800 (PST) Received: from ratree.psu.ac.th ([192.100.77.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA16447 for ; Tue, 20 Feb 2001 22:02:08 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (sw11.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id MAA19775; Wed, 21 Feb 2001 12:00:47 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f1L50ZA02613; Wed, 21 Feb 2001 12:00:40 +0700 (ICT) From: Robert Elz To: "Paul Francis" cc: "Brian Haberman" , "ipng" Subject: Re: Wade through the archives (was Re: another renumbering question) In-reply-to: Your message of "Tue, 20 Feb 2001 14:09:34 PST." <02ff01c09b89$cf065f20$8cc90518@smateo1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Feb 2001 12:00:35 +0700 Message-ID: <2611.982731635@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 20 Feb 2001 14:09:34 -0800 From: "Paul Francis" Message-ID: <02ff01c09b89$cf065f20$8cc90518@smateo1.sfba.home.com> | It would not be globally routable "by definition"... That is, the prefix | would be recognized by routers as non-globally routable and they would | refuse to route them. no, you can't do that with site local - the block has to be done by configuration, where the administrator tells the router that a site boundary exists, otherwise you end up just having link local addresses with a lot of extra bits set... This means that it will always be technically possible to explode the site boundaries, and route using this new kind of address, if people wanted to (whatever the address type is called). | so the | potentiallity of huge routing tables is there whether or not a site-id | registry is created. This is certainly true - unique site locals (or GULRs or whatever) might add to the pressure a little but they don't create it, and nor does anyone have to take any notice of it. Their purpose is not for wire are routing. That just needs to be made very clear. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 04:43:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1LCfdL19454 for ipng-dist; Wed, 21 Feb 2001 04:41:39 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1LCfU219447 for ; Wed, 21 Feb 2001 04:41:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18753 for ; Wed, 21 Feb 2001 04:41:29 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA09543 for ; Wed, 21 Feb 2001 05:41:28 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA22260; Wed, 21 Feb 2001 14:52:55 +0200 Date: Wed, 21 Feb 2001 14:52:55 +0200 Message-Id: <200102211252.OAA22260@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: Address configuration questions (RFC2462) References: <200102191238.OAA20125@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like get clarification to section 5.5.3 (e): what is supposed to happen with the preferred lifetime? Do the two hour checks apply to it too? [if not, then DOS can force all addresses into deprecated state]. However, I have some doubts whether this two-hour rules gives any protection against DOS attacks. Anyone can read the RFC, and note: "Ok, that won't work, but let's try some other things...", like fake a number of RA's from same or different routers, with *LOTS* of different prefixes => Either the target nodes runs out of memory or if there is upper limit of prefixes (like I have), they overwrite existing valid ones or prevent new ones from being entered. Any ideas how to prevent this? Perhaps one should only rely that the "official" routers monitor the RA's and raise an alarm, if they see unknown routers or inconsitent information? Anyone trying to DOS from the local net would quickly be caught? Of course, there is the IPSEC, but... seems that only manual SA's will work (can't run IKE for this). (For RA's, a single unidirectional SA with DST=allnodes multicast would do the trick, SA wouldn't need the src addres either, the same could be used by all routers). => the keys must be widely known so that valid users can install their machines on the net. Not too secure, but I suppose better than nothing. After RA's are passing securely, things get easier, because you can start using IKE in some cases. It's a kind of bootstrapping process that needs to be designed...? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 07:53:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1LFq6b20290 for ipng-dist; Wed, 21 Feb 2001 07:52:06 -0800 (PST) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1LFpv220283 for ; Wed, 21 Feb 2001 07:51:57 -0800 (PST) Received: from hogwart.Central.Sun.COM (hogwart.Central.Sun.COM [129.153.128.110]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26648; Wed, 21 Feb 2001 08:51:56 -0700 (MST) Received: (from davemq@localhost) by hogwart.Central.Sun.COM (8.11.2+Sun/8.11.2) id f1LFq0X194845; Wed, 21 Feb 2001 09:52:00 -0600 (CST) Date: Wed, 21 Feb 2001 09:52:00 -0600 From: Dave Marquardt To: Niveda Monyvannan Cc: users@ipv6.org, ipng@sunroof.eng.sun.com Subject: Re: Clarification in Tunnel Message-ID: <20010221095200.F156881@hogwart> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from niveda@indiainfo.com on Tue, Feb 20, 2001 at 03:48:37PM +0530 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Feb 20, 2001 at 03:48:37PM +0530, Niveda Monyvannan wrote: > Should configured tunnel always be a duplex one? Are you talking about tunneling IPv6 over IPv4? I don't think you need to have a duplex tunnel. Try considering the tunnel "interface" to be transmit only, i.e. half duplex. The tunneling RFCs (2893 and 2473) treat tunneling as an encapsulation mechanism and decapsulation is just "normal" protocol operation. So I would say, no, you don't need to have a full duplex tunnel. > A-------------B========C--------------------D > > Let us say B is configured to encaptulate v6 packet to C. Should C have > a configured tunnel interface towards B to receive a encaptulated > packets from B? No, I don't think so. > take a look at the following scenario u still have reachability from D > to A. > A D F > | | | > B======>======C======>=====E > > and THERE IS A CONFIGURED TUNNEL HALF-DUPLEX ONE, FROM E TO B. This way > packets from D can reach A right ? Okay, that's a good ROUTING setup. Routing can always be assymmetric, so this works fine. One thing this made me wonder about, though. Let's say we have your ABCD scenario above: A-------------B========C--------------------D C is a router. All nodes have IPv6 addresses, call them A6, B6, C6, and D6. B and C have IPv4 addresses, B4 and C4. Is it "legal" to configure a tunnel from B to D by using B4 as the local IPv4 address and C4 as the remote address, and configuring the local IPv6 address as B6 and the remote IPv6 address as D6? Packets to D would get encapsulated at B in an IPv4 packet with B4 as source and C4 as destination. When the packet reached C, it would be decapsulated. Since C is a router, it would forward the packet on to D. Is this allowed? It's confusing, but I don't see why it wouldn't work. -- Dave Marquardt Sun Microsystems, Inc. +1 512 401-1077 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 07:56:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1LFttP20311 for ipng-dist; Wed, 21 Feb 2001 07:55:55 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1LFtk220304 for ; Wed, 21 Feb 2001 07:55:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16861 for ; Wed, 21 Feb 2001 07:55:46 -0800 (PST) Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA25104 for ; Wed, 21 Feb 2001 08:55:45 -0700 (MST) Received: (cpmta 29465 invoked from network); 21 Feb 2001 07:55:44 -0800 Received: from c1389778-a.smateo1.sfba.home.com (HELO dellchan) (24.5.201.140) by smtp.francis.com (209.228.32.65) with SMTP; 21 Feb 2001 07:55:44 -0800 X-Sent: 21 Feb 2001 15:55:44 GMT Message-ID: <045601c09c1e$c0bf7a60$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Nathan Lutchansky" , "ipng mailing list" References: Subject: Re: Wade through the archives (was Re: another renumbering question) Date: Wed, 21 Feb 2001 07:55:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > register it as a domain name with a specially-designated suffix. Let's > say the suffix is -site-ipv6.net, and let's say they chose the nice random > number 0x0012345678, so they would register the domain > "x0012345678-site-ipv6.net". If somebody else was using that unique > prefix, company.foo would find this out when they went to register it, and > would be forced to choose a different number. This guarantees uniqueness. > That is certainly an interesting idea. The obvious negatives: 1. Extra load on core DNS, mainly I suppose for just storing the things---presumably not too many of the actual queries would work thier way to the core (though some necessarily would). 2. Extra overhead and delay of the additional query. For popular sites, which typically have a very short TTL, the extra query would happen often, leading to increased load on local DNS server blah blah blah 3. Having to change the DNS client...buy-in from the DNS community might be tough. 4. The weirdness of requesting query x from DNS, and DNS going off and actually making query y. Does this actually happen in any other context today? Sounds like a major architectural change for DNS...(ah, but then again it wouldn't be the first time for IPv6....) 5. Presumably sites that prefered two-faced over this would not want thier hosts making this extra xxx-site-ipv6.net query. So there would have to be some way of switching the behaviour on and off. I don't know...other reactions? PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 09:00:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1LGxGu20627 for ipng-dist; Wed, 21 Feb 2001 08:59:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1LGx5220620 for ; Wed, 21 Feb 2001 08:59:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11306 for ; Wed, 21 Feb 2001 08:59:05 -0800 (PST) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29419 for ; Wed, 21 Feb 2001 08:59:04 -0800 (PST) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.20 #3) id 14VcbW-0004JU-00; Wed, 21 Feb 2001 11:59:02 -0500 Date: Wed, 21 Feb 2001 11:59:02 -0500 (EST) From: Nathan Lutchansky To: Paul Francis cc: ipng mailing list Subject: Re: Wade through the archives (was Re: another renumbering question) In-Reply-To: <045601c09c1e$c0bf7a60$8cc90518@smateo1.sfba.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some of these I'd thought of, others I hadn't. I didn't realize until afterwards that this would probably need to be run by the DNS groups to make sure they're OK with it. On Wed, 21 Feb 2001, Paul Francis wrote: > 1. Extra load on core DNS, mainly I suppose for just storing the > things---presumably not too many of the actual queries would work thier way > to the core (though some necessarily would). Essentially this boils down to the question, "Does registering an extra domain for each site/organization cause extra load on the DNS system, considering that these extra domains would receive very little core traffic?" Two points: a) As it stands, most companies register not only their primary domain name, but their domain name in multiple TLDs (com, net, org, plus CCs), all possible misspellings of their name, their name with various suffixes like "sucks", a domain or two for each of their products, maybe a name for each of their regional offices, and so on. Adding a single name to correspond to their site's network number will probably be fairly insignificant. b) I don't think any registrar will tell you, "No, people should stop registering domains because the DNS infrastructure won't handle it." :-) > 2. Extra overhead and delay of the additional query. For popular sites, > which typically have a very short TTL, the extra query would happen often, > leading to increased load on local DNS server blah blah blah Like I said in the proposal, the authoritative server for the site-local zone will likely be very close to all the clients doing lookups in that zone. We would expect that site-local queries never leave the site. > 3. Having to change the DNS client...buy-in from the DNS community might be > tough. Oh, yeah, and A6/DNAME don't require changing the DNS client at all. If we're tacking on features, we may as well do it all up front. This can be just another modification required for IPv6 support. > 4. The weirdness of requesting query x from DNS, and DNS going off and > actually making query y. Does this actually happen in any other context > today? Sounds like a major architectural change for DNS...(ah, but then > again it wouldn't be the first time for IPv6....) Kind of. This is along the same lines as domain search paths. If I type "http://www" into my browser, the DNS resolver will return the address for www.litech.org even though I clearly did not type "litech.org" in the address. It might even return the address for www.litech.internal, even if what I expected was www.litech.org. Note that domain search paths are configured via DHCP, and thus are set at a site-level rather than individually for each host. (Although each host is able to modify this if desired.) > 5. Presumably sites that prefered two-faced over this would not want thier > hosts making this extra xxx-site-ipv6.net query. So there would have to be > some way of switching the behaviour on and off. I'm a bit unclear on what you mean by "two-faced" DNS then. I'm assuming that you mean that queryes for addresses inside the company.foo domain would be answered differently depending on the IP address of the queryer. My proposal would achieve exactly this, by having all clients inside the site obtain addresses from the company.foo.x0012345678-site-ipv6.net zone instead of the real company.foo zone. If two-faced DNS is desirable to "hide" the addresses from hosts outside the site, then the DNS servers for x0012345678-site-ipv6.net could easily be configured to only allow queries from site-local addresses. The other possible interpretation for two-faced DNS is that hosts inside the site would use addresses in a separate domain, like company.internal as described in the BIND documentation, and that company.internal would only be available to hosts inside the site. My proposal is analogous to this, only the internal-only zone is registered globally, and clients automatically look up addresses inside the zone without manual configuration. Hope this clears things up. -Nathan -- +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 10:50:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1LIo0K21151 for ipng-dist; Wed, 21 Feb 2001 10:50:00 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1LInp221144 for ; Wed, 21 Feb 2001 10:49:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23741 for ; Wed, 21 Feb 2001 10:49:50 -0800 (PST) Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA23522 for ; Wed, 21 Feb 2001 10:49:49 -0800 (PST) Received: (cpmta 9458 invoked from network); 21 Feb 2001 10:49:49 -0800 Received: from unknown (HELO dellchan) (208.135.49.132) by smtp.francis.com (209.228.32.71) with SMTP; 21 Feb 2001 10:49:49 -0800 X-Sent: 21 Feb 2001 18:49:49 GMT Message-ID: <04b401c09c37$0919e440$8cc90518@smateo1.sfba.home.com> From: "Paul Francis" To: "Nathan Lutchansky" Cc: "ipng mailing list" References: Subject: Re: Wade through the archives (was Re: another renumbering question) Date: Wed, 21 Feb 2001 10:49:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > b) I don't think any registrar will tell you, "No, people should stop > registering domains because the DNS infrastructure won't handle it." :-) yeah, I know the registrars are happy to take your money. I was thinking of the actual core machines. > Kind of. This is along the same lines as domain search paths. If I type > "http://www" into my browser, the DNS resolver will return the address for > www.litech.org even though I clearly did not type "litech.org" in the > address. It might even return the address for www.litech.internal, even > if what I expected was www.litech.org. Heh, I didn't know about this. I just tried it (from home), and sure enough got the home page of my ISP! So what happened? Did my browser "complete" the URL for me, or did DNS do it? me type http://www ---> browser expands to gethostbyname(www.myisp.com), DNS do query(www.myisp.com), or me type "http://www" ---> browser do "gethostbyname(www)", DNS expands to query(www.myisp.com) I would guess the former, but nothing will surprise me these days...are DNS clients "intelligently" expanding DNS queries for us now? > I'm a bit unclear on what you mean by "two-faced" DNS then. I'm assuming > that you mean that queryes for addresses inside the company.foo domain > would be answered differently depending on the IP address of the queryer. > > My proposal would achieve exactly this, by having all clients inside the I basically meant this. (I'm not quite clear as to whether internal dns servers actually pay attention to the IP address of the queryer, or rather if they just assume that if they got a query, it must have come from inside since the firewall prevents them from coming from outside. I would have assumed the latter. >From what I know so far, I believe it may be possible for a site to use GULRs today without any changes to any existing implementations, as long as they use two-faced DNS. The ability to do this is very attractive for obvious reasons. It is probably mainly for that reason that I'm disinclined towards the part of your idea that requires change to the DNS client. The part of your scheme that uses site-ipv6.net simply for the purpose of helping guarantee uniqueness, however, is very nice. I don't think everyone would want to use it (rather they would just be lazy and flip the coins but not register), but those that do would at least have some legitimate legal claim to the number, should the issue arrise in the future. Another attractive part of this aspect of your scheme is that it would put pressure on ICANN to create a true registry for the GULR identifiers. The pressure would come from people that are outraged at having to pay for a domain name that they don't in fact intend to use as a domain name. So at some point the site-IPv6.net's would be grandfathered into a "true" registry. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 12:01:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1LK0TF21478 for ipng-dist; Wed, 21 Feb 2001 12:00:29 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1LK0F221464 for ; Wed, 21 Feb 2001 12:00:15 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17251 for ; Wed, 21 Feb 2001 12:00:14 -0800 (PST) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24254 for ; Wed, 21 Feb 2001 12:00:05 -0800 (PST) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.20 #3) id 14VfQh-0006AW-00; Wed, 21 Feb 2001 15:00:03 -0500 Date: Wed, 21 Feb 2001 15:00:03 -0500 (EST) From: Nathan Lutchansky To: Paul Francis cc: ipng mailing list Subject: Re: Wade through the archives (was Re: another renumbering question) In-Reply-To: <04b401c09c37$0919e440$8cc90518@smateo1.sfba.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 21 Feb 2001, Paul Francis wrote: > > b) I don't think any registrar will tell you, "No, people should stop > > registering domains because the DNS infrastructure won't handle it." :-) > > yeah, I know the registrars are happy to take your money. I was thinking of > the actual core machines. Oh, right. Those. But I still think it's negligible considering how much other stuff gets registered for immeasurably little benefit. > > Kind of. This is along the same lines as domain search paths. If I type > > "http://www" into my browser, the DNS resolver will return the address for > > www.litech.org even though I clearly did not type "litech.org" in the > > address. It might even return the address for www.litech.internal, even > > if what I expected was www.litech.org. > > Heh, I didn't know about this. I just tried it (from home), and sure enough > got the home page of my ISP! So what happened? Did my browser "complete" > the URL for me, or did DNS do it? [...] > I would guess the former, but nothing will surprise me these days...are DNS > clients "intelligently" expanding DNS queries for us now? This is a resolver feature, and AFAIK they've supported this from the beginning. It's the "domain search path". Check the manpage for resolver(5). Essentially, if there are fewer than two dots in any name you're trying to resolve, the resolver will attempt to append every domain in your search path and resolve the result before trying to resolve the name alone as a FQDN. I'm not sure if this behavior is specified in an RFC or not, but every IP stack/resolver I've encountered has this feature. The search path is a parameter that can be passed via DHCP, or configured locally in /etc/resolv.conf in Un*x or in the network control panel in Windows. > From what I know so far, I believe it may be possible for a site to use > GULRs today without any changes to any existing implementations, as long as > they use two-faced DNS. The ability to do this is very attractive for > obvious reasons. It is probably mainly for that reason that I'm disinclined > towards the part of your idea that requires change to the DNS client. Yes, with two-faced DNS you could use GULRs right now. But two-faced DNS is inconvenient for certain situations like mobile IP and multisite nodes. Which DNS server would a multisite node query? If it needed to get GULR addresses for both sites, it would need to have more complicated changes to its DNS resolver than my proposal would require. Or it would have to run a full DNS server locally. In fact, you could implement my proposal today without two-faced DNS by simply setting the threshhold for search-path lookups higher than 2 dots, and inserting the unique prefix domain as the first entry in the search path. Of course, you'd have to configure this on every host at your site. The advantage to modifying the resolvers is to hard-code (literally) the format for the unique-local domains. Maybe folks in Australia start using x0012345678-site-ipv6.net.au instead of the official suffix. Maybe Big Rich Company(R) accidentally registers and uses x0012345678-site-ip6.net (misspelled), then a few years down the road tries to take the domain x0012345678-site-ipv6.net away from the real registered owner. Or worse, tries to merge sites with them. It is conflicts like these that we are trying to avoid, and we can enforce the use of the correct format now if we provide an immediate incentive for getting it right the first time. > The part of your scheme that uses site-ipv6.net simply for the purpose of > helping guarantee uniqueness, however, is very nice. I don't think everyone > would want to use it (rather they would just be lazy and flip the coins but > not register), but those that do would at least have some legitimate legal > claim to the number, should the issue arrise in the future. [They'd have to flip 38 coins then, eh? :-) ] That was the original motivation behind using domains in the first place. But the more incentive we can find for sites to register, the more likely it will be to work. Modifying resolvers to allow hosts to auto-configure themselves for site-local resolution is a nice incentive, and having actual data in the domains also ensures that the contact and NS information for the domains will remain up-to-date in the whois database. > Another attractive part of this aspect of your scheme is that it would put > pressure on ICANN to create a true registry for the GULR identifiers. The > pressure would come from people that are outraged at having to pay for a > domain name that they don't in fact intend to use as a domain name. So at > some point the site-IPv6.net's would be grandfathered into a "true" > registry. While it would be nice to simply have a TLD (kinda like .arpa) or other dedicated repository for these registrations, we all know how likely it is that such an entity would be created at this stage. All the other arguments against a new repository, such as measures to prevent an individual from grabbing the whole space, are already resolved for an established system like DNS. Perhaps at some point in the future we will have enough motivation and operational experience to move to a better method of registration. Regarding the difficulty in modifying the resolvers... I think that would take the addition of maybe 10 lines of code, don't you? -Nathan -- +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 14:31:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1LMUig22078 for ipng-dist; Wed, 21 Feb 2001 14:30:44 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1LMUX222064 for ; Wed, 21 Feb 2001 14:30:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01191 for ; Wed, 21 Feb 2001 14:30:33 -0800 (PST) Received: from c000.snv.cp.net (c000-h002.c000.snv.cp.net [209.228.32.66]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA11367 for ; Wed, 21 Feb 2001 14:30:32 -0800 (PST) Received: (cpmta 21797 invoked from network); 21 Feb 2001 14:30:31 -0800 Received: from unknown (HELO dellchan) (208.135.49.132) by smtp.francis.com (209.228.32.66) with SMTP; 21 Feb 2001 14:30:31 -0800 X-Sent: 21 Feb 2001 22:30:31 GMT Message-ID: <003c01c09c55$e6d8e060$1300a8c0@smateo1.sfba.home.com> From: "Paul Francis" To: "Nathan Lutchansky" Cc: "ipng mailing list" References: Subject: Re: Wade through the archives (was Re: another renumbering question) Date: Wed, 21 Feb 2001 14:30:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > That was the original motivation behind using domains in the first place. > But the more incentive we can find for sites to register, the more likely > it will be to work. Modifying resolvers to allow hosts to auto-configure > themselves for site-local resolution is a nice incentive, and having > actual data in the domains also ensures that the contact and NS > information for the domains will remain up-to-date in the whois database. > You know, I only now realized that most of your scheme is with respect to the usage of site-locals, not GULRs. My last couple messages in response to your scheme were concerning GULRs only, so please disregard them... PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 14:59:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1LMwda22125 for ipng-dist; Wed, 21 Feb 2001 14:58:39 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1LMwS222118 for ; Wed, 21 Feb 2001 14:58:28 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14963 for ; Wed, 21 Feb 2001 14:58:25 -0800 (PST) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06309 for ; Wed, 21 Feb 2001 14:58:20 -0800 (PST) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.20 #3) id 14ViDD-0007n4-00; Wed, 21 Feb 2001 17:58:19 -0500 Date: Wed, 21 Feb 2001 17:58:19 -0500 (EST) From: Nathan Lutchansky To: Paul Francis cc: ipng mailing list Subject: Re: Wade through the archives (was Re: another renumbering question) In-Reply-To: <003c01c09c55$e6d8e060$1300a8c0@smateo1.sfba.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 21 Feb 2001, Paul Francis wrote: > > That was the original motivation behind using domains in the first place. > > But the more incentive we can find for sites to register, the more likely > > it will be to work. Modifying resolvers to allow hosts to auto-configure > > themselves for site-local resolution is a nice incentive, and having > > actual data in the domains also ensures that the contact and NS > > information for the domains will remain up-to-date in the whois database. > > > > You know, I only now realized that most of your scheme is with respect to > the usage of site-locals, not GULRs. My last couple messages in response to > your scheme were concerning GULRs only, so please disregard them... This is my mistake. I've been using the terms "site-local" and GULR/unique-local interchangably, when in fact they are two separate terms. The site-ipv6.net zone would be used to store addresses within a site's GULR prefix. Your responses to my earlier messages are valid, as far as I can tell. -Nathan -- +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 15:43:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1LNgW322160 for ipng-dist; Wed, 21 Feb 2001 15:42:32 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1LNgN222153 for ; Wed, 21 Feb 2001 15:42:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08251 for ; Wed, 21 Feb 2001 15:42:23 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26180 for ; Wed, 21 Feb 2001 16:42:22 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA10329; Wed, 21 Feb 2001 15:42:21 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f1LNgH922563; Wed, 21 Feb 2001 15:42:17 -0800 X-mProtect: Wed, 21 Feb 2001 15:42:17 -0800 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdVTYAGT; Wed, 21 Feb 2001 15:41:58 PST Message-Id: <4.3.2.7.2.20010221153636.01f25e50@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Feb 2001 15:38:14 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as an Informational RFC: Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-03.txt Pages : 31 Date : 12-Feb-01 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on March 7, 2001. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 15:44:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1LNhEv22169 for ipng-dist; Wed, 21 Feb 2001 15:43:14 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1LNgx222162 for ; Wed, 21 Feb 2001 15:42:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13804 for ; Wed, 21 Feb 2001 15:42:59 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26561 for ; Wed, 21 Feb 2001 16:42:59 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA10394; Wed, 21 Feb 2001 15:42:58 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f1LNgtR24966; Wed, 21 Feb 2001 15:42:55 -0800 X-mProtect: Wed, 21 Feb 2001 15:42:55 -0800 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdyGiAYu; Wed, 21 Feb 2001 15:42:50 PST Message-Id: <4.3.2.7.2.20010221153853.01f4ece8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Feb 2001 15:39:01 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as an Informational RFC: Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-03.txt Pages : 31 Date : 12-Feb-01 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on March 7, 2001. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 16:58:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1M0vqs22226 for ipng-dist; Wed, 21 Feb 2001 16:57:52 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1M0vh222219 for ; Wed, 21 Feb 2001 16:57:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25272 for ; Wed, 21 Feb 2001 16:57:43 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA12964 for ; Wed, 21 Feb 2001 17:57:42 -0700 (MST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Wed, 21 Feb 2001 16:52:21 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Feb 2001 16:51:28 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Wed, 21 Feb 2001 16:51:28 -0800 content-class: urn:content-classes:message Subject: RE: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 21 Feb 2001 16:51:16 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657405266CE7@DF-BOWWOW.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4653.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Thread-Index: AcCcZm/Y4+pexSXyREWdHJJtKVyPgAAAittA From: "Dave Thaler" To: "Bob Hinden" , X-OriginalArrivalTime: 22 Feb 2001 00:51:28.0434 (UTC) FILETIME=[96F26120:01C09C69] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1M0vi222220 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end two > week from today on March 7, 2001. Since some of my comments to the authors on 1/25 are substantive, and none have yet been addressed, I'm resending to the ipng mailing list as requested. Point #6 is controversial, and arguments for both sides have each been presented by multiple proponents on the apifolks list. 1) Section 3.5 talks about creating an "IPv6/UDP" socket with a socket call with PF_INET6. Later, in section 3.7, the reader finds out that it isn't an "IPv6/UDP" socket at all, but a sort of hybrid IPv6+IPv4/UDP socket. To create a pure "IPv6/UDP" socket, one needs to also use the setsockopt described in 5.3. It would be nice if the discussing in 3.5 wasn't so misleading. For example, how about adding a parenthentical forward reference like: OLD: > Applications may create IPv6/TCP and IPv6/UDP sockets by simply using NEW: > Applications may create IPv6/TCP and IPv6/UDP sockets (which may > also handle IPv4 communication as described in section 3.7) by simply > using ... 2) Section 5.2's first sentence seems to limit applicability to UDP. Neither this document, nor 2292bis mentions that these can be used with RAW sockets (or conceivably non-UDP dgram sockets if anyone defines one). This needs to be fixed in one place or the other. My own preference would be for this section to just say these options will fail on SOCK_STREAM sockets, and leave it at that. 3) The description of IPV6_MULTICAST_IF should say (as is done for IPV6_JOIN_GROUP) what happens if the app specifies 0. (I believe this should tell the kernel to choose one.) 4) IPV6_LEAVE_GROUP is similarly terse. If the app passes 0 as the interface to IPV6_JOIN_GROUP, the current wording implies that it has to magically figure out which interface the kernel chose and specify that interface in the leave. The wording should be updated to say that the value of the interface field should match whatever the app used in that field in its IPV6_JOIN_GROUP call. 5) Section 5.3's title uses "IPV6_ONLY" whereas the socket option is IPV6_V6ONLY. These should be consistent, or else the title shouldn't contain something that looks like a defined constant. 6) Section 5.3 states that the ipv6-only option is off by default. Like the discussion of bind semantics where we agreed to disagree, I strongly object to this as a requirement, for somewhat analogous reasons. Some stacks today (ours being one of them) are such that the behavior is "on". Changing the default will break apps. As with bind semantics, IMHO it's better to put the burden of always setting the option, on apps that need to be portable across OS's, rather than apps that are written for a single OS (whether it be Solaris 8, Windows, Linux, or anything else). The only reason this is a problem is that both stacks and apps already exist that people depend on the behavior being "on" by default, and I believe it's too late to force everyone to change. Sad but true. 7) In section 6.2, a strange character is present where an apostrophe should be, in two places: > name will not be returned. If the node^?s name cannot be located, the ^^ here > host^?s name cannot be located. ^^ here 8) In section 6.4: > [...] Note that IN6_IS_ADDR_LINKLOCAL > and IN6_IS_ADDR_SITELOCAL return true only for the two local-use IPv6 > unicast addresses. [...] I believe "types of" should be inserted after "two". There's certainly more than two local-use unicast addresses... Furthermore, it would help to illustrate the point by explicitly stating what the result of the test IN6_IS_ADDR_LINKLOCAL( ::1 ) is, especially in light of the fact that the scoped-arch document says ::1 is link-scoped (i.e. it should return false, and it's worth noting this, similar to the current note about multicast addresses). -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 19:21:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1M3KCP22354 for ipng-dist; Wed, 21 Feb 2001 19:20:12 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1M3K3222347 for ; Wed, 21 Feb 2001 19:20:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24994 for ; Wed, 21 Feb 2001 19:19:57 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA26426 for ; Wed, 21 Feb 2001 20:19:47 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1M3Jag18249 for ; Wed, 21 Feb 2001 21:19:46 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 21 Feb 2001 21:19:35 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 21 Feb 2001 21:19:35 -0600 Message-ID: To: dthaler@Exchange.Microsoft.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Basic Socket Interface Extensions for IPv6 " Date: Wed, 21 Feb 2001 21:19:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave, All your comments have been addressed. It may be some edits got missed and I will take blame for that, as I was moving files between different systems of late but things are stable now. > Since some of my comments to the authors on 1/25 > are substantive, and none have yet been addressed, > I'm resending to the ipng mailing list as requested. > Point #6 is controversial, and arguments for both sides have each > been presented by multiple proponents on the apifolks list. Yes and has been discussed and we took what we believe to be consensus from that mail and your free to continue to object, but we hoped you would not. > > 1) Section 3.5 talks about creating an "IPv6/UDP" socket > with a socket call with PF_INET6. Later, in section 3.7, the > reader finds out that it isn't an "IPv6/UDP" socket at all, > but a sort of hybrid IPv6+IPv4/UDP socket. To create > a pure "IPv6/UDP" socket, one needs to also use the setsockopt > described in 5.3. It would be nice if the discussing in 3.5 > wasn't so misleading. For example, how about adding a > parenthentical forward reference like: > > OLD: > > Applications may create IPv6/TCP and IPv6/UDP sockets by > simply using > NEW: > > Applications may create IPv6/TCP and IPv6/UDP sockets (which may > > also handle IPv4 communication as described in section 3.7) > by simply > > using ... I am fine with this but 3.7 has been in the spec for 6 years. I will attach a very good note from one api implementor which will apply to your point #6 too. I also do not recall your input on this on apifolks? This is not a problem to fix. > > 2) Section 5.2's first sentence seems to limit applicability to UDP. > Neither this document, nor 2292bis mentions that these can be used > with RAW sockets (or conceivably non-UDP dgram sockets if anyone > defines one). This needs to be fixed in one place or the other. > My own preference would be for this section to just say > these options > will fail on SOCK_STREAM sockets, and leave it at that. This is what I consider inherent for a base Info api, but we can do this as the IEEE will want this fixed too. OK fine. Again first time I have seen this one. > > 3) The description of IPV6_MULTICAST_IF should say (as is done for > IPV6_JOIN_GROUP) what happens if the app specifies 0. > (I believe this should tell the kernel to choose one.) This the implied behavior but we can add if the app specifies zero the implementation must select the interface. Not magic just smart code :----) > > 4) IPV6_LEAVE_GROUP is similarly terse. If the app passes 0 as the > interface to IPV6_JOIN_GROUP, the current wording implies that > it has to magically figure out which interface the kernel chose > and specify that interface in the leave. The wording should > be updated to say that the value of the interface field > should match > whatever the app used in that field in its IPV6_JOIN_GROUP call. We can fix the wording but what you say is what I did anyway when I wrote the code for this. OK fine. > > 5) Section 5.3's title uses "IPV6_ONLY" whereas the socket option > is IPV6_V6ONLY. These should be consistent, or else the title > shouldn't contain something that looks like a defined constant. This is a bug yes it should have been fixed. > > 6) Section 5.3 states that the ipv6-only option is off by default. > Like the discussion of bind semantics where we agreed to disagree, > I strongly object to this as a requirement, for somewhat analogous > reasons. Some stacks today (ours being one of them) are such that > the behavior is "on". Changing the default will break apps. > As with bind semantics, IMHO it's better to put the burden > of always > setting the option, on apps that need to be portable across OS's, > rather than apps that are written for a single OS (whether it > be Solaris 8, Windows, Linux, or anything else). The only reason > this is a problem is that both stacks and apps already exist that > people depend on the behavior being "on" by default, and I believe > it's too late to force everyone to change. Sad but true. We cannot get consensus here. But your implementation was one of the last ones done. All implementations but yours has no problem with the default on. On apifolks one other wanted to change it but most did not. We should not alter the behavior of this default for your implementation it would say your implementation is more important than others and that is not true at all. Also see the attached mail from one api implementor from apifolks. So the default will stand as is as far as I am concerned and consensus in this working group. If you want to begin this discussion here again then you will go against the apifolks list consensus. Thats fine do so. But see the attached mail and the working group should read it too. > > 7) In section 6.2, a strange character is present where an > apostrophe should be, in two places: > > name will not be returned. If the node^?s name cannot be > located, the > ^^ here > > host^?s name cannot be located. > ^^ here Hmmmm. Will fix this I don't have it on my nroff output. > > 8) In section 6.4: > > [...] Note that IN6_IS_ADDR_LINKLOCAL > > and IN6_IS_ADDR_SITELOCAL return true only for the two > local-use IPv6 > > unicast addresses. [...] > > I believe "types of" should be inserted after "two". > There's certainly more than two local-use unicast addresses... > Furthermore, it would help to illustrate the point by explicitly > stating what the result of the test > IN6_IS_ADDR_LINKLOCAL( ::1 ) > is, especially in light of the fact that the scoped-arch document > says ::1 is link-scoped (i.e. it should return false, and it's > worth noting this, similar to the current note about multicast > addresses). Fine with "types". We should not add explicit tests to this spec. What do others think? I suggest we let IEEE add specific tests. thanks for the careful reading. attached for all is from Jack McCann at Compaq on point #6 and sums up my view of this and I believe most of our design team and implementors view: --------------------------------------- I'm in favor of having the default behavior specified. It would be rather pathetic to place the burden of our inability to agree on a generation (or more) of application developers. Further, I'll point out (again) that the default behavior is already specified, and has been since draft-ietf-ipngwg-bsd-api-01.txt (1995), the precursor to rfc2133, rfc2553, and 2553bis. That default behavior is to allow AF_INET6 sockets to operate over IPv4. The wording, essentially unchanged since 1995, is: "Applications may use PF_INET6 sockets to open TCP connections to IPv4 nodes, or send UDP packets to IPv4 nodes, by simply encoding the destination's IPv4 address as an IPv4-mapped IPv6 address, and passing that address, within a sockaddr_in6 structure, in the connect() or sendto() call. When applications use PF_INET6 sockets to accept TCP connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the system returns the peer's address to the application in the accept(), recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded this way." (Note this section would need to be modified if we change the default to V6ONLY == 1.) The V6ONLY option was introduced to provide a way for a program to alter that default behavior. We may also want to consider this in the context of the two programming models: 1. single AF_INET6 socket handles both IPv4 and IPv6 -> wants V6ONLY == 0 2. separate AF_INET and AF_INET6 sockets for IPv4 and IPv6 -> wants V6ONLY == 1 Speaking generally, the single-socket model provides a simple port for existing single-socket applications. The separate-socket model provides protocol independence, but at the cost of additional code changes for existing single-socket applications. One could argue that since we're already paying the additional code cost in the separate-socket model, that's where we should add code to set V6ONLY to 1, and not increase the code changes required in the simpler single-socket model. As for the argument about some existing implementations defaulting to V6ONLY == 0, and others defaulting to V6ONLY == 1, one could argue that a V6ONLY == 1 implementation is not conformant to any existing version of the six year old API specification (see bsd-api-01 comments above). Vendors are now shipping conformant commercial products, this is not the time to change a behavior that has been stable and specified for 6 years with multiple conforming implementations. As for the argument about IPv4-mapped addresses bypassing access controls, one could argue that is simply a porting bug. - Jack ----------------------------------------------- thanks again, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 19:21:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1M3KWL22363 for ipng-dist; Wed, 21 Feb 2001 19:20:32 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1M3KK222356 for ; Wed, 21 Feb 2001 19:20:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA20979 for ; Wed, 21 Feb 2001 19:20:19 -0800 (PST) Received: from gate.alliedtelesyn.co.nz ([202.49.72.33]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA28620 for ; Wed, 21 Feb 2001 19:20:17 -0800 (PST) Received: (qmail 12923 invoked from network); 22 Feb 2001 05:30:44 -0000 Received: from aslan.alliedtelesyn.co.nz (HELO alliedtelesyn.co.nz) (202.49.72.92) by gate-int.alliedtelesyn.co.nz with SMTP; 22 Feb 2001 05:30:44 -0000 Received: from ASLAN/SpoolDir by alliedtelesyn.co.nz (Mercury 1.47); 22 Feb 01 16:19:02 +1200 Received: from SpoolDir by ASLAN (Mercury 1.47); 22 Feb 01 16:18:59 +1200 From: "Sean Lin" Organization: Allied Telesyn Research, Chch, NZ To: ipng@sunroof.eng.sun.com Date: Thu, 22 Feb 2001 16:18:58 +1200 (NZT) MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Neigbour Solicitation messages without SLLA Reply-to: sean.lin@alliedtelesyn.co.nz Message-ID: <3A953BEB.11171.FBEE963@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I do not think the following was specified in RFC2460 (or I can't find it stated anywhere). What happens if you receive a Neighbour Solicitation Message with unicast addresses without a source link layer address? Do you add an entry with the state set to STALE or INCOMPLETE? Or do you just ignore it? Sean ------------------------------------------------------------- Sean Lin 27 Nazareth Avenue Software Engineer PO Box 8011 Allied Telesyn Research Christchurch phone +64 3 339 3000 New Zealand fax +64 3 339 3002 email: sean.lin@alliedtelesyn.co.nz web: http://www.alliedtelesyn.co.nz/ ------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 21 19:54:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f1M3rPt22409 for ipng-dist; Wed, 21 Feb 2001 19:53:25 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1M3rF222402 for ; Wed, 21 Feb 2001 19:53:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24288 for ; Wed, 21 Feb 2001 19:53:13 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA12409 for ; Wed, 21 Feb 2001 20:53:12 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id MAA20446; Thu, 22 Feb 2001 12:52:58 +0900 (JST) To: "Dave Thaler" cc: "Bob Hinden" , ipng@sunroof.eng.sun.com In-reply-to: dthaler's message of Wed, 21 Feb 2001 16:51:16 PST. <5B90AD65A9E8934987DB0C8C0762657405266CE7@DF-BOWWOW.platinum.corp.microsoft.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" From: itojun@iijlab.net Date: Thu, 22 Feb 2001 12:52:58 +0900 Message-ID: <20444.982813978@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Please send substantive comments to the ipng mailing list, and minor >> editorial comments to the authors. This last call period will end two >> week from today on March 7, 2001. Just to make sure: with 2553bis-03 draft, the comment from Jason Thorpe regarding to constness of gai_strerror return type is not addressed. Quoting Jim: >good catch Jason...and your right (yes it is constant).. >I will fix things like this before the last draft for the rfc editor. >I will find someone to go talk to austin. I don't now that I am at nokia. >but I still know the austin folks. so I hope it to be addressed before it becomes RFC. (as jim may have guessed) I second Dave on his point #6. I believe we should not ignore deployed codebase (not just operating systems, but also third party applications all around us) when we make updates to API. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 22 01:29:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) id f1M9SRo22851 for ipng-dist; Thu, 22 Feb 2001 01:28:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) with ESMTP id f1M9SGB22844 for ; Thu, 22 Feb 2001 01:28:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27929 for ; Thu, 22 Feb 2001 01:28:16 -0800 (PST) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18410 for ; Thu, 22 Feb 2001 01:28:15 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f1M9Qw211940; Thu, 22 Feb 2001 10:26:58 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA00491; Thu, 22 Feb 2001 10:26:57 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f1M9QuO51894; Thu, 22 Feb 2001 10:26:57 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200102220926.f1M9QuO51894@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: sean.lin@alliedtelesyn.co.nz cc: ipng@sunroof.eng.sun.com Subject: Re: Neigbour Solicitation messages without SLLA In-reply-to: Your message of Thu, 22 Feb 2001 16:18:58 +1200. <3A953BEB.11171.FBEE963@localhost> Date: Thu, 22 Feb 2001 10:26:56 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: What happens if you receive a Neighbour Solicitation Message with unicast addresses without a source link layer address? => what do you mean by "with unicast"? Do you add an entry with the state set to STALE or INCOMPLETE? Or do you just ignore it? => if the destination is multicast it is just ignored. If the destination is unicast then the state is not changed and an advertisement is sent (this can create an entry in the INCOMPLETE state). There is no DoS issue because the peer must know your link layer address in order to send an unicast NS. Francis.Dupont@enst-bretagne.fr PS: NUD is a case you can see unicast NS without SLLA, for instance for the first packet of NUD... RFC 2460 has a SHOULD for SLLA with a MAY for no SLLA in the unicast case so you can do near what you like (:-). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 22 13:25:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) id f1MLNsx23515 for ipng-dist; Thu, 22 Feb 2001 13:23:54 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) with ESMTP id f1MLNhB23508 for ; Thu, 22 Feb 2001 13:23:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29896 for ; Thu, 22 Feb 2001 13:23:42 -0800 (PST) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22181 for ; Thu, 22 Feb 2001 13:23:40 -0800 (PST) Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id 83B46E82; Thu, 22 Feb 2001 13:23:38 -0800 (PST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 6384AFBD; Thu, 22 Feb 2001 13:23:38 -0800 (PST) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 0AF552E1; Thu, 22 Feb 2001 15:23:40 -0600 (CST) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id B37162E6; Thu, 22 Feb 2001 15:23:39 -0600 (CST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id QAA0000011959; Thu, 22 Feb 2001 16:23:38 -0500 (EST) Received: from whitestar.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id QAA0000013451; Thu, 22 Feb 2001 16:23:38 -0500 (EST) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA10103; Thu, 22 Feb 2001 16:23:37 -0500 Message-Id: <3A958359.AC9C701A@zk3.dec.com> Date: Thu, 22 Feb 2001 16:23:37 -0500 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: ru, en Mime-Version: 1.0 To: IPNG Working Group , Jim.Bound@nokia.com Subject: Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" References: <4.3.2.7.2.20010221153853.01f4ece8@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim It appears that the definition of AI_DEFAULT has been removed from the document. I am not sure if this was intentional or not. If this was intentional, then I think that AI_DEFAULT symbol should be removed from section 7. If this definition was removed by mistake, it should probably be put back. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 23 07:40:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) id f1NFdAN26484 for ipng-dist; Fri, 23 Feb 2001 07:39:10 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) with ESMTP id f1NFd0G26477 for ; Fri, 23 Feb 2001 07:39:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07142 for ; Fri, 23 Feb 2001 07:39:01 -0800 (PST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24600 for ; Fri, 23 Feb 2001 07:38:45 -0800 (PST) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id 0D90472501; Fri, 23 Feb 2001 17:37:51 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 3E334BA03; Fri, 23 Feb 2001 17:37:50 +0200 (EET) Message-ID: <3A968461.1F420465@nomadiclab.com> Date: Fri, 23 Feb 2001 17:40:17 +0200 From: Pekka Nikander X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: mobile-ip@marvin.corpeast.baynetworks.com, ipsec@lists.tislabs.com, IPNG Working Group Subject: A new I-D on authorization issues in IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [My aplogies for sending this to three separage lists, but IMHO this is really relevant to all of them.] A have submitted a new I-D concerning a number of authorization issues in IPv6 related signalling, including Mobile IPv6 Binding Updates. The purpose of the I-D is to summarize and clarify the situation from this specific security point of view. As it has not appeared in the archieves yet, it is also available at http://www.nomadiclab.com/~pnr/publications/\ draft-nikander-ipng-address-ownership-00.txt I hope that the draft can act as one input to the the forthcoming Mobile IPv6 discussion to be held at Minneapolis, and clarify some issues related to using IPsec in IPv6 to protect various kinds of signalling messages. For your convenience, I've included the draft abstract below. --Pekka Nikander Abstract This document seeks to clarify a number of problems related to authorization of changing local routing information in the current IPv6 architecture. This document does not (currently) cover actual routing protocols. Instead, in IPv6, there are a number of additional mechanisms that allow local routing information to be changed. Some mechanisms are meant to be used only locally, while someof them allow changes to be initiated from a remote location; in the latter case, IPsec is used to protect the relevant signalling messages. However, the current specifications are partially obscure about the actual authorization requirements that must be met in order to be actually secure. The purpose of this document is to clarify the situation, and foster understanding of the potential attacks and required countermeasures. In this document, we first collect together and summarize the non-routing-protocol mechanisms that allow routing information to be changed. After that, we classify the mechanisms using a couple of orthogonal dimensions. Finally, we discuss the authorization requirements for the different mechanisms. It is important to note that the security problems discussed in this document become relevant only when we start to consider multiple security domains. As long as the mechanisms are used only within a single security domain, where all nodes are equally trusted, the problem does not exist. However, if several security domains are connected together, or if anything like "opportunistic IPsec", as promoted by John Gilmore, becomes reality, the problems discussed in this document will become very real. An other way of expressing the scope of the problems is to say that the attacks can be characterized as insider attacks. In general, the IPsec architecture, as it stands today, is relatively good in keeping outsiders out. However, it is currently not nearly as good at dealing with attacks from within. In a way, when IPsec is used to protect application level traffic, the applications are assumed to take care of their specific protection needs, e.g., in the form of user names, passwords, and application or operating system access control lists. Unfortunately, when IPsec is used to protect traffic signalling, as discussed in this document, the controls do not seem to be adequate. Basically, this is an authorization problem. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 23 12:24:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) id f1NKNIS26693 for ipng-dist; Fri, 23 Feb 2001 12:23:18 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) with ESMTP id f1NKN7G26686 for ; Fri, 23 Feb 2001 12:23:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24046 for ; Fri, 23 Feb 2001 12:23:07 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16824 for ; Fri, 23 Feb 2001 12:23:06 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA16987; Fri, 23 Feb 2001 15:23:02 -0500 (EST) Message-Id: <200102232023.PAA16987@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: ipng@sunroof.eng.sun.com Subject: 6overNAT draft cc: moore@cs.utk.edu From: Keith Moore Date: Fri, 23 Feb 2001 15:23:02 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I've just submitted my first draft of "6 over NAT" to the Internet-Drafts folks, using the name draft-moore-6overNAT-00.txt. Especially since it proposes a somewhat odd use of Neighbor Discovery I would appreciate it if it were reviewed by members of this group (whether formally by the group or informally by individuals) folks who don't want to wait until it comes out via normal channels may download it from http://www.cs.utk.edu/~moore/draft-moore-6overNAT-00.txt thanks! Keith Running IPv6 over a (potentially-NATted) IPv4 Network Abstract This document describes a protocol (dubbed "6overNAT") for deploying IP version 6 over a network which supports IP version 4 but cannot (yet) natively support IP version 6. The target network may be separated from the public Internet by one or more network address translators (NATs), and the target network may itself contain NATs. This protocol is intended to allow IPv6-capable hosts on the private network to be assigned globally unique and routable IPv6 addresses, and to allow those hosts to exchange traffic with IPv6 hosts on the public IPv6 Internet (or given suitable connections, on other private IPv6 networks), without intervening translation of IPv6 addresses. It is intended that this protocol should allow almost any IPv4-capable enterprise network to begin using IPv6 over that network for a small marginal cost and with little effort. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 24 04:37:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) id f1OCagm27182 for ipng-dist; Sat, 24 Feb 2001 04:36:42 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) with ESMTP id f1OCaVG27175 for ; Sat, 24 Feb 2001 04:36:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03479 for ; Sat, 24 Feb 2001 04:36:25 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA16144 for ; Sat, 24 Feb 2001 05:36:24 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id VAA24541; Sat, 24 Feb 2001 21:21:02 +0900 (JST) Date: Sat, 24 Feb 2001 20:22:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela Cc: ipng@sunroof.eng.sun.com Subject: Re: Address configuration questions (RFC2462) In-Reply-To: In your message of "Wed, 21 Feb 2001 14:52:55 +0200" <200102211252.OAA22260@burp.tkv.asdf.org> References: <200102191238.OAA20125@burp.tkv.asdf.org> <200102211252.OAA22260@burp.tkv.asdf.org> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000414(IM141) Lines: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 21 Feb 2001 14:52:55 +0200, >>>>> Markku Savela said: > I would like get clarification to section 5.5.3 (e): what is supposed > to happen with the preferred lifetime? Do the two hour checks apply to > it too? [if not, then DOS can force all addresses into deprecated > state]. I don't think so. Section 5.5.4. of RFC 2462 says A deprecated address SHOULD continue to be used as a source address in existing communications, but SHOULD NOT be used in new communications if an alternate (non-deprecated) address is available and has sufficient scope. Thus, even if all addresses become deprecated, you can still use all the addresses as the source address for a new communication, because there's no other non-deprecated addresses. I admit the "two-hour" rule is not a complete solution against all types of DOS attack, though. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 24 06:41:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) id f1OEdmt27217 for ipng-dist; Sat, 24 Feb 2001 06:39:48 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) with ESMTP id f1OEddG27210 for ; Sat, 24 Feb 2001 06:39:39 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00362 for ; Sat, 24 Feb 2001 06:39:29 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17167 for ; Sat, 24 Feb 2001 06:39:28 -0800 (PST) Received: from jimfleming (as1b-229.chi.il.dial.anet.com [198.92.157.229]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id IAA06180; Sat, 24 Feb 2001 08:39:19 -0600 (CST) From: "Jim Fleming" To: "Keith Moore" , Subject: RE: 6overNAT draft Date: Sat, 24 Feb 2001 08:39:28 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200102232023.PAA16987@astro.cs.utk.edu> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What patent and/or intellectual property rights will ICANN and/or the ISOC be claiming based on this ? http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp 1:20 ARIZONA Jim Fleming http://www.DOT-Arizona.com http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Keith Moore Sent: Friday, February 23, 2001 2:23 PM To: ipng@sunroof.eng.sun.com Cc: moore@cs.utk.edu Subject: 6overNAT draft Folks, I've just submitted my first draft of "6 over NAT" to the Internet-Drafts folks, using the name draft-moore-6overNAT-00.txt. Especially since it proposes a somewhat odd use of Neighbor Discovery I would appreciate it if it were reviewed by members of this group (whether formally by the group or informally by individuals) folks who don't want to wait until it comes out via normal channels may download it from http://www.cs.utk.edu/~moore/draft-moore-6overNAT-00.txt thanks! Keith Running IPv6 over a (potentially-NATted) IPv4 Network Abstract This document describes a protocol (dubbed "6overNAT") for deploying IP version 6 over a network which supports IP version 4 but cannot (yet) natively support IP version 6. The target network may be separated from the public Internet by one or more network address translators (NATs), and the target network may itself contain NATs. This protocol is intended to allow IPv6-capable hosts on the private network to be assigned globally unique and routable IPv6 addresses, and to allow those hosts to exchange traffic with IPv6 hosts on the public IPv6 Internet (or given suitable connections, on other private IPv6 networks), without intervening translation of IPv6 addresses. It is intended that this protocol should allow almost any IPv4-capable enterprise network to begin using IPv6 over that network for a small marginal cost and with little effort. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 26 08:53:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) id f1QEHEP27918 for ipng-dist; Mon, 26 Feb 2001 06:17:14 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) with ESMTP id f1QEGsG27911 for ; Mon, 26 Feb 2001 06:17:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06157 for ; Mon, 26 Feb 2001 06:16:28 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18508 for ; Mon, 26 Feb 2001 06:16:28 -0800 (PST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1QEGRg26600 for ; Mon, 26 Feb 2001 08:16:27 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 26 Feb 2001 08:16:27 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Mon, 26 Feb 2001 08:16:27 -0600 Message-ID: To: ipng@sunroof.eng.sun.com Subject: ND Router Advertisements using Unicast Date: Mon, 26 Feb 2001 08:16:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I cannot see any reason from ND spec why I would not be able to send out ND Router Advertisements to Clients using Unicast? Anyone disagree? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 26 08:55:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) id f1QEWiH27928 for ipng-dist; Mon, 26 Feb 2001 06:32:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) with ESMTP id f1QEVwG27921 for ; Mon, 26 Feb 2001 06:32:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07920 for ; Mon, 26 Feb 2001 06:31:27 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11773 for ; Mon, 26 Feb 2001 06:31:26 -0800 (PST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1QEVQg27846 for ; Mon, 26 Feb 2001 08:31:26 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 26 Feb 2001 08:31:16 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Mon, 26 Feb 2001 08:31:16 -0600 Message-ID: To: vlad@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Basic Socket Interface Extensions for IPv6 " Date: Mon, 26 Feb 2001 08:31:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Vlad, Yes it was removed at api-2553bis-00.txt so its been awhile. plus the default is not consensus anymore and getaddrinfo changed things and xnet took different path. I will remove the symbol. Good catch and thanks. /jim > -----Original Message----- > From: ext Vladislav Yasevich [mailto:vlad@zk3.dec.com] > Sent: Thursday,February 22,2001 4:24 PM > To: IPNG Working Group; Jim.Bound@nokia.com > Subject: Re: W.G. Last Call on "Basic Socket Interface Extensions for > IPv6" > > > Jim > > It appears that the definition of AI_DEFAULT has been removed > from the document. I am not sure if this was intentional or not. > If this was intentional, then I think that AI_DEFAULT symbol > should be removed from section 7. If this definition was > removed by mistake, it should probably be put back. > > -vlad > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Tel: (603) 884-1079 > Compaq Computer Corp. Fax: (435) 514-6884 > 110 Spit Brook Rd ZK03-3/T07 > Nashua, NH 03062 > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 26 13:03:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) id f1QIgE728144 for ipng-dist; Mon, 26 Feb 2001 10:42:14 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) with ESMTP id f1QIfxG28137 for ; Mon, 26 Feb 2001 10:42:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21959 for ; Mon, 26 Feb 2001 10:41:37 -0800 (PST) Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA10898 for ; Mon, 26 Feb 2001 10:41:35 -0800 (PST) Received: (cpmta 4159 invoked from network); 26 Feb 2001 10:41:34 -0800 Received: from unknown (HELO dellchan) (208.135.49.132) by smtp.francis.com (209.228.32.71) with SMTP; 26 Feb 2001 10:41:34 -0800 X-Sent: 26 Feb 2001 18:41:34 GMT Message-ID: <03ce01c0a023$b571af80$1300a8c0@smateo1.sfba.home.com> From: "Paul Francis" To: References: Subject: Near-Unique Site-Local Identifier draft Date: Mon, 26 Feb 2001 10:41:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've posted a draft on assigning random site-local identifiers at http://www.aciri.org/francis/draft-francis-ipngwg-unique-site-local-00.txt. This was submitted in time to make the Minn. ID deadline. Thanks, PF Abstract For many or most sites, site-local addresses are used for packets between nodes within the site. The fact that site-local addresses are not globally unique makes their usage and administration more difficult than they would be if there were globally unique (or nearly globally unique). For instance, before two sites can be merged, one of them has to be renumbered. The meaning of site-local addresses becomes ambiguous when they are taken out of the immediate context of the IPv6 layer, for instance when they are conveyed in email or stored in text files. All other things being equal, it would be preferable if the prefix of addresses with site-local scope were as globally unique as possible. This draft expands the format of the site-local address to allow them to be near-unique. It does not, however, change the definition or usage of the site-local address. This draft describes the format and assignment method of near-unique site-local prefixes. It also outlines some usage scenarios. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 26 13:03:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) id f1QIj2u28153 for ipng-dist; Mon, 26 Feb 2001 10:45:02 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3.Beta0+Sun/8.11.3.Beta0) with ESMTP id f1QIhpG28146 for ; Mon, 26 Feb 2001 10:44:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28315 for ; Mon, 26 Feb 2001 10:43:29 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05815 for ; Mon, 26 Feb 2001 11:43:19 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA11814; Mon, 26 Feb 2001 10:43:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f1QIhFx06180; Mon, 26 Feb 2001 10:43:15 -0800 X-mProtect: Mon, 26 Feb 2001 10:43:15 -0800 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdFRWIoI; Mon, 26 Feb 2001 10:43:06 PST Message-ID: <3A9AA3BD.B98613DD@Kniveton.com> Date: Mon, 26 Feb 2001 10:43:09 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jim.Bound@nokia.com CC: ipng@sunroof.eng.sun.com Subject: Re: ND Router Advertisements using Unicast References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim.Bound@nokia.com wrote: > > Folks, > > I cannot see any reason from ND spec why I would not be able to send out ND > Router Advertisements to Clients using Unicast? Sure you can send them, just make sure the target client is on the same link, or they will be silently discarded when TTL<255. > > Anyone disagree? > > thanks > /jim > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- T.J. Kniveton NOKIA Research -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 27 03:53:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) id f1RBqgg28853 for ipng-dist; Tue, 27 Feb 2001 03:52:42 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) with ESMTP id f1RBqVw28846 for ; Tue, 27 Feb 2001 03:52:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13633 for ; Tue, 27 Feb 2001 03:52:30 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02652 for ; Tue, 27 Feb 2001 03:52:30 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04053; Tue, 27 Feb 2001 06:52:29 -0500 (EST) Message-Id: <200102271152.GAA04053@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-vida-mld-v2-00.txt Date: Tue, 27 Feb 2001 06:52:29 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multicast Listener Discovery Version 2 (MLDv2) for IPv6 Author(s) : R. Vida et al. Filename : draft-vida-mld-v2-00.txt Pages : 48 Date : 26-Feb-01 This document specifies Version 2 of the Multicast Listener Discovery protocol, MLDv2. MLD is the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vida-mld-v2-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-vida-mld-v2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vida-mld-v2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010226143442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vida-mld-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-vida-mld-v2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010226143442.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 27 08:31:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) id f1RGTfC29093 for ipng-dist; Tue, 27 Feb 2001 08:29:41 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) with ESMTP id f1RGTWw29086 for ; Tue, 27 Feb 2001 08:29:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13831 for ; Tue, 27 Feb 2001 08:29:32 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03122 for ; Tue, 27 Feb 2001 08:29:27 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA08471; Tue, 27 Feb 2001 08:29:26 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f1RGTMB23795; Tue, 27 Feb 2001 08:29:22 -0800 X-mProtect: Tue, 27 Feb 2001 08:29:22 -0800 Nokia Silicon Valley Messaging Protection Received: from Ihinden-4.iprg.nokia.com (205.226.22.77, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdD9JCbs; Tue, 27 Feb 2001 07:39:09 PST Message-Id: <4.3.2.7.2.20010227073317.02358588@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Feb 2001 07:35:22 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "Unicast-Prefix-based IPv6 Multicast Addresses" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : Unicast-Prefix-based IPv6 Multicast Addresses Author(s) : B. Haberman, D. Thaler Filename : draft-ietf-ipngwg-uni-based-mcast-01.txt Pages : 5 Date : 26-Jan-01 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on March 13, 2001. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 27 09:35:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) id f1RHYgE29119 for ipng-dist; Tue, 27 Feb 2001 09:34:42 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) with ESMTP id f1RHYWw29112 for ; Tue, 27 Feb 2001 09:34:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28504 for ; Tue, 27 Feb 2001 09:34:33 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09744 for ; Tue, 27 Feb 2001 09:34:31 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 27 Feb 2001 09:18:04 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 27 Feb 2001 09:17:09 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 27 Feb 2001 09:17:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4653.0 content-class: urn:content-classes:message Subject: RE: Near-Unique Site-Local Identifier draft MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Feb 2001 09:16:08 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Near-Unique Site-Local Identifier draft Thread-Index: AcCgOHF93KL6ob0/STWjzMJKrh7JswAAftsg From: "Christian Huitema" To: "Paul Francis" , X-OriginalArrivalTime: 27 Feb 2001 17:17:04.0967 (UTC) FILETIME=[1B21F570:01C0A0E1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f1RHYXw29113 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You wrote: The probability of a duplicate assignment somewhere is N^2/2^38... which is not quite correct. The probability of at least one duplicate out of N assignments out of a space of size X is P = 1 - product(1..N)(1-(i-1)/X) Which is a bit hard to compute, and certainly does not result in N^2/X. Using a log approximation, you get Log (1-P) = sigma(1..N) log (1 - (i-1)/X) = sigma(1..N)(-(i-1)/X) + 0(N^3/X^2) Thus (1-P) ~= e^-(N.N-1/2.X) ~= e^-(N^2/2.X) P ~= 1 - e^-(N^2/2.X) if N^3 << X^2 I would suggest you correct your phrase to be a bit less assertive, something like "The probability of a duplicate assignment somewhere becomes significant is N^2 becomes close to 2^38" -- or just mention the birthday paradox. > -----Original Message----- > From: Paul Francis [mailto:paul@francis.com] > Sent: Monday, February 26, 2001 10:41 AM > To: ipng@sunroof.eng.sun.com > Subject: Near-Unique Site-Local Identifier draft > > > > I've posted a draft on assigning random site-local > identifiers at > http://www.aciri.org/francis/draft-francis-ipngwg-unique-site- > local-00.txt. > > This was submitted in time to make the Minn. ID deadline. > > Thanks, > > PF > > Abstract > > For many or most sites, site-local addresses are used for packets > between nodes within the site. The fact that site-local addresses > are not globally unique makes their usage and administration more > difficult than they would be if there were globally unique (or > nearly globally unique). For instance, before two sites can be > merged, one of them has to be renumbered. The meaning of > site-local > addresses becomes ambiguous when they are taken out of the > immediate > context of the IPv6 layer, for instance when they are conveyed in > email or stored in text files. > > All other things being equal, it would be preferable if the prefix > of addresses with site-local scope were as globally unique as > possible. This draft expands the format of the site-local address > to allow them to be near-unique. It does not, however, change the > definition or usage of the site-local address. This draft > describes > the format and assignment method of near-unique site-local > prefixes. > It also outlines some usage scenarios. > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 27 09:56:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) id f1RHt5w29151 for ipng-dist; Tue, 27 Feb 2001 09:55:05 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) with ESMTP id f1RHt0w29144 for ; Tue, 27 Feb 2001 09:55:00 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f1RHqTG22790 for ipng@sunroof.eng.sun.com; Tue, 27 Feb 2001 09:52:29 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1JJ8Q205151 for ; Mon, 19 Feb 2001 11:08:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07715 for ; Mon, 19 Feb 2001 11:08:26 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20070 for ; Mon, 19 Feb 2001 11:08:25 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA00439; Mon, 19 Feb 2001 11:08:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f1JJ8LS25860; Mon, 19 Feb 2001 11:08:21 -0800 X-mProtect: Mon, 19 Feb 2001 11:08:21 -0800 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdpqfzmf; Mon, 19 Feb 2001 11:08:09 PST Message-ID: <3A916F1C.B086EAAB@Nokia.com> Date: Mon, 19 Feb 2001 11:08:12 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mattias Pettersson CC: "Powell, Ken" , mobile-ip@marvin.corpeast.baynetworks.com, ipng@sunroof.eng.sun.com Subject: Re: New idea for Router Sol/Adv and Mobility - NO new types References: <3A90EF17.C7114389@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mattias Pettersson wrote: > > "Powell, Ken" wrote: > > > I suppose another option would be to add a > > "request aggregate prefix list" flag bit to > > the router solicitation message. Such a flag > > bit would be easier to implement in that > > it would only impact the part of the stack > > that deals with router solicitation/advertisement > > processing. > > > > What do others prefer? > > I prefer this new RS type. > > If the HA needs to know what home _link_ is in question, in case there > are more than one, it can use the destination address of the RS. Thus, > one fewer purpose for the home address option. > Let me play devil's advocate: No new types are required! What we're sending is still a Router Solicitation/Advertisement. The fact that it is routed gives us more information: 1. The TTL of RS is < 255, which tells the HA it is from off-link. 2. The HA knows that (1) means it is a mobile node and needs all prefixes on the link. 3. It sends a regular (HA) RA, and adds prefix options for every prefix on the link 4. The TTL of the RA is < 255, which tells the MN it is from off-link. 5. The MN knows that (4) means it is a HA-generated RA and applies to its home address(es) There is no need to create a new type, when we are simply allowing a superset of normal RS/RA behavior. Consider the following: A. If router solicitations are extended to allow off-link RSs, the RSs for mobile nodes would be totally compatible and "make sense". B. If RAs are extended as well, these mobile RAs would also make sense These messages will only ever be shared between MN & HA, who will both understand what they mean. Nevertheless, the point of (A) & (B) is that these messages are globally consistent and do not conflict with other possible extensions. It makes more sense to think of these messages as router advertisements and solicitations -- that's really what they are, extended to handle mobility. If the goal of Mobile IP is to modify/enhance existing protocols as little as possible to support mobility, adding message types when it's not necessary is the wrong thing to do. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 27 09:56:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) id f1RHtYe29160 for ipng-dist; Tue, 27 Feb 2001 09:55:34 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) with ESMTP id f1RHtRw29153 for ; Tue, 27 Feb 2001 09:55:27 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f1RHqua22820 for ipng@sunroof.eng.sun.com; Tue, 27 Feb 2001 09:52:56 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f1LKLN221588 for ; Wed, 21 Feb 2001 12:21:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04342 for ; Wed, 21 Feb 2001 12:21:22 -0800 (PST) Received: from titan.bieringer.de ([195.226.187.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA02961 for ; Wed, 21 Feb 2001 13:21:17 -0700 (MST) Received: (qmail 26274 invoked from network); 21 Feb 2001 20:21:10 -0000 Received: from p3ee29460.dip.t-dialin.net (HELO worker.bieringer.de) (62.226.148.96) by mail.bieringer.de with SMTP; 21 Feb 2001 20:21:10 -0000 Message-Id: <5.0.2.1.0.20010221211316.01ae7830@mail.bieringer.de> X-Sender: list4peter@mail.bieringer.de X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 21 Feb 2001 21:22:42 +0100 To: Dave Marquardt , Niveda Monyvannan From: Peter Bieringer Subject: Re: Clarification in Tunnel Cc: users@ipv6.org, ipng@sunroof.eng.sun.com In-Reply-To: <20010221095200.F156881@hogwart> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 16:52 21.02.2001, Dave Marquardt wrote: >On Tue, Feb 20, 2001 at 03:48:37PM +0530, Niveda Monyvannan wrote: > > Should configured tunnel always be a duplex one? > >Are you talking about tunneling IPv6 over IPv4? I don't think you >need to have a duplex tunnel. Try considering the tunnel "interface" >to be transmit only, i.e. half duplex. The tunneling RFCs (2893 and >2473) treat tunneling as an encapsulation mechanism and decapsulation >is just "normal" protocol operation. So I would say, no, you don't >need to have a full duplex tunnel. > > > A-------------B========C--------------------D > > > > Let us say B is configured to encaptulate v6 packet to C. Should C have > > a configured tunnel interface towards B to receive a encaptulated > > packets from B? > >No, I don't think so. Hmm, but C have to know about the IPv6 network between A and B and must route/tunnel such (response from D) packets to IPv4-B back again. >One thing this made me wonder about, though. Let's say we have your >ABCD scenario above: > > A-------------B========C--------------------D > >C is a router. All nodes have IPv6 addresses, call them A6, B6, C6, >and D6. B and C have IPv4 addresses, B4 and C4. Is it "legal" to >configure a tunnel from B to D by using B4 as the local IPv4 address >and C4 as the remote address, and configuring the local IPv6 address >as B6 and the remote IPv6 address as D6? Why would you setup D6 on C? What is the reason for that? > Packets to D would get >encapsulated at B in an IPv4 packet with B4 as source and C4 as >destination. When the packet reached C, it would be decapsulated. >Since C is a router, it would forward the packet on to D. Is this >allowed? It's confusing, but I don't see why it wouldn't work. Perhaps it's better to clarify such szenarios using unnumbered tunnels first (for routing/tunneling issues this is enough IMHO). On Linux using NBMA tunnels are the IMHO easiest method to setup tunneling. Only needed information for tunnel: IPv6 network of destination and IPv4 of tunnel endpoint, e.g. C must know about IPv6net(A-B) and IPv4(B) B must know about IPv6net(C-D) and IPv4(C) That's all Setup on Linux: route -A inet6 add $IPv6net(foreign) gw ::$IPv4(foreign tunnel) dev sit0 Perhaps on Solaris the same way can be done. Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 27 12:16:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) id f1RKE3r29436 for ipng-dist; Tue, 27 Feb 2001 12:14:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) with ESMTP id f1RKDpw29429 for ; Tue, 27 Feb 2001 12:13:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00433 for ; Tue, 27 Feb 2001 12:13:51 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20140 for ; Tue, 27 Feb 2001 12:13:49 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f1RKDld03097 for ; Tue, 27 Feb 2001 21:13:47 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Feb 27 21:15:13 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 27 Feb 2001 21:10:02 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBA3@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'T.J. Kniveton'" Cc: "Mattias Pettersson (ERA)" , "Powell, Ken" , "'mobile-ip@standards.nortelnetworks.com'" , ipng@sunroof.eng.sun.com Subject: RE: New idea for Router Sol/Adv and Mobility - NO new types Date: Tue, 27 Feb 2001 21:13:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I suppose another option would be to add a > > > "request aggregate prefix list" flag bit to > > > the router solicitation message. Such a flag > > > bit would be easier to implement in that > > > it would only impact the part of the stack > > > that deals with router solicitation/advertisement > > > processing. > > > > > > What do others prefer? > > > > I prefer this new RS type. > > > > If the HA needs to know what home _link_ is in question, in case there > > are more than one, it can use the destination address of the RS. Thus, > > one fewer purpose for the home address option. > > > > Let me play devil's advocate: > > No new types are required! What we're sending is still a Router > Solicitation/Advertisement. The fact that it is routed gives us more > information: > > 1. The TTL of RS is < 255, which tells the HA it is from off-link. > 2. The HA knows that (1) means it is a mobile node and needs all > prefixes on the link. > > => I don't think that's a good assumption. There is no need to > guess when you can be sure of the purpose of the message. > > > It makes more sense to think of these messages as router advertisements > and solicitations -- that's really what they are, extended to handle > mobility. If the goal of Mobile IP is to modify/enhance existing > protocols as little as possible to support mobility, adding message > types when it's not necessary is the wrong thing to do. > > => I don't think having a new type is wrong. This is a "differentl" > use of the rtr sol/adv messages and that's what a type means. > So I'm not sure that it is worth arguing against it, since it's > such a minor addition. > > -- > T.J. Kniveton > NOKIA Research Center > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 27 12:42:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) id f1RKevA29455 for ipng-dist; Tue, 27 Feb 2001 12:40:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) with ESMTP id f1RKecw29448 for ; Tue, 27 Feb 2001 12:40:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22432 for ; Tue, 27 Feb 2001 12:40:38 -0800 (PST) Received: from mail.korea.ac.kr (korea.ac.kr [163.152.1.251]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04985 for ; Tue, 27 Feb 2001 12:40:37 -0800 (PST) Received: from smart (smtp.korea.ac.kr [163.152.1.10]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id FAA178114; Wed, 28 Feb 2001 05:30:26 +0900 Received: from zrchh190 by smtprch2.nortel.com; Tue, 27 Feb 2001 14:22:09 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Tue, 27 Feb 2001 14:26:33 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id PAA06934 for ; Tue, 27 Feb 2001 15:16:51 -0500 (EST) Received: from 47.234.0.32 (actually ertpsms2.internet.nortel.com) by zrtps06t; Tue, 27 Feb 2001 15:15:56 -0500 Received: from penguin-ext.wise.edt.ericsson.se ( [194.237.142.110]) by with SMTP (MailShield v1.5); Tue, 27 Feb 2001 15:17:32 -0500 Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f1RKDld03101 for ; Tue, 27 Feb 2001 21:13:47 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Feb 27 21:15:13 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 27 Feb 2001 21:10:02 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBA3@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'T.J. Kniveton'" Cc: "Mattias Pettersson (ERA)" , "Powell, Ken" , mobile-ip@marvin.corpeast.baynetworks.com, ipng@sunroof.eng.sun.com Subject: RE: New idea for Router Sol/Adv and Mobility - NO new types Date: Tue, 27 Feb 2001 21:13:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se X-SMTP-MAIL-FROM: Hesham.Soliman@era.ericsson.se X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [194.237.142.110] X-Orig: X-Orig: X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I suppose another option would be to add a > > > "request aggregate prefix list" flag bit to > > > the router solicitation message. Such a flag > > > bit would be easier to implement in that > > > it would only impact the part of the stack > > > that deals with router solicitation/advertisement > > > processing. > > > > > > What do others prefer? > > > > I prefer this new RS type. > > > > If the HA needs to know what home _link_ is in question, in case there > > are more than one, it can use the destination address of the RS. Thus, > > one fewer purpose for the home address option. > > > > Let me play devil's advocate: > > No new types are required! What we're sending is still a Router > Solicitation/Advertisement. The fact that it is routed gives us more > information: > > 1. The TTL of RS is < 255, which tells the HA it is from off-link. > 2. The HA knows that (1) means it is a mobile node and needs all > prefixes on the link. > > => I don't think that's a good assumption. There is no need to > guess when you can be sure of the purpose of the message. > > > It makes more sense to think of these messages as router advertisements > and solicitations -- that's really what they are, extended to handle > mobility. If the goal of Mobile IP is to modify/enhance existing > protocols as little as possible to support mobility, adding message > types when it's not necessary is the wrong thing to do. > > => I don't think having a new type is wrong. This is a "differentl" > use of the rtr sol/adv messages and that's what a type means. > So I'm not sure that it is worth arguing against it, since it's > such a minor addition. > > -- > T.J. Kniveton > NOKIA Research Center > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 27 12:51:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) id f1RKnTq29684 for ipng-dist; Tue, 27 Feb 2001 12:49:29 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3.Beta1+Sun/8.11.3.Beta1) with ESMTP id f1RKnBw29677 for ; Tue, 27 Feb 2001 12:49:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23716 for ; Tue, 27 Feb 2001 12:49:11 -0800 (PST) Received: from mail.korea.ac.kr (korea.ac.kr [163.152.1.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24605 for ; Tue, 27 Feb 2001 12:49:05 -0800 (PST) Received: from smart (smtp.korea.ac.kr [163.152.1.10]) by mail.korea.ac.kr (8.8.8H1/8.8.8) with SMTP id FAA168696; Wed, 28 Feb 2001 05:39:01 +0900 Received: from zrchh190 by smtprch2.nortel.com; Tue, 27 Feb 2001 14:26:33 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Tue, 27 Feb 2001 14:29:14 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id PAA06934 for ; Tue, 27 Feb 2001 15:16:51 -0500 (EST) Received: from 47.234.0.32 (actually ertpsms2.internet.nortel.com) by zrtps06t; Tue, 27 Feb 2001 15:15:56 -0500 Received: from penguin-ext.wise.edt.ericsson.se ( [194.237.142.110]) by with SMTP (MailShield v1.5); Tue, 27 Feb 2001 15:17:32 -0500 Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f1RKDld03101 for ; Tue, 27 Feb 2001 21:13:47 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Feb 27 21:15:13 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 27 Feb 2001 21:10:02 +0100 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBBA3@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'T.J. Kniveton'" Cc: "Mattias Pettersson (ERA)" , "Powell, Ken" , mobile-ip@marvin.corpeast.baynetworks.com, ipng@sunroof.eng.sun.com Subject: RE: New idea for Router Sol/Adv and Mobility - NO new types Date: Tue, 27 Feb 2001 21:13:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain X-SMTP-HELO: penguin-ext.wise.edt.ericsson.se X-SMTP-MAIL-FROM: Hesham.Soliman@era.ericsson.se X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [194.237.142.110] X-Orig: X-Orig: X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I suppose another option would be to add a > > > "request aggregate prefix list" flag bit to > > > the router solicitation message. Such a flag > > > bit would be easier to implement in that > > > it would only impact the part of the stack > > > that deals with router solicitation/advertisement > > > processing. > > > > > > What do others prefer? > > > > I prefer this new RS type. > > > > If the HA needs to know what home _link_ is in question, in case there > > are more than one, it can use the destination address of the RS. Thus, > > one fewer purpose for the home address option. > > > > Let me play devil's advocate: > > No new types are required! What we're sending is still a Router > Solicitation/Advertisement. The fact that it is routed gives us more > information: > > 1. The TTL of RS is < 255, which tells the HA it is from off-link. > 2. The HA knows that (1) means it is a mobile node and needs all > prefixes on the link. > > => I don't think that's a good assumption. There is no need to > guess when you can be sure of the purpose of the message. > > > It makes more sense to think of these messages as router advertisements > and solicitations -- that's really what they are, extended to handle > mobility. If the goal of Mobile IP is to modify/enhance existing > protocols as little as possible to support mobility, adding message > types when it's not necessary is the wrong thing to do. > > => I don't think having a new type is wrong. This is a "differentl" > use of the rtr sol/adv messages and that's what a type means. > So I'm not sure that it is worth arguing against it, since it's > such a minor addition. > > -- > T.J. Kniveton > NOKIA Research Center > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 27 17:21:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f1S1K2v00297 for ipng-dist; Tue, 27 Feb 2001 17:20:02 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f1S1JqE00290 for ; Tue, 27 Feb 2001 17:19:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00281 for ; Tue, 27 Feb 2001 17:19:53 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar3-182-130.dsl.gtei.net [4.33.182.130]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA16804; Tue, 27 Feb 2001 17:19:50 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 27 Feb 2001 17:19:48 -0800 Received: from eagleswings [4.33.178.101] by smtp.tndh.net [4.33.182.130] (SLmail 3.2.3113) with SMTP id E3CF3C94547A44DD814E766913CF8CE3 for plus 3 more; Tue, 27 Feb 2001 17:19:48 -0800 Reply-To: From: "Tony Hain" To: "Dave Marquardt" , "Niveda Monyvannan" Cc: , Subject: RE: Clarification in Tunnel Date: Tue, 27 Feb 2001 17:19:47 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <20010221095200.F156881@hogwart> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-SLUIDL: A003D080-66474798-9F067AD7-EAB73821 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Marquardt wrote: > One thing this made me wonder about, though. Let's say we have your > ABCD scenario above: > > A-------------B========C--------------------D > > C is a router. All nodes have IPv6 addresses, call them A6, B6, C6, > and D6. B and C have IPv4 addresses, B4 and C4. Is it "legal" to > configure a tunnel from B to D by using B4 as the local IPv4 address > and C4 as the remote address, and configuring the local IPv6 address > as B6 and the remote IPv6 address as D6? Packets to D would get > encapsulated at B in an IPv4 packet with B4 as source and C4 as > destination. When the packet reached C, it would be decapsulated. > Since C is a router, it would forward the packet on to D. Is this > allowed? It's confusing, but I don't see why it wouldn't work. The confusing part is asking about the tunnel as being from B to D. The tunnel in your example would be from B to C, with the traffic flow between B and D. This is legal, and is the basic premise for the 6to4 router as defined in rfc3056. While 6to4 does this with implicit tunnels, there is no operational difference between that and a configured tunnel between routers. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 27 19:13:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f1S3CUi00388 for ipng-dist; Tue, 27 Feb 2001 19:12:30 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f1S3CJE00381 for ; Tue, 27 Feb 2001 19:12:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13143 for ; Tue, 27 Feb 2001 19:12:19 -0800 (PST) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19295 for ; Tue, 27 Feb 2001 19:12:18 -0800 (PST) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.20 #3) id 14Xx2H-0004ua-00 for ipng@sunroof.eng.sun.com; Tue, 27 Feb 2001 22:12:17 -0500 Date: Tue, 27 Feb 2001 22:12:17 -0500 (EST) From: Nathan Lutchansky To: ipng mailing list Subject: Draft of intro document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I've written up a short introductory document for IPv6 to introduce the seasoned network admin/programmer to the wonderful world of IPv6. It's fairly technical, but I think I've covered everything important. I would appreciate if I could get some feedback on it from people who are more familiar with the protocol. I'm hoping it will be a good resource for those interested in learning about IPv6, so I'd like to be fairly certain of its accuracy. :-) http://v6web.litech.org/ipv6primer/ Please don't post this URL anywhere until people here have had a chance to send me comments. After that, it's pretty much free to distribute. Thanks! -Nathan -- +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 28 00:41:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f1S8eFR00645 for ipng-dist; Wed, 28 Feb 2001 00:40:15 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f1S8e5E00638 for ; Wed, 28 Feb 2001 00:40:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA02327 for ; Wed, 28 Feb 2001 00:40:06 -0800 (PST) Received: from pkgate.yokogawa.co.jp (pkgate.yokogawa.co.jp [210.135.206.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA02675 for ; Wed, 28 Feb 2001 00:40:04 -0800 (PST) Received: from nara.yokogawa.co.jp (nara.mitaka.yokogawa.co.jp [10.0.9.132]) by pkgate.yokogawa.co.jp (8.9.1/3.5Wpl5:001218) with ESMTP id RAA20340 for ; Wed, 28 Feb 2001 17:40:03 +0900 (JST) Received: from nara.yokogawa.co.jp (localhost [127.0.0.1]) by nara.yokogawa.co.jp (8.9.3/3.7W:010213) with ESMTP id RAA03536 for ; Wed, 28 Feb 2001 17:40:03 +0900 Received: from hiwa.mitaka.yokogawa.co.jp (root@hiwa.mitaka.yokogawa.co.jp [133.140.145.16]) by nara.yokogawa.co.jp (8.9.3/3.7W:010213) with ESMTP id RAA03530 for ; Wed, 28 Feb 2001 17:40:03 +0900 Received: from localhost (hosta.mitaka.yokogawa.co.jp [10.0.49.53]) by hiwa.mitaka.yokogawa.co.jp (8.8.5/3.5Wpl5:991215) with ESMTP id SAA16911 for ; Wed, 28 Feb 2001 18:06:55 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: RE: Redirect ICMP and TAHI test? From: OKABE Nobuo In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA8022560B6@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA8022560B6@red-msg-06.redmond.corp.microsoft.com> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010228174149S.nov@tahi.org> Date: Wed, 28 Feb 2001 17:41:49 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 45 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm examining the subject. From: Markku Savela Subject: Redirect ICMP and TAHI test? Date: Mon, 19 Feb 2001 14:38:06 +0200 > In TAHI Neighbor Discovery test 62, it introduces two routers, then > sends a redirect from "one" of them, and expects the redirect to have > an effect... He reported to me that his problem had come from not the tests but elsewhere. However, he also pointed out potential bugs of the tests: ncStateByRedirect4Nonce.seq ncStateByRedirect4Incomplete.seq ncStateByRedirect4Reachable.seq ncStateByRedirect4Stale.seq ncStateByRedirect4Probe.seq Those tests assumes that - a NUT does not have round-robin fashion in the default router selection. - a NUT selects a same router as the default. - a NUT selects the router whose RA comes first becomes the default router. In other word, some of the assumptions are broken, the tests may be failed. From: "Richard Draves" Subject: RE: Redirect ICMP and TAHI test? Date: Mon, 19 Feb 2001 08:25:44 -0800 > Yes, the Redirect TAHI tests fail on the MS implementation, for the same > reason. I think the test is broken. I guess that one of the above assumptions is broken in the case of MS implementation. This one always update the default router when accepting RA. I will be able to debug/fix the test if I have an implementation that behaves the same. Thank you for your feedback, again. --- nobuo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 28 06:38:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) id f1SEZBE00967 for ipng-dist; Wed, 28 Feb 2001 06:35:11 -0800 (PST) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f1SEYvE00960 for ; Wed, 28 Feb 2001 06:34:58 -0800 (PST) Received: from lillen (gbl-dhcp-212-200 [129.157.212.200]) by bebop.France.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA19974; Wed, 28 Feb 2001 15:33:50 +0100 (MET) Date: Wed, 28 Feb 2001 15:32:48 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: New idea for Router Sol/Adv and Mobility - NO new types To: "T.J. Kniveton" Cc: Mattias Pettersson , "Powell, Ken" , mobile-ip@marvin.corpeast.baynetworks.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3A916F1C.B086EAAB@Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Let me play devil's advocate: > > No new types are required! What we're sending is still a Router > Solicitation/Advertisement. The fact that it is routed gives us more > information: Excessive overloading of semantics might not be the best solution. So let me play the reverse devil's advocate and say: The cost of adding two new ICMP types is close to zero and it provides more clarity since the semantics of a regular RA/RS and an RA/RS to/from a mobile node will be different. Also, this clarity helps talking about the mobile node which will receive RAs from the routers on the visited link, and messages from its home agent(s). So what is wrong with adding new types? > 1. The TTL of RS is < 255, which tells the HA it is from off-link. Or a spoofed RS. When a router receives a spoofed RS it would presumbly log an event and/or increase a counter. With your overloading proposal it can't tell the difference between a spoofed one and a mobile node using an RA. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------