From owner-ipng@sunroof.eng.sun.com Thu Jul 1 04:03:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA02204 for ipng-dist; Thu, 1 Jul 1999 03:59:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02197 for ; Thu, 1 Jul 1999 03:59:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA22768 for ; Thu, 1 Jul 1999 03:59:36 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA26374 for ; Thu, 1 Jul 1999 03:59:35 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id UAA18619 for ; Thu, 1 Jul 1999 20:59:33 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Thu, 1 Jul 1999 20:59:33 +1000 (EST) From: Peter Tattam To: IPNG Mailing List Subject: ND for link-local addresses on multi-homed hosts. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When trying to locate a known link-local address (for test purposes), I have had trouble with ND over a multi-homed (more than one interface) host. According to the ND specs, to find an address, one determines which interface the dest address belongs and then does a ND on either the host or the next hop. However for link-local addresses, no route will be found so the default route processing would take place. If a default gateway were available, the ND for the link-local address would appear on the wrong interface, and hence I'd never find the host. If no default gateway were to be found, either a default interface would be used or the dest would be unroutable. I believe to correct my code, I need to process link-local addresses in a special manner. For link-local addresses, I would bypass normal routing table lookups and go direct to the neighbor cache to look for the address to determine it's interface and link layer address. If the link-local address is already in the neighbor cache, then I know where it is and can use the address directly. If it is not, I would need to neighbor solicit all interfaces for the link local address and wait for the neighbor advertise before sending the packet. I would also have to defer filling in the source address until after the neighbor advertise arrived as I don't know which interface the link-local address is related to. This could also be hairy for higher level protocols that might want to know the source address before sending the packet... While I thought this was a pathological case, it may not necessarily be so for routers & tunnel servers. It gets worse when the only source address available for an interface is the link-local address. Is it a requirement that unknown link-local addresses be reachable on multi-homed hosts? Is my asessment correct or have I missed an important RFC on the subject. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 1 04:13:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA02246 for ipng-dist; Thu, 1 Jul 1999 04:10:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02239 for ; Thu, 1 Jul 1999 04:10:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA10002 for ; Thu, 1 Jul 1999 04:10:41 -0700 (PDT) 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 FAA11412 for ; Thu, 1 Jul 1999 05:10:40 -0600 (MDT) 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 UAA28552; Thu, 1 Jul 1999 20:10:22 +0900 (JST) To: Peter Tattam cc: IPNG Mailing List In-reply-to: peter's message of Thu, 01 Jul 1999 20:59:33 +1000. 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: ND for link-local addresses on multi-homed hosts. From: itojun@iijlab.net Date: Thu, 01 Jul 1999 20:10:22 +0900 Message-ID: <28550.930827422@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >When trying to locate a known link-local address (for test purposes), I have >had trouble with ND over a multi-homed (more than one interface) host. >According to the ND specs, to find an address, one determines which interface >the dest address belongs and then does a ND on either the host or the next hop. >However for link-local addresses, no route will be found so the default >route processing would take place. If a default gateway were available, the ND >for the link-local address would appear on the wrong interface, and hence I'd >never find the host. If no default gateway were to be found, either a default >interface would be used or the dest would be unroutable. I believe userland programs MUST specify outgoing interface by using advanced api, or sin6_scope_id (the behavior for latter one is rather vague on the document), for link-local addresses. Otherwise kernel cannot disambiguate it in multi-interface node case. Once the userland program specifies interface to go out, your problem (in kernel) is solved. 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 Jul 1 04:50:10 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA02282 for ipng-dist; Thu, 1 Jul 1999 04:47:22 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02275 for ; Thu, 1 Jul 1999 04:47:12 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA10920 for ; Thu, 1 Jul 1999 04:47:12 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA06837 for ; Thu, 1 Jul 1999 04:47:11 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26283; Thu, 1 Jul 1999 07:47:08 -0400 (EDT) Message-Id: <199907011147.HAA26283@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-jumbograms-01.txt Date: Thu, 01 Jul 1999 07:47:07 -0400 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 : IPv6 Jumbograms Author(s) : D. Borman, S. Deering, B. Hinden Filename : draft-ietf-ipngwg-jumbograms-01.txt Pages : 9 Date : 30-Jun-99 A 'jumbogram' is an IPv6 packet containing a payload longer than 65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-jumbograms-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-jumbograms-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-jumbograms-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: <19990630150021.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-jumbograms-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-jumbograms-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990630150021.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 Jul 1 07:51:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA02625 for ipng-dist; Thu, 1 Jul 1999 07:48:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02618 for ; Thu, 1 Jul 1999 07:48:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA24484 for ; Thu, 1 Jul 1999 07:48:25 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25860 for ; Thu, 1 Jul 1999 08:48:24 -0600 (MDT) Received: from [171.68.180.71] (sj-dial-3-70.cisco.com [171.68.180.71]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA01808; Thu, 1 Jul 1999 07:47:09 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <28550.930827422@coconut.itojun.org> References: <28550.930827422@coconut.itojun.org> Date: Thu, 1 Jul 1999 07:47:08 -0700 To: itojun@iijlab.net From: Steve Deering Subject: Re: ND for link-local addresses on multi-homed hosts. Cc: Peter Tattam , IPNG Mailing List Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:10 PM +0900 7/1/99, itojun@iijlab.net wrote: > I believe userland programs MUST specify outgoing interface by using > advanced api, or sin6_scope_id (the behavior for latter one is rather > vague on the document), for link-local addresses. Otherwise kernel > cannot disambiguate it in multi-interface node case. I would refine that a little bit to say: applications must provide a way for the user to specify the outgoing interface (regardless of scope of the destination address). It would be convenient for a system to have a notion of a "default" interface (e.g., the first non-loopback interface instantiated at boot time, overridable by a system configuration command), to be used as the outgoing interface for non-global destinations whenever the application does not specify one. This is how it has been handled for IP(v4) multicast, which also has the interface-selection problem when using non-global destination (multicast) addresses. 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 Thu Jul 1 10:46:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA03201 for ipng-dist; Thu, 1 Jul 1999 10:43:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03194 for ; Thu, 1 Jul 1999 10:43:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA25205 for ; Thu, 1 Jul 1999 10:43:16 -0700 (PDT) Received: from maredsous.monarch.cs.cmu.edu (MAREDSOUS.MONARCH.CS.CMU.EDU [128.2.250.149]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21024 for ; Thu, 1 Jul 1999 10:43:15 -0700 (PDT) Received: from maredsous.monarch.cs.cmu.edu (localhost [127.0.0.1]) by maredsous.monarch.cs.cmu.edu id NAA25460; Thu, 1 Jul 1999 13:49:15 -0400 (EDT) To: ipng@sunroof.eng.sun.com From: Dave Johnson Reply-To: Dave Johnson Subject: Revised Mobile IPv6 draft available Date: Thu, 01 Jul 1999 13:49:15 -0400 Message-ID: <25458.930851355@maredsous.monarch.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Friday of last week, I submitted a revised version of the Mobile IPv6 draft to fix and clear up some of the minor things pointed out at the last meeting and on the mailing list since. I sent an announcement of it to the Mobile IP mailing list then, but I forgot to include the IPng list in my announcement. Here is the list of changes since the previous version of the draft: - Changed the listed Option Type codes for the destination options and Type codes Router Advertisement options to their official values, now that IPv6 has finally officially assigned these. - Added a Router (R) bit in the Binding Update option format, for use in "home registration" Binding Updates. This flag bit tells the home agent that the mobile node is a router, so that the home agent can set the corresponding bit correctly in all proxy Neighbor Advertisements that it sends on behalf of this mobile node. Also added a bit to save this flag in the definition of the Binding Cache entry format, and defined how it is used in sending proxy Neighbor Advertisements. - Added a bit of text in a few places to clarify the meaning of MAX_UPDATE_RATE. - Added to Section 7.3 a requirement that every home agent SHOULD support a configuration mechanism to allow a system administrator to manually set the value to be sent by this home agent in the Home Agent Preference field of the Home Agent Information Option in Router Advertisements that it sends. - Added a suggestion in Section 6.4 that the Home Agent Preference field in a Home Agent Information option being sent by a home agent could be set dynamically by the sending home agent based on factors such as the number of mobile nodes it is currently serving or the remaining resources it has for serving additional mobile nodes. However, the details of such dynamic settings are beyond the scope of this document since they do not involve protocol standardization issues. - Normalized all references to the "Mobile IPv6 Home-Agents" anycast address to use the full name of this specific anycast address and to point to the new definition of reserved IPv6 subnet anycast addresses, RFC 2526. - Updated all references to their most recent versions, including changing old Internet-Draft references into new RFC references where available. Changed remaining specific Internet-Draft references to be generic "Work in progress" references. - Updated the "Status of This Memo" section to the new official version of this text. - Corrected a few minor typographical errors in places. This new version of the draft is draft-ietf-mobileip-ipv6-08.txt. I still haven't seen an official announcement of it on the IETF list, but I assume one will be posted sometime soon. For those who would like a copy of the draft now, a link to it is available on one of the CMU Monarch Project web pages at http://www.monarch.cs.cmu.edu/ietf.html or you can get a copy directly from the much longer URL http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-08.txt 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 Jul 1 11:10:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA03338 for ipng-dist; Thu, 1 Jul 1999 11:07:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03331 for ; Thu, 1 Jul 1999 11:07:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA00956 for ; Thu, 1 Jul 1999 11:07:05 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03191 for ; Thu, 1 Jul 1999 11:07:04 -0700 (PDT) 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 DAA05925; Fri, 2 Jul 1999 03:06:53 +0900 (JST) To: Dave Johnson cc: ipng@sunroof.eng.sun.com In-reply-to: dbj's message of Thu, 01 Jul 1999 13:49:15 -0400. <25458.930851355@maredsous.monarch.cs.cmu.edu> 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: Revised Mobile IPv6 draft available From: itojun@iijlab.net Date: Fri, 02 Jul 1999 03:06:53 +0900 Message-ID: <5923.930852413@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >On Friday of last week, I submitted a revised version of the Mobile IPv6 >draft to fix and clear up some of the minor things pointed out at the >last meeting and on the mailing list since. I sent an announcement of >it to the Mobile IP mailing list then, but I forgot to include the IPng >list in my announcement. Here is the list of changes since the >previous version of the draft: There were several questions arose for relationship of mobile-ipv6 and ipsec (in here, and ipsec mailing list). Do you have any plan to update that part? Without that update we can't make a complete implementation of mobile-ipv6 (with security considered). 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 Jul 1 11:26:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA03409 for ipng-dist; Thu, 1 Jul 1999 11:22:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03402 for ; Thu, 1 Jul 1999 11:22:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA00801 for ; Thu, 1 Jul 1999 11:22:10 -0700 (PDT) Received: from maredsous.monarch.cs.cmu.edu (MAREDSOUS.MONARCH.CS.CMU.EDU [128.2.250.149]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23154 for ; Thu, 1 Jul 1999 12:22:09 -0600 (MDT) Received: from maredsous.monarch.cs.cmu.edu (localhost [127.0.0.1]) by maredsous.monarch.cs.cmu.edu id OAA25579; Thu, 1 Jul 1999 14:27:48 -0400 (EDT) To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com In-Reply-To: Your message of "Fri, 02 Jul 1999 03:06:53 +0900" <5923.930852413@coconut.itojun.org> From: Dave Johnson Reply-To: Dave Johnson Subject: Re: Revised Mobile IPv6 draft available Date: Thu, 01 Jul 1999 14:27:48 -0400 Message-ID: <25577.930853668@maredsous.monarch.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>On Friday of last week, I submitted a revised version of the Mobile IPv6 >>draft to fix and clear up some of the minor things pointed out at the >>last meeting and on the mailing list since. I sent an announcement of >>it to the Mobile IP mailing list then, but I forgot to include the IPng >>list in my announcement. Here is the list of changes since the >>previous version of the draft: > > There were several questions arose for relationship of mobile-ipv6 > and ipsec (in here, and ipsec mailing list). Do you have any plan > to update that part? Without that update we can't make a complete > implementation of mobile-ipv6 (with security considered). > >itojun Yes, I believe that is the only remaining place where clarification is needed, although I haven't had enough time to read through all the IPsec documents myself enough times, and haven't had a chance to talk enough with IPsec experts about it, to really get the definitive text writtin into the draft for this. I hope to be able to talk with implementers and IPsec experts about this in Oslo. Will you be there? 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 Jul 1 11:31:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA03443 for ipng-dist; Thu, 1 Jul 1999 11:29:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03432 for ; Thu, 1 Jul 1999 11:29:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA12837 for ; Thu, 1 Jul 1999 11:29:21 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14459 for ; Thu, 1 Jul 1999 11:29:20 -0700 (PDT) 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 DAA06329; Fri, 2 Jul 1999 03:29:11 +0900 (JST) To: Dave Johnson cc: ipng@sunroof.eng.sun.com In-reply-to: dbj's message of Thu, 01 Jul 1999 14:27:48 -0400. <25577.930853668@maredsous.monarch.cs.cmu.edu> 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: Revised Mobile IPv6 draft available From: itojun@iijlab.net Date: Fri, 02 Jul 1999 03:29:11 +0900 Message-ID: <6327.930853751@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> There were several questions arose for relationship of mobile-ipv6 >> and ipsec (in here, and ipsec mailing list). Do you have any plan >> to update that part? Without that update we can't make a complete >> implementation of mobile-ipv6 (with security considered). >Yes, I believe that is the only remaining place where clarification is >needed, although I haven't had enough time to read through all the >IPsec documents myself enough times, and haven't had a chance to talk >enough with IPsec experts about it, to really get the definitive text >writtin into the draft for this. I hope to be able to talk with >implementers and IPsec experts about this in Oslo. Will you be there? Yes I will. 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 Jul 1 12:47:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA03649 for ipng-dist; Thu, 1 Jul 1999 12:44:45 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03642 for ; Thu, 1 Jul 1999 12:44:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA18790 for ; Thu, 1 Jul 1999 12:44:36 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA17545 for ; Thu, 1 Jul 1999 12:44:35 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Jul 1999 12:38:34 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2448.0) id <3CT775YB>; Thu, 1 Jul 1999 12:38:35 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515492@RED-MSG-50> From: Richard Draves To: "'itojun@iijlab.net'" , Peter Tattam , "'Steve Deering'" Cc: IPNG Mailing List Subject: RE: ND for link-local addresses on multi-homed hosts. Date: Thu, 1 Jul 1999 12:38:31 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This just changed in MSR IPv6 release 1.3. In previous releases, I was hard-core - to send to a link-local address, the application had to specify the outgoing interface. But this caused much confusion and inconvenience. In release 1.3, this is still the default behavior. But: - You can create routes for link-local addresses to specify what interface they should be on-link to. For example you can specify a default interface for link-local addresses with a route for fe80::/10, or you can be more specific if you wish. (The same goes for multicast destination addresses and ff00::/8.) - You can send to your own link-local addresses without specifying an outgoing interface. (If you are unfortunate enough to have non-unique link-local addresses, it will just pick one of the interfaces.) Or you can specify an outgoing interface and override this. 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 Thu Jul 1 21:02:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA04133 for ipng-dist; Thu, 1 Jul 1999 20:59:13 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04126 for ; Thu, 1 Jul 1999 20:59:03 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA377408; Thu, 1 Jul 1999 20:59:03 -0700 (PDT) Date: Thu, 1 Jul 1999 20:56:58 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND for link-local addresses on multi-homed hosts. To: Peter Tattam Cc: IPNG Mailing List 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 > If the link-local address is already in the neighbor cache, then I know where > it is and can use the address directly. > > If it is not, I would need to neighbor solicit all interfaces for the link > local address and wait for the neighbor advertise before sending the packet. That would work as long as the link-local addresses are unique across all links, which is true for the IEEE 802 family. But e.g. with PPP you can have the same (e.g. fe80::1) address appear on multiple interfaces. Thus you need to have the applications specify the interface id for this to work in general. 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 Jul 2 04:42:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA04546 for ipng-dist; Fri, 2 Jul 1999 04:39:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04539 for ; Fri, 2 Jul 1999 04:39:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA00684 for ; Fri, 2 Jul 1999 04:39:28 -0700 (PDT) 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 FAA06538 for ; Fri, 2 Jul 1999 05:39:27 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05230; Fri, 2 Jul 1999 07:39:24 -0400 (EDT) Message-Id: <199907021139.HAA05230@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-router-renum-09.txt Date: Fri, 02 Jul 1999 07:39:24 -0400 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 : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-09.txt Pages : 30 Date : 01-Jul-99 IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-09.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-router-renum-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-router-renum-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990701143734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-renum-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990701143734.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 Jul 2 04:42:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA04555 for ipng-dist; Fri, 2 Jul 1999 04:40:19 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04548 for ; Fri, 2 Jul 1999 04:40:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA09019 for ; Fri, 2 Jul 1999 04:40:08 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA11479 for ; Fri, 2 Jul 1999 04:40:07 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05264; Fri, 2 Jul 1999 07:40:04 -0400 (EDT) Message-Id: <199907021140.HAA05264@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-03.txt Date: Fri, 02 Jul 1999 07:40:03 -0400 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-03.txt Pages : 22 Date : 01-Jul-99 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-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-site-prefixes-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-site-prefixes-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: <19990701143749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-site-prefixes-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-site-prefixes-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990701143749.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 Jul 2 07:30:26 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA04772 for ipng-dist; Fri, 2 Jul 1999 07:27:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04765 for ; Fri, 2 Jul 1999 07:27:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA15023 for ; Fri, 2 Jul 1999 07:27:42 -0700 (PDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08330 for ; Fri, 2 Jul 1999 08:27:41 -0600 (MDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA23452; Fri, 2 Jul 1999 10:27:31 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA26794; Fri, 2 Jul 1999 10:27:34 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id KAA18510; Fri, 2 Jul 1999 10:27:32 -0400 (EDT) Message-Id: <199907021427.KAA18510@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Peter Tattam cc: ipng@sunroof.eng.sun.com Subject: Re: Other mechanisms for DNS server discovery. In-reply-to: Your message of "Wed, 23 Jun 1999 13:11:09 -0400." Date: Fri, 02 Jul 1999 10:27:31 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter Tattam writes: > In light of the fact that DNS is absolutely essential for a working > stack these days and that there are mechanisms built in to IPv6 for > automatic address and network configuration, is there any merit in > providing some sure fire way of seeding a DNS server list for a host > with a mechanism that is different from DHCP? Perhaps including it > in Router advertisements. You've hit on the generic topic of how does a client bootstrap itself into a sufficiently-configured node able to use the Internet. A WG is likely to be created that deals with this exact topic. There was a BOF in Minneapolis (see http://www.ietf.cnri.reston.va.us/proceedings/99mar/index.html and go section 2.3.10) and there will be another meeting in Oslo. A couple of drafts have also been produced for the Oslo meeting (draft-hattig-homenet-reqts-00.txt, and draft-guttman-nits-reqts-00.txt). There is also a mailing list: nits-request@merit.edu. The NITS effort should focus on both v4 and v6, since many of the issues (though not necessarily the solutions) are the same in both spaces. The overall goal is to make "plug-and-play" really work. One of the configurations of concern is a "home network" where there might not be a DHCP (or even DNS) server. Note that the term "home network" is a bit misleading, as the plug-and-play problem also applies to two laptops at the beach communicating over (say) a limited-range wireless link. I strongly encourage interested folk to participate in that effort. 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 Jul 2 07:36:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA04817 for ipng-dist; Fri, 2 Jul 1999 07:35:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04809 for ; Fri, 2 Jul 1999 07:35:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA16295; Fri, 2 Jul 1999 07:35:40 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00139; Fri, 2 Jul 1999 07:35:34 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA13220; Fri, 2 Jul 1999 10:35:27 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA37258; Fri, 2 Jul 1999 10:35:29 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id KAA16934; Fri, 2 Jul 1999 10:35:26 -0400 (EDT) Message-Id: <199907021435.KAA16934@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: "Matt Crawford" cc: Paul A Vixie , Erik Nordmark , Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of "Tue, 29 Jun 1999 10:13:31 CDT." <199906291513.KAA13509@gungnir.fnal.gov> Date: Fri, 02 Jul 1999 10:35:25 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > if we want to specify a metaquery that can be satisfied by either AAAA > > or A6 records (or A records for that matter) then by all means let's make > > one. MAILA and MAILB are metaqueries. they have no corresponding RRTYPES; > > they are examples of QTYPE being a subtype of RRTYPE in the DNS specs. > I made that suggestion to the AD's. I'll let them present their own > arguments against it, rather than distort them from memory. I don't recall any specific argument against this (other than perhaps a general "don't know if this would be acceptable to the DNS folks"). It sounds like an avenue worth exploring. 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 Jul 2 08:41:15 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA04936 for ipng-dist; Fri, 2 Jul 1999 08:38:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04929 for ; Fri, 2 Jul 1999 08:38:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA04551 for ; Fri, 2 Jul 1999 08:38:26 -0700 (PDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25610 for ; Fri, 2 Jul 1999 09:38:25 -0600 (MDT) Received: from bogey by east.isi.edu (8.8.5/5.61+local-24) id ; Fri, 2 Jul 1999 15:38:22 GMT Message-ID: <032401bec4a2$3eac0700$634cf526@east.isi.edu> From: "Aaron Griggs" To: "A.Le_Rouzic" Cc: , , References: <25577.930853668@maredsous.monarch.cs.cmu.edu> <377C8A68.6EEA@bull.net> Subject: Re: Revised Mobile IPv6 draft available Date: Fri, 2 Jul 1999 11:47:51 -0400 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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > We agree with Aaron that the IP home address must be used but this > one can be hidden in the case where ESP is used causing the difficulty > to retrieve the SA for this address. > The triple used to find the SA uses the destination address so this is not a problem when the mobile node sends to the correspondent node (IP(MN->CN)_ESP_HmAddrOpt_Data). The correspondent node receives the ESP packet and uses its own address for the lookup. So the SA is found. When the correspondent nodes sends to the mobile node, there isn't a problem because a routing header is used which is before the ESP header (IP(CN->MN)_RH_ESP_Data). When the mobile node hits the ESP header and does the SA lookup, the destination address is the home address. > We think the probleme is where has to be the Home address header > extension. It is not described enough in the draft. > > It is why we suggest to process the destination option Home Address > like the Routing header as described in the IPSEC RFC but this should > be added in the current IPSEC and MobileIPv6 RFCs or drafts. > > Like the routing header before the AH or ESP header, that will allow > in any case to retrieve the SA with the Home address IP. After, it > should be only a implementation issue. Again, the SA triple uses the destination address and not the source address so the home address option isn't an issue. For the inbound SP verification, make the remote IP address wildcarded so the home address option affect (source address changed from mobile to home) doesn't make the verification fail. Aaron -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 08:52:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA04974 for ipng-dist; Fri, 2 Jul 1999 08:50:28 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04967 for ; Fri, 2 Jul 1999 08:50:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA05473 for ; Fri, 2 Jul 1999 08:50:16 -0700 (PDT) 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 JAA28694 for ; Fri, 2 Jul 1999 09:50:15 -0600 (MDT) 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 AAA26080; Sat, 3 Jul 1999 00:49:34 +0900 (JST) To: "Aaron Griggs" cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-reply-to: agriggs's message of Fri, 02 Jul 1999 11:47:51 -0400. <032401bec4a2$3eac0700$634cf526@east.isi.edu> 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: Revised Mobile IPv6 draft available From: itojun@iijlab.net Date: Sat, 03 Jul 1999 00:49:33 +0900 Message-ID: <26078.930930573@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Like the routing header before the AH or ESP header, that will allow >> in any case to retrieve the SA with the Home address IP. After, it >> should be only a implementation issue. >Again, the SA triple uses the destination address and not the source address >so the home address option isn't an issue. For the inbound SP verification, Source address (whether it is ip6_src or home address option) is still very important. When you negotiate the key with the peer, IKE runs between (src, dst) pair. 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 Fri Jul 2 10:23:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA05035 for ipng-dist; Fri, 2 Jul 1999 10:20:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05028 for ; Fri, 2 Jul 1999 10:20:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA22916 for ; Fri, 2 Jul 1999 10:20:32 -0700 (PDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22963 for ; Fri, 2 Jul 1999 10:20:31 -0700 (PDT) Received: from bogey by east.isi.edu (8.8.5/5.61+local-24) id ; Fri, 2 Jul 1999 17:20:18 GMT Message-ID: <035301bec4b0$7d2cd190$634cf526@east.isi.edu> From: "Aaron Griggs" To: , "A.Le_Rouzic" Cc: , , References: <25577.930853668@maredsous.monarch.cs.cmu.edu> <377C8A68.6EEA@bull.net> <032401bec4a2$3eac0700$634cf526@east.isi.edu> Subject: Re: Revised Mobile IPv6 draft available Date: Fri, 2 Jul 1999 13:29:49 -0400 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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Again, the SA triple uses the destination address and not the source address > so the home address option isn't an issue. For the inbound SP verification, > make the remote IP address wildcarded so the home address option affect > (source address changed from mobile to home) doesn't make the verification > fail. I messed up on this statement. The SP address that can be wildcarded is the local address. I usually specify an SP as bidirectional with a remote and local address. The local address is the source address for outbound traffic and the destination address for inbound traffic. The result of a bidirectional SP is two SAs: one for inbound and one for outbound. The outbound SA has the destination address of the remote machine and the inbound SA has the destination address of the local machine. My implementation only supports manual keys so I require the user to enter a local address. Itojun wrote: >Source address (whether it is ip6_src or home address option) >is still very important. When you negotiate the key >with the peer, IKE runs between (src, dst) pair. Couldn't the source just be selected by the sender? For multiple address on an interface, the best address is selected. My statements above handles specifying a source for the SA. Since I am not implementing IKE, I might be missing something. Aaron -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 10:30:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA05065 for ipng-dist; Fri, 2 Jul 1999 10:29:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05058 for ; Fri, 2 Jul 1999 10:28:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA12046 for ; Fri, 2 Jul 1999 10:28:56 -0700 (PDT) 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 LAA22902 for ; Fri, 2 Jul 1999 11:28:47 -0600 (MDT) 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 CAA27962; Sat, 3 Jul 1999 02:27:56 +0900 (JST) To: "Aaron Griggs" cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com In-reply-to: agriggs's message of Fri, 02 Jul 1999 13:29:49 -0400. <035301bec4b0$7d2cd190$634cf526@east.isi.edu> 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: Revised Mobile IPv6 draft available From: itojun@iijlab.net Date: Sat, 03 Jul 1999 02:27:56 +0900 Message-ID: <27960.930936476@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Source address (whether it is ip6_src or home address option) >>is still very important. When you negotiate the key >>with the peer, IKE runs between (src, dst) pair. >Couldn't the source just be selected by the sender? For multiple address on >an interface, the best address is selected. My statements above handles >specifying a source for the SA. Since I am not implementing IKE, I might be >missing something. IKE never select the address to use by its own. IKE obeys the address the underlying communication is using. IKE always use the address pair of the underlying communication. If the kernel would like to send a IPsec'ed packet with (src, dst) and found no key with it, it will make a upcall from kernel to IKE daemon for (src, dst) by using PF_KEY interface. IKE daemon will negotiate the key, using the (src, dst) pair. IPv6: "would like to throw a packet with src->dst, let's encrypt it" IPsec: "I have no key with me, need to ask IKE for key" | | kernel to userland message v IKE: "I will negotiate the key for src->dst" The question here is: IPsec part must pick the source address to be used by IKE, and the IPsec part itself, from home address option or genine IPv6 source address. Which is appropriate for which case? 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 Fri Jul 2 11:10:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA05117 for ipng-dist; Fri, 2 Jul 1999 11:08:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05110 for ; Fri, 2 Jul 1999 11:08:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA00598 for ; Fri, 2 Jul 1999 11:08:13 -0700 (PDT) Received: from mwunix.mitre.org (mwunix.mitre.org [128.29.154.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07705 for ; Fri, 2 Jul 1999 11:08:12 -0700 (PDT) Received: from smtpsrv2.mitre.org (smtpsrv2.mitre.org [128.29.154.2]) by mwunix.mitre.org (8.8.8/8.8.8) with ESMTP id OAA22319 for ; Fri, 2 Jul 1999 14:08:11 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv2.mitre.org (8.9.3/8.9.3) with ESMTP id OAA19007 for ; Fri, 2 Jul 1999 14:08:04 -0400 (EDT) Received: from m22025-pc.mitre.org (128.29.105.55) by mailhub2.mitre.org with SMTP id 1124139; Fri, 02 Jul 1999 14:08:05 EST Message-ID: <377D0052.546D5651@mitre.org> Date: Fri, 02 Jul 1999 14:09:22 -0400 From: Sham Chakravorty Organization: The MITRE Corporation X-Mailer: Mozilla 4.61 [en]C-19990607M (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: schakra@mitre.org Subject: IPv6 for large orgnaizations References: <25458.930851355@maredsous.monarch.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is my second attempt, please ignore this message if you recieved it earlier. We are in the process of summarizing various Ipv6 implementation issues including the status of the protocol, extent of its use around the world, etc., for the US Army for use in mostly mobile, narrow bandwidth environment. We would most appreciate information on your experience with IPv6 implementation for large organizations in the DoD and other agencies. We would appreciate knowing about the extent of IPv4 (or other) tunneling needs, interoperability issues, impact of narrow bandwidth limitations (especially in the low bandwidth links such as radio links), delays due to dual stacking at the hosts and/or routers if any, issues for the mobile environment, and any other related issues such as impact on security, training of the network managers/ops staff, etc. Thanks much in anticipation of your inputs. S. Chakravorty ************************************* -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 14:20:26 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA05223 for ipng-dist; Fri, 2 Jul 1999 14:17:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05216 for ; Fri, 2 Jul 1999 14:17:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA26366 for ; Fri, 2 Jul 1999 14:17:33 -0700 (PDT) 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 PAA15343 for ; Fri, 2 Jul 1999 15:17:31 -0600 (MDT) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id OAA03677; Fri, 2 Jul 1999 14:17:30 -0700 (PDT) Message-Id: <3.0.5.32.19990702141648.0335c7e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 02 Jul 1999 14:16:48 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "IPv6 Router Alert Option" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 : IPv6 Router Alert Option Author(s) : D. Katz, C. Partridge, A. Jackson Filename : draft-ietf-ipngwg-ipv6router-alert-05.txt Pages : 5 Date : 21-Jun-99 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end on July 14, 1999. 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 Fri Jul 2 14:53:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA05266 for ipng-dist; Fri, 2 Jul 1999 14:50:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05259 for ; Fri, 2 Jul 1999 14:50:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA13509 for ; Fri, 2 Jul 1999 14:50:16 -0700 (PDT) Received: from admin.cgocable.net (admin.cgocable.net [24.226.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01926 for ; Fri, 2 Jul 1999 14:50:15 -0700 (PDT) Received: from cgocable.net (cgowave-60-18.cgocable.net [24.226.60.18]) by admin.cgocable.net (8.9.3/8.9.3) with ESMTP id RAA11559 for ; Fri, 2 Jul 1999 17:50:35 -0400 (EDT) Message-ID: <377D325F.ABD2477A@cgocable.net> Date: Fri, 02 Jul 1999 17:42:55 -0400 From: ryane Reply-To: ryane@cgocable.net X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: IPv6 and second internet? References: <3.0.5.32.19990702141648.0335c7e0@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've been reading these postings for a while, and it makes sense to me that we have a need for this protocol, however, what is the sense of making IPv6 compatable with IPv4, when we are going to be "scrapping" the original internet soon for a second internet (which is in development)----shouldn't we be planning for the second internet as opposed to wasting our time with this one which will probably be dead in 5 to 10 years? Bob Hinden wrote: > This is a IPng working group last call for comments on advancing the > following document as a Proposed Standard: > > Title : IPv6 Router Alert Option > Author(s) : D. Katz, C. Partridge, A. Jackson > Filename : draft-ietf-ipngwg-ipv6router-alert-05.txt > Pages : 5 > Date : 21-Jun-99 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end on July > 14, 1999. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 15:16:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA05304 for ipng-dist; Fri, 2 Jul 1999 15:14:14 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05297 for ; Fri, 2 Jul 1999 15:14:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA29338 for ; Fri, 2 Jul 1999 15:14:04 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA25522 for ; Fri, 2 Jul 1999 16:14:03 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA31744; Fri, 2 Jul 1999 23:13:56 +0100 Received: from hursley.ibm.com (lig32-227-11-37.us.lig-dial.ibm.com [32.227.11.37]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA24252; Fri, 2 Jul 1999 23:13:54 +0100 (BST) Message-ID: <377D3934.7631883D@hursley.ibm.com> Date: Fri, 02 Jul 1999 17:12:04 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ryane@cgocable.net CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 and second internet? References: <3.0.5.32.19990702141648.0335c7e0@mailhost.iprg.nokia.com> <377D325F.ABD2477A@cgocable.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't think we are aware of such a plan over here at the Internet Architecture Board :-) Perhaps you are being confused by the name of the "Internet 2" university project. That will hopefully act as a testbed for the next generation of technology, including IPv6, that will feed into the Internet over the coming years. The same is true of many other advanced projects around the world; this has been the model for Internet progress since the beginning. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div As of May 24, 1999: on assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org ryane wrote: > > I've been reading these postings for a while, and it makes sense to me that we > have a need for this protocol, however, what is the sense of making IPv6 > compatable with IPv4, when we are going to be "scrapping" the original > internet soon for a second internet (which is in development)----shouldn't we > be planning for the second internet as opposed to wasting our time with this > one which will probably be dead in 5 to 10 years? > > Bob Hinden wrote: > > > This is a IPng working group last call for comments on advancing the > > following document as a Proposed Standard: > > > > Title : IPv6 Router Alert Option > > Author(s) : D. Katz, C. Partridge, A. Jackson > > Filename : draft-ietf-ipngwg-ipv6router-alert-05.txt > > Pages : 5 > > Date : 21-Jun-99 > > > > Please send substantive comments to the ipng mailing list, and minor > > editorial comments to the authors. This last call period will end on July > > 14, 1999. > > > > 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 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sun Jul 4 20:24:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA06324 for ipng-dist; Sun, 4 Jul 1999 20:21:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA06317 for ; Sun, 4 Jul 1999 20:21:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA02101 for ; Sun, 4 Jul 1999 20:21:38 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA05226 for ; Sun, 4 Jul 1999 20:21:37 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id NAA25349; Mon, 5 Jul 1999 13:21:30 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Mon, 5 Jul 1999 13:21:29 +1000 (EST) From: Peter Tattam To: IPv6 Deployment List , users@ipv6.org, IPNG Mailing List Subject: Using virtual PPP for IPv6 tunneling. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While the solution I knocked together for dynamic tunneling is ok, while developing it, I became aware that there is another way to do the dynamic tunneling that would work much better, and this is by setting up a virtual PPP session over an TCP session. I believe this approach has been applied to one of the tunnel broker instances. Could those involved let me know how it's done so I can implement a compatible solution in Trumpet Winsock. As I already have working PPP code, I can easily port this to go across a TCP connection, and I even have an opprotunity to test out IPv6 header compression. I believe a PPP solution may be the most efficent one for the deployment of tunnels over IPv4 as TCP header compression would aply to the IPv4 component, and the new draft standard for compression can be applied to the IPv6 component. It would also be able to tunnel reliably through firewalls and NAT's as it would not require the use of a IPv6 over IP tunnels, but rather would directly interface as a PPP connection to the IPv6 subsystem at both ends. >From my point of view, the implementation could be *very* simple. Merely connect to a well known port on the PPP tunnel server and negotiate all PPP functions over the virtual circuit. Getting a usable IPv6 address would be accomplished via ND (router advertise) from the tunnel server. While I have reviewed the version that is being used across Linux, I have not tried it as it requires ssh do do its job. I believe a solution could be found which avoids this. I am also unclear as to whether it does actually implement a virtual PPP connection over TCP or whether the control connection is just to manage the configuration of a traditional tunnel at both ends. If a successful compromise can be found, I will be releasing a Win32 capable Tunnel server which would complement the client. I would als be incorporating the client directly into our client TCP/IP package. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 4 20:39:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA06355 for ipng-dist; Sun, 4 Jul 1999 20:36:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA06348 for ; Sun, 4 Jul 1999 20:36:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA12103 for ; Sun, 4 Jul 1999 20:36:39 -0700 (PDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07088 for ; Sun, 4 Jul 1999 20:36:39 -0700 (PDT) Received: by jekyll.piermont.com (Postfix, from userid 1000) id D9FF2155; Sun, 4 Jul 1999 23:36:36 -0400 (EDT) To: Peter Tattam Cc: IPv6 Deployment List , users@ipv6.org, IPNG Mailing List Subject: Re: Using virtual PPP for IPv6 tunneling. References: Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 04 Jul 1999 23:36:36 -0400 In-Reply-To: Peter Tattam's message of "Mon, 5 Jul 1999 13:21:29 +1000 (EST)" Message-ID: <874sjj9397.fsf@jekyll.piermont.com> Lines: 12 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter Tattam writes: > While the solution I knocked together for dynamic tunneling is ok, while > developing it, I became aware that there is another way to do the dynamic > tunneling that would work much better, and this is by setting up a virtual PPP > session over an TCP session. That ends up producing Bad Mojo. The fight between the two layers of congestion control algorithms is frightening to watch. Better to use other mechanisms that don't have TCP at the bottom. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 4 21:07:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA06429 for ipng-dist; Sun, 4 Jul 1999 21:04:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06422 for ; Sun, 4 Jul 1999 21:04:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA04450 for ; Sun, 4 Jul 1999 21:04:24 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA10601 for ; Sun, 4 Jul 1999 21:04:23 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.7.6/8.9.3) with ESMTP id DAA30962; Mon, 5 Jul 1999 03:51:14 GMT Message-Id: <199907050351.DAA30962@inner.net> To: Peter Tattam cc: deployment@ipv6.org, ipng@sunroof.eng.sun.com Subject: Re: Using virtual PPP for IPv6 tunneling. In-reply-to: Your message of "Mon, 05 Jul 1999 13:21:29 +1000." X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Mon, 05 Jul 1999 00:03:48 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , yo u write: >While the solution I knocked together for dynamic tunneling is ok, while >developing it, I became aware that there is another way to do the dynamic >tunneling that would work much better, and this is by setting up a virtual PPP >session over an TCP session. I believe this approach has been applied to one >of the tunnel broker instances. This sounds like a way to accomplish the same thing as IPv6-in-IPv4 tunnels but with much greater protocol overhead (read: waste). -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 4 21:12:02 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA06463 for ipng-dist; Sun, 4 Jul 1999 21:10:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06456 for ; Sun, 4 Jul 1999 21:10:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA08523 for ; Sun, 4 Jul 1999 21:10:39 -0700 (PDT) Received: from thunk.epilogue.com (thunk-home.epilogue.com [128.224.138.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA11594 for ; Sun, 4 Jul 1999 21:10:38 -0700 (PDT) Received: from thunk.epilogue.com (localhost [[UNIX: localhost]]) by thunk.epilogue.com (8.8.8/8.8.8) with ESMTP id AAA10101; Mon, 5 Jul 1999 00:10:21 -0400 (EDT) Message-Id: <199907050410.AAA10101@thunk.epilogue.com> From: Bill Sommerfeld To: Peter Tattam cc: IPv6 Deployment List , users@ipv6.org, IPNG Mailing List Subject: Re: Using virtual PPP for IPv6 tunneling. In-Reply-To: Message from Peter Tattam of "Mon, 05 Jul 1999 13:21:29 +1000." Date: Mon, 05 Jul 1999 00:10:20 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While I have no direct experience with IPv6 over PPP over TCP for tunnelling, I have been regularly using IP over PPP over SSH over TCP tunnels for quite some time as a "poor man's ipsec". > While the solution I knocked together for dynamic tunneling is ok, > while developing it, I became aware that there is another way to do > the dynamic tunneling that would work much better, and this is by > setting up a virtual PPP session over an TCP session. This is very easy to configure, but is likely to have poorer performance than a "regular" tunnel, particularly for TCP traffic through the tunnel. TCP trades latency for reliability, but doesn't deal well with link layers which involve variable latency. The short answer is that TCP doesn't run over TCP very well. other gotchas: 1) Unless you're careful configuring the MTU's of the PPP link, maximum-sized PPP frames will probably be fragmented into multiple TCP segments, which will subject you to additional latency from slow start and the Nagle algorithm. 2) In the presence of packet loss on the path between the tunnel endpoints, both TCP's will end up retransmitting. Packets for the inner tcp will end up queued in the tcp send queue at the tunnel endpoints as well as backed up in the PPP send queue. Once the packets get through, the inner tcp will likely see a flood of duplicate acks, which may prod the tcp fast retransmission algorithm into action, provoking a few more duplicate packets which might by themselves cause congestion and loss. Bad news.. - 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 Sun Jul 4 21:22:09 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA06494 for ipng-dist; Sun, 4 Jul 1999 21:19:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06487 for ; Sun, 4 Jul 1999 21:19:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA05625 for ; Sun, 4 Jul 1999 21:19:22 -0700 (PDT) Received: from thunk.epilogue.com (thunk-home.epilogue.com [128.224.138.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA12784 for ; Sun, 4 Jul 1999 21:19:21 -0700 (PDT) Received: from thunk.epilogue.com (localhost [[UNIX: localhost]]) by thunk.epilogue.com (8.8.8/8.8.8) with ESMTP id AAA10150; Mon, 5 Jul 1999 00:19:14 -0400 (EDT) Message-Id: <199907050419.AAA10150@thunk.epilogue.com> From: Bill Sommerfeld To: Peter Tattam Cc: IPv6 Deployment List , users@ipv6.org, IPNG Mailing List Subject: Re: Using virtual PPP for IPv6 tunneling. In-Reply-To: Message from Bill Sommerfeld of "Mon, 05 Jul 1999 00:10:20 EDT." <199907050410.AAA10101@thunk.epilogue.com> Date: Mon, 05 Jul 1999 00:19:14 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A couple additional notes.. Since you brought up NATs and firewalls as obstacles to work around: - if tunnelling through NAT is desired, an IPv6 over *UDP* tunnel is likely to be able to get through a NAT without too much trauma. - tunnelling IPv6 through a firewall without the knowledge and consent of the firewall's manager has great potential to be a career limiting move. - 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 Sun Jul 4 21:36:01 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA06544 for ipng-dist; Sun, 4 Jul 1999 21:33:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06537 for ; Sun, 4 Jul 1999 21:33:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA05628 for ; Sun, 4 Jul 1999 21:33:17 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA11660 for ; Sun, 4 Jul 1999 22:33:16 -0600 (MDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.7.6/8.9.3) with ESMTP id EAA31047; Mon, 5 Jul 1999 04:20:08 GMT Message-Id: <199907050420.EAA31047@inner.net> To: Bill Sommerfeld cc: deployment@ipv6.org, ipng@sunroof.eng.sun.com Subject: Re: Using virtual PPP for IPv6 tunneling. In-reply-to: Your message of "Mon, 05 Jul 1999 00:19:14 EDT." <199907050419.AAA10150@thunk.epilogue.com> X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Mon, 05 Jul 1999 00:32:44 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199907050419.AAA10150@thunk.epilogue.com>, you write: > - if tunnelling through NAT is desired, an IPv6 over *UDP* tunnel is >likely to be able to get through a NAT without too much trauma. Somewhere in my todo pile is a draft on using UDP as a chained header. I use it every day in order to do a secure tunnel through the highly broken NAT implementation I'm stuck behind. The same problem, and the same solution, should work just as well for IPv6. So you'd build your packets like: [ IPv4 p=UDP ] [ UDP dport=whatever ] [pad, nexthdr=41 ] [ IPv6 ... ] If this is something that people would be interested in building, I can dequeue this particular task and post a draft. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 4 22:28:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA06614 for ipng-dist; Sun, 4 Jul 1999 22:24:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA06607 for ; Sun, 4 Jul 1999 22:23:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA10680 for ; Sun, 4 Jul 1999 22:23:56 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA16764 for ; Sun, 4 Jul 1999 23:23:53 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id PAA03318; Mon, 5 Jul 1999 15:23:15 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Mon, 5 Jul 1999 15:23:15 +1000 (EST) From: Peter Tattam To: Craig Metz cc: deployment@ipv6.org, ipng@sunroof.eng.sun.com Subject: Re: Using virtual PPP for IPv6 tunneling. In-Reply-To: <199907050351.DAA30962@inner.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 5 Jul 1999, Craig Metz wrote: > In message , yo > u write: > >While the solution I knocked together for dynamic tunneling is ok, while > >developing it, I became aware that there is another way to do the dynamic > >tunneling that would work much better, and this is by setting up a virtual PPP > >session over an TCP session. I believe this approach has been applied to one > >of the tunnel broker instances. > > This sounds like a way to accomplish the same thing as IPv6-in-IPv4 tunnels > but with much greater protocol overhead (read: waste). > Boy, did my idea cop it or what. I forgot to don my flame proof clothing :) I forgot to mention that I am talking in terms of using this only for real client PPP connections, not necessarily for normal tunnels. When I crunched the numbers and am not quite so convinced as to wastage. For an IPv6 tunnel, you would have IPv4 header (prot=41), uncompressible over VJ compression. (20 bytes) Ipv6 header. Uncompressible with most tunnels. (40 bytes) We are looking at minimum 60 bytes per tunnelled packet, more often than not carrying TCP or UDP traffic. PPP framing and overhead would still apply as we are already PPP over IPv4. Now if virutal PPP was running over a TCP session, you would have VJ affecting the tunnel traffic directly - our 20 bytes of prot 41 down to around 4-5 bytes. There would not be the IPv4 encapsulation so one can apply the latest IPv6 compression techniques to the raw IPv6 packet. For TCP traffic, this would equate to around 4-5 bytes or so. I would see on average an improvement of around 4 to compression on the headers if this approach were taken for live PPP connections. I accept your comments about TCP latency & data aggregation, which I believe could be dealt with by TCP_NODELAY options if the stacks at either end are suffiently flexible. Since we know that the underlying data is already packetized, I don't see any performance hits over using a normal tunnel except for reliable delivery getting in the way. With TCP_NODELAY off, you may actually get some kind of improvement in overheads as many small IPv6 packets could get aggregated into one lump. As long as you kept your packetizing routines under the MTU, I think it could sort itself out, but I could be totally wrong. As far as TCP reties are concerned, if the tunnel server is realtively close to the client, I think the extent of retries over the local IPv4 link would be minimal. If the server is much more remote, I admit there would be problems. The only way of alleviating this would be adding some intelligence to the protocol to prevent congestion - i.e. short circuit the stream when it gets too many packets. The other idea of using UDP results in slightly more overhead over using normal tunneling, but has the advantage of being able to get through a NAT. It does however suffer in that the native PPP connection will not be able to compress the headers. Tunneling overhead in this case would be 28 bytes. My primary motive for using a TCP stream is to gain advantage of the widespread use of VJ compression in regular PPP terminal servers. Important in the whole discussion however is that the biggest overhead savings actually are made with the Ipv6 header compression. Perhaps we should be pushing to make this standard on any dynamic IPv6 tunnel server. In fact I thought about this for other reasons, but without the ability to specify different framing for the different compressed IPv6 packet types, I'm sunk. If I'm allowed to use the IP version to specify framing for the other compression packet types, it could be done.... (unless we allow the next_header to have specific values for the compressed frames - a bad idea as routing filters would need to be extended past prot=41) Anyway, I could put something together and test the performance between the two as a benchmark. Who knows, it might still work. Nothing ventured, nothing gained. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 4 22:40:11 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA06661 for ipng-dist; Sun, 4 Jul 1999 22:37:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA06654 for ; Sun, 4 Jul 1999 22:37:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA07280 for ; Sun, 4 Jul 1999 22:37:27 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA18202 for ; Sun, 4 Jul 1999 23:37:26 -0600 (MDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.7.6/8.9.3) with ESMTP id FAA31212; Mon, 5 Jul 1999 05:24:17 GMT Message-Id: <199907050524.FAA31212@inner.net> To: Peter Tattam cc: ipng@sunroof.eng.sun.com Subject: Re: Using virtual PPP for IPv6 tunneling. In-reply-to: Your message of "Mon, 05 Jul 1999 15:23:15 +1000." X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Mon, 05 Jul 1999 01:36:53 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , you write: [deploment@ipv6.org snipped; this is a protocol discussion now ;)] >My primary motive for using a TCP stream is to gain advantage of the widesprea >use of VJ compression in regular PPP terminal servers. Most modern terminal servers also support some LZ-ish compression. If you really want to save bits, that's what you should be using anyway. I believe that LZ-ish compression will do better with tunnelling in UDP than in TCP, as the UDP header is very fixed and the TCP header has sequence numbers moving. VJ compression is and always has been a kluge. A kluge that happens to work really well in the common case, but it's still at the end of the day a kluge. The big issue is that TCP delivers properties that are very different than what IP does, while UDP delivers properties that are approximately the same as what IP does. If you run TCP -- or some other reliable-ish transport -- on top of TCP, odd things probably happen. You may find that the change in properties confuses the inner TCP enough to wipe out any performance gains you would otherwise get from header compression. But I bet that it would work fine in the common case; there are a lot of people out there using TCP-based tunnels and they do seem to get along. What happens to those tunnels when things aren't so good on the network isn't so clear, and that's where I'm guessing it would misbehave. It's also inefficient to run this over TCP, and not just in bits, but also in terms of both ends' stacks. Remember that TCP is a very stateful thing and you also have TCP segmentation/reassembly and sequencing thrown in there, while UDP requires no such state at the two ends. Doing this over TCP would work. But I don't think it is a good idea. OTOH, I have enough operational experince running over UDP to know that it works and doesn't do anything wacky, it just decreases your PMTU a bit. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 4 22:56:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA06694 for ipng-dist; Sun, 4 Jul 1999 22:54:12 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA06687 for ; Sun, 4 Jul 1999 22:54:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA18228 for ; Sun, 4 Jul 1999 22:54:04 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA25133 for ; Sun, 4 Jul 1999 22:54:00 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id PAA04919; Mon, 5 Jul 1999 15:53:33 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Mon, 5 Jul 1999 15:53:33 +1000 (EST) From: Peter Tattam To: Craig Metz cc: ipng@sunroof.eng.sun.com Subject: Re: Using virtual PPP for IPv6 tunneling. In-Reply-To: <199907050524.FAA31212@inner.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 5 Jul 1999, Craig Metz wrote: > In message , you > write: > [deploment@ipv6.org snipped; this is a protocol discussion now ;)] > >My primary motive for using a TCP stream is to gain advantage of the widesprea > >use of VJ compression in regular PPP terminal servers. > > Most modern terminal servers also support some LZ-ish compression. If you > really want to save bits, that's what you should be using anyway. I believe > that LZ-ish compression will do better with tunnelling in UDP than in TCP, as > the UDP header is very fixed and the TCP header has sequence numbers moving. > VJ compression is and always has been a kluge. A kluge that happens to work > really well in the common case, but it's still at the end of the day a kluge. > > The big issue is that TCP delivers properties that are very different than > what IP does, while UDP delivers properties that are approximately the same as > what IP does. If you run TCP -- or some other reliable-ish transport -- on > top of TCP, odd things probably happen. You may find that the change in > properties confuses the inner TCP enough to wipe out any performance gains you > would otherwise get from header compression. But I bet that it would work fine > in the common case; there are a lot of people out there using TCP-based tunnels > and they do seem to get along. What happens to those tunnels when things aren't > so good on the network isn't so clear, and that's where I'm guessing it would > misbehave. > > It's also inefficient to run this over TCP, and not just in bits, but also in > terms of both ends' stacks. Remember that TCP is a very stateful thing and > you also have TCP segmentation/reassembly and sequencing thrown in there, while > UDP requires no such state at the two ends. > > Doing this over TCP would work. But I don't think it is a good idea. OTOH, I > have enough operational experince running over UDP to know that it works and > doesn't do anything wacky, it just decreases your PMTU a bit. > > -Craig > Ok, so the general consensus is that there's not a great deal to be gained from compressing the IPv4 tunnel whether it be over prot 41 or UDP, except that UDP can get through a NAT, and that LZ-ish compression (e.g. typical modem) will do a lot for you already. If that were the case, I would hazard a guess that the LZ-ish compression would apply to the whole packet obviating the need for IPv6 header compression no? If that whole approach to header compression is valid then why are we bothering with the newer header compression protocol at all. Shoudln't we just let other link layers do it instead. Some emperical tests could be made of typical modem connection to see if there really is a significant difference between IPv6 tunneled telnet session to a raw Ipv4 telnet session. Surely there are some good rules of thumb already? Just to throw another spanner in the works - wait till you hear this one. I had a customer requesting how they could open a raw socket on the TCP port so that they could send their packets to take advantage of VJ compression for modem PPP traffic. Sound familiar? Peter P.S. in Aus, we are byte counters because we get charged by the megabyte for internet traffic. Issues like this could be important if I want to roll out IPv6 locally. -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 4 23:03:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA06728 for ipng-dist; Sun, 4 Jul 1999 23:02:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06721 for ; Sun, 4 Jul 1999 23:02:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA07959 for ; Sun, 4 Jul 1999 23:02:28 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA21163 for ; Mon, 5 Jul 1999 00:02:26 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id QAA05469 for ; Mon, 5 Jul 1999 16:02:25 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Mon, 5 Jul 1999 16:02:25 +1000 (EST) From: Peter Tattam To: IPNG Mailing List Subject: Treating Tunnels similar to routing entries. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry.. me again :) In my implementation of dynamic tunnel client/servers and integration of tunnels into the TCP stack, it became apparent that treating tunnels as interfaces was a bit of overkill, and that they could be more efficiently managed as a hybrid sort of routing entry. In fact in my latest version, some significant code was moved out of the interface and directly managed by the main IP packet processor. With some minor modifications, the whole lot could be managed as something akin to a routing entry. Has any thought been given to this kind of treatment to the subject? Or is it an implementation detail that needs no further discussion. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 4 23:16:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA06790 for ipng-dist; Sun, 4 Jul 1999 23:13:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06783 for ; Sun, 4 Jul 1999 23:13:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA08232 for ; Sun, 4 Jul 1999 23:13:15 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27946 for ; Sun, 4 Jul 1999 23:13:13 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.7.6/8.9.3) with ESMTP id GAA31373; Mon, 5 Jul 1999 06:00:06 GMT Message-Id: <199907050600.GAA31373@inner.net> To: Peter Tattam cc: ipng@sunroof.eng.sun.com Subject: Re: Treating Tunnels similar to routing entries. In-reply-to: Your message of "Mon, 05 Jul 1999 16:02:25 +1000." X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Mon, 05 Jul 1999 02:12:46 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , you write: >In my implementation of dynamic tunnel client/servers and integration of >tunnels into the TCP stack, it became apparent that treating tunnels as >interfaces was a bit of overkill, and that they could be more efficiently >managed as a hybrid sort of routing entry. In fact in my latest version, som >significant code was moved out of the interface and directly managed by the >main IP packet processor. With some minor modifications, the whole lot could >be managed as something akin to a routing entry. > >Has any thought been given to this kind of treatment to the subject? Or is it >an implementation detail that needs no further discussion. The NRL implementation has done this since 1995. It works fine. It has certain advantages. However, the WG pretty much decided that a tunnel is an interface; certain specs make this assumption and more or less force you to take that approach if you want to be fully compliant. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 4 23:23:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA06813 for ipng-dist; Sun, 4 Jul 1999 23:22:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06806 for ; Sun, 4 Jul 1999 23:22:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA12147 for ; Sun, 4 Jul 1999 23:22:09 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA29492 for ; Sun, 4 Jul 1999 23:22:07 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id QAA06556; Mon, 5 Jul 1999 16:21:45 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Mon, 5 Jul 1999 16:21:44 +1000 (EST) From: Peter Tattam To: Craig Metz cc: ipng@sunroof.eng.sun.com Subject: Re: Treating Tunnels similar to routing entries. In-Reply-To: <199907050600.GAA31373@inner.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 5 Jul 1999, Craig Metz wrote: > In message , you > write: > >In my implementation of dynamic tunnel client/servers and integration of > >tunnels into the TCP stack, it became apparent that treating tunnels as > >interfaces was a bit of overkill, and that they could be more efficiently > >managed as a hybrid sort of routing entry. In fact in my latest version, som > >significant code was moved out of the interface and directly managed by the > >main IP packet processor. With some minor modifications, the whole lot could > >be managed as something akin to a routing entry. > > > >Has any thought been given to this kind of treatment to the subject? Or is it > >an implementation detail that needs no further discussion. > > The NRL implementation has done this since 1995. It works fine. It has > certain advantages. However, the WG pretty much decided that a tunnel is an > interface; certain specs make this assumption and more or less force you to > take that approach if you want to be fully compliant. > > -Craig > That's fine. My code is fairly efficient anyway, and the only time the tunnel interface is referred to in traffic processing is in the send routine. As the interface already has an implied route attached to it, I don't believe that much more efficiency could be gained other than a few cycles here & there. In my stack, virtual interfaces can come & go as they please. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 4 23:28:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA06835 for ipng-dist; Sun, 4 Jul 1999 23:24:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06828 for ; Sun, 4 Jul 1999 23:24:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA12327 for ; Sun, 4 Jul 1999 23:24:35 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA29791 for ; Sun, 4 Jul 1999 23:24:33 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.7.6/8.9.3) with ESMTP id GAA31395; Mon, 5 Jul 1999 06:11:24 GMT Message-Id: <199907050611.GAA31395@inner.net> To: Peter Tattam cc: ipng@sunroof.eng.sun.com Subject: Re: Treating Tunnels similar to routing entries. In-reply-to: Your message of "Mon, 05 Jul 1999 16:21:44 +1000." X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Mon, 05 Jul 1999 02:24:02 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , you write: >That's fine. My code is fairly efficient anyway, and the only time the tunnel >interface is referred to in traffic processing is in the send routine. As the >interface already has an implied route attached to it, I don't believe that >much more efficiency could be gained other than a few cycles here & there. In >my stack, virtual interfaces can come & go as they please. Be careful; the basic and advanced APIs don't like interfaces coming and going too quickly. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 04:29:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA07516 for ipng-dist; Tue, 6 Jul 1999 04:25:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07509 for ; Tue, 6 Jul 1999 04:25:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA17601 for ; Tue, 6 Jul 1999 04:25:29 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA23366 for ; Tue, 6 Jul 1999 05:25:27 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id MAA74692; Tue, 6 Jul 1999 12:25:24 +0100 Received: from hursley.ibm.com (lig32-239-108-212.emea.lig-dial.ibm.com [32.239.108.212]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id MAA16330; Tue, 6 Jul 1999 12:25:15 +0100 (BST) Message-ID: <3781E304.2212EDB3@hursley.ibm.com> Date: Tue, 06 Jul 1999 06:05:40 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Peter Tattam CC: IPNG Mailing List Subject: Re: Treating Tunnels similar to routing entries. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The 6to4 proposal (which is an NGTRANS item) actually works best if you think of tunnels as routing entries, but nevertheless there has to be an element of interface present since 6to4 provides a prefix and prefixes tend to go with router interfaces. Brian Peter Tattam wrote: > > Sorry.. me again :) > > In my implementation of dynamic tunnel client/servers and integration of > tunnels into the TCP stack, it became apparent that treating tunnels as > interfaces was a bit of overkill, and that they could be more efficiently > managed as a hybrid sort of routing entry. In fact in my latest version, some > significant code was moved out of the interface and directly managed by the > main IP packet processor. With some minor modifications, the whole lot could > be managed as something akin to a routing entry. > > Has any thought been given to this kind of treatment to the subject? Or is it > an implementation detail that needs no further discussion. > > Peter > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.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 Tue Jul 6 07:17:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA07617 for ipng-dist; Tue, 6 Jul 1999 07:15:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07610 for ; Tue, 6 Jul 1999 07:14:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA29147 for ; Tue, 6 Jul 1999 07:14:53 -0700 (PDT) Received: from thunk.epilogue.com (flexed02.flex.surfnet.nl [192.87.110.162]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26769 for ; Tue, 6 Jul 1999 08:14:50 -0600 (MDT) Received: from thunk.epilogue.com (localhost [[UNIX: localhost]]) by thunk.epilogue.com (8.8.8/8.8.8) with ESMTP id XAA00297; Mon, 5 Jul 1999 23:52:01 -0400 (EDT) Message-Id: <199907060352.XAA00297@thunk.epilogue.com> From: Bill Sommerfeld To: Dancer cc: Bill Sommerfeld , Peter Tattam , IPv6 Deployment List , users@ipv6.org, IPNG Mailing List Subject: Re: Using virtual PPP for IPv6 tunneling. In-Reply-To: Message from Dancer of "Mon, 05 Jul 1999 18:05:35 +1000." <3780674F.BFCC637D@zeor.simegen.com> Date: Mon, 05 Jul 1999 23:52:00 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would have thought TCP would be more likely to go through NAT cleanly > than UDP. It depends on the NAT and how it sets up the address/port mappings. The ones I'm familiar with deal about the same with UDP as with TCP. > After all, TCP is full of well-known connection associations > that tie all the packets to a part of a known stream. UDP, even > connected UDP, is (apparently) stateless from the firewall's POV. UDP has both source and destination ports just like tcp; not that i've ever implemented the guts of a NAT, but it would seem to be pretty straightforward to map UDP just like you map TCP.. In comparison, IP-in-IP lacks ports, and AH and ESP have just the SPI, which is unidirectional (can't be used to figure out where to reply to). - 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 Tue Jul 6 07:29:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA07651 for ipng-dist; Tue, 6 Jul 1999 07:26:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07640 for ; Tue, 6 Jul 1999 07:26:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA19340 for ; Tue, 6 Jul 1999 07:26:32 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17746 for ; Tue, 6 Jul 1999 07:26:30 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id AAA22567; Wed, 7 Jul 1999 00:26:17 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Wed, 7 Jul 1999 00:26:16 +1000 (EST) From: Peter Tattam To: Bill Sommerfeld cc: Dancer , IPv6 Deployment List , users@ipv6.org, IPNG Mailing List Subject: Re: Using virtual PPP for IPv6 tunneling. In-Reply-To: <199907060352.XAA00297@thunk.epilogue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 5 Jul 1999, Bill Sommerfeld wrote: > > I would have thought TCP would be more likely to go through NAT cleanly > > than UDP. > > It depends on the NAT and how it sets up the address/port mappings. > The ones I'm familiar with deal about the same with UDP as with TCP. > > > After all, TCP is full of well-known connection associations > > that tie all the packets to a part of a known stream. UDP, even > > connected UDP, is (apparently) stateless from the firewall's POV. > > UDP has both source and destination ports just like tcp; not that i've > ever implemented the guts of a NAT, but it would seem to be pretty > straightforward to map UDP just like you map TCP.. Having implemented a NAT, I can speak from some experience. TCP is slightly better than UDP in that it is stateful, and you can reuses resources more quickly. With UDP, there's no way to tell how long an address mapping tuple is going to last for. At least with TCP, you have SYN/FIN/RST packets to give you hints. I haven't actually used the stateful info in my NAT though, thus TCP and UDP can be treated identically. > > In comparison, IP-in-IP lacks ports, and AH and ESP have just the SPI, > which is unidirectional (can't be used to figure out where to reply > to). > > - Bill > > Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 09:11:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA07803 for ipng-dist; Tue, 6 Jul 1999 09:08:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07796 for ; Tue, 6 Jul 1999 09:08:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA00670 for ; Tue, 6 Jul 1999 09:08:10 -0700 (PDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23913 for ; Tue, 6 Jul 1999 09:08:10 -0700 (PDT) Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA26843; Tue, 6 Jul 1999 12:07:46 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <26078.930930573@coconut.itojun.org> References: agriggs's message of Fri, 02 Jul 1999 11:47:51 -0400. <032401bec4a2$3eac0700$634cf526@east.isi.edu> Date: Tue, 6 Jul 1999 12:08:49 -0400 To: itojun@iijlab.net From: Stephen Kent Subject: Re: Revised Mobile IPv6 draft available Cc: "Aaron Griggs" , ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, RFC 2401 et al. are quite clear on this point. The triple used for inbound SA lookups does not include the source address. 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 Jul 6 09:17:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA07856 for ipng-dist; Tue, 6 Jul 1999 09:16:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07849 for ; Tue, 6 Jul 1999 09:15:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA14889 for ; Tue, 6 Jul 1999 09:15:51 -0700 (PDT) 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 KAA10494 for ; Tue, 6 Jul 1999 10:15:49 -0600 (MDT) 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 BAA14565; Wed, 7 Jul 1999 01:15:04 +0900 (JST) To: Stephen Kent cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-reply-to: kent's message of Tue, 06 Jul 1999 12:08:49 -0400. 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: Revised Mobile IPv6 draft available From: itojun@iijlab.net Date: Wed, 07 Jul 1999 01:15:04 +0900 Message-ID: <14563.931277704@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >RFC 2401 et al. are quite clear on this point. The triple used for inbound >SA lookups does not include the source address. I agree that source address is not used in inbound SA lookups. I'm talking about outbound and IKE. 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 Tue Jul 6 09:56:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA07958 for ipng-dist; Tue, 6 Jul 1999 09:53:13 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07951 for ; Tue, 6 Jul 1999 09:53:09 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA17510 for ipng@sunroof.eng.sun.com; Tue, 6 Jul 1999 09:51:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04409 for ; Fri, 2 Jul 1999 02:45:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA26993 for ; Fri, 2 Jul 1999 02:45:26 -0700 (PDT) Received: from ecbull20.frec.bull.fr ([129.183.4.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21338 for ; Fri, 2 Jul 1999 03:45:24 -0600 (MDT) Received: from isatis.frec.bull.fr (isatis.frec.bull.fr [129.183.144.1]) by ecbull20.frec.bull.fr (8.9.2/8.9.1) with ESMTP id LAA53658; Fri, 2 Jul 1999 11:46:23 +0200 Received: from isatis (isatis.frec.bull.fr [129.183.144.1]) by isatis.frec.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id LAA203180; Fri, 2 Jul 1999 11:46:19 +0200 (DFT) Message-ID: <377C8A68.6EEA@bull.net> Date: Fri, 02 Jul 1999 11:46:16 +0200 From: "A.Le_Rouzic" X-Mailer: Mozilla 3.01Gold (X11; I; AIX 2) MIME-Version: 1.0 To: Dave Johnson CC: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: Revised Mobile IPv6 draft available References: <25577.930853668@maredsous.monarch.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, We are also looking at a mobileipv6 plus ipsec implementation in AIX 4.3 as prototype and we met the same difficulties than Itojun and Aaron Griggs. Which IP address to use for the tunnel IP ? Home address or COA address? Where the DES OPT Home address has to be ? We agree with Aaron that the IP home address must be used but this one can be hidden in the case where ESP is used causing the difficulty to retrieve the SA for this address. We think the probleme is where has to be the Home address header extension. It is not described enough in the draft. It is why we suggest to process the destination option Home Address like the Routing header as described in the IPSEC RFC but this should be added in the current IPSEC and MobileIPv6 RFCs or drafts. Like the routing header before the AH or ESP header, that will allow in any case to retrieve the SA with the Home address IP. After, it should be only a implementation issue. About, IPSEC on care-of-address. It can be written as optional or additionnal like also Aaron proposed in a previous mail. It is not possible for us to be in Oslo but we are interested by your conclusion if it impacts future IPSEC and MobileIPv6 specifications. Nevertheless you can transmit to Francis Dupont we are working with. Patrice Romand (Patrice.Romand@bull.net) Aime Le Rouzic (Aime.Lerouzic@bull.net) Dave Johnson wrote: > > >>On Friday of last week, I submitted a revised version of the Mobile IPv6 > >>draft to fix and clear up some of the minor things pointed out at the > >>last meeting and on the mailing list since. I sent an announcement of > >>it to the Mobile IP mailing list then, but I forgot to include the IPng > >>list in my announcement. Here is the list of changes since the > >>previous version of the draft: > > > > There were several questions arose for relationship of mobile-ipv6 > > and ipsec (in here, and ipsec mailing list). Do you have any plan > > to update that part? Without that update we can't make a complete > > implementation of mobile-ipv6 (with security considered). > > > >itojun > > Yes, I believe that is the only remaining place where clarification is > needed, although I haven't had enough time to read through all the > IPsec documents myself enough times, and haven't had a chance to talk > enough with IPsec experts about it, to really get the definitive text > writtin into the draft for this. I hope to be able to talk with > implementers and IPsec experts about this in Oslo. Will you be there? > > Dave > > I will > > Itojun -- ________________________Aime LEROUZIC____________________________ BULL S.A ECHIROLLES FRANCE mailto:Aime.Lerouzic@frec.bull.fr http://www-frec.bull.com tel: +33 (0)4 76 29 75 51 Communications TCPIP http://intranet/lerouzic -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 10:48:47 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA08218 for ipng-dist; Tue, 6 Jul 1999 10:46:22 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08211 for ; Tue, 6 Jul 1999 10:46:17 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA17778 for ipng@sunroof.eng.sun.com; Tue, 6 Jul 1999 10:44:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06948 for ; Mon, 5 Jul 1999 01:07:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA22773 for ; Mon, 5 Jul 1999 01:07:15 -0700 (PDT) Received: from gw.simegen.com (gw.simegen.com [203.2.135.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA15710 for ; Mon, 5 Jul 1999 01:07:13 -0700 (PDT) Received: from anaconda.simegen.com (zeor.simegen.com) [203.28.9.32] by gw.simegen.com with esmtp (Exim 3.02 #1 (Debian)) id 1113mG-0001ts-00; Mon, 05 Jul 1999 18:07:01 +1000 Message-ID: <3780674F.BFCC637D@zeor.simegen.com> Date: Mon, 05 Jul 1999 18:05:35 +1000 From: Dancer X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Sommerfeld CC: Peter Tattam , IPv6 Deployment List , users@ipv6.org, IPNG Mailing List Subject: Re: Using virtual PPP for IPv6 tunneling. References: <199907050419.AAA10150@thunk.epilogue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Sommerfeld wrote: > > A couple additional notes.. > > Since you brought up NATs and firewalls as obstacles to work around: > > - if tunnelling through NAT is desired, an IPv6 over *UDP* tunnel is > likely to be able to get through a NAT without too much trauma. I would have thought TCP would be more likely to go through NAT cleanly than UDP. After all, TCP is full of well-known connection associations that tie all the packets to a part of a known stream. UDP, even connected UDP, is (apparently) stateless from the firewall's POV. I don't suppose you'd care to expand a little further? > - tunnelling IPv6 through a firewall without the knowledge and > consent of the firewall's manager has great potential to be a career > limiting move. *amen* to that. It's also bad if the firewall's manager waves a feather-duster around like a sword. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 10:49:01 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA08209 for ipng-dist; Tue, 6 Jul 1999 10:45:41 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08202 for ; Tue, 6 Jul 1999 10:45:36 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA17749 for ipng@sunroof.eng.sun.com; Tue, 6 Jul 1999 10:44:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06924 for ; Mon, 5 Jul 1999 01:01:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA22580 for ; Mon, 5 Jul 1999 01:01:49 -0700 (PDT) Received: from gw.simegen.com (gw.simegen.com [203.2.135.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA05911 for ; Mon, 5 Jul 1999 02:01:48 -0600 (MDT) Received: from anaconda.simegen.com (zeor.simegen.com) [203.28.9.32] by gw.simegen.com with esmtp (Exim 3.02 #1 (Debian)) id 1113ex-0001tE-00; Mon, 05 Jul 1999 17:59:28 +1000 Message-ID: <3780658B.1CFC8487@zeor.simegen.com> Date: Mon, 05 Jul 1999 17:58:03 +1000 From: Dancer X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: perry@piermont.com CC: Peter Tattam , IPv6 Deployment List , users@ipv6.org, IPNG Mailing List Subject: Re: Using virtual PPP for IPv6 tunneling. References: <874sjj9397.fsf@jekyll.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Perry E. Metzger" wrote: > > Peter Tattam writes: > > While the solution I knocked together for dynamic tunneling is ok, while > > developing it, I became aware that there is another way to do the dynamic > > tunneling that would work much better, and this is by setting up a virtual PPP > > session over an TCP session. > > That ends up producing Bad Mojo. The fight between the two layers of > congestion control algorithms is frightening to watch. Better to use > other mechanisms that don't have TCP at the bottom. Well, in a pinch you could connect a UDP socket. It mimics the supposed reliability of the underlying network link, will run point-to-point, and PPP should be relatively happy with it. You also shouldn't need to inform anything about the change to the transport layer. IMO, though, if you want scary: PPP and the error-correction on any modern modem can do some pretty bleak things to flow and congestion too. The modem may perform all sorts of guff, while trying to keep the link-layer ignorant of it all. D From owner-ipng@sunroof.eng.sun.com Mon Jul 5 01:04:18 1999 X-Unix-From: owner-ipng@sunroof.eng.sun.com Mon Jul 5 01:04:18 1999 Status: RO X-Status: $$$T Return-Path: Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA513918 for ; Mon, 5 Jul 1999 01:04:18 -0700 (PDT) From: owner-ipng@sunroof.eng.sun.com Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA06943; Mon, 5 Jul 1999 01:04:16 -0700 (PDT) Date: Mon, 5 Jul 1999 01:04:16 -0700 (PDT) Message-Id: <199907050804.BAA06943@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from [Dancer ] Content-Length: 3354 From owner-ipng Mon Jul 5 01:04:06 1999 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06936 for ; Mon, 5 Jul 1999 01:04:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA11402 for ; Mon, 5 Jul 1999 01:04:04 -0700 (PDT) Received: from gw.simegen.com (gw.simegen.com [203.2.135.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA06248 for ; Mon, 5 Jul 1999 02:04:03 -0600 (MDT) Received: from anaconda.simegen.com (zeor.simegen.com) [203.28.9.32] by gw.simegen.com with esmtp (Exim 3.02 #1 (Debian)) id 1113ib-0001tb-00; Mon, 05 Jul 1999 18:03:13 +1000 Message-ID: <3780666C.17A587EF@zeor.simegen.com> Date: Mon, 05 Jul 1999 18:01:48 +1000 From: Dancer X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Sommerfeld CC: Peter Tattam , IPv6 Deployment List , users@ipv6.org, IPNG Mailing List Subject: Re: Using virtual PPP for IPv6 tunneling. References: <199907050410.AAA10101@thunk.epilogue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > > While I have no direct experience with IPv6 over PPP over TCP for > tunnelling, I have been regularly using IP over PPP over SSH over TCP > tunnels for quite some time as a "poor man's ipsec". > > > While the solution I knocked together for dynamic tunneling is ok, > > while developing it, I became aware that there is another way to do > > the dynamic tunneling that would work much better, and this is by > > setting up a virtual PPP session over an TCP session. > > This is very easy to configure, but is likely to have poorer > performance than a "regular" tunnel, particularly for TCP traffic > through the tunnel. > > TCP trades latency for reliability, but doesn't deal well with link > layers which involve variable latency. The short answer is that TCP > doesn't run over TCP very well. > > other gotchas: > 1) Unless you're careful configuring the MTU's of the PPP > link, maximum-sized PPP frames will probably be fragmented into > multiple TCP segments, which will subject you to additional latency > from slow start and the Nagle algorithm. > > 2) In the presence of packet loss on the path between the tunnel > endpoints, both TCP's will end up retransmitting. > > Packets for the inner tcp will end up queued in the tcp send queue at > the tunnel endpoints as well as backed up in the PPP send queue. > > Once the packets get through, the inner tcp will likely see a flood of > duplicate acks, which may prod the tcp fast retransmission algorithm > into action, provoking a few more duplicate packets which might by > themselves cause congestion and loss. Bad news.. Yes, pathological loss bites, rather. When you add the route, modify the window size to (say) 4096, and set the txqueuelen down to something low. Like 1. This really blows away udp traffic (like DNS and ICMP and so forth) but will make your tcp over ppp over tcp work a lot more smoothly. D -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 10:49:01 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA08200 for ipng-dist; Tue, 6 Jul 1999 10:45:16 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08193 for ; Tue, 6 Jul 1999 10:45:11 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA17720 for ipng@sunroof.eng.sun.com; Tue, 6 Jul 1999 10:43:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06924 for ; Mon, 5 Jul 1999 01:01:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA22580 for ; Mon, 5 Jul 1999 01:01:49 -0700 (PDT) Received: from gw.simegen.com (gw.simegen.com [203.2.135.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA05911 for ; Mon, 5 Jul 1999 02:01:48 -0600 (MDT) Received: from anaconda.simegen.com (zeor.simegen.com) [203.28.9.32] by gw.simegen.com with esmtp (Exim 3.02 #1 (Debian)) id 1113ex-0001tE-00; Mon, 05 Jul 1999 17:59:28 +1000 Message-ID: <3780658B.1CFC8487@zeor.simegen.com> Date: Mon, 05 Jul 1999 17:58:03 +1000 From: Dancer X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: perry@piermont.com CC: Peter Tattam , IPv6 Deployment List , users@ipv6.org, IPNG Mailing List Subject: Re: Using virtual PPP for IPv6 tunneling. References: <874sjj9397.fsf@jekyll.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Perry E. Metzger" wrote: > > Peter Tattam writes: > > While the solution I knocked together for dynamic tunneling is ok, while > > developing it, I became aware that there is another way to do the dynamic > > tunneling that would work much better, and this is by setting up a virtual PPP > > session over an TCP session. > > That ends up producing Bad Mojo. The fight between the two layers of > congestion control algorithms is frightening to watch. Better to use > other mechanisms that don't have TCP at the bottom. Well, in a pinch you could connect a UDP socket. It mimics the supposed reliability of the underlying network link, will run point-to-point, and PPP should be relatively happy with it. You also shouldn't need to inform anything about the change to the transport layer. IMO, though, if you want scary: PPP and the error-correction on any modern modem can do some pretty bleak things to flow and congestion too. The modem may perform all sorts of guff, while trying to keep the link-layer ignorant of it all. D -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 11:04:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA08316 for ipng-dist; Tue, 6 Jul 1999 11:01:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08309 for ; Tue, 6 Jul 1999 11:00:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA25517 for ; Tue, 6 Jul 1999 11:00:50 -0700 (PDT) Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA12853 for ; Tue, 6 Jul 1999 11:00:50 -0700 (PDT) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Tue, 6 Jul 1999 18:59:48 +0100 Date: Tue, 6 Jul 1999 19:00:10 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Dancer cc: perry@piermont.com, Peter Tattam , IPv6 Deployment List , users@ipv6.org, IPNG Mailing List Subject: Re: Using virtual PPP for IPv6 tunneling. In-Reply-To: <3780658B.1CFC8487@zeor.simegen.com> Message-ID: Organization: speaking for none X-URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 5 Jul 1999, Dancer wrote: > IMO, though, if you want scary: PPP and the error-correction on any > modern modem can do some pretty bleak things to flow and congestion too. > The modem may perform all sorts of guff, while trying to keep the > link-layer ignorant of it all. I keep expecting someone to build an 'IP only' modem with a lot of redundant-with-PPP stuff stripped out. Doesn't seem to have happened - even with software modems. L. PGP -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 15:30:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA08744 for ipng-dist; Tue, 6 Jul 1999 15:26:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08737 for ; Tue, 6 Jul 1999 15:26:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA24586 for ; Tue, 6 Jul 1999 15:25:48 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA03513 for ; Tue, 6 Jul 1999 15:25:48 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Jul 1999 15:23:04 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2448.0) id <3NF3M1J3>; Tue, 6 Jul 1999 15:23:04 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145154C7@RED-MSG-50> From: Richard Draves To: "'Craig Metz'" , Peter Tattam Cc: ipng@sunroof.eng.sun.com Subject: RE: Treating Tunnels similar to routing entries. Date: Tue, 6 Jul 1999 15:22:57 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >In my implementation of dynamic tunnel client/servers and > integration of > >tunnels into the TCP stack, it became apparent that treating > tunnels as > >interfaces was a bit of overkill, and that they could be > more efficiently > >managed as a hybrid sort of routing entry. In fact in my > latest version, som > >significant code was moved out of the interface and directly > managed by the > >main IP packet processor. With some minor modifications, > the whole lot could > >be managed as something akin to a routing entry. > > > >Has any thought been given to this kind of treatment to the > subject? Or is it > >an implementation detail that needs no further discussion. > > The NRL implementation has done this since 1995. It works > fine. It has > certain advantages. However, the WG pretty much decided that > a tunnel is an > interface; certain specs make this assumption and more or > less force you to > take that approach if you want to be fully compliant. MSR IPv6 also uses this approach for configured tunnels. Indeed it works fine. But as we work on support for dynamic routing protocols, we'll probably change to representing configured tunnels as interfaces. I think the specs should allow both implementation strategies. 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 Jul 6 15:34:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA08762 for ipng-dist; Tue, 6 Jul 1999 15:32:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08755 for ; Tue, 6 Jul 1999 15:32:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA11588 for ; Tue, 6 Jul 1999 15:32:23 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06002 for ; Tue, 6 Jul 1999 15:32:09 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.7.6/8.9.3) with ESMTP id WAA02225; Tue, 6 Jul 1999 22:17:48 GMT Message-Id: <199907062217.WAA02225@inner.net> To: Richard Draves cc: Peter Tattam , ipng@sunroof.eng.sun.com Subject: Re: Treating Tunnels similar to routing entries. In-reply-to: Your message of "Tue, 06 Jul 1999 15:22:57 PDT." <4D0A23B3F74DD111ACCD00805F31D810145154C7@RED-MSG-50> X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 06 Jul 1999 18:31:30 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4D0A23B3F74DD111ACCD00805F31D810145154C7@RED-MSG-50>, you write: >MSR IPv6 also uses this approach for configured tunnels. Indeed it works >fine. But as we work on support for dynamic routing protocols, we'll >probably change to representing configured tunnels as interfaces. The netproc stuff I've been working on mostly for IPsec purposes provides a viable way to do dynamic routing protocols without the need for tunnel interfaces. A lot of the routing people have decided that they need tunnel interfaces and are writing specs that way. I've tried to unconfuse them and get them to see what it is that they really need (which is to know where a tunnelled packet came from and to be able to send it back the same way), but haven't had a whole lot of luck at it. >I think the specs should allow both implementation strategies. I think so, too, but that's not the way that some of the specs have ended up. If you want to be strictly conformant, you have to implement tunnel interfaces. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 03:18:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA09200 for ipng-dist; Wed, 7 Jul 1999 03:15:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09193 for ; Wed, 7 Jul 1999 03:15:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA25034 for ; Wed, 7 Jul 1999 03:15:36 -0700 (PDT) Received: from ygmail.kt.co.kr (ygmail_kt.kotel.co.kr [147.6.3.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA09239 for ; Wed, 7 Jul 1999 03:15:36 -0700 (PDT) Received: from kt.co.kr ([147.6.65.78]) by ygmail.kt.co.kr (8.8.8/8.8.8) with ESMTP id TAA11678; Wed, 7 Jul 1999 19:18:48 +0900 (KST) Message-ID: <37832A39.9DA3F6C3@kt.co.kr> Date: Wed, 07 Jul 1999 19:21:45 +0900 From: ksb Reply-To: ksbn@kt.co.kr Organization: kt X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: =?EUC-KR?B?sbnBpg==?= 6Bone <6bone@isi.edu> CC: IETF ipng , "6Bone(WIDE)" <6bone-jp@wide.ad.jp> Subject: multicast tool Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear members: I got a small IPv6 network based on Solaris7 hosts. I hope to experiment the IPv6 multicast on Solaris7 hosts(IPv6 prototype patch installed). But it's difficult to find proper software. Will you send me some information? Sincerely, -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 07:53:01 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA09357 for ipng-dist; Wed, 7 Jul 1999 07:50:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09350 for ; Wed, 7 Jul 1999 07:50:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA26942 for ; Wed, 7 Jul 1999 07:50:07 -0700 (PDT) Received: from ziggy.stardust.com (ns.stardust.com [205.184.205.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11690 for ; Wed, 7 Jul 1999 08:50:07 -0600 (MDT) Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id HAA08982; Wed, 7 Jul 1999 07:44:06 -0700 Message-Id: <3.0.5.32.19990707074257.009d4300@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 07 Jul 1999 07:42:57 -0700 To: ksbn@kt.co.kr, =?EUC-KR?B?sbnBpg==?= 6Bone <6bone@isi.edu> From: Marty Bickford Subject: Re: multicast tool Cc: IETF ipng , "6Bone(WIDE)" <6bone-jp@wide.ad.jp> In-Reply-To: <37832A39.9DA3F6C3@kt.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is an IP Multicast product directory at http://www.ipmulticast.com/ipmi_dir/ . If you find additional software to add, please do. Stardust would also be happy to host a directory of IPv6 software. If you think it would be useful, start sending me pointers to software/products to add. Thanks, Marty http://www.stardust.com/ At 07:21 PM 7/7/99 +0900, ksb wrote: >Dear members: > >I got a small IPv6 network based on Solaris7 hosts. >I hope to experiment the IPv6 multicast on Solaris7 >hosts(IPv6 prototype patch installed). >But it's difficult to find proper software. >Will you send me some information? > >Sincerely, > >-- > Kim, Sahng-Beom / Korea Telecom > TEL : +82-42-870-8322 > FAX : +82-42-870-8329 > E-mail : ksbn@kt.co.kr >-- > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > --- Marty Bickford - 408.879.8080 (8081-fax) Stardust.com - http://www.stardust.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 Jul 8 13:53:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA10811 for ipng-dist; Thu, 8 Jul 1999 13:49:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10804 for ; Thu, 8 Jul 1999 13:49:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01908 for ; Thu, 8 Jul 1999 13:49:15 -0700 (PDT) Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20071 for ; Thu, 8 Jul 1999 13:49:12 -0700 (PDT) Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id PAA06583 for ; Thu, 8 Jul 1999 15:49:08 -0500 (CDT) Received: from cyras.com(216.100.242.3) by dfw-ix1.ix.netcom.com via smap (V1.3) id rma006542; Thu Jul 8 15:48:54 1999 Received: from nodnsquery(10.10.10.123) by cyras30.cyras.com via Gauntlet (3.0) Thu, 08 Jul 1999 13:55:02 -0800 Message-ID: <37851D42.E621A5BE@cyras.com> Date: Thu, 08 Jul 1999 14:50:58 -0700 From: Mark Sandstrom X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Traffic shaping with IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 2463 (ICMPv6) does not define an ICMPv6 message corresponding to ICMP (RFC 792) Source Quench message. In addition, RFC 2463 specifies that "an ICMPv6 message MUST NOT be generated if a packet is dropped due to congestion". As it looks like ICMPv6 does not provide means for traffic volume control, my question is: what in general are the means for network congestion control with IPv6? In particular, my problem is: What action should a router take to prevent a buffer overflow e.g. in a case that it receives IPv6 packets (from several sources) destined towards the same output port with a cumulated volume greater than the output capacity of that port? Any help and pointers to documents discussing this subject are greatly appreciated. Thanks, Mark Sandstrom e-mail: msandstrom@cyras.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 Jul 9 02:55:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA11459 for ipng-dist; Fri, 9 Jul 1999 02:52:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11452 for ; Fri, 9 Jul 1999 02:52:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA22544 for ; Fri, 9 Jul 1999 02:52:13 -0700 (PDT) Received: from spexcams01.speedport.net ([203.26.193.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07491 for ; Fri, 9 Jul 1999 03:52:13 -0600 (MDT) Received: by spexcams01 with Internet Mail Service (5.5.1960.3) id <3MKZLPS2>; Fri, 9 Jul 1999 11:50:26 +0200 Message-ID: <5B88AE75A21DD31199110008C7BB99ED02DECA@spexcams01> From: "Dunn, Jim" To: ipng@sunroof.eng.sun.com Subject: IP Version 5 Date: Fri, 9 Jul 1999 11:50:26 +0200 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am new to this list, so forgive the silly question, But what happened to IPv5. Also If I want to run up an internal IPv6 testbed, Where can I find the tools to do this ? Jim Dunn Senior Network Engineer SpeedPort Global Network N.V. Amsterdam Operations Centre Kruislaan 400 1098 SM Amsterdam Tel: +31 (0)20 888 4074 Fax: +31 (0)20 888 4317 Mobile: +44 (0)370 672229 E-Mail: jim.dunn@speedport.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 Fri Jul 9 03:42:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA11495 for ipng-dist; Fri, 9 Jul 1999 03:39:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11488 for ; Fri, 9 Jul 1999 03:39:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA01456 for ; Fri, 9 Jul 1999 03:39:32 -0700 (PDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA14098 for ; Fri, 9 Jul 1999 04:39:31 -0600 (MDT) Received: from blues.mchh.siemens.de ([194.138.158.227]) by gorilla.mchh.siemens.de (8.8.7/8.8.7) with ESMTP id MAA28576; Fri, 9 Jul 1999 12:38:54 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([218.1.68.146]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA27026; Fri, 9 Jul 1999 12:38:00 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2448.0) id <3M2NQNWK>; Fri, 9 Jul 1999 12:41:30 +0200 Message-ID: From: Petri Bernhard To: "'Dunn, Jim'" Cc: ipng@sunroof.eng.sun.com Subject: RE: IP Version 5 Date: Fri, 9 Jul 1999 12:41:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Jim, I think the version 5 had once been allocated to an experimental Stream Transport II protocol at that time. For your testbed, I suggest you take a look onto: http://www.ipv6.org/ which will also give you further links and references. You may also look at: http://6bone.net/ which gives you information about the 6bone, the testbed for deployment of IPv6. Kind regards Bernhard Bernhard Petri, Siemens Advanced Network Standards Tel: +49 89 722-34578 Fax: +49 89 722-62366 bernhard.petri@icn.siemens.de ______________________________ > -----Original Message----- > From: Dunn, Jim [SMTP:jim.dunn@corp.speedport.net] > Sent: Friday, July 09, 1999 11:50 AM > To: ipng@sunroof.eng.sun.com > Subject: IP Version 5 > Importance: High > > I am new to this list, so forgive the silly question, But what happened > to IPv5. > > Also If I want to run up an internal IPv6 testbed, Where can I find the > tools to do this ? > > Jim Dunn > Senior Network Engineer > > SpeedPort Global Network N.V. > Amsterdam Operations Centre > Kruislaan 400 > 1098 SM Amsterdam > > Tel: +31 (0)20 888 4074 > Fax: +31 (0)20 888 4317 > Mobile: +44 (0)370 672229 > E-Mail: jim.dunn@speedport.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 Fri Jul 9 05:44:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA11576 for ipng-dist; Fri, 9 Jul 1999 05:41:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11569 for ; Fri, 9 Jul 1999 05:41:10 -0700 (PDT) From: trawick@us.ibm.com Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA27652 for ; Fri, 9 Jul 1999 05:41:10 -0700 (PDT) Received: from ny.us.ibm.com. (e4.ny.us.ibm.com [32.97.182.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01682 for ; Fri, 9 Jul 1999 06:41:10 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id IAA77238; Fri, 9 Jul 1999 08:40:38 -0400 Received: from d54mta05.raleigh.ibm.com (d54mta05.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.03) with SMTP id IAA34252; Fri, 9 Jul 1999 08:40:44 -0400 Received: by d54mta05.raleigh.ibm.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852567A9.0045A3AF ; Fri, 9 Jul 1999 08:40:38 -0400 X-Lotus-FromDomain: IBMUS To: Jim Bound cc: ipng@sunroof.eng.sun.com Message-ID: <852567A9.0045A30A.00@d54mta05.raleigh.ibm.com> Date: Fri, 9 Jul 1999 08:40:35 -0400 Subject: Re: getipnodebyname() and numeric address string arguments with various non-zero flags Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk First, thanks for your response. I'm sorry for the delay in getting back to you. >I think your asking for the counter to what we did describe too? I guess so. The paragraph after "The two simple cases are:" seemed to rule out checking the flags when the type of numeric address string matched the af parameter. Of course, I'm not suggesting a updated RFC and don't know where any sort of clarifications should live anyway. So the purpose of the following comments are for me to better understand the requirements and for other naive readers like myself perusing this list to better understand them as well. I think the sentence "The two simple cases are: When name is a dotted-decimal IPv4 address and af equals AF_INET, or when name is an IPv6 hex address and af equals AF_INET6." should be replaced by "The two simple cases are: When name is a dotted-decimal IPv4 address and af equals AF_INET, or when name is an IPv6 hex address and af equals AF_INET6, and either the AI_ADDRCONFIG flag is not specified or a source address is configured for the specified af." In addition, the following paragraph should be added: It is an error when name is a dotted-decimal IPv4 address and af equals AF_INET and the AI_ADDRCONFIG flag is specified and there is no IPv4 source address configured. It is an error when name is a IPv6 hex address but not an IPv4-mapped IPv6 address and af equals AF_INET6 and the AI_ADDRCONFIG flag is specified and there is no IPv6 source address configured. >But link-local addresses are not kept in the DNS at this time. I'm afraid I don't follow. Was anything I said specific to link-local addresses without me knowing it? Thanks and best wishes, Jeff Trawick, trawick@us.ibm.com IBM SecureWay (nee' eNetwork) Software Tips: ->http://www2.software.ibm.com/eNetwork/Tips.nsf/Tips?OpenView&Count=500 OS/390 UNIX - Frequently Asked Questions: ->http://www.s390.ibm.com/oe/bpxqarc.html Jim Bound on 06/28/99 02:24:36 PM To: Jeff Trawick/Raleigh/IBM@IBMUS cc: ipng@sunroof.eng.sun.com Subject: Re: getipnodebyname() and numeric address string arguments with various non-zero flags >>From RFC 2553, I gather that it makes no difference what is passed for the flags >parameter on getipnodebyname() when the type of the numeric address string >matches the address family parameter. Right? No. AI_V4MAPPED, AI_ADDRCONFIG, and AI_ALL still can be used. >So getipnodebyname("FE80::1000:whatever",AF_INET6,AI_DEFAULT,&error_num) on a >system that doesn't have a local IPv6 interface will succeed, but the >application won't be able to use the resulting address. Right? No. An error should be returned because AF_INET6 is specified and no IPv6 interface exists. AI_DEFAULT == (AI_V4MAPPED | AI_ADDRCONFIG) So one could get back a mapped address. But link-local addresses are not kept in the DNS at this time. >If this is correct, perhaps future documentation should be more clear about >getipnodebyname() ignoring flags for this scenario? I think your asking for the counter to what we did describe too? /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 Jul 9 06:42:47 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA11641 for ipng-dist; Fri, 9 Jul 1999 06:39:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11634 for ; Fri, 9 Jul 1999 06:39:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA09489 for ; Fri, 9 Jul 1999 06:39:33 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23698 for ; Fri, 9 Jul 1999 06:39:27 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA189656; Fri, 9 Jul 1999 14:39:25 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA14042; Fri, 9 Jul 1999 14:39:22 +0100 (BST) Message-ID: <3785FAE5.DDF6D3D8@hursley.ibm.com> Date: Fri, 09 Jul 1999 08:36:37 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Mark Sandstrom CC: ipng@sunroof.eng.sun.com Subject: Re: Traffic shaping with IPv6 References: <37851D42.E621A5BE@cyras.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Read RFC 2475 for this question. Brian Mark Sandstrom wrote: > > RFC 2463 (ICMPv6) does not define an ICMPv6 message corresponding to > ICMP (RFC 792) Source Quench message. In addition, RFC 2463 specifies > that "an ICMPv6 message MUST NOT be generated if a packet is dropped due > > to congestion". As it looks like ICMPv6 does not provide means for > traffic volume control, my question is: what in general are the means > for network congestion control with IPv6? > > In particular, my problem is: > What action should a router take to prevent a buffer overflow e.g. in a > case that it receives IPv6 packets (from several sources) destined > towards the same output port with a cumulated volume greater than the > output capacity of that port? > > Any help and pointers to documents discussing this subject are greatly > appreciated. > > Thanks, > > Mark Sandstrom > e-mail: msandstrom@cyras.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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.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 Jul 9 07:39:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA11699 for ipng-dist; Fri, 9 Jul 1999 07:36:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11692 for ; Fri, 9 Jul 1999 07:36:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA14334 for ; Fri, 9 Jul 1999 07:36:33 -0700 (PDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11688 for ; Fri, 9 Jul 1999 07:36:32 -0700 (PDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id KAA29508; Fri, 9 Jul 1999 10:36:23 -0400 (EDT) Message-Id: <199907091436.KAA29508@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Brian E Carpenter cc: Mark Sandstrom , ipng@sunroof.eng.sun.com Subject: Re: Traffic shaping with IPv6 In-reply-to: Your message of "Fri, 09 Jul 1999 08:36:37 CDT." <3785FAE5.DDF6D3D8@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jul 1999 10:36:23 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk And RFC 2309 as well. > Read RFC 2475 for this question. > > Brian > > Mark Sandstrom wrote: [snip] > > In particular, my problem is: > > What action should a router take to prevent a buffer overflow e.g. in a > > case that it receives IPv6 packets (from several sources) destined > > towards the same output port with a cumulated volume greater than the > > output capacity of that port? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)468-8466 x232 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 9 11:08:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA12245 for ipng-dist; Fri, 9 Jul 1999 11:05:23 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12238 for ; Fri, 9 Jul 1999 11:05:17 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id LAA21691 for ipng@sunroof.eng.sun.com; Fri, 9 Jul 1999 11:03:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11388 for ; Fri, 9 Jul 1999 00:30:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA16448 for ; Fri, 9 Jul 1999 00:30:22 -0700 (PDT) Received: from math.uwaterloo.ca (math.uwaterloo.ca [129.97.140.144]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA17112 for ; Fri, 9 Jul 1999 01:30:21 -0600 (MDT) Received: (from nasokan@localhost) by math.uwaterloo.ca (8.8.8/8.8.8) id DAA03892; Fri, 9 Jul 1999 03:30:20 -0400 (EDT) From: Asokan Message-Id: <199907090730.DAA03892@math.uwaterloo.ca> Subject: Question about the privacy extensions for stateless address autoconf draft To: ipng@sunroof.eng.sun.com, narten@raleigh.ibm.com Date: Fri, 9 Jul 1999 03:30:18 -0400 (EDT) Organization: University of Waterloo X-Mailer: ELM [version 2.4 PL25] 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 Thomas, I have a question about your recent draft 'Privacy Extensions for Stateless Address Autoconfiguration in IPv6.' Your requirement 2 states that it should be difficult for an outsider to predict the next interface identifier based on previous ones (actually, requirement 1 is not really necessary if requirement 2 is satisfied). I don't see how the algorithm in Section 3.1 satisfies this requirement. The interface identifier created in Step 3 is used to generate all the temporary addresses. The same identifier is also used to generate the next identifier in a predictable way (i.e., there is no other secret/random input in Step 2). An observer watching traffic can extract the current interface identifier from the src/dst address, and then compute all future interface identifiers, thereby linking subsequent activities of the interface even as the interface identifier changes. Am I missing something? If not, I think something similar to the method in Section 3.2 (which essentially results in a pseudo-random sequence) is the appropriate one. Even here, it is not sufficient to use 'information that [merely] differs from one machine to another' (such as user identity). In order to satisfy your requirement 2, one should use _secret_ information that is not known to outside observers to derive a pseudo-random sequence. Thanks in advance for any clarifications. Regards, - Asokan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 02:12:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA14786 for ipng-dist; Tue, 13 Jul 1999 02:09:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14779 for ; Tue, 13 Jul 1999 02:09:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA26761 for ; Tue, 13 Jul 1999 02:09:05 -0700 (PDT) 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 DAA01309 for ; Tue, 13 Jul 1999 03:09:05 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id EAA16895 for ; Tue, 13 Jul 1999 04:09:04 -0500 (CDT) Message-Id: <199907130909.EAA16895@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Comment on draft-ietf-ipngwg-addrconf-privacy-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16891.931856943.1@gungnir.fnal.gov> Date: Tue, 13 Jul 1999 04:09:04 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As the draft is written, if a node ever reveals its built-in identifier and one "privacy" identifier, all subsequent identifiers can be predicted. If the node uses zeros to start the sequence, then knowledge of the built-in identifier is sufficient. To fix: require starting with random bits, not zero, and keep 128 bits as "history", not 64. (No new random input is then needed to generate more identifiers.) If stable storage is not available aros reboots, require new rndom bits at each boot. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 19:06:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA15510 for ipng-dist; Tue, 13 Jul 1999 19:02:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15503 for ; Tue, 13 Jul 1999 19:02:38 -0700 (PDT) From: sen_ml@eccosys.com Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA01529 for ; Tue, 13 Jul 1999 19:02:40 -0700 (PDT) Received: from nsm.htp.org ([202.241.243.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA06827 for ; Tue, 13 Jul 1999 19:02:39 -0700 (PDT) Received: (qmail 18838 invoked from network); 14 Jul 1999 02:00:46 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 14 Jul 1999 02:00:46 -0000 To: ipng@sunroof.eng.sun.com Subject: Re: Comment on draft-ietf-ipngwg-addrconf-privacy-00.txt In-Reply-To: Your message of "Tue, 13 Jul 1999 04:09:04 -0500" <199907130909.EAA16895@gungnir.fnal.gov> References: <199907130909.EAA16895@gungnir.fnal.gov> X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990714110234J.sen_ml@eccosys.com> Date: Wed, 14 Jul 1999 11:02:34 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At around Tue, 13 Jul 1999 04:09:04 -0500, "Matt Crawford" may have mentioned: > To fix: require starting with random bits, not zero, and keep > 128 bits as "history", not 64. (No new random input is then > needed to generate more identifiers.) If stable storage is not > available aros reboots, require new rndom bits at each boot. what are some ballpark figures regarding collisions of sets of (48, 64, etc.) randomly chosen bits? applying birthday problem reasoning i came up w/ a formula, but i haven't figured out how to solve it via brute force w/ the numbers (too big) involved, yet -- there must be a better way :-) what are the flaws w/ the approach of randomly generating a mac address and then using this to create an eui-64 based identifier as described in appendix a of rfc 2373? specifically, any problems other than potential collisions? is there a generally acceptable collision threshold? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 14 04:47:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA15769 for ipng-dist; Wed, 14 Jul 1999 04:45:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15762 for ; Wed, 14 Jul 1999 04:45:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA07472 for ; Wed, 14 Jul 1999 04:45:02 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA18691 for ; Wed, 14 Jul 1999 04:45:02 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 14 Jul 1999 04:38:47 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2448.0) id <369T32TB>; Wed, 14 Jul 1999 04:38:47 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515582@RED-MSG-50> From: Richard Draves To: "'sen_ml@eccosys.com'" , ipng@sunroof.eng.sun.com Subject: RE: Comment on draft-ietf-ipngwg-addrconf-privacy-00.txt Date: Wed, 14 Jul 1999 04:38:42 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > what are some ballpark figures regarding collisions of sets of (48, > 64, etc.) randomly chosen bits? applying birthday problem reasoning i > came up w/ a formula, but i haven't figured out how to solve it via > brute force w/ the numbers (too big) involved, yet -- there must be a > better way :-) Here's one way to look at it - if you are using n random bits, then it takes 2^(n/2) numbers before the probability of a collision reaches 50%. 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 Wed Jul 14 05:28:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA15886 for ipng-dist; Wed, 14 Jul 1999 05:24:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15879 for ; Wed, 14 Jul 1999 05:24:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA03046; Wed, 14 Jul 1999 05:24:20 -0700 (PDT) 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 GAA02770; Wed, 14 Jul 1999 06:24:19 -0600 (MDT) Received: from new (wldhcp1099.ietf.uninett.no [128.39.10.99]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id FAA07537; Wed, 14 Jul 1999 05:23:43 -0700 (PDT) Message-Id: <3.0.5.32.19990714052247.03bbc100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 14 Jul 1999 05:22:47 -0700 To: narten@raleigh.ibm.com, nordmark@eng.sun.com From: Bob Hinden Subject: Request to Advance "IPv6 Router Alert Option" Cc: scoya@cnri.reston.va.us, deering@cisco.com, 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 Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : IPv6 Router Alert Option Author(s) : D. Katz, C. Partridge, A. Jackson Filename : draft-ietf-ipngwg-ipv6router-alert-05.txt Pages : 5 Date : 21-Jun-99 A working group last call for this document was completed on July 14, 1999 and the document was discussed at the IPng w.g. session held at the Oslo IETF. Bob Hinden / Steve Deering IPng Working Group Co-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 Wed Jul 14 08:38:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA16162 for ipng-dist; Wed, 14 Jul 1999 08:35:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16155 for ; Wed, 14 Jul 1999 08:35:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA27889 for ; Wed, 14 Jul 1999 08:35:26 -0700 (PDT) Received: from aussie.cs.mu.OZ.AU (dhcp31142.ietf.uninett.no [128.39.31.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05603 for ; Wed, 14 Jul 1999 09:35:23 -0600 (MDT) Received: from cs.mu.OZ.AU (localhost [127.0.0.1]) by aussie.cs.mu.OZ.AU (8.8.8/8.8.8) with ESMTP id RAA13434; Wed, 14 Jul 1999 17:35:05 +0200 (CEST) From: Robert Elz To: Matt Crawford cc: namedroppers@internic.net, ipng@sunroof.eng.sun.com Reply-To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-dns-lookups-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 17:35:05 +0200 Message-ID: <13431.931966505@cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, As we discussed in the hall today ... doing name to address translations using A6 records has an interesting new property that might bear some explicit mention in the doc, and perhaps might impact upon some of the APIs. This isn't strictly a DNS issue, the DNS properties don't change as such, but as the library functions (gethostbyname() etc) are generally considered to be DNS related, I have cc'd this to namedroppers, as well as to the ipng list. I think that replies should be confined to the ipng list (so hopefully Randy will oblige and not allow any through to namedroppers...) The issue is that with A6 it becomes possible (without having to stetch your imagination towards absurdities) for the resolver interface (the thing that converts A6 records into 128 bit addresses for the application) to return a partial set of the addresses owned by the name that was being looked up. With correctly functioning servers, that never happens with A (or AAAA) records, if a server returns you any of them, it should be returning you all of them (they're an RRSet in DNS speak, and such a thing is always supposed to be treated as a unit). But while the A6 records at any node in the DNS tree will be a RRSet, they can require extra processing to produce the 128 bit result, and, some of that processing might take longer than other parts. I don't think this is a bad thing, in fact it is probably a good one, provided that applications are aware it can happen, and hopefully, provided there's a way that the application can decide for itself whether it prefers an address, any address, as quickly as possible, or whether it wants the resolver to work as hard as it can and return every address that the DNS suggests should reach the name in question. Since the doc in question here isn't an API doc, saying a lot about this in there probably isn't appropriate. It most probably is appropriate to mention the issue though. 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 Jul 14 11:55:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA16462 for ipng-dist; Wed, 14 Jul 1999 11:50:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16455 for ; Wed, 14 Jul 1999 11:50:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA28115 for ; Wed, 14 Jul 1999 11:50:29 -0700 (PDT) Received: from ib.rc.vix.com (ib.rc.vix.com [204.152.187.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07269 for ; Wed, 14 Jul 1999 12:50:28 -0600 (MDT) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by ib.rc.vix.com (8.9.1/8.9.1) via ESMTP id LAA16529 for ; Wed, 14 Jul 1999 11:50:28 -0700 (PDT) env-from (Bob_Halley@iengines.net) Received: from bb.rc.vix.com (localhost [127.0.0.1]) by bb.rc.vix.com (8.9.1/8.9.1) via ESMTP id LAA25049 for ; Wed, 14 Jul 1999 11:50:28 -0700 (PDT) env-from (Bob_Halley@iengines.net) Message-Id: <199907141850.LAA25049@bb.rc.vix.com> To: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-Reply-To: Message from Robert Elz of "Wed, 14 Jul 1999 17:35:05 +0200." <13431.931966505@cs.mu.OZ.AU> Date: Wed, 14 Jul 1999 11:50:28 -0700 From: Bob Halley Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The issue is that with A6 it becomes possible (without having to stetch > your imagination towards absurdities) for the resolver interface (the thing > that converts A6 records into 128 bit addresses for the application) to > return a partial set of the addresses owned by the name that was being > looked up. Yes. For example, it won't be uncommon for some A6 chains for a name to be complete in a cache, while others are incomplete. Even if the cache at one time had all the chains complete, some of the chains may subsequently have become incomplete because a link was purged due to TTL, signature validity period, or because the space was needed in the cache. A smart application would like to be able to try to use what's in the cache right now, since one of the addresses will probably work, and the delay of getting all of the addresses can be avoided. > I don't think this is a bad thing, in fact it is probably a good one, > provided that applications are aware it can happen, and hopefully, provided > there's a way that the application can decide for itself whether it prefers > an address, any address, as quickly as possible, or whether it wants the > resolver to work as hard as it can and return every address that the DNS > suggests should reach the name in question. Applications which say "give me something quickly" must be prepared to wait longer if their connection attempts with the quick answers fail. If they don't wait, they could turn what might have been a small delay into failure. Simple applications won't want to worry about things like this, so some kind of tradeoff between latency and completeness will have to be made for them. /Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 15 02:52:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA17193 for ipng-dist; Thu, 15 Jul 1999 02:49:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17186 for ; Thu, 15 Jul 1999 02:49:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA10052 for ; Thu, 15 Jul 1999 02:49:44 -0700 (PDT) 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 CAA26411 for ; Thu, 15 Jul 1999 02:49:45 -0700 (PDT) Received: from new (wldhcp10221.ietf.uninett.no [128.39.10.221]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id CAA12087; Thu, 15 Jul 1999 02:49:39 -0700 (PDT) Message-Id: <3.0.5.32.19990715024833.032ccb20@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 15 Jul 1999 02:48:33 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: FYI: IANA [Delegation of IPv6 address space] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Very important milestone for IPv6! Bob >Reply-To: >From: "IANA" >To: >Cc: "'iana'" >Subject: Delegation of IPv6 address space >Date: Wed, 14 Jul 1999 12:32:07 -0700 >X-MSMail-Priority: Normal >X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 >Importance: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 >Sender: owner-iana-announce@ISI.EDU > >Internet Community, > >After much discussion concerning the policy guidelines for the deployment of >IPv6 addresses, in addition to the years of technical development done >throughout the Internet community, the IANA has delegated the initial IPv6 >address space to the regional registries in order to begin immediate >worldwide deployment of IPv6 addresses. > >We would like to thank the current Regional Internet Registries (RIR) for >their invaluable work in the construction of the policy guidelines, which >seem to have general consensus from the Internet community. We would also >like to thank the efforts of the IETF community and the support of the IAB >in making this effort a reality. > >If you have further questions concerning this issue, please contact your >RIR, or you may also contact the IANA at iana@iana.org. > >The policy guidelines can be found online at one of the Regional Internet >Registries: > > http://www.apnic.net > http://www.arin.net > http://www.ripe.net > >This is an historic moment in the continued development of the Internet. > >Thank you for your valuable support and participation in the Internet >community. > >Josh Elliott >On Behalf of the IANA Staff > > > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 16 17:37:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA18714 for ipng-dist; Fri, 16 Jul 1999 17:34:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18707 for ; Fri, 16 Jul 1999 17:34:48 -0700 (PDT) From: Sonum_Mathur@3com.com Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA15727 for ; Fri, 16 Jul 1999 17:34:47 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA12945 for ; Fri, 16 Jul 1999 17:34:47 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id RAA01104 for ; Fri, 16 Jul 1999 17:34:46 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id RAA08039 for ; Fri, 16 Jul 1999 17:34:46 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 882567B1.000329A9 ; Fri, 16 Jul 1999 17:34:32 -0700 X-Lotus-FromDomain: 3COM To: ipng@sunroof.eng.sun.com Message-ID: <882567B1.000327D4.00@hqoutbound.ops.3com.com> Date: Fri, 16 Jul 1999 17:34:32 -0700 Subject: getaddrinfo error Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have installed ftp6 (from inet6apps ver 0.36), telnet6 (from telnet.95.10.23) and chimera (from chimera-2.0a14) for my Linux host. For all of these applications, I am getting the same error 'getaddrinfo : name or service is not known". What could be the possible reason for the error ? The name resolution is working perfectly for ping6 and traceroute6. Also, I have glibc 2.1 installed on my machine. -- Sonum -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 16 21:13:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA18793 for ipng-dist; Fri, 16 Jul 1999 21:10:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18786 for ; Fri, 16 Jul 1999 21:10:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA28401 for ; Fri, 16 Jul 1999 21:10:49 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA29118 for ; Fri, 16 Jul 1999 22:10:48 -0600 (MDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.7.6/8.9.3) with ESMTP id DAA21881; Sat, 17 Jul 1999 03:50:28 GMT Message-Id: <199907170350.DAA21881@inner.net> To: Sonum_Mathur@3com.com cc: ipng@sunroof.eng.sun.com Subject: Re: getaddrinfo error In-reply-to: Your message of "Fri, 16 Jul 1999 17:34:32 PDT." <882567B1.000327D4.00@hqoutbound.ops.3com.com> X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Sat, 17 Jul 1999 00:10:38 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <882567B1.000327D4.00@hqoutbound.ops.3com.com>, you write: >I have installed ftp6 (from inet6apps ver 0.36), telnet6 (from telnet.95.10.23 >and chimera (from chimera-2.0a14) for my Linux host. RTFM under "If you have problems." -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 19 04:31:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA19789 for ipng-dist; Mon, 19 Jul 1999 04:29:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19782 for ; Mon, 19 Jul 1999 04:28:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA07234 for ; Mon, 19 Jul 1999 04:28:53 -0700 (PDT) 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 FAA26171 for ; Mon, 19 Jul 1999 05:28:52 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13979; Mon, 19 Jul 1999 07:28:49 -0400 (EDT) Message-Id: <199907191128.HAA13979@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-url-literal-02.txt Date: Mon, 19 Jul 1999 07:28:49 -0400 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 : Preferred Format for Literal IPv6 Addresses in URL's Author(s) : B. Hinden, B. Carpenter Filename : draft-ietf-ipngwg-url-literal-02.txt Pages : 4 Date : 15-Jul-99 This document defines the preferred format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. This format has been implemented in the IPv6 versions of several widely deployed browsers including Microsoft Internet Explorer, Mozilla, and Lynx. It is also intended to be used in the IPv6 version of the service location protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-url-literal-02.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-url-literal-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-url-literal-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990715080240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-url-literal-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-url-literal-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990715080240.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 Mon Jul 19 04:33:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA19800 for ipng-dist; Mon, 19 Jul 1999 04:32:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19793 for ; Mon, 19 Jul 1999 04:32:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA17887 for ; Mon, 19 Jul 1999 04:32:00 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA28343 for ; Mon, 19 Jul 1999 04:31:58 -0700 (PDT) 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 UAA17193; Mon, 19 Jul 1999 20:31:13 +0900 (JST) To: "Aaron Griggs" cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com In-reply-to: agriggs's message of Fri, 02 Jul 1999 13:29:49 -0400. <035301bec4b0$7d2cd190$634cf526@east.isi.edu> 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: Revised Mobile IPv6 draft available From: itojun@iijlab.net Date: Mon, 19 Jul 1999 20:31:12 +0900 Message-ID: <17191.932383872@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Source address (whether it is ip6_src or home address option) >>is still very important. When you negotiate the key >>with the peer, IKE runs between (src, dst) pair. >Couldn't the source just be selected by the sender? For multiple address on >an interface, the best address is selected. My statements above handles >specifying a source for the SA. Since I am not implementing IKE, I might be >missing something. I may have replied this one, so ignore it if it is a duplicate. IKE must be run over src-dst pair which is to be used by IPsec. If IPsec needs a SA between (src home addr, dst), IKE must be run over (src home addr, dst) pair. This causes nasty bootstrap problem, like: - mobile node wishes to send tcp packet with (src home addr, dst) in the header - SA is looked up between (src home addr, dst) - since there's no SA, IKE daemon is invoked for new key - IKE daemon tries to send udp port 500 packet over (src home addr, dst) - infinite loop I've talked with Dave at Oslo IETF, about how mobile-ipv6 packet must be processed on inbound and outbound case, with regard to ipsec. He will be sending addition to the draft onto the list. 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 Mon Jul 19 07:30:11 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA20287 for ipng-dist; Mon, 19 Jul 1999 07:27:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20280 for ; Mon, 19 Jul 1999 07:26:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA12597 for ; Mon, 19 Jul 1999 07:26:21 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21575 for ; Mon, 19 Jul 1999 07:26:17 -0700 (PDT) Received: from localhost (kame201.kame.net [203.178.141.201]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id XAA12201; Mon, 19 Jul 1999 23:20:27 +0900 (JST) Date: Mon, 19 Jul 1999 23:30:28 +0900 Message-ID: <14227.13956.816549.46688D@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.OZ.AU Subject: how to prohibit an application from sending a jumbo payload opt User-Agent: Wanderlust/2.1.2 (Rico Suave) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 39 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk draft-ietf-ipngwg-2292bis-00 says that we should prohibit a userland application from including a jumbo payload option in a hop-by-hop options header when the application sends a packet: The Jumbo Payload option should not be passed back to an application and an application should receive an error if it attempts to set it. (the second paragraph of section 7, page 30.) I agree that we need some kind of restriction on sending a packet with a hop-by-hop options header. However, IMO, the behavior described in the draft is too heavy for the kernel. The kernel has to parse all options in a hop-by-hop options header passed from an application in order to check whether or not a jumbo payload option is mistakenly included. (Note that an application can set a jumbo payload option in any position of a hop-by-hop options header using inet6_opt_xxx library functions.) Moreover, the check must be done for every packet when the application uses a raw/UDP socket. I'd prefer the following approach: - simply prohibit an application from setting a hop-by-hop options header(i.e. not special type of options) in a sending packet unless the application has some privilege(e.g. the super user privilege). - if we need an application which may send a hop-by-hop options header and can be used by a normal user, temporarily give the privilege to the user(using, for example, setuid operation). Erik Nordmark(@Sun, who is one of the authors of the draft) suggested me to ask other implementors' opinion. So I posted here. How do you think of this issue as implementors? I'd appreciate any comments. Thanks, JINMEI, Tatuya Communication Platform Laboratory Corporate R&D Center, Toshiba 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 Jul 19 11:28:29 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA20658 for ipng-dist; Mon, 19 Jul 1999 11:22:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20651 for ; Mon, 19 Jul 1999 11:22:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA26341 for ; Mon, 19 Jul 1999 11:22:45 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12439 for ; Mon, 19 Jul 1999 11:22:44 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.7.6/8.9.3) with ESMTP id SAA25148; Mon, 19 Jul 1999 18:00:35 GMT Message-Id: <199907191800.SAA25148@inner.net> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: how to prohibit an application from sending a jumbo payload opt In-reply-to: Your message of "Mon, 19 Jul 1999 23:30:28 +0900." <14227.13956.816549.46688D@condor.isl.rdc.toshiba.co.jp> X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Mon, 19 Jul 1999 14:22:21 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <14227.13956.816549.46688D@condor.isl.rdc.toshiba.co.jp>, you write: >I agree that we need some kind of restriction on sending a packet with >a hop-by-hop options header. However, IMO, the behavior described in >the draft is too heavy for the kernel. The kernel has to parse all >options in a hop-by-hop options header passed from an application in >order to check whether or not a jumbo payload option is mistakenly >included. (Note that an application can set a jumbo payload option in >any position of a hop-by-hop options header using inet6_opt_xxx >library functions.) Moreover, the check must be done for every packet >when the application uses a raw/UDP socket. I believe that having the application send the kernel fully formed options headers is inherently flawed. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 19 11:53:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA20703 for ipng-dist; Mon, 19 Jul 1999 11:42:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20696 for ; Mon, 19 Jul 1999 11:42:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA01568 for ; Mon, 19 Jul 1999 11:42:03 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22429 for ; Mon, 19 Jul 1999 11:42:02 -0700 (PDT) Received: from localhost (kame201.kame.net [203.178.141.201]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id DAA12767 for ; Tue, 20 Jul 1999 03:36:12 +0900 (JST) Date: Tue, 20 Jul 1999 03:46:10 +0900 Message-ID: <14227.29298.769378.81364V@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: how to prohibit an application from sending a jumbo payload opt In-Reply-To: In your message of "Mon, 19 Jul 1999 14:22:21 -0400" <199907191800.SAA25148@inner.net> References: <14227.13956.816549.46688D@condor.isl.rdc.toshiba.co.jp> <199907191800.SAA25148@inner.net> User-Agent: Wanderlust/2.1.2 (Rico Suave) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 19 Jul 1999 14:22:21 -0400, >>>>> Craig Metz said: > In message <14227.13956.816549.46688D@condor.isl.rdc.toshiba.co.jp>, you write: >> I agree that we need some kind of restriction on sending a packet with >> a hop-by-hop options header. However, IMO, the behavior described in >> the draft is too heavy for the kernel. The kernel has to parse all >> options in a hop-by-hop options header passed from an application in >> order to check whether or not a jumbo payload option is mistakenly >> included. (Note that an application can set a jumbo payload option in >> any position of a hop-by-hop options header using inet6_opt_xxx >> library functions.) Moreover, the check must be done for every packet >> when the application uses a raw/UDP socket. (To make sure of it:) I didn't mean that an application should correctly set all options including a jumbo payload option. Some options, of course, should be set in the kernel automatically. > I believe that having the application send the kernel fully formed options > headers is inherently flawed. So do you have any good idea? Should we adopt a completely different API? JINMEI, Tatuya Communication Platform Laboratory Corporate R&D Center, Toshiba 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 Jul 19 11:58:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA20724 for ipng-dist; Mon, 19 Jul 1999 11:53:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20717 for ; Mon, 19 Jul 1999 11:53:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA02484 for ; Mon, 19 Jul 1999 11:53:41 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA28363 for ; Mon, 19 Jul 1999 11:53:39 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA06925; Mon, 19 Jul 1999 11:53:03 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA10769; Mon, 19 Jul 1999 11:53:02 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id LAA05584; Mon, 19 Jul 1999 11:53:08 -0700 (PDT) Date: Mon, 19 Jul 1999 11:53:08 -0700 (PDT) From: Tim Hartrick Message-Id: <199907191853.LAA05584@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp Subject: Re: how to prohibit an application from sending a jumbo payload opt Cc: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > draft-ietf-ipngwg-2292bis-00 says that we should prohibit a userland > application from including a jumbo payload option in a hop-by-hop > options header when the application sends a packet: > > The Jumbo Payload option should not > be passed back to an application and an application should receive an > error if it attempts to set it. > (the second paragraph of section 7, page 30.) > > I agree that we need some kind of restriction on sending a packet with > a hop-by-hop options header. However, IMO, the behavior described in > the draft is too heavy for the kernel. The kernel has to parse all > options in a hop-by-hop options header passed from an application in > order to check whether or not a jumbo payload option is mistakenly > included. (Note that an application can set a jumbo payload option in > any position of a hop-by-hop options header using inet6_opt_xxx > library functions.) Moreover, the check must be done for every packet > when the application uses a raw/UDP socket. > > I'd prefer the following approach: > > - simply prohibit an application from setting a hop-by-hop > options header(i.e. not special type of options) in a sending > packet unless the application has some privilege(e.g. the super > user privilege). > - if we need an application which may send a hop-by-hop options > header and can be used by a normal user, temporarily give the > privilege to the user(using, for example, setuid operation). > > Erik Nordmark(@Sun, who is one of the authors of the draft) suggested > me to ask other implementors' opinion. So I posted here. How do you > think of this issue as implementors? I'd appreciate any comments. > I am not convinced that there is any need to forbid the user from sending or receiving the jumbo payload option. The worst that the user can do is send illegal options out on the wire which will be discarded by the receiver. If an application receives the jumbo payload option I don't see what damage can be done with the information. Searching for the option so that it can be removed looks like a bunch of work for no reason at all. This is more or less how IP options have worked forever. I don't see any reason to make the sending of hop-by-hop or any options privileged. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 19 12:09:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20807 for ipng-dist; Mon, 19 Jul 1999 12:06:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20800 for ; Mon, 19 Jul 1999 12:06:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA14252 for ; Mon, 19 Jul 1999 12:06:47 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05698 for ; Mon, 19 Jul 1999 12:06:46 -0700 (PDT) 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 EAA27002; Tue, 20 Jul 1999 04:06:11 +0900 (JST) To: Tim Hartrick cc: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au In-reply-to: tim's message of Mon, 19 Jul 1999 11:53:08 MST. <199907191853.LAA05584@feller.mentat.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: how to prohibit an application from sending a jumbo payload opt From: itojun@iijlab.net Date: Tue, 20 Jul 1999 04:06:10 +0900 Message-ID: <27000.932411170@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I am not convinced that there is any need to forbid the user from sending >or receiving the jumbo payload option. The worst that the user can do is >send illegal options out on the wire which will be discarded by the receiver. >If an application receives the jumbo payload option I don't see what damage >can be done with the information. Searching for the option so that it can >be removed looks like a bunch of work for no reason at all. This is more or >less how IP options have worked forever. Some of the extension headers are okay to be modified/seen from the userland, some are not. AH, ESP, and mobility options are apparently not to be touched from advaned API. I believe jumbogram falls into the category. (it needs to be used together with other code, like TCP/UDP. userland can not do much about it) 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 Mon Jul 19 12:29:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20842 for ipng-dist; Mon, 19 Jul 1999 12:22:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20835 for ; Mon, 19 Jul 1999 12:22:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA20243 for ; Mon, 19 Jul 1999 12:22:40 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14213 for ; Mon, 19 Jul 1999 12:22:39 -0700 (PDT) Received: from localhost (kame201.kame.net [203.178.141.201]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id EAA12879; Tue, 20 Jul 1999 04:16:51 +0900 (JST) Date: Tue, 20 Jul 1999 04:26:50 +0900 Message-ID: <14227.31738.495686.9765Q@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Subject: Re: how to prohibit an application from sending a jumbo payload opt In-Reply-To: In your message of "Mon, 19 Jul 1999 11:53:08 -0700 (PDT)" <199907191853.LAA05584@feller.mentat.com> References: <199907191853.LAA05584@feller.mentat.com> User-Agent: Wanderlust/2.1.2 (Rico Suave) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 40 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 19 Jul 1999 11:53:08 -0700 (PDT), >>>>> Tim Hartrick said: >> - simply prohibit an application from setting a hop-by-hop >> options header(i.e. not special type of options) in a sending >> packet unless the application has some privilege(e.g. the super >> user privilege). >> - if we need an application which may send a hop-by-hop options >> header and can be used by a normal user, temporarily give the >> privilege to the user(using, for example, setuid operation). > I am not convinced that there is any need to forbid the user from sending > or receiving the jumbo payload option. The worst that the user can do is > send illegal options out on the wire which will be discarded by the receiver. > If an application receives the jumbo payload option I don't see what damage > can be done with the information. Searching for the option so that it can > be removed looks like a bunch of work for no reason at all. This is more or > less how IP options have worked forever. > I don't see any reason to make the sending of hop-by-hop or any options > privileged. Hmm...to tell the truth, I don't see any special reason, either. However, there has been restriction on kind of options that can affect the IP header or some other important fields of the packet. For example, access to bpf is usually restricted to privileged users. Even opening a raw socket is restricted. My suggestion is thus based on such a conservative point of view. For receiver side, I totally agree with you; there is no damage with a receiving jumbo payload option. In fact, I asked Erik to remove the unnecessary (at least for me) restriction from the draft. In any case, the important point for me is to keep the kernel simple, especially when we can do so. JINMEI, Tatuya Communication Platform Laboratory Corporate R&D Center, Toshiba 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 Jul 19 12:30:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20851 for ipng-dist; Mon, 19 Jul 1999 12:29:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20844 for ; Mon, 19 Jul 1999 12:28:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA08691 for ; Mon, 19 Jul 1999 12:28:41 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02373 for ; Mon, 19 Jul 1999 13:28:40 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA07151; Mon, 19 Jul 1999 12:28:11 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA11569; Mon, 19 Jul 1999 12:28:11 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id MAA05602; Mon, 19 Jul 1999 12:28:17 -0700 (PDT) Date: Mon, 19 Jul 1999 12:28:17 -0700 (PDT) From: Tim Hartrick Message-Id: <199907191928.MAA05602@feller.mentat.com> To: itojun@iijlab.net Subject: Re: how to prohibit an application from sending a jumbo payload opt Cc: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > > >I am not convinced that there is any need to forbid the user from sending > >or receiving the jumbo payload option. The worst that the user can do is > >send illegal options out on the wire which will be discarded by the receiver. > >If an application receives the jumbo payload option I don't see what damage > >can be done with the information. Searching for the option so that it can > >be removed looks like a bunch of work for no reason at all. This is more or > >less how IP options have worked forever. > > Some of the extension headers are okay to be modified/seen from the > userland, some are not. AH, ESP, and mobility options are apparently > not to be touched from advaned API. I believe jumbogram falls into > the category. (it needs to be used together with other code, like > TCP/UDP. userland can not do much about it) > I am not arguing that user applications should add things like the various mobility options to their packet. Clearly, applications shouldn't do this. I am arguing that if we allow applications to build completely arbitrary options headers these applications can only harm themselves by adding jumbo payload or mobility options to their datagrams. If these busted applications can't harm the host system or other systems then there is no upside to making the kernel more complicated to protect the system from nonexistent threat. Is there some damage an application can do to its host system or other systems by being able to create arbitrary hop-by-hop or destination options headers and receive all the contents of hop-by-hop or destination options headers? Obviously, AH and ESP are in a very different category entirely. These are extension headers that should never be passed in from or passed out to user space. The current advanced API rightly forbids this by simply not allowing raw packet headers to be passed to and from the kernel. I was not suggesting that this change. We were discussing hop-by-hop and destination options headers. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 19 12:49:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20896 for ipng-dist; Mon, 19 Jul 1999 12:45:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20889 for ; Mon, 19 Jul 1999 12:45:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA20411 for ; Mon, 19 Jul 1999 12:45:27 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08341 for ; Mon, 19 Jul 1999 13:45:27 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA07301; Mon, 19 Jul 1999 12:44:57 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA11947; Mon, 19 Jul 1999 12:44:57 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id MAA05611; Mon, 19 Jul 1999 12:45:03 -0700 (PDT) Date: Mon, 19 Jul 1999 12:45:03 -0700 (PDT) From: Tim Hartrick Message-Id: <199907191945.MAA05611@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp Subject: Re: how to prohibit an application from sending a jumbo payload opt Cc: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > Hmm...to tell the truth, I don't see any special reason, > either. However, there has been restriction on kind of options that > can affect the IP header or some other important fields of the > packet. For example, access to bpf is usually restricted to privileged > users. Even opening a raw socket is restricted. My suggestion is thus > based on such a conservative point of view. > Sure raw sockets have traditionally been privileged. I was not suggesting that this change. Note however that that prohibition probably doesn't have anything to do with prohibiting the sending of broken options. If one wants to send datagrams with busted options (IPv4 or IPv6) you can simply open a UDP socket and have at it. I believe that prohibition exists because raw sockets allow for the sending of datagrams from arbitrary protocols like IPPROTO_TCP, IPPROTO_UDP and IPPROTO_OSPF. Clearly, this facility can be used to cause significant problems for the host system and other systems on the network. The damage that can be done with bpf is obvious. > For receiver side, I totally agree with you; there is no damage with a > receiving jumbo payload option. In fact, I asked Erik to remove the > unnecessary (at least for me) restriction from the draft. > > In any case, the important point for me is to keep the kernel simple, > especially when we can do so. > 100% agree. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 19 12:54:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20921 for ipng-dist; Mon, 19 Jul 1999 12:52:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20914 for ; Mon, 19 Jul 1999 12:52:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA21596 for ; Mon, 19 Jul 1999 12:52:49 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10858 for ; Mon, 19 Jul 1999 13:52:47 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id VAA20637; Mon, 19 Jul 1999 21:52:33 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id VAA07191; Mon, 19 Jul 1999 21:52:33 +0200 (MET DST) Message-Id: <199907191952.VAA07191@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Subject: Re: how to prohibit an application from sending a jumbo payload opt In-reply-to: Your message of Tue, 20 Jul 1999 04:26:50 +0900. <14227.31738.495686.9765Q@condor.isl.rdc.toshiba.co.jp> Date: Mon, 19 Jul 1999 21:52:33 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: For example, access to bpf is usually restricted to privileged users. => this is for security reasons: it is too easy to grab passwords if any user can read and with write you can abort TCP connections, ... (only IPSEC can make this more safe) Even opening a raw socket is restricted. => in fact for many ICMPv6 packets it should be nice to have unrestricted socket. Alain Durand works with a student on an ICMPv6 socket API without special priviledges... For receiver side, I totally agree with you; there is no damage with a receiving jumbo payload option. In fact, I asked Erik to remove the unnecessary (at least for me) restriction from the draft. => only AH and ESP have no usage for users (they need SAs, no the bits). Let users build junk options... In any case, the important point for me is to keep the kernel simple, especially when we can do so. => there are already far too many things in kernels! Regards Francis.Dupont@inria.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 Jul 20 07:07:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA22596 for ipng-dist; Tue, 20 Jul 1999 07:04:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22589 for ; Tue, 20 Jul 1999 07:04:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA06729 for ; Tue, 20 Jul 1999 07:04:07 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07319 for ; Tue, 20 Jul 1999 07:04:05 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1040:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id WAA14151; Tue, 20 Jul 1999 22:58:02 +0900 (JST) Date: Tue, 20 Jul 1999 23:08:07 +0900 Message-ID: <14228.33479.683446.36620E@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@inria.fr Cc: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Subject: Re: how to prohibit an application from sending a jumbo payload opt In-Reply-To: In your message of "Mon, 19 Jul 1999 21:52:33 +0200" <199907191952.VAA07191@givry.inria.fr> References: <14227.31738.495686.9765Q@condor.isl.rdc.toshiba.co.jp> <199907191952.VAA07191@givry.inria.fr> User-Agent: Wanderlust/2.1.2 (Rico Suave) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 39 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 19 Jul 1999 21:52:33 +0200, >>>>> Francis Dupont said: > For example, access to bpf is usually restricted to privileged users. > => this is for security reasons: it is too easy to grab passwords if > any user can read and with write you can abort TCP connections, ... > (only IPSEC can make this more safe) Right. The bpf example might not have been a good one...I meant that: if the restriction of sending jumbo opt described in the draft came from some security reasons, I'd follow the rule. But I don't like to make the kernel code too complex for that purpose. I'd rather prohibit sending the entire hop-by-hop header. If there is no security issue of sending a jumbo opt, we should of course eliminate any restrictions. > For receiver side, I totally agree with you; there is no damage with a > receiving jumbo payload option. In fact, I asked Erik to remove the > unnecessary (at least for me) restriction from the draft. > => only AH and ESP have no usage for users (they need SAs, no the bits). > Let users build junk options... I'm sorry, but I missed your point...how do AH and ESP relate to receiving a jumbo opt? > In any case, the important point for me is to keep the kernel simple, > especially when we can do so. > => there are already far too many things in kernels! Yes, but it doesn't mean we need no effort to make the kernel simpler. JINMEI, Tatuya Communication Platform Laboratory Corporate R&D Center, Toshiba 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 Jul 20 09:24:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA22917 for ipng-dist; Tue, 20 Jul 1999 09:21:03 -0700 (PDT) Received: from hsmpka.eng.sun.com (hsmpka [129.146.55.47] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA22903 for ; Tue, 20 Jul 1999 09:20:50 -0700 (PDT) Received: from finesse by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA27841; Tue, 20 Jul 1999 09:20:48 -0700 Message-Id: <199907201620.JAA27841@hsmpka.eng.sun.com> Date: Tue, 20 Jul 1999 09:18:05 -0700 (PDT) From: Charles Perkins Reply-To: Charles Perkins Subject: Mobile Policy Table To: ipng@sunroof.eng.sun.com Cc: "Mary G. Baker" MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cJs6HWWNbzOKuH9CQeHw4g== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, During the recent ipng working group meeting, we had a long discussion about multi-homing. Selection of source IP address is an interesting problem for applications running on a multi-homed computer. I mentioned that there had been some relevant work done at Stanford, in the context of Mobile IP (for IPv4). In that context, the application might under some circumstances prefer to use the computer's home address, or in other circumstances it might prefer to use the more ephemeral care-of address. The following paper discusses the use of a proposed Mobile Policy Table to assist with making the selection: X. Zhao, C. Castelluccia, and M. Baker, "Flexible Network Support for Mobility." Proceedings of Mobicom'98, Dallas, Texas, October 1998. This paper is available at: http://mosquitonet.stanford.edu/ I think that such an approach might be adapted for solving the problem of selecting a source IP address for general multi-homed computers. Having a care-of address and a home address is just one case of multi-homing, albeit a case with a fairly clear set of criteria for making the selection. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 10:30:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA23159 for ipng-dist; Tue, 20 Jul 1999 10:24:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23150 for ; Tue, 20 Jul 1999 10:24:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA00110 for ; Tue, 20 Jul 1999 10:24:44 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14117 for ; Tue, 20 Jul 1999 10:24:40 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1040:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id CAA14583; Wed, 21 Jul 1999 02:18:23 +0900 (JST) Date: Wed, 21 Jul 1999 02:28:30 +0900 Message-ID: <14228.45502.376427.97972S@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com Cc: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Subject: Re: how to prohibit an application from sending a jumbo payload opt In-Reply-To: In your message of "Mon, 19 Jul 1999 12:45:03 -0700 (PDT)" <199907191945.MAA05611@feller.mentat.com> References: <199907191945.MAA05611@feller.mentat.com> User-Agent: Wanderlust/2.1.2 (Rico Suave) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 19 Jul 1999 12:45:03 -0700 (PDT), >>>>> Tim Hartrick said: > Sure raw sockets have traditionally been privileged. I was not suggesting > that this change. Note however that that prohibition probably doesn't have > anything to do with prohibiting the sending of broken options. If one wants > to send datagrams with busted options (IPv4 or IPv6) you can simply open a UDP > socket and have at it. I believe that prohibition exists because raw sockets > allow for the sending of datagrams from arbitrary protocols like IPPROTO_TCP, > IPPROTO_UDP and IPPROTO_OSPF. Clearly, this facility can be used to cause > significant problems for the host system and other systems on the network. Okay, so your position is that we don't need any restriction (including the spec discribed in the 2292bis draft) on sending a jumbo payload option or even on sending a whole hop-by-hop opt header, right? IMO, it depends on how we regard allowing a user to freely send a hop-by-hop option. I basically agree with you, but someone may warry that a busted option annoys the receiver's system and sometimes cause a DoS attack. I'd like to know others' opinion, especially the authors' one. JINMEI, Tatuya Communication Platform Laboratory Corporate R&D Center, Toshiba 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 Jul 20 10:45:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA23259 for ipng-dist; Tue, 20 Jul 1999 10:42:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23252 for ; Tue, 20 Jul 1999 10:41:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA04097 for ; Tue, 20 Jul 1999 10:41:54 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01666 for ; Tue, 20 Jul 1999 11:41:39 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA11385; Tue, 20 Jul 1999 10:40:52 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA29735; Tue, 20 Jul 1999 10:40:52 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id KAA05940; Tue, 20 Jul 1999 10:41:05 -0700 (PDT) Date: Tue, 20 Jul 1999 10:41:05 -0700 (PDT) From: Tim Hartrick Message-Id: <199907201741.KAA05940@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp Subject: Re: how to prohibit an application from sending a jumbo payload opt Cc: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > Okay, so your position is that we don't need any restriction > (including the spec discribed in the 2292bis draft) on sending a jumbo > payload option or even on sending a whole hop-by-hop opt header, > right? > In the case of the jumbo payload option, yes, that is my position. The worst case is that the application adds a jumbo payload option which results in an illegal datagram being sent to the destination. The destination will simply discard the broken datagram. > IMO, it depends on how we regard allowing a user to freely send a > hop-by-hop option. I basically agree with you, but someone may warry > that a busted option annoys the receiver's system and sometimes cause > a DoS attack. I'd like to know others' opinion, especially the > authors' one. > Indeed, it is easy to imagine options which could be defined that could be used in a DOS attack. That would be a serious problem and we probably should avoid defining such options if possible. If we need such options then they would need to be destination options which get placed after an AH header. That is, they would need to be authenticated before they were processed. The only ones I know of at this time which MIGHT have such a problem would be the mobility options. I have not read this spec in a long time so I can't say with any degree of certainty that all these options are benign if added to a datagram incorrectly. Hopefully folks that have more experience with the IPv6 mobility spec and its interactions with IPSec can give us the skinny on the security con- siderations for the various mobility options. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 11:15:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA23320 for ipng-dist; Tue, 20 Jul 1999 11:12:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23313 for ; Tue, 20 Jul 1999 11:12:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA28994 for ; Tue, 20 Jul 1999 11:12:08 -0700 (PDT) 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 LAA09926 for ; Tue, 20 Jul 1999 11:12:07 -0700 (PDT) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id LAA03622; Tue, 20 Jul 1999 11:11:40 -0700 (PDT) Message-Id: <3.0.5.32.19990720111037.008dce80@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 20 Jul 1999 11:10:37 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 : Preferred Format for Literal IPv6 Addresses in URL's Author(s) : B. Hinden, B. Carpenter Filename : draft-ietf-ipngwg-url-literal-02.txt Pages : 4 Date : 15-Jul-99 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 August 3, 1999. 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 Jul 20 11:29:49 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA23374 for ipng-dist; Tue, 20 Jul 1999 11:23:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23367 for ; Tue, 20 Jul 1999 11:23:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA01074 for ; Tue, 20 Jul 1999 11:23:48 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18830 for ; Tue, 20 Jul 1999 12:23:44 -0600 (MDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.7.6/8.9.3) with ESMTP id SAA28216; Tue, 20 Jul 1999 18:22:52 GMT Message-Id: <199907201822.SAA28216@inner.net> To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" In-reply-to: Your message of "Tue, 20 Jul 1999 11:10:37 PDT." <3.0.5.32.19990720111037.008dce80@mailhost.iprg.nokia.com> X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 20 Jul 1999 14:23:16 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3.0.5.32.19990720111037.008dce80@mailhost.iprg.nokia.com>, you writ e: >This is a IPng working group last call for comments on advancing the >following document as a Proposed Standard: > > Title : Preferred Format for Literal IPv6 Addresses in URL's > Author(s) : B. Hinden, B. Carpenter > Filename : draft-ietf-ipngwg-url-literal-02.txt > Pages : 4 > Date : 15-Jul-99 > >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 August 3, 1999. Please choose a delimiter character that is not interpreted as a special character by *IX shells. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 12:34:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA23484 for ipng-dist; Tue, 20 Jul 1999 12:32:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23477 for ; Tue, 20 Jul 1999 12:31:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA08158 for ; Tue, 20 Jul 1999 12:31:54 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14434 for ; Tue, 20 Jul 1999 13:31:49 -0600 (MDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.7.6/8.9.3) with ESMTP id TAA28358; Tue, 20 Jul 1999 19:31:29 GMT Message-Id: <199907201931.TAA28358@inner.net> To: Francis Dupont cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" In-reply-to: Your message of "Tue, 20 Jul 1999 21:29:28 +0200." <199907201929.VAA15595@givry.inria.fr> X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 20 Jul 1999 15:31:24 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199907201929.VAA15595@givry.inria.fr>, you write: > In your previous mail you wrote: > > Please choose a delimiter character that is not interpreted as a special > character by *IX shells. > >=> too late, there are many URLs with '?' characters in them >(and '?' is a special character for UNIX shells)... We cannot fix what is wrong with the web (well, with a time machine and a two by four, maybe), but we can try to prevent new wrongs. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 12:34:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA23472 for ipng-dist; Tue, 20 Jul 1999 12:29:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23465 for ; Tue, 20 Jul 1999 12:29:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA07913 for ; Tue, 20 Jul 1999 12:29:41 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25327 for ; Tue, 20 Jul 1999 12:29:40 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id VAA14193; Tue, 20 Jul 1999 21:29:29 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id VAA15595; Tue, 20 Jul 1999 21:29:29 +0200 (MET DST) Message-Id: <199907201929.VAA15595@givry.inria.fr> From: Francis Dupont To: Craig Metz cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" In-reply-to: Your message of Tue, 20 Jul 1999 14:23:16 EDT. <199907201822.SAA28216@inner.net> Date: Tue, 20 Jul 1999 21:29:28 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Please choose a delimiter character that is not interpreted as a special character by *IX shells. => too late, there are many URLs with '?' characters in them (and '?' is a special character for UNIX shells)... Francis.Dupont@inria.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 Jul 20 15:04:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA23624 for ipng-dist; Tue, 20 Jul 1999 15:01:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23617 for ; Tue, 20 Jul 1999 15:01:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA08462 for ; Tue, 20 Jul 1999 15:01:02 -0700 (PDT) Received: from hecky.acns.nwu.edu (hecky.acns.nwu.edu [129.105.16.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA03283 for ; Tue, 20 Jul 1999 16:01:00 -0600 (MDT) Received: (from mailnull@localhost) by hecky.acns.nwu.edu (8.8.7/8.8.7) id RAA00474; Tue, 20 Jul 1999 17:00:59 -0500 (CDT) Received: from dhcp196.it.nwu.edu(129.105.237.196) by hecky.acns.nwu.edu via smap (V2.0) id xma000331; Tue, 20 Jul 99 17:00:32 -0500 Message-ID: <3794F10E.546D048E@hursley.ibm.com> Date: Tue, 20 Jul 1999 16:58:38 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Craig Metz CC: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" References: <199907201822.SAA28216@inner.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, > Please choose a delimiter character that is not interpreted as a special > character by *IX shells. Please be more specific. Are you objecting to [] ? If so what is your counter-proposal; it has to be reasonably intuitive as well as being possible to fit into the URL syntax. 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 Jul 20 15:07:00 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA23642 for ipng-dist; Tue, 20 Jul 1999 15:05:09 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23635 for ; Tue, 20 Jul 1999 15:05:04 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id PAA01419 for ipng@sunroof.eng.sun.com; Tue, 20 Jul 1999 15:03:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23403 for ; Tue, 20 Jul 1999 11:40:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA16697 for ; Tue, 20 Jul 1999 11:40:21 -0700 (PDT) Received: from exchange.concordia.ab.ca (dns.concordia.ab.ca [199.185.120.34]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26255 for ; Tue, 20 Jul 1999 11:40:20 -0700 (PDT) Received: from strobe (strobe.concordia.ab.ca [199.185.121.46]) by exchange.concordia.ab.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id NPY6B54H; Tue, 20 Jul 1999 12:40:31 -0600 Message-ID: <011901bed2de$eb3d7a40$2e79b9c7@admin.concordia.ab.ca> From: "Ed Boraas" To: , "Bob Hinden" References: <3.0.5.32.19990720111037.008dce80@mailhost.iprg.nokia.com> Subject: Re: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" Date: Tue, 20 Jul 1999 12:37:28 -0600 Organization: http://www.ed.boraas.ca 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 ----- Original Message ----- From: Bob Hinden To: Sent: Tuesday, July 20, 1999 12:10 PM Subject: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" > This is a IPng working group last call for comments on advancing the > following document as a Proposed Standard: > > Title : Preferred Format for Literal IPv6 Addresses in URL's > Author(s) : B. Hinden, B. Carpenter > Filename : draft-ietf-ipngwg-url-literal-02.txt > Pages : 4 > Date : 15-Jul-99 > > 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 August 3, 1999. Hello there. I am concerned that the choice of brackets as an enclosure for IPv6 addresses in URLs may cause problems for people using UNIX and UNIX-like OSes, as most shells interpret the brackets as special characters. One could not (if I am not mistaken), invoke lynx from the commandline as follows: lynx http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html but would rather have to use backslash escapes, like this: http://\[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210\]:80/index.html If there is a possibility of choosing another, non-"special" character, I would heartily endorse the change. Yours, Ed Boraas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 15:43:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA23691 for ipng-dist; Tue, 20 Jul 1999 15:37:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23684 for ; Tue, 20 Jul 1999 15:37:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA26832 for ; Tue, 20 Jul 1999 15:37:24 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA23318 for ; Tue, 20 Jul 1999 16:37:24 -0600 (MDT) Received: from 157.54.9.125 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Jul 1999 15:35:21 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2524.0) id ; Tue, 20 Jul 1999 15:35:16 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515603@RED-MSG-50> From: Richard Draves To: "'IPng List'" Cc: "'Petri Helenius'" , "'Perry E. Metzger'" , Magnus Ahltorp , Craig Metz , Joe Abley , "'kuznet@ms2.inr.ac.ru'" , "'Robert Rockell'" Subject: RE: Bad routes update Date: Tue, 20 Jul 1999 15:35:04 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (I would like to move the main thrust of the discussion from the 6bone list to the ipng list.) Someone expressed the thought that multihoming is being swept under the rug... I don't think so. We spent considerable time on the subject in Oslo and I believe there was a consensus to plan an interim WG meeting with multihoming being a major focus. Perry said: > Think of it from a systematic viewpoint. Is there actually a > way for a > multi-homed host both to get service from "two parts of the tree" and > yet not announce that into the default free zone? Thinking about it > for several minutes indicates "no". I think giving the multi-homed host two addresses (one for each part of the tree) is the beginning of a "yes" answer. It shifts the problem from the network backbone (routing scalability) to the network periphery (when to use which address). Petri said: > But having all TCP sessions reset when topology converges is > a showstopper for IPv6 deployment. I was disappointed when there was no controversy around this point in Oslo... There are a several arguments for why TCP session survival when topology changes is not crucial: - Most application use is for the web. Web TCP sessions are very short-lived and if there is a problem, the user will just use stop/reload. - Mission-critical applications already have logic for reliability above TCP. (Transactions, restarting transfers, etc.) The Internet today is just not reliable enough to rely entirely on TCP's guarantees for mission-critical applications. - BGP reacts/converges very slowly to topology changes. I've recently seen data that indicates convergence usually takes minutes and there is a heavy tail of very long convergence times. So even if you use a single prefix and rely on BGP for fail over, you will often see poor results. That said, one element of the Oslo proposal was an RFC 2260-style solution - one benefit of that approach is survivability of existing TCP connections. 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 Jul 20 16:02:29 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA23713 for ipng-dist; Tue, 20 Jul 1999 15:56:37 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23706 for ; Tue, 20 Jul 1999 15:56:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA15690 for ; Tue, 20 Jul 1999 15:56:18 -0700 (PDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA22985 for ; Tue, 20 Jul 1999 15:56:16 -0700 (PDT) Received: by jekyll.piermont.com (Postfix, from userid 1000) id EE91511B; Tue, 20 Jul 1999 18:56:12 -0400 (EDT) To: Richard Draves Cc: "'IPng List'" , "'Petri Helenius'" , Magnus Ahltorp , Craig Metz , Joe Abley , "'kuznet@ms2.inr.ac.ru'" , "'Robert Rockell'" Subject: Re: Bad routes update References: <4D0A23B3F74DD111ACCD00805F31D81014515603@RED-MSG-50> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 20 Jul 1999 18:56:12 -0400 In-Reply-To: Richard Draves's message of "Tue, 20 Jul 1999 15:35:04 -0700" Message-ID: <87pv1nszg3.fsf@jekyll.piermont.com> Lines: 61 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Draves writes: > (I would like to move the main thrust of the discussion from the 6bone list > to the ipng list.) Fine with me. > I think giving the multi-homed host two addresses (one for each part of the > tree) is the beginning of a "yes" answer. It shifts the problem from the > network backbone (routing scalability) to the network periphery (when to use > which address). It won't work. It means that if the network routing to one of the addresses dies, the TCP connections die. > Petri said: > > But having all TCP sessions reset when topology converges is > > a showstopper for IPv6 deployment. > > I was disappointed when there was no controversy around this point in > Oslo... There are a several arguments for why TCP session survival when > topology changes is not crucial: Let me be really blunt. Right now, I can happily leave a "cvs update" that takes several hours running over the nice v4 internet and feel happy knowing that no matter what happens, the connection will keep on trucking. If the new v6 internet doesn't work that well, it is broken from my point of view. I didn't sign up on this to see my internet work less well than it does right now. > - Most application use is for the web. Web TCP sessions are very short-lived > and if there is a problem, the user will just use stop/reload. > > - Mission-critical applications already have logic for reliability above > TCP. (Transactions, restarting transfers, etc.) The Internet today is just > not reliable enough to rely entirely on TCP's guarantees for > mission-critical applications. Again, you just aren't dealing with the reality. Sure, lots of the net is the web, but it isn't all, and you're essentially saying "network reliability? we don't need that!" forever. I'm sorry, but having *less* reliability just isn't acceptable. People use this *now*. I don't think it is reasonable to break them. Oh, and > - BGP reacts/converges very slowly to topology changes. I've recently seen > data that indicates convergence usually takes minutes sure, but someday, we *will* have much better performing protocols in place. I don't think it is reasonable to architect things to burn today's limitations "into the wood", especially when, as I note, I use the net for long lived connections every day and I *don't* lose the way you're telling me I will have to under v6. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 16:38:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA23763 for ipng-dist; Tue, 20 Jul 1999 16:32:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23756 for ; Tue, 20 Jul 1999 16:31:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA14218 for ; Tue, 20 Jul 1999 16:31:56 -0700 (PDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07150 for ; Tue, 20 Jul 1999 16:31:56 -0700 (PDT) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 46FD211B; Tue, 20 Jul 1999 19:31:54 -0400 (EDT) To: Craig Metz Cc: Francis Dupont , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" References: <199907201931.TAA28358@inner.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 20 Jul 1999 19:31:53 -0400 In-Reply-To: Craig Metz's message of "Tue, 20 Jul 1999 15:31:24 -0400" Message-ID: <87d7xmucd2.fsf@jekyll.piermont.com> Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig Metz writes: > > Please choose a delimiter character that is not interpreted as a special > > character by *IX shells. > > > >=> too late, there are many URLs with '?' characters in them > >(and '?' is a special character for UNIX shells)... > > We cannot fix what is wrong with the web (well, with a time machine and a two > by four, maybe), but we can try to prevent new wrongs. I'm not sure that there are better characters really available. Most of the "obvious" ones are also bad. Also, literals are rare, and ?'s in URLs are very, very common. Not to say that a good idea wouldn't be a nice thing but I'm just not sanguine that the barn door isn't being shut a bit late. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 20:21:10 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA24077 for ipng-dist; Tue, 20 Jul 1999 20:18:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA24070 for ; Tue, 20 Jul 1999 20:18:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA05099 for ; Tue, 20 Jul 1999 20:18:00 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA21986 for ; Tue, 20 Jul 1999 21:17:59 -0600 (MDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA18684; Tue, 20 Jul 1999 20:16:55 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA96185; Tue, 20 Jul 1999 20:17:45 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id UAA26152; Tue, 20 Jul 1999 20:17:30 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199907210317.UAA26152@bossette.engr.sgi.com> Subject: Re: Bad routes update To: perry@piermont.com Date: Tue, 20 Jul 1999 20:17:30 -0700 (PDT) Cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com, pete@sms.fi, map@stacken.kth.se, cmetz@inner.net, jabley@clear.co.nz, kuznet@ms2.inr.ac.ru, rrockell@sprint.net In-Reply-To: <87pv1nszg3.fsf@jekyll.piermont.com> from "Perry E. Metzger" at Jul 20, 99 06:56:12 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Perry E. Metzger wrote: > > I was disappointed when there was no controversy around this point in > > Oslo... There are a several arguments for why TCP session survival when > > topology changes is not crucial: > > Let me be really blunt. > > Right now, I can happily leave a "cvs update" that takes several hours > running over the nice v4 internet and feel happy knowing that no > matter what happens, the connection will keep on trucking. If you lose connectivity for more than 10 mins for any BSD derived stack you'll also lose your connection. TCP isn't that reliable. If site renumbering were done on a regular basis this could turn out to be quite annoying, but that won't happen, will it. Site renumbering will be much rarer than your next-hop router going down for > 10 mins and you losing your connection, IMO. > People use this *now*. I don't think it is reasonable to break them. Er, don't exactly the same multi-homing issues exist with v4 right now? They just aren't an issue because TCP does not change its source and destination addressing during a connection. You're talking about a TCP change rather than a v6 issue, aren't you? I strongly urge leaving things alone right now. This is really the worst time to start talking about changes to the IPv6 API (i.e. connect("FQDN")), especially for a `problem' that has been lived with for a very long time. This is a completely orthogonal issue to IPv6 IMO. Just my .2 cents as an implementor. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Jul 20 20:52:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA24100 for ipng-dist; Tue, 20 Jul 1999 20:49:16 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA24093 for ; Tue, 20 Jul 1999 20:49:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA23254 for ; Tue, 20 Jul 1999 20:49:04 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA07097 for ; Tue, 20 Jul 1999 21:49:01 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id NAA22138; Wed, 21 Jul 1999 13:48:39 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Wed, 21 Jul 1999 13:48:39 +1000 (EST) From: Peter Tattam To: Sam Manthorpe cc: perry@piermont.com, richdr@microsoft.com, ipng@sunroof.eng.sun.com, pete@sms.fi, map@stacken.kth.se, cmetz@inner.net, jabley@clear.co.nz, kuznet@ms2.inr.ac.ru, rrockell@sprint.net Subject: Re: Bad routes update In-Reply-To: <199907210317.UAA26152@bossette.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This may or may not be relevant to the discussion. A few months ago, I put some ideas together based on the GSE debate. I have been reluctant to publish it because of the possible ridicule it may generate, but nothing ventured, nothing gained, so here it is. http://jazz.trumpet.com.au/ipv6-draft/GSE-plus-routing-idea-july-21-1999.htm It's only rough "ideas on the back of a napkin" style, not a rigorous treatment of the subject, and there may be things that just won't work in it. Of course the actual numbers I used in the document are flexible, and it should be read with that in mind. Anyway it's only as food for thought, and I bet noone will take it seriously. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 22:40:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA24153 for ipng-dist; Tue, 20 Jul 1999 22:32:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24146 for ; Tue, 20 Jul 1999 22:31:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA01075 for ; Tue, 20 Jul 1999 22:31:58 -0700 (PDT) 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 WAA19129 for ; Tue, 20 Jul 1999 22:31:57 -0700 (PDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Jul 1999 22:25:40 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2524.0) id ; Tue, 20 Jul 1999 22:25:45 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101451560C@RED-MSG-50> From: Richard Draves To: "'perry@piermont.com'" Cc: "'IPng List'" Subject: RE: Bad routes update Date: Tue, 20 Jul 1999 22:25:37 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I think giving the multi-homed host two addresses (one for > each part of the > > tree) is the beginning of a "yes" answer. It shifts the > problem from the > > network backbone (routing scalability) to the network > periphery (when to use > > which address). > > It won't work. It means that if the network routing to one of the > addresses dies, the TCP connections die. There are two answers to that. The short-term answer is an RFC 2260-style solution. The long-term answer is to change TCP so you can change endpoint addresses, for survivability and renumbering. > Right now, I can happily leave a "cvs update" that takes > several hours > running over the nice v4 internet and feel happy knowing that no > matter what happens, the connection will keep on trucking. > > If the new v6 internet doesn't work that well, it is broken from my > point of view. I didn't sign up on this to see my internet work less > well than it does right now. The v4 internet often doesn't work that well. How often has one of your "cvs update" operations actually survived an ISP failure? Sure, there are some applications for which TCP survivability is important. See the short-term and long-term answers above. But for the business uses of the Internet (the reasons for which sites are willing to pay multiple ISPs to be multihomed), TCP survivability is not nearly as important as availability for new connections. 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 Wed Jul 21 01:27:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA24254 for ipng-dist; Wed, 21 Jul 1999 01:23:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24247 for ; Wed, 21 Jul 1999 01:22:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA27959 for ; Wed, 21 Jul 1999 01:22:49 -0700 (PDT) Received: from mediator.uni-c.dk (mediator.uni-c.dk [130.228.12.55]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA26900 for ; Wed, 21 Jul 1999 01:22:49 -0700 (PDT) Received: (from erik@localhost) by mediator.uni-c.dk (8.9.3/8.9.3) id KAA03890; Wed, 21 Jul 1999 10:22:12 +0200 (MET DST) Date: Wed, 21 Jul 1999 10:22:12 +0200 From: Erik Bertelsen To: Brian E Carpenter Cc: Craig Metz , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" Message-ID: <19990721102212.C1807@mediator.uni-c.dk> References: <199907201822.SAA28216@inner.net> <3794F10E.546D048E@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <3794F10E.546D048E@hursley.ibm.com>; from Brian E Carpenter on Tue, Jul 20, 1999 at 04:58:38PM -0500 Organization: UNI-C Multimedia Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Jul 20, 1999 at 16:58:38 -0500, Brian E Carpenter wrote: > Craig, > > > Please choose a delimiter character that is not interpreted as a special > > character by *IX shells. > > Please be more specific. Are you objecting to [] ? If so what > is your counter-proposal; it has to be reasonably intuitive > as well as being possible to fit into the URL syntax. > If I recall correctly, one of the reasons for choosing [] despite of being active characters in Unix shells was that there was precedence for doing just this -- again if my memory serves correctly -- in the rsh/rcp family of programs when the remote machine is known by IP address instead of by name. If there is no good choice of delimiters, we should at least choose the least bad ones, and preferable choose some that are consistent with previous history... Erik Bertelsen, UNI-C. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 01:28:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA24263 for ipng-dist; Wed, 21 Jul 1999 01:25:21 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24256 for ; Wed, 21 Jul 1999 01:25:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA28091 for ; Wed, 21 Jul 1999 01:25:10 -0700 (PDT) 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 CAA10806 for ; Wed, 21 Jul 1999 02:25:04 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA00148; Wed, 21 Jul 1999 10:24:04 +0200 (MET DST) Message-ID: <19990721102404.B46@theory.cs.uni-bonn.de> Date: Wed, 21 Jul 1999 10:24:04 +0200 From: Ignatios Souvatzis To: Ed Boraas , ipng@sunroof.eng.sun.com, Bob Hinden Subject: Re: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" References: <3.0.5.32.19990720111037.008dce80@mailhost.iprg.nokia.com> <011901bed2de$eb3d7a40$2e79b9c7@admin.concordia.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <011901bed2de$eb3d7a40$2e79b9c7@admin.concordia.ab.ca>; from Ed Boraas on Tue, Jul 20, 1999 at 12:37:28PM -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Jul 20, 1999 at 12:37:28PM -0600, Ed Boraas wrote: > > OSes, as most shells interpret the brackets as special characters. One could > not (if I am not mistaken), invoke lynx from the commandline as follows: > > lynx http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > > but would rather have to use backslash escapes, like this: > > http://\[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210\]:80/index.html > > If there is a possibility of choosing another, non-"special" character, I > would heartily endorse the change. As far as I remember, this has been discussed in-depth long ago, and no better choise was found. Btw, a more intuitive way to call lynx would be: lynx 'http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html' -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 02:16:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA24364 for ipng-dist; Wed, 21 Jul 1999 02:14:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA24357 for ; Wed, 21 Jul 1999 02:14:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA14257 for ; Wed, 21 Jul 1999 02:14:02 -0700 (PDT) Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA09018 for ; Wed, 21 Jul 1999 02:13:59 -0700 (PDT) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id VAA13875; Wed, 21 Jul 1999 21:13:57 +1200 (NZST) Date: Wed, 21 Jul 1999 21:13:57 +1200 From: Joe Abley To: ipng@sunroof.eng.sun.com Subject: MultiHoming with IPv6 Message-ID: <19990721211356.B17512@patho.gen.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i X-Files: the Truth is Out There Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I've been cluttering the 6bone list with some concerns about multi- homing from an operational perspective, and the subject has been deemed off-topic for now. Rob Rockell of Sprint suggested this was a better place to raise some of the issues in the post that follows, so here we go. Apologies for not lurking for longer than two minutes before barging in :) 6bone folk: apologies for the rude bcc'ing; just letting people know where at least one branch of this thread has been taken. I have been surprised by some of the vehement opposition to the idea of compromising the pure backbone aggregation model, given the amount of complexity that seems to be involved in the alternatives. Is it not more reasonable to expect to have to make compromises in this area, in the interests of a realistic transition to IPv6? Isn't it _unreasonable_ to effectively change the semantics of TCP, such that a distant network event could disrupt an active session (by making one or both endpoint addresses unreachable), rather than allowing it to recover and continue? Earlier 6bone post is attached, to provide some context. Joe --- Date: Tue, 20 Jul 1999 21:33:34 +1200 >From: Joe Abley To: Craig Metz Cc: Richard Draves , 6bone@ISI.EDU Subject: Re: Bad routes update X-Mailer: Mutt 0.95.4i In-Reply-To: <199907200655.GAA26375@inner.net>; from Craig Metz on Tue, Jul 20, 1999 at 02:55:44AM -0400 Precedence: bulk Hi, On Tue, Jul 20, 1999 at 02:55:44AM -0400, Craig Metz wrote: > In message <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50>, you write: > >> >3FFE:F00:2::0/48 11261 > >> > >> This is not a bogus route per se. I told them to set it up > >> this way. I have > >> been recommending that non-pTLA multi-homed sites use a /48, > >> which happens to > >> mesh nicely with the way I've been managing tunnel address > >> space at NRL. > > > >This is bogus - the backbone should only see /24s. > > First off, you're going to have a very hard time arguing that the new /28s > shouldn't be seen. Second, there *must* be some provision for sites to > multi-home without being a full pTLA, or pTLA allocations will explode as will > the allocations of pTLAs to people who shouldn't have them. I was going to keep quiet about this until I had done a lot more reading, but it seems that perhaps things aren't as cut and dried as I had imagined, and perhaps there is some benefit in raising this on the 6bone list. I asked questions about multi-homing a long time ago, and the prevelant answer at the time (which I am hearing from Richard again, so I guess it hasn't changed) was: o if you connect to multiple pTLAs, you will get multple allocations of address space, since aggregation in the backbone is important and must not be compromised. o if you connect to an NLA which is multi-homed, you will be provided with multiple addresses for every host. I raised some issues regarding resilience of individual TCP sessions in the event of a pTLA-NLA event upstream, and the answers were (and are): o stability of individual sessions is not important in the event of a routing change upstream; o having _new_ sessions connect correctly (i.e. handling the change of TCP session endpoint address) is more important; this will be done by o an algorithm for choosing suitable source and destination addresses for TCP virtual circuit endpoints that will become clear with operational experience. I am not convinced by the first point, and the second and third ideas look very clumsy to me. Much more clumsy than having long-prefix routes injected into the backbone, leading to routers with 80,000 routes in them, to be honest. Personal opinion, and a little diversionary. My real concern is the operational impact of managing IP addresses of end users, or of the administrators just before the end-users. Suppose we, as a large (by NZ terms; tiny in global terms) operator decide to multi-home to four backbone providers. We will not be alone; other providers in NZ will do similar things. This happens now with IPv4 in one way or another. Today we have smaller ISPs who dual-attach to two or more of the major carriers. And below them we have customers who dual-home between ISPs. All this dual-homing is done for a reason, and that's diversity -- the way we build fault tolerance into our IP networks is to provision multiple, diverse and independent paths, and to advertise our networks in every direction. This takes care and skill to manage correctly, but if done well can be very effective. With IPv6, this means that the poor customer will need to number each address on their equipment with as many as 16 different addresses (their upstreams will each have to deal with 8). >From an operational perspective, we deal with dual-homed customers today who do not have technical staff in-house -- they hire it in, by the hour, and pay through the nose for it. A change in a customer relationship for one of the NLAs (who have no direct relationship with the end customer in question) now has the knock-on effect of requiring all downstream users to change addresses on their interfaces. I believe the IPv6 autoconfiguration story, but only as far as it goes -- I don't believe in effective automatic DNS and route filter updates, for example. There is going to be manual intervention required all along the track. The number of end-users just in our customer base that have a business requirement to multi-home increases every month. This sounds a little bit like a nightmare. Is this for real? This sounds a little less like IP, and a little more like E.164 number portability in the switched voice network, complete with business cards that need re-printing every two months (cue Psycho violins, trembling shower curtain, shadow of hand c/w bloody knife). For pTLA above, also read TLA in the real network -- I am presuming that the original aims of the 6bone hold true, and that operational procedures developed here will migrate their way to the Real Network. I still presume that I am under some basic misconception that, once cleared, will leave me happy and relaxed. The sooner someone can point it out to me, the sooner I can get some sleep :) Joe -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Te Kaihoahoa Kawei, CLEAR Communications Ltd http://www.clear.net.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 Jul 21 02:32:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA24391 for ipng-dist; Wed, 21 Jul 1999 02:29:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA24384 for ; Wed, 21 Jul 1999 02:29:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA14031 for ; Wed, 21 Jul 1999 02:29:37 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11050 for ; Wed, 21 Jul 1999 03:29:35 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id LAA29417; Wed, 21 Jul 1999 11:29:33 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id LAA12895; Wed, 21 Jul 1999 11:29:32 +0200 (MET DST) Message-Id: <199907210929.LAA12895@givry.inria.fr> From: Francis Dupont To: Erik Bertelsen cc: Brian E Carpenter , Craig Metz , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" In-reply-to: Your message of Wed, 21 Jul 1999 10:22:12 +0200. <19990721102212.C1807@mediator.uni-c.dk> Date: Wed, 21 Jul 1999 11:29:31 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: If I recall correctly, one of the reasons for choosing [] despite of being active characters in Unix shells was that there was precedence for doing just this -- again if my memory serves correctly -- in the rsh/rcp family of programs when the remote machine is known by IP address instead of by name. => this is for mail (RFC 822), not for rsh/rcp which doesn't usually work with literals. If there is no good choice of delimiters, we should at least choose the least bad ones, and preferable choose some that are consistent with previous history... => I agree, if there is no better counter-proposal we should go with []! Francis.Dupont@inria.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 Wed Jul 21 06:36:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA24490 for ipng-dist; Wed, 21 Jul 1999 06:33:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24483 for ; Wed, 21 Jul 1999 06:31:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA28127 for ; Wed, 21 Jul 1999 06:30:51 -0700 (PDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA16017 for ; Wed, 21 Jul 1999 06:30:49 -0700 (PDT) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 8079E163; Wed, 21 Jul 1999 09:30:47 -0400 (EDT) To: sm@bossette.engr.sgi.com (Sam Manthorpe) Cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com, pete@sms.fi, map@stacken.kth.se, cmetz@inner.net, jabley@clear.co.nz, kuznet@ms2.inr.ac.ru, rrockell@sprint.net Subject: Re: Bad routes update References: <199907210317.UAA26152@bossette.engr.sgi.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 21 Jul 1999 09:30:47 -0400 In-Reply-To: sm@bossette.engr.sgi.com's message of "Tue, 20 Jul 1999 20:17:30 -0700 (PDT)" Message-ID: <87n1wqcepk.fsf@jekyll.piermont.com> Lines: 43 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sm@bossette.engr.sgi.com (Sam Manthorpe) writes: > > Right now, I can happily leave a "cvs update" that takes several hours > > running over the nice v4 internet and feel happy knowing that no > > matter what happens, the connection will keep on trucking. > > If you lose connectivity for more than 10 mins for any BSD derived > stack you'll also lose your connection. That's a lot better than losing every time the routing changes, which is often multiple times in one day. > > People use this *now*. I don't think it is reasonable to break them. > > Er, don't exactly the same multi-homing issues exist with v4 right now? Not really. People who need multi-homing set up multi-homing and at the moment the doctrine of "use only the provider God gave you because only a sicko would want to use multiple providers" hasn't yet been burned in the wood. I know a lot of organizations that do this and are much happier because of it. People are saying that in v6 land they're going to have to "go screw" and I really don't think that's acceptable. People keep saying "well, we'll engineer around it" but thus far, no one has actually demonstrated real, deployable protocol to do so. > They just aren't an issue because TCP does not change its source and > destination addressing during a connection. You're talking about a > TCP change rather than a v6 issue, aren't you? As I said, right now, this works fine in v4. People announce routes through two providers and everything is copacetic. The issue is that people are trying to squash the practice in v6. They're claiming that one must never do this. If you guys insist on having people claim that they're bigger than they are in order to do that, all that's going to happen is that people will fight to pretend that they need bigger address blocks than they do. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 06:40:26 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA24509 for ipng-dist; Wed, 21 Jul 1999 06:37:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24502 for ; Wed, 21 Jul 1999 06:37:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA28657 for ; Wed, 21 Jul 1999 06:37:26 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18368 for ; Wed, 21 Jul 1999 06:37:26 -0700 (PDT) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id JAA04903; Wed, 21 Jul 1999 09:34:47 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000032315; Wed, 21 Jul 1999 09:34:46 -0400 (EDT) From: Jim Bound Message-Id: <199907211334.JAA0000032315@quarry.zk3.dec.com> To: sm@bossette.engr.sgi.com (Sam Manthorpe) cc: perry@piermont.com, richdr@microsoft.com, ipng@sunroof.eng.sun.com, pete@sms.fi, map@stacken.kth.se, cmetz@inner.net, jabley@clear.co.nz, kuznet@ms2.inr.ac.ru, rrockell@sprint.net Subject: Re: Bad routes update In-reply-to: Your message of "Tue, 20 Jul 1999 20:17:30 PDT." <199907210317.UAA26152@bossette.engr.sgi.com> Date: Wed, 21 Jul 1999 09:34:46 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I strongly urge leaving things alone right now. This is really the >worst time to start talking about changes to the IPv6 API >(i.e. connect("FQDN")), especially for a `problem' that has been lived >with for a very long time. This is a completely orthogonal issue to >IPv6 IMO. I agree, unless anyone is talking about changing the src/dst address duriing a renumbering operation the connection will not break. If we are talking about that change the subject line and start that discussion. We do not need to fix changing src/dst addresses on the fly for renumbering to deploy IPv6 whats so ever. Please focus this discussion and lets not yell "wolf" 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 Wed Jul 21 06:40:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA24518 for ipng-dist; Wed, 21 Jul 1999 06:39:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24511 for ; Wed, 21 Jul 1999 06:39:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA15317 for ; Wed, 21 Jul 1999 06:39:02 -0700 (PDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18975 for ; Wed, 21 Jul 1999 06:39:00 -0700 (PDT) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 8A424163; Wed, 21 Jul 1999 09:38:58 -0400 (EDT) To: Joe Abley Cc: Sam Manthorpe , richdr@microsoft.com, ipng@sunroof.eng.sun.com, pete@sms.fi, map@stacken.kth.se, cmetz@inner.net, kuznet@ms2.inr.ac.ru, rrockell@sprint.net Subject: Re: Bad routes update References: <87pv1nszg3.fsf@jekyll.piermont.com> <199907210317.UAA26152@bossette.engr.sgi.com> <19990721203820.A81633@clear.co.nz> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 21 Jul 1999 09:38:58 -0400 In-Reply-To: Joe Abley's message of "Wed, 21 Jul 1999 20:38:20 +1200" Message-ID: <87lncacebx.fsf@jekyll.piermont.com> Lines: 51 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joe Abley writes: > We routinely re-route inbound traffic through a backup carrier in order > to do maintenance on our primary inbound (US -> NZ) network without > customers being affected. It is not acceptable for all TCP sessions > to break whenever we decide to re-route traffic for a couple of hours. Lots of people are claiming this is just fine, and the fact that you are using multiple providers is some sort of disease on your part. I think they ought to start re-thinking this idea right now. Multiple homing is existing IPv4 practice and is not going away. > > You're talking about a > > TCP change rather than a v6 issue, aren't you? > > Nope. We're talking about a route aggregation issue. For reference, this discussion came up because some people started setting up multiple tunnels to multiple "providers" on the 6bone, and others started complaining about the "bogus routes" they were emitting -- i.e. more specific routes being announced via some provider to another provider's address block, i.e. the existing v4 practice. Lots of people are harboring the illusion that there is some way to avoid this in v6. "We'll build new protocol!" they say. "We'll use IP mobility algorithms!" they say. "We'll outlaw the practice!" they say. Try any of those and you're going to fall flat on your face. The fact is that this is a real internet with real problems that can't be wished away via non-real protocols. Unfortunately, the time for tinkering with v6 is over. You guys had seven years to come up with protocols to get around the multi-homing issue and you danced around it. Well, too late. Now you have to accept people advertising multiple routes to their multi-homed networks. If you wanted to do something else, you should have done it over the last decade while you had the time and breathing room. If we actually are going to deploy v6, we can't break existing users or they'll go on the warpath. If we're going to actually deploy v6, we have to do it now. That means that whatever magic multi-homing solutions people pull out of the pot of engineering manna are going to have to come "someday" and we're going to have to deploy using the existing solution now. Unless, of course, people don't want to actually deploy. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 07:07:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA24593 for ipng-dist; Wed, 21 Jul 1999 07:03:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24586 for ; Wed, 21 Jul 1999 07:03:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA24234 for ; Wed, 21 Jul 1999 07:03:13 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20180 for ; Wed, 21 Jul 1999 08:03:12 -0600 (MDT) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id KAA31175; Wed, 21 Jul 1999 10:02:24 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000004508; Wed, 21 Jul 1999 10:02:24 -0400 (EDT) From: Jim Bound Message-Id: <199907211402.KAA0000004508@quarry.zk3.dec.com> To: perry@piermont.com cc: Joe Abley , Sam Manthorpe , richdr@microsoft.com, ipng@sunroof.eng.sun.com, pete@sms.fi, map@stacken.kth.se, cmetz@inner.net, kuznet@ms2.inr.ac.ru, rrockell@sprint.net Subject: Re: Bad routes update In-reply-to: Your message of "21 Jul 1999 09:38:58 EDT." <87lncacebx.fsf@jekyll.piermont.com> Date: Wed, 21 Jul 1999 10:02:23 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Joe Abley writes: >> We routinely re-route inbound traffic through a backup carrier in order >> to do maintenance on our primary inbound (US -> NZ) network without >> customers being affected. It is not acceptable for all TCP sessions >> to break whenever we decide to re-route traffic for a couple of hours. >Lots of people are claiming this is just fine, and the fact that you >are using multiple providers is some sort of disease on your part. Who exactly is claiming this is bad can we put names or organizations to those who think this is a bad idea. I don't see a problem with doing this and never did. >I think they ought to start re-thinking this idea right now. I agree with Perry. >Multiple homing is existing IPv4 practice and is not going away. Agreed. >> > You're talking about a >> > TCP change rather than a v6 issue, aren't you? >> >> Nope. We're talking about a route aggregation issue. >For reference, this discussion came up because some people started >setting up multiple tunnels to multiple "providers" on the 6bone, and >others started complaining about the "bogus routes" they were emitting >-- i.e. more specific routes being announced via some provider to >another provider's address block, i.e. the existing v4 practice. So whats wrong with that we have to permit it and the routes are not bogus if they work. >Lots of people are harboring the illusion that there is some way to >avoid this in v6. "We'll build new protocol!" they say. "We'll use IP >mobility algorithms!" they say. "We'll outlaw the practice!" they say. That is not going to work. >Try any of those and you're going to fall flat on your face. The fact >is that this is a real internet with real problems that can't be >wished away via non-real protocols. Exactly. >Unfortunately, the time for tinkering with v6 is over. You guys had >seven years to come up with protocols to get around the multi-homing >issue and you danced around it. Well, too late. Now you have to accept >people advertising multiple routes to their multi-homed networks. If >you wanted to do something else, you should have done it over the last >decade while you had the time and breathing room. > >If we actually are going to deploy v6, we can't break existing users >or they'll go on the warpath. If we're going to actually deploy v6, we >have to do it now. Agreed. This is not a problem and existing practice should work as we did nothing in IPv6 to prevent how it is done in IPv4. I won't go into the debate if we ignored the multihome problem because we as designers did not, what we did is define an addressing architecture that enhances the use of IX's IMO that makes fixing the multihome problem somewhat less complex. /jim That means that whatever magic multi-homing solutions people pull out of the pot of engineering manna are going to have to come "someday" and we're going to have to deploy using the existing solution now. Unless, of course, people don't want to actually deploy. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jul 21 07:10:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA24613 for ipng-dist; Wed, 21 Jul 1999 07:09:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24606 for ; Wed, 21 Jul 1999 07:09:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA24685 for ; Wed, 21 Jul 1999 07:09:01 -0700 (PDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22384 for ; Wed, 21 Jul 1999 08:09:00 -0600 (MDT) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 57E38163; Wed, 21 Jul 1999 10:08:58 -0400 (EDT) To: Richard Draves Cc: "'IPng List'" Subject: Re: Bad routes update References: <4D0A23B3F74DD111ACCD00805F31D8101451560C@RED-MSG-50> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 21 Jul 1999 10:08:58 -0400 In-Reply-To: Richard Draves's message of "Tue, 20 Jul 1999 22:25:37 -0700" Message-ID: <87k8ruccxx.fsf@jekyll.piermont.com> Lines: 69 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Draves writes: > > It won't work. It means that if the network routing to one of the > > addresses dies, the TCP connections die. > > There are two answers to that. The short-term answer is an RFC 2260-style > solution. The long-term answer is to change TCP so you can change endpoint > addresses, for survivability and renumbering. None of this will work today. v6 has been debated for seven years. We have existing implementations, none of which do any of the proposed magic. Unfortunately, if we are *ever* going to have v6, we have to start deploying *now*. If you want to wait another three years and see v6 die, well, fine, but unfortunately, right now, our stacks do not have a way to deal with this and we need to deploy *now*, which means we use the solution we've got. > > Right now, I can happily leave a "cvs update" that takes > > several hours > > running over the nice v4 internet and feel happy knowing that no > > matter what happens, the connection will keep on trucking. > > > > If the new v6 internet doesn't work that well, it is broken from my > > point of view. I didn't sign up on this to see my internet work less > > well than it does right now. > > The v4 internet often doesn't work that well. How often has one of your "cvs > update" operations actually survived an ISP failure? At least every few days. It happens all the time. Maybe you don't notice this much because you work at Microsoft which has multiple diverse routes, and you haven't been spending a lot of time doing extensive work over the net. As a consultant, I routinely spend hours logged in to systems across the net, so I'm fairly acutely aware of the reliability issues. I often lose effective connectivity for a minute or so, but it is rare when dealing with multi-homed clients that I lose connectivity completely. > Sure, there are some applications for which TCP survivability is important. The net doesn't exist only to provide http connections. Anyone establishing a remote tunnel so they can work from home has to deal with the same problem I do. In the scheme you are proposing, such users will get very mad indeed. > See the short-term and long-term answers above. But for the business uses of > the Internet (the reasons for which sites are willing to pay multiple ISPs > to be multihomed), TCP survivability is not nearly as important as > availability for new connections. This is a generalization that just won't wash. You're making lots of assumptions, many of which aren't warranted under the circumstances. Right now, people pay lots of money for diverse providers for a good reason. It isn't that they love wasting money. They *need* the reliability. You're telling us that they don't exist -- but of course, if they didn't exist, why would you be worried about them exploding the routing tables? As I've said, we had seven years to come up with a solution for these people other than diverse route announcements and we did not come up with one. Given that, I think its time that we accepted that we're going to have to deploy with the same solution we had in v4. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 07:40:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA24712 for ipng-dist; Wed, 21 Jul 1999 07:36:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24705 for ; Wed, 21 Jul 1999 07:36:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA21487 for ; Wed, 21 Jul 1999 07:36:50 -0700 (PDT) Received: from hecky.acns.nwu.edu (hecky.acns.nwu.edu [129.105.16.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08637 for ; Wed, 21 Jul 1999 07:36:44 -0700 (PDT) Received: (from mailnull@localhost) by hecky.acns.nwu.edu (8.8.7/8.8.7) id JAA07217; Wed, 21 Jul 1999 09:36:43 -0500 (CDT) Received: from dhcp196.it.nwu.edu(129.105.237.196) by hecky.acns.nwu.edu via smap (V2.0) id xma007042; Wed, 21 Jul 99 09:36:25 -0500 Message-ID: <3795DA76.D9078977@hursley.ibm.com> Date: Wed, 21 Jul 1999 09:34:30 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Joe Abley CC: ipng@sunroof.eng.sun.com Subject: Re: MultiHoming with IPv6 References: <19990721211356.B17512@patho.gen.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joe, The multihoming proposal presented last week in Oslo (OK, a long way from NZ but I did spot one Kiwi there :) specifically deals with operational backup, without requiring TCP connections to survive prefix changes, and without compromising aggregation. I think when you see it written up in a draft it will address most of your concerns, but your comments from an operational perspective will be highly valuable. Your concerns about renumbering, a.k.a. prefix updates, are valid. There is more work to be done on the automation of downstream prefix updates, but remember that a prefix update is not a flag-day operation; the old and new prefixes can co-exist for as long as needed operationally. We do need A6 records for this to work properly. Brian Carpenter Joe Abley wrote: > > Hi, > > I've been cluttering the 6bone list with some concerns about multi- > homing from an operational perspective, and the subject has been deemed > off-topic for now. > > Rob Rockell of Sprint suggested this was a better place to raise some > of the issues in the post that follows, so here we go. Apologies for > not lurking for longer than two minutes before barging in :) > > 6bone folk: apologies for the rude bcc'ing; just letting people know > where at least one branch of this thread has been taken. > > I have been surprised by some of the vehement opposition to the idea of > compromising the pure backbone aggregation model, given the amount of > complexity that seems to be involved in the alternatives. > > Is it not more reasonable to expect to have to make compromises in > this area, in the interests of a realistic transition to IPv6? Isn't > it _unreasonable_ to effectively change the semantics of TCP, such that > a distant network event could disrupt an active session (by making > one or both endpoint addresses unreachable), rather than allowing it to > recover and continue? > > Earlier 6bone post is attached, to provide some context. > > Joe > > --- > > Date: Tue, 20 Jul 1999 21:33:34 +1200 > >From: Joe Abley > To: Craig Metz > Cc: Richard Draves , 6bone@ISI.EDU > Subject: Re: Bad routes update > X-Mailer: Mutt 0.95.4i > In-Reply-To: <199907200655.GAA26375@inner.net>; from Craig Metz on Tue, Jul 20, > 1999 at 02:55:44AM -0400 > Precedence: bulk > > Hi, > > On Tue, Jul 20, 1999 at 02:55:44AM -0400, Craig Metz wrote: > > In message <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50>, you write: > > >> >3FFE:F00:2::0/48 11261 > > >> > > >> This is not a bogus route per se. I told them to set it up > > >> this way. I have > > >> been recommending that non-pTLA multi-homed sites use a /48, > > >> which happens to > > >> mesh nicely with the way I've been managing tunnel address > > >> space at NRL. > > > > > >This is bogus - the backbone should only see /24s. > > > > First off, you're going to have a very hard time arguing that the new /28s > > shouldn't be seen. Second, there *must* be some provision for sites to > > multi-home without being a full pTLA, or pTLA allocations will explode as will > > the allocations of pTLAs to people who shouldn't have them. > > I was going to keep quiet about this until I had done a lot more reading, > but it seems that perhaps things aren't as cut and dried as I had imagined, > and perhaps there is some benefit in raising this on the 6bone list. > > I asked questions about multi-homing a long time ago, and the prevelant > answer at the time (which I am hearing from Richard again, so I guess it > hasn't changed) was: > > o if you connect to multiple pTLAs, you will get multple allocations > of address space, since aggregation in the backbone is important and > must not be compromised. > > o if you connect to an NLA which is multi-homed, you will be provided > with multiple addresses for every host. > > I raised some issues regarding resilience of individual TCP sessions > in the event of a pTLA-NLA event upstream, and the answers were (and are): > > o stability of individual sessions is not important in the event of > a routing change upstream; > > o having _new_ sessions connect correctly (i.e. handling the change > of TCP session endpoint address) is more important; this will be done by > > o an algorithm for choosing suitable source and destination addresses > for TCP virtual circuit endpoints that will become clear with > operational experience. > > I am not convinced by the first point, and the second and third ideas > look very clumsy to me. Much more clumsy than having long-prefix routes > injected into the backbone, leading to routers with 80,000 routes in them, > to be honest. Personal opinion, and a little diversionary. > > My real concern is the operational impact of managing IP addresses of > end users, or of the administrators just before the end-users. Suppose > we, as a large (by NZ terms; tiny in global terms) operator decide to > multi-home to four backbone providers. We will not be alone; other > providers in NZ will do similar things. This happens now with IPv4 > in one way or another. > > Today we have smaller ISPs who dual-attach to two or more of the major > carriers. > > And below them we have customers who dual-home between ISPs. > > All this dual-homing is done for a reason, and that's diversity -- the > way we build fault tolerance into our IP networks is to provision multiple, > diverse and independent paths, and to advertise our networks in every > direction. This takes care and skill to manage correctly, but if done > well can be very effective. > > With IPv6, this means that the poor customer will need to number each > address on their equipment with as many as 16 different addresses > (their upstreams will each have to deal with 8). > > >From an operational perspective, we deal with dual-homed customers today > who do not have technical staff in-house -- they hire it in, by the > hour, and pay through the nose for it. A change in a customer > relationship for one of the NLAs (who have no direct relationship with > the end customer in question) now has the knock-on effect of requiring > all downstream users to change addresses on their interfaces. > > I believe the IPv6 autoconfiguration story, but only as far as it > goes -- I don't believe in effective automatic DNS and route filter > updates, for example. There is going to be manual intervention required > all along the track. > > The number of end-users just in our customer base that have a business > requirement to multi-home increases every month. > > This sounds a little bit like a nightmare. Is this for real? This > sounds a little less like IP, and a little more like E.164 number > portability in the switched voice network, complete with business > cards that need re-printing every two months (cue Psycho violins, > trembling shower curtain, shadow of hand c/w bloody knife). > > For pTLA above, also read TLA in the real network -- I am presuming > that the original aims of the 6bone hold true, and that operational > procedures developed here will migrate their way to the Real Network. > > I still presume that I am under some basic misconception that, once > cleared, will leave me happy and relaxed. The sooner someone can > point it out to me, the sooner I can get some sleep :) > > Joe > > -- > Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 > Te Kaihoahoa Kawei, CLEAR Communications Ltd http://www.clear.net.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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 07:45:03 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA24769 for ipng-dist; Wed, 21 Jul 1999 07:43:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24754 for ; Wed, 21 Jul 1999 07:43:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA03464 for ; Wed, 21 Jul 1999 07:43:28 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02957 for ; Wed, 21 Jul 1999 08:35:31 -0600 (MDT) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.9.3/8.8.5) with ESMTP id QAA16231; Wed, 21 Jul 1999 16:34:08 +0200 (MET DST) Message-Id: <4.2.0.56.19990721162108.00ba1540@brahma.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Wed, 21 Jul 1999 16:34:34 +0200 To: perry@piermont.com From: Alain Durand Subject: multi-homing vs route aggregation (was Re: Bad routes update) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <87k8ruccxx.fsf@jekyll.piermont.com> References: <4D0A23B3F74DD111ACCD00805F31D8101451560C@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:08 21/07/99 -0400, you wrote: >As I've said, we had seven years to come up with a solution for these >people other than diverse route announcements and we did not come up >with one. Given that, I think its time that we accepted that we're >going to have to deploy with the same solution we had in v4. This solution (advertising prefixes through different ISPs) works fine in v4 mainly because of the limited number of multi-homed sites. Imagine multi-homing become the standard de-facto practise. CIDR will stop working and the default free routers will not have to carry about 50000 routes but zillions. This was a serious problem in 1993 when memory on routers was VERY expensive, and multiplied by the number of default free routers this was going nowhere. The other issue was the time to go through the routing table to select which interface to send packets to. I'm not a router hardware specialist. If one is listening to this thread, could he elaborate on this issue? - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 07:54:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA24812 for ipng-dist; Wed, 21 Jul 1999 07:51:18 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24805 for ; Wed, 21 Jul 1999 07:51:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA24633 for ; Wed, 21 Jul 1999 07:51:09 -0700 (PDT) Received: from hecky.acns.nwu.edu (hecky.acns.nwu.edu [129.105.16.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13851 for ; Wed, 21 Jul 1999 07:51:08 -0700 (PDT) Received: (from mailnull@localhost) by hecky.acns.nwu.edu (8.8.7/8.8.7) id JAA13591; Wed, 21 Jul 1999 09:51:05 -0500 (CDT) Received: from dhcp196.it.nwu.edu(129.105.237.196) by hecky.acns.nwu.edu via smap (V2.0) id xma013462; Wed, 21 Jul 99 09:50:37 -0500 Message-ID: <3795DDCA.43005DAF@hursley.ibm.com> Date: Wed, 21 Jul 1999 09:48:42 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Ignatios Souvatzis CC: Ed Boraas , ipng@sunroof.eng.sun.com, Bob Hinden Subject: Re: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" References: <3.0.5.32.19990720111037.008dce80@mailhost.iprg.nokia.com> <011901bed2de$eb3d7a40$2e79b9c7@admin.concordia.ab.ca> <19990721102404.B46@theory.cs.uni-bonn.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ignatios Souvatzis wrote: ... > Btw, a more intuitive way to call lynx would be: > > lynx 'http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html' Sure, this works today. In my test, lynx actually returned an error 400 from the local proxy, clearly showing that the "[" was passed to the proxy which then couldn't parse the new syntax. 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 Wed Jul 21 07:58:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA24838 for ipng-dist; Wed, 21 Jul 1999 07:56:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24831 for ; Wed, 21 Jul 1999 07:56:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA25681 for ; Wed, 21 Jul 1999 07:56:41 -0700 (PDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15843 for ; Wed, 21 Jul 1999 07:56:39 -0700 (PDT) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 1F547163; Wed, 21 Jul 1999 10:56:36 -0400 (EDT) To: Alain Durand Cc: ipng@sunroof.eng.sun.com Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) References: <4D0A23B3F74DD111ACCD00805F31D8101451560C@RED-MSG-50> <4.2.0.56.19990721162108.00ba1540@brahma.imag.fr> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 21 Jul 1999 10:56:31 -0400 In-Reply-To: Alain Durand's message of "Wed, 21 Jul 1999 16:34:34 +0200" Message-ID: <87vhbeaw68.fsf@jekyll.piermont.com> Lines: 46 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain Durand writes: > This solution (advertising prefixes through different > ISPs) works fine in v4 mainly because of the limited number > of multi-homed sites. > Imagine multi-homing become the standard de-facto practise. > CIDR will stop working and the default free routers will not have > to carry about 50000 routes but zillions. Well, it appears that the v4 internet has not had it become standard practice, so why do we assume the v6 internet will be different? If we replaced v4 with v6 on every host on the net tomorrow, we'd only have the current problem, not a new one. Why must v6 solve *this* problem? The problem has to be solved regardless of whether we are running v4 or v6. My long term answer continues to be this: this is an economics issue, not a technical issue. We have a classic "commons problem" in economic terms -- people are able to use a resource without paying for it, resulting in a "tragedy of the commons". People adding routes are not forced to pay for the incremental cost those routes impose on the owners of the routers in the default free zone. This results in overconsumption of the resource. Being forced to pay some arbitrary fee would not work either -- that would result in the resource being either over or underconsumed without regard to the proper market clearing level. In the long run, the solution is the same as that for all "commons problems" -- if you develop a market in routing announcements, then the market can set a cost for route injection, and then the desire to inject new routes will be balanced by this cost. The supply and demand curves will then cross nicely, and people will make reasonable decisions about whether to inject new routes, properly balancing their need for added reliability against the cost that that reliability has for them. I only hope that if I keep on saying this for about five more years, someone out there who's taken an econ class might actually understand what I'm getting at and agree that this is probably the only reasonable long term solution, short of inventing a technology that we don't have yet and may very well never have. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 08:52:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA24933 for ipng-dist; Wed, 21 Jul 1999 08:49:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24926 for ; Wed, 21 Jul 1999 08:49:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA19768 for ; Wed, 21 Jul 1999 08:49:07 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06917 for ; Wed, 21 Jul 1999 09:49:05 -0600 (MDT) Received: by odin.digi-data.com id <15244>; Wed, 21 Jul 1999 11:44:39 -0400 Message-Id: <99Jul21.114439gmt-0400.15244@odin.digi-data.com> Date: Wed, 21 Jul 1999 11:51:32 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IPng@sunroof.eng.sun.com Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) References: <87vhbeaw68.fsf@jekyll.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Perry, "Perry E. Metzger" wrote: > > Alain Durand writes: > > This solution (advertising prefixes through different > > ISPs) works fine in v4 mainly because of the limited number > > of multi-homed sites. > > Imagine multi-homing become the standard de-facto practise. > > CIDR will stop working and the default free routers will not have > > to carry about 50000 routes but zillions. > > Well, it appears that the v4 internet has not had it become standard > practice, so why do we assume the v6 internet will be different? It might not be different but it is possible. > If we > replaced v4 with v6 on every host on the net tomorrow, we'd only have > the current problem, not a new one. Why must v6 solve *this* problem? > The problem has to be solved regardless of whether we are running v4 > or v6. I agree that IPv6 does not need to solve this problem right now and we should deploy nonetheless, but the problem is an issue that will come up to catch us later. Perhaps we better try to figure what can be a solution right now and hopefully set things up to accommodate the solution later. > > My long term answer continues to be this: this is an economics > issue, not a technical issue. > It is both. Even if you were to compel people to pay the cost of adding more routes, what are you going to do when a large mass decide they are willing to pay whatever price necessary? If a resource is over-subscribed and you have no way to extend or increase it, you will have no progress. In fact you will have a large mass of unsatisfied consumers who will go looking for something else. > We have a classic "commons problem" in economic terms -- people are > able to use a resource without paying for it, resulting in a "tragedy > of the commons". > > People adding routes are not forced to pay for the incremental cost > those routes impose on the owners of the routers in the default free > zone. This results in overconsumption of the resource. Being forced to > pay some arbitrary fee would not work either -- that would result in > the resource being either over or underconsumed without regard to the > proper market clearing level. > > In the long run, the solution is the same as that for all "commons > problems" -- if you develop a market in routing announcements, then > the market can set a cost for route injection, and then the desire to > inject new routes will be balanced by this cost. The supply and > demand curves will then cross nicely, and people will make reasonable > decisions about whether to inject new routes, properly balancing their > need for added reliability against the cost that that reliability has > for them. > I agree that it is not a good idea to fix the number of routers in the default-free zone, but it is necessary to constrain the growth of the number of routes that must be propagated at that level to a rate that is less than the existing capacity to add resources to accommodate the additional routes. > I only hope that if I keep on saying this for about five more years, > someone out there who's taken an econ class might actually understand > what I'm getting at and agree that this is probably the only > reasonable long term solution, short of inventing a technology that we > don't have yet and may very well never have. > > Perry Having the users of the network pay the costs associated with adding the new routes **is** the only reasonable long-term way to ensure that we can continue to accommodate that kind of behaviour, but I believe that by the time we have figured out the full cost of injecting additional routes like that we would have gone a long way to solve the technical issue as well. Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 08:54:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA24951 for ipng-dist; Wed, 21 Jul 1999 08:53:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24944 for ; Wed, 21 Jul 1999 08:53:03 -0700 (PDT) From: bmanning@ISI.EDU Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA07807 for ; Wed, 21 Jul 1999 08:53:03 -0700 (PDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08794 for ; Wed, 21 Jul 1999 09:53:02 -0600 (MDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id IAA18489; Wed, 21 Jul 1999 08:53:01 -0700 (PDT) Posted-Date: Wed, 21 Jul 1999 08:52:58 -0700 (PDT) Message-Id: <199907211552.AA14607@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Wed, 21 Jul 1999 08:52:59 -0700 Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) To: Alain.Durand@imag.fr (Alain Durand) Date: Wed, 21 Jul 1999 08:52:58 -0700 (PDT) Cc: perry@piermont.com, ipng@sunroof.eng.sun.com In-Reply-To: <4.2.0.56.19990721162108.00ba1540@brahma.imag.fr> from "Alain Durand" at Jul 21, 1999 04:34:34 PM X-Mailer: ELM [version 2.5 PL0] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This solution (advertising prefixes through different > ISPs) works fine in v4 mainly because of the limited number > of multi-homed sites. > Imagine multi-homing become the standard de-facto practise. > CIDR will stop working and the default free routers will not have > to carry about 50000 routes but zillions. closer to 60K routes these days. More providers are multihomed today than in 1993. The popularity of legecy delegations sometimes called swamp space is that they are generally globally routable w/o provider aggregation. The other tactic that people are using is MPLS and tunnels. > This was a serious problem in 1993 when memory on routers > was VERY expensive, and multiplied by the number of default free > routers this was going nowhere. The other issue was the time to go > through the routing table to select which interface to send packets to. > > I'm not a router hardware specialist. If one is listening to this thread, > could he elaborate on this issue? Its not a memory issue. See the discussions from the bigi archives, the nanog archives, the end2end archives, the cidrd archives, pier archives and perhaps other places as well. > > - Alain. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- --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 Jul 21 09:30:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA25013 for ipng-dist; Wed, 21 Jul 1999 09:25:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25006 for ; Wed, 21 Jul 1999 09:24:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA13556 for ; Wed, 21 Jul 1999 09:24:51 -0700 (PDT) Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21268 for ; Wed, 21 Jul 1999 09:24:48 -0700 (PDT) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id EAA05230; Thu, 22 Jul 1999 04:24:26 +1200 (NZST) Date: Thu, 22 Jul 1999 04:24:26 +1200 From: Joe Abley To: bmanning@ISI.EDU Cc: Alain Durand , perry@piermont.com, ipng@sunroof.eng.sun.com Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) Message-ID: <19990722042425.B7270@patho.gen.nz> References: <4.2.0.56.19990721162108.00ba1540@brahma.imag.fr> <199907211552.AA14607@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199907211552.AA14607@zed.isi.edu>; from bmanning@ISI.EDU on Wed, Jul 21, 1999 at 08:52:58AM -0700 X-Files: the Truth is Out There Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bill, On Wed, Jul 21, 1999 at 08:52:58AM -0700, bmanning@ISI.EDU wrote: > > This solution (advertising prefixes through different > > ISPs) works fine in v4 mainly because of the limited number > > of multi-homed sites. > > Imagine multi-homing become the standard de-facto practise. > > CIDR will stop working and the default free routers will not have > > to carry about 50000 routes but zillions. > > closer to 60K routes these days. > > More providers are multihomed today than in 1993. > The popularity of legecy delegations sometimes called > swamp space is that they are generally globally routable > w/o provider aggregation. The other tactic that people are > using is MPLS and tunnels. It seems to me that at least some of these tactics would apply to IPv6 as well as IPv4, and provide an alternative approach to routing collapse in the core. (cf remarkabable similarity between Peter Tattam's home-grown "routing ID" based core and MPLS). Is it a reasonable approach to consider the issue IPv6-independent? Can we leave it to backbone providers to deploy suitable solutions (such as those you mentioned) to fix the problem as it arises, rather than preventing it from ever happening? Doom and gloom merchants have been predicting the collapse of the core due to an explosion of route prefixes for a long time now, and exercises such as increased efforts in aggregation have always kept the issue under control. Is the alleged explosion under IPv6 any different from these previous alleged explosions? Or am I blissfully unaware of *real* problems in the IPv4 core today? Joe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 09:42:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA25042 for ipng-dist; Wed, 21 Jul 1999 09:38:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25035 for ; Wed, 21 Jul 1999 09:38:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA09939 for ; Wed, 21 Jul 1999 09:38:23 -0700 (PDT) Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00497 for ; Wed, 21 Jul 1999 10:38:21 -0600 (MDT) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id EAA14357; Thu, 22 Jul 1999 04:38:07 +1200 (NZST) Date: Thu, 22 Jul 1999 04:38:06 +1200 From: Joe Abley To: "Perry E. Metzger" Cc: Richard Draves , "'IPng List'" Subject: Re: Bad routes update Message-ID: <19990722043806.E7270@patho.gen.nz> References: <4D0A23B3F74DD111ACCD00805F31D8101451560C@RED-MSG-50> <87k8ruccxx.fsf@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <87k8ruccxx.fsf@jekyll.piermont.com>; from Perry E. Metzger on Wed, Jul 21, 1999 at 10:08:58AM -0400 X-Files: the Truth is Out There Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jul 21, 1999 at 10:08:58AM -0400, Perry E. Metzger wrote: > > See the short-term and long-term answers above. But for the business uses of > > the Internet (the reasons for which sites are willing to pay multiple ISPs > > to be multihomed), TCP survivability is not nearly as important as > > availability for new connections. > > This is a generalization that just won't wash. You're making lots of > assumptions, many of which aren't warranted under the > circumstances. There seems to be a prevailing idea in some quarters that some protocols are of business interest, and others aren't. We (CLEAR) are in the business of selling extremely reliable wholesale internet connections to ISPs, and those ISPs are just as demanding as corporate clients (more so in most cases). To these demanding business customers, protocols which require long-lived TCP sessions like IRC are business-critical, no matter how trivial these protocols seem from a corporate perspective. A significant proportion of multi-homing activity here in New Zealand is with tier-3 ISPs, and not yet with corporate accounts (who are currently more likely to forego the complexities of BGP and multi-homing for a nice SLA which gives them penalty payments). Joe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 10:01:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA25108 for ipng-dist; Wed, 21 Jul 1999 09:57:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25101 for ; Wed, 21 Jul 1999 09:57:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA02019 for ; Wed, 21 Jul 1999 09:57:26 -0700 (PDT) Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04918 for ; Wed, 21 Jul 1999 09:57:25 -0700 (PDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08121; Wed, 21 Jul 1999 09:56:14 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA91810; Wed, 21 Jul 1999 09:56:11 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA28448; Wed, 21 Jul 1999 09:56:06 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199907211656.JAA28448@bossette.engr.sgi.com> Subject: Re: W.G. Last Call on "Preferred Format for Literal IPv6 Addresses in URL's" To: erik@mediator.uni-c.dk (Erik Bertelsen) Date: Wed, 21 Jul 1999 09:56:05 -0700 (PDT) Cc: brian@hursley.ibm.com, cmetz@inner.net, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: <19990721102212.C1807@mediator.uni-c.dk> from "Erik Bertelsen" at Jul 21, 99 10:22:12 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Bertelsen wrote: > > If there is no good choice of delimiters, we should at least choose > the least bad ones, and preferable choose some that are consistent > with previous history... > Yes, and [] is not bad IMO. In most shells, [] would only be a problem in the command line if there happens to be a file in the current working directory that would be matched by the [] wildcard, which for URLs would be pretty rare. csh, sh and bash all work fine. I haven't tried others. So: On Tue, Jul 20, 1999 at 12:37:28PM -0600, Ed Boraas wrote: > > OSes, as most shells interpret the brackets as special characters. One could > not (if I am not mistaken), invoke lynx from the commandline as follows: > > lynx http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html So one _could_ invoke lynx in this way, unless in your current directory, there happened to be a subdirectory called: http:/ which contained another subdirectory called: [0-9A-Za-z:]:80 which contained a file called index.html This being a fairly pathalogical case I wouldn't worry about it and if you _are_ worried about it there are always backslashes :-) Try it yourself: #include int main(int argc, char **argv) { printf("Got \"%s\"\n", argv[1]); } Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Jul 21 10:01:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA25098 for ipng-dist; Wed, 21 Jul 1999 09:56:57 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25091 for ; Wed, 21 Jul 1999 09:56:51 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA02304 for ipng@sunroof.eng.sun.com; Wed, 21 Jul 1999 09:55:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24309 for ; Wed, 21 Jul 1999 01:41:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA12226 for ; Wed, 21 Jul 1999 01:41:18 -0700 (PDT) Received: from fep4-orange.clear.net.nz (fep4-orange.clear.net.nz [203.97.32.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA17640 for ; Wed, 21 Jul 1999 02:41:16 -0600 (MDT) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep4-orange.clear.net.nz (1.5/1.3) with ESMTP id UAA06050; Wed, 21 Jul 1999 20:38:25 +1200 (NZST) Received: (from jabley@localhost) by buddha.clear.net.nz (8.9.3/8.9.2) id UAA81758; Wed, 21 Jul 1999 20:38:20 +1200 (NZST) (envelope-from jabley) Date: Wed, 21 Jul 1999 20:38:20 +1200 From: Joe Abley To: Sam Manthorpe Cc: perry@piermont.com, richdr@microsoft.com, ipng@sunroof.eng.sun.com, pete@sms.fi, map@stacken.kth.se, cmetz@inner.net, kuznet@ms2.inr.ac.ru, rrockell@sprint.net Subject: Re: Bad routes update Message-ID: <19990721203820.A81633@clear.co.nz> References: <87pv1nszg3.fsf@jekyll.piermont.com> <199907210317.UAA26152@bossette.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907210317.UAA26152@bossette.engr.sgi.com>; from Sam Manthorpe on Tue, Jul 20, 1999 at 08:17:30PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Jul 20, 1999 at 08:17:30PM -0700, Sam Manthorpe wrote: > Perry E. Metzger wrote: > > Right now, I can happily leave a "cvs update" that takes several hours > > running over the nice v4 internet and feel happy knowing that no > > matter what happens, the connection will keep on trucking. > > If you lose connectivity for more than 10 mins for any BSD derived > stack you'll also lose your connection. TCP isn't that reliable. It's incredibly rare that I lose connectivity somewhere for long enough that TCP sessions time out. However, it's not _that_ rare for me to lose connectivity for a minute or so due to a major network event. The fact of the matter is that TCP usually _is_ that reliable. If we start to dump all our customer's TCP sessions on a semi-regular basis, the helpdesk will track me down and kill me while I sleep. > If site renumbering were done on a regular basis this could turn out > to be quite annoying, but that won't happen, will it. Site renumbering > will be much rarer than your next-hop router going down for > 10 mins > and you losing your connection, IMO. We routinely re-route inbound traffic through a backup carrier in order to do maintenance on our primary inbound (US -> NZ) network without customers being affected. It is not acceptable for all TCP sessions to break whenever we decide to re-route traffic for a couple of hours. > > People use this *now*. I don't think it is reasonable to break them. > > Er, don't exactly the same multi-homing issues exist with v4 right now? Nope. > They just aren't an issue because TCP does not change its source and > destination addressing during a connection. That's right. > You're talking about a > TCP change rather than a v6 issue, aren't you? Nope. We're talking about a route aggregation issue. > I strongly urge leaving things alone right now. This is really the > worst time to start talking about changes to the IPv6 API > (i.e. connect("FQDN")), especially for a `problem' that has been lived > with for a very long time. This is a completely orthogonal issue to > IPv6 IMO. This is a completely new problem, and one that does not happen with IPv4. This is a vital operational issue for us, and one which is surely best debated (and experimented with) on the 6bone in preference to any production v6 network. That's what the 6bone is for, right? > Just my .2 cents as an implementor. My NZ$0.02 as an operator. Joe -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Te Kaihoahoa Kawei, CLEAR Communications Ltd http://www.clear.net.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 Jul 21 10:02:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA25134 for ipng-dist; Wed, 21 Jul 1999 10:00:06 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25127 for ; Wed, 21 Jul 1999 09:59:55 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA02340 for ipng@sunroof.eng.sun.com; Wed, 21 Jul 1999 09:58:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24430 for ; Wed, 21 Jul 1999 03:59:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA19360 for ; Wed, 21 Jul 1999 03:59:36 -0700 (PDT) Received: from fep3-orange.clear.net.nz (fep3-orange.clear.net.nz [203.97.32.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA02082 for ; Wed, 21 Jul 1999 03:59:34 -0700 (PDT) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep3-orange.clear.net.nz (1.5/1.3) with ESMTP id WAA16758; Wed, 21 Jul 1999 22:49:55 +1200 (NZST) Received: (from jabley@localhost) by buddha.clear.net.nz (8.9.3/8.9.2) id WAA83309; Wed, 21 Jul 1999 22:49:50 +1200 (NZST) (envelope-from jabley) Date: Wed, 21 Jul 1999 22:49:50 +1200 From: Joe Abley To: Peter Tattam Cc: Sam Manthorpe , perry@piermont.com, richdr@microsoft.com, ipng@sunroof.eng.sun.com, pete@sms.fi, map@stacken.kth.se, cmetz@inner.net, kuznet@ms2.inr.ac.ru, rrockell@sprint.net Subject: Re: Bad routes update Message-ID: <19990721224950.A83063@clear.co.nz> References: <199907210317.UAA26152@bossette.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Peter Tattam on Wed, Jul 21, 1999 at 01:48:39PM +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jul 21, 1999 at 01:48:39PM +1000, Peter Tattam wrote: > This may or may not be relevant to the discussion. > > A few months ago, I put some ideas together based on the GSE debate. > I have been reluctant to publish it because of the possible ridicule it may > generate, but nothing ventured, nothing gained, so here it is. > > http://jazz.trumpet.com.au/ipv6-draft/GSE-plus-routing-idea-july-21-1999.htm > > It's only rough "ideas on the back of a napkin" style, not a rigorous > treatment of the subject, and there may be things that just won't work in it. > Of course the actual numbers I used in the document are flexible, and it should > be read with that in mind. > > Anyway it's only as food for thought, and I bet noone will take it seriously. It looks a little like you are using a 32-bit BGP ASN-type-thing (the visible portion of the globally unique site id) as a key to choose a label for the datagram, so that it can be pushed through an MPLS cloud-looking-thing. Doesn't the exchange and dispersal of routing IDs sound like the label distribution protocol? Perhaps MPLS is a general solution for the core, and will collapse an arbitrary complex routing problem in the centre of the network into a generally simpler mesh? Is MPLS an alternative approach to avoiding routing collapse in the core? Joe -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Te Kaihoahoa Kawei, CLEAR Communications Ltd http://www.clear.net.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 Jul 21 10:03:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA25143 for ipng-dist; Wed, 21 Jul 1999 10:01:10 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25136 for ; Wed, 21 Jul 1999 10:01:04 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA02369 for ipng@sunroof.eng.sun.com; Wed, 21 Jul 1999 09:59:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24449 for ; Wed, 21 Jul 1999 05:09:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA22746 for ; Wed, 21 Jul 1999 05:09:33 -0700 (PDT) Received: from neteracy.instructors.net (gateway.rherr.txdirect.net [209.142.76.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA21678 for ; Wed, 21 Jul 1999 06:09:32 -0600 (MDT) Received: from ts002d04.chi-il.concentric.net [206.173.185.64] (HELO inst1) by neteracy.instructors.net (AltaVista Mail V1.0/1.0 BL18 listener) id 0000_004e_3795_bbd1_1ac3; Wed, 21 Jul 1999 07:23:45 -0500 From: "Ted Rohling" To: Subject: Time for a Review Date: Wed, 21 Jul 1999 07:09:55 -0500 Message-ID: <001101bed371$f1b838e0$40b9adce@inst1.arg.com> 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 8.5, Build 4.71.2173.0 In-Reply-To: <19990721211356.B17512@patho.gen.nz> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Has anyone taken the time to develop a list of things we can do in IPv4 and determine exactly how they are going to be done in IPv6. I know IPv6 has lots of new stuff but what about the old stuff. IE. Assignment of DNS server address during autoconfiguration. Forced selection of "gateway" router during autoconfiguration when there are multiple routers attached to a segment. Assignment of Node names and Domain names during autoconfiguration. ..... and the list goes on. These may not be extremely interesting developmental issues but until the ADMINISTRATIVE trivia is taken care of and people understand how things will work, IPv6 remains a mystery and an interesting yet unnecessary opportunity to avoid. For those of you who are implementors or developers, remember that the fruits of your labors have to be used by someone. A simple "that will be handled by individual implementations" is not a satisfactory answer to those of us who will live with this in the real world. Hope this doesn't generate a stream of protests but during the next IETF meeting, why doesn't someone undertake this in a committee meeting and help us in the user community understand why this is so useful. Thanks for listening -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 10:08:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA25228 for ipng-dist; Wed, 21 Jul 1999 10:06:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25218 for ; Wed, 21 Jul 1999 10:06:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA15982 for ; Wed, 21 Jul 1999 10:06:10 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14381 for ; Wed, 21 Jul 1999 11:06:09 -0600 (MDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA06203; Wed, 21 Jul 1999 10:04:47 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA25499; Wed, 21 Jul 1999 10:05:36 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA28703; Wed, 21 Jul 1999 10:05:32 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199907211705.KAA28703@bossette.engr.sgi.com> Subject: Re: Bad routes update To: jabley@clear.co.nz (Joe Abley) Date: Wed, 21 Jul 1999 10:05:31 -0700 (PDT) Cc: perry@piermont.com, richdr@microsoft.com, ipng@sunroof.eng.sun.com, pete@sms.fi, map@stacken.kth.se, cmetz@inner.net, kuznet@ms2.inr.ac.ru, rrockell@sprint.net In-Reply-To: <19990721203820.A81633@clear.co.nz> from "Joe Abley" at Jul 21, 99 08:38:20 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joe Abley wrote: > > If site renumbering were done on a regular basis this could turn out > > to be quite annoying, but that won't happen, will it. Site renumbering > > will be much rarer than your next-hop router going down for > 10 mins > > and you losing your connection, IMO. > > We routinely re-route inbound traffic through a backup carrier in order > to do maintenance on our primary inbound (US -> NZ) network without > customers being affected. It is not acceptable for all TCP sessions > to break whenever we decide to re-route traffic for a couple of hours. Yes but you don't routinely renumber your site. You just change routes and that works fine in IPv6 as it does in IPv4. Or are you talking about moving your NAT box rom one net to another? > > > People use this *now*. I don't think it is reasonable to break them. > > > > Er, don't exactly the same multi-homing issues exist with v4 right now? > > Nope. So you can change the outgoing interface of your TCP connection, together with the source address of your TCP 4-tuple and your connection stays up? Please tell me more! Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Jul 21 10:33:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA25282 for ipng-dist; Wed, 21 Jul 1999 10:29:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25275 for ; Wed, 21 Jul 1999 10:29:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA09163 for ; Wed, 21 Jul 1999 10:29:30 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19323 for ; Wed, 21 Jul 1999 10:29:29 -0700 (PDT) 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 CAA01220 for ; Thu, 22 Jul 1999 02:29:22 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: jabley's message of Wed, 21 Jul 1999 20:38:20 +1200. <19990721203820.A81633@clear.co.nz> 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: multihoming (Re: Bad routes update) From: itojun@iijlab.net Date: Thu, 22 Jul 1999 02:29:22 +0900 Message-ID: <1218.932578162@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Couldn't we just calm down until Oslo IETF minutes is made available? Most of the items are tackled in presentation there, of course with clarification of problem domains. Most of the emails we saw these days seems to not sharing clear problem domain. Multihoming issue includes policy issues so problem domain can be very different by person to person. So, again, let us wait till minutes is made available. 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 Jul 21 10:47:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA25332 for ipng-dist; Wed, 21 Jul 1999 10:45:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25325 for ; Wed, 21 Jul 1999 10:44:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA03434 for ; Wed, 21 Jul 1999 10:44:54 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25968 for ; Wed, 21 Jul 1999 10:44:54 -0700 (PDT) Received: from sigma.zk3.dec.com (brysigma.zk3.dec.com [16.141.40.6]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id NAA32013; Wed, 21 Jul 1999 13:44:18 -0400 (EDT) Received: from localhost by sigma.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id NAA0000027355; Wed, 21 Jul 1999 13:44:18 -0400 (EDT) From: Jim Bound Message-Id: <199907211744.NAA0000027355@sigma.zk3.dec.com> X-Authentication-Warning: sigma.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: multihoming (Re: Bad routes update) In-reply-to: Your message of "Thu, 22 Jul 1999 02:29:22 +0900." <1218.932578162@coconut.itojun.org> Date: Wed, 21 Jul 1999 13:44:17 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Couldn't we just calm down until Oslo IETF minutes is made available? Most of the items are tackled in presentation there, of course with clarification of problem domains. Most of the emails we saw these days seems to not sharing clear problem domain. Multihoming issue includes policy issues so problem domain can be very different by person to person. So, again, let us wait till minutes is made available. I agree. I was in the dark as I was not at Oslo. Can we please listen to Itojun on this one. Then we can discuss it based on the draft and also clearly articulate the problem space technically and political issues as I think there are some. Also I think Brian was telling us the same thing. How about we chill out till the draft is available. /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 Jul 21 10:47:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA25322 for ipng-dist; Wed, 21 Jul 1999 10:44:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25315 for ; Wed, 21 Jul 1999 10:43:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA24182 for ; Wed, 21 Jul 1999 10:43:54 -0700 (PDT) Received: from alpha.mcit.com (omzrelay01.mcit.com [199.249.19.243]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25511 for ; Wed, 21 Jul 1999 10:43:52 -0700 (PDT) Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #38416) with ESMTP id <0FF80006ZEAEUJ@firewall.mcit.com> for ipng@sunroof.eng.sun.com; Wed, 21 Jul 1999 17:37:29 +0000 (GMT) Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122]) by omzrelay.mcit.com (8.8.7/) with ESMTP id RAA14354 for ; Wed, 21 Jul 1999 17:38:27 +0000 (GMT) Received: from AXE_LAP.nss.mcit.com ([166.34.20.118]) by omzmta04.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19990721173725.KELX3540@AXE_LAP.nss.mcit.com> for ; Wed, 21 Jul 1999 17:37:25 +0000 Date: Wed, 21 Jul 1999 13:38:46 -0400 From: Bill Axelrod Subject: RE: Time for a Review In-reply-to: <001101bed371$f1b838e0$40b9adce@inst1.arg.com> To: ipng@sunroof.eng.sun.com Reply-to: Bill.Axelrod@wcom.com Message-id: <000f01bed39f$e37af6e0$761422a6@AXE_LAP.nss.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Ted completely. >From a maintainer/end-user point of view, I'd want to know that IPv6 has been fully functionality regression tested and that any migration plans include methods to overcome any ways where the functionality or the implementation processes change. Would the NGTRANS (Next Generation Transition) working group be better suited to research this? Bill -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Ted Rohling Sent: Wednesday, July 21, 1999 8:10 AM To: ipng@sunroof.eng.sun.com Subject: Time for a Review Has anyone taken the time to develop a list of things we can do in IPv4 and determine exactly how they are going to be done in IPv6. I know IPv6 has lots of new stuff but what about the old stuff. IE. Assignment of DNS server address during autoconfiguration. Forced selection of "gateway" router during autoconfiguration when there are multiple routers attached to a segment. Assignment of Node names and Domain names during autoconfiguration. ..... and the list goes on. These may not be extremely interesting developmental issues but until the ADMINISTRATIVE trivia is taken care of and people understand how things will work, IPv6 remains a mystery and an interesting yet unnecessary opportunity to avoid. For those of you who are implementors or developers, remember that the fruits of your labors have to be used by someone. A simple "that will be handled by individual implementations" is not a satisfactory answer to those of us who will live with this in the real world. Hope this doesn't generate a stream of protests but during the next IETF meeting, why doesn't someone undertake this in a committee meeting and help us in the user community understand why this is so useful. Thanks for listening -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 11:00:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA25415 for ipng-dist; Wed, 21 Jul 1999 10:56:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25408 for ; Wed, 21 Jul 1999 10:56:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA26824 for ; Wed, 21 Jul 1999 10:56:49 -0700 (PDT) Received: from squid.pdc.kth.se (squid.pdc.kth.se [130.237.221.65]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01430 for ; Wed, 21 Jul 1999 10:56:48 -0700 (PDT) Received: (from d95-mah@localhost) by squid.pdc.kth.se (8.8.7/8.8.7) id TAA09346; Wed, 21 Jul 1999 19:56:43 +0200 (MET DST) To: ipng@sunroof.eng.sun.com Subject: Dialup issues From: Magnus Ahltorp Content-Type: text/plain; charset="iso-8859-1" Content-Language: en Date: 21 Jul 1999 19:56:42 +0200 Message-ID: Lines: 8 X-Mailer: Gnus v5.6.45/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Are there any documents describing how to assign addresses to dialup lines? Assigning /64 to dialup lines seems like overkill, yet people want to run some sort of network at home with all the machines having global addresses. /Magnus -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 11:39:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA25460 for ipng-dist; Wed, 21 Jul 1999 11:26:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25453 for ; Wed, 21 Jul 1999 11:26:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA21352 for ; Wed, 21 Jul 1999 11:26:29 -0700 (PDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16281 for ; Wed, 21 Jul 1999 11:26:29 -0700 (PDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA03539 for ; Wed, 21 Jul 1999 14:26:27 -0400 (EDT) Received: from mailsrv2.mitre.org (mailsrv2.mitre.org [129.83.221.17]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA20266 for ; Wed, 21 Jul 1999 14:26:11 -0400 (EDT) Received: from mitre.org ([128.29.122.99]) by mailsrv2.mitre.org (Netscape Messaging Server 3.61) with ESMTP id AAA3745 for ; Wed, 21 Jul 1999 14:26:25 -0400 Message-ID: <379611E3.29D78843@mitre.org> Date: Wed, 21 Jul 1999 14:30:59 -0400 From: "Ta,Phong G." Organization: The MITRE Corporation X-Mailer: Mozilla 4.61 [en]C-19990607M (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: IPv6 Implementation for large corporation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Are there any documentations about IPv6 implementation issues for large corporation? Any suggestion is welcome. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 11:51:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA25508 for ipng-dist; Wed, 21 Jul 1999 11:37:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25500 for ; Wed, 21 Jul 1999 11:37:06 -0700 (PDT) From: bmanning@ISI.EDU Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA14695 for ; Wed, 21 Jul 1999 11:37:02 -0700 (PDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21100 for ; Wed, 21 Jul 1999 11:37:02 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id LAA27073; Wed, 21 Jul 1999 11:37:01 -0700 (PDT) Posted-Date: Wed, 21 Jul 1999 11:36:59 -0700 (PDT) Message-Id: <199907211837.AA16970@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Wed, 21 Jul 1999 11:37:00 -0700 Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) To: jabley@patho.gen.nz (Joe Abley) Date: Wed, 21 Jul 1999 11:36:59 -0700 (PDT) Cc: bmanning@ISI.EDU, Alain.Durand@imag.fr (Alain Durand), perry@piermont.com, ipng@sunroof.eng.sun.com In-Reply-To: <19990722042425.B7270@patho.gen.nz> from "Joe Abley" at Jul 22, 1999 04:24:26 AM X-Mailer: ELM [version 2.5 PL0] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > More providers are multihomed today than in 1993. > > The popularity of legecy delegations sometimes called > > swamp space is that they are generally globally routable > > w/o provider aggregation. The other tactic that people are > > using is MPLS and tunnels. > > It seems to me that at least some of these tactics would apply to IPv6 > as well as IPv4, and provide an alternative approach to routing collapse > in the core. (cf remarkabable similarity between Peter Tattam's home-grown > "routing ID" based core and MPLS). > > Is it a reasonable approach to consider the issue IPv6-independent? Can we > leave it to backbone providers to deploy suitable solutions (such as those > you mentioned) to fix the problem as it arises, rather than preventing it > from ever happening? > > Joe I see two distinct threads here. - routing system "containment" - session stability some off the cuff thoughts on each. - routing systems are dependent on a couple of things, agreement between transport agents to exchange client prefix and path data is one. the ability to do this depends on technologies for managing entries in a routing table. I've not yet seen a real good way to track the value here. It seems to hinge on two points, the number of "slots" to keep the data and the time each slot is occupied. These assumptions seem to hold true, regardless of network protocol. IPv6 is "scary" because the potential for killing existing designs is so high and the business/political alternatives lead down the path of collusion between providers and restraint of trade. Hence the desire to use psudo-technological arguments about the limitations of existing technologies to build crippling addressing architectures and archane delegation procedures. (yes, I am biased here.. :) - session stability has been thought of in the not too recent past. Christian H. had an interesting idea that had a brief proof-of-concept done at UCLA a couple years back. He argued for the replacement of the IP address inthe PCB with a host unique ID. I had a more hairbrained scheme to use the FQDN in the PCB. The general idea is to decouple the node identifier from the topology label, allowing things to move in the topology w/o changing the host id. There was some preliminary thought about casting this as TransportV6. See the Nimrod work and Noel C., Steve K. and others for the last decades discussion on this. For me, its always boilded down to developing support for variable length addressing, which has has been rejected as far back as the last two decades. (at least according to the IEN copies that I have here, predating the RFC series.) The IRTF and IAB have consistently tossed the idea as too disruptive. (Hey, bill is biased here too!) --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 Jul 21 11:53:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA25542 for ipng-dist; Wed, 21 Jul 1999 11:47:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25535 for ; Wed, 21 Jul 1999 11:47:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA18258 for ; Wed, 21 Jul 1999 11:47:33 -0700 (PDT) Received: from snowy2.woods.net (snowy2.woods.net [209.112.190.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25619 for ; Wed, 21 Jul 1999 11:47:31 -0700 (PDT) Received: by snowy2.woods.net id m1171On-000INRC (Solaris Smail-3.2.0.104 1998-Nov-20 #2); Wed, 21 Jul 1999 10:47:25 -0800 (AKDT) Message-Id: Date: Wed, 21 Jul 1999 10:47:25 -0800 (AKDT) From: acd@woods.net (Aaron Dewell) To: robert@digi-data.com Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) Cc: IPng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Why not just call that the cost of doing business in the default-free zone? If you choose to put your router/organization there, that has some costs X associated with it. It also has other advantages (reliability, speed, etc.) that come with it also. Those advantages have costs. The fact that others (the end-networks) have influence over what those costs are is not relevant. Seems to me wanting people to pay for the resources of being in a better position is kindof ... greedy. Anyone who is part of the backbone has a business reason for being there, and needs to pay the cost of that reason. Having the providers who reap the benefits of being there **is** the only reasonable long-term way to ensure that we can continue to accomodate that kind of behavior. ;-) Aaron Robert Honore wrote: > It is both. Even if you were to compel people to pay the cost of adding more > routes, what are you going to do when a large mass decide they are willing to > pay whatever price necessary? If a resource is over-subscribed and you have no > way to extend or increase it, you will have no progress. In fact you will have > a large mass of unsatisfied consumers who will go looking for something else. [...] > Having the users of the network pay the costs associated with adding the new > routes **is** the only reasonable long-term way to ensure that we can continue > to accommodate that kind of behaviour, but I believe that by the time we have > figured out the full cost of injecting additional routes like that we would have > gone a long way to solve the technical issue as well. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 13:44:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA25953 for ipng-dist; Wed, 21 Jul 1999 13:40:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25946 for ; Wed, 21 Jul 1999 13:40:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA28073 for ; Wed, 21 Jul 1999 13:40:24 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15787 for ; Wed, 21 Jul 1999 14:40:22 -0600 (MDT) Received: by odin.digi-data.com id <15234>; Wed, 21 Jul 1999 16:36:03 -0400 Message-Id: <99Jul21.163603gmt-0400.15234@odin.digi-data.com> Date: Wed, 21 Jul 1999 16:43:03 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Aaron Dewell , IPng Mailing List Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Aaron, Aaron Dewell wrote: > > Why not just call that the cost of doing business in the default-free > zone? If you choose to put your router/organization there, that has > some costs X associated with it. It also has other advantages > (reliability, speed, etc.) that come with it also. Those advantages > have costs. The fact that others (the end-networks) have influence > over what those costs are is not relevant. > That is fine, but the real problem comes up when the end-network sites decide they too want to become multihomed. The site that wants to become multihomed and have its routes propagated above that site's proper aggregation providers should pay something for each additional route it wants propagated past each provider. > Seems to me wanting people to pay for the resources of being in a better > position is kindof ... greedy. Anyone who is part of the backbone has a > business reason for being there, and needs to pay the cost of that reason. > Certainly, and each end-site that wants to propagate additional routes through this backbone provider incurs an additional cost for each additional route. Why should the end-site not pay that cost. > Having the providers who reap the benefits of being there **is** the only > reasonable long-term way to ensure that we can continue to accomodate that > kind of behavior. ;-) > > Aaron > Yours sincerelyl, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 13:47:47 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA26013 for ipng-dist; Wed, 21 Jul 1999 13:46:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26005 for ; Wed, 21 Jul 1999 13:45:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA10064 for ; Wed, 21 Jul 1999 13:45:48 -0700 (PDT) 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 OAA19117 for ; Wed, 21 Jul 1999 14:45:41 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id PAA03791 for ; Wed, 21 Jul 1999 15:45:32 -0500 (CDT) Message-Id: <199907212045.PAA03791@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Dialup issues In-reply-to: Your message of 21 Jul 1999 19:56:42 +0200. Date: Wed, 21 Jul 1999 15:45:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Are there any documents describing how to assign addresses to dialup > lines? > > Assigning /64 to dialup lines seems like overkill, yet people want to > run some sort of network at home with all the machines having global > addresses. You can give a single address with PPP. The next step from there is a /64. And it makes sense, because isn't this exactly one sort of customer for whom autoconfiguration is very important? It would make sense to leave the endpoints of the link itself without global addresses and allot the /64 to the subnet behind the dialup peer. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 14:17:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA26100 for ipng-dist; Wed, 21 Jul 1999 14:14:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26093 for ; Wed, 21 Jul 1999 14:13:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA04732 for ; Wed, 21 Jul 1999 14:13:55 -0700 (PDT) Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24124 for ; Wed, 21 Jul 1999 14:13:52 -0700 (PDT) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id JAA21278; Thu, 22 Jul 1999 09:13:16 +1200 (NZST) Date: Thu, 22 Jul 1999 09:13:15 +1200 From: Joe Abley To: Sam Manthorpe Cc: Joe Abley , perry@piermont.com, richdr@microsoft.com, ipng@sunroof.eng.sun.com, pete@sms.fi, map@stacken.kth.se, cmetz@inner.net, kuznet@ms2.inr.ac.ru, rrockell@sprint.net Subject: Re: Bad routes update Message-ID: <19990722091315.A15134@patho.gen.nz> References: <19990721203820.A81633@clear.co.nz> <199907211705.KAA28703@bossette.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199907211705.KAA28703@bossette.engr.sgi.com>; from Sam Manthorpe on Wed, Jul 21, 1999 at 10:05:31AM -0700 X-Files: the Truth is Out There Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jul 21, 1999 at 10:05:31AM -0700, Sam Manthorpe wrote: > > Joe Abley wrote: > > > If site renumbering were done on a regular basis this could turn out > > > to be quite annoying, but that won't happen, will it. Site renumbering > > > will be much rarer than your next-hop router going down for > 10 mins > > > and you losing your connection, IMO. > > > > We routinely re-route inbound traffic through a backup carrier in order > > to do maintenance on our primary inbound (US -> NZ) network without > > customers being affected. It is not acceptable for all TCP sessions > > to break whenever we decide to re-route traffic for a couple of hours. > > Yes but you don't routinely renumber your site. You just change routes > and that works fine in IPv6 as it does in IPv4. No, it won't. Since we are not a (p)TLA, the current rules forbid us to advertise our prefixes to all our transit ASes. This effectively means that TCP endpoints need to renumber to recover from a network event such as that I described. > Or are you talking about moving your NAT box rom one net to another? No NAT here. We're a wholesale supplier of IPv4 transit to about twenty ISPs, and have several hundred dedicated-access (i.e. permenantly- connected) retail customers, and around 100,000 dial-up users. > > > > People use this *now*. I don't think it is reasonable to break them. > > > > > > Er, don't exactly the same multi-homing issues exist with v4 right now? > > > > Nope. > > So you can change the outgoing interface of your TCP connection, > together with the source address of your TCP 4-tuple and your > connection stays up? Please tell me more! No. I don't need to, since all my IPv4 transit ASes are happy for me to announce the (relatively) long-prefix routes that describe all possible TCP endpoints within my network to them. No TCP endpoint renumbering or other bolt-on TCP stability techniques required. That was my point. Joe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 14:39:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA26162 for ipng-dist; Wed, 21 Jul 1999 14:36:11 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26155 for ; Wed, 21 Jul 1999 14:36:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA22524 for ; Wed, 21 Jul 1999 14:36:00 -0700 (PDT) Received: from snowy2.woods.net (snowy2.woods.net [209.112.190.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03012 for ; Wed, 21 Jul 1999 14:35:56 -0700 (PDT) Received: by snowy2.woods.net id m11741n-000INRC (Solaris Smail-3.2.0.104 1998-Nov-20 #2); Wed, 21 Jul 1999 13:35:51 -0800 (AKDT) From: Aaron Dewell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14230.15671.239764.278370@snowy.woods.net> Date: Wed, 21 Jul 1999 13:35:51 -0800 (AKDT) To: robert@digi-data.com X-Face: F Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) In-Reply-To: <99Jul21.163603gmt-0400.15234@odin.digi-data.com> References: <99Jul21.163603gmt-0400.15234@odin.digi-data.com> X-Mailer: VM 6.63 under 20.4 "Emerald" XEmacs Lucid Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Honore wrote: > That is fine, but the real problem comes up when the end-network sites decide > they too want to become multihomed. The site that wants to become multihomed > and have its routes propagated above that site's proper aggregation providers > should pay something for each additional route it wants propagated past each > provider. They do pay. They pay their BB provider for service. You're saying the other BBs should be paid also, which I think is wrong. By virtue of being a BB provider, they have a certain commercial advantage. Advantages cost money. To play in that market, they should maintain that infrastructure (and costs). If they can't, they aren't in the backbone market. Backbone providers charge more money because they are the Internet backbone. Running a router with a *large* quantity of memory is part of being in the default-free zone. You want to have them charge more money for better connectivity (which they have), but have it not cost them anything to provide that. Wrong. All services have a cost to provide, this is one of them. This cost is not the responsibility of the end-site, it is a cost of doing business in that market. > Certainly, and each end-site that wants to propagate additional routes through > this backbone provider incurs an additional cost for each additional route. Why > should the end-site not pay that cost. Because the ones getting the bonus are not them. They shouldn't pay, that is a service provided by the backbones so they can provide backbone service. No, the end-site should not be paying to propagate routes. _______________________________________________________________________ |Aaron Dewell ===> acd@woods.net | |http://www.woods.net/~acd http://www.woods.net/ | |PGP keyid 0x0D12A6B9 available from http://keys.pgp.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 Jul 21 15:29:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA26229 for ipng-dist; Wed, 21 Jul 1999 15:23:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26222 for ; Wed, 21 Jul 1999 15:23:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA18017 for ; Wed, 21 Jul 1999 15:23:16 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21052 for ; Wed, 21 Jul 1999 15:23:14 -0700 (PDT) Received: by odin.digi-data.com id <15234>; Wed, 21 Jul 1999 18:18:57 -0400 Message-Id: <99Jul21.181857gmt-0400.15234@odin.digi-data.com> Date: Wed, 21 Jul 1999 18:25:50 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: Session Stability (was multi-homing vs route aggregation (was Re: Bad routes update)) References: <199907211837.AA16970@zed.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There are two distinct threads here: Route Containment and Session Stability. Now that I mention it, I do think we need to visit that question of session stability yet again. My objection to Peter Tattam's document titled "Routing Idea - A variation on GSE ", I will refer to it [GSE+], is that it still requires making changes to the IP header as it traverses a site's border routers and travels across the network. Additionally, it requires what seems to me to be radical changes to the behaviour of routers. Otherwise, [GSE+] does cover an important point about session stability, that is, the need to provide a unique number for a node to identify its transport connection peer despite any changes to the actual IP address of either peer of the connection. I wish to submit that that need is **not** a routing issue. It is not even a network issue. What we need is a means of associating a number unique within the node with the peer connection end-point. The number does not need to be globally unique. It does not need to be valid forever. The number **does** need to be securely associated with the peer end-point IP address and maybe the peer end-point transport protocol port. Together with such an association we need some kind of agent that keep that association up-to-date for the duration of the connection. The number can be discarded or recycled at the end of the connection. This whole scheme is, I think, similar to the concept originating from C. Huitema. Here is the scheme. Perhaps we can use either a random number or a number otherwise generated when initialising the connection. This number will have the same number of bits as an IP address. We can then use that number in the Protol Control Block. That number will serve as a lookup index within the host to some association with the peer's real IP address. That IP address will then be what is placed in the IP header as the destination address for all packets that will be transmitted until the peer node needs to renumber or choose a different interface or address. When either of the peers needs to change its IP address, the node whose IP address is changing will then activate its agent to send out a request of some sort to change the peer address association. This request will contain the old IP address, the new IP address, together with the two end-point transport protocol port numbers and some kind of signature. The peer that receives such a request should then have its agent acknowledge that request if it accepts the request. Otherwise the peer can either ignore the request or kill the connection. The acknowledgement must also be signed. I know this would probably require the creation of yet another protocol with which to implement the agent, but to me this is more comfortable than altering an IP header in transit. A protocol that could support the agent would probably sit between IP and the transport protocol. Still one should note that this protocol **does not** require transmitting an Agent header (or whatever else you will call it) for every packet. Of course the communicating peers would need to form some kind of security association before this becomes possible, but in the case that either of the peers does not support either the agent or the security, the performance is no worse than what obtains at present. A scheme like this seems to make more sense to me, since it does not depend too much on cooperation from any nodes other than the two peer nodes and the burden remains with these two nodes to maintain the connection. Do remember this is just one way to address the session stability problem. Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 15:54:58 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA26254 for ipng-dist; Wed, 21 Jul 1999 15:51:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26247 for ; Wed, 21 Jul 1999 15:51:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA23073 for ; Wed, 21 Jul 1999 15:51:33 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22004 for ; Wed, 21 Jul 1999 16:51:31 -0600 (MDT) Received: by odin.digi-data.com id <15234>; Wed, 21 Jul 1999 18:47:18 -0400 Message-Id: <99Jul21.184718gmt-0400.15234@odin.digi-data.com> Date: Wed, 21 Jul 1999 18:54:19 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Aaron Dewell , IPng Mailing List Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) References: <99Jul21.163603gmt-0400.15234@odin.digi-data.com> <14230.15671.239764.278370@snowy.woods.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Aaron, > > That is fine, but the real problem comes up when the end-network sites decide > > they too want to become multihomed. The site that wants to become multihomed > > and have its routes propagated above that site's proper aggregation providers > > should pay something for each additional route it wants propagated past each > > provider. > > They do pay. They pay their BB provider for service. You're > saying the other BBs should be paid also, which I think is > wrong. The sentence that runs, "The site that wants to become multihomed ..... should pay something for each additional route it wants propagated past each provider", should have read, "The site that wants to become multihomed and have its routes propagated above that site's proper aggregation providers should pay something for each additional route it wants propagated past its provider." Now if i have end-network site A and this site is multihomed and directly connected to two distinct NLA, TLA or provider sites B and C, what is wrong with paying B if the site A wants to propagate additional routes through B, and what is wrong with paying C if A wants to propagate additional routes through C? Remember this is an end-network site. Normally he is supposed to be singly connected and cannot act as any kind of transit network. You cannot deny that there is a cost for B and C to accommodate site A. Even though it may be very small, that cost is still real. Nobody compelled site A to seek to become multi homed. They do experience a benefit from being multihomed. That benefit also comes at a cost. Note I am **not** advocating that payments be made to any providers to which the end-network site is not **directly connected**. > Backbone providers charge more money because they are the > Internet backbone. Running a router with a *large* quantity of > memory is part of being in the default-free zone. You want to > have them charge more money for better connectivity (which they > have), but have it not cost them anything to provide that. > Wrong. All services have a cost to provide, this is one of > them. This cost is not the responsibility of the end-site, it > is a cost of doing business in that market. > > > Certainly, and each end-site that wants to propagate additional routes through > > this backbone provider incurs an additional cost for each additional route. Why > > should the end-site not pay that cost. > > Because the ones getting the bonus are not them. They shouldn't > pay, that is a service provided by the backbones so they can > provide backbone service. No, the end-site should not be paying > to propagate routes. > Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 16:13:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA26282 for ipng-dist; Wed, 21 Jul 1999 16:09:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26275 for ; Wed, 21 Jul 1999 16:09:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA07490 for ; Wed, 21 Jul 1999 16:09:20 -0700 (PDT) Received: from snowy2.woods.net (snowy2.woods.net [209.112.190.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07351 for ; Wed, 21 Jul 1999 16:09:17 -0700 (PDT) Received: by snowy2.woods.net id m1175U4-000INcC (Solaris Smail-3.2.0.104 1998-Nov-20 #2); Wed, 21 Jul 1999 15:09:08 -0800 (AKDT) From: Aaron Dewell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14230.21268.33023.629157@snowy.woods.net> Date: Wed, 21 Jul 1999 15:09:08 -0800 (AKDT) To: robert@digi-data.com X-Face: F Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) In-Reply-To: <99Jul21.184718gmt-0400.15234@odin.digi-data.com> References: <99Jul21.163603gmt-0400.15234@odin.digi-data.com> <14230.15671.239764.278370@snowy.woods.net> <99Jul21.184718gmt-0400.15234@odin.digi-data.com> X-Mailer: VM 6.63 under 20.4 "Emerald" XEmacs Lucid Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Honore wrote: > Now if i have end-network site A and this site is multihomed and directly > connected to two distinct NLA, TLA or provider sites B and C, what is wrong with > paying B if the site A wants to propagate additional routes through B, and what > is wrong with paying C if A wants to propagate additional routes through C? > Remember this is an end-network site. Normally he is supposed to be singly > connected and cannot act as any kind of transit network. End-network includes ISPs, frankly. ISPs and corporate sites look the same. Your argument precludes smaller ISPs (those that cannot qualify for a TLA) from multihoming. I believe that Perry brought up that point - that this practice will encourage folks to pretend they are much bigger than they are in order to have the privilege of being multihomed. "Folks" in this case referring to ISPs who are not multi-state. I see your argument for corporate sites, but I still don't agree with it. Should MicroSoft not be multi-homed? IBM? The point is debatable in those cases, but not for ISPs. ISPs need to multihome because they are in the business of providing absolutely reliable service. > You cannot deny that there is a cost for B and C to accommodate site A. Even > though it may be very small, that cost is still real. Nobody compelled site A > to seek to become multi homed. They do experience a benefit from being > multihomed. That benefit also comes at a cost. Note I am **not** advocating > that payments be made to any providers to which the end-network site is not > **directly connected**. I'm not denying there is a cost. I'm saying that cost is part of doing business in that market, that it shouldn't be passed on. They are paying for being multihomed. They pay two providers instead of one. One provider would (presumably) charge them less for the same (total) bandwidth. Two providers will charge them more. There is their extra costs. I am also not saying that anyone should be able to be multihomed for free. I'm saying that those who do should not be subsidizing the basic business costs of the BB providers. That would be like me asking my customers to each pay $10 for rent on my office space. Clearly, they would not do that. Same if a BB provider asks it's peers (or the end site, it comes to the same thing) to pay a portion of the inherent costs of being a BB site. _______________________________________________________________________ |Aaron Dewell ===> acd@woods.net | |http://www.woods.net/~acd http://www.woods.net/ | |PGP keyid 0x0D12A6B9 available from http://keys.pgp.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 Jul 21 16:57:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA26330 for ipng-dist; Wed, 21 Jul 1999 16:54:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26322 for ; Wed, 21 Jul 1999 16:54:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA21262 for ; Wed, 21 Jul 1999 16:54:32 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA13581 for ; Wed, 21 Jul 1999 17:54:32 -0600 (MDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA17006 for ; Wed, 21 Jul 1999 16:54:32 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <87vhbeaw68.fsf@jekyll.piermont.com> References: <4D0A23B3F74DD111ACCD00805F31D8101451560C@RED-MSG-50> <4.2.0.56.19990721162108.00ba1540@brahma.imag.fr> <87vhbeaw68.fsf@jekyll.piermont.com> Date: Wed, 21 Jul 1999 16:54:29 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: Re: multi-homing vs route aggregation Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am getting *really* tired of messages of the form "If IPv6 doesn't do foo, it will be dead on arrival!", usually accompanied by someone else saying "If IPv6 *does* do foo, it will be dead on arrival!", and usually written in an authoritative/threatening tone of email that implies that anyone who doesn't agree is an utter fool and if the writer doesn't get his (for some reason, it's always a "he") own way, he will take his ball and go home, and maybe tell the whole world what nincompoops the IPv6 designers are, too! Look, folks, these are tough issues, with no easy or painless solutions. In many cases, solutions involve making not just technical tradeoffs, but also economic and political tradeoffs, and where one stands on a specific issue often depends on where one sits (i.e., the valid concerns of implementors, providers, users, managers, consultants, architects, academics, legislators, et al are often at odds with one other). If we are going to succeed in this effort, we need to have a lot more respect for differing opinions, and more flexibility in accommodating solutions other than our first choices. (End of rant.) Regarding the specific issue of site multihoming vs. route aggregation, I don't think we ought to just dismiss the concerns about route aggregation with appeals to Moore's law or Adam Smith's invisible hand. I would prefer to not rule out a possible IPv6 future in which many millions of sites (e.g., many households) are connected to multiple service providers (whether for robustness or for different grades of service at different prices or whatever), and those sites don't each have to send a cheque for $0.00001 to every service provider in the world to pay for the extra memory, bandwidth, and CPU cycles required to support one more prefix in the providers' routers, in order to get the benefits from multihoming. Perhaps route aggregation will become less of a concern due to technological advances, but I think it is (a) premature to count on it, and (b) clearly a very hard sell in much of the current ISP community, for whatever reasons. (A number of vocal members of that community have loudly proclaimed that, if IPv6 doesn't fix the route aggregation problem, all it will do is make the routing tables four times larger for absolutely no benefit [dismissing the benefit of global addressing], and so we should all just wait for something that *does* solve the route aggregation problem.) Therefore, I suggest that it is prudent and worthwhile to continue to work on other ways to support multi-homed sites well, other than injecting their prefixes into the top-level routing, such as: - better end-host support for multihoming, with the goal of making transport protocols tolerant of changes of address availability/reachability, just like they are currently tolerant of packet loss, reordering, delay, and duplication. (This is the "don't trust the network" philosophy of TCP, which was the fundamental key to its success.) - RFC2260-style or mobile-IP-style tunneling approaches to allow continued use of addresses when the "native" routing for those addresses isn't working or isn't the best. - schemes like metro-based addressing which reduce the need for a multi-homed site to have multiple address prefixes by "flattening" the routing in a local region, rather than flattening the routing globally). - schemes that add another level of naming above or below the IP addressing layer to allow the routing system to operate on different names than the transport protocols, like map-n-encap or GSE+ or something that takes advantage of the EUI64-based node IDs embedded in IPv6 addresses. Most of these directions can be pursued without holding up implementation or deployment of IPv6, i.e., they would be additional capabilities that could be implemented and deployed in a backwards-compatible manner over the next few years if they looked good. (That's probably not true of the GSE+ type of schemes, which is why I personally am less than enthusiastic about those approaches.) (With regard to holding up deployment, there were some messages recently that expressed concern that changing the API to support, e.g., passing a DNS name rather than an IPv6 address in a "connect" call, would set us back years in development and deployment. I think there is a misunderstanding there. Any such change would be an *addition* to the API. The current API would continue to be supported. Applications could be upgraded to support the new API over time, and applications using the new API could co-exist with, and interoperate with, those using the current API. No need to hold up anything at this point.) Finally, on top of the depression I feel at reading all the inflexible bickering and posturing on the IPv6 lists, today brought the good news that Apple is going to make wireless Ethernet (IEEE 802.11) base-stations affordable at last (see ), but the bad news that a major selling point of Apple's new device is its built-in NAT capability. Sigh. 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 Wed Jul 21 21:34:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA00365 for ipng-dist; Wed, 21 Jul 1999 21:31:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00358 for ; Wed, 21 Jul 1999 21:31:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA17571 for ; Wed, 21 Jul 1999 21:31:28 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA20067 for ; Wed, 21 Jul 1999 22:31:26 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id OAA29780; Thu, 22 Jul 1999 14:31:14 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Thu, 22 Jul 1999 14:31:14 +1000 (EST) From: Peter Tattam To: Magnus Ahltorp cc: ipng@sunroof.eng.sun.com Subject: Re: Dialup issues 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 On 21 Jul 1999, Magnus Ahltorp wrote: > Are there any documents describing how to assign addresses to dialup > lines? > > Assigning /64 to dialup lines seems like overkill, yet people want to > run some sort of network at home with all the machines having global > addresses. Yeah. That's what I ended up doing to get RA to work correctly on a Cisco. Assigning a /64 to each line may use up addresses a little too fast. Generally, I would prefer to assign a /64 to a group of dialup lines, and let the autoconfig sort out the clashes. I would assum the routers could then assign the remote end point a /128 and keep the server end as unnumbered (much the same as is done in Ipv4). Alternatively, one could use a set of /126 subnets, but I am told this breaks a few Ipv6 implementations that have difficulties with prefixes > 64. As an aside, are Ipv6 implementations supposed to fully implement prefixes > 64. Peter > > /Magnus > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 21:59:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA00391 for ipng-dist; Wed, 21 Jul 1999 21:56:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00384 for ; Wed, 21 Jul 1999 21:56:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA19424 for ; Wed, 21 Jul 1999 21:56:37 -0700 (PDT) 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 VAA10210 for ; Wed, 21 Jul 1999 21:56:36 -0700 (PDT) Received: from 157.54.9.125 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Jul 1999 21:34:04 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2524.0) id ; Wed, 21 Jul 1999 21:34:05 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515626@RED-MSG-50> From: Richard Draves To: "'Francis Dupont'" Cc: "'IPng List'" Subject: TCP survivability with mobile-ip Date: Wed, 21 Jul 1999 21:33:56 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => the mobility stuff (use of bindings) is implemented but not yet the > router renumbering (needed to set preferred lifetimes). Of course it > needs some security (authentication) too. > Another point: this works for ISP failures, not for > renumbering because > old addresses should be stiff valid (but default lifetimes > are 7 and 30 > days then renumbering survival is only a concern with very > long connections). Hi Francis, you mentioned this in Oslo. It's not obvious to me how to use mobile IP bindings to recover from ISP failures. Could you work through a scenario in more detail? 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 Wed Jul 21 22:18:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA00414 for ipng-dist; Wed, 21 Jul 1999 22:09:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA00407 for ; Wed, 21 Jul 1999 22:09:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA06770 for ; Wed, 21 Jul 1999 22:09:11 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA13009 for ; Wed, 21 Jul 1999 22:09:11 -0700 (PDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Jul 1999 21:58:08 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id ; Wed, 21 Jul 1999 21:58:06 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515627@RED-MSG-50> From: Richard Draves To: "'perry@piermont.com'" Cc: "'IPng List'" Subject: RE: Bad routes update Date: Wed, 21 Jul 1999 21:58:07 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > There are two answers to that. The short-term answer is an > RFC 2260-style > > solution. The long-term answer is to change TCP so you can > change endpoint > > addresses, for survivability and renumbering. > > None of this will work today. Do you mean, they would work but they are not ready "today", or you think both approaches are unworkable? One nice aspect of the RFC 2260-style approach is that it's an operational solution, it doesn't require any protocol invention or development. So it should be possible to deploy it "today". Well I don't really know enough about router vendor implementations to be saying that confidently, but that's my understanding. I was thinking of trying to dig up some data on Internet usage or Gartner-style analysis of business internet usage, but then I realized that facts are probably not going to change anyone's mind on this issue :-). Suffice it to say that I agree it's a great thing for TCP connections to survive, and it should be and IS part of the proposal presented in Oslo, but I persist in believing that it's less important than having new TCP connections succeed. > Right now, people pay lots of money for diverse providers for a good > reason. It isn't that they love wasting money. They *need* the > reliability. You're telling us that they don't exist -- but > of course, > if they didn't exist, why would you be worried about them exploding > the routing tables? No, it's the opposite. I agree that they exist and I think in the future many many more people/companies will want to be multihomed. This would actually be a selling point for v6, if we have a better story for multihoming than v4 does. 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 Wed Jul 21 23:40:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA00548 for ipng-dist; Wed, 21 Jul 1999 23:36:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00541 for ; Wed, 21 Jul 1999 23:36:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA01964 for ; Wed, 21 Jul 1999 23:36:11 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA02056 for ; Wed, 21 Jul 1999 23:36:11 -0700 (PDT) Received: from [171.68.179.121] (sj-dial-1-120.cisco.com [171.68.179.121]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id XAA04816; Wed, 21 Jul 1999 23:34:58 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Wed, 21 Jul 1999 23:34:57 -0700 To: Magnus Ahltorp , Peter Tattam From: Steve Deering Subject: Re: Dialup issues Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 7:56 PM +0200 7/21/99, Magnus Ahltorp wrote: >Assigning /64 to dialup lines seems like overkill, yet people want to >run some sort of network at home with all the machines having global >addresses. There were some back-of-the-envelope studies done during the IPng selection process that indicated that 48 bits would be enough to address something like every enterprise, residence, and automobile in the world, based on UN population predictions for the year 2025 or thereabouts. This included accounting for the inevitable inefficiency of hierarchical addressing, but assumed some discipline in the allocation of those 48 bits (e.g., not forcing all hierarchical boundaries to fall on a multiple of 4 or 8 bits). Thus, I see no inherent problem in allocating as much as a /48 worth of space to a dial-up connection to a home; that would allow the customer to have many home subnets (e.g., a "body net" of wearable computers for each person living there, a network in each of the homes's vehicles, plus various non-mobile nets, each using EUI64- based stateless autoconfiguration for transparent plug-and-play. Though I suppose by the time that's common, we won't have to put up with silly "dial-up" connections any more... However, I understand that the idea of giving each home 80 bits worth of address space is hard to fathom by most of us who are suffering from IPv4's address scarcity (kinda like people in the old Soviet Union not being able to comprehend the abundance of an American supermarket). So maybe starting with /64s for dial-up connections is a reasonable initial step (like the way people who have been starving should be careful about overeating when they finally find food), but let's not worry about trying to conserve /64s. There are a *lot* of them. And the last thing we want is for IPv6 users to feel they need to install an IPv6 NAT box to get a bigger address space than they can get from their ISP(s)! At 2:31 PM +1000 7/22/99, Peter Tattam wrote: >As an aside, are Ipv6 implementations supposed to fully implement >prefixes > 64. Yes. Most of the unicast address space has been specified to have a 64-bit interface ID field, but not all of it. IPv6 implementations ought to be able to handle prefixes of any length. 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 Thu Jul 22 00:02:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA00570 for ipng-dist; Wed, 21 Jul 1999 23:59:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00563 for ; Wed, 21 Jul 1999 23:59:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA03305 for ; Wed, 21 Jul 1999 23:59:25 -0700 (PDT) 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 AAA19683 for ; Thu, 22 Jul 1999 00:59:24 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id XAA23359; Wed, 21 Jul 1999 23:58:59 -0700 (PDT) From: Bill Manning Message-Id: <199907220658.XAA23359@boreas.isi.edu> Subject: Re: Dialup issues To: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Wed, 21 Jul 1999 23:58:59 -0700 (PDT) Cc: map@stacken.kth.se (Magnus Ahltorp), ipng@sunroof.eng.sun.com In-Reply-To: from "Peter Tattam" at Jul 22, 1999 02:31:14 PM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > the same as is done in Ipv4). Alternatively, one could use a set of /126 > subnets, but I am told this breaks a few Ipv6 implementations that have > difficulties with prefixes > 64. > > As an aside, are Ipv6 implementations supposed to fully implement prefixes > > 64. > > Peter Citing an old addage: "Be Conservative in what you send, Liberal in what you receive" and noting that there remains the option to evolve how the address architecture looks, (noting that IPv4 underwent at least three iterations in 25 years and IPv6 has done the same number in 5) I think it would be prudent to allow flexability. If it was me, I'd treat the whole 128 bits as CIDRizable. -- --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 Thu Jul 22 01:53:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA00780 for ipng-dist; Thu, 22 Jul 1999 01:50:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00772 for ; Thu, 22 Jul 1999 01:50:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA09811 for ; Thu, 22 Jul 1999 01:50:00 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA09833 for ; Thu, 22 Jul 1999 02:49:59 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id KAA22561; Thu, 22 Jul 1999 10:49:44 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id KAA11197; Thu, 22 Jul 1999 10:49:43 +0200 (MET DST) Message-Id: <199907220849.KAA11197@givry.inria.fr> From: Francis Dupont To: Peter Tattam cc: Magnus Ahltorp , ipng@sunroof.eng.sun.com Subject: Re: Dialup issues In-reply-to: Your message of Thu, 22 Jul 1999 14:31:14 +1000. Date: Thu, 22 Jul 1999 10:49:42 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: As an aside, are Ipv6 implementations supposed to fully implement prefixes > 64. => since the 64-bit interface ID introduction I believe there are only three cases for prefix lengths: - less than 64 bits (they should not be used for link prefixes) - 64 bits (link prefixes) - 128 bits (cheap point-to-point link prefixes) I think you can use 128 bit or 64 bit prefixes for PPP, *not* 126 or 124 bits. Regards Francis.Dupont@inria.fr PS: my implementation rejects prefix-infos in router advertisements with length < 16 or (length > 64 and length != 128) both in router and host codes since yesterday (I work on prefix discovery for PPP because I had some problems with Unix ifconfig which wants two addresses (local and peer) for point-to-point links... I advise to use the router address stuff (from mobile I-D, 6.2, page 34) on the router side in order to give peer addresses). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 02:13:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA00876 for ipng-dist; Thu, 22 Jul 1999 02:10:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00861 for ; Thu, 22 Jul 1999 02:10:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA20612 for ; Thu, 22 Jul 1999 02:10:14 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA03217 for ; Thu, 22 Jul 1999 02:10:14 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id LAA23110; Thu, 22 Jul 1999 11:10:12 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id LAA03235; Thu, 22 Jul 1999 11:10:12 +0200 (MET DST) Message-Id: <199907220910.LAA03235@givry.inria.fr> From: Francis Dupont To: Richard Draves cc: "'IPng List'" Subject: Re: TCP survivability with mobile-ip In-reply-to: Your message of Wed, 21 Jul 1999 21:33:56 PDT. <4D0A23B3F74DD111ACCD00805F31D81014515626@RED-MSG-50> Date: Thu, 22 Jul 1999 11:10:11 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Hi Francis, you mentioned this in Oslo. It's not obvious to me how to use mobile IP bindings to recover from ISP failures. Could you work through a scenario in more detail? => draft-ietf-ngtrans-6bone-multi-01.txt section 7 pages 10-12 (I can send to you more things out of the list if you'd like) Francis.Dupont@inria.fr PS: the idea emerged during a 6bone BOF at Washington IETF (about multi ISP, routing & survival issues...). Matt Crawford still kept conclusion (?) slides available at http://www-dcg.fnal.gov/~crawdad/mhome/index.htm (broken flag has been replaced by preferred lifetime fall to 0 which is simpler and/then better but this is the only new thing). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 02:33:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA00930 for ipng-dist; Thu, 22 Jul 1999 02:30:10 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00922 for ; Thu, 22 Jul 1999 02:30:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA04437 for ; Thu, 22 Jul 1999 02:30:00 -0700 (PDT) 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 DAA15616 for ; Thu, 22 Jul 1999 03:29:55 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA29551; Thu, 22 Jul 1999 11:23:02 +0200 (MET DST) Message-ID: <19990722112302.C29345@theory.cs.uni-bonn.de> Date: Thu, 22 Jul 1999 11:23:02 +0200 From: Ignatios Souvatzis To: Steve Deering , Magnus Ahltorp , Peter Tattam Cc: ipng@sunroof.eng.sun.com Subject: Re: Dialup issues References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Steve Deering on Wed, Jul 21, 1999 at 11:34:57PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jul 21, 1999 at 11:34:57PM -0700, Steve Deering wrote: > > Yes. Most of the unicast address space has been specified to have a > 64-bit interface ID field, but not all of it. IPv6 implementations > ought to be able to handle prefixes of any length. Most of? I thought that, err... 1/8 were special addresses including multidcast, 1/8 were global aggregatable addresses with the /64 property, and all others reserved for future use? Regards, -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 02:37:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA00948 for ipng-dist; Thu, 22 Jul 1999 02:35:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00941 for ; Thu, 22 Jul 1999 02:35:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA11846 for ; Thu, 22 Jul 1999 02:35:23 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA07622 for ; Thu, 22 Jul 1999 02:35:22 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id LAA23739; Thu, 22 Jul 1999 11:35:21 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id LAA19560; Thu, 22 Jul 1999 11:35:20 +0200 (MET DST) Message-Id: <199907220935.LAA19560@givry.inria.fr> From: Francis Dupont To: Richard Draves cc: "'perry@piermont.com'" , "'IPng List'" Subject: Re: Bad routes update In-reply-to: Your message of Wed, 21 Jul 1999 21:58:07 PDT. <4D0A23B3F74DD111ACCD00805F31D81014515627@RED-MSG-50> Date: Thu, 22 Jul 1999 11:35:19 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: One nice aspect of the RFC 2260-style approach is that it's an operational solution, it doesn't require any protocol invention or development. So it should be possible to deploy it "today". Well I don't really know enough about router vendor implementations to be saying that confidently, but that's my understanding. => when the RFC 2260-style approach was published I found some problems (complex setup, ISP reluctance, link failure only solution) and I asked to Yakov Rekhter if this was deployed and his answer was yes. Perhaps we should ask in IDR or NANOG mailing list in order to know if it is really used? Francis.Dupont@inria.fr PS: RFC 2260 doesn't need something special in router implementations, as you've said it is an operational solution (:-). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 02:37:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA00957 for ipng-dist; Thu, 22 Jul 1999 02:35:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00950 for ; Thu, 22 Jul 1999 02:35:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA11951 for ; Thu, 22 Jul 1999 02:35:38 -0700 (PDT) Received: from squid.pdc.kth.se (squid.pdc.kth.se [130.237.221.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA16439 for ; Thu, 22 Jul 1999 03:35:38 -0600 (MDT) Received: (from d95-mah@localhost) by squid.pdc.kth.se (8.8.7/8.8.7) id LAA11758; Thu, 22 Jul 1999 11:35:19 +0200 (MET DST) To: Steve Deering Cc: Peter Tattam , ipng@sunroof.eng.sun.com Subject: Re: Dialup issues References: From: Magnus Ahltorp Content-Type: text/plain; charset="iso-8859-1" Content-Language: en Date: 22 Jul 1999 11:35:19 +0200 In-Reply-To: Steve Deering's message of "Wed, 21 Jul 1999 23:34:57 -0700" Message-ID: Lines: 18 X-Mailer: Gnus v5.6.45/Emacs 20.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So maybe starting with /64s for dial-up connections is a reasonable > initial step (like the way people who have been starving should be > careful about overeating when they finally find food), but let's not > worry about trying to conserve /64s. There are a *lot* of them. And > the last thing we want is for IPv6 users to feel they need to install > an IPv6 NAT box to get a bigger address space than they can get from > their ISP(s)! The proposal I was going to make was to see a group of dial-ip connections as one /64, and use DHCP to allocate addresses. I haven't yet thought about the neighbour discovery issues involved in sharing a /64 in this way, since I wanted to know if someone else had been working on it. Would it be interesting to study subnet-sharing, or should I just consider it a Bad Thing and forget about it? /Magnus -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 02:58:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA00993 for ipng-dist; Thu, 22 Jul 1999 02:55:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00986 for ; Thu, 22 Jul 1999 02:55:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA12675 for ; Thu, 22 Jul 1999 02:55:32 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA10929 for ; Thu, 22 Jul 1999 02:55:32 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id LAA24022; Thu, 22 Jul 1999 11:55:29 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id LAA19384; Thu, 22 Jul 1999 11:55:26 +0200 (MET DST) Message-Id: <199907220955.LAA19384@givry.inria.fr> From: Francis Dupont To: Richard Draves cc: "'perry@piermont.com'" , "'IPng List'" Subject: Re: Bad routes update In-reply-to: Your message of Wed, 21 Jul 1999 21:58:07 PDT. <4D0A23B3F74DD111ACCD00805F31D81014515627@RED-MSG-50> Date: Thu, 22 Jul 1999 11:55:26 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I persist in believing that it's less important than having new TCP connections succeed. => there are two (nearly solved) cases: - outgoing new connections: if the preferred lifetime of "bad" prefixes is set to zero then we should only use "good" addresses as sources. In order to implement this we need failure detection (ie trigger next actions from a routing event), router renumbering (ie multicast the information) and neighbor discovery (ie standard prefix management), only the router renumbering part is not yet available... - incoming new connections: if literal addresses are used we are already dead. If DNS is used then it returns a set of addresses, "bad" ones don't work then the set is tried in an uncontrolable order until a "good" address works. There is only *one* standard BSD application which tries only one address: lpr. Of course with A6 it will be easy to speed up this mechanism (there will be only one RR to update in case of a failure in place of zillions of AAAA RRs which is simpler, faster and can be done with short TTLs). Then the new connection issue is solved on the paper. I agree this should be tested and deployed asap. Regards Francis.Dupont@inria.fr PS: I believe standard Windows applications are doing the same kind of things than in BSD, ie try the list of addresses returned by the DNS until one works? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 03:47:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA01049 for ipng-dist; Thu, 22 Jul 1999 03:44:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01042 for ; Thu, 22 Jul 1999 03:44:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA07323 for ; Thu, 22 Jul 1999 03:44:08 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA20305 for ; Thu, 22 Jul 1999 03:44:07 -0700 (PDT) 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 TAA19680; Thu, 22 Jul 1999 19:43:20 +0900 (JST) To: Francis Dupont cc: Richard Draves , "'perry@piermont.com'" , "'IPng List'" In-reply-to: Francis.Dupont's message of Thu, 22 Jul 1999 11:55:26 +0200. <199907220955.LAA19384@givry.inria.fr> 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: Bad routes update From: itojun@iijlab.net Date: Thu, 22 Jul 1999 19:43:20 +0900 Message-ID: <19678.932640200@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - outgoing new connections: if the preferred lifetime of "bad" prefixes > is set to zero then we should only use "good" addresses as sources. > In order to implement this we need failure detection (ie trigger > next actions from a routing event), router renumbering (ie multicast > the information) and neighbor discovery (ie standard prefix management), > only the router renumbering part is not yet available... I believe you can solve this with RFC2260 in reverse direction as well. ingress filtering may cause some trouble, but basically it is possible to use RFC2260-like approach for this. 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 Jul 22 07:14:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA01263 for ipng-dist; Thu, 22 Jul 1999 07:11:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01256 for ; Thu, 22 Jul 1999 07:10:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA21235 for ; Thu, 22 Jul 1999 07:10:53 -0700 (PDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05813 for ; Thu, 22 Jul 1999 07:10:51 -0700 (PDT) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 010F8193; Thu, 22 Jul 1999 10:10:48 -0400 (EDT) To: Richard Draves Cc: "'IPng List'" Subject: Re: Bad routes update References: <4D0A23B3F74DD111ACCD00805F31D81014515627@RED-MSG-50> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 22 Jul 1999 10:10:48 -0400 In-Reply-To: Richard Draves's message of "Wed, 21 Jul 1999 21:58:07 -0700" Message-ID: <87lnc86ahj.fsf@jekyll.piermont.com> Lines: 58 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Draves writes: > > > There are two answers to that. The short-term answer is an > > RFC 2260-style > > > solution. The long-term answer is to change TCP so you can > > change endpoint > > > addresses, for survivability and renumbering. > > > > None of this will work today. > > Do you mean, they would work but they are not ready "today", or you think > both approaches are unworkable? I personally feel the approaches are not known to be workable, but that's really not important here. What I actually insist on seeing working code with some test deployment experience before we consider relying on something. Call me old fashioned, but I don't like the OSI "design first and see if it works later" approach that's been infecting the IETF lately. All too often, it turns out a great idea doesn't actually work. (I have a lot of concrete concerns, by the way. One of the biggest problems with various EID schemes right now, by the way, is their reliance on IPSec for *all* TCP traffic in order to get anything like a semblance of network security. Unfortunately, to date, I know of no one who's tried running a network that way (and I speak a one of the fairly early IPSec guys). However, I'm willing to be proven wrong -- by working code.) We have a working operational model of how to do this now. When we see a new *working* operational model, then we can consider demanding that people give up their old model. Until then, I'm going to keep shouting pretty loudly that people are going to have to accept punched holes in the routing topology for multihomed sites, and that at some point they're going to have to just accept that the only reasonable way to handle this is economics, not technology. > > Right now, people pay lots of money for diverse providers for a good > > reason. It isn't that they love wasting money. They *need* the > > reliability. You're telling us that they don't exist -- but > > of course, > > if they didn't exist, why would you be worried about them exploding > > the routing tables? > > No, it's the opposite. I agree that they exist and I think in the future > many many more people/companies will want to be multihomed. This would > actually be a selling point for v6, if we have a better story for > multihoming than v4 does. But after seven years, we haven't come up with one we can show, have we. We've had lots of smart people think about this and come up with straw proposals, but we've yet to see one actually demonstrated to work smoothly in the real world. Lots of smart people haven't yet come up with something really usable yet. When they do, we can reconsider. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 07:29:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA01313 for ipng-dist; Thu, 22 Jul 1999 07:24:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01306 for ; Thu, 22 Jul 1999 07:23:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA04902 for ; Thu, 22 Jul 1999 07:23:55 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09737 for ; Thu, 22 Jul 1999 07:23:53 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id AAA08921 for ; Fri, 23 Jul 1999 00:23:51 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Fri, 23 Jul 1999 00:23:51 +1000 (EST) From: Peter Tattam To: IPNG Mailing List Subject: waiting for IETF minutes.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk with baited breath... how long? Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 07:29:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA01334 for ipng-dist; Thu, 22 Jul 1999 07:28:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01327 for ; Thu, 22 Jul 1999 07:28:12 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA26457 for ; Thu, 22 Jul 1999 07:28:12 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11080 for ; Thu, 22 Jul 1999 07:28:11 -0700 (PDT) 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 XAA23214; Thu, 22 Jul 1999 23:26:31 +0900 (JST) To: perry@piermont.com cc: "'IPng List'" In-reply-to: perry's message of 22 Jul 1999 10:10:48 -0400. <87lnc86ahj.fsf@jekyll.piermont.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: Bad routes update From: itojun@iijlab.net Date: Thu, 22 Jul 1999 23:26:30 +0900 Message-ID: <23212.932653590@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> > > There are two answers to that. The short-term answer is an RFC 2260-style >> > > solution. The long-term answer is to change TCP so you can change endpoint >> > > addresses, for survivability and renumbering. >> > None of this will work today. >> Do you mean, they would work but they are not ready "today", or you think >> both approaches are unworkable? >I personally feel the approaches are not known to be workable, but >that's really not important here. (snip) >We have a working operational model of how to do this now. When we see >a new *working* operational model, then we can consider demanding that >people give up their old model. Until then, I'm going to keep shouting >pretty loudly that people are going to have to accept punched holes in >the routing topology for multihomed sites, and that at some point >they're going to have to just accept that the only reasonable way to >handle this is economics, not technology. I believe RFC2260 just work, today. There's no extra code needed. When you have two upstream ISP (ISP A and ISP B), all we needs to do are: - to setup tunnel between ISP A to your exit router B, and ISP B to your exit router A (ISP coordination needed) - Then, announce routes properly with preference coordinated between two exit routers. This can be done by BGP if you have AS#, or by RIPng if you coordinate with ISPs properly. You do not need to announce more-specific route toward backbone to achieve this. I'll be testing this configuration in my home soon. One issue you may worry about is how to convince ISPs. We are yet to see IPv6 ISPs (there are few, but not many). If first dozen of ISPs support RFC2260, newcommers will. (am I too optimistic?) We are really good at setting up tunnels BTW :-) 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 Jul 22 07:43:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA01394 for ipng-dist; Thu, 22 Jul 1999 07:39:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01387 for ; Thu, 22 Jul 1999 07:39:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA29842 for ; Thu, 22 Jul 1999 07:39:45 -0700 (PDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14487 for ; Thu, 22 Jul 1999 07:39:44 -0700 (PDT) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 24726193; Thu, 22 Jul 1999 10:39:40 -0400 (EDT) To: itojun@iijlab.net Cc: "'IPng List'" Subject: Re: Bad routes update References: <23212.932653590@coconut.itojun.org> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 22 Jul 1999 10:39:40 -0400 In-Reply-To: itojun@iijlab.net's message of "Thu, 22 Jul 1999 23:26:30 +0900" Message-ID: <87emi0695f.fsf@jekyll.piermont.com> Lines: 22 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > I believe RFC2260 just work, today. There's no extra code needed. The "inject routes only during failures" idea in 2260 is okay, but the "add engineering tunnels" idea leads to seriously bad performance issues during failures as lots of traffic suddenly traverses encapsulated over the net. Neither will cope reasonably with the issue of picking an appropriate prefix on laptop with which to try connecting to some site -- if you have multihomed for performance reasons, we'd still need protocols to tell desktop machines that going out via ISP A is better by far than going out via ISP B. In the inverse sense, and in many ways more critically, your customers will need to figure out which of the two IP addresses a machine is known by is "better" for it to connect to. Maybe some of this could be solved by query protocols by which end stations could ask "which of these N addresses is `closest'", but we don't yet have such protocols done. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 08:09:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA01420 for ipng-dist; Thu, 22 Jul 1999 08:06:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01413 for ; Thu, 22 Jul 1999 08:06:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA03413 for ; Thu, 22 Jul 1999 08:06:27 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24984 for ; Thu, 22 Jul 1999 09:04:17 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id BAA10431; Fri, 23 Jul 1999 01:03:10 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Fri, 23 Jul 1999 01:03:10 +1000 (EST) From: Peter Tattam To: itojun@iijlab.net cc: perry@piermont.com, "'IPng List'" Subject: Re: Bad routes update In-Reply-To: <23212.932653590@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 22 Jul 1999 itojun@iijlab.net wrote: > > >> > > There are two answers to that. The short-term answer is an RFC 2260-style > >> > > solution. The long-term answer is to change TCP so you can change endpoint > >> > > addresses, for survivability and renumbering. > >> > None of this will work today. > >> Do you mean, they would work but they are not ready "today", or you think > >> both approaches are unworkable? > >I personally feel the approaches are not known to be workable, but > >that's really not important here. > (snip) > >We have a working operational model of how to do this now. When we see > >a new *working* operational model, then we can consider demanding that > >people give up their old model. Until then, I'm going to keep shouting > >pretty loudly that people are going to have to accept punched holes in > >the routing topology for multihomed sites, and that at some point > >they're going to have to just accept that the only reasonable way to > >handle this is economics, not technology. > > I believe RFC2260 just work, today. There's no extra code needed. > > When you have two upstream ISP (ISP A and ISP B), all we needs to > do are: > - to setup tunnel between ISP A to your exit router B, and ISP B to > your exit router A (ISP coordination needed) > - Then, announce routes properly with preference coordinated between > two exit routers. > This can be done by BGP if you have AS#, or by RIPng if you coordinate > with ISPs properly. You do not need to announce more-specific route > toward backbone to achieve this. I'll be testing this configuration > in my home soon. > > One issue you may worry about is how to convince ISPs. > We are yet to see IPv6 ISPs (there are few, but not many). > If first dozen of ISPs support RFC2260, newcommers will. > (am I too optimistic?) > > We are really good at setting up tunnels BTW :-) > > 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 > -------------------------------------------------------------------- > I have used this very technique in IPv4 to deal with a UHF radio link that occasionally drops out. Consider our situation... TSI head office <----------- radio link ----------> Hobart CBD backbone | | | | V V Large Telco & ISP Smaller ISP & telco | | +---------------------- Greater Internet ---------------+ We have connections to two ISPs. We also have two locations for our peering points. One peering point is direct to our head office which is not in the CBD. It is provided by "Large telco", and goes direct to their IP cloud. We also have a not quite as large ISP, but the cost of getting traffic to TSI head office is fairly expensive as "Large Telco" pretty much controls all data traffic in the region. The locations are close physically, but because of a large water mass (deep river between two), there is quite a distance to go to get a direct link by land, so we have opted for the time being to use radio. Occasionally there is an interruption to the radio service for weather reasons or when a very large ship docks right in front of the radio path. To make this survive I have a tunnel operating between the two networks which uses IP addresses from each backbone ISP to form the end points. This is up all the time, but has a routing cost higher than the normal link across the river. When the link dies, the routers at each end detect the outage and the tunnel kicks in. Usually the time to detect it is less than a minute, and TCP connections usually survive unless they have a small timeout. This is all done with EIGRP as the IGP. While this is a simple example, I did find it took me a while to get working correctly and there were some bizarre interactions with BGP which needed some tweaking to get right, but they were possibly related to poor BGP configuration in the first place. Anyway, just to let you know that this works now, and could be endorsed if ISPs get more used to working with tunnels. I remember trying to explain the setup to a Cisco help desk when debugging it & they were a little taken aback. The downsides are the increased size of packets and possible fragmentation that may occur. As such, I only see it as a solution for temporary outages. As an aside, I also tried the same technique to redirect traffic temporarily on our private USA-AUS link for testing purposes. Worked quite handsomely. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 08:16:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA01487 for ipng-dist; Thu, 22 Jul 1999 08:15:20 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01476 for ; Thu, 22 Jul 1999 08:15:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA10639 for ; Thu, 22 Jul 1999 08:15:09 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26401 for ; Thu, 22 Jul 1999 08:15:08 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id BAA10831; Fri, 23 Jul 1999 01:14:55 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Fri, 23 Jul 1999 01:14:55 +1000 (EST) From: Peter Tattam To: "Perry E. Metzger" cc: itojun@iijlab.net, "'IPng List'" Subject: Re: Bad routes update In-Reply-To: <87emi0695f.fsf@jekyll.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 22 Jul 1999, Perry E. Metzger wrote: > > itojun@iijlab.net writes: > > I believe RFC2260 just work, today. There's no extra code needed. > > The "inject routes only during failures" idea in 2260 is okay, but the > "add engineering tunnels" idea leads to seriously bad performance > issues during failures as lots of traffic suddenly traverses > encapsulated over the net. Not so bad. I didn't notice significant degradation in my example. Some network is better than no network :) BTW, my BGP setup is stuffed up because the cost of getting the routers upgraded sufficiently to run full BGP at both ends does not justify the benefit of doing so at this stage. At a pinch, I can staticly reconfigure the network to use one provider or the other, or I can build in a fail safe to switch over to the other provider. This is an argument in favour of aggregation as the BGP tables would be more manageable. > > Neither will cope reasonably with the issue of picking an appropriate > prefix on laptop with which to try connecting to some site -- if you > have multihomed for performance reasons, we'd still need protocols to > tell desktop machines that going out via ISP A is better by far than > going out via ISP B. In the inverse sense, and in many ways more > critically, your customers will need to figure out which of the two IP > addresses a machine is known by is "better" for it to connect to. > I believe the tunnel technique would solve this as all addresses should still be visible. Indeed, an end user could survive by still having only one primary address allocation from one NLA for their main use, and a secondary address allocation from a second NLA just for getting tunnels to route in the right direction. > Maybe some of this could be solved by query protocols by which end > stations could ask "which of these N addresses is `closest'", but we > don't yet have such protocols done. > > Perry > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 08:21:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA01523 for ipng-dist; Thu, 22 Jul 1999 08:18:58 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01514 for ; Thu, 22 Jul 1999 08:18:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA00242 for ; Thu, 22 Jul 1999 08:18:49 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27626 for ; Thu, 22 Jul 1999 08:18:47 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id BAA10999 for ; Fri, 23 Jul 1999 01:17:31 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Fri, 23 Jul 1999 01:17:30 +1000 (EST) From: Peter Tattam To: IPNG Mailing List Subject: Re: waiting for IETF minutes.. 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 On Fri, 23 Jul 1999, Peter Tattam wrote: > with baited breath... bated... Oh boy am I embarrased.. :) > > how long? > > Peter > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 08:29:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA01559 for ipng-dist; Thu, 22 Jul 1999 08:26:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01552 for ; Thu, 22 Jul 1999 08:25:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA01007 for ; Thu, 22 Jul 1999 08:25:21 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00124 for ; Thu, 22 Jul 1999 08:25:20 -0700 (PDT) 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 AAA24111; Fri, 23 Jul 1999 00:25:14 +0900 (JST) To: perry@piermont.com cc: "'IPng List'" In-reply-to: perry's message of 22 Jul 1999 10:39:40 -0400. <87emi0695f.fsf@jekyll.piermont.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: Bad routes update From: itojun@iijlab.net Date: Fri, 23 Jul 1999 00:25:14 +0900 Message-ID: <24109.932657114@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I believe RFC2260 just work, today. There's no extra code needed. >The "inject routes only during failures" idea in 2260 is okay, but the >"add engineering tunnels" idea leads to seriously bad performance >issues during failures as lots of traffic suddenly traverses >encapsulated over the net. >Neither will cope reasonably with the issue of picking an appropriate >prefix on laptop with which to try connecting to some site -- if you >have multihomed for performance reasons, we'd still need protocols to >tell desktop machines that going out via ISP A is better by far than >going out via ISP B. In the inverse sense, and in many ways more >critically, your customers will need to figure out which of the two IP >addresses a machine is known by is "better" for it to connect to. I tried to be silent but I couldn't :-P Again, there are policy issues in multihoming. 100 people have 100 different reasons for multihoming. 100 people have 100 ways to decide which route is "better". What does "better" means in your text? RFC2260 tries to route your packet as much as possible during link failures. So RFC2260 can be the foundation for other multihoming technologies. With RFC2260 we can control routing to prefer leased line over tunnels. Using source address/destination address pair selection heuristics with RFC2260, you may be able to use (possibly) shorter route, based on prefix-length match. However, as nobody has the whole picture of the Internet I would say that src/dst addr selection is just for heurestics. This is documented by Rich Draves. Performance-oriented multihoming has no solution today for IPv4, since: - query packet will change the performance metric value (schrodinger's cat-in-the-box) - what is the preformance metric value for you? roundtrip time? bandwidth? (let me know if you have solution for IPv4, I love to hear that), I believe this is VERY^128 hard problem. We need a clear categorization of problem domain, and then we need to see if we have solution. Just saying "we need multihoming" is not useful. So, we need to be silent till minutes comes up. 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 Jul 22 08:30:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA01568 for ipng-dist; Thu, 22 Jul 1999 08:28:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01561 for ; Thu, 22 Jul 1999 08:28:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA01391 for ; Thu, 22 Jul 1999 08:28:45 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03989 for ; Thu, 22 Jul 1999 09:28:43 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id BAA11384 for ; Fri, 23 Jul 1999 01:28:38 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Fri, 23 Jul 1999 01:28:36 +1000 (EST) From: Peter Tattam To: "'IPng List'" Subject: Re: Bad routes update 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 This might be jumping the gun a little, but in the "choosing the soruce address" part of the debate, how well will autoconfiged host pick up a topology change via RA as has been suggested. While autoconfig works ok when a host comes on line since the traffic is likely to be lighter, but once a host is in full swing on a busy network, might not important RA denoting a significant network even get lost? One might argue that network traffic would drop anyway, but if there was also significant local traffic, this might not be the case. Perhaps when a signifcant net event takes place one could step up the frequency of RA to make sure that everyone took notice of it. This may seem trivial on an ethernet LAN, but RA lossage might be significant on PPP connections. Just curious... Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 11:24:29 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA02411 for ipng-dist; Thu, 22 Jul 1999 11:20:49 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02404 for ; Thu, 22 Jul 1999 11:20:45 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id LAA03541 for ipng@sunroof.eng.sun.com; Thu, 22 Jul 1999 11:19:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02382 for ; Thu, 22 Jul 1999 11:13:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA04819 for ; Thu, 22 Jul 1999 11:13:53 -0700 (PDT) Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06792 for ; Thu, 22 Jul 1999 11:13:52 -0700 (PDT) Received: from unix3.andrew.cmu.edu (UNIX3.ANDREW.CMU.EDU [128.2.15.7]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id OAA01326; Thu, 22 Jul 1999 14:13:51 -0400 (EDT) Date: Thu, 22 Jul 1999 14:13:51 -0400 (EDT) From: Justin To: ipng@sunroof.eng.sun.com Subject: Re: multi-homing vs route aggregation 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 On Wed, 21 Jul 1999, Steve Deering wrote: > Regarding the specific issue of site multihoming vs. route aggregation, > I don't think we ought to just dismiss the concerns about route > aggregation with appeals to Moore's law or Adam Smith's invisible hand. > I would prefer to not rule out a possible IPv6 future in which many > millions of sites (e.g., many households) are connected to multiple > service providers (whether for robustness or for different grades of > service at different prices or whatever), and those sites don't each > have to send a cheque for $0.00001 to every service provider in the > world to pay for the extra memory, bandwidth, and CPU cycles required > to support one more prefix in the providers' routers, in order to get > the benefits from multihoming. Perhaps route aggregation will become > less of a concern due to technological advances, but I think it is > (a) premature to count on it, and (b) clearly a very hard sell in much > of the current ISP community, for whatever reasons. (A number of vocal > members of that community have loudly proclaimed that, if IPv6 doesn't > fix the route aggregation problem, all it will do is make the routing > tables four times larger for absolutely no benefit [dismissing the > benefit of global addressing], and so we should all just wait for > something that *does* solve the route aggregation problem.) If there's no good current solution for massive amounts of multihoming, ISPs should tell Joe User, who wants to give his dog's dog collar, his TV remote, and his toaster global ipv6 addresses AND who wants multiple ISPs, to go away. Just because ipv6 has the theoretical ability to allow more devices to be connected, doesn't mean that has to be encouraged, or even allowed, until problems with it are fixed. Exactly why does a toaster need a global ip, anyway? Do all the ISPs for a multihomed site have to announce the route? Couldn't only one announce, and when the others see a withdrawl of that route, they compete (intelligently) to decide which next advertises it? I don't see this as an issue with ipv6 at all, I think it's an issue with BGP4+. Plus, a solution to this could be made to solve renumbering as well; why not have the customer use the same ips with both ISPs, then renumbering is not necessary. ISP2 can pick up the withdrawn route for ENTITY through ISP1 since it knows ENTITY is a customer. Routing updates propegate. No lost tcp connections. "But this will cause massive routing churn!" I would think even a significant increase in route churn is much more acceptable than requiring that all routers with global BGP views have 32GB of memory or some other rediculous amount when ipv6 is deployed. ...and I would hope that anyone who wants to be multihomed would ensure that their links are reliable, which would mean not many extra routing updates for failed links. Just my $.019 (not redeemable for cash) Justin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 13:10:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA02654 for ipng-dist; Thu, 22 Jul 1999 13:04:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02647 for ; Thu, 22 Jul 1999 13:04:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA20990 for ; Thu, 22 Jul 1999 13:04:28 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16529 for ; Thu, 22 Jul 1999 13:04:27 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA217214; Thu, 22 Jul 1999 21:04:24 +0100 Received: from hursley.ibm.com (lig32-226-85-171.us.lig-dial.ibm.com [32.226.85.171]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA24706; Thu, 22 Jul 1999 21:04:21 +0100 (BST) Message-ID: <37971ABE.613EB98C@hursley.ibm.com> Date: Thu, 22 Jul 1999 08:21:02 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Ted Rohling CC: ipng@sunroof.eng.sun.com Subject: Re: Time for a Review References: <001101bed371$f1b838e0$40b9adce@inst1.arg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Indeed. There is a plan to commission such a review by the IESG, since it is an IETF-wide issue. (Think of it as somewhat like the Y2K review recently published.) Hopefully this will start pretty soon. Brian Carpenter Ted Rohling wrote: > > Has anyone taken the time to develop a list of things we can do in IPv4 and > determine exactly how they are going to be done in IPv6. I know IPv6 has > lots of new stuff but what about the old stuff. IE. > > Assignment of DNS server address during autoconfiguration. > Forced selection of "gateway" router during autoconfiguration when there are > multiple routers attached to a segment. > Assignment of Node names and Domain names during autoconfiguration. > ..... and the list goes on. > > These may not be extremely interesting developmental issues but until the > ADMINISTRATIVE trivia is taken care of and people understand how things will > work, IPv6 remains a mystery and an interesting yet unnecessary opportunity > to avoid. For those of you who are implementors or developers, remember > that the fruits of your labors have to be used by someone. A simple "that > will be handled by individual implementations" is not a satisfactory answer > to those of us who will live with this in the real world. > > Hope this doesn't generate a stream of protests but during the next IETF > meeting, why doesn't someone undertake this in a committee meeting and help > us in the user community understand why this is so useful. > > Thanks for listening > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.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 Thu Jul 22 13:10:47 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA02663 for ipng-dist; Thu, 22 Jul 1999 13:05:50 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02656 for ; Thu, 22 Jul 1999 13:05:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA27159 for ; Thu, 22 Jul 1999 13:05:40 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16972 for ; Thu, 22 Jul 1999 13:05:38 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA137504 for ; Thu, 22 Jul 1999 21:05:33 +0100 Received: from hursley.ibm.com (lig32-226-85-171.us.lig-dial.ibm.com [32.226.85.171]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA23500 for ; Thu, 22 Jul 1999 21:05:28 +0100 (BST) Message-ID: <379721CA.40A0947B@hursley.ibm.com> Date: Thu, 22 Jul 1999 08:51:06 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: IPng Mailing List Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) References: <99Jul21.163603gmt-0400.15234@odin.digi-data.com> <14230.15671.239764.278370@snowy.woods.net> <99Jul21.184718gmt-0400.15234@odin.digi-data.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This thread is definitely off in the long weeds IMHO. What we (the IPNG WG of the IETF) can do is design a technology that allows ISPs to support multihoming and prefix updates without punching holes in the TLA and subTLA aggregates. It really isn't under our control whether they choose to use this, or prefer to shoot themselves in the feet by continuing to apply IPv4 practice to IPv6. Let's just design the technology here, and as itojun said we made some progress on that in Oslo. 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 Jul 22 15:09:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA02847 for ipng-dist; Thu, 22 Jul 1999 15:06:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02840 for ; Thu, 22 Jul 1999 15:05:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA14010 for ; Thu, 22 Jul 1999 15:05:58 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03087 for ; Thu, 22 Jul 1999 15:05:50 -0700 (PDT) Received: by odin.digi-data.com id <15236>; Thu, 22 Jul 1999 18:01:20 -0400 Message-Id: <99Jul22.180120gmt-0400.15236@odin.digi-data.com> Date: Thu, 22 Jul 1999 18:08:13 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter , IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation (was Re: Bad routes update)) References: <199907211837.AA16970@zed.isi.edu> <99Jul21.181857gmt-0400.15234@odin.digi-data.com> <37971ECA.790C1811@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Brian, Brian E Carpenter wrote: > > Robert, > > What is your objection to altering an IP header in tranist, as > long as the altered part is not included in any checksum? > > Brian Let me say this at the outset. I would hate to see deployment of IPv6 delayed over the Multihoming and Session Stability issues when we can get them fixed later without any adverse effects right now. My objection to altering an IP header in transit stems from what I understand the IP end-to-end model to be. It is probably more a philosophical bias on my part than anything else. I may be wrong, but I believe the end-to-end model essentially advocates that the packets will not be altered in transit. Also, I do not see any compelling need to alter packet headers in order to provide for session stability. My last message also dealt primarily with the session stability idea in [GSE+]. I still think [GSE+] does not do enough to remedy the drawbacks of [GSE]. Besides, such a radical change to the addressing infrastructure and the behaviour of routers probably are not required to solve the multihoming problem, but as I said before that was not the issue I really want to deal with. I believe that work to solve the question of transport connections surviving a renumbering event or topology change is worth the effort, hence my clumsy attempt at presenting a mechanism. Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 15:44:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA02899 for ipng-dist; Thu, 22 Jul 1999 15:40:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02892 for ; Thu, 22 Jul 1999 15:40:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA17742 for ; Thu, 22 Jul 1999 15:40:47 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21677 for ; Thu, 22 Jul 1999 16:40:42 -0600 (MDT) Received: by odin.digi-data.com id <15236>; Thu, 22 Jul 1999 18:36:25 -0400 Message-Id: <99Jul22.183625gmt-0400.15236@odin.digi-data.com> Date: Thu, 22 Jul 1999 18:43:18 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Shane Kerr , IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Shane, Shane Kerr wrote: > > Warning: I've not ready any of the literature presented in this e-mail. -------------------SNIP---------------------------- > I would suggest such a number be created by combining a unique number from > the session initiator with one from the other side. Such a number, while > not unique globally, would be unique for connections on both ends of a > session. By "unique", I mean one that is unlikely to be used again in > quite a while. Whether this should be simply an increasing integer value > or a CRC or a hash or what, I can't say. Personally I don't see any > problem with an incrementing integer, but I might be overlooking > something. An incrementing integer could be a problem. It could make it easy to highjack a session. I was just talking about a number that can be used for mapping to the IP address and can be used in place of the IP address in the Protocol Control Block. > > Is it possible to add this to a TCP connection handshake without adding an > extra packet transmission? Without looking at the RFC's in detail my > initial reaction is to say "yes". > What I am proposing does not require alteration of TCP. In fact I am not even advocating making any changes to the protocol. Also if you avoid the need to negotiate the number mutually between both parties, which I do not believe is really necessary, it is also possible to avoid an extra packet transmission except in the case of a renumbering event or topology change. > Which kind of brings us to the next question: is it possible to attain > any kind of session survival with a UDP session? Certainly the concept of > a UDP session has meaning (e.g. TFTP), but this is kept strictly at the > application level. I think it would be fairly difficult, if not > impossible, without some sort of protocol-level support (visions of NAT > dance through my head). But perhaps that's not such a big deal, as long > as it is agreed that this is a TCP-only proposition. > What I am proposing is independent of the specific transport protocol in use. It will work for both TCP and UDP. What I propose is code to perform the mapping to the IP address from the identifier used in the protocol control block and an auxiliary protocol to negotiate an update to that mapping when either peer needs to renumber or select a different interface. This combination of the mapping code and a protocol to negotiate the update I am calling an Agent. Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 16:15:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA02989 for ipng-dist; Thu, 22 Jul 1999 16:10:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02982 for ; Thu, 22 Jul 1999 16:10:36 -0700 (PDT) From: acd@woods.net Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA26606 for ; Thu, 22 Jul 1999 16:10:35 -0700 (PDT) Received: from snowy.woods.net (snowy.woods.net [209.112.190.80]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12146 for ; Thu, 22 Jul 1999 13:51:38 -0600 (MDT) Received: by snowy.woods.net id m117Osn-000AfVC (Solaris Smail-3.2.0.106 1999-Mar-31 #2); Thu, 22 Jul 1999 11:51:57 -0800 (AKDT) Message-Id: Date: Thu, 22 Jul 1999 11:51:57 -0800 (AKDT) To: jguyett@andrew.cmu.edu Subject: Re: multi-homing vs route aggregation Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Justin wrote: > If there's no good current solution for massive amounts of multihoming, > ISPs should tell Joe User, who wants to give his dog's dog collar, his TV > remote, and his toaster global ipv6 addresses AND who wants multiple > ISPs, to go away. Just because ipv6 has the theoretical ability to allow > more devices to be connected, doesn't mean that has to be encouraged, or > even allowed, until problems with it are fixed. Exactly why does a > toaster need a global ip, anyway? For the immediate-to-medium term, we're not talking about Joe User. We're talking about small-to-medium ISPs and medium-to-large corps. > Do all the ISPs for a multihomed site have to announce the route? > Couldn't only one announce, and when the others see a withdrawl of that > route, they compete (intelligently) to decide which next advertises it? I > don't see this as an issue with ipv6 at all, I think it's an issue with > BGP4+. Eeek! Eeek! No, because they aren't necessarily closely connected. Primary ISP would be advertising a /24 or /35 or whatever, and not be *also* advertising the customers addresses. There is no indication that the link has failed in the global BGP tables. At all. Unless the entire ISP fails, then the secondary ISPs could pick up the specific routes. But that would still be a major conceptual pain in the rear to coordinate or even implement. > Plus, a solution to this could be made to solve renumbering as well; why > not have the customer use the same ips with both ISPs, then renumbering is > not necessary. ISP2 can pick up the withdrawn route for ENTITY through > ISP1 since it knows ENTITY is a customer. Routing updates propegate. No > lost tcp connections. "But this will cause massive routing churn!" I > would think even a significant increase in route churn is much more > acceptable than requiring that all routers with global BGP views have 32GB > of memory or some other rediculous amount when ipv6 is deployed. ...and I > would hope that anyone who wants to be multihomed would ensure that their > links are reliable, which would mean not many extra routing updates for > failed links. Link reliability is often determined by the telco. Yes, you can yell at your telco, but that is like smashing your head into a brick wall. This is why one gets to be multihomed, for when either your telco or upstream explodes for no apparent purpose. _______________________________________________________________________ |Aaron Dewell ===> acd@woods.net | |http://www.woods.net/~acd http://www.woods.net/ | |PGP keyid 0x0D12A6B9 available from http://keys.pgp.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 Jul 22 16:15:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA03004 for ipng-dist; Thu, 22 Jul 1999 16:13:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02995 for ; Thu, 22 Jul 1999 16:12:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA27536 for ; Thu, 22 Jul 1999 16:12:57 -0700 (PDT) Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA07096 for ; Thu, 22 Jul 1999 17:12:55 -0600 (MDT) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id LAA26001; Fri, 23 Jul 1999 11:12:31 +1200 (NZST) Date: Fri, 23 Jul 1999 11:12:30 +1200 From: Joe Abley To: Robert Honore Cc: Brian E Carpenter , IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation (was Re: Bad routes update)) Message-ID: <19990723111230.A26323@patho.gen.nz> References: <199907211837.AA16970@zed.isi.edu> <99Jul21.181857gmt-0400.15234@odin.digi-data.com> <37971ECA.790C1811@hursley.ibm.com> <99Jul22.180120gmt-0400.15236@odin.digi-data.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <99Jul22.180120gmt-0400.15236@odin.digi-data.com>; from Robert Honore on Thu, Jul 22, 1999 at 06:08:13PM -0400 X-Files: the Truth is Out There Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Jul 22, 1999 at 06:08:13PM -0400, Robert Honore wrote: > I believe that work to solve the question of transport connections > surviving a renumbering event or topology change is worth the effort, > hence my clumsy attempt at presenting a mechanism. I am not trying to evangelise a particular solution, nor second-guess the forthcoming minutes from the Oslo meeting. However. :) Steve mentioned that an important requirement raised by carriers and ISPs in the initial design of IPv6 was that the routing complexity in the core should be minimised. However, this was some time ago. Since then, I think several important things have happened: o Providers have found other ways to reduce complexity in the core, using techniques like building out ATM switched cores to concentrate the routing load in fewer places (near the edge), and MPLS. o Routers have become capable of holding fantastic-sized BGP tables in the default-free zone, and performing hardware-assisted lookups on these huge tables at wire-speed. o The number of organisations multi-homing has increased, and the use of BGP has also increased. People are now using BGP to do all kinds of weird and wonderful things, and it will be difficult to characterise them all and build them into a brand new multi-homing scheme. o Perhaps most importantly, the Internet backbone is not the wild west it once was. The last point is important. Some of the largest IP networks on the planet (and ones on which the stability of many visible service now depend) have sprouted design and operational procedures that weren't in evidence seven years ago. These are clearly not as elaborate as the various Books of Telco that describe tried and tested procedures in the switched voice network, but they exist nonetheless. Procedures, and engineers who do things based on recipes rather than first principles, lead to inertia. My question, then is this: Do the original requirements of ISPs still make sense today? If the largest backbone networks were canvassed again today, would they have the same priorities in a new Internet architecture? CLEAR is small enough (and has a sufficiently low number of connection points to other networks) to accommodate any consensus approach to multi-homing, route aggregation and session stability, at least as far as the carrier requirements are concerned. I wonder whether larger ISPs will find a radical change in operational procedure so easy to swallow. Joe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 16:18:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA03034 for ipng-dist; Thu, 22 Jul 1999 16:16:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03027 for ; Thu, 22 Jul 1999 16:16:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA28304 for ; Thu, 22 Jul 1999 16:16:26 -0700 (PDT) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA08971 for ; Thu, 22 Jul 1999 17:16:25 -0600 (MDT) Received: (qmail 6358 invoked from network); 22 Jul 1999 23:16:24 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 22 Jul 1999 23:16:24 -0000 Received: from localhost by ops.arin.net (8.9.0/8.9.0) with SMTP id TAA27428; Thu, 22 Jul 1999 19:16:24 -0400 (EDT) Date: Thu, 22 Jul 1999 19:16:24 -0400 (EDT) From: Ramin Sepehr Rad Reply-To: Ramin Sepehr Rad To: Brian E Carpenter cc: IPng Mailing List Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) In-Reply-To: <379721CA.40A0947B@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, 22 Jul 1999, Brian E Carpenter wrote: > What we (the IPNG WG of the IETF) can do is design a technology > that allows ISPs to support multihoming and prefix updates > without punching holes in the TLA and subTLA aggregates. I don't exactly know what you mean by "prefix updates", but it sure sounds like an idea that I have been thinking about to solve the multi-homing problem. The idea is that each multi-home site decides on a primary prefix and each host on the site has only one IP address from that block. However, the other routers which are connected to other upstream provider use the secondary prefix and they would do a prefix translation if necessary. (Similar to NAT, yes I know I just announced my death wish.) A drawing might help: ISPA (2001:ABC::/32) ISPB (2001:DEF::/32) | | | | R1 R2 | | ____|_________________________________|_________ 2001:ABC:1000::/35 Say router 1 (R1) is the primary router (i.e. 2001:ABC:1000::/35 is the primary prefix). Then R2 has to act as the secondary and do prefix translation from 2001:ABC:1000::/35 to say 2001:DEF:F000::/35. This way, a host doesn't need multiple IP addresses so we don't have to worry about connection scalability and session stability. However, we do have to worry about the problems that NAT folks are facing. But not all of them, since prefix translation will be an isomorphic (one-to-one) translation, we don't have to worry about things such as, DNS caching, etc. -ramin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 16:35:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA03083 for ipng-dist; Thu, 22 Jul 1999 16:32:12 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03076 for ; Thu, 22 Jul 1999 16:32:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA01012 for ; Thu, 22 Jul 1999 16:32:01 -0700 (PDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA17059 for ; Thu, 22 Jul 1999 17:32:00 -0600 (MDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA10452; Thu, 22 Jul 1999 16:31:55 -0700 (PDT) From: Bill Manning Message-Id: <199907222331.QAA10452@zephyr.isi.edu> Subject: Re: Session Stability (was multi-homing vs route aggregation) To: robert@digi-data.com Date: Thu, 22 Jul 1999 16:31:54 -0700 (PDT) Cc: kerr@arin.net (Shane Kerr), IPng@sunroof.eng.sun.com (IPng Mailing List) In-Reply-To: <99Jul22.183625gmt-0400.15236@odin.digi-data.com> from "Robert Honore" at Jul 22, 1999 06:43:18 PM X-Mailer: ELM [version 2.5 PL0] 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 would suggest such a number be created by combining a unique number from > > the session initiator with one from the other side. Such a number, while > > not unique globally, would be unique for connections on both ends of a > > session. By "unique", I mean one that is unlikely to be used again in > > quite a while. Whether this should be simply an increasing integer value > > or a CRC or a hash or what, I can't say. Personally I don't see any > > problem with an incrementing integer, but I might be overlooking > > something. > > An incrementing integer could be a problem. It could make it easy to highjack a > session. I was just talking about a number that can be used for mapping to the > IP address and can be used in place of the IP address in the Protocol Control > Block. > This has been coded and tested already. Christian Hutiema had a group of UCLA students do this about three years ago. Based on a long-expired ID. There is code around someplace. > > Which kind of brings us to the next question: is it possible to attain > > any kind of session survival with a UDP session? Certainly the concept of > > a UDP session has meaning (e.g. TFTP), but this is kept strictly at the > > application level. I think it would be fairly difficult, if not > > impossible, without some sort of protocol-level support (visions of NAT > > dance through my head). But perhaps that's not such a big deal, as long > > as it is agreed that this is a TCP-only proposition. There are a couple of ways to do this, but they require some extra cruft on the side (adding limited state). Some code exists here as well. > > What I am proposing is independent of the specific transport protocol in use. > It will work for both TCP and UDP. What I propose is code to perform the > mapping to the IP address from the identifier used in the protocol control block > and an auxiliary protocol to negotiate an update to that mapping when either > peer needs to renumber or select a different interface. This combination of the > mapping code and a protocol to negotiate the update I am calling an Agent. Don;t think you need to do that much if designed properly. It really would be worth your time to review the e2e and bigi list archives. Most of this is old ground. > > Yours sincerely, > Robert Honore. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- --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 Thu Jul 22 17:07:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA03127 for ipng-dist; Thu, 22 Jul 1999 17:04:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03120 for ; Thu, 22 Jul 1999 17:04:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA07826 for ; Thu, 22 Jul 1999 17:04:02 -0700 (PDT) Received: from ns.uk.newbridge.com (ns.uk.newbridge.com [194.223.115.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA10296 for ; Thu, 22 Jul 1999 17:04:01 -0700 (PDT) Received: (from smtpd@localhost) by ns.uk.newbridge.com (8.6.12/8.6.12) id BAA07080 for ipng@sunroof.eng.sun.com; Fri, 23 Jul 1999 01:04:00 +0100 Received: from uk-gw1.uk.newbridge.com(194.223.115.70), claiming to be "newport-mh1.uk.newbridge.com" via SMTP by ns.uk.newbridge.com, id smtpdAAAa07075; Fri Jul 23 01:03:54 1999 Received: from emamail01.uk.newbridge.com by newport-mh1.uk.newbridge.com with ESMTP; Fri, 23 Jul 1999 01:03:52 +0100 Received: from w-BCROSBY ([138.120.24.17]) by emamail01.uk.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA4620; Fri, 23 Jul 1999 01:02:27 +0100 Message-Id: <4.2.0.58.19990723003444.009ac5b0@emamail01.uk.newbridge.com> X-Sender: bcrosby@emamail01.uk.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 23 Jul 1999 00:43:26 +0100 To: acd@woods.net From: "Ben CROSBY" Subject: Re: multi-homing vs route aggregation Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 20:51 22/07/99 , acd@woods.net wrote: >For the immediate-to-medium term, we're not talking about Joe User. We're >talking about small-to-medium ISPs and medium-to-large corps. I believe this is flawed. We are discussing immediate to medium term. What about deployment of xDSL technologies ? Permanant IP(v6) links to homes across the world, with services provided by a whole raft of different value-added service providers. I can see a situation just around the corner, where I want to be able to connect to my corporate lan on the one hand, and my video provider on the other hand, maybe even to a VPN between some friends so we can play video games. That gives me a very big reason to have my xDSL connected (network or standalone) at home multi-homed under v6. This is just one scenario, where end users can be multi homed, and it isn't for resilience. We really don't want to break the Route Aggregation. My 0.02c. Ben. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 17:12:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA03161 for ipng-dist; Thu, 22 Jul 1999 17:11:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03154 for ; Thu, 22 Jul 1999 17:11:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA06327 for ; Thu, 22 Jul 1999 17:11:03 -0700 (PDT) Received: from ns.uk.newbridge.com (ns.uk.newbridge.com [194.223.115.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA12111 for ; Thu, 22 Jul 1999 17:11:01 -0700 (PDT) Received: (from smtpd@localhost) by ns.uk.newbridge.com (8.6.12/8.6.12) id BAA07094 for IPng@sunroof.eng.sun.com; Fri, 23 Jul 1999 01:11:00 +0100 Received: from uk-gw1.uk.newbridge.com(194.223.115.70), claiming to be "newport-mh1.uk.newbridge.com" via SMTP by ns.uk.newbridge.com, id smtpdAAAa07088; Fri Jul 23 01:10:58 1999 Received: from emamail01.uk.newbridge.com by newport-mh1.uk.newbridge.com with ESMTP; Fri, 23 Jul 1999 01:10:56 +0100 Received: from w-BCROSBY ([138.120.24.17]) by emamail01.uk.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA4734; Fri, 23 Jul 1999 01:09:31 +0100 Message-Id: <4.2.0.58.19990723004506.00959f00@emamail01.uk.newbridge.com> X-Sender: bcrosby@emamail01.uk.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 23 Jul 1999 00:50:28 +0100 To: robert@digi-data.com From: "Ben CROSBY" Subject: Re: Session Stability (was multi-homing vs route aggregation (was Re: Bad routes update)) Cc: Brian E Carpenter , IPng Mailing List In-Reply-To: <99Jul22.180120gmt-0400.15236@odin.digi-data.com> References: <199907211837.AA16970@zed.isi.edu> <99Jul21.181857gmt-0400.15234@odin.digi-data.com> <37971ECA.790C1811@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 23:08 22/07/99 , Robert Honore wrote: >Let me say this at the outset. I would hate to see deployment of IPv6 delayed >over the Multihoming and Session Stability issues when we can get them fixed >later without any adverse effects right now. I'd echo these comments. We appear to be trying to get people to take up IPv6 and part of the reason why take up has been so slow is because of continued tweaking. However, this is a major point. It is a pity not more notice was paid a few years ago when we first discussed it in Washington. >My objection to altering an IP header in transit stems from what I understand >the IP end-to-end model to be. It is probably more a philosophical bias on my >part than anything else. I may be wrong, but I believe the end-to-end model >essentially advocates that the packets will not be altered in >transit. Also, I >do not see any compelling need to alter packet headers in order to >provide for >session stability. Not necessarily philosophical. We learnt from v4 that applications exist which need to pass IPaddresses within the datagram, rightly or wrongly. This is the reason why NAT breaks some applications. Do we really want to deploy a protocol which has the same flaws from day one ? >I believe that work to solve the question of transport connections surviving a >renumbering event or topology change is worth the effort, hence my clumsy >attempt at presenting a mechanism. It has the potential to be one of the most useful features of the protocol. Ben. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 17:30:00 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA03217 for ipng-dist; Thu, 22 Jul 1999 17:24:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03210 for ; Thu, 22 Jul 1999 17:24:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA08467 for ; Thu, 22 Jul 1999 17:24:37 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15468 for ; Thu, 22 Jul 1999 14:04:51 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA81898; Thu, 22 Jul 1999 21:04:48 +0100 Received: from hursley.ibm.com (lig32-226-85-171.us.lig-dial.ibm.com [32.226.85.171]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA23952; Thu, 22 Jul 1999 21:04:35 +0100 (BST) Message-ID: <37971ECA.790C1811@hursley.ibm.com> Date: Thu, 22 Jul 1999 08:38:18 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: robert@digi-data.com CC: IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation (was Re: Bad routes update)) References: <199907211837.AA16970@zed.isi.edu> <99Jul21.181857gmt-0400.15234@odin.digi-data.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, What is your objection to altering an IP header in tranist, as long as the altered part is not included in any checksum? 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 Jul 22 17:37:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA03248 for ipng-dist; Thu, 22 Jul 1999 17:35:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03241 for ; Thu, 22 Jul 1999 17:35:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA10479 for ; Thu, 22 Jul 1999 17:35:24 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15332 for ; Thu, 22 Jul 1999 14:04:22 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA272238; Thu, 22 Jul 1999 21:04:19 +0100 Received: from hursley.ibm.com (lig32-226-85-171.us.lig-dial.ibm.com [32.226.85.171]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA23932; Thu, 22 Jul 1999 21:04:16 +0100 (BST) Message-ID: <37971A2A.1107E7D@hursley.ibm.com> Date: Thu, 22 Jul 1999 08:18:34 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Matt Crawford CC: ipng@sunroof.eng.sun.com Subject: Re: Dialup issues References: <199907212045.PAA03791@gungnir.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Also, we have a large supply of /64s so this really shouldn't be a problem. Brian Matt Crawford wrote: > > > Are there any documents describing how to assign addresses to dialup > > lines? > > > > Assigning /64 to dialup lines seems like overkill, yet people want to > > run some sort of network at home with all the machines having global > > addresses. > > You can give a single address with PPP. The next step from there is > a /64. And it makes sense, because isn't this exactly one sort of > customer for whom autoconfiguration is very important? > > It would make sense to leave the endpoints of the link itself without > global addresses and allot the /64 to the subnet behind the dialup > peer. > Matt > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.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 Thu Jul 22 17:38:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA03257 for ipng-dist; Thu, 22 Jul 1999 17:36:48 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03250 for ; Thu, 22 Jul 1999 17:36:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA10653 for ; Thu, 22 Jul 1999 17:36:37 -0700 (PDT) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA24135 for ; Thu, 22 Jul 1999 14:30:36 -0600 (MDT) Received: (qmail 8181 invoked from network); 22 Jul 1999 20:30:35 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 22 Jul 1999 20:30:35 -0000 Received: from localhost by ops.arin.net (8.9.0/8.9.0) with SMTP id QAA18041; Thu, 22 Jul 1999 16:30:35 -0400 (EDT) Date: Thu, 22 Jul 1999 16:30:34 -0400 (EDT) From: Shane Kerr Reply-To: Shane Kerr To: Robert Honore cc: IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation) In-Reply-To: <99Jul21.181857gmt-0400.15234@odin.digi-data.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Warning: I've not ready any of the literature presented in this e-mail. On Wed, 21 Jul 1999, Robert Honore wrote: > Here is the scheme. Perhaps we can use either a random number or a > number otherwise generated when initialising the connection. This number > will have the same number of bits as an IP address. We can then use > that number in the Protol Control Block. That number will serve as a > lookup index within the host to some association with the peer's real IP > address. That IP address will then be what is placed in the IP header > as the destination address for all packets that will be transmitted > until the peer node needs to renumber or choose a different interface or > address. I would suggest such a number be created by combining a unique number from the session initiator with one from the other side. Such a number, while not unique globally, would be unique for connections on both ends of a session. By "unique", I mean one that is unlikely to be used again in quite a while. Whether this should be simply an increasing integer value or a CRC or a hash or what, I can't say. Personally I don't see any problem with an incrementing integer, but I might be overlooking something. Is it possible to add this to a TCP connection handshake without adding an extra packet transmission? Without looking at the RFC's in detail my initial reaction is to say "yes". Which kind of brings us to the next question: is it possible to attain any kind of session survival with a UDP session? Certainly the concept of a UDP session has meaning (e.g. TFTP), but this is kept strictly at the application level. I think it would be fairly difficult, if not impossible, without some sort of protocol-level support (visions of NAT dance through my head). But perhaps that's not such a big deal, as long as it is agreed that this is a TCP-only proposition. -- Shane Kerr Software Engineer American Registry for Internet Numbers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 17:48:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA03339 for ipng-dist; Thu, 22 Jul 1999 17:46:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03332 for ; Thu, 22 Jul 1999 17:46:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA12296 for ; Thu, 22 Jul 1999 17:46:09 -0700 (PDT) Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA23582 for ; Thu, 22 Jul 1999 18:46:08 -0600 (MDT) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id TAA15143; Thu, 22 Jul 1999 19:45:48 -0500 (CDT) Received: from dal-tx43-17.ix.netcom.com(207.221.94.145) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma015032; Thu Jul 22 19:45:18 1999 Message-ID: <37974CA3.AC9636B9@ix.netcom.com> Date: Thu, 22 Jul 1999 17:53:57 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Ben CROSBY CC: robert@digi-data.com, Brian E Carpenter , IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation (was Re: Bad routes update)) References: <199907211837.AA16970@zed.isi.edu> <99Jul21.181857gmt-0400.15234@odin.digi-data.com> <37971ECA.790C1811@hursley.ibm.com> <4.2.0.58.19990723004506.00959f00@emamail01.uk.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ben and all, Couldn't agree with you more on this point Ben.... Ben CROSBY wrote: > At 23:08 22/07/99 , Robert Honore wrote: > > >Let me say this at the outset. I would hate to see deployment of IPv6 delayed > >over the Multihoming and Session Stability issues when we can get them fixed > >later without any adverse effects right now. > > I'd echo these comments. We appear to be trying to get people to take up IPv6 > and part of the reason why take up has been so slow is because of continued > tweaking. However, this is a major point. It is a pity not more notice was > paid a > few years ago when we first discussed it in Washington. > > >My objection to altering an IP header in transit stems from what I understand > >the IP end-to-end model to be. It is probably more a philosophical bias on my > >part than anything else. I may be wrong, but I believe the end-to-end model > >essentially advocates that the packets will not be altered in > >transit. Also, I > >do not see any compelling need to alter packet headers in order to > >provide for > >session stability. > > Not necessarily philosophical. We learnt from v4 that applications exist > which need > to pass IPaddresses within the datagram, rightly or wrongly. This is the > reason why > NAT breaks some applications. Do we really want to deploy a protocol which > has the > same flaws from day one ? > > >I believe that work to solve the question of transport connections surviving a > >renumbering event or topology change is worth the effort, hence my clumsy > >attempt at presenting a mechanism. > > It has the potential to be one of the most useful features of the protocol. > > Ben. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 18:59:45 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA03497 for ipng-dist; Thu, 22 Jul 1999 18:56:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03489 for ; Thu, 22 Jul 1999 18:56:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA19924 for ; Thu, 22 Jul 1999 18:56:21 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA24339 for ; Thu, 22 Jul 1999 19:56:19 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id CAA261416 for ; Fri, 23 Jul 1999 02:56:15 +0100 Received: from hursley.ibm.com (lig32-226-130-159.us.lig-dial.ibm.com [32.226.130.159]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id CAA20174 for ; Fri, 23 Jul 1999 02:56:09 +0100 (BST) Message-ID: <3797CAA1.6107F3B7@hursley.ibm.com> Date: Thu, 22 Jul 1999 20:51:29 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation (was Re: Bad routes update)) References: <199907211837.AA16970@zed.isi.edu> <99Jul21.181857gmt-0400.15234@odin.digi-data.com> <37971ECA.790C1811@hursley.ibm.com> <99Jul22.180120gmt-0400.15236@odin.digi-data.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, Thanks. I asked the question because this was part of the discussion at the recent IAB workshop, and one of our recommendations was to study further the concept of separating endpoint names from endpoint locators. Your comments are relevant. However another of the recommndations was to actively pursue IPv6 deployment based on TLA addressing, and not hold this up due to such studies, and I'd be glad to see that happen (i.e. let's figure out simple TLA-based multihoming first). Brian Robert Honore wrote: > > Dear Brian, > > Brian E Carpenter wrote: > > > > Robert, > > > > What is your objection to altering an IP header in tranist, as > > long as the altered part is not included in any checksum? > > > > Brian > > Let me say this at the outset. I would hate to see deployment of IPv6 delayed > over the Multihoming and Session Stability issues when we can get them fixed > later without any adverse effects right now. > > My objection to altering an IP header in transit stems from what I understand > the IP end-to-end model to be. It is probably more a philosophical bias on my > part than anything else. I may be wrong, but I believe the end-to-end model > essentially advocates that the packets will not be altered in transit. Also, I > do not see any compelling need to alter packet headers in order to provide for > session stability. > > My last message also dealt primarily with the session stability idea in [GSE+]. > I still think [GSE+] does not do enough to remedy the drawbacks of [GSE]. > Besides, such a radical change to the addressing infrastructure and the > behaviour of routers probably are not required to solve the multihoming problem, > but as I said before that was not the issue I really want to deal with. > > I believe that work to solve the question of transport connections surviving a > renumbering event or topology change is worth the effort, hence my clumsy > attempt at presenting a mechanism. > > Yours sincerely, > Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 18:59:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA03479 for ipng-dist; Thu, 22 Jul 1999 18:56:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03472 for ; Thu, 22 Jul 1999 18:56:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA19906 for ; Thu, 22 Jul 1999 18:56:07 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA24279 for ; Thu, 22 Jul 1999 19:56:06 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id CAA261412 for ; Fri, 23 Jul 1999 02:56:01 +0100 Received: from hursley.ibm.com (lig32-226-130-159.us.lig-dial.ibm.com [32.226.130.159]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id CAA23480 for ; Fri, 23 Jul 1999 02:55:54 +0100 (BST) Message-ID: <3797C81E.678E773A@hursley.ibm.com> Date: Thu, 22 Jul 1999 20:40:46 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: multi-homing vs route aggregation References: <4.2.0.58.19990723003444.009ac5b0@emamail01.uk.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't understand this conversation at all. The whole point is that we don't even think about advertising anything more specific than a [sub]TLA prefix outside the ISP that owns the given [sub]TLA. Longer prefixes just never get out, and multihomed sites have multiple prefixes. If my house has two ISPs, it has two /64s perhaps, but they never escape from either ISP. In fact they probably never escape the two ISP's nearest wiring closets. Eliminate IPv4 thinking please! Brian Ben CROSBY wrote: > > At 20:51 22/07/99 , acd@woods.net wrote: > > >For the immediate-to-medium term, we're not talking about Joe User. We're > >talking about small-to-medium ISPs and medium-to-large corps. > > I believe this is flawed. We are discussing immediate to medium term. What > about deployment of xDSL technologies ? Permanant IP(v6) links to homes > across the world, with services provided by a whole raft of different > value-added > service providers. I can see a situation just around the corner, where I > want to > be able to connect to my corporate lan on the one hand, and my video provider > on the other hand, maybe even to a VPN between some friends so we can play > video games. That gives me a very big reason to have my xDSL connected > (network or standalone) at home multi-homed under v6. > > This is just one scenario, where end users can be multi homed, and it isn't for > resilience. > > We really don't want to break the Route Aggregation. > > My 0.02c. > > Ben. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.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 Thu Jul 22 18:59:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA03496 for ipng-dist; Thu, 22 Jul 1999 18:56:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03481 for ; Thu, 22 Jul 1999 18:56:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA19792 for ; Thu, 22 Jul 1999 18:56:16 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06789 for ; Thu, 22 Jul 1999 18:56:15 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id CAA261414; Fri, 23 Jul 1999 02:56:09 +0100 Received: from hursley.ibm.com (lig32-226-130-159.us.lig-dial.ibm.com [32.226.130.159]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id CAA24774; Fri, 23 Jul 1999 02:56:01 +0100 (BST) Message-ID: <3797C8D5.39D999F6@hursley.ibm.com> Date: Thu, 22 Jul 1999 20:43:49 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Ramin Sepehr Rad CC: IPng Mailing List Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ramin, You have essentially re-invented GSE which proposed on the fly prefix translation (except that the prefix was known as routing goop). The current plan is simpler: if the site has N prefixes, every host on the site has N IP addresses. This works without any need to rewrite prefixes. Brian Ramin Sepehr Rad wrote: > > On Thu, 22 Jul 1999, Brian E Carpenter wrote: > > > What we (the IPNG WG of the IETF) can do is design a technology > > that allows ISPs to support multihoming and prefix updates > > without punching holes in the TLA and subTLA aggregates. > > I don't exactly know what you mean by "prefix updates", but it sure sounds > like an idea that I have been thinking about to solve the multi-homing > problem. > > The idea is that each multi-home site decides on a primary prefix and each > host on the site has only one IP address from that block. However, the other > routers which are connected to other upstream provider use the secondary > prefix and they would do a prefix translation if necessary. (Similar to NAT, > yes I know I just announced my death wish.) > > A drawing might help: > > ISPA (2001:ABC::/32) ISPB (2001:DEF::/32) > | | > | | > R1 R2 > | | > ____|_________________________________|_________ > 2001:ABC:1000::/35 > > Say router 1 (R1) is the primary router (i.e. 2001:ABC:1000::/35 is the > primary prefix). Then R2 has to act as the secondary and do prefix translation > from 2001:ABC:1000::/35 to say 2001:DEF:F000::/35. > > This way, a host doesn't need multiple IP addresses so we don't have to worry > about connection scalability and session stability. > > However, we do have to worry about the problems that NAT folks are facing. > But not all of them, since prefix translation will be an isomorphic > (one-to-one) translation, we don't have to worry about things such as, DNS > caching, etc. > > -ramin > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.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 Jul 23 04:05:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA04147 for ipng-dist; Fri, 23 Jul 1999 04:03:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04140 for ; Fri, 23 Jul 1999 04:03:03 -0700 (PDT) From: george.tsirtsis@bt.com Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA20751 for ; Fri, 23 Jul 1999 04:03:02 -0700 (PDT) Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15270 for ; Fri, 23 Jul 1999 04:03:02 -0700 (PDT) Received: from cbtlipnt01.btlabs.bt.co.uk by arthur (local) with ESMTP; Fri, 23 Jul 1999 12:02:34 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Jul 1999 12:02:33 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2F4E601@mbtlipnt02.btlabs.bt.co.uk> To: ipng@sunroof.eng.sun.com Subject: RE: multi-homing vs route aggregation Date: Fri, 23 Jul 1999 12:02:27 +0100 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The specific example of Multihomed Home Networks (that Ben described) is a very interesting one and provides a variation to the general multihoming problem I believe. I say that because the 'most' common problem that ISPs try to solve with xDSL and home networks is concurrent connectivity to multiple ISPs/networks over the same xDSL line. The interesting thing here is that 'typically' (but obviously not always) one connection will be a 'general use ISP' and the other connection some kind of 'corporate network'. This is only required because 'typically' the corporate network is behind a firewall and you can not access it through a normal ISP. So, in this case multihoming is 'easier'!: End points inside the corporate are reachable through the corporate connection. All other connectivity should go through the normal ISP. ->The bottom line is that multihoming is not ONLY about resiliance but also about connectivity. ->The good news is that IPv6 is very good in the above scenario since the main problem here is to recognise which destinations are inside the corporate network. In IPv4 this is not easy at all but in IPv6 we have good mechanisms (site local addresses + higherarchical TLA/NLAs etc). Regards George > -----Original Message----- > From: Brian E Carpenter [SMTP:brian@hursley.ibm.com] > Sent: Friday, July 23, 1999 2:41 AM > To: ipng@sunroof.eng.sun.com > Subject: Re: multi-homing vs route aggregation > > I don't understand this conversation at all. > > The whole point is that we don't even think about advertising > anything more specific than a [sub]TLA prefix outside the ISP > that owns the given [sub]TLA. Longer prefixes just never get > out, and multihomed sites have multiple prefixes. If my house > has two ISPs, it has two /64s perhaps, but they never escape from > either ISP. In fact they probably never escape the two ISP's > nearest wiring closets. > > Eliminate IPv4 thinking please! > > Brian > > Ben CROSBY wrote: > > > > At 20:51 22/07/99 , acd@woods.net wrote: > > > > >For the immediate-to-medium term, we're not talking about Joe User. > We're > > >talking about small-to-medium ISPs and medium-to-large corps. > > > > I believe this is flawed. We are discussing immediate to medium term. > What > > about deployment of xDSL technologies ? Permanant IP(v6) links to homes > > across the world, with services provided by a whole raft of different > > value-added > > service providers. I can see a situation just around the corner, where I > > want to > > be able to connect to my corporate lan on the one hand, and my video > provider > > on the other hand, maybe even to a VPN between some friends so we can > play > > video games. That gives me a very big reason to have my xDSL connected > > (network or standalone) at home multi-homed under v6. > > > > This is just one scenario, where end users can be multi homed, and it > isn't for > > resilience. > > > > We really don't want to break the Route Aggregation. > > > > My 0.02c. > > > > Ben. > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 (IAB Chair) > Program Director, Internet Standards & Technology, IBM Internet Div > On assignment for IBM at http://www.iCAIR.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 Fri Jul 23 04:18:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA04166 for ipng-dist; Fri, 23 Jul 1999 04:14:55 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04159 for ; Fri, 23 Jul 1999 04:14:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA23461 for ; Fri, 23 Jul 1999 04:14:44 -0700 (PDT) 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 FAA13047 for ; Fri, 23 Jul 1999 05:14:43 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27733; Fri, 23 Jul 1999 07:14:39 -0400 (EDT) Message-Id: <199907231114.HAA27733@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-hbh-ext-csi-01.txt Date: Fri, 23 Jul 1999 07:14:39 -0400 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 : Connection/Link Status Investigation (CSI) IPv6 Hop-by-Hop option and ICMPv6 messages Extension Author(s) : H. Kitamura Filename : draft-ietf-ipngwg-hbh-ext-csi-01.txt Pages : 31 Date : 22-Jul-99 This document proposes a new mechanism whereby status information is collected for nodes along both the outgoing and incoming paths. This mechanism is called 'Connection/Link Status Investigation (CSI)'. In order to realize the CSI mechanism, one new IPv6 Hop-by-Hop option and three new ICMPv6 messages are proposed as extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-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-hbh-ext-csi-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-hbh-ext-csi-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: <19990722073957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-hbh-ext-csi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990722073957.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 Jul 23 07:43:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA04412 for ipng-dist; Fri, 23 Jul 1999 07:40:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04405 for ; Fri, 23 Jul 1999 07:40:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA27382 for ; Fri, 23 Jul 1999 07:40:07 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14342 for ; Fri, 23 Jul 1999 08:40:06 -0600 (MDT) Received: from [171.68.181.242] (sj-dial-4-113.cisco.com [171.68.181.242]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA12422; Fri, 23 Jul 1999 07:39:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19990722112302.C29345@theory.cs.uni-bonn.de> References: <19990722112302.C29345@theory.cs.uni-bonn.de> Date: Fri, 23 Jul 1999 07:39:03 -0700 To: Ignatios Souvatzis From: Steve Deering Subject: Re: Dialup issues Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:23 AM +0200 7/22/99, Ignatios Souvatzis wrote: >On Wed, Jul 21, 1999 at 11:34:57PM -0700, Steve Deering wrote: > > > > Yes. Most of the unicast address space has been specified to have a > > 64-bit interface ID field, but not all of it. IPv6 implementations > > ought to be able to handle prefixes of any length. > >Most of? I thought that, err... 1/8 were special addresses including >multidcast, 1/8 were global aggregatable addresses with the /64 property, >and all others reserved for future use? Page 7 of the IPv6 Addressing Architecture (RFC 2373) says: (2) The format prefixes 001 through 111, except for Multicast Addresses (1111 1111), are all required to have to have 64-bit interface identifiers in EUI-64 format. See section 2.5.1 for definitions. This covers almost all of the unassigned part of the address space. The only parts that do not fall under this rule are the multicast addresses (prefix 11111111) and the one-eighth of the space that has prefix 000 (some of which is assigned for embeddings of other address spaces, e.g., IPv4, NSAP, IPX). 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 Jul 23 07:52:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA04431 for ipng-dist; Fri, 23 Jul 1999 07:50:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04423 for ; Fri, 23 Jul 1999 07:50:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA28225 for ; Fri, 23 Jul 1999 07:50:11 -0700 (PDT) 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 IAA18852 for ; Fri, 23 Jul 1999 08:50:10 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA19626 for ; Fri, 23 Jul 1999 09:50:09 -0500 (CDT) Message-Id: <199907231450.JAA19626@gungnir.fnal.gov> To: IPng Mailing List From: "Matt Crawford" Subject: Re: Session Stability (was multi-homing vs route aggregation (was Re: Bad routes update)) In-reply-to: Your message of Thu, 22 Jul 1999 18:08:13 EDT. <99Jul22.180120gmt-0400.15236@odin.digi-data.com> Date: Fri, 23 Jul 1999 09:50:09 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Robert, > > > > What is your objection to altering an IP header in tranist, as > > long as the altered part is not included in any checksum? > > > > Brian > ... > My objection to altering an IP header in transit stems from what I > understand the IP end-to-end model to be. It is probably more a > philosophical bias on my part than anything else. I may be wrong, but I > believe the end-to-end model essentially advocates that the packets will not > be altered in transit. Also, I do not see any compelling need to alter > packet headers in order to provide for session stability. You fell into a trap, although Brian's so un-devious he probably didn't set it intentionally. There are several IPv4 header fields that are always modified en route, and several more that are sometimes modified. Given that, where do you draw the line between what MAY and what MUST NOT be modified, and how do you justify it? Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 07:57:11 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA04449 for ipng-dist; Fri, 23 Jul 1999 07:54:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04442 for ; Fri, 23 Jul 1999 07:54:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA14223 for ; Fri, 23 Jul 1999 07:54:38 -0700 (PDT) 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 HAA14227 for ; Fri, 23 Jul 1999 07:54:37 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA19667 for ; Fri, 23 Jul 1999 09:54:36 -0500 (CDT) Message-Id: <199907231454.JAA19667@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: multi-homing vs route aggregation In-reply-to: Your message of Thu, 22 Jul 1999 20:40:46 CDT. <3797C81E.678E773A@hursley.ibm.com> Date: Fri, 23 Jul 1999 09:54:36 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The whole point is that we don't even think about advertising > anything more specific than a [sub]TLA prefix outside the ISP > that owns the given [sub]TLA. Longer prefixes just never get > out, ... > > Brian A small correction: they never get out globally, but any routing peers are free to exchange any information they wish. I may set up a private link or tunnel between (sites or providers) FOO and BAR and exchange some routing information without regard for TLA or other bit-boundaries. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 08:23:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA04492 for ipng-dist; Fri, 23 Jul 1999 08:21:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04485 for ; Fri, 23 Jul 1999 08:20:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA10093 for ; Fri, 23 Jul 1999 08:20:50 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22804 for ; Fri, 23 Jul 1999 08:20:51 -0700 (PDT) Received: from [171.68.181.242] (sj-dial-4-113.cisco.com [171.68.181.242]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA14320; Fri, 23 Jul 1999 08:20:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <199907231450.JAA19626@gungnir.fnal.gov> References: <199907231450.JAA19626@gungnir.fnal.gov> Date: Fri, 23 Jul 1999 08:20:10 -0700 To: "Matt Crawford" From: Steve Deering Subject: Re: Session Stability (was multi-homing vs route aggregation (was Re: Bad routes update)) Cc: IPng Mailing List Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:50 AM -0500 7/23/99, Matt Crawford wrote: >Given that, where do you draw the line between what MAY and what MUST >NOT be modified, and how do you justify it? The line is drawn between those fields that the IP spec specifically identifies as modifiable en route, and those it does not. If the spec does not say a field is modifiable, then the routers cannot assume they can safely change it because there may be upper-layer dependencies on that field remaining unchanged (unknown and unknowable to the routers). Nor can they add fields or delete fields (e.g., options or extension headers), for the same reason. Of course, the routers can make any changes they want to an IP header, including compressing it, encapsulating it, shredding it, or translating it into Swahili, as long as those changes are undone before delivery to the destination(s) (and before reaching any intermediate devices like firewalls that might also depend on the constant fields of the header remaining constant). 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 Jul 23 09:00:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA04525 for ipng-dist; Fri, 23 Jul 1999 08:56:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04518 for ; Fri, 23 Jul 1999 08:56:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA21946 for ; Fri, 23 Jul 1999 08:56:42 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17512 for ; Fri, 23 Jul 1999 09:56:40 -0600 (MDT) Received: by odin.digi-data.com id <15233>; Fri, 23 Jul 1999 11:52:19 -0400 Message-Id: <99Jul23.115219gmt-0400.15233@odin.digi-data.com> Date: Fri, 23 Jul 1999 11:59:18 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Matt Crawford , IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation (was Re: Bad routes update)) References: <199907231450.JAA19626@gungnir.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Matt, I believe Steve Deering covers the answer perfectly: > >Given that, where do you draw the line between what MAY and what MUST > >NOT be modified, and how do you justify it? > > The line is drawn between those fields that the IP spec specifically > identifies as modifiable en route, and those it does not. If the spec > does not say a field is modifiable, then the routers cannot assume they > can safely change it because there may be upper-layer dependencies on > that field remaining unchanged (unknown and unknowable to the routers). > Nor can they add fields or delete fields (e.g., options or extension > headers), for the same reason. > > Of course, the routers can make any changes they want to an IP header, > including compressing it, encapsulating it, shredding it, or translating > it into Swahili, as long as those changes are undone before delivery to > the destination(s) (and before reaching any intermediate devices like > firewalls that might also depend on the constant fields of the header > remaining constant). > > Steve I have nothing I can add to this. You have to give me very strong justification if you advocate modifying IP headers outside of the protocol specification. Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 20:04:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA05455 for ipng-dist; Fri, 23 Jul 1999 20:01:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA05448 for ; Fri, 23 Jul 1999 20:01:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA23001 for ; Fri, 23 Jul 1999 20:01:35 -0700 (PDT) Received: from dfw-ix15.ix.netcom.com (dfw-ix15.ix.netcom.com [206.214.98.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25035 for ; Fri, 23 Jul 1999 20:01:35 -0700 (PDT) Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id WAA21851; Fri, 23 Jul 1999 22:01:21 -0500 (CDT) Received: from dal-tx1-24.ix.netcom.com(207.94.120.88) by dfw-ix15.ix.netcom.com via smap (V1.3) id rma021835; Fri Jul 23 22:01:03 1999 Message-ID: <3798BDEB.16635D62@ix.netcom.com> Date: Fri, 23 Jul 1999 20:09:33 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: list@ifwp.org, ipng@sunroof.eng.sun.com Subject: Re: [IDNO-DISCUSS] Re: [IFWP] What I would have said... References: <19990724020630.74EB6F0B0@ns1.vrx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard and all, Yep. And these are huge advantages over V6.... Richard J. Sexton wrote: > At 05:17 PM 7/23/99 -0700, you wrote: > >On Fri, Jul 23, 1999 at 04:32:58PM -0700, Bill Lovell wrote: > >> For the benefit of dumb butt here, what's the IP size of the new IPv6 thing? > >> (Did I get that right?) It's not a "dotted quad," I take it, so what is > >> it? And > >> its capacity is 2 to the what? > > > >128 bits vs 32 bits for IPv4. That's > > > >340282366920938463463374607431768211456 > >vs > >4294967296 > > > >addresses, if I did the arithmetic correctly... > > > >Or 56713727820156410577229101238 addresses for every human on earth, > >give or take a few. > > In the IPV8 model, the address is 16 bits of V4 address, 4 QoS1] > bits, and most importantly a 3 bit and an 8 bit prefix to the > address. This gives you 16 * 256 times the current number of > Internets to play with. > > See http://ipv8.vrx.net/kwikref/addresses/ > > With V6, you have to get addressed from one of the 3 RIR's, in V8 > you can get addresses from any of the 2048 TLD authorities. V8 rides > over a core V4 (or V6) transport and grows the net at the edges. > > [1] Quality of Service > -- > Richard Sexton | richard@tangled.web | http://dns.vrx.net/tech/rootzone > http://killifish.vrx.net http://www.mbz.org http://lists.aquaria.net > Bannockburn, Ontario, Canada, 70 & 72 280SE, 83 300SD +1 (613) 473-1719 Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 24 07:24:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA05882 for ipng-dist; Sat, 24 Jul 1999 07:21:14 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05875 for ; Sat, 24 Jul 1999 07:21:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA19129 for ; Sat, 24 Jul 1999 07:21:06 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06174 for ; Sat, 24 Jul 1999 08:21:05 -0600 (MDT) Received: from iota.zk3.dec.com (iota.zk3.dec.com [16.140.32.65]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id KAA25440; Sat, 24 Jul 1999 10:21:04 -0400 (EDT) Received: from localhost by iota.zk3.dec.com (8.7.6/UNX 1.7/1.1.20.3/24Apr98-0811AM) id KAA0000022426; Sat, 24 Jul 1999 10:21:03 -0400 (EDT) From: Jim Bound Message-Id: <199907241421.KAA0000022426@iota.zk3.dec.com> X-Authentication-Warning: iota.zk3.dec.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Brian E Carpenter cc: IPng Mailing List , bound@zk3.dec.com Subject: Re: Session Stability (was multi-homing vs route aggregation (was Re: Bad routes update)) In-reply-to: Your message of "Thu, 22 Jul 1999 20:51:29 CDT." <3797CAA1.6107F3B7@hursley.ibm.com> Date: Sat, 24 Jul 1999 10:21:02 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, As you know I agree with Robert very strongly. Also if some want to break the e2e model as I define it and most of my customers (they know its broke but would like it fixed I hear so don't inject that reality or we can have a discussion of whose customer is smarter yours or mine and I don't think that useful). >Thanks. I asked the question because this was part of the discussion >at the recent IAB workshop, and one of our recommendations was to >study further the concept of separating endpoint names from endpoint >locators. Your comments are relevant. We have been studying this for years it could be like trying to prove the 4th dimension of Einstein in fact exists within time and space. >From an implementation and **performance** view having nodes find addresses from identifiers is very bogus IMO and the wrong way to solve the problem. It will cause additional cycles on any platform and unneccessary IMO. It could be that IPsec discussions of identifiers is worth pursuing but I am not even convinced of that because the address is only part of the identification process. >However another of the recommndations was to actively pursue >IPv6 deployment based on TLA addressing, and not hold this up >due to such studies, and I'd be glad to see that happen >(i.e. let's figure out simple TLA-based multihoming first). Thank god for that wisdom judgement it would have caused so much battle in the IETF and gridlock we would not get anything else done as there is a strong faction of us out here who want to deploy IPv6 and if opposing got in the way of that now the market and that lets-deploy-ipv6-faction would be a joint debate from that side of the belief system. As far as altering IP heaeders in transit I think its time I put out before wash d.c. my view of IP Transparency. This is a very bad idea for certain fields in the IP header. I provide below mail I sent sometime ago to the IPv6 deployment list that came out before the IAB transparency draft. I will delete the headers and some other text not relative to this conversation. And yes it is a legal issue too. I do agree that NAP/ISP SLAs with subscribers could permit such behavior but I believe that is the only way. -------------------------------------- Excerpt from Mail on IPv6 Deployment List Thurs Feb 25, 1999 at 13:32: [DISCLAIMER] This is not a Compaq supported activity and nothing said reflects the view of my employer, this is an individual analysis by me. For discussion Node X and Node Y (defined as Nodes here) are communicating in a bi-directional means using TCP/IP the nomenclature. Whether it is an Intranet or on the Internet is not a disguishing characteristic for this discussion. Also none of the terms used from RFC 2119 apply to this discussion they may mean different things than 2119, it is not a spec but a set of principles. - The Nodes users data is not altered during communications. o The Nodes user data is not added to or reduced by any Node on the Network or by any Service on the Network. User Data is determined prior to communications between the Nodes. - The Nodes packet exchanges are their packets as ownership and the Nodes have a legal and moral right to not expect their packets IP header to be altered by any other Node along the path; except to have those packets forwarded by intermediate Nodes on the path. - The Nodes may permit along the communications path for other Nodes thru aggreement to use defined fields in the IP header which are classified as public domain to provide a level of service based on the marking of such fields by an intermediate Node or set of Nodes. This does not and should not include the alteration of the source or destination addresses of the orginating Nodes. - The Nodes have the capability to secure their communications path between them using the result of all the bits contained in the packet as a result for identification to each end, except for the services public domain fields and any field which is needed to assist the forwarding of the packet for metrics retained to avoid congestion or a packet that has exceeded its range for the function intended (e.g. Hop Limit, TTL, ECN bits). This should include the source and destination addresses in the packets, for identification. These principles state in essence that each end-user that generates a packet on a Node owns and defines the content of such packet sent to another Node, and alteration of that packet is only done to route that packet thru a network, provide a service for that packet, prevent that packet from causing congestion to other packets, or to set and reset metrics in the packet to determine if the packet can be delivered within a diameter defined by the end-user of the orginating packet. The IP architecture and TCP/IP protocol suite support this model. But because of the shortage of IP address space a new mechanism was introduced into the use of IP called Network Address Translation (NAT) where the source and destination addresses can be altered from private addresses behind such intermediate Nodes that perform this function. >From this change their is now discussion of not only NAT but that the packets from end-users can be altered within the network to provide benefits to the users by giving them their data from within the network and altering their packets to help them! Also that end-users can trust the Nodes in the middle between them. These are very bad ideas that will take the control out of the end-users hand for their packet and place it in the hands of the network. It also affects both de-centralized and centralized existing practice for distributed computing within the client/server model. The client no longers obtains its data from the server to do its economic business function, but from the network. The end-2-end model is important to the two Nodes above for: performance, scalability, security, cost of computing, and the ownership of the Nodes packets legally and morally. The end-2-end model reduces the chaos potential of keeping the network for one purpose and one purpose only "delivery of a packet between the Nodes in the most efficient means possible". The network between sole function should be to route those packets in tact between the Nodes. Anything else breaks the end-2-end model at great cost and opens up networks and the end users themselves to great chaos, and more importantly control by an unseen paradigm of trusting the entity in the middle with the business operation of the Nodes communicating. IPv6 because of its address space can continue to support the end-2-end model and because it did not do anything of and in itself to alter the principles of the end-2-end model defined by IPv4 and the TCP/IP protocol suite. It has enhanced the necessary fields to assist the forwarding paradigm with new fields for the public domain between the Nodes (e.g. Class, Flowlabel (can be used end-2-end too), Hop Limit, Extension Headers to assist forwarding decisions, TBD ECN bits). /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 Sat Jul 24 09:08:10 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA05994 for ipng-dist; Sat, 24 Jul 1999 09:05:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05987 for ; Sat, 24 Jul 1999 09:05:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA27635 for ; Sat, 24 Jul 1999 09:05:21 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11825 for ; Sat, 24 Jul 1999 09:05:21 -0700 (PDT) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id MAA30809; Sat, 24 Jul 1999 12:05:20 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000026879; Sat, 24 Jul 1999 12:05:19 -0400 (EDT) From: Jim Bound Message-Id: <199907241605.MAA0000026879@quarry.zk3.dec.com> To: robert@digi-data.com cc: Brian E Carpenter , IPng Mailing List , bound@zk3.dec.com Subject: Re: Session Stability (was multi-homing vs route aggregation (was Re: Bad routes update)) In-reply-to: Your message of "Thu, 22 Jul 1999 18:08:13 EDT." <99Jul22.180120gmt-0400.15236@odin.digi-data.com> Date: Sat, 24 Jul 1999 12:05:19 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, >I believe that work to solve the question of transport connections surviving a >renumbering event or topology change is worth the effort, hence my clumsy >attempt at presenting a mechanism. This as you know is very complex stuff and as Bill pointed out a proposal and I think an implementation exists from UCLA for one idea. But I believe any proposal must address both TCP and UDP. I also believe that for survival, the actual transport functions in the implementation must be done at the network layer and notification has to be done to any transport functions depending on addresses and to the APIs accessing the transport functions. [I am trying to describe this without using a particular implementation though I think using the BSD paradigm is how I would describe the kernel and API changes needed]. I think the trigger for such an event for the network layer is an IPv6 Extension Header and will IMO look very much like the IPv6 Mobile BINDING update. Charlie Perkins, I, and several University researchers started working on this from the perspective above but dropped it in favor of more pressing IPv6 activity. The question is how important is this in the scheme of things and work we have to do as implementors for IPv6 today. We certainly do not need this for IPv6 to begin deployment or even semi-wide deployment IMO. But open to hearing why that is not true? The solution to this problem must address the following IMO: 1. Cause the operation to begin of changing the endpoint address at the network layer on an implementation not the transport layer. 2. Support both TCP and UDP not doing UDP is not a complete approach. 3. An implementation analysis in this case is important to determine the standard engineering affects to the transport function and table lookups associated with that function, and the affect to APIs. 4. It should be an IPv6 DST option to notify expediently the Ext Header exists in the packet. This way it can be processed via the set up needed at the header. Some may not like this and I am not saying process the Ext headers out of order but rather the DST option could tell a Thread on an implementation that a change to an endpoint address is going to take place. 5. Propogation Delay needs to be taken into consideration once a commit to changing the endpoint addresses has taken place. 6. Performance costs of doing this should be measured and health warnings issued for RT applications. 7. Security is imperative the attacks from this are very bad and could cause major damage. That is just a start. But I am still not convinced this is a priority for us and would like to see the IRTF take this on at this point maybe instead of the IETF and have its own mail list not e2e or the like. It would need individual focus as a new effort and a Technical Champion to take it on and hear all the input on solutions for this space. I think this is even worth getting a grant to work on and do it diligently. I think it could even be a Phd Thesis actually. I also think this work would permit Hosts to use IPv6 anycast addresses too which I think would be a good thing esp for Host cluster operations where they do not want to "act" as routers, which is what we will have to do today to use anycast addresses in IPv6 in a compliant manner. /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 Sun Jul 25 16:14:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA07048 for ipng-dist; Sun, 25 Jul 1999 16:12:12 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07041 for ; Sun, 25 Jul 1999 16:12:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA15235 for ; Sun, 25 Jul 1999 16:12:02 -0700 (PDT) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA06057 for ; Sun, 25 Jul 1999 16:12:02 -0700 (PDT) Received: (qmail 5649 invoked from network); 25 Jul 1999 23:12:01 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 25 Jul 1999 23:12:01 -0000 Received: from localhost by ops.arin.net (8.9.0/8.9.0) with SMTP id TAA04057; Sun, 25 Jul 1999 19:12:00 -0400 (EDT) Date: Sun, 25 Jul 1999 19:12:00 -0400 (EDT) From: Shane Kerr Reply-To: Shane Kerr To: Bill Manning cc: IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation) In-Reply-To: <199907222331.QAA10452@zephyr.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm going to go ahead and post this to the list since at least three people have posted with some interest about renumbering survival. On Thu, 22 Jul 1999, Bill Manning wrote: > > An incrementing integer could be a problem. It could make it easy to highjack a > > session. I was just talking about a number that can be used for mapping to the > > IP address and can be used in place of the IP address in the Protocol Control > > Block. > > This has been coded and tested already. Christian Hutiema > had a group of UCLA students do this about three years ago. > Based on a long-expired ID. There is code around someplace. A URL or two would be nice. I searched on Altavista, Google, Yahoo, Excite, Lycos, and AskJeeves, as well as the search engine off of http://www.ucla.edu/, and could find no references to Christian Hutiema. I went to the UCLA computer science home page, http://www.cs.ucla.edu/, and couldn't find any references to related material. Any suggestions on where to go or who to e-mail? > > > Which kind of brings us to the next question: is it possible to attain > > > any kind of session survival with a UDP session? Certainly the concept of > > > a UDP session has meaning (e.g. TFTP), but this is kept strictly at the > > > application level. I think it would be fairly difficult, if not > > > impossible, without some sort of protocol-level support (visions of NAT > > > dance through my head). But perhaps that's not such a big deal, as long > > > as it is agreed that this is a TCP-only proposition. > > There are a couple of ways to do this, but they require some > extra cruft on the side (adding limited state). Some code > exists here as well. Again, a URL or two would be most helpful. Or a name, or something. > > What I am proposing is independent of the specific transport protocol in use. > > It will work for both TCP and UDP. What I propose is code to perform the > > mapping to the IP address from the identifier used in the protocol control block > > and an auxiliary protocol to negotiate an update to that mapping when either > > peer needs to renumber or select a different interface. This combination of the > > mapping code and a protocol to negotiate the update I am calling an Agent. > > Don;t think you need to do that much if designed properly. > It really would be worth your time to review the e2e and > bigi list archives. Most of this is old ground. Again, some detail would be nice. I'm not really sure what "e2e" or "bigi" are. I'm thinking you mean the IRTF end2end mailing list for e2e. However, I couldn't find an archive for the mailing list. At least, there wasn't one linked to from the IRTF home page, and a few quick searches on various web engines didn't turn up any hits. I'd rather not be the guy who says, "Is there an archive for this?" to the mailing list, but I guess I can if I have to. :) And what is "bigi" anyway? It seems like you want discussion on this topic ended, or at least moved off of the ipng mailing list. This is fine, but I'm not really sure where to take it from here. Am I the only one here interested in work on surviving a renumbering? It seems pertinent, given the current proposal on multihoming. -- Shane Kerr Software Engineer American Registry for Internet Numbers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 25 22:11:45 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA07334 for ipng-dist; Sun, 25 Jul 1999 22:08:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07327 for ; Sun, 25 Jul 1999 22:08:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA04881 for ; Sun, 25 Jul 1999 22:08:34 -0700 (PDT) Received: from server.co.rnp.br (server.co.rnp.br [200.17.63.117]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA00901 for ; Sun, 25 Jul 1999 23:08:32 -0600 (MDT) Received: from localhost (alex@localhost) by server.co.rnp.br (8.9.3/8.9.3) with ESMTP id CAA34664; Mon, 26 Jul 1999 02:08:06 -0300 Date: Mon, 26 Jul 1999 02:08:06 -0300 (GRNLNDST) From: Alex Soares de Moura Reply-To: alex@nc-rj.rnp.br To: Shane Kerr cc: Bill Manning , IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation) 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 On Sun, 25 Jul 1999, Shane Kerr wrote: > I'm going to go ahead and post this to the list since at least three > people have posted with some interest about renumbering survival. > > On Thu, 22 Jul 1999, Bill Manning wrote: > > > > An incrementing integer could be a problem. It could make it easy to highjack a > > > session. I was just talking about a number that can be used for mapping to the > > > IP address and can be used in place of the IP address in the Protocol Control > > > Block. > > > > This has been coded and tested already. Christian Hutiema > > had a group of UCLA students do this about three years ago. > > Based on a long-expired ID. There is code around someplace. > > A URL or two would be nice. I searched on Altavista, Google, Yahoo, > Excite, Lycos, and AskJeeves, as well as the search engine off of > http://www.ucla.edu/, and could find no references to Christian Hutiema. > I went to the UCLA computer science home page, http://www.cs.ucla.edu/, > and couldn't find any references to related material. Any suggestions on > where to go or who to e-mail? Try again and look for Cristian Huitema ^^^^^^^ > > > > > Which kind of brings us to the next question: is it possible to attain > > > > any kind of session survival with a UDP session? Certainly the concept of > > > > a UDP session has meaning (e.g. TFTP), but this is kept strictly at the > > > > application level. I think it would be fairly difficult, if not > > > > impossible, without some sort of protocol-level support (visions of NAT > > > > dance through my head). But perhaps that's not such a big deal, as long > > > > as it is agreed that this is a TCP-only proposition. > > > > There are a couple of ways to do this, but they require some > > extra cruft on the side (adding limited state). Some code > > exists here as well. > > Again, a URL or two would be most helpful. Or a name, or something. > > > > What I am proposing is independent of the specific transport protocol in use. > > > It will work for both TCP and UDP. What I propose is code to perform the > > > mapping to the IP address from the identifier used in the protocol control block > > > and an auxiliary protocol to negotiate an update to that mapping when either > > > peer needs to renumber or select a different interface. This combination of the > > > mapping code and a protocol to negotiate the update I am calling an Agent. > > > > Don;t think you need to do that much if designed properly. > > It really would be worth your time to review the e2e and > > bigi list archives. Most of this is old ground. > > Again, some detail would be nice. I'm not really sure what "e2e" or > "bigi" are. I'm thinking you mean the IRTF end2end mailing list for e2e. > However, I couldn't find an archive for the mailing list. At least, there > wasn't one linked to from the IRTF home page, and a few quick searches on > various web engines didn't turn up any hits. I'd rather not be the guy > who says, "Is there an archive for this?" to the mailing list, but I guess > I can if I have to. :) And what is "bigi" anyway? Archive of the end-2-end mailing list: ftp://ftp.isi.edu/end2end/ > It seems like you want discussion on this topic ended, or at least moved > off of the ipng mailing list. This is fine, but I'm not really sure where > to take it from here. Am I the only one here interested in work on > surviving a renumbering? It seems pertinent, given the current proposal > on multihoming. > > -- > Shane Kerr > Software Engineer > American Registry for Internet Numbers Best regards, -- Alex Soares de Moura Academic Brazilian Research Network - http://www.rnp.br/index_e.html NOC - [CO - http://www.rnp.br/co_e/] - Tel. +55 21 5111563 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 25 22:29:15 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA07369 for ipng-dist; Sun, 25 Jul 1999 22:24:31 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07362 for ; Sun, 25 Jul 1999 22:24:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA04720 for ; Sun, 25 Jul 1999 22:24:23 -0700 (PDT) Received: from server.co.rnp.br (server.co.rnp.br [200.17.63.117]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA27451 for ; Sun, 25 Jul 1999 22:24:21 -0700 (PDT) Received: from localhost (alex@localhost) by server.co.rnp.br (8.9.3/8.9.3) with ESMTP id CAA42222; Mon, 26 Jul 1999 02:24:15 -0300 Date: Mon, 26 Jul 1999 02:24:15 -0300 (GRNLNDST) From: Alex Soares de Moura Reply-To: alex@nc-rj.rnp.br To: Shane Kerr , Bill Manning , IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation) 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 On Mon, 26 Jul 1999, Alex Soares de Moura wrote: > On Sun, 25 Jul 1999, Shane Kerr wrote: > > > I'm going to go ahead and post this to the list since at least three > > people have posted with some interest about renumbering survival. > > > > On Thu, 22 Jul 1999, Bill Manning wrote: > > > > > > An incrementing integer could be a problem. It could make it easy to highjack a > > > > session. I was just talking about a number that can be used for mapping to the > > > > IP address and can be used in place of the IP address in the Protocol Control > > > > Block. > > > > > > This has been coded and tested already. Christian Hutiema > > > had a group of UCLA students do this about three years ago. > > > Based on a long-expired ID. There is code around someplace. > > > > A URL or two would be nice. I searched on Altavista, Google, Yahoo, > > Excite, Lycos, and AskJeeves, as well as the search engine off of > > http://www.ucla.edu/, and could find no references to Christian Hutiema. > > I went to the UCLA computer science home page, http://www.cs.ucla.edu/, > > and couldn't find any references to related material. Any suggestions on > > where to go or who to e-mail? > > Try again and look for Cristian Huitema > ^^^^^^^ Sorry, his name is Christian Huitema. His Homepage: http://www-sop.inria.fr/rodeo/personnel/huitema/huitema.html Best regards again, Alex -- Alex Soares de Moura Academic Brazilian Research Network - http://www.rnp.br/index_e.html NOC - [CO - http://www.rnp.br/co_e/] - Tel. +55 21 5111563 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 04:53:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA07727 for ipng-dist; Mon, 26 Jul 1999 04:51:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07720 for ; Mon, 26 Jul 1999 04:50:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA27836 for ; Mon, 26 Jul 1999 04:50:52 -0700 (PDT) Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA29689 for ; Mon, 26 Jul 1999 04:50:51 -0700 (PDT) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Mon, 26 Jul 1999 12:49:34 +0100 Date: Mon, 26 Jul 1999 12:49:47 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Shane Kerr cc: Bill Manning , IPng Mailing List , weinrib@intel.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-Reply-To: Message-ID: Organization: speaking for none X-URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 25 Jul 1999, Shane Kerr wrote: > On Thu, 22 Jul 1999, Bill Manning wrote: > > > > An incrementing integer could be a problem. It could make it > > > easy to highjack a session. I was just talking about a number > > > that can be used for mapping to the IP address and can be used > > > in place of the IP address in the Protocol Control Block. > > > > This has been coded and tested already. Christian Hutiema > > had a group of UCLA students do this about three years ago. > > Based on a long-expired ID. There is code around someplace. > > A URL or two would be nice. I searched on Altavista, Google, Yahoo, > Excite, Lycos, and AskJeeves, as well as the search engine off of > http://www.ucla.edu/, and could find no references to Christian Hutiema. Bill unintentionally misled you. It's spelt Huitema. http://www-sop.inria.fr/rodeo/personnel/huitema/huitema.html http://govt.argreenhouse.com/felix/index.shtml etc. Dunno where UCLA comes in. List of books in Amazon. > > > What I am proposing is independent of the specific transport > > > protocol in use. It will work for both TCP and UDP. What I > > > propose is code to perform the mapping to the IP address from > > > the identifier used in the protocol control block and an > > > auxiliary protocol to negotiate an update to that mapping when > > > either peer needs to renumber or select a different interface. > > > This combination of the mapping code and a protocol to > > > negotiate the update I am calling an Agent. > > > Don;t think you need to do that much if designed properly. > > It really would be worth your time to review the e2e and > > bigi list archives. Most of this is old ground. > > Again, some detail would be nice. I'm not really sure what "e2e" or > "bigi" are. I'm thinking you mean the IRTF end2end mailing list for e2e. > However, I couldn't find an archive for the mailing list. ftp://ftp.isi.edu/end2end/ has everything back to 1984. It would be worth someone-at-ISI's time to set up MHonarc and a search index on this in the ISI web pages. > At least, there wasn't one linked to from the IRTF home page, http://www.irtf.org/charters/end2end.htm 'needs updating... circa 1992' is, oddly, a page last updated March 1999. Not having a link to the end2end archives there, much less a search form for the archives, is frankly criminal, even if most of end2end-interest don't use these newfangled johnnycomelately things like the web. Abel, please fix the webpage with a link to ftp://ftp.isi.edu/end2end/ ASAP and begin looking into setting up searchable web indices of the IRTF lists so that new Internet researchers can get up to speed. It seems to me to be in the IRTF's best interest. Bill, since you're at ISI, please organise setting up MHonarc and search functionality for ISI's end2end archives. That will decrease the likelihood of you having to tell people that their ideas are old ground in future - and you'll be able to cite actual specifics easily if you wish when you do. Shane, bigi is likely big-internet. http://metalab.unc.edu/usenet-i/groups-html/info.big-internet.html I've no idea where the archives for this one, if any, are. L. and a pox on people who can't even call things by their True Names. PGP -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 05:43:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA07774 for ipng-dist; Mon, 26 Jul 1999 05:40:58 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07767 for ; Mon, 26 Jul 1999 05:40:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA23747 for ; Mon, 26 Jul 1999 05:40:46 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA08990 for ; Mon, 26 Jul 1999 05:40:35 -0700 (PDT) Received: by odin.digi-data.com id <15235>; Mon, 26 Jul 1999 08:35:58 -0400 Message-Id: <99Jul26.083558gmt-0400.15235@odin.digi-data.com> Date: Mon, 26 Jul 1999 08:42:58 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Shane Kerr , IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Shane, > Again, some detail would be nice. I'm not really sure what "e2e" or > "bigi" are. I shall check out the URL's you posted. I believe BIGI was supposed to be an internet mailing list for something called "BIG Internet". I have never been able to find their archives, though. Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 08:23:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA07962 for ipng-dist; Mon, 26 Jul 1999 08:20:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07955 for ; Mon, 26 Jul 1999 08:20:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA18743 for ; Mon, 26 Jul 1999 08:20:44 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16105 for ; Mon, 26 Jul 1999 09:20:43 -0600 (MDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 9BB634CE03; Mon, 26 Jul 1999 11:20:39 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id LAA02954; Mon, 26 Jul 1999 11:19:29 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id E048F41F16; Mon, 26 Jul 1999 11:19:28 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id D14DB400B4; Mon, 26 Jul 1999 11:19:23 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Shane Kerr Cc: Bill Manning , IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Jul 1999 11:19:23 -0400 From: "Steven M. Bellovin" Message-Id: <19990726151928.E048F41F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk See http://www.chem.ucla.edu/~beichuan/etcp/ for details, including Huitema's draft. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 08:43:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA08038 for ipng-dist; Mon, 26 Jul 1999 08:40:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08031 for ; Mon, 26 Jul 1999 08:39:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA07837 for ; Mon, 26 Jul 1999 08:39:55 -0700 (PDT) Received: from burdell.cc.gatech.edu (burdell.cc.gatech.edu [130.207.3.207]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03772 for ; Mon, 26 Jul 1999 08:39:54 -0700 (PDT) Received: from orsay.cc.gatech.edu (orsay.cc.gatech.edu [130.207.118.12]) by burdell.cc.gatech.edu (8.9.1/8.9.1) with ESMTP id LAA28445; Mon, 26 Jul 1999 11:39:53 -0400 (EDT) Received: from lixia (dhcp16.gatech.edu [130.207.181.16]) by orsay.cc.gatech.edu (8.9.1/8.9.1) with SMTP id LAA19969; Mon, 26 Jul 1999 11:39:42 -0400 (EDT) Message-Id: <199907261539.LAA19969@orsay.cc.gatech.edu> X-Sender: lixia@131.179.96.157 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 26 Jul 1999 08:38:35 -0700 To: "Steven M. Bellovin" , Shane Kerr From: Lixia Zhang Subject: Re: Session Stability (was multi-homing vs route aggregation) Cc: bzhang@cs.ucla.edu, IPng Mailing List In-Reply-To: <19990726151928.E048F41F16@SIGABA.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm sorry but that is an outdated draft. We have revised the spec and implementation since then. We'll try to put out an updated spec soon. Lixia At 08:19 AM 7/26/99 , Steven M. Bellovin wrote: >See http://www.chem.ucla.edu/~beichuan/etcp/ for details, including >Huitema's draft. > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Jul 26 08:59:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA08073 for ipng-dist; Mon, 26 Jul 1999 08:56:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08062 for ; Mon, 26 Jul 1999 08:56:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA11259 for ; Mon, 26 Jul 1999 08:56:30 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04132 for ; Mon, 26 Jul 1999 09:56:30 -0600 (MDT) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id LAA20389; Mon, 26 Jul 1999 11:56:15 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000024267; Mon, 26 Jul 1999 11:56:15 -0400 (EDT) From: Jim Bound Message-Id: <199907261556.LAA0000024267@quarry.zk3.dec.com> To: Lixia Zhang cc: "Steven M. Bellovin" , Shane Kerr , bzhang@cs.ucla.edu, IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Mon, 26 Jul 1999 08:38:35 PDT." <199907261539.LAA19969@orsay.cc.gatech.edu> Date: Mon, 26 Jul 1999 11:56:15 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Lixia, >I'm sorry but that is an outdated draft. We have revised the spec and >implementation since then. >We'll try to put out an updated spec soon. Does it still only support UDP? 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 Jul 26 09:14:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA08096 for ipng-dist; Mon, 26 Jul 1999 09:11:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08089 for ; Mon, 26 Jul 1999 09:11:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA12606 for ; Mon, 26 Jul 1999 09:11:15 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15602 for ; Mon, 26 Jul 1999 09:11:14 -0700 (PDT) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id MAA09306; Mon, 26 Jul 1999 12:09:43 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000028721; Mon, 26 Jul 1999 12:09:42 -0400 (EDT) From: Jim Bound Message-Id: <199907261609.MAA0000028721@quarry.zk3.dec.com> To: Lixia Zhang cc: "Steven M. Bellovin" , Shane Kerr , bzhang@cs.ucla.edu, IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Mon, 26 Jul 1999 11:56:15 EDT." <199907261556.LAA0000024267@quarry.zk3.dec.com> Date: Mon, 26 Jul 1999 12:09:42 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Lixia, >>I'm sorry but that is an outdated draft. We have revised the spec and >>implementation since then. >>We'll try to put out an updated spec soon. > >Does it still only support UDP? Whoops my UDP side of brain is dominant. mean't. Does it still only support TCP? p.s. thanks Steve B. for catching that.......... 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 Jul 26 09:14:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA08105 for ipng-dist; Mon, 26 Jul 1999 09:12:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08098 for ; Mon, 26 Jul 1999 09:12:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA12772 for ; Mon, 26 Jul 1999 09:12:43 -0700 (PDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16185 for ; Mon, 26 Jul 1999 09:12:43 -0700 (PDT) Received: from maia.east.isi.edu by east.isi.edu (8.8.5/5.61+local-24) id ; Mon, 26 Jul 1999 16:06:02 GMT Message-Id: <199907261606.QAA03668@east.isi.edu> X-Authentication-Warning: east.isi.edu: maia.east.isi.edu [38.245.76.14] didn't use HELO protocol To: Jim Bound Cc: ipng@sunroof.eng.sun.com Reply-To: mankin@EAST.ISI.EDU Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of Mon, 26 Jul 1999 11:56:15 -0400. <199907261556.LAA0000024267@quarry.zk3.dec.com> Date: Mon, 26 Jul 1999 12:07:12 EDT From: Allison Mankin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does it still only support UDP? Jim, Do you mean does it still only support TCP? UDP reattachment is not covered. That was one of the reasons the original draft was not pursued in the IETF Transport area, that it had limited applicability. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 09:30:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA08148 for ipng-dist; Mon, 26 Jul 1999 09:25:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08141 for ; Mon, 26 Jul 1999 09:25:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA28785 for ; Mon, 26 Jul 1999 09:24:59 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21337 for ; Mon, 26 Jul 1999 09:24:58 -0700 (PDT) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id MAA26027; Mon, 26 Jul 1999 12:24:58 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000000233; Mon, 26 Jul 1999 12:24:57 -0400 (EDT) From: Jim Bound Message-Id: <199907261624.MAA0000000233@quarry.zk3.dec.com> To: mankin@EAST.ISI.EDU cc: ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Mon, 26 Jul 1999 12:07:12 EDT." <199907261606.QAA03668@east.isi.edu> Date: Mon, 26 Jul 1999 12:24:57 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Allison, Yep. OK. I did not know that about the Transport Area either. I sent a correction to the list. Do you think its worth putting a draft together to attempt to intrigue developers at this time? I could ressurect my old draft as we have learned much more about this problem since then and why it may be important now. I don't think it has anything to do with the multihome issue though? Only renumbering? 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 Jul 26 09:34:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA08171 for ipng-dist; Mon, 26 Jul 1999 09:33:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08164 for ; Mon, 26 Jul 1999 09:33:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA00278 for ; Mon, 26 Jul 1999 09:33:02 -0700 (PDT) Received: from burdell.cc.gatech.edu (burdell.cc.gatech.edu [130.207.3.207]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22643 for ; Mon, 26 Jul 1999 10:32:58 -0600 (MDT) Received: from orsay.cc.gatech.edu (orsay.cc.gatech.edu [130.207.118.12]) by burdell.cc.gatech.edu (8.9.1/8.9.1) with ESMTP id MAA03766; Mon, 26 Jul 1999 12:32:57 -0400 (EDT) Received: from lixia (dhcp16.gatech.edu [130.207.181.16]) by orsay.cc.gatech.edu (8.9.1/8.9.1) with SMTP id MAA20215; Mon, 26 Jul 1999 12:32:52 -0400 (EDT) Message-Id: <199907261632.MAA20215@orsay.cc.gatech.edu> X-Sender: lixia@131.179.96.157 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 26 Jul 1999 09:31:48 -0700 To: Jim Bound From: Lixia Zhang Subject: Re: Session Stability (was multi-homing vs route aggregation) Cc: bzhang@cs.ucla.edu, IPng Mailing List In-Reply-To: <199907261609.MAA0000028721@quarry.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:09 AM 7/26/99 , Jim Bound wrote: >Hi Lixia, > >>>I'm sorry but that is an outdated draft. We have revised the spec and >>>implementation since then. >>>We'll try to put out an updated spec soon. >> >>Does it still only support UDP? I wondered that too when seeing your first msg :-) >Whoops my UDP side of brain is dominant. mean't. > >Does it still only support TCP? At this time, Yes. A little expansion on that yes: - We had wanted to get this (UDP) part done but it's just one of the (many) term projects that had no support for continuition. - in principle there is no reason why the same code cannot be used for UDP - in detail, however, doing the same for UDP may require more changes to existing implementation. (One needs to maintain a list of possible addresses and info about their usability. TCP has this notion of "connection" which is the entity to attach this addr info to, while UDP has no equivalent entity ...) Lixia -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 09:48:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA08214 for ipng-dist; Mon, 26 Jul 1999 09:44:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08207 for ; Mon, 26 Jul 1999 09:44:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA18637 for ; Mon, 26 Jul 1999 09:44:39 -0700 (PDT) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA29399 for ; Mon, 26 Jul 1999 09:44:38 -0700 (PDT) Received: (qmail 9669 invoked from network); 26 Jul 1999 16:44:36 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 26 Jul 1999 16:44:36 -0000 Received: from sunshine.arin.net (sunshine.arin.net [192.149.252.183]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA29582; Mon, 26 Jul 1999 12:44:36 -0400 (EDT) Received: from localhost (kerr@localhost) by sunshine.arin.net (8.9.0/8.9.0) with SMTP id MAA04525; Mon, 26 Jul 1999 12:44:35 -0400 (EDT) X-Authentication-Warning: sunshine.arin.net: kerr owned process doing -bs Date: Mon, 26 Jul 1999 12:44:35 -0400 (EDT) From: Shane Kerr X-Sender: kerr@sunshine To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-Reply-To: <199907261624.MAA0000000233@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 26 Jul 1999, Jim Bound wrote: > I don't think it has anything to do with the multihome issue though? > > Only renumbering? My understanding is that the current proposal for multihoming involves each host/router/thingy on a multihomed network assuming an IP address for each published network. A problem with this is that if the upstream provider dies, then any sessions will have a different IP address - effectively renumbering any connections active at that time. -- Shane Kerr Software Engineer American Registry for Internet Numbers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 09:50:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA08232 for ipng-dist; Mon, 26 Jul 1999 09:49:23 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08225 for ; Mon, 26 Jul 1999 09:49:13 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA25748 for ; Mon, 26 Jul 1999 09:49:12 -0700 (PDT) Received: from burdell.cc.gatech.edu (burdell.cc.gatech.edu [130.207.3.207]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01272 for ; Mon, 26 Jul 1999 09:49:11 -0700 (PDT) Received: from orsay.cc.gatech.edu (orsay.cc.gatech.edu [130.207.118.12]) by burdell.cc.gatech.edu (8.9.1/8.9.1) with ESMTP id MAA04965; Mon, 26 Jul 1999 12:49:10 -0400 (EDT) Received: from lixia (dhcp16.gatech.edu [130.207.181.16]) by orsay.cc.gatech.edu (8.9.1/8.9.1) with SMTP id MAA20235; Mon, 26 Jul 1999 12:49:09 -0400 (EDT) Message-Id: <199907261649.MAA20235@orsay.cc.gatech.edu> X-Sender: lixia@131.179.96.157 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 26 Jul 1999 09:48:07 -0700 To: Jim Bound , mankin@east.isi.edu From: Lixia Zhang Subject: Re: Session Stability (was multi-homing vs route aggregation) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199907261624.MAA0000000233@quarry.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:24 AM 7/26/99 , Jim Bound wrote: >Hi Allison, > >Yep. OK. I did not know that about the Transport Area either. >I sent a correction to the list. > >Do you think its worth putting a draft together to attempt to intrigue >developers at this time? I could ressurect my old draft as we have >learned much more about this problem since then and why it may be >important now. > >I don't think it has anything to do with the multihome issue though? Well, other than some simple changes to TCP, the core of the implementation is on how to obtain and maintain the list of the addresses for the remote end. I believe this piece of functionality would be same/similar to what needed in multihoming cases (but I must say that I have not followed the multi-homing thread discussion---meant to but havent had time. I'm sitting in this DARPA/NSF "smart environment workshop" for the day which provides great net connectivities so I managed to read the email of the day). >Only renumbering? > >thanks >/jim Lixia -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 09:59:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA08297 for ipng-dist; Mon, 26 Jul 1999 09:55:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08290 for ; Mon, 26 Jul 1999 09:55:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA21229 for ; Mon, 26 Jul 1999 09:55:27 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04426 for ; Mon, 26 Jul 1999 10:55:26 -0600 (MDT) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id MAA07156; Mon, 26 Jul 1999 12:55:24 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000008227; Mon, 26 Jul 1999 12:55:24 -0400 (EDT) From: Jim Bound Message-Id: <199907261655.MAA0000008227@quarry.zk3.dec.com> To: Lixia Zhang cc: Jim Bound , bzhang@cs.ucla.edu, IPng Mailing List Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Mon, 26 Jul 1999 09:31:48 PDT." <199907261632.MAA20215@orsay.cc.gatech.edu> Date: Mon, 26 Jul 1999 12:55:24 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Lixia, >A little expansion on that yes: >- We had wanted to get this (UDP) part done but it's just one of the > (many) term projects that had no support for continuition. >- in principle there is no reason why the same code cannot be used > for UDP >- in detail, however, doing the same for UDP may require more changes > to existing implementation. (One needs to maintain a list of possible > addresses and info about their usability. TCP has this notion of > "connection" which is the entity to attach this addr info to, while > UDP has no equivalent entity ...) It depends on the approach taken which is why as you may recall I proposed it be altered at the network layer with an Ext header (the Mobile Binding would work for example), before the code executes connection responses or initiators. I suggested actually updating the data structures from where the connection code gets their information. One implementation problem with that is flushing out any cache an implementation may be using for performance reasons. But with the new DST options we can also now poke the network layer to look for the Ext hdr. The other problem my proposal had was TCP RST, but I was trying to propose using anycast addresses for Hosts at the same time which I would not suggest attempting again. That problem I now realize now is a separate problem and only indirectly releated to dynamically changing Transport endpoints. ICMPv4 or ICMPv6 issues are fixed using the approach of updating the state of a connection. Notifying the APIs is pretty trivial too we just need to add new notification codes, but a problem for existing applications, so they may not know whats up. I think IPsec will work for the security too and would have to be a MUST for this to be used. But if we can move this work to support UDP too and get a new spec out thats great. But we may want to check out different architectural issues with solving this problem. Besides Christian is one of our brightest folks and I am sure the idea will work, I just think we need to make sure UDP is not forgotten.` Do you think this is ready for IETF work or should be done via IRTF work? I sent some mail to the list on this the other day. 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 Jul 26 10:30:58 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA08402 for ipng-dist; Mon, 26 Jul 1999 10:24:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08395 for ; Mon, 26 Jul 1999 10:24:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA27252 for ; Mon, 26 Jul 1999 10:24:44 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14958 for ; Mon, 26 Jul 1999 10:24:42 -0700 (PDT) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id NAA14609; Mon, 26 Jul 1999 13:23:11 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000015491; Mon, 26 Jul 1999 13:23:10 -0400 (EDT) From: Jim Bound Message-Id: <199907261723.NAA0000015491@quarry.zk3.dec.com> To: Shane Kerr cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Mon, 26 Jul 1999 12:44:35 EDT." Date: Mon, 26 Jul 1999 13:23:10 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Shane, >> I don't think it has anything to do with the multihome issue though? >> >> Only renumbering? >My understanding is that the current proposal for multihoming involves >each host/router/thingy on a multihomed network assuming an IP address for >each published network. A problem with this is that if the upstream >provider dies, then any sessions will have a different IP address - >effectively renumbering any connections active at that time. First I would like to see the proposal. Anyone know when it will be sent out? Seems like this is a hot one. Will get lots of WG review too. Who are the authors? Are the slides available from Oslo? I don't think we can assume because an upstream providers die that causes a renumber operation. That is simply overkill. If the upstream provider dies and goes bankrupt and the doors get closed then yes that means they are really gone. But I believe that fail safe clauses with most ISPs will prevent that from happening, I suggest we not address such an extreme case till we solve the easy ones. The problem is if a blackout happens at an upstream provider will ones routing policy be agile enough to re-route the packets to another provider. Steve Deering gave a good list of ways to solve this problem and I can't add to it. I do think RFC 2260 tunneling feature is a nice approach for the short term, but that requires potentially two extra lines for the tunnels, one for each provider. But I would not support for Legal, Moral, Performance, and Transport implementation behavior reasons (and I have lots more) an upstream provider altering the endpoints of an IPv6 header to do multihoming. Nor do I believe this is necessary. If Node Y is talking to Node X on the internet across provider A with a prefix that is aggregatable by Provider A within their routing realm. And Provide A goes down but then you want to use Provider B to get to Node X from Node Y the answer should not be to change the src address of Node Y. For me that is pressing the button that says WRONG ANSWER. But lets see what the new Multihome spec says and use that as a rallying point to discuss this issue and get all our ideas on the table, including the one I dislike and we can debate and defend our positions as we work to consensus. Renumbering the other hand has an old story on this mail list. We support essentially the kick off of renumbering within IPv6 parts. The protocol parts can be done gracefully but if implementations hide addresses in static places then there is nothing we can do with protocol architecture to avoid such ill behaved artifacts. Also there are mgmt interfaces needed to manage any renumbering operation. But the story was even if IPv6 gets that right. Users have the right to use Telnet in IPv6 as a screen saver so to speak. And Telnet should not break because a site has been renumbered. Personally I disagree and know of no business application that runs this way that cannot be brought down and restarted for something as serious as renumbering a site. Its fantasy to believe renumbering can ever be made in the next 10 years with any protocol to just be done on a whim. That is just silly. But there are very valid reasons to want to dynamically renumber a transport connection from a networking perspective like Host Clusters and Failover supporting IPv6 anycast addresses, Embeded Systems (like Appliances and Celluar phones and mobile nodes) wanting to change their address on the fly for dynamic variant reasons across a network or spectrum of bandwidth. These IMO are real computer networking science problems we should be working on like I want my connection now to go here because my VM is bigger at this node. So my support of the good work Christian and Lixia and UCLA is doing is not for Internet renumbering but for the reasons I just stated. So I think Multihoming and Renumbering are two different discussions and Renumbering a site is not a sole reason to go off and solve the problem of altering transport endpoints on the fly. Hope this helps clear up where I am coming from anyway, /jim 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 Jul 26 20:30:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA09430 for ipng-dist; Mon, 26 Jul 1999 20:27:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA09423 for ; Mon, 26 Jul 1999 20:27:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA14922; Mon, 26 Jul 1999 20:26:00 -0700 (PDT) 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 VAA06362; Mon, 26 Jul 1999 21:25:58 -0600 (MDT) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id MAA29047; Tue, 27 Jul 1999 12:19:38 +0900 (JST) Date: Tue, 27 Jul 1999 12:29:57 +0900 Message-ID: <14237.10165.438998.75679V@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com Cc: erik.nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: how to prohibit an application from sending a jumbo payload opt In-Reply-To: In your message of "Tue, 20 Jul 1999 10:41:05 -0700 (PDT)" <199907201741.KAA05940@feller.mentat.com> References: <199907201741.KAA05940@feller.mentat.com> User-Agent: Wanderlust/2.1.2 (Rico Suave) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 48 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I apologize for not responding for a while... >>>>> On Tue, 20 Jul 1999 10:41:05 -0700 (PDT), >>>>> Tim Hartrick said: > In the case of the jumbo payload option, yes, that is my position. The > worst case is that the application adds a jumbo payload option which > results in an illegal datagram being sent to the destination. The destination > will simply discard the broken datagram. OK. > Indeed, it is easy to imagine options which could be defined that could be > used in a DOS attack. That would be a serious problem and we probably should > avoid defining such options if possible. If we need such options then they > would need to be destination options which get placed after an AH header. > That is, they would need to be authenticated before they were processed. > The only ones I know of at this time which MIGHT have such a problem would > be the mobility options. I have not read this spec in a long time so I can't > say with any degree of certainty that all these options are benign if added > to a datagram incorrectly. We've collected opinions of this issue from some implementors. Now let me summarize the opinions. For sending options: Tim: no restriction is necessary (at least currently). Craig: the current scheme is inherently flawed. Francis: (I'm not sure about his opinion, but he seems to think we need no restriction) jinmei: basically the same as Tim's, but would obey some restrictions if someone warries security. For receiving options: Tim: no restriction is necessary. jinmei: ditto. (Please correct the above if I misunderstood) To the authors of the draft: It seems to me that no one wants such a strict restriction described in the draft. I believe the result is worth reconsidering the spec. JINMEI, Tatuya Communication Platform Laboratory Corporate R&D Center, Toshiba 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 Jul 27 10:54:49 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA10689 for ipng-dist; Tue, 27 Jul 1999 10:50:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10674 for ; Tue, 27 Jul 1999 10:50:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA23850 for ; Tue, 27 Jul 1999 10:50:38 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06533 for ; Tue, 27 Jul 1999 11:50:36 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA126970 for ; Tue, 27 Jul 1999 18:50:34 +0100 Received: from hursley.ibm.com (lig32-225-78-165.us.lig-dial.ibm.com [32.225.78.165]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA27870 for ; Tue, 27 Jul 1999 18:50:29 +0100 (BST) Message-ID: <379DE443.1AE9CD13@hursley.ibm.com> Date: Tue, 27 Jul 1999 11:54:27 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Shane Kerr wrote: > > On Mon, 26 Jul 1999, Jim Bound wrote: > > > I don't think it has anything to do with the multihome issue though? > > > > Only renumbering? > > My understanding is that the current proposal for multihoming involves > each host/router/thingy on a multihomed network assuming an IP address for > each published network. A problem with this is that if the upstream > provider dies, then any sessions will have a different IP address - > effectively renumbering any connections active at that time. The proposal is to use the RFC 2260 technique to recover from outages; i.e. active connections get rerouted, not renumbered. Please give the proponents a little more time to write it up. It's vacation season after all. Brian 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 Jul 27 13:52:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA10942 for ipng-dist; Tue, 27 Jul 1999 13:47:16 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10935 for ; Tue, 27 Jul 1999 13:47:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA09660 for ; Tue, 27 Jul 1999 13:47:03 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA00495 for ; Tue, 27 Jul 1999 13:47:02 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24128; Tue, 27 Jul 1999 16:46:26 -0400 (EDT) Message-Id: <199907272046.QAA24128@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: IPv6 Jumbograms to Proposed Standard Date: Tue, 27 Jul 1999 16:46:26 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IPv6 Jumbograms' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary A "jumbogram" is an IPv6 packet containing a payload longer than 65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs. Working Group Summary The Jumbo Payload options was originally specified in the base IPv6 specification (RFC 1883). TCP and UDP enhancements to support jumbograms were specified in RFC 2147. At the time the IPv6 base specification was advanced to Draft Standard (RFC 2460), multiple interoperable implementations of jumbograms had not been demonstrated. Consequently, jumbogram support was removed from the IPv6 base document in order to advance the rest of the base spec. This document defines the Jumbo Payload option, combining the definition originally in RFC 1883 with the TCP UDP enhancements defined in 2147. Protocol Quality This protocol has been reviewed for the IESG by Thomas Narten and Erik Nordmark. Note to RFC Editor: 1. The IESG requests that the RFC Editor delete section 1.2 (and remove the reference to 2119 in the references section). 2. The IESG requests the RFC Editor to remove section 9 (change log of draft versions) from the document. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 15:12:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA11071 for ipng-dist; Tue, 27 Jul 1999 15:06:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11064 for ; Tue, 27 Jul 1999 15:06:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA14977 for ; Tue, 27 Jul 1999 15:06:16 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08532 for ; Tue, 27 Jul 1999 16:06:14 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA42416; Tue, 27 Jul 1999 23:06:11 +0100 Received: from hursley.ibm.com (dhcp23211.almaden.ibm.com [9.1.23.211]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA23960; Tue, 27 Jul 1999 23:06:10 +0100 (BST) Message-ID: <379E2CE0.905B52D6@hursley.ibm.com> Date: Tue, 27 Jul 1999 17:04:16 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Hilarie Orman CC: ipng@sunroof.eng.sun.com Subject: Re: Novell and "the Net" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hilarie, This was put into the IPv6 addressing formats years ago and is really just waiting to be obsoleted IMHO. No big deal. Brian Hilarie Orman wrote: > > Novell is committed to basing its products solely on IP and has no > interest in the IPv6 IPX space. Users of legacy products might > have interest in allocations in some weird way, I suppose. No > one from Novell was at the Oslo IETF to cheer for some obscure IPX > reservation; we were there to cheer for IP, the IETF, and > the future of the Internet. > > Hilarie -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.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 Tue Jul 27 17:06:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA11296 for ipng-dist; Tue, 27 Jul 1999 17:02:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11289 for ; Tue, 27 Jul 1999 17:02:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA18192 for ; Tue, 27 Jul 1999 17:02:33 -0700 (PDT) Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19016 for ; Tue, 27 Jul 1999 18:02:31 -0600 (MDT) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id MAA02687; Wed, 28 Jul 1999 12:02:16 +1200 (NZST) Date: Wed, 28 Jul 1999 12:02:16 +1200 From: Joe Abley To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) Message-ID: <19990728120216.A24211@patho.gen.nz> References: <379DE443.1AE9CD13@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <379DE443.1AE9CD13@hursley.ibm.com>; from Brian E Carpenter on Tue, Jul 27, 1999 at 11:54:27AM -0500 X-Files: the Truth is Out There Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, On Tue, Jul 27, 1999 at 11:54:27AM -0500, Brian E Carpenter wrote: > > The proposal is to use the RFC 2260 technique to recover > from outages; i.e. active connections get rerouted, not renumbered. > > Please give the proponents a little more time to write it up. It's > vacation season after all. When you say "the" proposal, what exactly do you mean? I understood that there were several proposals on the table, including: + pure aggregation model, no TCP session stability in the face of multi-homed upstream failure, algorithm required for TCP endpoint address selection + RFC2260 model, algorithm required for TCP endpoint address selection, possible work required on individual platforms to allow the triggered "fill-in" subnet advertisements + IPv4 model, sacrifice complexity in the core for the sake of simplicity at the edge, and trust other techniques to manage the routing avalanche (like MPLS) + NAT/other transit address modification to provide some degree of address transparency to upstream networks when in the shadow of a transit provider failure ... and so on, and so on. Has a decision been taken to persue the RFC2260 model in preference to others? Incidentally, are the Oslo minutes published yet? I can't find anything more recent than Minneapolis (maybe I'm looking in the wrong place). This is not a loaded question :) I'm just interested in reading the minutes when they're available. Regards, Joe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 17:41:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA11382 for ipng-dist; Tue, 27 Jul 1999 17:38:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11375 for ; Tue, 27 Jul 1999 17:38:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA12560 for ; Tue, 27 Jul 1999 17:38:06 -0700 (PDT) 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 SAA28070 for ; Tue, 27 Jul 1999 18:38:04 -0600 (MDT) 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 JAA01816; Wed, 28 Jul 1999 09:37:28 +0900 (JST) To: Joe Abley cc: Brian E Carpenter , ipng@sunroof.eng.sun.com In-reply-to: jabley's message of Wed, 28 Jul 1999 12:02:16 +1200. <19990728120216.A24211@patho.gen.nz> 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: Session Stability (was multi-homing vs route aggregation) From: itojun@iijlab.net Date: Wed, 28 Jul 1999 09:37:28 +0900 Message-ID: <1814.933122248@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > + RFC2260 model, algorithm required for TCP endpoint address selection, > possible work required on individual platforms to allow the triggered > "fill-in" subnet advertisements RFC2260 does not say so. RFC2260 (section 5.2) tries to let two ISP links back up each other, by having extra connection (usually tunnel) between ISP-A router and site router for ISP-B (and vice versa). End node need not to do anything special. This does not require extra (non-aggregatable) routing announcement. Renumbering (when one of your address goes away) is separate from this story. 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 Tue Jul 27 17:48:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA11416 for ipng-dist; Tue, 27 Jul 1999 17:46:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11409 for ; Tue, 27 Jul 1999 17:46:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA13686 for ; Tue, 27 Jul 1999 17:46:00 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA29924 for ; Tue, 27 Jul 1999 18:45:59 -0600 (MDT) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id UAA13483; Tue, 27 Jul 1999 20:45:58 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id UAA0000013631; Tue, 27 Jul 1999 20:45:58 -0400 (EDT) From: Jim Bound Message-Id: <199907280045.UAA0000013631@quarry.zk3.dec.com> To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Tue, 27 Jul 1999 11:54:27 CDT." <379DE443.1AE9CD13@hursley.ibm.com> Date: Tue, 27 Jul 1999 20:45:58 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, >> My understanding is that the current proposal for multihoming involves >> each host/router/thingy on a multihomed network assuming an IP address for >> each published network. A problem with this is that if the upstream >> provider dies, then any sessions will have a different IP address - >> effectively renumbering any connections active at that time. >The proposal is to use the RFC 2260 technique to recover >from outages; i.e. active connections get rerouted, not renumbered. Glad to hear that. >Please give the proponents a little more time to write it up. It's >vacation season after all. Sure. My issue here is one of the concerns Steve Deering presented is when the mailing list members in their eagerness to work on IPv6 and get stuff done quickly take a thread: 1) that is not defined well, 2) solutions are rumors and no drafts, and 3) people think we have not done something we should have for IPv6 - folks start proposing solutions to a problem that is not defined well and my hot button may say we (the designers and workers initially) screwed up with the Addr Arch or Addr Conf or whatever and IPv6 is in trouble now .---)... I have to chime in as I can't just let that go on the list. I have been guilty of #1 and #2 too but I try hard to not be of late. In fact I am to the point if the problem is not defined I am going start acting like Tom Hanks in "Big" (movie about boy who gets mans body but still is boy) and says to the marketing and engineering persons building products in a meeting "I don't get it", no kid will ever buy that stuff!!!!!! /jim Brian 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 17:49:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA11425 for ipng-dist; Tue, 27 Jul 1999 17:47:08 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11418 for ; Tue, 27 Jul 1999 17:46:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA22621 for ; Tue, 27 Jul 1999 17:46:56 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA25320 for ; Tue, 27 Jul 1999 17:46:54 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id KAA06046; Wed, 28 Jul 1999 10:46:36 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Wed, 28 Jul 1999 10:46:36 +1000 (EST) From: Peter Tattam To: itojun@iijlab.net cc: Joe Abley , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-Reply-To: <1814.933122248@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 28 Jul 1999 itojun@iijlab.net wrote: > > > + RFC2260 model, algorithm required for TCP endpoint address selection, > > possible work required on individual platforms to allow the triggered > > "fill-in" subnet advertisements > > RFC2260 does not say so. RFC2260 (section 5.2) tries to let two > ISP links back up each other, by having extra connection > (usually tunnel) between ISP-A router and site router for ISP-B > (and vice versa). > End node need not to do anything special. > This does not require extra (non-aggregatable) routing announcement. > > Renumbering (when one of your address goes away) is separate from > this story. There is another minor but important related issue and that is of suboptimal routing for particular prefixes. Will this be addressed? > > 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 > -------------------------------------------------------------------- > Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 17:53:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA11457 for ipng-dist; Tue, 27 Jul 1999 17:51:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11450 for ; Tue, 27 Jul 1999 17:50:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA23078 for ; Tue, 27 Jul 1999 17:50:48 -0700 (PDT) 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 SAA00883 for ; Tue, 27 Jul 1999 18:50:45 -0600 (MDT) 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 JAA02049; Wed, 28 Jul 1999 09:50:27 +0900 (JST) To: Peter Tattam cc: ipng@sunroof.eng.sun.com In-reply-to: peter's message of Wed, 28 Jul 1999 10:46:36 +1000. 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: Session Stability (was multi-homing vs route aggregation) From: itojun@iijlab.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <2042.933123015.0@coconut.itojun.org> Date: Wed, 28 Jul 1999 09:50:27 +0900 Message-ID: <2047.933123027@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2042.933123015.1@coconut.itojun.org> Content-Transfer-Encoding: 7bit >> RFC2260 does not say so. RFC2260 (section 5.2) tries to let two >> ISP links back up each other, by having extra connection >> (usually tunnel) between ISP-A router and site router for ISP-B >> (and vice versa). >> End node need not to do anything special. >> This does not require extra (non-aggregatable) routing announcement. >> >> Renumbering (when one of your address goes away) is separate from >> this story. >There is another minor but important related issue and that is of suboptimal >routing for particular prefixes. >Will this be addressed? No I do not think so. Source address selection is a separate question from RFC2260. Here comes a draft that describes how RFC2260 would work with IPv6 (I'll submit this very soon to the correct path). Please be sure to read this with RFC2260. itojun ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2042.933123015.2@coconut.itojun.org> Content-Transfer-Encoding: 7bit Internet Engineering Task Force Jun-ichiro Hagino INTERNET-DRAFT Research Lab, IIJ Expires: January 23, 2000 July 23, 1999 IPv6 multihoming support at site exit routers draft-itojun-ipv6-2260-00.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be January 23, 2000. Abstract The document describes operational requirements and mechanisms for basic IPv6 multihoming support. The mechanism in this document can be combined with more sophisticated (or complex) multihoming support mechanisms, and it will be able to serve as foundation for others. The document is largely based on RFC2260 [Bates, 1998] by Tony Bates. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 1. Problem IPv6 specifications try to decrease the number of backbone routes, to cope with possible memory overflow problem in the backbone routers. To achieve this, the IPv6 addressing architecture [Hinden, 1998] only allows the use of aggregatable addresses. Also, IPv6 network administration rules [Durand, 1999] do not allow non-aggregatable routing announcements to the backbone. Hagino Expires: January 23, 2000 [Page 1] DRAFT IPv6 multihoming support at site exit routers July 1999 In IPv4, a multihomed site uses either of the following technique to achieve better reachability: o Obtain a portable IPv4 address prefix, and announce it from multiple upstream providers. o Obtain single IPv4 address prefix from ISP A, and announce it from multiple upstream providers the site is connected to. The above two methodologies are not available in IPv6, but on the other hand IPv6 sites and hosts may obtain multiple simultaneous address prefixes to achieve the same result. The document provides a way to configure site exit routers and ISP routers, so that the site can achieve better reachability from multihoming connectivity, without violating IPv6 rules. The technique uses already-defined routing protocol (BGP or RIPng), and tunnelling of IPv6 packets, and introduces no new protocol standard. The document is largely based on RFC2260 [Bates, 1998] by Tony Bates. 2. Goals and non-goals The goal of this document is to achieve better packet delivery from a site to the outside, or from the outside to the site, even when some of site exit link is down. Non goals are: o Choose the "best" exit link as possible (How do you measure "best" exit link anyway?). o Achieve load-balancing between multiple exit links. 3. Basic mechanisms We use technique described in RFC2260 section 5.2 onto our configuration. To summarize, for IPv4-only networks, RFC2260 says that: o We assume that our site is connected to 2 ISPs, ISP-A and ISP-B. o We are assigned IP address prefix, Pref-A and Pref-B, from ISP-A and ISP-B respectively. Hosts near ISP-A will get an address from Pref- A, and vice versa. o In the site, we locally exchanage routes for Pref-A and Pref-B, so that hosts in the site can communicate with each other without using external link. Hagino Expires: January 23, 2000 [Page 2] DRAFT IPv6 multihoming support at site exit routers July 1999 o ISP-A and our site is connected by ``primary link'' between ISP router ISP-BR-A and our router E-BR-A. ISP B and our site is connected by primary link between ISP router ISP-BR-B and our router E-BR-B. (ISP A) (ISP B) ISP-BR-A ISP-BR-B | | |Primary link | | | | | +---|-----------------------------|--+ | E-BR-A E-BR-B | | | | Pref-A <----------> Pref-B | +------------------------------------+ o Establish a secondary link, between ISP-BR-A and E-BR-B, and ISP-BR-B and E-BR-A, respectively. Secondary link usually is IP-over-IP tunnel. It is important to have secondary link on top of different medium than primary link, so that one of them survives link failure. For example, secondary link between ISP-BR-A and E-BR-B should go through different medium than primary link between ISP-BR-A and E-BR- A. If secondary link is an IPv4-over-IPv4 tunnel, tunnel endpoint at E-BR-A needs to be an address in Pref-A, not in Pref-B (tunnelled packet needs to travel from ISP-BR-B to E-BR-A, over the primary link between ISP-BR-A and E-BR-A). (ISP A) (ISP B) ISP-BR-A ISP-BR-B | | | | | \-----------------------+ | | | Secondary link | | | | +----------------------|-/ | | | | | | | | | | | | | | | | | +---|--|----------------------|---|--+ | E-BR-A E-BR-B | | | | | +------------------------------------+ o For inbound packets, E-BR-A will advertise (1) Pref-A toward ISP-BR-A with strong preference over primary link, and (2) Pref-B toward ISP- BR-B with weak preference over secondary link. Similarly, E-BR-B will advertise (1) Pref-B toward ISP-BR-B with strong preference over Hagino Expires: January 23, 2000 [Page 3] DRAFT IPv6 multihoming support at site exit routers July 1999 primary link, and (2) Pref-A toward ISP-BR-A with weak preference over secondary link. Note that we always announce Pref-A to ISP-BR-A, and Pref-B to ISP- BR-B. o For outbound packets, ISP-BR-A will advertise (1) default route (or specific routes) toward E-BR-A with strong preference over primary link, and (2) default route (or specific routes) toward E-BR-B with weak preference over secondary link. Similarly, ISP-BR-B will advertise (1) default route (or specific routes) toward E-BR-B with strong preference over primary link, and (2) default route (or specific routes) toward E-BR-A with weak preference over secondary link. Under this configuration, both inbound and outbound packet can survive link failure on either side. Routing information with weak preference will be available as backup, for both inbound and outbound cases. 4. Extensions for IPv6 RFC2260 is written for IPv4 and BGP. With IPv6 and BGP4+, or IPv6 and RIPng, similar result can be achieved, without violating IPv6 addressing/routing rules. 4.1. IPv6 rule conformance In RFC2260, we announce Pref-A toward ISP-BR-A only, and Pref-B toward ISP-BR-B only. Therefore, there will be no extra routing announcement to the outside of the site. This conforms to the aggregation requirement in IPv6 documents. Also, RFC2260 does not require portable addresses. 4.2. Address assignment to the nodes In IPv4, it is usually assumed that a node will be assigned single IPv4 address. Therefore, RFC2260 assumed that addresses from Pref-A will be assigned to nodes near E-BR-A, and vice versa (second bullet in the previous section). With IPv6, a node can be assigned multiple IPv6 addresses. So we can assign (1) one address from Pref-A, (2) one address from Pref-B, or (3) two addresses from both address prefixes, to single node in the site. This will allow more flexibility to nodes in the site. However, this may make source address selection on a node more complex. Source address selection itself is out of scope of the document. Hagino Expires: January 23, 2000 [Page 4] DRAFT IPv6 multihoming support at site exit routers July 1999 4.3. Configuration of links With IPv6, primary link can be IPv6 native connectivity, RFC1933 [Gilligan, 1996] IPv6-over-IPv4 configured tunnel, 6to4 [Carpenter, 1999] IPv6-over-IPv4 encapsulation, or some others. If tunnelling-based connectivity is used in some of primary links, administrators may want to avoid IPv6-over-IPv6 tunnels for secondary links. For example, if: o primary links to ISP-A and ISP-B are RFC1933 IPv6-over-IPv4 tunnels, and o ISP-A, ISP-B and the site have IPv4 connectivity with each other, it makes no sense to configure a secondary link by IPv6-over-IPv6 tunnel, since it will actually be IPv6-over-IPv6-over-IPv4 tunnel. In this case, IPv6-over-IPv4 tunnel should be used for secondary link. This configuration has a big win as secondary link will be able to have the same path MTU than the primary link. 4.4. Using RFC2260 with IPv6 and BGP4+ RFC2260 approach on top of IPv6 will work fine as documented in RFC2260. There will be no extra twists necessary. 4.5. Using RFC2260 with IPv6 and RIPng It is possible to run RFC2260-like configuration with RIPng [Malkin, 1997] , with careful control of metric. Routers in the figure needs to increase RIPng metric on secondary link, to make primary link a preferred path. If we denote the RIPng metric for route announcement, from router R1 toward router R2, as metric(R1, R2), the invariants that must hold are: o metric(E-BR-A, ISP-BR-A) < metric(E-BR-B, ISP-BR-A) o metric(E-BR-B, ISP-BR-B) < metric(E-BR-A, ISP-BR-B) o metric(ISP-BR-A, E-BR-A) < metric(ISP-BR-A, E-BR-B) o metric(ISP-BR-B, E-BR-B) < metric(ISP-BR-B, E-BR-A) Note that smaller metric means stronger route in RIPng. Hagino Expires: January 23, 2000 [Page 5] DRAFT IPv6 multihoming support at site exit routers July 1999 5. Issues with ingress filters in ISP If the upstream ISP imposes ingress filters [Ferguson, 1998] to outbound traffic, story becomes much more complex. A packet with source address taken from Pref-A must go out from ISP-BR-A. Similarly, a packet with source address taken from Pref-B must go out from ISP-BR-B. Since none of the routers in the site network will route packets based on source address, packets can easily be routed to incorrect border router. One possible way is to negotiate with both ISPs, to allow both Pref-B and Pref-A to be used as source address. This approach does not work if upstream ISP of ISP-A imposes ingress filtering. Since there will be multiple levels of ISP on top of ISP-A, it will be hard to understand which upstream ISP imposes the filter. In reality, this problem will be very rare, as ingress filter is not suitable for use in large ISPs where smaller ISPs are connected beneath. Another possibility is to use source-based routing at E-BR-A and E-BR-B. In this case, secondary link needs to be IPv6-over-IPv6 tunnel. When an outbound packet arrives to E-BR-A with source address in Pref-B, E-BR-A will forward it to secondary link (tunnel to ISP-BR-B) based on source- based routing decision. The packet will look like this: o Outer IPv6 header: source = address of E-BR-A in Pref-A, dest = ISP- BR-B o Inner IPv6 header: source = address in Pref-B, dest = final dest Tunneled packet will travel across ISP-BR-A toward ISP-BR-B. The packet can go through ingress filter at ISP-BR-A, since it has outer IPv6 source address in Pref-A. Packet will reach ISP-BR-B and decapsulated before ingress filter is applied. Decapsulated packet can go through ingress filter at ISP-BR-B, since it now has source address in Pref-B (from inner IPv6 header). Notice the following facts when configuring this: o Not every router implements source-based routing. o Interaction of normal routing and source-based routing at E-BR-A (and/or E-BR-B) can be vary by router implementations. o Interaction of tunnel egress and filter rules at ISP-BR-B (and/or ISP-BR-A) can be vary by router implementations and filter configurations. 6. Observations We limited the number of ISPs to 2 in the document, but it can easily be extended to the cases where we have 3 or more upstream ISPs. Hagino Expires: January 23, 2000 [Page 6] DRAFT IPv6 multihoming support at site exit routers July 1999 If you have many upstream providers, you would not make all ISPs backup each other, as it requires O(N^2) tunnels for N ISPs. Rather, it is better to make N/2 pairs of ISPs, and let each pair of ISP backup each other. It is important to pick pairs which are unlikely to be down simultaneously. In this way, number of tunnels will be O(N). Suppose that the site is very large and it has ISP links in very distant locations, such as in US and in Japan. In such case, it is wiser to use this technique only among ISP links in US, and only among ISP links in Japan. If you use this technique between ISP A in US and ISP B in Japan, the secondary link make packets travel very long path, for example, from host in the site in US, to E-BR-B in Japan, to ISP-BR-B (again in Japan), and then to the final destination in US. This may not make sense for actual use, due to excessive delay. Similarly, in a large site, addresses must be assigned to end nodes with great care, to minimize delays due to extra path packets may travel. It may be wiser to avoid assigning an address in a prefix assigned from Japanese ISP, to an end node in US. If one of primary link is down for a long time, administrators may want to control source address selection on end hosts so that secondary link is less likely to be used. This can be achieved by marking unwanted prefix as deprecated. Suppose the primary link toward ISP-A has been down. You will issue router advertisement [Thomson, 1998; Narten, 1998] packets from routers, with preferred lifetime set to 0 in prefix information option for Pref-A. End hosts will consider addresses in Pref-A as deprecated, and will not use any of them as source address for future connections. If an end host in the site makes new connection to outside, the host will use an address in Pref-B as source address, and reply packet to the end host will travel primary link from ISP-BR-B toward E-BR-B. Some of non-goals (such as "best" exit link selection) can be achieved by combining technique described in this document, with some other techniques. One example of the technique would be the source/destination address selection heuristics on the end nodes. 7. Security considerations The configuration described in the document introduces no new security problem. If primary links toward ISP-A and ISP-B have different security characteristics (like encrypted link and non-encrypted link), administrators needs to be careful setting up secondary links tunneled on them. Packets may travel unwanted path, if secondary links are configured without care. Hagino Expires: January 23, 2000 [Page 7] DRAFT IPv6 multihoming support at site exit routers July 1999 References Bates, 1998. T. Bates and Y. Rekhter, "Scalable Support for Multi-homed Multi- provider Connectivity" in RFC2260 (January 1998). ftp://ftp.isi.edu/in- notes/rfc2260.txt. Hinden, 1998. R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. Durand, 1999. A. Durand and B. Buclin, "6Bone Routing Practice" in RFC2546 (March 1999). ftp://ftp.isi.edu/in-notes/rfc2546.txt. Gilligan, 1996. R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers" in RFC1933 (April 1996). ftp://ftp.isi.edu/in- notes/rfc1933.txt. Carpenter, 1999. B. Carpenter and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels" in draft-ietf-ngtrans-6to4-02.txt (June 1999). work in progress material. Malkin, 1997. G. Malkin and R. Minnear, "RIPng for IPv6" in RFC2080 (January 1997). ftp://ftp.isi.edu/in-notes/rfc2080.txt. Ferguson, 1998. P. Ferguson and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing" in RFC2267 (January 1998). ftp://ftp.isi.edu/in-notes/rfc2267.txt. Thomson, 1998. S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration" in RFC2462 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2462.txt. Narten, 1998. T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)" in RFC2461 (December 1998). ftp://ftp.isi.edu/in- notes/rfc2461.txt. Acknowledgements The document was made possible by cooperation from people in ipngwg multihoming design team, people in KAME project and George Tsirtsis. Hagino Expires: January 23, 2000 [Page 8] DRAFT IPv6 multihoming support at site exit routers July 1999 Author's address Jun-ichiro Hagino Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku,Tokyo 101-0054, JAPAN Tel: +81-3-5259-6350 Fax: +81-3-5259-6351 email: itojun@iijlab.net Hagino Expires: January 23, 2000 [Page 9] ------- =_aaaaaaaaaa0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 18:06:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA11497 for ipng-dist; Tue, 27 Jul 1999 18:02:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11490 for ; Tue, 27 Jul 1999 18:02:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA27757 for ; Tue, 27 Jul 1999 18:02:38 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA29146 for ; Tue, 27 Jul 1999 18:02:36 -0700 (PDT) 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 KAA02207; Wed, 28 Jul 1999 10:02:26 +0900 (JST) To: Peter Tattam , ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Wed, 28 Jul 1999 09:50:27 JST. <2047.933123027@coconut.itojun.org> 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: Session Stability (was multi-homing vs route aggregation) From: itojun@iijlab.net Date: Wed, 28 Jul 1999 10:02:26 +0900 Message-ID: <2205.933123746@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>There is another minor but important related issue and that is of suboptimal >>routing for particular prefixes. >>Will this be addressed? > No I do not think so. Source address selection is a separate question > from RFC2260. Oops sorry, I just meant that this must be tackled separately from RFC2260. Some proposals are there, for example. - draft-yamamoto-wide-comm-model (expired) - draft-draves-ipngwg-simple-srcaddr-01.txt 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 Tue Jul 27 18:12:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA11523 for ipng-dist; Tue, 27 Jul 1999 18:10:45 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11516 for ; Tue, 27 Jul 1999 18:10:40 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id SAA01924 for ipng@sunroof.eng.sun.com; Tue, 27 Jul 1999 18:09:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10031 for ; Tue, 27 Jul 1999 06:11:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA14896 for ; Tue, 27 Jul 1999 06:11:57 -0700 (PDT) Received: from mail.uestc.edu.cn (mail.uestc.edu.cn [202.112.14.154]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03042 for ; Tue, 27 Jul 1999 06:11:53 -0700 (PDT) Received: from in2 ([202.115.17.242]) by mail.uestc.edu.cn (Sun Internet Mail Server sims.3.5.1998.08.08.00.06) with SMTP id <0FFJ004NB648W4@mail.uestc.edu.cn> for ipng@sunroof.eng.sun.com; Tue, 27 Jul 1999 21:14:37 +0800 (CST) Date: Tue, 27 Jul 1999 21:10:44 +0800 From: Huang Chun Subject: Could Anyone help me to explain the meaning of "aggregatable" To: ipng@sunroof.eng.sun.com Message-id: <002f01bed831$7263e8e0$f21173ca@in2.osl.uestc.edu.cn> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 4.72.3110.5 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_nB22cMjzIBbbR4s+QZ4o8w)" X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Priority: 3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_nB22cMjzIBbbR4s+QZ4o8w) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi, All, I am a beginer of IPv6 from China and now studying the the IPv6 = Addressing Architecture.=20 In RFC2373, the original Provider-Based Unicast(FP 010) and = Geographic-Based Unicast(FP 100) are replaced by Aggregatable Global = Unicast Adress(FP 001). As far as I think, the "aggregatable" means the = Address Prefix's size is varible on router of different topological = hierarchy. Is what I think correct? Who can give me a clear and complete = explain of the meaning of "aggregatable". And is there a good Chinese = word for this type of address? Thanks! Regards -HuangChun --Boundary_(ID_nB22cMjzIBbbR4s+QZ4o8w) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi, All,
 
I am a beginer of IPv6 from China = and now=20 studying the the IPv6 Addressing Architecture.
 
In RFC2373, the original  = Provider-Based=20 Unicast(FP 010) and  Geographic-Based Unicast(FP 100) are replaced = by=20 Aggregatable Global Unicast Adress(FP 001). As far as I think, the=20 "aggregatable" means the Address Prefix's size is varible on = router of=20 different topological hierarchy. Is what I think correct? Who can give = me a=20 clear and complete explain of the meaning of "aggregatable". = And is=20 there a good Chinese word for this type of address?
 
Thanks!
 
Regards
 
-HuangChun
--Boundary_(ID_nB22cMjzIBbbR4s+QZ4o8w)-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 18:44:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA11595 for ipng-dist; Tue, 27 Jul 1999 18:40:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11588 for ; Tue, 27 Jul 1999 18:40:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA01777 for ; Tue, 27 Jul 1999 18:40:21 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA11677 for ; Tue, 27 Jul 1999 19:40:19 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id LAA09840 for ; Wed, 28 Jul 1999 11:40:18 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Wed, 28 Jul 1999 11:40:18 +1000 (EST) From: Peter Tattam To: IPNG Mailing List Subject: IPv6 work on flow label Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Could someone outline current status of work related to using the flow label. I am interested in exploring some ideas using it. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 18:55:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA11640 for ipng-dist; Tue, 27 Jul 1999 18:51:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11627 for ; Tue, 27 Jul 1999 18:51:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA14401 for ; Tue, 27 Jul 1999 18:51:19 -0700 (PDT) Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA10622 for ; Tue, 27 Jul 1999 18:51:12 -0700 (PDT) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id NAA16018; Wed, 28 Jul 1999 13:50:49 +1200 (NZST) Date: Wed, 28 Jul 1999 13:50:48 +1200 From: Joe Abley To: itojun@iijlab.net Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) Message-ID: <19990728135048.A27833@patho.gen.nz> References: <19990728120216.A24211@patho.gen.nz> <1814.933122248@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <1814.933122248@coconut.itojun.org>; from itojun@iijlab.net on Wed, Jul 28, 1999 at 09:37:28AM +0900 X-Files: the Truth is Out There Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jul 28, 1999 at 09:37:28AM +0900, itojun@iijlab.net wrote: > > > + RFC2260 model, algorithm required for TCP endpoint address selection, > > possible work required on individual platforms to allow the triggered > > "fill-in" subnet advertisements > > RFC2260 does not say so. RFC2260 (section 5.2) tries to let two > ISP links back up each other, by having extra connection > (usually tunnel) between ISP-A router and site router for ISP-B > (and vice versa). > End node need not to do anything special. > This does not require extra (non-aggregatable) routing announcement. My apologies -- I mis-read the RFC (or at least skimmed it over- superficially). This is the section that I remembered: 5.1. Advertising reachability information by enterprise border routers When an enterprise border router connected to a particular ISP determines that the connectivity between the enterprise and the Internet is up through all of its ISPs, the router advertises (to the border router of that ISP) reachability to only the address prefix that the ISP allocated to the enterprise. This way in a steady state routes injected by the enterprise into its ISPs are aggregated by these ISPs, and are not propagated into the "default-free" zone of the Internet. I think the tunnels you refer to are those included in the following section, under the heading of "Further Improvements", which I had either not noticed or had forgotten about: An enterprise border router would maintain EBGP peering not just with the directly connected border router of an ISP, but with the border router(s) in one or more ISPs that have their border routers directly connected to the other border routers within the enterprise. We refer to such peering as "non-direct" EBGP. [...] Forwarding along a route received over non-direct peering should be accomplished via encapsulation [RFC1773]. I see you have forwarded a draft document for how this might apply to IPv6, which is a good thing, I think -- as I believe I have illustrated, there is potentially more than one interpretation of what "RFC2260" can mean with respect to the multi-homing issue. Regards, Joe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 19:11:26 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA11682 for ipng-dist; Tue, 27 Jul 1999 19:07:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11675 for ; Tue, 27 Jul 1999 19:07:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA22763 for ; Tue, 27 Jul 1999 19:07:42 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA14008 for ; Tue, 27 Jul 1999 19:07:42 -0700 (PDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id TAA28200; Tue, 27 Jul 1999 19:07:05 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19990728120216.A24211@patho.gen.nz> References: <379DE443.1AE9CD13@hursley.ibm.com> <19990728120216.A24211@patho.gen.nz> Date: Tue, 27 Jul 1999 19:07:03 -0700 To: Joe Abley From: Steve Deering Subject: Re: Session Stability (was multi-homing vs route aggregation) Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:02 PM +1200 7/28/99, Joe Abley wrote: >Incidentally, are the Oslo minutes published yet? Not yet. Stand by... (I just made an editing pass over them, to convert them from Word to ASCII, and have sent them back to Allison for proofreading. They will be posted as soon as she gives me the OK.) 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 Jul 27 19:17:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA11705 for ipng-dist; Tue, 27 Jul 1999 19:14:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11698 for ; Tue, 27 Jul 1999 19:14:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA03949 for ; Tue, 27 Jul 1999 19:14:13 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA15305 for ; Tue, 27 Jul 1999 19:14:13 -0700 (PDT) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id WAA17489; Tue, 27 Jul 1999 22:14:12 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000008164; Tue, 27 Jul 1999 22:14:12 -0400 (EDT) From: Jim Bound Message-Id: <199907280214.WAA0000008164@quarry.zk3.dec.com> To: Joe Abley cc: itojun@iijlab.net, Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Wed, 28 Jul 1999 13:50:48 +1200." <19990728135048.A27833@patho.gen.nz> Date: Tue, 27 Jul 1999 22:14:11 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >5.1. Advertising reachability information by enterprise border routers > > When an enterprise border router connected to a particular ISP > determines that the connectivity between the enterprise and the > Internet is up through all of its ISPs, the router advertises (to the > border router of that ISP) reachability to only the address prefix > that the ISP allocated to the enterprise. This way in a steady state > routes injected by the enterprise into its ISPs are aggregated by > these ISPs, and are not propagated into the "default-free" zone of > the Internet. > >I think the tunnels you refer to are those included in the following >section, under the heading of "Further Improvements", which I had >either not noticed or had forgotten about: > An enterprise border router would maintain EBGP peering not just with > the directly connected border router of an ISP, but with the border > router(s) in one or more ISPs that have their border routers directly > connected to the other border routers within the enterprise. We > refer to such peering as "non-direct" EBGP. >[...] > > Forwarding along a route received over non-direct peering should be > accomplished via encapsulation [RFC1773]. In my mail today earlier I stated I thought 2260 could help too but at added cost. I feel the first one above will not fly here because it breakes aggregation of IPv6 model. The second one will work but you have to have another connection to the other ISP and they diagram that in 2260. But if want to be multihomed and use both it costs more and that seems natural to a capitalist like me. /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 Tue Jul 27 19:33:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA11727 for ipng-dist; Tue, 27 Jul 1999 19:24:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11720 for ; Tue, 27 Jul 1999 19:24:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA04732 for ; Tue, 27 Jul 1999 19:24:24 -0700 (PDT) Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA19843 for ; Tue, 27 Jul 1999 20:24:21 -0600 (MDT) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id OAA01027; Wed, 28 Jul 1999 14:24:04 +1200 (NZST) Date: Wed, 28 Jul 1999 14:24:04 +1200 From: Joe Abley To: itojun@iijlab.net Cc: Peter Tattam , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) Message-ID: <19990728142403.A7869@patho.gen.nz> References: <2047.933123027@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <2047.933123027@coconut.itojun.org>; from itojun@iijlab.net on Wed, Jul 28, 1999 at 09:50:27AM +0900 X-Files: the Truth is Out There Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, On Wed, Jul 28, 1999 at 09:50:27AM +0900, itojun@iijlab.net wrote: > > Internet Engineering Task Force Jun-ichiro Hagino > INTERNET-DRAFT Research Lab, IIJ > Expires: January 23, 2000 July 23, 1999 > > > IPv6 multihoming support at site exit routers > draft-itojun-ipv6-2260-00.txt This draft clarifies the aspects of RFC2260 which you mentioned in an IPv6 context considerably. However, I am not convinced that this approach fully addresses the issue at hand. Under your proposal, host renumbering is avoided for the specific failure mode where a multi-homed site suffers a single circuit failure to one of its ISPs. In my experience, multi-homing with IPv4 is rarely a simple affair (especially when the customer multi-homing does not meet the criteria to warrant a nice large address prefix, and are using something only marginally acceptable in the core like a /24). For this reason, customers who are concerned about circuit failure between their network and their ISP generally obtain multiple circuits to the same ISP. This avoids the route aggregation problems, and gives them all the protection they require. It's also usually cheaper than buying separate service from a second ISP. We call this "multi- attaching" rather than multi-homing, but that's just us. Customers who go to the trouble of multi-homing typically do so because they are worried about the stability of _transit_ through a single ISP. For example, we are multi-homed (currently) to Concentric Networks and Telstra -- both organisations provide us with global transit. This has saved our bacon in the past when one of those providers has suffered an outage which left us connected, but broke the transit (in the example that springs to mind, we were left with excellent connectivity to one Concentric POP and nothing to the rest of their network). I'm not making a point about Concentric in particular, by the way -- they were bitten by a nasty fault, and they have since eliminated the single point of failure in their usual efficient manner. However, the point is that transit failures _do_ happen, regardless of how robust a single provider engineers their network. Under your draft, a failure of this kind would still require renumbering at the edge of the network, and special treatment for established sessions (if they were to persist, which I would suggest probably ought to be documented as a requirement). As I mentioned earlier, when I read rfc2260 my attention was drawn to section 5.1, which I think addresses this exact issue: it attempts to ensure that the purity is maintained in the default-free zone in the absense of failures, but can be sacrificed in the interests of connectivity during failures only. I'm not naive enough to believe that 2260, as it stands, is without operational concerns. However, I believe the framework in 5.1 addresses a more relevant operational concern than that in 5.2. Regards, Joe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 20:04:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA11775 for ipng-dist; Tue, 27 Jul 1999 20:01:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11768 for ; Tue, 27 Jul 1999 20:01:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA07656 for ; Tue, 27 Jul 1999 20:01:21 -0700 (PDT) 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 VAA27277 for ; Tue, 27 Jul 1999 21:01:20 -0600 (MDT) 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 MAA04256; Wed, 28 Jul 1999 12:01:03 +0900 (JST) To: Joe Abley cc: ipng@sunroof.eng.sun.com In-reply-to: jabley's message of Wed, 28 Jul 1999 14:24:04 +1200. <19990728142403.A7869@patho.gen.nz> 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: Session Stability (was multi-homing vs route aggregation) From: itojun@iijlab.net Date: Wed, 28 Jul 1999 12:01:03 +0900 Message-ID: <4254.933130863@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >In my experience, multi-homing with IPv4 is rarely a simple affair >(especially when the customer multi-homing does not meet the criteria >to warrant a nice large address prefix, and are using something only >marginally acceptable in the core like a /24). I agree, I believe the word "multi-homing" has several aspects in it. >Customers who go to the trouble of multi-homing typically do so because >they are worried about the stability of _transit_ through a single ISP. > >For example, we are multi-homed (currently) to Concentric Networks and >Telstra -- both organisations provide us with global transit. This has >saved our bacon in the past when one of those providers has suffered >an outage which left us connected, but broke the transit (in the >example that springs to mind, we were left with excellent connectivity >to one Concentric POP and nothing to the rest of their network). Just curious, how did you solve this case for IPv4? You had AS number and Concentric (or ISP-A) announced your route properly so you were saved? >Under your draft, a failure of this kind would still require >renumbering at the edge of the network, and special treatment for >established sessions (if they were to persist, which I would suggest >probably ought to be documented as a requirement). For newly established sessions a sentence in Observation section may help (setting preferred lifetime of unreachable prefix to 0). The draft gives few help about session stability (make connected tcp session survive failures). As Abstract section says, this is very basic support and is waiting for more sophisticated (complex) mechanisms on top of it. I believe we need a session layer for it if we try to design it properly, this is not the job for layer 3 :-) >I'm not naive enough to believe that 2260, as it stands, is without >operational concerns. However, I believe the framework in 5.1 addresses >a more relevant operational concern than that in 5.2. Section 5.1 is, I believe, not acceptable for IPv6 for aggregation concerns. 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 Tue Jul 27 20:11:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA11797 for ipng-dist; Tue, 27 Jul 1999 20:10:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11790 for ; Tue, 27 Jul 1999 20:09:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA08278 for ; Tue, 27 Jul 1999 20:09:52 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA29153 for ; Tue, 27 Jul 1999 21:09:51 -0600 (MDT) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id XAA28031; Tue, 27 Jul 1999 23:09:50 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000016560; Tue, 27 Jul 1999 23:09:50 -0400 (EDT) From: Jim Bound Message-Id: <199907280309.XAA0000016560@quarry.zk3.dec.com> To: Peter Tattam cc: IPNG Mailing List Subject: Re: IPv6 work on flow label In-reply-to: Your message of "Wed, 28 Jul 1999 11:40:18 +1000." Date: Tue, 27 Jul 1999 23:09:50 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Peter, >Could someone outline current status of work related to using the flow label. >I am interested in exploring some ideas using it. We use it for RSVP IPv6 and RAPI (api for rsvp). Its also part of the kernel implementation. See RSVP 2205 and http://www.ietf.org/html.charters/rsvp-charter.html and the applicability statements to RSVP. Also see diff serve specs talking about integrating diff srv and rsvp (I have not looked at the very latest here just yet but its on my list). It saves a lookup and additional state with IPv6 than IPv4 as the flowspec is in the header. If we can get a couple of IPv6 rsvp implementations up and running we can test them at UNH interoperability test events too. I don't know of any experiments yet? But I think we need some and I think once the diff srv / integrated services / rsvp parts settle down I think there are some experiments to have in there. But if you want to use it at your own risk it could be used on an Intranet and used by a private application. Though Ipv6 does not improve QOS or make it possible (directly) which is the wrong message, it does have enabling functions and potentials being a new protocol to make QOS more efficient from an implementation view and its also inherent to sockaddr_in6 data structure. But I will go there another day as I am working on slides/paper of why IPv6 enables QOS. Also QOS means different things to different folks and business issues I have found out over the last year. Would like to hear your ideas for sure here or privately. /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 Tue Jul 27 21:18:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA11841 for ipng-dist; Tue, 27 Jul 1999 21:15:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA11834 for ; Tue, 27 Jul 1999 21:15:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA00832 for ; Tue, 27 Jul 1999 21:15:06 -0700 (PDT) Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA11392 for ; Tue, 27 Jul 1999 22:15:03 -0600 (MDT) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id QAA29988; Wed, 28 Jul 1999 16:14:51 +1200 (NZST) Date: Wed, 28 Jul 1999 16:14:51 +1200 From: Joe Abley To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) Message-ID: <19990728161450.A23265@patho.gen.nz> References: <19990728142403.A7869@patho.gen.nz> <4254.933130863@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <4254.933130863@coconut.itojun.org>; from itojun@iijlab.net on Wed, Jul 28, 1999 at 12:01:03PM +0900 X-Files: the Truth is Out There Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jul 28, 1999 at 12:01:03PM +0900, itojun@iijlab.net wrote: > >For example, we are multi-homed (currently) to Concentric Networks and > >Telstra -- both organisations provide us with global transit. This has > >saved our bacon in the past when one of those providers has suffered > >an outage which left us connected, but broke the transit (in the > >example that springs to mind, we were left with excellent connectivity > >to one Concentric POP and nothing to the rest of their network). > > Just curious, how did you solve this case for IPv4? You had AS number > and Concentric (or ISP-A) announced your route properly so you were > saved? Correct. Telstra's advertisement of our route (which is normally "far away" from most of the internet) became the most available prefix, and hence traffic flowed in that direction. > >I'm not naive enough to believe that 2260, as it stands, is without > >operational concerns. However, I believe the framework in 5.1 addresses > >a more relevant operational concern than that in 5.2. > > Section 5.1 is, I believe, not acceptable for IPv6 for aggregation > concerns. I don't think any of the approaches I've seen so far address all concerns. I presume we are looking for a compromise. Joe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 22:38:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA11894 for ipng-dist; Tue, 27 Jul 1999 22:31:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11887 for ; Tue, 27 Jul 1999 22:31:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA27234 for ; Tue, 27 Jul 1999 22:31:11 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA23669 for ; Tue, 27 Jul 1999 23:31:10 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id PAA25754 for ; Wed, 28 Jul 1999 15:31:08 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Wed, 28 Jul 1999 15:31:08 +1000 (EST) From: Peter Tattam To: IPNG Mailing List Subject: Stats on IPv4 DFZ, info on router limitations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Could someone post here for relevance some useful stats on what is the current size of the IPv4 DFZ and quantiles on stability, or at least point me to the right place. Important would be to have a breakdown on the number of networks of all prefix lens. For stability, I guess it would depend on the point where measurements are taken, and relative percentage of primary routes vs secondary routes. Also, what was the definitive answer on what constitute the major bottleneck for large DFZs in router design. Was it memory or CPU, (or other)? Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 28 01:37:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA12045 for ipng-dist; Wed, 28 Jul 1999 01:34:23 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12038 for ; Wed, 28 Jul 1999 01:34:14 -0700 (PDT) From: george.tsirtsis@bt.com Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA15266 for ; Wed, 28 Jul 1999 01:34:15 -0700 (PDT) Received: from babelbrox.axion.bt.co.uk (babelbrox.axion.bt.co.uk [132.146.16.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA29328 for ; Wed, 28 Jul 1999 01:34:13 -0700 (PDT) Received: from cbtlipnt02.btlabs.bt.co.uk by babelbrox.axion.bt.co.uk (local) with ESMTP; Wed, 28 Jul 1999 09:33:38 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id ; Wed, 28 Jul 1999 09:33:34 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2F4E626@mbtlipnt02.btlabs.bt.co.uk> To: ipng@sunroof.eng.sun.com Cc: jabley@patho.gen.nz, itojun@iijlab.net Subject: RE: Session Stability (was multi-homing vs route aggregation) Date: Wed, 28 Jul 1999 09:33:20 +0100 X-Mailer: Internet Mail Service (5.5.2448.0) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: itojun@iijlab.net [SMTP:itojun@iijlab.net] > Sent: Wednesday, July 28, 1999 4:01 AM > To: Joe Abley > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Session Stability (was multi-homing vs route > aggregation) > .... > >Under your draft, a failure of this kind would still require > >renumbering at the edge of the network, and special treatment for > >established sessions (if they were to persist, which I would suggest > >probably ought to be documented as a requirement). > > For newly established sessions a sentence in Observation section > may help (setting preferred lifetime of unreachable prefix to 0). > > This part of the draft is a VERY condense version of a longer discussion I had with Itojun offline about **combining RFC2260 with Router Renumbering (RR)**. I do not think that addresses Joe's concern but read on to see what it can do for you. Here is summary of the discussion: With RFC2260 technique alone when one of the links fails (say ISP-BR-B <-> E-BR-A) all incoming traffic from ISP-B will go through the secondary path (tunnel) ISP-BR-B -> ISP-BR-A -> E-BR-A. Now for existing TCP connections this is fair enough and better than loosing the connection altogether. For NEW connections, however, it would be better to avoid using source address from prefix ISP-B and thus avoid tunnelling on the way back. RR could deprecate prefix ISP-B and make preferred prefix ISP-A for all new connections. This way all new connection would go through ISP-A and not through the tunnel. I passed this through Matt Crawford and at least in principle he considered the use of RR for deprecating prefixes reasonable as long as one plays with preferred lifetimes and not valid lifetimes. Now this only makes sense if the link to ISP-B goes done for some time and not just few seconds since this could create a bit of a problem? Matt seamed reasonably happy that this could be done successfully but we can get into details latter Another (probably *extreme* and I only put it here to check possibilities!) use of RR would be the following: Say the RFC2260 scheme is *not* possible (because ISPs do not cooperate or whatever). One could think of using RR ONLY (without tunnels) to go some way towards dealing with the problem of link failure. (ISP A) (ISP B) ISP-BR-A ISP-BR-B | | |Primary link | | | +---|-----------------------------|--+ | E-BR-A E-BR-B | | | | Pref-A <----------> Pref-B | +------------------------------------+ To take the example in Itojun's draft say we have the above connectivity. Also say that all hosts make addresses out of both prefixes ISP-A and ISP-B. Normally they choose source address based on 'normal' address selection mechanisms. Say that link to/from ISP-B breaks. All existing connections using source address with prefix ISP-B will not have return path anymore. E-BR-B initiates RR cycle deprecating prefix ISP-B. Source address selection rules take this into account and thus, all new connections use source address with prefix ISP-A. If the link to ISP-A also fails, E-BR-A deprecates prefix ISP-A and thus, all new connections can only use site local addresses and they are not loosing their time trying to communicate outside the site. Again this is probably very extreme us of RR and will result in loss of existing connections. As an aside: I am not an expert in RR but here is how one can deprecate a prefix using it if say the link to ISP-B (with Prefix B) goes down. IPv6 Header Next Header = 58 (ICMPv6) Source Address = (Management Station) Destination Address = FF05::2 (All Routers, site-local scope) ICMPv6/RR Header Type = 138 (Router Renumbering), Code = 0 (Command) Flags = 60 hex (R, A) First (and only) PCO: Match-Prefix Part OpCode = 2 (CHANGE) OpLength = 7 (reflects 1 Use-Prefix Parts - 2N+3) Ordinal = 0 (arbitrary) MatchLen = 48 MatchPrefix = Pref-B/48 prefix First Use-Prefix Part UseLen = 0 KeepLen = 64 (this retains the old prefix value intact) FlagMask = 0 (copy RA flags from previous) , RAFlags = 0 (initialise L&A flags in RA) Valid Lifetime = 7200 seconds (2 hours) Preferred Lifetime = 0 seconds <------Deprecation! V flag = 1, P flag = 1 UsePrefix = 0::0 George -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 28 06:40:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA12180 for ipng-dist; Wed, 28 Jul 1999 06:36:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12173 for ; Wed, 28 Jul 1999 06:36:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA09077 for ; Wed, 28 Jul 1999 06:36:09 -0700 (PDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA05593 for ; Wed, 28 Jul 1999 06:36:08 -0700 (PDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id JAA15805; Wed, 28 Jul 1999 09:36:02 -0400 (EDT) Message-Id: <199907281336.JAA15805@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Peter Tattam cc: IPNG Mailing List Subject: Re: IPv6 work on flow label In-reply-to: Your message of "Wed, 28 Jul 1999 11:40:18 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Jul 1999 09:36:01 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Could someone outline current status of work related to using the flow label. > I am interested in exploring some ideas using it. See draft-berson-rsvp-ipv6-fl-00.txt (.ps) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)468-8466 x232 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 28 07:40:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA12249 for ipng-dist; Wed, 28 Jul 1999 07:37:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12242 for ; Wed, 28 Jul 1999 07:36:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA25042 for ; Wed, 28 Jul 1999 07:36:51 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27301 for ; Wed, 28 Jul 1999 07:36:51 -0700 (PDT) Received: from [171.68.180.112] (sj-dial-3-111.cisco.com [171.68.180.112]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA23283; Wed, 28 Jul 1999 07:35:18 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: Date: Wed, 28 Jul 1999 07:35:13 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: draft minutes from IPng WG meetings in Oslo Cc: Bob Hinden Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here are the draft minutes from the Oslo meetings; please send any corrections to Bob Hinden and me. Many thanks to Allison for such fine notes -- reading them almost made up for not being able to attend in person! Steve -------- Minutes of the meetings of the IPng Working Group in Oslo, July 1999 Meetings chaired by Bob Hinden Minutes recorded by Allison Mankin Wednesday, July 14 I. Agenda Bashing It was reiterated that Steve Deering was unable to attend Oslo because of a family emergency. Dave Johnson announced that the mobile-ipv6 draft was resubmitted just before meeting, and it is very close to final, but still needs to have added clarification about IPSEC. No major agenda item about it in this IETF's meetings, but attendees invited to comment on IPSEC there if needed, or else via the email list. II. Document Status - Bob Hinden, RFC: Basic API published as RFC2553. Approved for PS by IESG: Jumbograms. IETF Last Call completed for DS: Addressing Architecture and Aggregatable Global Unicast - the IESG needs reports of experience with scoped multicast forwarding and there is IESG concern about how to standardize architecture docs. Does DS need to wait until a large enough deployment has occurred to indicate how scalable the addresses are? During IETF week, there are some offline discussions related to the 8+8 decision; the IAB workshop on the Network Layer recommended talking about it. IETF Last Call completed for PS: Router Renumbering is back at IESG, and they are not waiting for a revision. DNS extensions - dependent docs have been approved, but the draft is waiting for revisions covering how to handle resolver behavior during the AAAA/A6 transition - an update is on today's agenda. Multicast Listener Discovery is ready for IESG ballot. Submitted to IESG for PS: Router Alert - WG last call finished without comments today, so it will be sent to IESG now. Submitted to IESG for Informational: The GSE analysis was at the IESG for a long time. About two weeks ago, the authors received a security review from Steve Bellovin, requested by the IESG. Steve, the authors, some ADs, and Bob Hinden were to meet during Oslo to discuss the review, and there will probably be a document revision. WG Last Call completed for Informational: The initial sub-TLA assignments draft was never submitted to IESG because preliminary discussions with the IANA and registry people suggested we wait for action by them. Their action has happened: there will be an announcement at the plenary tonight that the IANA has delegated the first allotments of sub-TLA space to the three registries. A Method for Flexible Assignment - This draft is close to be ready for submission, but the author has been asked to revise it some to provide more context. The Case for IPv6 - Some comments are being forwarded to the authors. Note that this document will be sent to IESG as an IAB doc, not IPNGWG. III. Updates - Matt Crawford, FNAL DNS Lookups: IETF Last Call was issued 14 June. Remaining issue is specification of resolver behavior during the aaaa to a6 transition - the straw man proposal for this had very light discussion on the mailing list. ICMP Name Lookups: Near ready for WG Last Call - one known issue is that the lookup request hashes the name using a CRC32, noting that this should be fine because it is not a hash for security purposes. Some people have asked that it use an IPSEC hash instead, simply because IPSEC hashes already have been implemented in stack and will not entail extra code. Matt noted finally that there has been no complaint about the draft's specified multicast address. Other: There are potential interactions between Router Renumbering and mobility: for instance, if you set or clear the R flag in the router advertisement. Question is how to minimize the coupling of the two documents so as not to delay the standards track progress of either one. Hinden commented that RR was further along than IPv6 Mobility, so perhaps the right thing would be for the latter to reference the former. Hinden took an action to ask Thomas Narten for an AD opinion on this, since Thomas was not in the room at that point. There are similar interactions between RR and the site-prefixes draft. Questions: Itojun asked when A6 will be implemented. Answer: Bind 9 will have it. The last word Matt had was that its ETA is the coming fall, but Matt got that update 3 months ago. IV. CSI - Hiroshi Kitamura, NEC The Secretariat republished the original draft as 01 instead of using the updated text. This presentation is an update from his presentation at last IETF. Connection/Link Status Investigation (CSI) is a traceroute or pathchar type mechanism using one new HBH option and three new ICMPv6 messages - - CSI HBH option - ICMPv6 Status Request/Status Reply/Status Report The basic mechanism is to send a message with a pre-allocated space for each hop to record the requested information in. Scalability of this space is handled by having a node which fills the remaining space send a Status Report back and forward on the Request with the original space now cleared for new information. The CSI option may be disabled by nodes and then they mark a bitmap with 0 in the position of the skipped node. This mechanism is limited to 24 hops. A change between the 00 and 01drafts was to eliminate the version field, and plan on using a new investigation type code when going to a new version of a particular investigation type. Issues include: which address to record from among all assigned to an interface. The proposal would be to use rules like those for source address selection, keyed to the destination address in the ICMPv6 header. To economize on the space, there is a mechanism for IP address compression - in a large scale net: record upper part, small scale net: lower part. The speaker did not address how you would determine and specify which compression mode to use. The speaker stated why CSI can be said to be simple to implement: none of the envisioned investigation type responses have to be rapidly processed in the routers and they do not require intelligence or complexity there - the model is that the data is collected by the requester and analyzed offline. The speaker has implemented a tool called tracestatus, and suggests it can replace ping and traceroute. The code may be released soon. Comments - Comment: It's less simple than traceroute, which requires nothing on routers. It is also not true that you can simplify by saying no security considerations enter into it. Answer: there are security considerations in draft 01. Answering about traceroute: if the function had been seen as necessary early on in the IPv4 development, then maybe the IPv4 designers would have chosen to create something like CSI, but IPv4 option problems ruled out that thinking later. Crawford: Note that timestamp definitions within the draft are inconsistent. Asks if it is necessary that this be ICMP? Suggests that the option field might also need to include a Router Alert. Can routers disable some types of data but allow others? Answer - that can be set as a policy but as currently specified, the replies cannot tell the requester about the specifics. Durand asks if this is a working group item - Hinden says not sure if WG supports. Similar 1997 proposal by Durand and others did not have working group support. Preference by Hinden now is keep as individual submission until work is more mature. If people disagree with that, say something now. Author is asked to label next draft as individual submission, not draft-ipngwg-hbh-etc.. Haskins - this might belong in operations area. V. UDP-Lite - Lars-Ake Larzon , Lulea University The presentation proposed a small change to UDP aimed at realtime applications in error-prone environments. IP in cellular nets experiences errors and delay, and there is an increasing interest in the use of error-tolerant codecs to get tolerable performance for realtime flows. For this, the IP/UDP checksumming is not optimal - UDP will drop damaged packets which the error-tolerant codecs delivered as damaged but usable. And, of course, disabling the UDP checksum with a zero value as in IPv4 is not permitted for IPv6. Transport layer properties wanted for the realtime applications over cell - low complexity for low protocol overhead, checksum coverage of just the protocol headers, allowance of delivery of damaged frames. Proposed solution: UDP's packet length field is redundant because the IP header has it too - so replace it with a field called Checksum Coverage that specifies how much of packet from the beginning of the UDP header should be covered by the checksum. If checksum coverage is less than packet length then that remaining part of packet will not be checksummed. Examples: - Voice over IP (VoIP) using IP/UDP/RTP - cover only headers - VoIP with compressed RTP - with checksum covering only the headers, they have measured that there are 40% fewer context synchronization losses and TWICE will succeed more often. More details on this will be presented to the AVT WG on Thursday. - 64 kbps PCM audio over cellular - normally cellular would not be used for this voice encoding because of its too limited bandwidth. However, there are tests of using it and recovering from the extensive packet losses. More packets get through when UDP-Lite is used; a clicking sound occurs from the losses, which the application can filter out. One of the arguments for standardizing on UDP-Lite is low deployment cost, because it can look exactly like regular UDP by simply having the full length in the Coverage Field. It could be deployed as a separate protocol parallel to UDP, but the speaker asks consideration for replacing UDP in IPv6 with UDP-Lite, since there has been limited deployment to date. Comments: Hinden: First thought is that UDP is usually considered in transport area. On the other hand, IPNGWG has changed the checksum of TCP/UDP so it's probably OK to consider UDP-Lite here. Comment: Doesn't this conflict with having underlying protocols that are checksummed themselves, like PPP radio? Answer: link protocols for IP over cellular are not settled yet, and there is ongoing work on link layers that deliver the damaged frames. Draves: how does an application ask for less coverage? Answer: the default behavior is to look like ordinary UDP, and in their implementation, the application uses a socket option to set lesser coverage. Comment: this WG made UDP unsafe for the applications described by requiring the checksum, unlike IPv4, so it is our responsibility to fix the problem. The commenter also agrees that the data link layers haven't been fully defined for newer digital cellular such as UMTS. Crawford: Though new transport doesn't necessarily belong here, this WG also has worked on jumbograms, and note this would interact with jumbograms. Hinden: note a new comment on checksum limitations for very large datagrams that the IESG had the authors to that draft. Speaker: we think being able to specify coverage only as far as 64K would be OK, but also, the semantic of zero in the Coverage field, meaning the entire packet is covered, means you can request coverage of the whole jumbogram. Hinden took an action to talk to the ADs. He'd lean to making a separate UDP because there have already been investments in UDP as is. Another of the authors of UDP-Lite added as a last word that the changes to UDP are 2 lines of code. VI. TAHI Project: IPv6 Code Verification - Nobuo Okaba, Yokagawa Electric Corp. The TAHI project was started in 1998, funded by the Japanese government. Its objectives are conformance and interoperability tests for IPv6, to be made publicly available. The current coverage is 106 tests for hosts, taking about 6 hours to complete, and 56 for routers taking about 3.5 hours. Unattended operation works fine. Among tests of basic function still to be done are: RS/RA functions of the router and Redirect. The implementations that have been tested so far are Hitachi NR60, various versions of KAME, and some NEC prototype host code. The development plan is to complete the basic spec by 8/99, ICMPv6 by 10/99, IPSEC by 12/99, v6/v4 Tunnel by 12/99, Address Architecture by 12/99. Testing on the ipv6-unified kernel will be started next month. Test package releases are planned every two months. Results for both KAME and ipv6-unified will be published. Both the test spec and testing code will be published. Plan an interop event in October in Japan. Begin checking the TAHI web site for these various developments in August 1999 - www.tahi.org Itojun: Can you describe how TAHI is distinguished from UNH. Answer: a major difference is that all the test programs will be openly available, as will test results such as the ipv6-unified. Dave Johnson: When will TAHI make tests for mobile IPv6. Answer: sometime in 2000. Dave: January looks open. A demo in the IETF laptop room was available by arrangement. Code to be tested is welcome. One can get in touch using contact@tahi.org or nobuo_okabe@yokogawa.co.jp. Question: are the tests hand-coded in C or using a specification language? Answer: in C. VII. IPv6 in GSM-like Infrastructure - Hossam Afifi, INRIA Sophia The hypothesis of this presentation was that the IP over cell phone standards currently being developed for GSM and its successors could fail to be deployed because of complexity, and, in that circumstance, an IPv6 stack for current GSM could become a viable standard. IPv6 can provide improvement and simplification of GSM networking . Draft-afifi-sixtel-00.txt, by the speaker, Jim Bound and Laurent Toutain is the basis of the talk. GSM has a few 100 million users today - both voice and data modems. It is a success story like the Internet. There is a standard for data transfer over wireless, GPRS, which is viewed as an extension to GSM. Hypothesis is that it is not successful like GSM. It is currently standardized by not deployed. UMTS (3GPP) and IMT2000, representing the next generation, are not yet standardized. There are two kinds of mobility in GSM, from cell to cell within one switch (MSC) and between MSCs. The Home Database is with your home MSC, and the Visitor Database is updated when you change MSC. The GSM functions are in a Call Management layer, Mobility Management layer, and Radio Resource layer. GPRS does not use this architecture, but has a different fixed database structure. You can have equipment that is GSM only, GPRS only, or both. GPRS has many complex services, including a reliable multicast. Frame Relay is used between base stations and the databases. A slide showed GPRS as having complex protocol stacks in the database (SGSN) and base stations. A simple way to add IPv6 to cell telephony is just to use Francis Dupont's IPv6-supporting device driver for GSM modems. The accepted view is that IPv6 should be added to the GPRS protocol architecture, but since GPRS is not deployed and is such a mess, the suggestion is to bypass it and architect just for GSM. The draft covers what was proposed in more detail. Highlights: - Place an IPv6 Router over an adaptation layer over the stack in the MSC. - Design the needed adaptation layer in IETF, and go to ETSI to suggest changes as needed to Call Management and Mobility Management. - The architecture would be one MSC/subnet. - Some needed additions are header compression and mux/demux. - Use IPv6 mobility for the inter-MSC mobility. - Have DHCPv6 give the address to a phone on turn-on and add IPSEC to the Call Management layer. - Have DHCPv6 and IPv6 interact on the move to a new MSC, with support for this in Mobility Management The speaker concluded suggesting a poll of whether this proposal is useful, whether to work on it in the WG, and if there would be concurrence about the work suggested to be done in ETSI. Comments - Eklund, Ericsson: Much of what they would do is already part of GPRS. For instance, it already includes the ability to choose IPv6 instead of IPv4. The suggestions represent misunderstanding of GPRS. Eklund's opinion is that no operator would adopt this scheme. Answer: an operator Afifi is working with is unhappy with the prospective performance of GPRS and its complex stack and has expressed interest in bypassing GPRS. Eklund - the cost of building an alternative means that all operators are going to use GPRS. I Hakkunen, Nokia: Also thinks the authors misunderstand what is happening in GPRS. GPRS is complex because it needs to be. The end result of the suggested use of GSM would be as complex as GPRS because it would have to be. Answer: GSM is deployed today. What is the guarantee that GPRS will be deployed? Hakkunen: Cannot speak officially, but there is very high pressure for GPRS deployment, and thinks it will be deployed. Tsirtis, BT: This is for a good cause, but you could spend a lot of time trying to get ETSI to change existing standards, or work in the early days of something that isn't hard and fast yet, and the latter would be more effective. So IETF should even go beyond GPRS and be longer term. Suggestion is to go to UMTS [???he may have said DMTS] instead. Comment: About the poor performance of GPRS, in normal GSM traffic, the occasional free slots in the TDM timeslotting scheme are retrofitted for GPRS. It performs so badly, because there is little allocation for it yet. Answer: Another reason why GPRS isn't attractive for the IPv6 over cell. Hakkunen: Some people are proposing the GPRS stack for UMTS. If IETF could convince UMTS people to use this solution instead, this would be most effective. Hinden: When I first saw the GPRS stack, I saw it as too complex too. However, it is not certain that this WG can have this work in its charter. Rather, it seems appropriate to ask the Internet ADs about looking at the whole IP over cellular media topic. Hinden took an action to bring it up to the Internet ADs. Perkins: Timing matters. Make a working group item related to this now would make it more real. Hinden: It's too late to affect GPRS. Hinden: Suggests this draft remain an individual submission. VIII. Preferred Format for Literal IPv6 Addresses in URLs - Hinden The major goal of the format is to make cut and paste of IPv6 literal addresses into browsers easy. The draft is browser focused - there are URLs in a lot of places and it is hard to fix parsing software everywhere. In the draft in its 01 version, the format is to enclose the literal address in square brackets. There have been implementations demonstrating feasibility in MS IE, Mozilla, and Lynx - these are not production implementations, but their coverage is good. Hinden would like to start WG Last Call for this to go to PS, continuing to omit the issue of literal support for non-browser uses of URL. But it is noted that the IPv6 service location protocol drafters may be able to use this too. Itojun: Is it legal to have a square bracket around a regular URL with FQDN? His implementation accepts finding square brackets there. Answer: We shouldn't require that it do. Draves: MSRIPv6 IE also accepts square brackets around the FQDN as an implementation byproduct. Comment: Every example has an explicit :80, why? Answer: This was just to show there would be no problem between the address use of ':' and the port use of ':'. Examples without the port will be included too. Itojun: please show examples with 3ffe in lower case, not only upper. Perkins: Service location protocol for IPv6 is done and is just waiting for this format to get settled. They will reference the draft. Narten: SLPv6 is not quite ready, because they need to include rules about server source address use when multihomed - these should be reviewed by IPNGWG. In fact, SLPv6 should become an IPNGWG document, because the SLP working group is trying to shut down. IX. Privacy Extensions for Stateless Address Autoconfiguration - Narten, IBM The constancy of the Interface ID could (in some cases) be used for tracking individuals, for instance when the device stays with the user, like a PDA. A server could tell when you were at home, office, travelling, based on the changing prefixes. The proposed extension for privacy is optional because it is not a concern for everyone. In particular, servers already have a permanent DNS name, so that is already an identifier for them. Also, many are used to having a stable IPv4 address, for instance because the DHCP spec encourages giving the same address. Finally, sites may want to be able to track use easily, and having nodes be able to become anonymous would be viewed as a cost to them. Solution requirements: - Interface identifier must change over time. - It does not need to be cryptographically random, just unpredictable to an outside observer. If there is stable storage, the draft provides an algorithm for creating a new IID, otherwise it is to be pseudo-randomly generated. The algorithm briefly is to append the IID to a 64-bit history value, compute the MD5 message digest, take the first 64 bits for the temporary IID, use the temporary as the next history value. Issues - How frequently to recommend changing? The initial approach is at each restart (system reboot). An assumption is that this is a client-only solution. A device that's both a server and a client may want to use the constant IID for server use and this stuff for its client communications. Then one has to get into source address selection issues. Should this be specified as for use in global addresses? Collision avoidance - in autoconfiguration now, DAD halts the process when a duplicate is discovered. But for privacy IID selection purposes, there should be a retry mechanism. Is it reasonable to assume that the IEEE identifier will remain private to node? If it is known already, the generation algorithm may be predictable. An observer on the same link will certainly know it. (Comment by someone: this is not for privacy on the same link). The alternative is not to use the constant IID as a seed. Avoiding using it is easy, assuming that systems can be expected to generate a pseudo-random number reasonably well. Comments - Crawford: Let people choose their own threat model and decide for themselves how often to take a dose of this privacy drug. On the other hand, when restart-based model is not used, some more problems arise: on changing IID without a restart, the system has to track addresses in use already, in open connections, and unlike prefix-changing, it does not get external cues (router advertisements) to start doing so. Perkins: Wonders why it is believed that the history list is simpler than trying to do a new random number each time. No need to overspecify: a default method for generating the privacy IID is not needed for interoperation. Also, with respect to the analogy to prefix-changing, note that address lifetimes are upper bounds - the system is free to stop using some prefix when it wants to. Answer: It may be hard to track upper layer users of addresses with the defunct IID, especially UDP. Afifi: For this to work, DHCP servers would need modifications, because clients are identified by their MAC addresses. Answer: If you are using DHCP, you have to generate a normal link-layer address, not use an anonymized one. Nordmark: Is it a privacy concern that DHCP servers know the constant IIDs of systems? Answer: DHCP is supposed to be trusted. Hinden: You may not trust a DHCP server you are visiting. Hinden: The draft will need revision. Narten: Could the WG comment on whether the simple first cut in the draft is enough. Draves: Would like to see it include reboot-less change that can be done more frequently. Others nod. Question: Who will get to use the IID when a duplicate is found? Answer: The original owner. Unlike with ARP, there is no problem that the cache could be corrupted. Question: But if it's a duplicate of a system that is temporarily down, especially of a server that cannot change? Answer: This case is okay, because the server should using an IID with the global-bit. Still, partition could cause problems for the DAD/retry. Comment: Make the random generation a good function, likelihood of collision low. Itojun: Definitely agrees that the frequency of change should be a choice of user. It's fine to change at reboot time, but give warnings about issues in reboot-less change. Comment: There is another case for needing to use both modes of address simultaneously. Many client-only systems will have to keep a stable address for the backward translation of name required by some servers (some telnetd's, smtpd's) and choose to use the private address only for applications without this constraint. Answer: The draft doesn't go into this case, because it is a bit of a rathole. For instance, how will applications decide? Draves: Have stable address be deprecated and private preferred? Answer: That doesn't help for the client-only two-mode case. Draves: It does help for server/client on one system case. Comment: It may be that DHCP must give out the private addresses because people are manually configuring addresses with the low-numbered IIDs such as ::1. It would be bad if there are collisions for those. They have local-bit set to true, so they are in same space as the generated private IIDs. Narten: Note that in the draft, the last thing that is done is to set the bit to local. Nordmark: DHCP also sets the bit to local, so there is the prospect of collision with DHCP-assigned addresses. Given the amount of space, it is not such a big collision risk, but maybe further structuring of the addresses could be considered. Answer: could consider getting an EUI prefix for these... X. Update to Advanced API - Erik Nordmark, Sun >From the time of the LA IETF, implementors have found it too complex, so the update simplifies it by providing less flexibility. A goal is to allow implementations to support both the old API (RFC2292) and this new API. The high order bits of changes between the RFC and this draft are summarized here: - Biggest change was to remove IPV6_PKTOPTIONS feature that set many options by recursion - it was not possible to know the behavior if one of many being set failed - did the others take effect anyway? Sticky options can now be set with individual setsockopt calls. - Added IPV6_RTHDRDSTOPTS to control DSTOPTS that show up before routing header, since can no longer control that with omnibus of IPV6_PKTOPTIONS. - Removed the ability to be able to specify HBH and DSTOPTS with multiple ancillary data items. Now application is responsible for formatting the whole extension header, so protocol stack does not have to guess the alignment restrictions etc. - Added separate IPV6_RECVxxx options to enable the receipt of the corresponding ancillary data items. Now the applications uses getsockopt to retrieve any sticky options it has set with setsockopt. - Clarified how and when TCP returns ancillary data items - it must when the content changes from one segment to another, but not necessarily on each data receive when the content does not change. These are not all the changes - see list in draft. Some TODO items are still extant: - Add mechanism to avoid fragmentation by sending at the minimum IPv6 MTU, for instance, this would be useful for a DNS server that does not want to do Path MTU discovery for a single reply. - Add MTU notification so that UDP apps can participate in PMTU discovery. This could be an ancillary data items received without any data, IPV6_PATHMTU, enabled with IPV6_RECV_PATHMTU. - Add reachability confirmation for UDP and raw socket apps to allow them to talk to Neighbor Discovery to defer NUD probes. This could be an ancillary data item for sendmsg with zero length called IPV6_REACHCONF. Due to shortage of time, the meeting was advised to look in the draft for the list of open issues. Implementors need to inspect this draft carefully. Is anything missing? The authors wants to do one more crank on it and then be done. Itojun: It is actually desirable that 2292 and 2292bis both be supported? If so, 2292bis should have words saying it is an addition. Answer: Do people need backward compatibility? Please speak up. The actual preference is that 2292bis should obsolete 2292, but it depends on the state of implementations. XI. Site Prefixes in Neighbor Discovery - Erik Nordmark, Sun Brief summary of the spec - Store site-local address in the DNS - RRset contains just site-locals if not connected, site-locals and globals if connected. Routers advertise the global prefixes for the site, typically as a /48 in the RA prefix options The resolver/getipnodebyname() filters the RRset - Test: one or more global addresses falls in site prefix - Exclude site-locals if not true The draft is 03. Changes since previous draft include: format change in option to make better fit with Router Renumbering; change the rules about suppressing global addresses returned from DNS to supporess only those that match the global prefixes received from the RAs; refine the text to handle case when DNS has only site-local addresses in it (in a non-connected site). Defined multi-sited nodes (with a single domain name) and tried to flesh out options in this case; specified that multi-sited nodes can use the site-local listings of only one site - a multihomed node must have a different domain name for each site if it wants to use site-local addresses in all its sites. For more additions and details, see the draft. There was a shortage of time for the presentation. The text was changed to reference AAAA/A6 instead of AAAA. But should it refer just to A6? Open issue - should the protocol advertise a human-readable name for each site? Deering has suggested this for multicast scopes in the past, as something useful for application user interfaces. (For instance, a user could be asked whether she wanted campus or office). It would be possible to add an ND option for the human-readable site name. Next steps: Get the basic rule (that all implementations, including those that do not implement ND site-local extensions, ignore site-locals received in the DNS RRset) into the implementations. The presentation ran out of time as the meeting time ended, so the request was made that discussion start on the mailing list about what the progress should be for this draft. July 15 Hinden announced (following from an announcement by Mike Roberts, temporary president of ICANN, at the IETF plenary the night before) that IANA has officially made the first delegation of IPv6 sub-TLAs to the Regional Internet Registries - we're not done, but this is another important step. The second session of IPNGWG was dedicated to multihoming. There was one item left over from the first session agenda, to be covered very quickly: XII. IPv6 Inverse Neighbor Discovery - Thomas Narten, IBM This is a document by Alex Conta that started in the ION WG. The IESG thought it needed more work after ION sent it to them following their WG last call. It was specified as a Frame Relay-related standard , but Narten pointed out that the Inverse ND is more general than its FR application, so Alex moved the FR-specific stuff into an Appendix, leaving the generic ND material in the main text The WG is requested to comments on it to Alex as soon as possible and an IPNGWG Last Call is requested to take place a few weeks following Oslo. Multihoming Agenda XIII. Overview of IP(v6) Multihoming Issues- Deering, presented by Rich Draves, Microsoft Research The agenda and starting points for this WG discussion were developed by a small design team put together by the WG chairs, which met or teleconferenced several times in June. It was emphasized that the design team results have no special status, but just were to serve as starting point for WG discussion Multihoming issues arise: Node Site There are pretty close analogies between the node and site cases. Note multihoming is dynamic - hosts, sites can acquire or lose addresses - can be multihomed for an interval. Multihoming issues are not new with IPv6, but the host ones are more prevalent or maybe more of an issue with IPv6 because of its support for multiple addresses per interface, for multiple scopes, for renumbering, and for transition scenarios introducing new interfaces, such as 6to4. Sites are equally likely to be multihomed in IPv4 or v6, but IPv6 may introduce the situation that sites are to get/use a different prefix with each ISP, rather than punching holes. Issues of - - Multiple Addresses for a Node: choice of source address, apps that use addresses as peer identifiers. - Multiple Interfaces for a Node: same issues, plus others such as that redirect only works if the sender uses the addresses of the outgoing and not those of other interfaces. Load-sharing across interfaces becomes possible, may or may not be desired. - Multiple Prefixes for a Site: policy-based preferences for using one prefix or not. - Multiple Attachment Points for a Site: will need to use right attachment - some of this is the domain of routing protocols, but not entirely. Load-sharing may be desired. How to receive packets for prefix of one attachment when it is down, but another is up. If ISP is doing ingress filtering, definitely need to choose prefix for source address that matches attachment being used. This is an incomplete list of the many issues. Not all of these need to be resolved by the WG now, as we have lived with them in IPv4 for a long time. Figure out the key ones. Generalized Host Multihoming - Hosts may have multiple local addresses (LA) and local interfaces (LI), and hosts may peer with multiple remote addresses (RA). For each triple chooses a particular path. There's a range of possible capabilities: - At session initiation time, for instance, TCP connect, choose the triple most likely to work (e.g. longest prefix match) - Try multiple triples/paths till one works - Iterate them over multiple sessions - Try them all and measure somehow which one is best - Keep history/experience - For an ongoing session, detect failure of current path and move - For an ongoing session, detect availability of a better path and move - Spread session traffic across multiple paths Later presentations will go into detail of proposed solutions chosen from above space. Different Models for Multiple Interface These were discussed as outgoing, but each has a version for incoming too: - Strong: the source address MUST belong to the originating interface - Semi-strong: the source address SHOULD belong to the originating interface - Weak: the source address MAY belong to any interface of the originating host Another take on these models is to consider whether the stack can choose the interface to use freely or not, when the application has picked the interface it wants to use. Advantages of Different Models The weak model has is simpler to implement because you go into the routing table and just get whatever match to the destination address is found. The strong model requires constraining what you can take from routing table. In IPv6, implementations already have this problem/ feature of routing-table lookup to some extent because of the presence of scoped addresses, so the semi-strong model looks promising intrinsically. Additional Near-Term Point - Consider using RFC 2260 - see Itojun's presentation to follow this. IPv6 Features for (Future) Use in Resolving Multihoming Issues - Globally-unique Node ID - e.g. when the interface ID is autoconfigured using an Ethernet MAC address, with bit indicating it is globally unique. The bit was added to the IID field to give potential for future transports to use the IID alone for transport control block lookup. - Router Renumbering - border routers can feed prefixes to the routers within the site, and it could be used to control what prefixes are used. - Use of Site-Local Addresses - to give intra-site communications immunity from external multihoming effects. - Exchange-based Addressing - assign a single TLA to a set of interconnected ISPs, and do flat routing among customers of exchange. Pros: multihomed sites can have a single prefix across their multiple attachments; also, sites avoid renumbering when they change ISPs. The standard IPv6 address architecture has the capability of doing this. Conclusions Do a few simple things now. Keep the WG focus on: - Heuristics for source and destination address selection - Some aspects of trying multiple paths - RFC 2260 And provide a host architecture that can evolve to support better multihoming support in the future. Multihoming will continue to be a rich source of problems. This presentation and the next two presentations are meant to be one group's contribution to the WG discussion. Comments - Perkins: Multihoming issues have come up in mobility. IPv6 must decide whether use careof or home address. Some Stanford University work developed the concept of a mobility address policy table, which seems as if it would be generalizable. How the table was populated was for future study. A pointer was sent to the mailing list. Hinden: From some points of view, mobility is another class of solutions for multihoming. Perkins: People should consider Erik Nordmark's presentation to mobility WG with implicit tunnels. Narten: But note the main focus of the ideas from our design team is not what happens when connection is already up and something happens, but rather what happens at the outset of connections. XIV. Multihoming: RFC2260 Approach - Jun-ichiro Hagino (Itojun), Research Laboratory, Internet Initiative Japan Focus is on multihoming support that is possible now. This talk covers the router stuff: Goal is to try to deliver packets of any (source, destination) during failure of one or more of the site exit links IPv4 uses portable addresses so that prefixes of one provider can be advertised out of another provider's attachment point. In IPv6, the portable address concept is not there, and advertisements should be more restricted. The next talk by Rich Draves will be about end2end stuff: Goal is to try to find the best (source, destination) on connection establishment, and perhaps in more advanced phases, to switch to a better (source, destination) during the course of a connection. RFC2260 One of the approaches in RFC2260 guarantees no extra routing announcement to outside and is friendly with IPv6 aggregation policy. Sites get ISP-provided addresses from multiple ISPs and are assumed to route them locally. For IPv4, the assumption is that a site has a region for each ISP's addresses, and routing exchange within the site for communication without going outside. IPv6 is different in making it easy for every end host to get addresses from each of the ISPs if that is desired. Let there be a site with a blue ISP and a red ISP, with the red site border router advertising the red prefix into the red ISP and the blue site border router advertising blue prefix into the blue ISP. and the internal routing stated above. Next: establish an IP in IP tunnel from the blue site border router to the red ISP border router and vice versa. In the stable state: announce the blue prefix from the red-to-blue tunnel endpoint in the blue ISP router. When the blue-blue link fails, so that the stronger route advertising the blue prefix into the blue ISP has failed, only then will the tunnel backup route be used and the blue prefix traffic will tunnel to and from the red site border router. There will be no advertisement of the blue prefix by the red ISP, so aggregation is not broken. IPv6 Extensions of RFC 2260 - - Address assignment: the two (or more) ISP prefixes could be assigned in separate regions of the site, as in IPv4, or throughout the site, or a combination of some mixed regions and other distinct regions. - Packets can survives ISP filters - use RFC2260 in reverse direction and site router tunnels the packet (source routing might be needed?). Scalability in a Very Large Site - Do not try to make a full-mesh configuration of tunnels, because it's too much mess. In an example where it's easy to see the suitable partial mesh: the two ISPs of the site portion located in Japan back each other up, the two ISPs of the site portion located in the US back each other up, but there is no backup between the countries. Conclusions - RFC 2260 is a good base for IPv6 multihoming - it is aggregation-friendly and does not encourage use of portable addresses. It is an operational solution - no change to protocol code. Will ISPs be able to do 2260? Some BGP gurus in Japan have said they find it feasible. Scalability - guideline document needed. Note - Dupont draft talking about RFC 2260 should be reviewed. Comments - Dupont: About 2260 in general, it is complex to set it up, and it is hard to find the expertise for running it. Many ISP policies are prohibitive of it. Finally, it does not help at all if the provider border router goes down, only if the link goes down. So 2260 is more than nothing, but not very capable. Itojun will try in his home. Mankin: we should set up some trials on the 6bone. Hinden: This is one tool for multihoming, but not a complete handling of the issues. Note that link failures are more common that router failures. Dupont: in the context where the exit router on the site is the ISP border router (belongs to the ISP), then a link failure amounts to an ISP router failure and is not cured by 2260. Nordmark: What about the potential for distributing the injected route with IBGP as in 2260? Comment: One could have a concern with AS number space consumption being increased by multihoming and 2260 does not help with that. Itojun: It would be possible to do something with another routing protocol than BGP. Tsirtis: It sounds good to combine 2260 with router renumbering as the earlier presentation said, so that when the link fails (or the router fails), nodes are told to change prefix. Itojun: Still RFC 2260 is a good starting point XV. Design Team's Proposal for IPv6 Multihoming - Rich Draves, Microsoft Research Goals - Support multihomed sites - Remove temptation to break the provider addressing plan and aggregation - more scalable routing is something IPv6 has to come through with. - Site availability is a key requirement. - Maintaining existing connections is a bonus, but not crucial - making sure new connections can be established goes very far. Business- critical apps are designed to be able to restart after a broken connection and otherwise recover if TCP breaks. - Helping multihomed hosts deal is also a bonus, but is not as critical an issue as making multihomed sites work properly. Changes should be kept minimal changes - not rock boat - No protocol changes - No TCP/UDP implementation changes - No API changes - No application changes. Ideally nobody would have to do anything and we'll fix these issues :) Finally an evolvable solution is needed. Grand Outline Phase 1 - required work for WG - RFC2260 approach - Source address selection - Destination address ordering Phase 1.5 - is this required? - TCP tries multiple source addresses Phase 2 - future work? - Additional APIs, e.g. connect to a DNS name - Centralize destination/source address selection (DNS...) Phase 3 - definitely in future - Adjusting paths after probing Phase 1 - Required Work on Source Address Selection Using longest-matching prefix. Getipnodebyname - ordering of destination addresses returned by DNS leads to source address selection in IPv6 stack. Pluses, Minuses, Questions: +Minimal changes +Scope/prefix matching - local, site, both of you have addresses from ISP A. ? Incorporate TCP feedback - to influence future decisions. - Does not try all pairs - for each destination, will only choose one column - Apps are responsible for any probing of the multiple destination addresses - some already do, but most don't - Another drawback is the need for feedback from the application to know when communication is successful, so a UDP without feedback can't tell you an address is ok ? Big timeouts during trying list ? Because of having decentralized the source/address selection, it is harder for administrators to insert their own controls Why Not Just Use RFC2260? - It doesn't help you find common scope/prefix - It doesn't help multihomed hosts, whereas the above architecture does help some - It doesn't deal with ISP/router failures, just ISP/link failure - Using a tunnel is inefficient - ISPs are willing? As far the design team could find out (admittedly not having searched exhaustively), none have implemented or tried using RFC2260. It is an extra burden. And why should an ISP help you to use another ISP? Why Not Use Address Selection/Ordering Only and Not RFC2260? Consider: Site 1 connected to ISP A and ISP B, Site 2 only connected to ISP A Site 1 has node with address 1a, 1b, Site 2 has node with address 2a Site 1 will want to use 1a to talk to Site 2. If the link between Site 1 and ISP A fails, then when it uses ISP B to initiate a TCP connection to Site 2, it fails. Question - Zill: Why not use routing headers? Answer: The team thought about doing so and it has possibilities. The use of router renumbering cited by Dupont and others also has possibilities. Phase 1.5 - is it required? TCP tries multiple source addresses - it would be necessary to work out the details. It would be an implementation change, not a change to the protocol. RFC2260 would not be needed for basic availability. All destination/source address pairs would get tried, but there would be a tendency for them to be tried in the wrong order because connect would choose one at a time of one's own interface prefixes at a time - trying <1a-2a> <1a-2b> instead of <1a-2a> <1b-2b>. Comments - Dupont: You could fix this with a new ICMP message to say change source address. Answer: This would require more work from the router, having to look at the source addresses being used - team talked about it, but... Crawford: It wouldn't work for this case anyway. Phase 2 - Future Work? Stack maintains host cache database DNS-based API - TCP: connect (DNS-name) - UDP: connect (DNS-name) - this would return to the applications a sorted list of destination/source pairs - UDP/etc: Would need an API addition to do update-database. This is because the stack can't tell if communications are working (even the app may not know). This is why the UDP:connect gives the application back a list of address pairs. Phase 3 - Definitely Future Work - Builds on the host cache database - Modify TCP for survivability, renumbering - security? - NUD-like probing for best destination/source pair - would have to control the overhead and load on this? An application could be willing to pay with some extra packets for large gain of a better path. Phase 1 Detailing: Source Address Selection Draft - 01 - Only applies when application has not specified source address - Define candidate set of source addresses, define pair-wise source address comparison - Always attempts communication using some source address - an alternative philosophy would be to fail in some cases, e.g. your peer has a global address but you have no global source address available. Philosophy in draft is to try anyway, because it might work and if so, it's better than nothing. Cases when you don't have appropriate scope address are probably due to misconfiguration. To fix the problem, administrator may need to be able use the communication. Nordmark: You can make the case especially in multicast, because peers may actually be on your link, and you have no way to know. Answer: This can be true in unicast too, for instance, you may have only a global for someone on your link. Nordmark: unlike in the multicast case, that can only be due to misconfiguration. Candidate Source Address Set - Do routing lookup, take all addresses of interface - RECOMMEND just using addresses assigned to outgoing interface, but permit use of addresses assigned to other interfaces (depending on the kind of peer - when talking to a routing peer, you MUST use an address belonging to the interface). - Question to WG - Under what circumstances (if any) should we allow use of addresses not assigned to the sending interface? Maybe if all prefixes on the sending interface are deprecated? Source Address Comparison - Series of tie-breakers: scope, preferred/deprecated, longest-matching-prefix - Scenario A. Global destination address - pick from 1. link-local source address or 2. deprecated global source address... - Scenario B. Site-local destination address - pick from 1. deprecated site-local source address or 2. preferred global source address. - Answers in draft now A.2, B.2 - Deering and Hinden school of thought is never to use a deprecated source address if you have any alternative. A answer would be 1. Hinden: Rationale is that site-local meant you were not supposed to communicate outside your site or else there was an error so that you didn't get your new global prefix. If you start the connection with the deprecated address, the site administrators won't find out about the mistake quickly. Draves: That's one school of thought. The alternative view is that the administrator who made the mistake may need ability to use the deprecated to be able to fix the screw-up. Hinden: let those administrators use a telnet that allows you to pick your choice of source address including breaking these rules. Elz: Don't forget these rules are only deals for when the application doesn't choose its own source address. You need some apps to be able to do this. Destination Address Ordering No draft yet - Try address with smallest scope first. - Try addresses that have longest possible match with a potential source address, if there is a choice within scope. - Don't unnecessarily perturb the DNS order. If you imagine this as a sort, you want it to be like a stable sort, so if you have a tie, you don't change the order. - Avoid extra system calls in the common case, cache in system library, so as not to have multiple calls down into stack for all those addresses. Discussion of scopes and destination address choice Elz: going to write a draft where DNS only returns highest scope and nodes when they connect algorithmically create smaller scope to use. If packet gets through and you have a site-local response back, then change to site-local. You can do this independent of what application requests. Draves: Some dangers, including that it would add latency. Elz: Would only add small amount if site is not too big a thing. Nordmark: Version 00 of the site-local draft had something like this, but it provides less administrative control, for instance you don't have option of leaving out the site-local address entries from the DNS for nodes you know are frequently mobile. You might want to have that admin control. Elz: Mobile IPv6 has arranged for site-local addresses to work. Anyway, will write up his draft. The Grand Outline discussion was consensus of the design team - Phase 1 solves the most pressing problems. Discussion - Dupont: TCP survivability/renumbering is entirely solved by mobility mechanisms. Narten: Have to disagree, because with mobility, you know when you've moved, but when a link goes down, or something other than router advertisements cause a new prefix to be needed, it is not as clearcut for the sender to know. The change is harder. Dupont: Have implemented it. It works. Carpenter: Change term renumbering to something like prefix migration - your home address is what's going to disappear at the end of the prefix migration. Nordmark: If we'd have done Phase 2 two years ago, it would have been phased in with the new API, but there are perhaps enough people porting applications now, that the Phase 2 API could not be included in some implementations. miss some. Hinden: This isn't an advanced API, it's more basic than basic. Itojun: There are already many applications using the basic API, so please don't drop it. Cheshire - MacOS connects using DNS names and it works fine - AF-DNS family name Carpenter: It would be nice because it's a fairly concrete interpretation of having APIs with a level of abstraction from network layer. Good news because architecture justified, bad news if it carried along some delay. Hinden: It might be good that we don't standardize APIs. Status - The source address selection draft is out there for working group review. Hinden then tried to turn the entire discussion into some next steps/actions. No voices said not to do Phase 1 - so the next step is either to add to the source selection document to include destination ordering as well, or make a new document for it. Action - Continue source/destination selection draft(s). Heard fairly strongly that there is value in doing Phase 2 - the DNS-based API part. We could do something very simple and use it to get experience. Not everyone has done their IPv6 implementation and shipped it as a product yet....Also we would hope IPv6 encourages some new applications, so even if the ports are done, there are new users of APIs to come. Action - Start Simple IPv6 API Crawford: An addition to this would be to use SRV records to find out the ports too. Some negative responses to this from the room. Action on 2260 - Next step is to have serious conversations with ISPs and routing experts - maybe there are serious reasons on their part not using it. To the design team's not very broad knowledge, it has not been implemented. Elz: Note the two ways to talk to ISP: saying something would be technically nice to do versus saying there are tens of millions in it for them if they do it. Provided a few well-heeled subscribers demand RFC 2260, it will be thereafter be provided everyone. Nordmark: ISPs often don't like tunnels because of issues with transit or non-transit. They are known not to like 6bone tunnels. Action - Investigate RFC2260 - Get more ISP opinions - Consult routing experts - Conduct 6bone tests Carpenter: Randy Bush said RFC 2260 has not been used in IPv4 because it is too complex. This could be a chicken-and-egg problem. Hinden: Things do change, this is the Internet after all Shand: Did a draft on this sort of topic 3-4 years ago. He will look and see if it has any interesting ideas to revive. Dupont: A lengthy draft on this stuff was just revived by NGTRANS. It should be moved to IPNGWG. XVI. Interim Meeting It would be useful to have an interim meeting focused on multihoming. When - last week in September is one thought of chairs. A question is whether it would be good to have it adjacent to an IPv6 Forum meeting?? Carpenter: Consider whether or not to broaden scope to prefix migration (renumbering) in general - got clear message from ISPs in context of last week's workshop. Hinden: good idea. Others concur. Carpenter: Prefix migration was Mike O'Dell's phrase, by the way. Fink: Adjacency to IPv6 Forum meeting does not have strong value to our community. Blanchet: First one is just between NANOG and Internet2 members' meeting anyway. Nordmark: How many went to IPv6 Forum meetings this week? Hinden: They were for limited invitees, and not advertised. Hinden: Please send a message to chairs if you can host the interim meeting and when you can host it. Fink: Suggest not broaden scope too much, e.g. to include an NGTRANS meeting, because this would dilute the ability to get things done. Looking at some of the transition mechanisms, it may prove a good idea to have interim specific narrow micro-working groups for making NGTRANS progress. [end of minutes] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 28 10:11:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA12474 for ipng-dist; Wed, 28 Jul 1999 10:08:37 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12467 for ; Wed, 28 Jul 1999 10:08:32 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA02214 for ipng@sunroof.eng.sun.com; Wed, 28 Jul 1999 10:06:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12000 for ; Wed, 28 Jul 1999 01:06:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA14190 for ; Wed, 28 Jul 1999 01:06:38 -0700 (PDT) Received: from calypso.urec.cnrs.fr (calypso.urec.cnrs.fr [194.57.137.114]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA23906 for ; Wed, 28 Jul 1999 01:06:36 -0700 (PDT) Received: from titan.urec.fr (titan [194.57.137.115]) by calypso.urec.cnrs.fr (8.9.3/jtpda-5.3.1) with ESMTP id KAA02006 ; Wed, 28 Jul 1999 10:06:35 +0200 From: Bernard.Tuy@urec.cnrs.fr (Bernard Tuy) Received: from (tuy@localhost) by titan.urec.fr (8.8.7/jtpda-5.2) id KAA01296 ; Wed, 28 Jul 1999 10:06:31 +0200 (MET DST) Date: Wed, 28 Jul 1999 10:06:31 +0200 (MET DST) Message-Id: <199907280806.KAA01296@titan.urec.fr> To: iesg-secretary@ietf.org Subject: Re: Protocol Action: IPv6 Jumbograms to Proposed Standard Cc: rfc-editor@isi.edu, iab@isi.edu, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-MD5: VfCcUkcUj5O4DXhxH9F8cg== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id BAA12001 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ====BT: I'd assume that the document promoted to PS is : dated June 25th, 1999 instead of the one mention below ? Just to be sure, I've not missed something there ... Cheers, +Bernard Tuy. --- | From: The IESG | Date: Tue, 27 Jul 1999 16:46:26 -0400 | | | | The IESG has approved the Internet-Draft 'IPv6 Jumbograms' | as a Proposed Standard. This | document is the product of the IPNG Working Group. | | The IESG contact persons are Erik Nordmark and Thomas Narten. | -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 28 12:48:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA12722 for ipng-dist; Wed, 28 Jul 1999 12:44:29 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12715 for ; Wed, 28 Jul 1999 12:44:24 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id MAA00633 for ipng@sunroof.eng.sun.com; Wed, 28 Jul 1999 12:42:44 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12703 for ; Wed, 28 Jul 1999 12:40:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA13138 for ; Wed, 28 Jul 1999 12:40:57 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26765 for ; Wed, 28 Jul 1999 12:40:55 -0700 (PDT) Received: from scoya.cnri.reston.va.us (scoya.cnri.reston.va.us [10.27.5.106]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21969; Wed, 28 Jul 1999 15:39:45 -0400 (EDT) Date: Wed, 28 Jul 1999 15:40:03 -0400 (Eastern Daylight Time) From: Steve Coya Reply-To: Steve Coya To: Bernard Tuy cc: iesg-secretary@ietf.org, rfc-editor@isi.edu, iab@isi.edu, ipng@sunroof.eng.sun.com Subject: Re: Protocol Action: IPv6 Jumbograms to Proposed Standard In-Reply-To: <199907280806.KAA01296@titan.urec.fr> Message-ID: X-X-Sender: scoya@odin.cnri.reston.va.us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You are correct, the current version (-01) was approved. The RFC Editor and I exchanged mail about this. 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 Wed Jul 28 20:33:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA13225 for ipng-dist; Wed, 28 Jul 1999 20:31:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13218 for ; Wed, 28 Jul 1999 20:30:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA28318 for ; Wed, 28 Jul 1999 20:30:54 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA17971 for ; Wed, 28 Jul 1999 20:30:53 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id XAA18942; Wed, 28 Jul 1999 23:30:49 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000019735; Wed, 28 Jul 1999 23:30:50 -0400 (EDT) From: Jim Bound Message-Id: <199907290330.XAA0000019735@quarry.zk3.dec.com> To: Joe Abley cc: itojun@iijlab.net, Peter Tattam , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Wed, 28 Jul 1999 14:24:04 +1200." <19990728142403.A7869@patho.gen.nz> Date: Wed, 28 Jul 1999 23:30:49 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Customers who go to the trouble of multi-homing typically do so because >they are worried about the stability of _transit_ through a single ISP. Or for geographical reasons which is why we are multihomed. There are many reaons folks want to be multihomed is my point. Should we document all those reasons? >For example, we are multi-homed (currently) to Concentric Networks and >Telstra -- both organisations provide us with global transit. This has >saved our bacon in the past when one of those providers has suffered >an outage which left us connected, but broke the transit (in the >example that springs to mind, we were left with excellent connectivity >to one Concentric POP and nothing to the rest of their network). >I'm not making a point about Concentric in particular, by the way -- they >were bitten by a nasty fault, and they have since eliminated the single >point of failure in their usual efficient manner. However, the point is >that transit failures _do_ happen, regardless of how robust a single >provider engineers their network. >Under your draft, a failure of this kind would still require >renumbering at the edge of the network, and special treatment for >established sessions (if they were to persist, which I would suggest >probably ought to be documented as a requirement). I don't see that? Nor the need for renumbering? I also dont' support such a solution with renumbering for the e2e reasons I sent out which is not just technical but mostly that reason. >As I mentioned earlier, when I read rfc2260 my attention was drawn to >section 5.1, which I think addresses this exact issue: it attempts to >ensure that the purity is maintained in the default-free zone in the >>absense of failures, but can be sacrificed in the interests of >connectivity during failures only. The auto-route-injection in 5.1 breaks aggregation too unless one uses the optimized IBGP discussed, which I think may work and dovetail well with Itojun's proposal. But I still believe Itojun's proposal will work as a 2260 mechanism and if you want to state cases where it will not work please do the following: - Highlight the solution Itojun proposes in the draft and pictures. - Then describe a scenario where it will not work and why. I know your not hand waving here but an engineer that puts for work in this community deserves some order in responses when a WG member says the proposal won't work. We grill each others specs but sometimes we need to grill the input. >I'm not naive enough to believe that 2260, as it stands, is without >operational concerns. However, I believe the framework in 5.1 addresses >a more relevant operational concern than that in 5.2. I think we should verify that 5.1 does not break the IPv6 AGGR model for that address space. /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 Jul 28 20:40:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA13261 for ipng-dist; Wed, 28 Jul 1999 20:39:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13254 for ; Wed, 28 Jul 1999 20:39:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA28727 for ; Wed, 28 Jul 1999 20:39:03 -0700 (PDT) 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 VAA04563 for ; Wed, 28 Jul 1999 21:39:02 -0600 (MDT) 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 MAA25606; Thu, 29 Jul 1999 12:37:08 +0900 (JST) To: Jim Bound cc: ipng@sunroof.eng.sun.com In-reply-to: bound's message of Wed, 28 Jul 1999 23:30:49 -0400. <199907290330.XAA0000019735@quarry.zk3.dec.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: Session Stability (was multi-homing vs route aggregation) From: itojun@iijlab.net Date: Thu, 29 Jul 1999 12:37:08 +0900 Message-ID: <25604.933219428@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>I'm not naive enough to believe that 2260, as it stands, is without >>operational concerns. However, I believe the framework in 5.1 addresses >>a more relevant operational concern than that in 5.2. >I think we should verify that 5.1 does not break the IPv6 AGGR model for >that address space. Sorry I'm sure that 5.1 does break the aggregation. It announnces same address prefix (portable, or a prefix from ISP-A) toward two or more ISPs. 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 Jul 28 20:59:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA13292 for ipng-dist; Wed, 28 Jul 1999 20:56:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13285 for ; Wed, 28 Jul 1999 20:56:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA18768 for ; Wed, 28 Jul 1999 20:56:30 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA07853 for ; Wed, 28 Jul 1999 21:56:29 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id XAA21736; Wed, 28 Jul 1999 23:56:25 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000030464; Wed, 28 Jul 1999 23:56:26 -0400 (EDT) From: Jim Bound Message-Id: <199907290356.XAA0000030464@quarry.zk3.dec.com> To: Steve Deering cc: ipng@sunroof.eng.sun.com, Bob Hinden Subject: Re: draft minutes from IPng WG meetings in Oslo In-reply-to: Your message of "Wed, 28 Jul 1999 07:35:13 PDT." Date: Wed, 28 Jul 1999 23:56:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One comment: I got a real problem with phase 2 discussions for DNS API but will await a draft. The idea was part of a recent ngtrans discussion too. p.s. Please no one send me private mail on this I will say upfront any mail on this subject to me will be forwarded to the IPng list. If you put PRIVATE in the subject I will just not discuss it with you. This must be discussed openly and on the mail list. 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 Wed Jul 28 21:28:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA13341 for ipng-dist; Wed, 28 Jul 1999 21:23:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13334 for ; Wed, 28 Jul 1999 21:23:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA20958 for ; Wed, 28 Jul 1999 21:23:31 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA13005 for ; Wed, 28 Jul 1999 22:23:30 -0600 (MDT) Received: from anw.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id AAA16522 for ; Thu, 29 Jul 1999 00:23:29 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id AAA0000693631; Thu, 29 Jul 1999 00:23:29 -0400 (EDT) From: Jim Bound Message-Id: <199907290423.AAA0000693631@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: TESTING IPv6 Re: draft minutes from IPng WG meetings in Oslo In-reply-to: Your message of "Wed, 28 Jul 1999 07:35:13 PDT." Date: Thu, 29 Jul 1999 00:23:28 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Steve/Allison - Excellent minutes thanks........] Sorry one other clarification comment I woud have made in response to the following: >Itojun: Can you describe how TAHI is distinguished from UNH. Answer: >a major difference is that all the test programs will be openly >available, as will test results such as the ipv6-unified. At UNH and at Connectathon the testing to support vendors testing and interoperability as the code is being developed and the specs. For example once we agree on src address selection or APIs we can go build the code and go to a UNH or Connectathon type environment and test online without fear of being bashed for parts that are incomplete or interoperability issues in the media or other interests. The fact that vendor X's tests are not open to the public or other vendors (of course when your testing together in a room you work together and we learn about each others stuff and why we sign Non-Disclosure agreements) is not just a policy but a Feature Benefit of using UNH and other such forums. Now if someone is talking about giving vendors an "IPv6 Certificate of Compliance" thats another issue and has many business and legal issues for vendors and for goverments. I am not saying TAHI is not good or important but just clarifying why we want the UNH tests to be closed. Its also important to differentiate vendor product software from non-vendor software for testing. 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 Wed Jul 28 21:55:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA13376 for ipng-dist; Wed, 28 Jul 1999 21:52:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13369 for ; Wed, 28 Jul 1999 21:52:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA22323 for ; Wed, 28 Jul 1999 21:52:42 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA04921 for ; Wed, 28 Jul 1999 21:52:40 -0700 (PDT) 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 NAA27045 for ; Thu, 29 Jul 1999 13:52:39 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: bound's message of Thu, 29 Jul 1999 00:23:28 -0400. <199907290423.AAA0000693631@anw.zk3.dec.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: TESTING IPv6 Re: draft minutes from IPng WG meetings in Oslo From: itojun@iijlab.net Date: Thu, 29 Jul 1999 13:52:39 +0900 Message-ID: <27043.933223959@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Sorry one other clarification comment I woud have made in response to >the following: >>Itojun: Can you describe how TAHI is distinguished from UNH. Answer: >>a major difference is that all the test programs will be openly >>available, as will test results such as the ipv6-unified. >At UNH and at Connectathon the testing to support vendors testing >and interoperability as the code is being developed and the specs. >For example once we agree on src address selection or APIs we can go >build the code and go to a UNH or Connectathon type environment and test >online without fear of being bashed for parts that are incomplete or >interoperability issues in the media or other interests. The fact >that vendor X's tests are not open to the public or other vendors (of >course when your testing together in a room you work together and we >learn about each others stuff and why we sign Non-Disclosure agreements) >is not just a policy but a Feature Benefit of using UNH and other such >forums. Let me clarify. TAHI guys provide test tools as free software. So you can test your code in-house, without travelling to Japan nor UNH. In this case you will have nothing to disclose to others. You just need to install a test node that runs TAHI tools (which is slightly- patched KAME/FreeBSD2.2.8 on PC clones). Separately, TAHI guys are able to test your product with you face-to-face (of course only when schedule allows). They can keep the result hidden, or they can put result onto TAHI webpage. Pls talk with TAHI guys, I think they are flexible enough on this issue. >I am not saying TAHI is not good or important but just clarifying why we >want the UNH tests to be closed. Its also important to differentiate >vendor product software from non-vendor software for testing. Understood. One thing that is not visible from me is, are UNH guys active on IPv6 testing these days? I see few announcements for test events lately (last one was Connectathon if I remember correctly). Or they mainly test vendor code on request from vendors? 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 Jul 28 22:20:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA13409 for ipng-dist; Wed, 28 Jul 1999 22:16:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13402 for ; Wed, 28 Jul 1999 22:16:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA27991 for ; Wed, 28 Jul 1999 22:16:15 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA21690 for ; Wed, 28 Jul 1999 23:16:14 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id BAA30441; Thu, 29 Jul 1999 01:16:11 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id BAA0000009259; Thu, 29 Jul 1999 01:16:13 -0400 (EDT) From: Jim Bound Message-Id: <199907290516.BAA0000009259@quarry.zk3.dec.com> To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: TESTING IPv6 Re: draft minutes from IPng WG meetings in Oslo In-reply-to: Your message of "Thu, 29 Jul 1999 13:52:39 +0900." <27043.933223959@coconut.itojun.org> Date: Thu, 29 Jul 1999 01:16:12 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK Itojun...I get it.........thanks UNH is still active and running test suites on site if you leave a test system there too and they send you the reports. I think there is one planned just before Nov Wash DC IETF meeting. Also I think the next round of specs need testing too after our core ones especially some transition ones if possible. p.s. Bill L. at UNH want to say more ????? Or UNH folks ??? /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 Jul 29 07:19:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA13663 for ipng-dist; Thu, 29 Jul 1999 07:16:16 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13656 for ; Thu, 29 Jul 1999 07:16:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA18486 for ; Thu, 29 Jul 1999 07:16:06 -0700 (PDT) Received: from vaiola.tahi.org (217.pool2.osaka.att.ne.jp [165.76.118.232]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28570 for ; Thu, 29 Jul 1999 08:16:00 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by vaiola.tahi.org (8.8.8/8.8.8) with ESMTP id XAA00482; Thu, 29 Jul 1999 23:11:39 +0900 (JST) (envelope-from nov@tkd.att.ne.jp) To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: TESTING IPv6 Re: draft minutes from IPng WG meetings in Oslo From: OKABE Nobuo Reply-To: Nobuo_Okabe@yokogawa.co.jp In-Reply-To: Your message of "Thu, 29 Jul 1999 00:23:28 -0400" <199907290423.AAA0000693631@anw.zk3.dec.com> References: <199907290423.AAA0000693631@anw.zk3.dec.com> X-Mailer: Mew version 1.93 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: <19990729231137D.nov@tkd.att.ne.jp> Date: Thu, 29 Jul 1999 23:11:37 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 57 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for not responding so quickly. From: Jim Bound Subject: TESTING IPv6 Re: draft minutes from IPng WG meetings in Oslo Date: Thu, 29 Jul 1999 00:23:28 -0400 Message-ID: <199907290423.AAA0000693631@anw.zk3.dec.com> > [Steve/Allison - Excellent minutes thanks........] > > Sorry one other clarification comment I woud have made in response to > the following: > > >Itojun: Can you describe how TAHI is distinguished from UNH. Answer: > >a major difference is that all the test programs will be openly > >available, as will test results such as the ipv6-unified. > > At UNH and at Connectathon the testing to support vendors testing > and interoperability as the code is being developed and the specs. > For example once we agree on src address selection or APIs we can go > build the code and go to a UNH or Connectathon type environment and test > online without fear of being bashed for parts that are incomplete or > interoperability issues in the media or other interests. The fact > that vendor X's tests are not open to the public or other vendors (of > course when your testing together in a room you work together and we > learn about each others stuff and why we sign Non-Disclosure agreements) > is not just a policy but a Feature Benefit of using UNH and other such > forums. > > Now if someone is talking about giving vendors an "IPv6 Certificate of > Compliance" thats another issue and has many business and legal issues > for vendors and for goverments. > > I am not saying TAHI is not good or important but just clarifying why we > want the UNH tests to be closed. Its also important to differentiate > vendor product software from non-vendor software for testing. I understand what you said because we have beeing discussed about thoes. Let me explain tahi project briefly. 1. We provide test tools freely. you can run tests yourself. Even if you don't run the tests, you can exsamin test specifications. 2. We are also planning to give test events near future. 3. Usually, we keep the test result confidential. We can open the resut if you want to do so. We have opened the test result of KAME exceptionally, but have not opened test result of other implemetions. I don't mean that tahi project compete against UNH ,Connectathon or something like that. Or I hope that the project cooperates with UNH and conectathon for IPv6 deployment. Thanks. ---------- Okabe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 29 07:44:47 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA13709 for ipng-dist; Thu, 29 Jul 1999 07:41:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13702 for ; Thu, 29 Jul 1999 07:41:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA20718 for ; Thu, 29 Jul 1999 07:41:28 -0700 (PDT) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04815 for ; Thu, 29 Jul 1999 07:41:27 -0700 (PDT) Received: from localhost (rglr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id KAA00685; Thu, 29 Jul 1999 10:38:41 -0400 (EDT) Date: Thu, 29 Jul 1999 10:38:41 -0400 From: Ray LaRocca To: ipng@sunroof.eng.sun.com cc: ipmembers@iol.unh.edu Subject: UNH IPv6 Group Test Period Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ****************** ANNOUNCEMENT ******************* The UNH - Interoperability Lab IP/Routing Consortium will be hosting an IPv6 test period on November 1-5, 1999. Information on location, hotels and travel info can be found at our Web site: http://www.iol.unh.edu On-line registration is also available on our Web site, for additional information you may contact, Carol Cooper (chc@iol.unh.edu), 603-862-0201 or me at the information below. Regards, -Ray /* * Ray LaRocca Lead Engineer, IP/Routing Consortium * Manager, FDDI Consortium * Email: rglr@iol.unh.edu * Tel: (603) 862-2804 InterOperability Lab * Lab Tel: (603) 862-0090 University of New Hampshire * Fax: (603) 862-4181 7 Leavitt Lane, Room 106 * Web: http://www.iol.unh.edu Durham, NH 03824-3525 */ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 29 07:55:03 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA13747 for ipng-dist; Thu, 29 Jul 1999 07:52:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13736 for ; Thu, 29 Jul 1999 07:52:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA21967 for ; Thu, 29 Jul 1999 07:52:00 -0700 (PDT) Received: from eos-f.sr.unh.edu (eos-241.sr.unh.edu [132.177.241.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA10659 for ; Thu, 29 Jul 1999 08:51:58 -0600 (MDT) Received: from [132.177.241.23] (whitec.sr.unh.edu [132.177.241.23]) by eos-f.sr.unh.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA17654 for ; Thu, 29 Jul 1999 10:51:49 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: whl@bluemoon.sr.unh.edu Message-Id: Date: Thu, 29 Jul 1999 10:52:05 -0400 To: ipng@sunroof.eng.sun.com From: "William H. Lenharth" Subject: IPv6 Testing Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The testing that we do at UNH is based on IETF specs., and is driven by vendor based demand. Our interest is in promoting and encouraging the rapid development of the technology, such as IIPv6. For that reason our testing is closed to marketting or press personnel. One of our biggest advantages >is not our vast test suite that we have been developing since 1994, but >our ability to provide knowledgeable engineers to test products WITHOUT >vendor participation or attendence, this I >thing would be particularily important for those companies located outside >the USA. Also, since >member companies leave and update thier equipment , we have a large >testing network in operation >in our lab, running current implementations. We will be hosting the next >test period for IPv6 the week before the Nov 1999 IETF meetings in >Washington, DC..Feel free to check our web site (www.iol.unh.edu) or >contact me at whl@sr.unh.edu for information. > > > > > >>OK Itojun...I get it.........thanks >> >>UNH is still active and running test suites on site if you leave a test >>system there too and they send you the reports. >> >>I think there is one planned just before Nov Wash DC IETF meeting. >> >>Also I think the next round of specs need testing too after our core >>ones especially some transition ones if possible. >> >>p.s. Bill L. at UNH want to say more ????? Or UNH folks ??? >> >>/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 >>-------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 29 10:04:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA14115 for ipng-dist; Thu, 29 Jul 1999 10:00:58 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14108 for ; Thu, 29 Jul 1999 10:00:54 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA01673 for ipng@sunroof.eng.sun.com; Thu, 29 Jul 1999 09:59:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13580 for ; Thu, 29 Jul 1999 05:13:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA11707 for ; Thu, 29 Jul 1999 05:13:26 -0700 (PDT) Received: from eos-f.sr.unh.edu (eos-243.sr.unh.edu [132.177.243.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA24016 for ; Thu, 29 Jul 1999 05:13:26 -0700 (PDT) Received: from [132.177.241.23] (whitec.sr.unh.edu [132.177.241.23]) by eos-f.sr.unh.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA08631 for ; Thu, 29 Jul 1999 08:13:24 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: whl@bluemoon.sr.unh.edu Message-Id: In-Reply-To: <199907290516.BAA0000009259@quarry.zk3.dec.com> References: Your message of "Thu, 29 Jul 1999 13:52:39 +0900." <27043.933223959@coconut.itojun.org> Date: Thu, 29 Jul 1999 08:13:56 -0400 To: ipng@sunroof.eng.sun.com From: "William H. Lenharth" Subject: Re: TESTING IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The testing that we do at UNH is based on IETF specs., and is driven by vendor based demand. Our interest is in promoting and encouraging the rapid development of the technology, such as IIPv6. For that reason our testing is closed to marketting or press personnel. One of our biggest advantages is not our vast test suite that we have been developing since 1994, but our ability to provide knowledgeable engineers to test products WITHOUT vendor participation or attendence, this I thing would be particularily important for those companies located outside the USA. Also, since member companies leave and update thier equipment , we have a large testing network in operation in our lab, running current implementations. We will be hosting the next test period for IPv6 the week before the Nov 1999 IETF meetings in Washington, DC..Feel free to check our web site (www.iol.unh.edu) or contact me at whl@sr.unh.edu for information. >OK Itojun...I get it.........thanks > >UNH is still active and running test suites on site if you leave a test >system there too and they send you the reports. > >I think there is one planned just before Nov Wash DC IETF meeting. > >Also I think the next round of specs need testing too after our core >ones especially some transition ones if possible. > >p.s. Bill L. at UNH want to say more ????? Or UNH folks ??? > >/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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 29 17:45:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA15044 for ipng-dist; Thu, 29 Jul 1999 17:43:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15022; Thu, 29 Jul 1999 17:41:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA01174; Thu, 29 Jul 1999 17:41:23 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA11339; Thu, 29 Jul 1999 17:41:21 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id KAA16485; Fri, 30 Jul 1999 10:41:20 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Fri, 30 Jul 1999 10:41:20 +1000 (EST) From: Peter Tattam To: IPNG Mailing List , NGTRANS Mailing List Subject: Any calls for IPv6 over MS-DOS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I noticed a request on comp.protocols.tcp-ip.ibmpc for a DOS implementation of IPv6. We have some DOS stuff that could be worked up to do it, but would take at least a month or so to shoehorn it into a DOS TSR that would be practical in size. Does anyone think this project is worth pursuing? Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------