From owner-ipng@sunroof.eng.sun.com Wed Sep 1 05:59:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA28549 for ipng-dist; Wed, 1 Sep 1999 05:56: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 FAA28542 for ; Wed, 1 Sep 1999 05:56: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 FAA25443 for ; Wed, 1 Sep 1999 05:56:27 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA29735 for ; Wed, 1 Sep 1999 06:56:26 -0600 (MDT) 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 IAA32364; Wed, 1 Sep 1999 08:55:32 -0400 Received: from tigers.raleigh.ibm.com (tigers.raleigh.ibm.com [9.37.176.195]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA21310; Wed, 1 Sep 1999 08:55:34 -0400 Received: from raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by tigers.raleigh.ibm.com (AIX4.3/UCB 8.8.8/8.7/RTP-ral-1.0) with ESMTP id IAA27242; Wed, 1 Sep 1999 08:56:38 -0400 Message-ID: <37CD2286.9AAE9577@raleigh.ibm.com> Date: Wed, 01 Sep 1999 08:56:38 -0400 From: Brian Haberman X-Mailer: Mozilla 4.6 [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: Richard Draves CC: ipng@sunroof.eng.sun.com Subject: Re: node-local mc & the API References: <4D0A23B3F74DD111ACCD00805F31D810145158CB@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Draves wrote: > > How do node-local multicast addresses interact with the IPV6_MULTICAST_LOOP > option? If the option is set to disallow loopback, I assume that means > transmissions will get dropped in the bit bucket? Rich, I was under the impression that node-local multicast does not really follow the same loopback conventions as other multicast addresses do. The reason is that the packet addressed is not meant to leave the box so if anything in the node is "joined" to the group, it will get the packet. I suppose that you could look at it as when an app joins to that node-local address, the loopback state is automatically enabled. 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 Sep 1 07:27:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA28670 for ipng-dist; Wed, 1 Sep 1999 07:24: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 HAA28663 for ; Wed, 1 Sep 1999 07:24:10 -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 HAA04000; Wed, 1 Sep 1999 07:24:09 -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 HAA08742; Wed, 1 Sep 1999 07:24:08 -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 KAA06235; Wed, 1 Sep 1999 10:24:07 -0400 (EDT) Received: from whitestar.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000028620; Wed, 1 Sep 1999 10:24:05 -0400 (EDT) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA22194; Wed, 1 Sep 1999 10:24:04 -0400 Message-Id: <37CD3703.8C6D7ECA@zk3.dec.com> Date: Wed, 01 Sep 1999 10:24:03 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.51 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: Erik Nordmark Cc: IPNG Working Group Subject: Re: Comments on 2292bis (Adv. API) (2) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > > Section 9.5 [page 36] > > - How is the "previous" length updated in this sentence? > > 1977 .... This > > 1978 function returns the updated "previous" length taking into account > > 1979 the option that was returned. > > It updates it so that it can be passed to the next call to inet6_opt_next. > I'll add some text to that effect. > (Or were you asking how to implement this?) I was asking, what "update 'previous' length" means in this case. Do we simply account for the new option by increment (or decrement for other functions) the length accordingly, or is there some other processing need? The reason I asked this is that the sentence seemed a little vague to me. > > > - Also, the main body of the spec does not indicate if inet6_opt_next returns > > pad options or just skips over them. The example code in the appendix shows > > the application code does recognize and ignore pad options. Suggest a note > > be added to this section indicating inet6_opt_next does return pad options. > > I agree we should clarify this. But do we want it to return them or skip them? > I do not see a reason for returning Pad1 and PadN options. The reason I asked is then the example in the Appendix had Pad1 and PadN in the 'switch' clause and it was not stated anywhere in the document whether inet6_opt_next returned these options. > > > > > Sections 12.2 and 12.3 > > - What was the reason to put rcmd_af() and rexec_af() in this spec? > > It was the concensus of the reviewers that these functions are not really > > needed since they both used to call rresvport() and can be made to call > > rresvport_af(). As it is currently, rcmd() and rexec() do the hostname > > lookups. At this point these functions can make the decision to use V6 or > > V4 based on the addresses returned. We do not really see the need for > > rcmd_af() and rexec_af(). > > I tried finding the old discussion but failed to do so. > > The issue is that transparently changing rcmd and rresvport to > open AF_INET6 sockets (based on what getipnodebyname returns) > might break some existing applications. > For example, an application which calls rcmd and then calls > getpeername. > > Thus I think we need APIs so that only applications which state that > they can handle sockaddr_in6 addresses will get an AF_INET6 socket > returned by rcmd/rexec/rresvport. > OK, I see your point. I guess we can leave it in this document for lack of a better place. > > Section 22 [page 47] > > - This section and it's subsections add a lot of new requirements to > > an implementation's handling of the msghdr and cmsghdr structures. > > What aspects of msghdr and cmsghdr are new? 99% of it is in > posix/xnet already. > > The only new things are CMSG_SPACE and CMSG_LEN. Anything else? > Yes. - Last paragraph of section 22.3.1 (CMSG_FIRSTHDR). I checked the xnet doc and it does not require this check. I agree that this is a good thing to do and we should put this into the main body of the document to avoid porting problems. - Second paragraph of section 22.3.2. This is new to the API and is not specified in Posix or xnet. > > We don't think this should be treated as "informational" given that > > many of these requirements are necessary to support the main body of > > the spec. Also, the new requirements are being made to posix standard > > structures and macros. Something needs to be done to make this section > > less "informational." > > We could lift out the new stuff and leave the repetitive information > in the appendix. That would be great. > > Erik Thanks -vlad +++++++++++++++++++++++++++++++ Vladislav Yasevich Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 (603) 884-1079 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 1 09:27:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA28857 for ipng-dist; Wed, 1 Sep 1999 09:24: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 JAA28850 for ; Wed, 1 Sep 1999 09:23:55 -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 JAA18587; Wed, 1 Sep 1999 09:23:55 -0700 (PDT) Received: from roll.mentat.com ([192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26613; Wed, 1 Sep 1999 09:23:52 -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 JAA16166; Wed, 1 Sep 1999 09:24:43 -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 JAA20124; Wed, 1 Sep 1999 09:24:43 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id JAA02715; Wed, 1 Sep 1999 09:24:43 -0700 (PDT) Date: Wed, 1 Sep 1999 09:24:43 -0700 (PDT) From: Tim Hartrick Message-Id: <199909011624.JAA02715@feller.mentat.com> To: Erik.Nordmark@eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) Cc: vlad@zk3.dec.com, Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > > > I would say that a non-zero sin6_scope_id overrides the IPV6_MULTICAST_IF > > option and that the interface indices in the IPV6_PKTINFO and IPV6_NEXTHOP > > options override the sin6_scope_id. > > For IPV6_NEXTHOP are you talking about an ifindex in a sockaddr_dl? > If so, will this override IPV6_PKTINFO or the other way around? > sockaddr_dl? Where did that come from. The IPV6_NEXTHOP options uses a sockaddr_in6. There is language in the document which implies that the sockaddr in the option could be some other kind of sockaddr but that seems like unnecessary flexibility/complexity. It is IPV6_NEXTHOP and should only apply to IPv6. I don't think we should be defining some generic next hop option and if we are then it should be called SO_NEXTHOP and all of the permutations should be specified. I know I don't want to go there. As you note, the IPV6_PKTINFO and the IPV6_NEXTHOP can contain conflicting information. The choices of how to deal with these conflicts are myriad. We could use the last interface specified. We could fail the operation if there is a conflict.... I would probably opt for the former. > For IPV6_PKTINFO there might be a difference whether it is a sticky option > or in ancillary data. > I am not sure what you mean here. 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 Wed Sep 1 09:30:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA28881 for ipng-dist; Wed, 1 Sep 1999 09:28: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 JAA28874 for ; Wed, 1 Sep 1999 09:28: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 JAA03227; Wed, 1 Sep 1999 09:28:32 -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 JAA28165; Wed, 1 Sep 1999 09:28:29 -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 JAA16185; Wed, 1 Sep 1999 09:29:09 -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 JAA20192; Wed, 1 Sep 1999 09:29:08 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id JAA02718; Wed, 1 Sep 1999 09:29:11 -0700 (PDT) Date: Wed, 1 Sep 1999 09:29:11 -0700 (PDT) From: Tim Hartrick Message-Id: <199909011629.JAA02718@feller.mentat.com> To: sm@bossette.engr.sgi.com, Erik.Nordmark@eng.sun.com Subject: Re: more 2292-bis comments Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > I'm open to input. Does anybody want 2292 compatibility? > I say nuke it. 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 Wed Sep 1 09:34:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA28919 for ipng-dist; Wed, 1 Sep 1999 09:33: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 JAA28912 for ; Wed, 1 Sep 1999 09:32:57 -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 JAA04203; Wed, 1 Sep 1999 09:32:56 -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 KAA21364; Wed, 1 Sep 1999 10:32:55 -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 JAA16217; Wed, 1 Sep 1999 09:32:58 -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 JAA20322; Wed, 1 Sep 1999 09:32:58 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id JAA02724; Wed, 1 Sep 1999 09:33:01 -0700 (PDT) Date: Wed, 1 Sep 1999 09:33:01 -0700 (PDT) From: Tim Hartrick Message-Id: <199909011633.JAA02724@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp, Erik.Nordmark@eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) Cc: vlad@zk3.dec.com, Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > Good question. > bind() conceptually specifies the local part of the address and not > where things are sent. > > Thus it would make more sense to ask > if you bind to link-local X with ifindex 2 > will that reject packets sent to link-local address X which arrive on some > other interface? > I would say yes. The scope-id (the interface index in your example) is really part of the address. For systems that use the same link token on all their interfaces the ability to bind to a specific local address and get only datagrams destined for that address is, in my opinion, essential. 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 Wed Sep 1 10:58:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA29040 for ipng-dist; Wed, 1 Sep 1999 10:53:50 -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 KAA29033 for ; Wed, 1 Sep 1999 10:53:41 -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 KAA15749; Wed, 1 Sep 1999 10:53:40 -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 KAA03573; Wed, 1 Sep 1999 10:53:38 -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 TAA11163; Wed, 1 Sep 1999 19:53:31 +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 TAA30680; Wed, 1 Sep 1999 19:53:29 +0200 (MET DST) Message-Id: <199909011753.TAA30680@givry.inria.fr> From: Francis Dupont To: Erik Nordmark cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , tim@mentat.com, vlad@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-reply-to: Your message of Tue, 31 Aug 1999 14:22:59 PDT. Date: Wed, 01 Sep 1999 19:53:24 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: bind() conceptually specifies the local part of the address and not where things are sent. Thus it would make more sense to ask if you bind to link-local X with ifindex 2 will that reject packets sent to link-local address X which arrive on some other interface? => the answer should be yes (ie. packets are rejected, this is what I have implemented). 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 Sep 1 11:06:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA29076 for ipng-dist; Wed, 1 Sep 1999 11:04: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 LAA29069 for ; Wed, 1 Sep 1999 11:03: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 LAA18375 for ; Wed, 1 Sep 1999 11:03:55 -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 LAA08337 for ; Wed, 1 Sep 1999 11:03:54 -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 UAA11384; Wed, 1 Sep 1999 20:03:53 +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 UAA31928; Wed, 1 Sep 1999 20:03:52 +0200 (MET DST) Message-Id: <199909011803.UAA31928@givry.inria.fr> From: Francis Dupont To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: Re: node-local mc & the API In-reply-to: Your message of Tue, 31 Aug 1999 16:09:37 PDT. <4D0A23B3F74DD111ACCD00805F31D810145158CB@RED-MSG-50> Date: Wed, 01 Sep 1999 20:03:51 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Does the API require/allow any special restrictions on node-local multicast addresses. For example, can an implementation require that node-local multicast addresses only be assigned to a loopback interface? => I don't understand what you means by "assigned". Do you suggest a JOIN can be done only on a loopback interface if the multicast address is a node-local one? How do node-local multicast addresses interact with the IPV6_MULTICAST_LOOP option? If the option is set to disallow loopback, I assume that means transmissions will get dropped in the bit bucket? => fortunately the default is to loopback packets then for common applications this doesn't matter. The whole node-local is a bit under-specified but this doesn't make portable applications difficult to write. Obviously it is more a (kernel) implementor issue than a general one. 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 Wed Sep 1 11:10:02 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA29087 for ipng-dist; Wed, 1 Sep 1999 11:06: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 LAA29078 for ; Wed, 1 Sep 1999 11:06:17 -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 LAA18897; Wed, 1 Sep 1999 11:06:16 -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 LAA09295; Wed, 1 Sep 1999 11:05:48 -0700 (PDT) Received: from bogey by east.isi.edu (8.8.5/5.61+local-24) id ; Wed, 1 Sep 1999 18:05:42 GMT Message-ID: <011f01bef4a5$234be470$634cf526@east.isi.edu> From: "Aaron Griggs" To: "Erik Nordmark" Cc: References: Subject: Re: Comments on 2292bis (Adv. API) Date: Wed, 1 Sep 1999 14:09:25 -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 > > - if we set a non-zero value to sin6_scope_id and a global unicast > > address to sin6_addr, what should the kernel do? Return an error? > > Ignore the value? Or send the packet to the interface whose index is > > the specified value? > > Ignore or error sounds reasonable. Is there a reason why scope_id is not used for the global unicast addresses? > > Which value should the kernel set to sin6_scope_id when receiving > > from a global address? > > Zero. Again, why not set the interface value on which the global unicast addresses was received? 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 Wed Sep 1 11:36:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA29149 for ipng-dist; Wed, 1 Sep 1999 11:26: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 LAA29142 for ; Wed, 1 Sep 1999 11:26: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 LAA29091; Wed, 1 Sep 1999 11:26:42 -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 LAA18815; Wed, 1 Sep 1999 11:26: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 UAA11688; Wed, 1 Sep 1999 20:26:38 +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 UAA32250; Wed, 1 Sep 1999 20:26:37 +0200 (MET DST) Message-Id: <199909011826.UAA32250@givry.inria.fr> From: Francis Dupont To: "Aaron Griggs" cc: "Erik Nordmark" , ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-reply-to: Your message of Wed, 01 Sep 1999 14:09:25 EDT. <011f01bef4a5$234be470$634cf526@east.isi.edu> Date: Wed, 01 Sep 1999 20:26:36 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Is there a reason why scope_id is not used for the global unicast addresses? => because the scope_id is defined (?) only for local scopes. > > Which value should the kernel set to sin6_scope_id when receiving > > from a global address? > > Zero. Again, why not set the interface value on which the global unicast addresses was received? => because someone else would like to get the site identifier on which the global unicast addresses was received: if you need the interface value in this case you have to use a more specific device. 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 Wed Sep 1 11:59:47 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA29187 for ipng-dist; Wed, 1 Sep 1999 11:52: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 LAA29180 for ; Wed, 1 Sep 1999 11:52:16 -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 LAA00190 for ; Wed, 1 Sep 1999 11:52:14 -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 LAA00209 for ; Wed, 1 Sep 1999 11:52:02 -0700 (PDT) Received: from bogey by east.isi.edu (8.8.5/5.61+local-24) id ; Wed, 1 Sep 1999 18:51:31 GMT Message-ID: <015201bef4ab$861969f0$634cf526@east.isi.edu> From: "Aaron Griggs" To: "Francis Dupont" Cc: References: <199909011826.UAA32250@givry.inria.fr> Subject: Re: Comments on 2292bis (Adv. API) Date: Wed, 1 Sep 1999 14:55:13 -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 > In your previous mail you wrote: > > Is there a reason why scope_id is not used for the global unicast addresses? > > => because the scope_id is defined (?) only for local scopes. > Basic Socket Interface Extensions for IPv6 (rfc 2553) says about sin6_scope_id: The sin6_scope_id field is a 32-bit integer that identifies a set of interfaces as appropriate for the scope of the address carried in the sin6_addr field. For a link scope sin6_addr sin6_scope_id would be an interface index. For a site scope sin6_addr, sin6_scope_id would be a site identifier. The mapping of sin6_scope_id to an interface or set of interfaces is left to implementation and future specifications on the subject of site identifiers. I assumed link scope sin6_addr was both link-local and global. Maybe, specifying "link-local" instead of "link" would help clarify. > > > Which value should the kernel set to sin6_scope_id when receiving > > > from a global address? > > > > Zero. > > Again, why not set the interface value on which the global unicast addresses > was received? > > => because someone else would like to get the site identifier on which > the global unicast addresses was received: if you need the interface > value in this case you have to use a more specific device. > So to specify an interface index for global unicast addresses, I should use IPV6_PKTINFO instead of the scope_id. 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 Wed Sep 1 12:43:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA29253 for ipng-dist; Wed, 1 Sep 1999 12:32: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 MAA29246 for ; Wed, 1 Sep 1999 12:31:39 -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 MAA10952 for ; Wed, 1 Sep 1999 12:31:12 -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 NAA09930 for ; Wed, 1 Sep 1999 13:31:10 -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 VAA12710; Wed, 1 Sep 1999 21:31:09 +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 VAA32513; Wed, 1 Sep 1999 21:31:08 +0200 (MET DST) Message-Id: <199909011931.VAA32513@givry.inria.fr> From: Francis Dupont To: "Aaron Griggs" cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-reply-to: Your message of Wed, 01 Sep 1999 14:55:13 EDT. <015201bef4ab$861969f0$634cf526@east.isi.edu> Date: Wed, 01 Sep 1999 21:31:06 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => because the scope_id is defined (?) only for local scopes. Basic Socket Interface Extensions for IPv6 (rfc 2553) says about sin6_scope_id: The sin6_scope_id field is a 32-bit integer that identifies a set of interfaces as appropriate for the scope of the address carried in the sin6_addr field. For a link scope sin6_addr sin6_scope_id would be an interface index. For a site scope sin6_addr, sin6_scope_id would be a site identifier. The mapping of sin6_scope_id to an interface or set of interfaces is left to implementation and future specifications on the subject of site identifiers. I assumed link scope sin6_addr was both link-local and global. Maybe, specifying "link-local" instead of "link" would help clarify. => you know the English language far more than me but I believe that "link-local scope" == "link scope" + a redundancy ? So to specify an interface index for global unicast addresses, I should use IPV6_PKTINFO instead of the scope_id. => until the sin6_scope_id semantic is defined for the global scope I think you have to do that but it is only useful when you have multiple routes for the same destination (then the kernel can select one using the specified interface). Is it something really useful? All the examples with IPV6_PKTINFO (and now sin6_scope_id) are not with global unicasts. 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 Wed Sep 1 17:05:02 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA29688 for ipng-dist; Wed, 1 Sep 1999 17:01: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 RAA29681 for ; Wed, 1 Sep 1999 17:01: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 RAA29546 for ; Wed, 1 Sep 1999 17:01:08 -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 RAA02481 for ; Wed, 1 Sep 1999 17:01:07 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 01 Sep 1999 16:06:53 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2448.0) id ; Wed, 1 Sep 1999 16:06:53 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145158E1@RED-MSG-50> From: Richard Draves To: "'Francis Dupont'" , "'Brian Haberman'" Cc: ipng@sunroof.eng.sun.com Subject: RE: node-local mc & the API Date: Wed, 1 Sep 1999 16:06:42 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Francis Dupont [mailto:Francis.Dupont@inria.fr] > Does the API require/allow any special restrictions on > node-local multicast > addresses. For example, can an implementation require that > node-local > multicast addresses only be assigned to a loopback interface? > > => I don't understand what you means by "assigned". > Do you suggest a JOIN can be done only on a loopback interface if > the multicast address is a node-local one? I'm not promoting any particular position (at least not yet), I'm just trying to figure out the semantics of node-local multicast addresses in the API so I can implement them properly. Many implementations have the concept of a loopback interface. So when an application does IPV6_JOIN_GROUP, and ipv6mr_multiaddr is node-local, can ipv6mr_interface specify a loopback interface? Can it specify a non-loopback interface? > From: Brian Haberman [mailto:haberman@raleigh.ibm.com] > > How do node-local multicast addresses interact with the > IPV6_MULTICAST_LOOP > > option? If the option is set to disallow loopback, I assume > that means > > transmissions will get dropped in the bit bucket? > > I was under the impression that node-local multicast does not > really > follow the same loopback conventions as other multicast addresses do. > The > reason is that the packet addressed is not meant to leave the > box so if > anything in the node is "joined" to the group, it will get > the packet. > I > suppose that you could look at it as when an app joins to that > node-local > address, the loopback state is automatically enabled. It makes more sense to me that IPV6_MULTICAST_LOOP apply uniformly to all scopes of multicast addresses. 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 Sep 1 20:17:10 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA29833 for ipng-dist; Wed, 1 Sep 1999 20:14:13 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29826 for ; Wed, 1 Sep 1999 20:14:02 -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 UAA712533; Wed, 1 Sep 1999 20:13:59 -0700 (PDT) Date: Wed, 1 Sep 1999 20:11:43 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) To: Tim Hartrick Cc: Erik.Nordmark@eng.sun.com, vlad@zk3.dec.com, Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199909011624.JAA02715@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > sockaddr_dl? Where did that come from. The IPV6_NEXTHOP options uses a > sockaddr_in6. There is language in the document which implies that the > sockaddr in the option could be some other kind of sockaddr but that seems > like unnecessary flexibility/complexity. It is IPV6_NEXTHOP and should only > apply to IPv6. I don't think we should be defining some generic next hop > option and if we are then it should be called SO_NEXTHOP and all of the > permutations should be specified. I know I don't want to go there. I somehow forgot that sockaddr_in6 has an ifindex. Sorry for my confusion. > As you note, the IPV6_PKTINFO and the IPV6_NEXTHOP can contain conflicting > information. The choices of how to deal with these conflicts are myriad. > > We could use the last interface specified. We could fail the operation if > there is a conflict.... I would probably opt for the former. Well, "last specified" isn't well defined when a single sendmsg can carry more than once ifindex (sounds like 3 currently with sin6_scope_id in the destination, in IPV6_PKTINFO, and in sin6_scope_id in the nexthop). > > For IPV6_PKTINFO there might be a difference whether it is a sticky option > > or in ancillary data. > > > > I am not sure what you mean here. A possible choice would be IPV6_PKTINFO in acillary data overrides sin6_scope_id in the destination but sin6_scope_id in the destination overrides a sticky IPV6_PKTINFO I'm not saying that this makes sense - I'm just saying that when exploring the precedence rules we need to think about possible differences whether a pirce of information is used as a sticky option or as ancillary data. But - I have a few more older emails to go through (as I edit the document for clarity - makes the process somewhat slow :-( Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 1 20:20:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA29855 for ipng-dist; Wed, 1 Sep 1999 20:18:57 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29848 for ; Wed, 1 Sep 1999 20:18:47 -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 UAA714655; Wed, 1 Sep 1999 20:18:43 -0700 (PDT) Date: Wed, 1 Sep 1999 20:16:27 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) To: Tim Hartrick Cc: jinmei@isl.rdc.toshiba.co.jp, Erik.Nordmark@eng.sun.com, vlad@zk3.dec.com, Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199909011633.JAA02724@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would say yes. The scope-id (the interface index in your example) is > really part of the address. For systems that use the same link token on all > their interfaces the ability to bind to a specific local address and get only > datagrams destined for that address is, in my opinion, essential. Tim, I'm not directly disagreeing with you but in general this is not sufficient. Certain applications might desire to only receive packets on one interface while still being able to receive both unicast as well as one or more multicast addresses. Either the app can use N sockets each bound to a link local unicast/multicast address with the appropriate scope-ip, or use single in6addr_any socket and IPV6_RCVPKTINFO to throw away the undesired packets. It seems like we are creating multiple mechanisms to do the same thing. How do we gauge when we have enough mechanism? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 1 20:24:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA29877 for ipng-dist; Wed, 1 Sep 1999 20:23:13 -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 UAA29870 for ; Wed, 1 Sep 1999 20:23:02 -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 UAA02356; Wed, 1 Sep 1999 20:23:01 -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 UAA05240; Wed, 1 Sep 1999 20:23:00 -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 UAA18357; Wed, 1 Sep 1999 20:23: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 UAA02736; Wed, 1 Sep 1999 20:23:52 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id UAA03021; Wed, 1 Sep 1999 20:23:57 -0700 (PDT) Date: Wed, 1 Sep 1999 20:23:57 -0700 (PDT) From: Tim Hartrick Message-Id: <199909020323.UAA03021@feller.mentat.com> To: Erik.Nordmark@eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) Cc: vlad@zk3.dec.com, Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From Erik.Nordmark@eng.sun.com Wed Sep 1 20:14:59 1999 > Received: from roll.mentat.com (roll [192.88.122.129]) > by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id UAA02470 > for ; Wed, 1 Sep 1999 20:14:58 -0700 (PDT) > Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) > by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id UAA18320 > for ; Wed, 1 Sep 1999 20:14:57 -0700 (PDT) > Received: from sunmail1.Sun.COM ([129.145.1.2]) > by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA29413; > Wed, 1 Sep 1999 20:14:02 -0700 (PDT) > Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) Erik, > > Well, "last specified" isn't well defined when a single sendmsg can carry more > than once ifindex (sounds like 3 currently with sin6_scope_id in the > destination, in IPV6_PKTINFO, and in sin6_scope_id in the nexthop). > Sure we need to define the ordering. I would say that the address would be first, and the options would be considered in the same order they are placed in the cmsghdr vector. > > > For IPV6_PKTINFO there might be a difference whether it is a sticky option > > > or in ancillary data. > > > > > > > I am not sure what you mean here. > > A possible choice would be > IPV6_PKTINFO in acillary data overrides sin6_scope_id in the destination > but > sin6_scope_id in the destination overrides a sticky IPV6_PKTINFO > > I'm not saying that this makes sense - I'm just saying that when exploring > the precedence rules we need to think about possible differences > whether a pirce of information is used as a sticky option or > as ancillary data. > I see. Any chance that the problem can be done away with by simply not allowing IPV6_PKTINFO and IPV6_NEXTHOP to be sticky? Do they have much utility as sticky options for a TCP connection? Just asking while trying to sort out all these permutations..... 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 Wed Sep 1 20:29:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA29903 for ipng-dist; Wed, 1 Sep 1999 20:27:30 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29896 for ; Wed, 1 Sep 1999 20:27:19 -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 UAA718640; Wed, 1 Sep 1999 20:27:17 -0700 (PDT) Date: Wed, 1 Sep 1999 20:25:01 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) To: Aaron Griggs Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <011f01bef4a5$234be470$634cf526@east.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is there a reason why scope_id is not used for the global unicast addresses? There are two different ways to answer. 1. The scope-id isn't an interface index - it is something which identifies the "domain" to which the address belongs. For global addresses there is only one domain ("global") since they are globally routable. For link-local and site-local there are potentially multiple domains. 2. The motivation for adding sin6_scope_id was so that a class of simple applications (like the UDP echo server which calls recvfrom and then sendto) will work on nodes with multiple interfaces (for link-local addresses) and on "multi-sited" nodes (for site-local addresses). The advanced API has support for applications which want to control the outbound interface (as well as other parameters) independent of the scope of the destination address. Erik > > > Which value should the kernel set to sin6_scope_id when receiving > > > from a global address? > > > > Zero. > > Again, why not set the interface value on which the global unicast addresses > was received? > > 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 Wed Sep 1 20:36:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA29930 for ipng-dist; Wed, 1 Sep 1999 20:34: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 UAA29923 for ; Wed, 1 Sep 1999 20:34: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 UAA23395; Wed, 1 Sep 1999 20:34:45 -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 UAA07941; Wed, 1 Sep 1999 20:34:45 -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 UAA18439; Wed, 1 Sep 1999 20:35:37 -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 UAA02999; Wed, 1 Sep 1999 20:35:37 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id UAA03026; Wed, 1 Sep 1999 20:35:41 -0700 (PDT) Date: Wed, 1 Sep 1999 20:35:41 -0700 (PDT) From: Tim Hartrick Message-Id: <199909020335.UAA03026@feller.mentat.com> To: Erik.Nordmark@eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) Cc: jinmei@isl.rdc.toshiba.co.jp, vlad@zk3.dec.com, Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > I'm not directly disagreeing with you but in general this is not > sufficient. > Certain applications might desire to only receive packets on one > interface while still being able to receive both unicast as well as > one or more multicast addresses. > > Either the app can use N sockets each bound to a link local unicast/multicast > address with the appropriate scope-ip, or use single in6addr_any > socket and IPV6_RCVPKTINFO to throw away the undesired packets. > > It seems like we are creating multiple mechanisms to do the same thing. > How do we gauge when we have enough mechanism? > We certainly have lots of ways to solve the interface specification problem as was noted earlier by Itojun I think. This is an unfortunate consequence of not developing the basic and advanced APIs together. Do you see an easy way throw out something that is superfluous? If we don't need to be compatible with existing 2292 we could be a little more vicious about reworking this. For example we could completely rethink PKTINFO and NEXTHOP and see if we can come up with alternatives that have less duplication of capability with the scope-id. Just off the top of my head, of course. I haven't really given it much thought. 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 Wed Sep 1 21:40:15 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA29977 for ipng-dist; Wed, 1 Sep 1999 21:37:01 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29970 for ; Wed, 1 Sep 1999 21:36:49 -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 VAA749125; Wed, 1 Sep 1999 21:36:48 -0700 (PDT) Date: Wed, 1 Sep 1999 21:34:32 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: node-local mc & the API To: Richard Draves Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D810145158CB@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does the API require/allow any special restrictions on node-local multicast > addresses. For example, can an implementation require that node-local > multicast addresses only be assigned to a loopback interface? I think "assigned" is a poor term here. Presumably you are asking both about joining multicast groups as well as sending to multicast groups, since interfaces can be optionally specified for both cases. I haven't seen anything in the API that restricts the behavior in any way. And the implications of adding such limitations might be far reaching. Why would node-local be special? One could also envision requirements on greater than link-local scope such as there must be at least one default router on the interface! I think we don't want to head down that path and leave it unspecified. Or we could clarify (when we open up the basic API again) that node-local scope can be used on any interface. > How do node-local multicast addresses interact with the IPV6_MULTICAST_LOOP > option? If the option is set to disallow loopback, I assume that means > transmissions will get dropped in the bit bucket? Your assumption matches my assumption. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 1 22:30:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA00019 for ipng-dist; Wed, 1 Sep 1999 22:21:33 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA00012 for ; Wed, 1 Sep 1999 22:21:21 -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 WAA765066; Wed, 1 Sep 1999 22:21:20 -0700 (PDT) Date: Wed, 1 Sep 1999 22:19:04 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses To: itojun@iijlab.net Cc: Bob Halley , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <15428.935059203@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 > For example, with regard to IPv4 mapped address, the current document > falis to define the kernel behavior, like: > - what should happen when IPv6 wildcard bind(2) is performed on > port X, then IPv4 specific bind(2) is performed onto port X > Actually current document defined nothing about port number space > treatment (whether IPv6 TCP port number space and IPv4 TCP port number > space is unified, or separated). I recall there being some email discussion on this a while back, but I don't recall if we reached consensus. In any case, this would be a clarification to the basic API. > There are too many interactions between two AFs introduced by > IPv4 mapped address. I do not think it to be healthy. I agree that adding much more features to mapped address support adds a lot of complexity. We've stayed away from any IP* options when using mapped addresses. Thus you can use IPPROTO_IP options on AF_INET sockets. And you can use IPPROTO_IPV6 options on AF_INET6 sockets as long as they are not bound or connected to a mapped address. This limitation helps preserve some sanity in the IP code. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 1 22:30:58 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA00028 for ipng-dist; Wed, 1 Sep 1999 22:25:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA00021 for ; Wed, 1 Sep 1999 22:24:51 -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 WAA766239; Wed, 1 Sep 1999 22:24:50 -0700 (PDT) Date: Wed, 1 Sep 1999 22:22:35 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) To: Francis Dupont Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , tim@mentat.com, vlad@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199908161627.SAA27400@givry.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => multicast addresses are exactly like link-local addresses even > they have their own scope because a multicast destination without > the outgoing interface is incomplete. Hmm, the IPv4 code (and our IPv6 code as well) can send multicast packets without any interface information. If there is no IP*_MULTICAST_IF (or sin6_scope_id, or IPV6_PKTINFO with ifindex) then the kernel will do a *unicast* route lookup for 224.0.0.0 in the IPv4 case. This will find the "default multicast interface". If we preserve this behavior in IPv6 we can treat the multicast scope issues the same as the unicast scope issues. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 1 22:49:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA00076 for ipng-dist; Wed, 1 Sep 1999 22:47:13 -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 WAA00067 for ; Wed, 1 Sep 1999 22:47:01 -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 WAA10695; Wed, 1 Sep 1999 22:47:02 -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 WAA11188; Wed, 1 Sep 1999 22:47:00 -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 OAA00715; Thu, 2 Sep 1999 14:46:54 +0900 (JST) To: Erik Nordmark cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Wed, 01 Sep 1999 22:19:04 MST. 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: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses From: itojun@iijlab.net Date: Thu, 02 Sep 1999 14:46:53 +0900 Message-ID: <713.936251213@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> For example, with regard to IPv4 mapped address, the current document >> falis to define the kernel behavior, like: >> - what should happen when IPv6 wildcard bind(2) is performed on >> port X, then IPv4 specific bind(2) is performed onto port X >> Actually current document defined nothing about port number space >> treatment (whether IPv6 TCP port number space and IPv4 TCP port number >> space is unified, or separated). >I recall there being some email discussion on this a while back, >but I don't recall if we reached consensus. >In any case, this would be a clarification to the basic API. For bind(2) ordering, I'm not sure if we can define behaviors for all the possibilities, there are too many cases. For port number space issue, I heard from someone that X/Open defined it to some extent. I don't have access to documents so take it as a rumor until someone confirms it. Also, Rich Stevens' book assumed something on it (I'll check it later). We may want to follow them, or fix them. 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 Sep 2 03:43:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA00243 for ipng-dist; Thu, 2 Sep 1999 03:40:29 -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 DAA00236 for ; Thu, 2 Sep 1999 03:40: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 DAA02370 for ; Thu, 2 Sep 1999 03:40:17 -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 DAA25941 for ; Thu, 2 Sep 1999 03:40:15 -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 GAA29688; Thu, 2 Sep 1999 06:39:19 -0400 (EDT) Message-Id: <199909021039.GAA29688@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 Router Alert Option to Proposed Standard Date: Thu, 02 Sep 1999 06:39:19 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IPv6 Router Alert Option' 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 This document describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path. For example, a Router Alert option is included in Multicast Listener Discovery (MLD) packets containing Listener Reports, which are sent to multicast groups but must also be processed by neighboring routers. Working Group Summary This document has traveled a long and tortuous path. At one point, attempts were made to reconcile the differing semantics of the IPv4 and IPv6 Router Alert options. Those attempts were ultimately unsuccessful, as there were compelling reasons for the v6 semantics and the but they were not compelling enough to change the v4 version of the option, which has been deployed. There was support in the WG for the current version of the option and no issues were raised during the last call. Protocol Quality This document has been reviewed for the IESG by Thomas Narten and Erik Nordmark. There are multiple implementations of the option. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 2 03:48:07 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA00265 for ipng-dist; Thu, 2 Sep 1999 03:47: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 DAA00258 for ; Thu, 2 Sep 1999 03:46:58 -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 DAA15281 for ; Thu, 2 Sep 1999 03:46:58 -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 EAA28667 for ; Thu, 2 Sep 1999 04:46:57 -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 GAA29732; Thu, 2 Sep 1999 06:46:16 -0400 (EDT) Message-Id: <199909021046.GAA29732@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: Multicast Listener Discovery (MLD) for IPv6 to Proposed Standard Date: Thu, 02 Sep 1999 06:46:16 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Multicast Listener Discovery (MLD) for IPv6' 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 This document specifies the protocol used by an IPv6 router to dis- cover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as Multicast Listener Discovery or MLD. MLD is derived from version 2 of IPv4's Internet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 message types, rather than IGMP message types. Working Group Summary There was strong support in the WG for this document and no issues were raised during the last call. Protocol Quality This protocol has been reviewed for the IESG by Thomas Narten and Erik Nordmark. Multiple implementations already exist. Note to RFC Editor: The IESG requests the RFC Editor to remove section 13 (changes since last draft) prior to publication. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 2 08:46:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA00526 for ipng-dist; Thu, 2 Sep 1999 08:43: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 IAA00518 for ; Thu, 2 Sep 1999 08:43: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 IAA29073 for ; Thu, 2 Sep 1999 08:43:24 -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 JAA21252 for ; Thu, 2 Sep 1999 09:43:17 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id RAA21237 for ipng@sunroof.eng.sun.com; Thu, 2 Sep 1999 17:42:59 +0200 (MET DST) Message-ID: <19990902174259.A21195@theory.cs.uni-bonn.de> Date: Thu, 2 Sep 1999 17:42:59 +0200 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: Typo in RFC 2461 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, when re-reading the RFC 2461, I found a typo... In ``3.1 Comparison with IPv4'' on page 14, it says: Address resolution multicasts are "spread" over 4 billion (2^32) multicast addresses greatly reducing address resolution related interrupts on nodes other than the target. Moreover, non-IPv6 machines should not be interrupted at all. However, according to the Address Architecture document (RFC 2373), only 2^24 addresses are used. In a future revision of the document, this should be corrected, like this: Address resolution multicasts are "spread" over 16 million (2^24) multicast addresses greatly reducing address resolution related interrupts on nodes other than the target. Moreover, non-IPv6 machines should not be interrupted at all. [This should not cause any problems; this is not in the protocol description part of the document.] Regards, Ignatios Souvatzis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 2 13:46:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA00906 for ipng-dist; Thu, 2 Sep 1999 13:40: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 NAA00899 for ; Thu, 2 Sep 1999 13:39: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 NAA14807 for ; Thu, 2 Sep 1999 13:39:48 -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 NAA28526 for ; Thu, 2 Sep 1999 13:39:47 -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 QAA06996; Thu, 2 Sep 1999 16:39:45 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id QAA02688; Thu, 2 Sep 1999 16:39:04 -0400 (EDT) Received: from m22025-pc.mitre.org (128.29.105.55) by mailhub1.mitre.org with SMTP id 1519332; Thu, 02 Sep 1999 16:39:41 EST Message-ID: <37CEE09B.28C6C203@mitre.org> Date: Thu, 02 Sep 1999 16:39:55 -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: Scott Bradner CC: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd References: <199908270013.UAA06251@newdev.harvard.edu> Content-Type: multipart/mixed; boundary="------------0F4B7E625C8BB56610DC4A91" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------0F4B7E625C8BB56610DC4A91 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hinden, Bradner and all, I am one of the passive readers of e-mails on IPv6 that show up on my screen everyday as they do on yours. Not withstanding all the time I (and at least another engineer working with me) spend on going through the e-mails and try to grasp the significance of the various comments, a few things stand out. You folks appear a little too concerned about crticism of an engineering standard (or set of standands in development) that has no single implementation, commercial or institutional, that we could find that is worthy of a mention. And, you do unfairly, if not unprofessionally, (as Jeff Williams points out) pick on Adhikari. So, here is the challenge, show us ONE real-world example of a decent-size IPv6 implementation for all the work and all the man-years that have been expended on it. If not, could we request that someone in the communicty of developers of standards and implementations justify why the alternate IPv4 solutions should be discarded or why people be concerned about IPv6 at all. Chakravorty Scott Bradner wrote: > > the author's bio line > > Richard Adhikari is a leading journalist on advanced-IP issues for several > major publications, including The Wall Street Journal, and is a regular > contributor to Planet IT. > > does not speak well for the wsj > > Scott > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------0F4B7E625C8BB56610DC4A91 Content-Type: text/x-vcard; charset=us-ascii; name="schakra.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sham Chakravorty Content-Disposition: attachment; filename="schakra.vcf" begin:vcard n:Chakravorty;Sham tel;fax:703-883-7142 tel;work:703-883-6841 x-mozilla-html:FALSE org:W15F adr:;;;Washington;;; version:2.1 email;internet:schakra@mitre.org x-mozilla-cpt:;-14304 fn:Sham Chakravorty end:vcard --------------0F4B7E625C8BB56610DC4A91-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 2 23:28:08 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d836PXh01432 for ipng-dist; Thu, 2 Sep 1999 23:25:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d836PNI01425 for ; Thu, 2 Sep 1999 23:25: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 XAA08190; Thu, 2 Sep 1999 23:25:22 -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 XAA05551; Thu, 2 Sep 1999 23:25:15 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id PAA02496; Fri, 3 Sep 1999 15:16:23 +0900 (JST) Date: Fri, 03 Sep 1999 15:27:24 +0900 Message-ID: <14287.27212.484722.65113P@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Tue, 31 Aug 1999 14:05:08 -0700 (PDT)" References: <14263.50679.209399.57571Q@condor.isl.rdc.toshiba.co.jp> User-Agent: Wanderlust/2.1.4 (Tears In Heaven) 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: 227 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 31 Aug 1999 14:05:08 -0700 (PDT), >>>>> Erik Nordmark said: >> Though the meaning does not change, the names defined in the RFC 2292 >> (and 2292bis) are a bit confusing for application programmers. >> Just FYI, KAME locally defines the following definitions (please note >> that we don't insist on these local definitions at all): >> >> #define MLD6_LISTENER_QUERY 130 /* multicast listener query */ >> #define MLD6_LISTENER_REPORT 131 /* multicast listener report */ >> #define MLD6_LISTENER_DONE 132 /* multicast listener done */ > To be consitent with ND_ (and since the protocol is really MLD and > not MLDv6) it would make sense to use the MLD_ prefix instead of MLD6_. Okay. >> I admit that it's hard (even impossible) to catch up all such new >> protocols, but 2292bis would be a good opportunity. I hope the revised >> API reflects as much changes as possible. > I agree that this would make sense. > Have you guys defined data structures for the above packet/option > formats in addition to the constants you list below? Yes, I'll show them below: MLD related structure (and shortcut macros): struct mld6_hdr { struct icmp6_hdr mld6_hdr; struct in6_addr mld6_addr; /* multicast address */ }; #define mld6_type mld6_hdr.icmp6_type #define mld6_code mld6_hdr.icmp6_code #define mld6_cksum mld6_hdr.icmp6_cksum #define mld6_maxdelay mld6_hdr.icmp6_data16[0] #define mld6_reserved mld6_hdr.icmp6_data16[1] ============ Router Renumbering related structures: #if BYTE_ORDER == BIG_ENDIAN /* net byte order */ struct icmp6_router_renum { /* router renumbering header */ struct icmp6_hdr rr_hdr; u_int8_t rr_segnum; u_int8_t rr_test : 1; u_int8_t rr_reqresult : 1; u_int8_t rr_forceapply : 1; u_int8_t rr_specsite : 1; u_int8_t rr_prevdone : 1; u_int8_t rr_flags_reserved : 3; u_int16_t rr_maxdelay; u_int32_t rr_reserved; }; #elif BYTE_ORDER == LITTLE_ENDIAN struct icmp6_router_renum { /* router renumbering header */ struct icmp6_hdr rr_hdr; u_int8_t rr_segnum; u_int8_t rr_flags_reserved : 3; u_int8_t rr_prevdone : 1; u_int8_t rr_specsite : 1; u_int8_t rr_forceapply : 1; u_int8_t rr_reqresult : 1; u_int8_t rr_test : 1; u_int16_t rr_maxdelay; u_int32_t rr_reserved; }; #endif /* BYTE_ORDER */ #define rr_type rr_hdr.icmp6_type #define rr_code rr_hdr.icmp6_code #define rr_cksum rr_hdr.icmp6_cksum #define rr_seqnum rr_hdr.icmp6_data32[0] struct rr_pco_match { /* match prefix part */ u_int8_t rpm_code; u_int8_t rpm_len; u_int8_t rpm_ordinal; u_int8_t rpm_matchlen; u_int8_t rpm_minlen; u_int8_t rpm_maxlen; u_int16_t rpm_reserved; struct in6_addr rpm_prefix; }; #define RPM_PCO_ADD 1 #define RPM_PCO_CHANGE 2 #define RPM_PCO_SETGLOBAL 3 #define RPM_PCO_MAX 4 #if BYTE_ORDER == BIG_ENDIAN /* net byte order */ struct rr_pco_use { /* use prefix part */ u_int8_t rpu_uselen; u_int8_t rpu_keeplen; u_int8_t rpu_mask_onlink : 1; u_int8_t rpu_mask_autonomous : 1; u_int8_t rpu_mask_reserved : 6; u_int8_t rpu_onlink : 1; u_int8_t rpu_autonomous : 1; u_int8_t rpu_raflags_reserved : 6; u_int32_t rpu_vltime; u_int32_t rpu_pltime; u_int32_t rpu_decr_vltime : 1; u_int32_t rpu_decr_pltime : 1; u_int32_t rpu_flags_reserved : 6; u_int32_t rpu_reserved : 24; struct in6_addr rpu_prefix; }; #elif BYTE_ORDER == LITTLE_ENDIAN struct rr_pco_use { /* use prefix part */ u_int8_t rpu_uselen; u_int8_t rpu_keeplen; u_int8_t rpu_mask_reserved : 6; u_int8_t rpu_mask_autonomous : 1; u_int8_t rpu_mask_onlink : 1; u_int8_t rpu_raflags_reserved : 6; u_int8_t rpu_autonomous : 1; u_int8_t rpu_onlink : 1; u_int32_t rpu_vltime; u_int32_t rpu_pltime; u_int32_t rpu_flags_reserved : 6; u_int32_t rpu_decr_pltime : 1; u_int32_t rpu_decr_vltime : 1; u_int32_t rpu_reserved : 24; struct in6_addr rpu_prefix; }; #endif /* BYTE_ORDER */ #if BYTE_ORDER == BIG_ENDIAN /* net byte order */ struct rr_result { /* router renumbering result message */ u_int8_t rrr_reserved; u_int8_t rrr_flags_reserved : 6; u_int8_t rrr_outofbound : 1; u_int8_t rrr_forbidden : 1; u_int8_t rrr_ordinal; u_int8_t rrr_matchedlen; u_int32_t rrr_ifid; struct in6_addr rrr_prefix; }; #elif BYTE_ORDER == LITTLE_ENDIAN struct rr_result { /* router renumbering result message */ u_int8_t rrr_reserved; u_int8_t rrr_forbidden : 1; u_int8_t rrr_outofbound : 1; u_int8_t rrr_flags_reserved : 6; u_int8_t rrr_ordinal; u_int8_t rrr_matchedlen; u_int32_t rrr_ifid; struct in6_addr rrr_prefix; }; #endif /* BYTE_ORDER */ ============ ICMPv6 name lookups related structures and macros: struct icmp6_nodeinfo { struct icmp6_hdr icmp6_ni_hdr; u_int64_t icmp6_ni_nonce; /* could be followed by reply data */ }; #define ni_type icmp6_ni_hdr.icmp6_type #define ni_code icmp6_ni_hdr.icmp6_code #define ni_cksum icmp6_ni_hdr.icmp6_cksum #define ni_qtype icmp6_ni_hdr.icmp6_data16[0] #define ni_flags icmp6_ni_hdr.icmp6_data16[1] #define NI_QTYPE_NOOP 0 /* NOOP */ #define NI_QTYPE_SUPTYPES 1 /* Supported Qtypes */ #define NI_QTYPE_FQDN 2 /* FQDN */ #define NI_QTYPE_NODEADDR 3 /* Node Addresses. XXX: spec says 2, but it may be a typo... */ #if BYTE_ORDER == BIG_ENDIAN #define NI_SUPTYPE_FLAG_COMPRESS 0x1 #define NI_FQDN_FLAG_VALIDTTL 0x1 #define NI_NODEADDR_FLAG_LINKLOCAL 0x1 #define NI_NODEADDR_FLAG_SITELOCAL 0x2 #define NI_NODEADDR_FLAG_GLOBAL 0x4 #define NI_NODEADDR_FLAG_ALL 0x8 #define NI_NODEADDR_FLAG_TRUNCATE 0x10 #elif BYTE_ORDER == LITTLE_ENDIAN #define NI_SUPTYPE_FLAG_COMPRESS 0x0100 #define NI_FQDN_FLAG_VALIDTTL 0x0100 #define NI_NODEADDR_FLAG_LINKLOCAL 0x0100 #define NI_NODEADDR_FLAG_SITELOCAL 0x0200 #define NI_NODEADDR_FLAG_GLOBAL 0x0400 #define NI_NODEADDR_FLAG_ALL 0x0800 #define NI_NODEADDR_FLAG_TRUNCATE 0x1000 #endif struct ni_reply_fqdn { u_int32_t ni_fqdn_ttl; /* TTL */ u_int8_t ni_fqdn_namelen; /* length in octets of the FQDN */ u_int8_t ni_fqdn_name[3]; /* XXX: alignment */ }; ============ macros for IPv6 (HbH and destination) options (some of them might be unnecessary): #define IP6OPT_PAD1 0x00 /* 00 0 00000 */ #define IP6OPT_PADN 0x01 /* 00 0 00001 */ #define IP6OPT_JUMBO 0xC2 /* 11 0 00010 = 194 */ #define IP6OPT_JUMBO_LEN 6 #define IP6OPT_TYPE(o) ((o) & 0xC0) #define IP6OPT_TYPE_SKIP 0x00 #define IP6OPT_TYPE_DISCARD 0x40 #define IP6OPT_TYPE_FORCEICMP 0x80 #define IP6OPT_TYPE_ICMP 0xC0 #define IP6OPT_MUTABLE 0x20 ============ Generic structure for IPv6 extension headers: (this might be unnecessary, but we belive this is useful) struct ip6_ext { u_char ip6e_nxt; u_char ip6e_len; }; ============ (end of our definitions) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 2 23:32:58 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d836Vwt01478 for ipng-dist; Thu, 2 Sep 1999 23:31:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d836VnI01471 for ; Thu, 2 Sep 1999 23:31:49 -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 XAA00977; Thu, 2 Sep 1999 23:31:50 -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 AAA03950; Fri, 3 Sep 1999 00:31:45 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id PAA02513; Fri, 3 Sep 1999 15:22:55 +0900 (JST) Date: Fri, 03 Sep 1999 15:33:55 +0900 Message-ID: <14287.27603.931580.39645R@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Tue, 31 Aug 1999 14:22:59 -0700 (PDT)" References: <14263.60698.673536.12718B@condor.isl.rdc.toshiba.co.jp> User-Agent: Wanderlust/2.1.4 (Tears In Heaven) 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: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 31 Aug 1999 14:22:59 -0700 (PDT), >>>>> Erik Nordmark said: >> - suppose that we set a non-zero value to sin6_scope_id, set a >> link-local address to sin6_addr, and call bind() with the socket >> address. When we try to send a packet to the socket, should the >> kernel send the packet to the interface specified by the >> sin6_scope_id passed to bind()? > Good question. > bind() conceptually specifies the local part of the address and not > where things are sent. > Thus it would make more sense to ask > if you bind to link-local X with ifindex 2 > will that reject packets sent to link-local address X which arrive on some > other interface? In KAME, the answer is yes. The KAME kernel always takes interface indices into accont when looking up PCB for a packet with link-local source or destination. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 2 23:44:26 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d836ept01544 for ipng-dist; Thu, 2 Sep 1999 23:40:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d836ehI01537 for ; Thu, 2 Sep 1999 23:40: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 XAA01365; Thu, 2 Sep 1999 23:40:43 -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 AAA05221; Fri, 3 Sep 1999 00:40:41 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id PAA02551; Fri, 3 Sep 1999 15:31:51 +0900 (JST) Date: Fri, 03 Sep 1999 15:42:53 +0900 Message-ID: <14287.28141.257440.75679V@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Tue, 31 Aug 1999 14:05:08 -0700 (PDT)" References: <14263.50679.209399.57571Q@condor.isl.rdc.toshiba.co.jp> User-Agent: Wanderlust/2.1.4 (Tears In Heaven) 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: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 31 Aug 1999 14:05:08 -0700 (PDT), >>>>> Erik Nordmark said: >> Moreover, there are some new protocols that have been defined since >> RFC 2292 and are about to be standardized, e.g. >> >> Router Renumbering >> Router Alert Option >> ICMPv6 name lookups > Is name lookups moving forward? Is it close to a WG last call? > (I haven't heard much about it.) (Sorry, I missed the comment above.) As far as I know, there's been no action to proceed ICMPv6 name lookups. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 3 00:04:51 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8371wx01619 for ipng-dist; Fri, 3 Sep 1999 00:01:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8371lI01612 for ; Fri, 3 Sep 1999 00:01:47 -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 AAA13329; Fri, 3 Sep 1999 00:01:46 -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 BAA08478; Fri, 3 Sep 1999 01:01:46 -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 AAA23148; Fri, 3 Sep 1999 00:02:40 -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 AAA25178; Fri, 3 Sep 1999 00:02:41 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id AAA10814; Fri, 3 Sep 1999 00:02:42 -0700 (PDT) Date: Fri, 3 Sep 1999 00:02:42 -0700 (PDT) From: Tim Hartrick Message-Id: <199909030702.AAA10814@feller.mentat.com> To: Erik.Nordmark@eng.sun.com, jinmei@isl.rdc.toshiba.co.jp Subject: Re: Comments on 2292bis (Adv. API) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > ============ > Router Renumbering related structures: > #if BYTE_ORDER == BIG_ENDIAN /* net byte order */ > struct icmp6_router_renum { /* router renumbering header */ > struct icmp6_hdr rr_hdr; > u_int8_t rr_segnum; > u_int8_t rr_test : 1; > u_int8_t rr_reqresult : 1; > u_int8_t rr_forceapply : 1; > u_int8_t rr_specsite : 1; > u_int8_t rr_prevdone : 1; > u_int8_t rr_flags_reserved : 3; > u_int16_t rr_maxdelay; > u_int32_t rr_reserved; > }; > #elif BYTE_ORDER == LITTLE_ENDIAN > struct icmp6_router_renum { /* router renumbering header */ > struct icmp6_hdr rr_hdr; > u_int8_t rr_segnum; > u_int8_t rr_flags_reserved : 3; > u_int8_t rr_prevdone : 1; > u_int8_t rr_specsite : 1; > u_int8_t rr_forceapply : 1; > u_int8_t rr_reqresult : 1; > u_int8_t rr_test : 1; > u_int16_t rr_maxdelay; > u_int32_t rr_reserved; > }; > #endif /* BYTE_ORDER */ > If I am remembering my ANSI C correctly there are a couple of problems with definitions which make use of bitfields. First, the ANSI standard does not support the declaration of bitfields based on any type other than unsigned int. Secondly, the implementation of bitfields is allowed to vary substantially from one compiler and/or architecture to another. Some compilers for some architectures may choose to pack bitfields in a way that would make both the above definitions useless regardless of byte order. If this specification is to be portable I believe that we will need to define structures in a way that does not run afoul of the architecturally flexible parts of the ANSI C language standard. Lastly, ignoring the possible portability problems, some compilers generate code for bitfield operations which performs really poorly relative to code that uses scalar types and bit operators. Based on this alone I would recommend that we not attempt to use bitfields. 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 Fri Sep 3 05:34:42 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d83CUo801829 for ipng-dist; Fri, 3 Sep 1999 05:30:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d83CUfI01822 for ; Fri, 3 Sep 1999 05:30: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 FAA23836; Fri, 3 Sep 1999 05:30:39 -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 FAA27790; Fri, 3 Sep 1999 05:30:38 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id VAA11399; Fri, 3 Sep 1999 21:21:29 +0900 (JST) Date: Fri, 03 Sep 1999 21:32:28 +0900 Message-ID: <14287.49116.94774.30564X@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik.Nordmark@eng.sun.com Cc: Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Wed, 1 Sep 1999 22:22:35 -0700 (PDT)" References: <199908161627.SAA27400@givry.inria.fr> User-Agent: Wanderlust/2.1.4 (Tears In Heaven) 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 Wed, 1 Sep 1999 22:22:35 -0700 (PDT), >>>>> Erik Nordmark said: >> => multicast addresses are exactly like link-local addresses even >> they have their own scope because a multicast destination without >> the outgoing interface is incomplete. > Hmm, the IPv4 code (and our IPv6 code as well) can send multicast > packets without any interface information. > If there is no IP*_MULTICAST_IF (or sin6_scope_id, or IPV6_PKTINFO with > ifindex) then the kernel will do a *unicast* route lookup for 224.0.0.0 > in the IPv4 case. This will find the "default multicast interface". > If we preserve this behavior in IPv6 we can treat the multicast scope > issues the same as the unicast scope issues. That's right, but my impression is that it was a workaround for those who didn't have enough API to specify the outgoing interface of a multicast packet. Even if we install a route for ff00::/8 to an interface, we have to specify another interface via some API after all. IMO, we should not rely on a `default route' in the kernel for sending a multicast packet. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 3 06:03:26 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d83Cx5X01888 for ipng-dist; Fri, 3 Sep 1999 05:59:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d83CwuI01881 for ; Fri, 3 Sep 1999 05:58:56 -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 FAA25074 for ; Fri, 3 Sep 1999 05:58:55 -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 GAA13994 for ; Fri, 3 Sep 1999 06:57:41 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id VAA11488; Fri, 3 Sep 1999 21:47:42 +0900 (JST) Date: Fri, 03 Sep 1999 21:58:41 +0900 Message-ID: <14287.50689.861424.62646Q@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: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Fri, 3 Sep 1999 00:02:42 -0700 (PDT)" <199909030702.AAA10814@feller.mentat.com> References: <199909030702.AAA10814@feller.mentat.com> User-Agent: Wanderlust/2.1.4 (Tears In Heaven) 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 Fri, 3 Sep 1999 00:02:42 -0700 (PDT), >>>>> Tim Hartrick said: > If I am remembering my ANSI C correctly there are a couple of problems > with definitions which make use of bitfields. > First, the ANSI standard does not support the declaration of bitfields based > on any type other than unsigned int. > Secondly, the implementation of bitfields is allowed to vary substantially > from one compiler and/or architecture to another. Some compilers for some > architectures may choose to pack bitfields in a way that would make both the > above definitions useless regardless of byte order. > If this specification is to be portable I believe that we will need to define > structures in a way that does not run afoul of the architecturally flexible > parts of the ANSI C language standard. > Lastly, ignoring the possible portability problems, some compilers generate > code for bitfield operations which performs really poorly relative to code > that uses scalar types and bit operators. Based on this alone I would recommend > that we not attempt to use bitfields. Though currently I don't have a way to access ANSI C specification, your comment seems reasonable. Actually, we had a discussion in the KAME team that we could safely use bitfields, but I forgot the consensus. I personally agree with you; we shouldn't use bitfields (especially for packet formats) if we regard portability. I'll confirm the opinion of the author of the structures for router renumbering. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 3 21:26:14 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d844Mvq03001 for ipng-dist; Fri, 3 Sep 1999 21:22:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d844MmI02994 for ; Fri, 3 Sep 1999 21:22:48 -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 VAA07649 for ; Fri, 3 Sep 1999 21:22:46 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA28836 for ; Fri, 3 Sep 1999 21:22:45 -0700 (PDT) Received: from endor.eas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id AAA06036 for ; Sat, 4 Sep 1999 00:22:44 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.eas.harvard.edu (8.8.8/8.8.8) id AAA24338 for ipng@sunroof.eng.sun.com; Sat, 4 Sep 1999 00:22:42 -0400 (EDT) Date: Sat, 4 Sep 1999 00:22:42 -0400 (EDT) Message-Id: <199909040422.AAA24338@endor.eas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: |Philosophical desires aside, the reality today is that the IPv4 |addresses are no longer the stable identifiers that folks find |covenient. Wishing it otherwise won't make it so. I would have to disagree with this at least in part. IPv4 addresses remain the stable identifiers that they always were because no good alternative has been offered. Those who own portable address space continue to find this convenient, while those with ISP-specific CIDR addresses find it a disincentive to switching ISPs. The question is whether we really wish to make the latter case (and current status quo) the standard for all IPv6 end users. [snipping description I agree with] |How to do the mapping in a world where network address can change is a |very hard problem, if one wants a solution that scales to the size of |the Internet. I agree completely that this is a very hard problem. I also have my doubts that it can be pushed onto the DNS without significantly changing the DNS as we know it. My main concern, though, is that the problem will be avoided rather than solved. Towards the beginning of the development of IPv6's hierarchical address space the general notion seemed to be that nobody would get stable, portable address space and that sites could be renumbered almost on a whim. This model carried with it the strong implication that the stable identifier problem (which really encompasses the tcp session stability issue and many other similar issues) would have to be solved before the protocol would be of any use to anyone: the new addresses were by definition not usable as stable identifiers. Now several years later IPv6 is starting to be deployed (ok, maybe just for testing) and the problem remains unsolved. Because a complete solution may well require fairly deep changes, I worry that its implementation is becoming very unlikely as the protocol becomes more fixed. Moreover, we seem to be talking about giving ISPs portable IPv6 address space for multi-homing, and this will conveniently solve the stable identifier problem for ISPs at the same time, thus removing pressure to implement a real solution. (Consider that the multi-homing problem is in many senses the same as the stable identifier problem. You need a way to identify your site as a destination for packets independent of the low-level address hierarchies in which it is participating at the moment. Both problems might be solvable with a single mechanism and then multi-homing would not have to provoke a need for special address space. I realize that I'm talking at a fairly high level of abstraction here and that such a solution would represent a radical change in direction that is virtually impossible at this stage. But it is interesting to consider a model where end users are not strictly dependent on an address management bureaucracy.) If things continue in the direction they seem to be moving, the net effect may be to enshrine in IPv6 a model that was supposed to be a temporary hack to deal with table size in RAM-starved routers. IPv6 addresses will be the first-class citizens of identity (because there is no alternative), but end users will be unable to allocate them statically. Enterprise managers may not be so quick to embrace the new protocol with only a promise of a later solution to the stability problem. Obviously it won't matter to the average dial-up user who already has a dynamic address (not that such users would have much say in the first place) and ISPs won't mind if they are getting portable address space. Network managers currently using stable, well-tested solutions like NAT may make for a hard sell unless specific advantages can be presented to justify the expense of an upgrade. There is also the concern about paying a (possibly increasing) address fee for all the machines that were previously behind the NAT: even though the IPv6 address space is vast, it's structure makes it subject to at least the perception of localized scarcity that could be used to justify high prices to end users. It would be unfortunate to switch to IPv6 only to have to switch again to NAT'ed IPv6 for cost reasons. Anyway, I hadn't intended to ramble on about this. As I said, I was playing devil's advocate to point out that IPv6 acceptance isn't quite a no-brainer, and that the strategy of comparing to current addressing solutions is by no means a knock-down argument. I will now return to quietly watching IPv6 progress. :) Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 3 21:52:30 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d844nFU03034 for ipng-dist; Fri, 3 Sep 1999 21:49:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d844n7I03027 for ; Fri, 3 Sep 1999 21:49:07 -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 VAA08604 for ; Fri, 3 Sep 1999 21:49:05 -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 WAA21586 for ; Fri, 3 Sep 1999 22:49:03 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id OAA07648; Sat, 4 Sep 1999 14:48:57 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Sat, 4 Sep 1999 14:48:57 +1000 (EST) From: Peter Tattam To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd In-Reply-To: <199909040422.AAA24338@endor.eas.harvard.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A very well put together argument. You understand the issues well. Peter On Sat, 4 Sep 1999, Dan Lanciani wrote: > Thomas Narten wrote: > > |Philosophical desires aside, the reality today is that the IPv4 > |addresses are no longer the stable identifiers that folks find > |covenient. Wishing it otherwise won't make it so. > > I would have to disagree with this at least in part. IPv4 addresses > remain the stable identifiers that they always were because no good > alternative has been offered. Those who own portable address space > continue to find this convenient, while those with ISP-specific CIDR > addresses find it a disincentive to switching ISPs. The question is > whether we really wish to make the latter case (and current status quo) > the standard for all IPv6 end users. > > [snipping description I agree with] > > |How to do the mapping in a world where network address can change is a > |very hard problem, if one wants a solution that scales to the size of > |the Internet. > > I agree completely that this is a very hard problem. I also have my doubts > that it can be pushed onto the DNS without significantly changing the DNS > as we know it. My main concern, though, is that the problem will be avoided > rather than solved. > > Towards the beginning of the development of IPv6's hierarchical address space > the general notion seemed to be that nobody would get stable, portable address > space and that sites could be renumbered almost on a whim. This model carried > with it the strong implication that the stable identifier problem (which really > encompasses the tcp session stability issue and many other similar issues) > would have to be solved before the protocol would be of any use to anyone: the > new addresses were by definition not usable as stable identifiers. Now several > years later IPv6 is starting to be deployed (ok, maybe just for testing) and > the problem remains unsolved. Because a complete solution may well require > fairly deep changes, I worry that its implementation is becoming very unlikely > as the protocol becomes more fixed. > > Moreover, we seem to be talking about giving ISPs portable IPv6 address space > for multi-homing, and this will conveniently solve the stable identifier > problem for ISPs at the same time, thus removing pressure to implement a real > solution. (Consider that the multi-homing problem is in many senses the same > as the stable identifier problem. You need a way to identify your site as a > destination for packets independent of the low-level address hierarchies in > which it is participating at the moment. Both problems might be solvable with > a single mechanism and then multi-homing would not have to provoke a need for > special address space. I realize that I'm talking at a fairly high level of > abstraction here and that such a solution would represent a radical change in > direction that is virtually impossible at this stage. But it is interesting > to consider a model where end users are not strictly dependent on an address > management bureaucracy.) > > If things continue in the direction they seem to be moving, the net effect > may be to enshrine in IPv6 a model that was supposed to be a temporary hack > to deal with table size in RAM-starved routers. IPv6 addresses will be the > first-class citizens of identity (because there is no alternative), but end > users will be unable to allocate them statically. Enterprise managers may not > be so quick to embrace the new protocol with only a promise of a later solution > to the stability problem. Obviously it won't matter to the average dial-up > user who already has a dynamic address (not that such users would have much > say in the first place) and ISPs won't mind if they are getting portable > address space. Network managers currently using stable, well-tested solutions > like NAT may make for a hard sell unless specific advantages can be presented > to justify the expense of an upgrade. There is also the concern about paying > a (possibly increasing) address fee for all the machines that were previously > behind the NAT: even though the IPv6 address space is vast, it's structure > makes it subject to at least the perception of localized scarcity that could > be used to justify high prices to end users. It would be unfortunate to > switch to IPv6 only to have to switch again to NAT'ed IPv6 for cost reasons. > > Anyway, I hadn't intended to ramble on about this. As I said, I was playing > devil's advocate to point out that IPv6 acceptance isn't quite a no-brainer, > and that the strategy of comparing to current addressing solutions is by no > means a knock-down argument. I will now return to quietly watching IPv6 > progress. :) > > Dan Lanciani > ddl@harvard.edu > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- 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 Fri Sep 3 22:22:34 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8459S303066 for ipng-dist; Fri, 3 Sep 1999 22:09:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8459II03059 for ; Fri, 3 Sep 1999 22:09:19 -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 WAA10375 for ; Fri, 3 Sep 1999 22:09:18 -0700 (PDT) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA04040 for ; Fri, 3 Sep 1999 22:09:16 -0700 (PDT) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id AAA24556; Sat, 4 Sep 1999 00:08:44 -0500 (CDT) Received: from dal-tx4-48.ix.netcom.com(207.94.121.112) by dfw-ix10.ix.netcom.com via smap (V1.3) id rma024550; Sat Sep 4 00:08:40 1999 Message-ID: <37D03942.A340BFD4@ix.netcom.com> Date: Fri, 03 Sep 1999 22:10:28 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Dan Lanciani CC: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd References: <199909040422.AAA24338@endor.eas.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan and all, Dan, you make some very good and complexing points and problems that I have seen with IPv6 and more importantly with how those addresses will be allocated. Currently ICANN is considering "Taxing" IP addresses, and they will likely start out with IPv6 addresses. This makes acceptance and portability a much more serious concern. Dan Lanciani wrote: > Thomas Narten wrote: > > |Philosophical desires aside, the reality today is that the IPv4 > |addresses are no longer the stable identifiers that folks find > |covenient. Wishing it otherwise won't make it so. > > I would have to disagree with this at least in part. IPv4 addresses > remain the stable identifiers that they always were because no good > alternative has been offered. Those who own portable address space > continue to find this convenient, while those with ISP-specific CIDR > addresses find it a disincentive to switching ISPs. The question is > whether we really wish to make the latter case (and current status quo) > the standard for all IPv6 end users. > > [snipping description I agree with] > > |How to do the mapping in a world where network address can change is a > |very hard problem, if one wants a solution that scales to the size of > |the Internet. > > I agree completely that this is a very hard problem. I also have my doubts > that it can be pushed onto the DNS without significantly changing the DNS > as we know it. My main concern, though, is that the problem will be avoided > rather than solved. > > Towards the beginning of the development of IPv6's hierarchical address space > the general notion seemed to be that nobody would get stable, portable address > space and that sites could be renumbered almost on a whim. This model carried > with it the strong implication that the stable identifier problem (which really > encompasses the tcp session stability issue and many other similar issues) > would have to be solved before the protocol would be of any use to anyone: the > new addresses were by definition not usable as stable identifiers. Now several > years later IPv6 is starting to be deployed (ok, maybe just for testing) and > the problem remains unsolved. Because a complete solution may well require > fairly deep changes, I worry that its implementation is becoming very unlikely > as the protocol becomes more fixed. > > Moreover, we seem to be talking about giving ISPs portable IPv6 address space > for multi-homing, and this will conveniently solve the stable identifier > problem for ISPs at the same time, thus removing pressure to implement a real > solution. (Consider that the multi-homing problem is in many senses the same > as the stable identifier problem. You need a way to identify your site as a > destination for packets independent of the low-level address hierarchies in > which it is participating at the moment. Both problems might be solvable with > a single mechanism and then multi-homing would not have to provoke a need for > special address space. I realize that I'm talking at a fairly high level of > abstraction here and that such a solution would represent a radical change in > direction that is virtually impossible at this stage. But it is interesting > to consider a model where end users are not strictly dependent on an address > management bureaucracy.) > > If things continue in the direction they seem to be moving, the net effect > may be to enshrine in IPv6 a model that was supposed to be a temporary hack > to deal with table size in RAM-starved routers. IPv6 addresses will be the > first-class citizens of identity (because there is no alternative), but end > users will be unable to allocate them statically. Enterprise managers may not > be so quick to embrace the new protocol with only a promise of a later solution > to the stability problem. Obviously it won't matter to the average dial-up > user who already has a dynamic address (not that such users would have much > say in the first place) and ISPs won't mind if they are getting portable > address space. Network managers currently using stable, well-tested solutions > like NAT may make for a hard sell unless specific advantages can be presented > to justify the expense of an upgrade. There is also the concern about paying > a (possibly increasing) address fee for all the machines that were previously > behind the NAT: even though the IPv6 address space is vast, it's structure > makes it subject to at least the perception of localized scarcity that could > be used to justify high prices to end users. It would be unfortunate to > switch to IPv6 only to have to switch again to NAT'ed IPv6 for cost reasons. > > Anyway, I hadn't intended to ramble on about this. As I said, I was playing > devil's advocate to point out that IPv6 acceptance isn't quite a no-brainer, > and that the strategy of comparing to current addressing solutions is by no > means a knock-down argument. I will now return to quietly watching IPv6 > progress. :) > > Dan Lanciani > ddl@harvard.edu > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- 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 Sep 4 19:25:41 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d852KEb03530 for ipng-dist; Sat, 4 Sep 1999 19:20:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d852K5I03523 for ; Sat, 4 Sep 1999 19:20:05 -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 TAA00372 for ; Sat, 4 Sep 1999 19:20:04 -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 TAA25333 for ; Sat, 4 Sep 1999 19:20:03 -0700 (PDT) Received: from new (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id TAA16590; Sat, 4 Sep 1999 19:20:02 -0700 (PDT) Message-Id: <3.0.5.32.19990904191829.03e4a100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 04 Sep 1999 19:18:29 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Draft IPng Interim Meeting Agenda Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the draft agenda for the IPng Interim meeting in Tokyo. The names listed by the topics are discussion leaders, not just presenters. Please send suggestions for additional topics, changes, and corrections to us. Bob Hinden / Steve Deering IPng Chairs ---------------------------------------------------------- Agenda for IETF IPng w.g. Meeting September 29, 1999 - October 1, 1999 Tokyo Meeting hosted by the WIDE Group Meeting information can be found at: http://www.wide.ad.jp/events/199909.ipng-interim/ Wednesday / 29 September 1999 ----------------------------- 10:00-12:00 Introduction / S. Deering, B. Hinden Local Site Introduction / Jun Murai ICANN IPv6 Status / Jun Murai IPv6 Address Scoping Model / S. Deering Multihoming - Multihoming Overview / S. Deering - Near term host mechanisms / R. Draves o Source & Destination Address Selection 13:00 - 17:00 - Longer term Host Mechanisms / E. Nordmark o API w/ DNS Names interface o Multiple addresses per Connection Thursday / 30 September 1999 ---------------------------- 09:00 - 12:00 Multihoming (continues) - Router Only Mechanisms / Itojun o RFC2260 Style for IPv6 o Multiple Prefix ISP Support 13:00 - 17:00 Model for IPv6 Renumbering / B. Hinden Plug & Play Architecture / S. Deering Friday / 1 October 1999 ----------------------- 09:00 - 12:00 API Issues / E. Nordmark - Multihoming - Scoping -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 5 05:24:41 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d85CKjk03796 for ipng-dist; Sun, 5 Sep 1999 05:20:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d85CKaI03789 for ; Sun, 5 Sep 1999 05:20:37 -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 FAA12152 for ; Sun, 5 Sep 1999 05:20:37 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA06428 for ; Sun, 5 Sep 1999 05:20:36 -0700 (PDT) Received: from world.std.com (qqi@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id IAA06612 for ; Sun, 5 Sep 1999 08:20:35 -0400 (EDT) Received: from localhost (qqi@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id IAA12751 for ; Sun, 5 Sep 1999 08:20:35 -0400 (EDT) Date: Sun, 5 Sep 1999 08:20:34 -0400 (EDT) From: Quality Quorum To: ipng@sunroof.eng.sun.com Subject: CIDR, what CIDR ? (Re: AN interesting article. FYI... contd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, ISP-specific CIDR addresses were mentonned several times ecently. FYI: it is possible now to make a relatively inexpensive IPV4 core router which will support ALL theoretically possible class-A,B and C routes plus say 2M of longer routes. So, CIDR imposed limitations on ISP-to-ISP mobility/multihoming are not going to be a problem very soon (if IPV4 is here to stay). Thanks, Aleksey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 7 02:58:04 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d879sbW04739 for ipng-dist; Tue, 7 Sep 1999 02:54:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d879sSI04732 for ; Tue, 7 Sep 1999 02:54:29 -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 CAA08193 for ; Tue, 7 Sep 1999 02:54:28 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id DAA04677 for ; Tue, 7 Sep 1999 03:54:27 -0600 (MDT) Received: (qmail 1283 invoked by uid 1001); 7 Sep 1999 09:54:26 -0000 Date: Tue, 7 Sep 1999 02:54:26 -0700 From: Ben Black To: ipng@sunroof.eng.sun.com Subject: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990907025426.U77014@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm not familiar with the workings of the IPng group, so please let me know if this violates any procedural or etiquette boundaries. I've just finished reading several of the IPv6 drafts and hoped my thoughts on one recently submitted draft might be of use. IPv6 multihoming is a thorny problem and I don't pretend to have a solution. I don't know that there is one possible as the network layer. Ben -- The IPv6 address allocation and routing hierarchy defined in [AGGR] and [ARCH] poses serious difficulties for implementation of multihomed networks. Rather than the usual practice of allocating a single prefix, or set of prefixes for multiple networks, network operators must either home to a single provider or allocate multiple prefixes for the same set of nodes. The draft "A Simple Solution for IPv6 Multihoming" [SMPL] profers an approach to achieving multihomed networks within the constraints of the IPv6 route aggregation hierarchy. Unfortunately, the fundamental assumptions regarding the purposes of multihoming lead the author of the document astray. The main goals of multihoming are: redundancy in the face of link and/or network failure, load balancing, and performance improvement. Of these, only load balancing is directly addressed, and even then with limited success. Similarly, although improving performance by connecting directly to networks which are common destinations is effective, the document does not provide options for accessing content providers accessible through other networks. A selection of quotes from the document will help in clarifying its shortcomings as a solution to multihoming within the existing, documented IPv6 routing framework. >From section 2 (Proposal): ISP-3 ---- ISP-4 | / | | / | | / | ISP-1 ---- ISP-2 link-1 \ / link-2 Customer-A A multi-homed customer will designate a primary ISP and receive IP address from its primary ISP's IPv6 aggregation block. In this example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A to the customer. Customer-A will advertise addr-1-A to ISP-1 and ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to ISP-1 only. ISP-1 will, of course, advertise its own aggregation Addr-1 to the entire Internet. It is clear from this description that the only redundancy provided with this solution is for the customer links (link-1 and link-2) and not for the ISPs themselves. Specifically, if ISP-1 suffers from a failure within the POP to which link-1 terminates, whether as an isolated failure or a more extensive failure within ISP-1, then Customer-A is no longer able to maintain connectivity despite their possession of a perfectly good alternate path through ISP-2. From an engineering perspective, no robustness has been gained through this multihoming which could not be gained more simply with multiple links to ISP-1. >From section 2 (Proposal): For inbound traffic to Customer-A, traffic will first be forwarded to ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will then forward the traffic destined to Customer-A via its connection to ISP-2 and/or its direct link to customer-A, according to certain polices. Most common policy would be the use of the shortest exit. By using both connections to forward traffic to Customer-A, load sharing is achieved. >From this statement it is unclear exactly how inbound load balancing is to be achieved. Is the author suggesting use of the (rather troublesome) concept of eBGP multipath? In the topology described in the diagram above, implementation of a load sharing mechanism across link-1 and link-2 would be a decidedly non-trivial matter. Again, given the lack of redundancy outlined above, it would be far more efficient for Customer-A to simply purchase multiple links to ISP-1. Additionally, Customer-A must now depend heavily on the connectivity between ISP-1 and ISP-2. Often, links to multiple providers are purchased specifically to avoid traffic crossing these (often congested) peerings. >From Section 4 (Concerns): - The primary ISP of a multihoming customer (such as ISP-1 in the example) would need to do more work in terms of distributing the traffic among other connected ISPs and the customer link. This can be done using BGP policy (BGP community) and using shortest exit. It will also carry more traffic for the customer. However, this is a value added service to the customer and the primary ISP can charge more fees for such services. Stating that the primary ISP "would need to do more work" is putting the problem a bit lightly. The addition of references to BGP policies and BGP communities does little to clarify how exactly the author believes traffic could effectively be distributed. >From Section 4 (Concerns): - The primary ISP is the sole interface for the multihomed customer to the Internet other than the ISPs the customer has directly connection with. Outages such as one between ISP-1 and ISP-4 would impact the reachability from customers of ISP-4 to Customer-A even though ISP-2 still has good connection to ISP-4. However, if the primary ISP is a good quality ISP, this sort of situation should happen rarely. The reason is that it's common practice that an ISP, especially good quality ISP, has multiple connections to other big ISPs at different geographical locations. Good quality ISPs also have robust network design to prevent any failure to impact the whole network. Choosing a good quality and robust ISP as primary ISP is a good practice. This is really the crux of the problem with the solution put forth in the document. The assumption that a given ISP will never have failures, or that rare failures are acceptable to customers who multihomed for redundancy, is simply not valid from an engineering perspective. If the primary goal of multihoming were load sharing, this solution would provide one, potentially very complicated, answer. However, the issue of multihoming for redundancy is totally ignored, drawing into question the need for a second ISP in the equation at all. Why not simply purchase additional bandwidth from the same ISP? >From Section 4 (Concerns): It is desirable to have solution which provides perfect redundancy and, at the same time, simplicity to scale management and operation. In the absence of a perfect solution, the trade-off needs to be made. The author believes that it is very important that the solution has to be simple and manageable. Manageability should be the top consideration. If manageability of the solution is to be the top consideration, the response put forward does not measure up. In the name of avoiding routing table growth the author has suggested adding significant complexity to the configuration and management of multihomed customers without showing any benefit for the effort. An area not addressed at all in the document is that of multihoming for access to networks attached to a given ISP, rather than access to that ISP. For example, using the diagram above, if Customer-A purchased connectivity to ISP-2 because ISP-2 had better connectivity to ISP-4, then the offered multihoming solution is of no use. ISP-4 will never see reachability to Customer-A via ISP-2. The primary lesson of the draft proposal is that the proposed, forced aggregation hierarchy places sever restrictions upon the engineering of reliable, high poerformance networks. To multihome effectively, a network operator must somehow qualify as a "long-haul provider" or other entity appropriate for allocation of its own address space. In this author's opinion, the current IPv6 addressing architecture creates an environment which provides scalability of the global routing table at the expense of any real hope for redundancy through multihoming. Solutions which avoid the use of multihoming with a single address space are possible and offer more hope for a robust network than those currently proposed. REFERENCES [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An Aggregatable Global Unicast Address Format", RFC 2374, July 1998. [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [SMPL] Yu, J., "A Simple Solution for IPv6 Multihoming", draft-yu-simple-ipv6multihoming-00.txt, August 1999. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 7 08:36:18 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d87FWwr04943 for ipng-dist; Tue, 7 Sep 1999 08:32:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d87FWnI04936 for ; Tue, 7 Sep 1999 08:32: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 IAA27485 for ; Tue, 7 Sep 1999 08:32:49 -0700 (PDT) Received: from solen.ce.chalmers.se (solen.ce.chalmers.se [129.16.20.244]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01150 for ; Tue, 7 Sep 1999 08:32:48 -0700 (PDT) Received: from blomman18.ce.chalmers.se (blomman18.ce.chalmers.se [129.16.21.48]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id RAA15801 for ; Tue, 7 Sep 1999 17:32:36 +0200 (MET DST) From: Otel Florian-Daniel Received: (from otel@localhost) by blomman18.ce.chalmers.se (8.8.8/8.8.8) id RAA26815; Tue, 7 Sep 1999 17:32:36 +0200 (MET DST) Date: Tue, 7 Sep 1999 17:32:36 +0200 (MET DST) To: ipng@sunroof.eng.sun.com Subject: Vendor support for IPv6 References: <19990907025426.U77014@layer8.net> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14293.12052.531570.43655@blomman18.ce.chalmers.se> Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello everybody, I have a rather delicate question to ask (maybe a little bit off-topic) so appologies in advance if that is the case. I'm intrested if someone can tell me where i can find some information about _official_ vendor support for IPv6. I'm intrested especially about cisco and Microsoft. Thanks in advance, Florian. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 7 11:28:33 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d87ILQP05193 for ipng-dist; Tue, 7 Sep 1999 11:21:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d87ILHI05186 for ; Tue, 7 Sep 1999 11:21: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 LAA05139 for ; Tue, 7 Sep 1999 11:21:16 -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 LAA19169 for ; Tue, 7 Sep 1999 11:21:15 -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 LAA27777; Tue, 7 Sep 1999 11:21:15 -0700 (PDT) Message-Id: <3.0.5.32.19990907111938.034d8100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 07 Sep 1999 11:19:38 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W. Richard Stevens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Co-author of RFC2553, RFC2292, RFC2133, as well as some non-IPv6-specific RFC's, died last Wednesday. We will miss him. Bob >From: "Jeff Payne" >To: >Subject: Richard W. Steven Obit. >Date: Sat, 4 Sep 1999 12:42:27 -0700 >X-MSMail-Priority: Normal >X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 >Importance: Normal >Sender: owner-end2end-interest@ISI.EDU > >STEVENS, W. Richard, noted author of computer books died on September 1. He >is best known for his ``UNIX Network Programming'' series (1990, 1998, >1999), ``Advanced Programming in the UNIX Environment'' (1992), and ``TCP/IP >Illustrated'' series (1994, 1995, 1996). > >Richard was born in 1951 in Luanshya, Northern Rhodesia (now Zambia), where >his father worked for the copper industry. The family moved to Salt Lake >City, Hurley, New Mexico, Washington, DC and Phalaborwa, South Africa. >Richard attended Fishburne Military School in Waynesboro, Virginia. He >received a B.SC. in Aerospace Engineering from the University of Michigan in >1973, and an M.S. (1978) and Ph.D. (1982) in Systems Engineering from the >University of Arizona. He moved to Tucson in 1975 and from then until 1982 >he was employed at Kitt Peak National Observatory as a computer programmer. >From 1982 until 1990 he was Vice President of Computing Services at Health >Systems International in New Haven, CT, moving back to Tucson in 1990. Here >he pursued his career as an author and consultant. He was also an avid pilot >and a part-time flight instructor during the 1970's. > >He is survived by his loving wife of 20 years, Sally Hodges Stevens; three >wonderful children, Bill, Ellen and David; sister, Claire Stevens of Las >Vegas, NV; brother, Bob and wife Linda Stevens of Dallas, TX; nieces, Laura, >Sarah, Collette, Christy; and nephew, Brad. He is predeceased by his >parents, Royale J. Stevens (1915-1984); and Helen Patterson Stevens >(1916-1997). Helen lived in Tucson from 1991-1997, and Royale lived here in >the early 1930's attending Tucson High School while his father was treated >for TB at the Desert Sanitorium (now TMC). > >The family asks that in lieu of flowers, donations be made in Richard's name >to Habitat for Humanity, 2950 E. 22nd Street, Tucson, AZ 85713. A memorial >service for Richard will be held at St. Phillip's in the Hills Episcopal >Church on Tuesday, September 7th at 12:00 noon. Following the service there >will be a reception in the Murphy Gallery of the Church. Please wear >colorful clothing to the service; Richard loved colors. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 7 11:45:16 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d87IdVQ05258 for ipng-dist; Tue, 7 Sep 1999 11:39:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d87IdDI05251 for ; Tue, 7 Sep 1999 11:39:23 -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 LAA04330 for ; Tue, 7 Sep 1999 11:39:12 -0700 (PDT) Received: from uumail-relay-blr.ernet.in (uumail-relay-blr.ernet.in [202.141.1.17]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27812 for ; Tue, 7 Sep 1999 11:39:09 -0700 (PDT) Received: from iisc.ernet.in (iisc.ernet.in [144.16.64.3]) by uumail-relay-blr.ernet.in (8.9.0/8.9.0) with ESMTP id AAA14556 for ; Wed, 8 Sep 1999 00:13:03 +0530 Received: from osiris.csa.iisc.ernet.in (osiris.csa.iisc.ernet.in [144.16.67.12]) by iisc.ernet.in (8.9.2/8.9.0) with ESMTP id AAA45558 for ; Wed, 8 Sep 1999 00:08:09 +0530 (IST) Received: from localhost by osiris.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id AAA19154 for ; Wed, 8 Sep 1999 00:08:10 +0530 (IST) X-Authentication-Warning: osiris.csa.iisc.ernet.in: vpk owned process doing -bs Date: Wed, 8 Sep 1999 00:08:10 +0530 (IST) From: Khandekar Vivek Prakash Reply-To: Khandekar Vivek Prakash To: ipng@sunroof.eng.sun.com Subject: Required some help Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am trying to do source routing using IPv6.I am using Red Hat 6.0.I have installed IPv6 on my host.To do source routing I need following functions 1>size_t inet6_rthdr_space(int type,int segments) 2>struct cmsghdr *inet6_rthdr_init(void *buf,int type) and so on. I have not found them in libc.my versions are glibc-2.1.1-6 libc-5.3.12-31 can you please tell me where can i find these fuctions or the latest version of libc containing these fuctions ? regards vivek -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 7 13:08:24 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d87K1R005557 for ipng-dist; Tue, 7 Sep 1999 13:01:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d87K1GI05550 for ; Tue, 7 Sep 1999 13:01:16 -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 NAA19742 for ; Tue, 7 Sep 1999 13:01:15 -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 OAA11650 for ; Tue, 7 Sep 1999 14:01:14 -0600 (MDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA18132; Tue, 7 Sep 1999 16:01:08 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA28180; Tue, 7 Sep 1999 16:01:11 -0400 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id PAA21739; Tue, 7 Sep 1999 15:59:06 -0400 Message-Id: <199909071959.PAA21739@rotala.raleigh.ibm.com> To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd In-Reply-To: Message from Dan Lanciani of "Sat, 04 Sep 1999 00:22:42 EDT." <199909040422.AAA24338@endor.eas.harvard.edu> Date: Tue, 07 Sep 1999 15:59:06 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > |Philosophical desires aside, the reality today is that the IPv4 > |addresses are no longer the stable identifiers that folks find > |covenient. Wishing it otherwise won't make it so. > I would have to disagree with this at least in part. IPv4 addresses > remain the stable identifiers that they always were because no good > alternative has been offered. Those who own portable address space > continue to find this convenient, while those with ISP-specific CIDR > addresses find it a disincentive to switching ISPs. I think we are more in agreement than disagreement. Folks would like for addresses to be stable identifiers, because they seem to be the closest thing available today. At the same time, those who don't have portable addresses are stuck with the realities that come with that (e.g., lack of permanence for those addresses). But whether we like it or not, global addresses are becoming less "stable" as identifiers. This can't be just wished away. > The question is whether we really wish to make the latter case (and > current status quo) the standard for all IPv6 end users. What is the alternative? I agree that this is an undesireable state to be in. But going back to the idea that everyone's addresses are portable isn't tenable either. Routing in the backbone would not be able to handle it (i.e., it doesn't scale even today, much less into the future). What you seem to be asking for is a solution to the core problem that no one has yet been able to come up with a solution for: How can we make renumbering painless enough to carry out so that it can be done on a regular basis (so that routing information can be sufficiently aggregated and backbone routing protocols can deal with a managable number of routing prefixes), yet at the same time have a stable identifier that end hosts can use in place of addresses? IPv4 hasn't come up with a solution to this problem and neither has IPv6. Saying we must solve this problem in order to make IPv6 viable doesn't change the reality that there is no concensus on how (or even whether it is possible) to solve the problem. And it is the case that v6 has taken steps to make it easier (not trivial, however) to renumber a site. But the notion that we'll be able to renumber sites frequently and with no disruption to end sites is fantasy IMO. Wishing it otherwise won't make it so. > |How to do the mapping in a world where network address can change is a > |very hard problem, if one wants a solution that scales to the size of > |the Internet. > I agree completely that this is a very hard problem. I also have my > doubts that it can be pushed onto the DNS without significantly > changing the DNS as we know it. My main concern, though, is that > the problem will be avoided rather than solved. But is this problem solvable today? There is disagreement today whether this is an engineering problem or a research problem. If it is really the latter, the implication is that we don't yet know how to solve the problem. > Towards the beginning of the development of IPv6's hierarchical > address space the general notion seemed to be that nobody would get > stable, portable address space and that sites could be renumbered > almost on a whim. I think this is a misconception (shared by many unfortunately). I don't think anyone who has spent a lot of time working on v6 thinks renumbering can be done "almost on a whim". Some folks wish this were the case, just like they wish IPv6 did a lot of things that it doesn't do (and never set out to do). > This model carried with it the strong implication that the stable > identifier problem (which really encompasses the tcp session > stability issue and many other similar issues) would have to be > solved before the protocol would be of any use to anyone: the new > addresses were by definition not usable as stable identifiers. Now > several years later IPv6 is starting to be deployed (ok, maybe just > for testing) and the problem remains unsolved. Because a complete > solution may well require fairly deep changes, I worry that its > implementation is becoming very unlikely as the protocol becomes > more fixed. > Moreover, we seem to be talking about giving ISPs portable IPv6 > address space for multi-homing, and this will conveniently solve the > stable identifier problem for ISPs at the same time, thus removing > pressure to implement a real solution. Could you explain a bit more? Why do you think we are giving ISPs portable address space? I believe only the TLA prefix is truly portable, and ISPs do not automatically get them. > (Consider that the multi-homing problem is in many senses the same > as the stable identifier problem. You need a way to identify your > site as a destination for packets independent of the low-level > address hierarchies in which it is participating at the moment. > Both problems might be solvable with a single mechanism and then > multi-homing would not have to provoke a need for special address > space. I realize that I'm talking at a fairly high level of > abstraction here and that such a solution would represent a radical > change in direction that is virtually impossible at this stage. But > it is interesting to consider a model where end users are not > strictly dependent on an address management bureaucracy.) I agree that site multihoming/renumbering are very similar and related problems. The current IPv6 addressing architecture (e.g., split of addressess into "routing goop" and EUI-64-like portion) and the large v6 addresses make it quite possible to still make changes. Not changes to the "base" so to speak, but there is certainly room for experimentation with the possibility of full migration later on. The difficulty so far has been coming up with something to exploit new approaches that folks agree we should pursue. While I sympathize with the feeling "this problem needs to be fixed", someone still needs to come up with a solution. > If things continue in the direction they seem to be moving, the net > effect may be to enshrine in IPv6 a model that was supposed to be a > temporary hack to deal with table size in RAM-starved routers. IPv6 > addresses will be the first-class citizens of identity (because > there is no alternative), but end users will be unable to allocate > them statically. I don't understand what you mean by the above. Do you mean "go to IANA and get a portable address block" from which one can assign addresses? That day is gone. > Enterprise managers may not be so quick to embrace the new protocol > with only a promise of a later solution to the stability problem. Let us be honest, there is no "promise" that there will be a solution. There is "hope", but no "promise". Who is making such a promise? And when I say "hope", I mean that solving this problem has not been ruled out. But I am not aware of anyone actively working on this particular problem either at this time. What folk (i.e. IPng) are working on now is multihoming that makes use of multiple prefixes/addresses on end hosts. This doesn't have all of the nice properties that portable addresses have (to the end host), but it is consistent with keeping backbone routing stable and manageable (which portable addressing does not do). > Obviously it won't matter to the average dial-up user who already > has a dynamic address (not that such users would have much say in > the first place) and ISPs won't mind if they are getting portable > address space. Network managers currently using stable, well-tested > solutions like NAT may make for a hard sell unless specific > advantages can be presented to justify the expense of an upgrade. > There is also the concern about paying a (possibly increasing) > address fee for all the machines that were previously behind the > NAT: even though the IPv6 address space is vast, it's structure > makes it subject to at least the perception of localized scarcity > that could be used to justify high prices to end users. It would be > unfortunate to switch to IPv6 only to have to switch again to NAT'ed > IPv6 for cost reasons. I don't follow the cost argument. What I have seen of the costs of obtaining v6 addresses is that they are comparable to the lowest cost one has to pay to get v4 addresses. However, for that cost one gets many many more v6 addresses. So the per-address cost of v6 is significantly lower. > Anyway, I hadn't intended to ramble on about this. As I said, I was playing > devil's advocate to point out that IPv6 acceptance isn't quite a no-brainer, > and that the strategy of comparing to current addressing solutions is by no > means a knock-down argument. I will now return to quietly watching IPv6 > progress. :) Having said all this, I am not claiming that v6 has a strong business argument over v4 (at this time). It is also not my intention to imply that your concerns aren't valid (I share the lament). However, I think we need to be honest about what v6 does today, and what possibilities it allows for the future. At the same time, I think its also important that folks be realistic about saying v6 should solve this problem and at the same time implying that we should just Do It. If someone comes up with a workable solution, we should have serious discussions about it. But in the absence of specific, concrete proposals, just saying "it would be nice" doesn't help and in some cases doesn't adequately take into consideration that there are real technical reasons why solutions have not yet been developed. 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 Tue Sep 7 14:36:24 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d87LR9w06332 for ipng-dist; Tue, 7 Sep 1999 14:27:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d87LQwM06325 for ; Tue, 7 Sep 1999 14:26:58 -0700 (PDT) Received: from bobo.eng.sun.com (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA314630; Tue, 7 Sep 1999 14:07:27 -0700 (PDT) Date: Tue, 7 Sep 1999 14:07:26 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik.Nordmark@eng.sun.com, Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <14287.49116.94774.30564X@condor.isl.rdc.toshiba.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > That's right, but my impression is that it was a workaround for those > who didn't have enough API to specify the outgoing interface of a > multicast packet. Even if we install a route for ff00::/8 to an > interface, we have to specify another interface via some API after > all. IMO, we should not rely on a `default route' in the kernel for > sending a multicast packet. Something needs to pick the "default multicast interface". It could be one of 1. The user (start the application with a command line option specifying the interface) 2. The application (without user information) 3. The kernel It makes sense having the kernel pick one if neither the user nor the application specifies one. (Of course, the user or application might want to override this but that doesn't change the question of where the default comes from). IPv4 applications can use the kernel default today. Why should we not provide the same ability for IPv6 applications? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 7 14:58:25 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d87Lp2W06403 for ipng-dist; Tue, 7 Sep 1999 14:51:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d87LogM06396 for ; Tue, 7 Sep 1999 14:50:43 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id OAA07943 for ipng@sunroof.eng.sun.com; Tue, 7 Sep 1999 14:48:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d87LleM06380 for ; Tue, 7 Sep 1999 14:47: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 OAA00172 for ; Tue, 7 Sep 1999 14:47:40 -0700 (PDT) Received: from quern.epilogue.com (quern.epilogue.com [128.224.1.136]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25405 for ; Tue, 7 Sep 1999 14:47:39 -0700 (PDT) Received: from raspberry-1.epilogue.com ([128.224.1.180]:29701 "HELO raspberry" ident: "IDENT-NOT-QUERIED [port 29701]") by newquern.epilogue.com with SMTP id <858-176>; Tue, 7 Sep 1999 17:47:26 -0400 X-Sender: mrfpop@pop.epilogue.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 07 Sep 1999 17:44:49 -0400 To: Thomas Narten From: Margaret Wasserman Subject: Re: AN interesting article. FYI... contd Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199909071959.PAA21739@rotala.raleigh.ibm.com> References: <199909040422.AAA24338@endor.eas.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <19990907214733Z858-176+1572@newquern.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >How can we make renumbering painless enough to carry out so that it >can be done on a regular basis (so that routing information can be >sufficiently aggregated and backbone routing protocols can deal with a >managable number of routing prefixes), yet at the same time have a >stable identifier that end hosts can use in place of addresses? Have two separate identifiers. One is transient and is used to indicate the position in the routing hierarchy, and the other is permanent and can be used to umambiguously identify a host within the administrative hierarchy. You also need a way to map from the permanent identifier to the current transient identifier. IMHO, IP Addresses, DNS names and the DNS system are adequate to meet the above three needs. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 7 19:55:29 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d882qON06947 for ipng-dist; Tue, 7 Sep 1999 19:52:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d882qE806940 for ; Tue, 7 Sep 1999 19:52:15 -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 TAA23254 for ; Tue, 7 Sep 1999 19:52:09 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA23046 for ; Tue, 7 Sep 1999 20:52:07 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA29993; Wed, 8 Sep 1999 11:52:06 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA19016; Wed, 8 Sep 1999 11:52:05 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA06212; Wed, 8 Sep 1999 11:52:05 +0900 (JST) To: ipng@sunroof.eng.sun.com Cc: junsec@wide.ad.jp, yumi@kame.net Subject: interim registration/hotel reservation From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.94 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: <19990908115116D.kazu@iijlab.net> Date: Wed, 08 Sep 1999 11:51:16 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Sorry for the delay but I think we are ready now. Those who are planing to atenda the next interim meeting in Japan should gain accece to: http://www.wide.ad.jp/events/199909.ipng-interim/ Participants MUST register through this page. If not, you can't take a chair through the meeting. Due to the room space, the number of paticipants is limited to 90. Optionally, you can book room(s) of Mita Miyako hotel through the page. Probably some guys feel that this page is inconvenient. For example, you may want to check out on 3rd Oct. You may want to register the meeting first and book a room later. In such cases, please feel free to send email messages to Scott Macdonald, JCOM (scott@jtbcom.co.jp). Scott will help you. Currently we are not sure that the discount rate can be applied to the other days. It is important to understand that JCOM treats Mita Miyako hotel only. If you want to stay in another hotel, please book a room by yourself. Scott will NOT help you. After the interim meeting, Japanese session will be held. Some Japanese guys explain what's going on in Japan to foreigners. This is optional. Please feel free to leave at noon without attending this session. Likewise, please feel free to attend this session. I believe this is worth listing. :-) If you will get in trouble, please tell me. I have responsibility on the local arrange. See you in Japan soon. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 8 01:19:30 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d888GH107066 for ipng-dist; Wed, 8 Sep 1999 01:16:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d888G8807059 for ; Wed, 8 Sep 1999 01:16: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 BAA29705 for ; Wed, 8 Sep 1999 01:16:06 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA07896 for ; Wed, 8 Sep 1999 01:16:01 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA22336; Wed, 8 Sep 1999 10:15:05 +0200 (MET DST) Message-ID: <19990908101505.A22259@theory.cs.uni-bonn.de> Date: Wed, 8 Sep 1999 10:15:05 +0200 From: Ignatios Souvatzis To: Margaret Wasserman , Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd References: <199909040422.AAA24338@endor.eas.harvard.edu> <199909071959.PAA21739@rotala.raleigh.ibm.com> <19990907214733Z858-176+1572@newquern.epilogue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990907214733Z858-176+1572@newquern.epilogue.com>; from Margaret Wasserman on Tue, Sep 07, 1999 at 05:44:49PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Sep 07, 1999 at 05:44:49PM -0400, Margaret Wasserman wrote: > > > >How can we make renumbering painless enough to carry out so that it > >can be done on a regular basis (so that routing information can be > >sufficiently aggregated and backbone routing protocols can deal with a > >managable number of routing prefixes), yet at the same time have a > >stable identifier that end hosts can use in place of addresses? > > > Have two separate identifiers. One is transient and is used to > indicate the position in the routing hierarchy, and the other is > permanent and can be used to umambiguously identify a host within > the administrative hierarchy. You also need a way to map from > the permanent identifier to the current transient identifier. > > IMHO, IP Addresses, DNS names and the DNS system are adequate > to meet the above three needs. Yes. -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 8 14:20:32 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d88LEo208087 for ipng-dist; Wed, 8 Sep 1999 14:14:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d88LEa808080 for ; Wed, 8 Sep 1999 14:14: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 OAA29380 for ; Wed, 8 Sep 1999 14:14:35 -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 OAA14349 for ; Wed, 8 Sep 1999 14:14:35 -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 QAA19372 for ; Wed, 8 Sep 1999 16:14:34 -0500 (CDT) Message-Id: <199909082114.QAA19372@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: AN interesting article. FYI... contd In-reply-to: Your message of Wed, 08 Sep 1999 10:15:05 +0200. <19990908101505.A22259@theory.cs.uni-bonn.de> Date: Wed, 08 Sep 1999 16:14:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Have two separate identifiers. ... You also need a way to map from > > the permanent identifier to the current transient identifier. > > > > IMHO, IP Addresses, DNS names and the DNS system are adequate > > to meet the above three needs. Well, I'll go as far as saying that any claim to the contrary first needs to show how this trio is *not* sufficient. 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 Sep 8 16:13:21 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d88N8sJ08372 for ipng-dist; Wed, 8 Sep 1999 16:08:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d88N8e808365 for ; Wed, 8 Sep 1999 16:08:40 -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 QAA479510; Wed, 8 Sep 1999 16:08:34 -0700 (PDT) Date: Wed, 8 Sep 1999 16:06:15 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: AN interesting article. FYI... contd To: Margaret Wasserman Cc: Thomas Narten , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <19990907214733Z858-176+1572@newquern.epilogue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Have two separate identifiers. One is transient and is used to > indicate the position in the routing hierarchy, and the other is > permanent and can be used to umambiguously identify a host within > the administrative hierarchy. You also need a way to map from > the permanent identifier to the current transient identifier. This sounds very attractive and feasible at the 50,000 foot level. But the devil is in the details. And since there isn't a fleshed out proposal for such a system it is impossible to discuss the advantages and disadvantages. Even high level "details" like whether or not you can map from one of the identifiers to the other and vice versa, appear to be open to discussion among the set of people that have proposed a solution along the above lines. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 8 16:13:31 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d88N9bK08381 for ipng-dist; Wed, 8 Sep 1999 16:09:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d88N9P808374 for ; Wed, 8 Sep 1999 16:09:26 -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 QAA479579; Wed, 8 Sep 1999 16:09:24 -0700 (PDT) Date: Wed, 8 Sep 1999 16:07:05 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: interim registration/hotel reservation To: Kazu Yamamoto Cc: ipng@sunroof.eng.sun.com, junsec@wide.ad.jp, yumi@kame.net In-Reply-To: "Your message with ID" <19990908115116D.kazu@iijlab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > http://www.wide.ad.jp/events/199909.ipng-interim/ I get no route from our (IPv4) socks proxy. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 8 17:15:34 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d890B7R08456 for ipng-dist; Wed, 8 Sep 1999 17:11:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d890Aw808449 for ; Wed, 8 Sep 1999 17:10:58 -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 RAA23147; Wed, 8 Sep 1999 17:10:55 -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 SAA22791; Wed, 8 Sep 1999 18:10:51 -0600 (MDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id RAA02544; Wed, 8 Sep 1999 17:10:49 -0700 (PDT) From: Bill Manning Message-Id: <199909090010.RAA02544@zephyr.isi.edu> Subject: Re: AN interesting article. FYI... contd To: Erik.Nordmark@eng.sun.com Date: Wed, 8 Sep 1999 17:10:49 -0700 (PDT) Cc: mrw@epilogue.com, narten@raleigh.ibm.com, ipng@sunroof.eng.sun.com In-Reply-To: from "Erik Nordmark" at Sep 8, 99 04:06:15 pm 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 > > > Have two separate identifiers. One is transient and is used to > > indicate the position in the routing hierarchy, and the other is > > permanent and can be used to umambiguously identify a host within > > the administrative hierarchy. You also need a way to map from > > the permanent identifier to the current transient identifier. > > This sounds very attractive and feasible at the 50,000 foot level. > But the devil is in the details. And since there isn't a fleshed out > proposal for such a system it is impossible to discuss the advantages > and disadvantages. > > Even high level "details" like whether or not you can map from > one of the identifiers to the other and vice versa, appear to be open to > discussion among the set of people that have proposed a solution along the > above lines. > > Erik > The NIMROD work of a few years back did explore many details on how to have independent identifiers. Worked fine as proof of concept. The papers and detail are still around. -- --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 Sep 8 18:23:02 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d891JOP08654 for ipng-dist; Wed, 8 Sep 1999 18:19:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d891JD808647 for ; Wed, 8 Sep 1999 18:19:14 -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 SAA495984; Wed, 8 Sep 1999 18:19:13 -0700 (PDT) Date: Wed, 8 Sep 1999 18:16:54 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: AN interesting article. FYI... contd To: Bill Manning Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199909090010.RAA02544@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 > The NIMROD work of a few years back did explore many details on how > to have independent identifiers. Worked fine as proof of concept. > The papers and detail are still around. Which documents specify this? RFC 1992 talks about the routing architecture but omits many of the non-routing aspects of the system. For instance, - which mappings exist between the different name spaces (it does mention that an endpoint label can be looked up to get both a locator and an EID) - how changes to the locators are handled (an endpoint needs to be notified both when its own locator changes and when its peer locator changes - the security and scalability of such changes need careful study to ensure that the system can be made to work in practise). - "Security issues are not addressed in this document." I guess I'm looking for a reasonable detailed *internet* architecture, as opposed to just routing architecture, that separates the locator and identifier. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 8 18:52:46 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d891kr908687 for ipng-dist; Wed, 8 Sep 1999 18:46:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d891kh808680 for ; Wed, 8 Sep 1999 18:46: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 SAA05461; Wed, 8 Sep 1999 18:46:28 -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 TAA17024; Wed, 8 Sep 1999 19:46:26 -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/smtpfeed 1.00) with ESMTP id KAA12267; Thu, 9 Sep 1999 10:46:20 +0900 (JST) To: Erik Nordmark cc: Kazu Yamamoto , ipng@sunroof.eng.sun.com, junsec@wide.ad.jp, yumi@kame.net In-reply-to: Erik.Nordmark's message of Wed, 08 Sep 1999 16:07:05 MST. 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: interim registration/hotel reservation From: itojun@iijlab.net Date: Thu, 09 Sep 1999 10:46:20 +0900 Message-ID: <12265.936841580@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> http://www.wide.ad.jp/events/199909.ipng-interim/ >I get no route from our (IPv4) socks proxy. There seems to be some routing issue between us. Hope this to be resolved soon. 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 Sep 8 22:20:59 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d895DuJ08990 for ipng-dist; Wed, 8 Sep 1999 22:13:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d895Dk808983 for ; Wed, 8 Sep 1999 22:13: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 WAA00384 for ; Wed, 8 Sep 1999 22:13:43 -0700 (PDT) Received: from minuet.das.harvard.edu (mail.eas.harvard.edu [140.247.50.251]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA01856 for ; Wed, 8 Sep 1999 23:13:43 -0600 (MDT) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id BAA07180; Thu, 9 Sep 1999 01:13:42 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id BAA17366; Thu, 9 Sep 1999 01:13:41 -0400 (EDT) Date: Thu, 9 Sep 1999 01:13:41 -0400 (EDT) Message-Id: <199909090513.BAA17366@endor.deas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: |I think we are more in agreement than disagreement. Folks would like |for addresses to be stable identifiers, because they seem to be the |closest thing available today. At the same time, those who don't have |portable addresses are stuck with the realities that come with that |(e.g., lack of permanence for those addresses). But whether we like it |or not, global addresses are becoming less "stable" as |identifiers. This can't be just wished away. We probably agree about the technical issue but maybe not about motivation. Clearly wishing to solve the problem is necessary if it is to be solved. Global addresses aren't becoming less stable all by themselves. It is the current course of our development. If we wish, we can change that course. IPv6 was a chance to start over and it isn't clear that it is optimal to base its addressing on past implementation restrictions. |> The question is whether we really wish to make the latter case (and |> current status quo) the standard for all IPv6 end users. | |What is the alternative? Well, I see at least two obvious alternatives. -We develop a distributed routing model that handles portable user addresses directly. It is possible to imagine cached route table models that don't have all the answers all the time. Things do not have to work in exactly the way they work today. -We decide that low-level routing absolutely requires a strictly hierarchical (and non-portable) address to function efficiently and thus we introduce another level of portable identifier somewhere between addresses and names. While neither of these are new concepts, either likely represents too radical a departure to happen at this late stage. I suspect that the actual course of events will involve incremental improvements to DDNS until the situation becomes palatable enough to accept. There are a couple of downsides to this. First, it's often harder to retrofit a deployed system than to engineer one from scratch and the result may not be as seamless as it could be. Second, it's simply inconvenient (to the point where it won't happen) to replace all fixed- length binary addresses with domain names. In particular, I strongly doubt we will see tcp protocol control blocks contain DNS names any time soon. Thus the session stability issue can't easily be solved by DDNS. |I agree that this is an undesireable state to |be in. But going back to the idea that everyone's addresses are |portable isn't tenable either. Why isn't it? It seems to have become policy that users shouldn't have portable addresses in _any_ context just because a side effect of a RAM-saving hack under one routing system of one protocol that equates addresses with routing happened to result in the current situation. The leap from the hack to the abstract user restriction is a big one... |Routing in the backbone would not be |able to handle it (i.e., it doesn't scale even today, much less into |the future). The scalability issue has always been debatable, even if we are talking only about brute force implementations of existing models (cf. a recent contributor's comments about cheap routers capable of managing the IPv4 address space without aggregation) and it becomes even more nebulous if we consider completely new models. However, I'd rather not debate the issue since such a debate usually involves a framework of difficult-to-define economic assumptions beyond the purely mathematical notion of scalability. So I propose to confine further comments to approaches that preserve hierarchical routing. |What you seem to be asking for is a solution to the core |problem that no one has yet been able to come up with a solution for: |How can we make renumbering painless enough to carry out so that it |can be done on a regular basis (so that routing information can be |sufficiently aggregated and backbone routing protocols can deal with a |managable number of routing prefixes), yet at the same time have a |stable identifier that end hosts can use in place of addresses? No. I wasn't asking for it. I was pointing out that by failing to provide such a solution IPv6 will hurt its acceptance, possibly severely. But sure, now that you mention it, I'll ask for it. :) |IPv4 hasn't come up with a solution to this problem and neither has |IPv6. IPv4 didn't really need a solution and, in any case, a real solution probably can't just be glued on to IPv4. Again, with IPv6 being a fresh start, there was (is?) a chance to do something at a lower level, or, more generally, to get some code into the stack before it is widely deployed. |Saying we must solve this problem in order to make IPv6 viable |doesn't change the reality that there is no concensus on how (or even |whether it is possible) to solve the problem. Does anybody seriously assert that the problem can't be solved? The problem isn't trivial, but I see no (technical) reasons to keep elevating it to such an untouchable philosophical plane. |And it is the case that v6 has taken steps to make it easier (not |trivial, however) to renumber a site. But the notion that we'll be |able to renumber sites frequently and with no disruption to end sites |is fantasy IMO. Wishing it otherwise won't make it so. However, wishing to make it so is a prerequisite to making it so, IMHO. Do we wish to make it so or not? If not, why not? If so, what price are we willing to pay resource-wise? |> |How to do the mapping in a world where network address can change is a |> |very hard problem, if one wants a solution that scales to the size of |> |the Internet. | |> I agree completely that this is a very hard problem. I also have my |> doubts that it can be pushed onto the DNS without significantly |> changing the DNS as we know it. My main concern, though, is that |> the problem will be avoided rather than solved. | |But is this problem solvable today? I think it is, given the motivation. |There is disagreement today |whether this is an engineering problem or a research problem. If it is |really the latter, the implication is that we don't yet know how to |solve the problem. Again, I think you are making the problem far too abstract and untouchable. Sometimes it's better to have a solution even if it isn't the provably optimal one rather than to have no solution. Sometimes even an obviously ugly solution is better than no solution. Sometimes the design process gets so hung up in the metaphysics of the problem that no solution is implemented. Given that the Internet will always remain at least in part a research project, I don't believe that failing to pigeonhole the problem to engineering or research (or even deciding that it belongs to the latter class) should preclude an attempt at a solution. But that's just my opinion. And I'm starting to repeat myself. :) |> Towards the beginning of the development of IPv6's hierarchical |> address space the general notion seemed to be that nobody would get |> stable, portable address space and that sites could be renumbered |> almost on a whim. | |I think this is a misconception (shared by many unfortunately). I think this misconception was perpetuated by IPv6 proponents, some of whom shared it themselves. :( |I |don't think anyone who has spent a lot of time working on v6 thinks |renumbering can be done "almost on a whim". You don't need to work on IPv6 at all to see this. It was blatantly obvious to any technical observer from the beginning that a great deal of work would be required to back up the hand-waving explanations of painless renumbering. The problem is that every time the detailed issue was raised there was some new reason to table the discussion. Maybe a modified tcp was just around the corner. Or maybe local addresses solve the problem because "nobody" expects persistent connections outside their own intranet. The problem is that those people who have not spent a lot of time working on IPv6 and who are not technical observers may well still believe what you consider a "fantasy." |Could you explain a bit more? Why do you think we are giving ISPs |portable address space? My belief is based on private mail in response to my original posting in this thread. Perhaps the responder would like to elaborate on those plans. |> Enterprise managers may not be so quick to embrace the new protocol |> with only a promise of a later solution to the stability problem. | |Let us be honest, there is no "promise" that there will be a |solution. Great. I agree completely. Let's be honest when trying to sell IPv6. That was my whole point. When making that little IPv4+NAT/whatever vs. IPv6 comparison chart we need to include the downsides. |There is "hope", but no "promise". Who is making such a |promise? Certainly not I. :) |And when I say "hope", I mean that solving this problem has |not been ruled out. But I am not aware of anyone actively working on |this particular problem either at this time. That's unfortunate. I was not aware that the issue had become so inactive. |> There is also the concern about paying a (possibly increasing) |> address fee for all the machines that were previously behind the |> NAT: even though the IPv6 address space is vast, it's structure |> makes it subject to at least the perception of localized scarcity |> that could be used to justify high prices to end users. It would be |> unfortunate to switch to IPv6 only to have to switch again to NAT'ed |> IPv6 for cost reasons. | |I don't follow the cost argument. What I have seen of the costs of |obtaining v6 addresses is that they are comparable to the lowest cost |one has to pay to get v4 addresses. However, for that cost one gets |many many more v6 addresses. So the per-address cost of v6 is |significantly lower. IPv6 addresses are cheap now because they are mostly useless for other than R&D. If and when they become commercially useful to end users the price will increase. I regularly see ISPs asking for ways to detect NAT activity because they bemoan the lost revenue they should be making on IP address fees. One of the disadvantages (to end users) and advantages (to ISPs) of a collection of IPv6 addresses vs. an IPv4 address plus NAT is that the ISP will be able to count and bill for every machine. Add to that the instability of the internal addresses when they become IPv6 and I stand by my assertion that the "upgrade" may be a hard sell. |Having said all this, I am not claiming that v6 has a strong business |argument over v4 (at this time). It is also not my intention to imply |that your concerns aren't valid (I share the lament). However, I think |we need to be honest about what v6 does today, and what possibilities |it allows for the future. At the same time, I think its also important |that folks be realistic about saying v6 should solve this problem and |at the same time implying that we should just Do It. Actually, I think we should just Do It for two reasons. First, it will help acceptance. Second, if and when IPv6 is well deployed and the issue causes problems, the market will implement a solution (or worse, multiple incompatible solutions) that may well be (a) worse kludge(s) than even a far-less-than-optimal approach integrated now. |If someone comes |up with a workable solution, we should have serious discussions about |it. But in the absence of specific, concrete proposals, just saying |"it would be nice" doesn't help and in some cases doesn't adequately |take into consideration that there are real technical reasons why |solutions have not yet been developed. Well, ok, since nobody is working on it, I'll make a proposal. I don't guarantee that this is original since I haven't researched other proposals (though from what you say there aren't many to speak of). Maybe I'll go beyond that and say that there likely isn't a shred of an original notion in the whole thing. That seems like a good disclaimer... I'll try to make it minimally intrusive on existing structure, so it will be a bit of a kludge. At the same time, it will probably be less of a kludge than even later-term solutions. I propose to sever the connection between routing address and identity address since that's really the only approach that can be glued in at this late stage. I propose to create a new address space for identity and leave the existing one for routing. To minimize code changes, I propose that the new address space be the same size as the old. The new address space will be allocatable to end users just like IPv4 addresses were in the good old days. (There's a money-making opportunity here for a new registry that can sell directly to end users.) I propose a set of servers, similar in many respects to the DNS but designed to facilitate efficient and secure dynamic data updates throughout its fabric while also allowing easy and transparent splitting of zones (i.e., dynamic delegation) to insure scalability. The servers will provide a mapping from portable identity addresses to current routable addresses. Near the bottom of the IP layer in each host will exist a mapping layer that uses these servers to convert portable addresses to routable addresses on packet transmission. (The cache issues at this level are well understood.) The portable addresses will be tucked away in an extension header/option/whatever to be restored on reception (no inverse lookup will occur). Most higher layer protocols and APIs will deal with portable addresses only, e.g., any pseudo-header checksum will be based on portable addresses, not routable address. A renumbering of the routable addresses will have no impact on high-level protocols or applications. The mapping layer may also be responsible for updating its routable address in the mapping server. Obviously, this approach is a something akin to a cross between ARP and NAT (though ISPs need not worry--it uses as many routable addresses as portable addresses, so billing will be unaffected :). With some attention to detail it could solve not only the session stability and stable identifier problems but also provide a pretty close approximation to multi-homing for end-user sites. Topologically it is similar to tunneling, but with dynamic setup giving the effect of a fully-connected matrix. In fact, you could recast the implementation in terms of existing tunneling protocols, but this would be less efficient and would not have the nice property of distributing the overhead across hosts. Some random thoughts on this approach: -There would probably have to be some API escape mechanism for administrative programs that need to deal with routable addresses. I believe this could be done with little impact on the API and no impact on most applications. -The mapping servers don't have to (and can't easily) provide inverse lookups to map routable addresses to portable addresses. In any context where the host mapping layer is required to perform a lookup, either both addresses or just the portable address are available. Only the forward lookup is useful from a security perspective. However, to support diagnostic programs we could allow a query to the host itself for its portable address given its routable address. -Isolated and/or transiently connected sites would have a server and/or static configuration burden similar to that imposed by the DNS. For true islands, there's no reason the mapping couldn't simply default to identity. -Careful gleaning of information from the routable to portable address relations in incoming packets could minimize lookup traffic, though it might be tricky to avoid spoofing attacks. A host should probably do something pro-active to inform its peers (as known from its map cache) if its routable address is renumbered to allow reasonable mapping timeouts; however, mechanisms similar to current stale-route detection could clean up after glitches. -If desirable the mapping function could be pushed into a border router. (I'm sure something like _that_ has been proposed.) As another possibility, the mapping function could stay with the host, but a border router could take over the job of updating the mapping server em masse since it likely has to participate in renumbering and may have all the data for the site. This could be a big win since individual hosts wouldn't need keys to update the mapping servers themselves. -It may be possible, though undesirable, for hosts participating in this addressing protocol to interoperate with non-participating hosts at the expense of some address ambiguity. If we gave up one bit in the current address (i.e., half the address space) we could make the address type self-determining, but there's no real advantage in that if this model were fully deployed. -This approach presents no additional route table load to the backbone routers and in fact does not require any support from them at all. Routers actively hostile to the protocol could block the header information, but even that could be overcome with suitable encryption. -This approach does not require the cooperation of the routable address administration, though it would be nice to have a little static space to root the mapping server tree. Even this isn't necessary since it could bootstrap from a DNS lookup. The entire system could be offered by a third- party much like that funky top-level-domain company, though I think that would be an unfortunate outcome. -The main price for portable addresses would be additional header bloat, much as this was the price for big IPv6 addresses in the first place. I consider the value added by portable addresses to be worth the price at least to the extent that IPv6's bigger addresses were worth the price. I'm sure others will disagree. -The most tricky aspect of the implementation is probably the rendezvous protocol among the mapping servers in a fluid routing address space. But if carefully planned, this protocol can evolve transparently. (Keep the part in the host stack simple!) Any argument that we can't implement such a system that operates in the face of currently anticipated levels of renumbering with currently available DDNS-like technology equally means that we can't support DDNS under IPv6 and that in turn hurts IPv6's case quite a bit. -One can imagine neat proxy-address hacks to maintain DHCP and dial-on-demand routable address pools smaller than the total number of portable addresses/nodes while still permitting outward dynamic connections. As soon as, say, the PPP connection is established, the target end node is "renumbered" from the proxy to an allocated routable address. This would be useful if/when routable IPv6 addresses become more expensive. Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 9 01:02:03 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d897vjb09152 for ipng-dist; Thu, 9 Sep 1999 00:57:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d897vX809144 for ; Thu, 9 Sep 1999 00:57:34 -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 AAA28048 for ; Thu, 9 Sep 1999 00:57:34 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA02856 for ; Thu, 9 Sep 1999 01:57:32 -0600 (MDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id KAA02336; Thu, 9 Sep 1999 10:57:31 +0300 (EET DST) Date: Thu, 9 Sep 1999 10:57:31 +0300 (EET DST) From: Markku Savela Message-Id: <199909090757.KAA02336@anise.tte.vtt.fi> To: ipng@sunroof.eng.sun.com In-reply-to: <199909090513.BAA17366@endor.deas.harvard.edu> (message from Dan Lanciani on Thu, 9 Sep 1999 01:13:41 -0400 (EDT)) Subject: Identifier and routing IPv6 addresses? Would Mobile-IP solve any? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I changed the subject from "AN interesting article. FYI... contd". > Thomas Narten wrote: > > |I think we are more in agreement than disagreement. Folks would like > |for addresses to be stable identifiers, because they seem to be the > |closest thing available today. At the same time, those who don't have > |portable addresses are stuck with the realities that come with that > |(e.g., lack of permanence for those addresses). But whether we like it > |or not, global addresses are becoming less "stable" as > |identifiers. This can't be just wished away. I'm just wondering if Mobile-IP architecture would bring some solutions for this problem? - I assume there are at least some organizations or entities that can have fairly permanent globally routable addresses (phone companies could run home agent service for phonenumbers mapped as IPv6 addresses, for example) Based on this, couldn't there be a new class of service: "address hosting". An organization with globally routable IPv6 address block would run Mobile IP home agent service for the addressess and would register them to clients. Such client could then sign on with any ISP as mobile host, the ISPs dynamically allocated address would just be the care address. Assuming mobile-ip6 would be present on ipv6 stacks, and that the assigned "care address" is fairly permanent, the home agent would be needed only at connection setup. The ISP's don't need to do anything special to support this (other than allowing true end-to-end IP connections, get rid of the pesky NATs!) Additionally, the client could always use the care address explicitly for short term connections (like web browsing etc). One thing though: it should be possible to have "home agent" for a network. I'm not sure this is possible with current Mobile-ip, the documents always use examples of single host. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 9 05:44:50 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d89CfIJ09485 for ipng-dist; Thu, 9 Sep 1999 05:41:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d89CfA809478 for ; Thu, 9 Sep 1999 05:41:10 -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 FAA11108 for ; Thu, 9 Sep 1999 05:41:10 -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 GAA26228 for ; Thu, 9 Sep 1999 06:41:06 -0600 (MDT) Received: by odin.digi-data.com id <15234>; Thu, 9 Sep 1999 08:38:00 -0400 Message-Id: <99Sep9.083800gmt-0400.15234@odin.digi-data.com> Date: Thu, 9 Sep 1999 08:43:57 -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: Re: AN interesting article. FYI... contd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Erik, Erik Nordmark wrote: > > > Have two separate identifiers. One is transient and is used to > > indicate the position in the routing hierarchy, and the other is > > permanent and can be used to umambiguously identify a host within > > the administrative hierarchy. You also need a way to map from > > the permanent identifier to the current transient identifier. > > This sounds very attractive and feasible at the 50,000 foot level. > But the devil is in the details. And since there isn't a fleshed out > proposal for such a system it is impossible to discuss the advantages > and disadvantages. Then it just begs the question. What will it take to produce such a proposal? I mean what would be the attributes of an acceptable proposal? > > Even high level "details" like whether or not you can map from > one of the identifiers to the other and vice versa, appear to be open to > discussion among the set of people that have proposed a solution along the > above lines. > As I see it, anyone proposing a solution using two separate identifiers would need to decide on at least the following issues. (1) Do the identifiers need to be globally unique, or merely unique to the peer systems? (1a) If not globally unique, how should they be negotiated between the peers? (1b) If globally unique, how should the global mapping to IP addresses be maintained? (2) Whatever the solution, it must work equally well for TCP as well as UDP. (3) A more favourable solution will not require the alteration of either TCP or UDP. (4) What means can be used to address the issue of mapping the identifier to an IP address within each peer system? (5) What should be the lifetime of such an identifier? (5a) How should that lifetime be determined? My own opinion is that the identifier does not need to be globally unique, but if in fact it does need to be, then a mechanism similar to DNS should be sufficient. 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 Sep 9 05:45:21 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d89ChuC09494 for ipng-dist; Thu, 9 Sep 1999 05:43:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d89Chk809487 for ; Thu, 9 Sep 1999 05:43: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 FAA19829 for ; Thu, 9 Sep 1999 05:43:46 -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 GAA26844 for ; Thu, 9 Sep 1999 06:43:42 -0600 (MDT) Received: by odin.digi-data.com id <15233>; Thu, 9 Sep 1999 08:40:32 -0400 Message-Id: <99Sep9.084032gmt-0400.15233@odin.digi-data.com> Date: Thu, 9 Sep 1999 08:46:28 -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: Re: AN interesting article. FYI... contd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Dan, > |Routing in the backbone would not be > |able to handle it (i.e., it doesn't scale even today, much less into > |the future). > > The scalability issue has always been debatable, even if we are talking only > about brute force implementations of existing models (cf. a recent contributor's > comments about cheap routers capable of managing the IPv4 address space without > aggregation) and it becomes even more nebulous if we consider completely new > models. However, I'd rather not debate the issue since such a debate usually > involves a framework of difficult-to-define economic assumptions beyond the > purely mathematical notion of scalability. So I propose to confine further > comments to approaches that preserve hierarchical routing. > There is really very little to debate in the Scalability Issue. The simple fact is that in a network with flat routing (portable addresses) the number of routes that must be managed in the network grows with the square of the number of nodes in the network. Now while current technology does allow routers to handle that at the current size of the internet and with the current IP address lengths, I doubt that situation will carry over into IPv6. Even if you were to start with flat routing in IPv6 now, you will eventually need to impose some hierarchy upon the network or change the routing topology to something else that allows the number of routes to grow more slowly. In other words introduce non-portable addresses. 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 Sep 9 06:03:29 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d89CxuB09548 for ipng-dist; Thu, 9 Sep 1999 05:59:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d89Cxm809541 for ; Thu, 9 Sep 1999 05:59:48 -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 FAA11860 for ; Thu, 9 Sep 1999 05:59:48 -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 GAA00618 for ; Thu, 9 Sep 1999 06:59:46 -0600 (MDT) Received: by odin.digi-data.com id <15233>; Thu, 9 Sep 1999 08:56:35 -0400 Message-Id: <99Sep9.085635gmt-0400.15233@odin.digi-data.com> Date: Thu, 9 Sep 1999 09:02:24 -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: Dan Lanciani , IPng Mailing List Subject: Re: AN interesting article. FYI... contd References: <199909090513.BAA17366@endor.deas.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Dan, > > IPv6 addresses are cheap now because they are mostly useless for other than > R&D. If and when they become commercially useful to end users the price will > increase. I regularly see ISPs asking for ways to detect NAT activity because > they bemoan the lost revenue they should be making on IP address fees. One of > the disadvantages (to end users) and advantages (to ISPs) of a collection of > IPv6 addresses vs. an IPv4 address plus NAT is that the ISP will be able to > count and bill for every machine. Add to that the instability of the internal > addresses when they become IPv6 and I stand by my assertion that the "upgrade" > may be a hard sell. I dare say that any ISP who does this is acting very unethically. The end user or end-site is only purchasing one thing from his ISP, and that is **bandwidth**. Why ought the ISP to care how many IP addresses the end-user has moving traffic over the link purchased from the ISP? The bandwidth is what the ISP sold to the end-user. The ISP should not charge for anything other than what is used. 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 Sep 9 06:19:25 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d89DFGG09566 for ipng-dist; Thu, 9 Sep 1999 06:15:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d89DF8809559 for ; Thu, 9 Sep 1999 06:15:08 -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 GAA04703 for ; Thu, 9 Sep 1999 06:15:08 -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 HAA04966 for ; Thu, 9 Sep 1999 07:14:53 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id PAA25860; Thu, 9 Sep 1999 15:12:44 +0200 (MET DST) Message-ID: <19990909151244.D25688@theory.cs.uni-bonn.de> Date: Thu, 9 Sep 1999 15:12:44 +0200 From: Ignatios Souvatzis To: robert@digi-data.com, Dan Lanciani , IPng Mailing List Subject: Re: AN interesting article. FYI... contd References: <199909090513.BAA17366@endor.deas.harvard.edu> <99Sep9.085635gmt-0400.15233@odin.digi-data.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <99Sep9.085635gmt-0400.15233@odin.digi-data.com>; from Robert Honore on Thu, Sep 09, 1999 at 09:02:24AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Sep 09, 1999 at 09:02:24AM -0400, Robert Honore wrote: > I dare say that any ISP who does this is acting very unethically. The end user > or end-site is only purchasing one thing from his ISP, and that is > **bandwidth**. Why ought the ISP to care how many IP addresses the end-user has > moving traffic over the link purchased from the ISP? The bandwidth is what the > ISP sold to the end-user. The ISP should not charge for anything other than > what is used. and routing and DNS entries. Don't forget that. -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 9 06:23:43 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d89DMB009585 for ipng-dist; Thu, 9 Sep 1999 06:22:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d89DM2809578 for ; Thu, 9 Sep 1999 06:22: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 GAA21920 for ; Thu, 9 Sep 1999 06:22:02 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA07045 for ; Thu, 9 Sep 1999 07:22:01 -0600 (MDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Sep 9 09:21:04 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.17.248.48]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA14774; Thu, 9 Sep 1999 09:21:01 -0400 (EDT) Message-ID: <37D7B433.24AFB4A6@dnrc.bell-labs.com> Date: Thu, 09 Sep 1999 09:20:51 -0400 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Lanciani CC: ipng@sunroof.eng.sun.com Subject: Addresses and multiplexing Re: AN interesting article. FYI... contd References: <199909090513.BAA17366@endor.deas.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: [..] > I regularly see ISPs asking for ways to detect NAT activity because > they bemoan the lost revenue they should be making on IP address fees. What a depressing notion. "My oh my, the users are learning to multiplex! Must figure out a way to stop this...." Sounds like the early reputed telco reaction to digital links ("Darn, the user will be able to fit N phone connections onto this neat digital link, I need to price it at >= N*cost_of_phone_links just in case that's what they try using it for..") gja -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 9 08:31:49 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d89FSG809679 for ipng-dist; Thu, 9 Sep 1999 08:28:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d89FS7809672 for ; Thu, 9 Sep 1999 08:28: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 IAA26171 for ; Thu, 9 Sep 1999 08:28:07 -0700 (PDT) Received: from samantha.lysator.liu.se (samantha.lysator.liu.se [130.236.254.202]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00508 for ; Thu, 9 Sep 1999 08:28:06 -0700 (PDT) Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206]) by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id RAA29151; Thu, 9 Sep 1999 17:28:03 +0200 (MET DST) Received: (from nisse@localhost) by sanna.lysator.liu.se (8.8.8/8.8.7) id RAA26486; Thu, 9 Sep 1999 17:28:11 +0200 (MET DST) To: Dan Lanciani Cc: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd References: <199909090513.BAA17366@endor.deas.harvard.edu> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 09 Sep 1999 17:28:10 +0200 In-Reply-To: Dan Lanciani's message of "Thu, 9 Sep 1999 01:13:41 -0400 (EDT)" Message-ID: Lines: 79 X-Mailer: Gnus v5.4.59/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I've been lurking on this list for a while. I think your concerns are important (and touches things like tcp-stability, multihoming, mobility, which I have seen discussed here earlier). Dan Lanciani writes: > Well, ok, since nobody is working on it, I'll make a proposal. I > don't guarantee that this is original since I haven't researched > other proposals (though from what you say there aren't many to speak > of). Maybe I'll go beyond that and say that there likely isn't a > shred of an original notion in the whole thing. That seems like a > good disclaimer... I'll try to make it minimally intrusive on > existing structure, so it will be a bit of a kludge. If you want to look deeper into these issues, I think that is excellent. I would also like to see some pointers (or even better, a survey) of previous work in this area. > At the same time, it will probably be less of a kludge than even later-term > solutions. > > I propose to sever the connection between routing address and identity > address since that's really the only approach that can be glued in at > this late stage. I propose to create a new address space for identity > and leave the existing one for routing. To minimize code changes, I > propose that the new address space be the same size as the old. The > new address space will be allocatable to end users just like IPv4 > addresses were in the good old days. (There's a money-making opportunity > here for a new registry that can sell directly to end users.) Is there any particular reason why not allocate the identifiers as a subspace of the IPv6 address spase (outside of the aggregatable unicast space, of course)? I imagine that would make gradual deployment easier; to a host that doesn't know how to map identifier addresses, those addresses will simply appear to be unreachable. (It's even conceivable to let the local router do the mapping and source-route them to the right aggregatable address). > I propose a set of servers, similar in many respects to the DNS but > designed to facilitate efficient and secure dynamic data updates > throughout its fabric while also allowing easy and transparent > splitting of zones (i.e., dynamic delegation) to insure scalability. I suspect this is the difficult part of it all. You need some sort of hierarchy in order to distribute management and allocation of the "identity addresses", where higher nodes delegates part of the space to lower nodes, just like in DNS. And there are some other interesting points comparing this to DNS: 1. Switching "identity provider" is analogous to switching DNS provider. I.e. it implies that your identity or FQDN changes, as the point where it is attached in the delegation hierarchy changes. 2. Currently, DNS-space is not much of a hierarchy. It seems all "sites" buy a name of the type "foo.com.", and put all externally visible machines there. Really large sites or corporations may have one more step of internal delegation. The point is, that this appears to actually work. So perhaps it's good enough to have a flat identity space, or at most two-level space? Another question is exactly what advantage the short "binary" addresses have over dns names. You say that they fit easier into packet headers, tcp control blocks, etc. If that is the main reason to use them rather than FQDN:s, perhaps we could get away with representing a FQDN with its md5 sum, and we will have at least one step in the lookup process for free. Or if that won't work, I think the reason why may give some information about the nature of the problem. Hmm. Anyway, I don't think this problem will be solved by me or anybody else popping ideas from their head. Someone has to figure out the evil little details, propose a solution, and then we can discuss that. If you can do that, I think that is a very valuable contribution. /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 9 20:11:48 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8A37Gk00683 for ipng-dist; Thu, 9 Sep 1999 20:07:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8A377000676 for ; Thu, 9 Sep 1999 20:07:07 -0700 (PDT) Received: from fenris.spnusw.sun.com (halley.EBay.Sun.COM [129.150.111.35]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA08065; Thu, 9 Sep 1999 20:07:05 -0700 (PDT) Received: from orpheus.amdahl.com (orpheus.amdahl.com [129.212.11.6]) by fenris.spnusw.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28867; Thu, 9 Sep 1999 20:00:21 -0700 (PDT) Received: by orpheus.amdahl.com (8.9.3/8.9.3) id UAA24132; Thu, 9 Sep 1999 20:07:05 -0700 (PDT) Received: from fujitsuI.fujitsu.com (fujitsuI.fujitsu.com [133.164.11.1]) by orpheus.amdahl.com (8.9.3/8.9.3) with ESMTP id UAA24087; Thu, 9 Sep 1999 20:07:01 -0700 (PDT) Received: by fujitsuI.fujitsu.com (8.9.3/8.9.3) id UAA16843; Thu, 9 Sep 1999 20:06:30 -0700 (PDT) Received: from abroad2.proxy.fujitsu.co.jp ([133.161.11.2]) by fujitsuI.fujitsu.com (8.9.3/8.9.3) with ESMTP id UAA16839; Thu, 9 Sep 1999 20:06:29 -0700 (PDT) Received: from abroad.proxy.fujitsu.co.jp by abroad2.proxy.fujitsu.co.jp (8.9.3/3.7W-9909-Abroad Gateway) id MAA04350; Fri, 10 Sep 1999 12:06:28 +0900 (JST) Received: from fdmnews.fujitsu.co.jp by abroad.proxy.fujitsu.co.jp (8.9.3/3.7W-9909-Abroad Gateway) id MAA02169; Fri, 10 Sep 1999 12:06:27 +0900 (JST) Received: from chisato.nd.net.fujitsu.co.jp by fdmnews.fujitsu.co.jp (8.9.3/3.7W-9909-Fujitsu Domain Master) id MAA26428; Fri, 10 Sep 1999 12:06:26 +0900 (JST) Received: from localhost (dhcp7186.nd.net.fujitsu.co.jp [10.18.7.186]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id MAA06428; Fri, 10 Sep 1999 12:06:25 +0900 (JST) To: jinmei@isl.rdc.toshiba.co.jp Cc: tim@mentat.com, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: <14287.50689.861424.62646Q@condor.isl.rdc.toshiba.co.jp> References: <199909030702.AAA10814@feller.mentat.com> <14287.50689.861424.62646Q@condor.isl.rdc.toshiba.co.jp> X-Mailer: Mew version 1.94b5 on XEmacs 20.4 (Emerald) X-Prom-Mew: Prom-Mew 1.93 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990910120608T.shin@nd.net.fujitsu.co.jp> Date: Fri, 10 Sep 1999 12:06:08 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990212(IM106) Lines: 92 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Though currently I don't have a way to access ANSI C specification, > your comment seems reasonable. Actually, we had a discussion in the > KAME team that we could safely use bitfields, but I forgot the > consensus. > > I personally agree with you; we shouldn't use bitfields (especially > for packet formats) if we regard portability. > > I'll confirm the opinion of the author of the structures for router > renumbering. > > Thanks, After the KAME team and WIDE group discussion, we decided to change the structure not to use bitfields. This is a revised proposal of router renum packet structure. Comments are welcome. Yoshinobu Inoue struct icmp6_router_renum { /* router renumbering header */ struct icmp6_hdr rr_hdr; u_int8_t rr_segnum; u_int8_t rr_flags; u_int16_t rr_maxdelay; u_int32_t rr_reserved; }; #define ICMP6_RR_FLAGS_SEGNUM 0x1 #define ICMP6_RR_FLAGS_TEST 0x2 #define ICMP6_RR_FLAGS_REQRESULT 0x4 #define ICMP6_RR_FLAGS_FORCEAPPLY 0x8 #define ICMP6_RR_FLAGS_SPECSITE 0x10 #define ICMP6_RR_FLAGS_PREVDONE 0x20 #define rr_type rr_hdr.icmp6_type #define rr_code rr_hdr.icmp6_code #define rr_cksum rr_hdr.icmp6_cksum #define rr_seqnum rr_hdr.icmp6_data32[0] struct rr_pco_match { /* match prefix part */ u_int8_t rpm_code; u_int8_t rpm_len; u_int8_t rpm_ordinal; u_int8_t rpm_matchlen; u_int8_t rpm_minlen; u_int8_t rpm_maxlen; u_int16_t rpm_reserved; struct in6_addr rpm_prefix; }; #define RPM_PCO_ADD 1 #define RPM_PCO_CHANGE 2 #define RPM_PCO_SETGLOBAL 3 struct rr_pco_use { /* use prefix part */ u_int8_t rpu_uselen; u_int8_t rpu_keeplen; u_int8_t rpu_ramask; u_int8_t rpu_raflags; u_int32_t rpu_vltime; u_int32_t rpu_pltime; u_int32_t rpu_flags; struct in6_addr rpu_prefix; }; #define ICMP6_RR_PCOUSE_RAFLAGS_ONLINK 0x1 #define ICMP6_RR_PCOUSE_RAFLAGS_AUTO 0x2 #if BYTE_ORDER == BIG_ENDIAN #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80000000 #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40000000 #elif BYTE_ORDER == LITTLE_ENDIAN #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80 #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40 #endif struct rr_result { /* router renumbering result message */ u_int16_t rrr_flags; u_int8_t rrr_ordinal; u_int8_t rrr_matchedlen; u_int32_t rrr_ifid; struct in6_addr rrr_prefix; }; #if BYTE_ORDER == BIG_ENDIAN #define ICMP6_RR_RESULT_FLAGS_OOB 0x0002 #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0001 #elif BYTE_ORDER == LITTLE_ENDIAN #define ICMP6_RR_RESULT_FLAGS_OOB 0x02 #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x01 #endif -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 9 23:15:28 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8A6B3A00966 for ipng-dist; Thu, 9 Sep 1999 23:11:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8A6Ap000959 for ; Thu, 9 Sep 1999 23:10:52 -0700 (PDT) Received: from fenris.spnusw.sun.com (halley.EBay.Sun.COM [129.150.111.35]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA18555; Thu, 9 Sep 1999 23:10:51 -0700 (PDT) Received: from orpheus.amdahl.com (orpheus.amdahl.com [129.212.11.6]) by fenris.spnusw.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01284; Thu, 9 Sep 1999 23:04:07 -0700 (PDT) Received: by orpheus.amdahl.com (8.9.3/8.9.3) id XAA15239; Thu, 9 Sep 1999 23:10:51 -0700 (PDT) Received: from fujitsuI.fujitsu.com (fujitsuI.fujitsu.com [133.164.11.1]) by orpheus.amdahl.com (8.9.3/8.9.3) with ESMTP id XAA15235; Thu, 9 Sep 1999 23:10:49 -0700 (PDT) Received: by fujitsuI.fujitsu.com (8.9.3/8.9.3) id XAA03355; Thu, 9 Sep 1999 23:10:18 -0700 (PDT) Received: from abroad2.proxy.fujitsu.co.jp ([133.161.11.2]) by fujitsuI.fujitsu.com (8.9.3/8.9.3) with ESMTP id XAA03351; Thu, 9 Sep 1999 23:10:17 -0700 (PDT) Received: from abroad.proxy.fujitsu.co.jp by abroad2.proxy.fujitsu.co.jp (8.9.3/3.7W-9909-Abroad Gateway) id PAA08674; Fri, 10 Sep 1999 15:10:16 +0900 (JST) Received: from m2.gw.fujitsu.co.jp by abroad.proxy.fujitsu.co.jp (8.9.3/3.7W-9909-Abroad Gateway) id PAA09175; Fri, 10 Sep 1999 15:10:15 +0900 (JST) Received: from chisato.nd.net.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.9.3/3.7W-9909-Fujitsu Domain Master) id PAA15290; Fri, 10 Sep 1999 15:10:15 +0900 (JST) Received: from localhost (dhcp7186.nd.net.fujitsu.co.jp [10.18.7.186]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id PAA13179; Fri, 10 Sep 1999 15:10:14 +0900 (JST) To: ipng@sunroof.eng.sun.com Cc: jinmei@isl.rdc.toshiba.co.jp, tim@mentat.com, Erik.Nordmark@eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: <14287.50689.861424.62646Q@condor.isl.rdc.toshiba.co.jp> References: <199909030702.AAA10814@feller.mentat.com> <14287.50689.861424.62646Q@condor.isl.rdc.toshiba.co.jp> X-Mailer: Mew version 1.94b5 on XEmacs 20.4 (Emerald) X-Prom-Mew: Prom-Mew 1.93 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990910150956I.shin@nd.net.fujitsu.co.jp> Date: Fri, 10 Sep 1999 15:09:56 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990212(IM106) Lines: 95 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk #I resend this message because there seemed to be some mail error. #Sorry for anyone getting this mail twice. > Though currently I don't have a way to access ANSI C specification, > your comment seems reasonable. Actually, we had a discussion in the > KAME team that we could safely use bitfields, but I forgot the > consensus. > > I personally agree with you; we shouldn't use bitfields (especially > for packet formats) if we regard portability. > > I'll confirm the opinion of the author of the structures for router > renumbering. > > Thanks, After the KAME team and WIDE group discussion, we decided to change the structure not to use bitfields. This is a revised proposal of router renum packet structure. Comments are welcome. Yoshinobu Inoue struct icmp6_router_renum { /* router renumbering header */ struct icmp6_hdr rr_hdr; u_int8_t rr_segnum; u_int8_t rr_flags; u_int16_t rr_maxdelay; u_int32_t rr_reserved; }; #define ICMP6_RR_FLAGS_SEGNUM 0x1 #define ICMP6_RR_FLAGS_TEST 0x2 #define ICMP6_RR_FLAGS_REQRESULT 0x4 #define ICMP6_RR_FLAGS_FORCEAPPLY 0x8 #define ICMP6_RR_FLAGS_SPECSITE 0x10 #define ICMP6_RR_FLAGS_PREVDONE 0x20 #define rr_type rr_hdr.icmp6_type #define rr_code rr_hdr.icmp6_code #define rr_cksum rr_hdr.icmp6_cksum #define rr_seqnum rr_hdr.icmp6_data32[0] struct rr_pco_match { /* match prefix part */ u_int8_t rpm_code; u_int8_t rpm_len; u_int8_t rpm_ordinal; u_int8_t rpm_matchlen; u_int8_t rpm_minlen; u_int8_t rpm_maxlen; u_int16_t rpm_reserved; struct in6_addr rpm_prefix; }; #define RPM_PCO_ADD 1 #define RPM_PCO_CHANGE 2 #define RPM_PCO_SETGLOBAL 3 struct rr_pco_use { /* use prefix part */ u_int8_t rpu_uselen; u_int8_t rpu_keeplen; u_int8_t rpu_ramask; u_int8_t rpu_raflags; u_int32_t rpu_vltime; u_int32_t rpu_pltime; u_int32_t rpu_flags; struct in6_addr rpu_prefix; }; #define ICMP6_RR_PCOUSE_RAFLAGS_ONLINK 0x1 #define ICMP6_RR_PCOUSE_RAFLAGS_AUTO 0x2 #if BYTE_ORDER == BIG_ENDIAN #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80000000 #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40000000 #elif BYTE_ORDER == LITTLE_ENDIAN #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80 #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40 #endif struct rr_result { /* router renumbering result message */ u_int16_t rrr_flags; u_int8_t rrr_ordinal; u_int8_t rrr_matchedlen; u_int32_t rrr_ifid; struct in6_addr rrr_prefix; }; #if BYTE_ORDER == BIG_ENDIAN #define ICMP6_RR_RESULT_FLAGS_OOB 0x0002 #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0001 #elif BYTE_ORDER == LITTLE_ENDIAN #define ICMP6_RR_RESULT_FLAGS_OOB 0x02 #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x01 #endif -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 10 07:27:11 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8AENY202301 for ipng-dist; Fri, 10 Sep 1999 07:23:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8AENN002294 for ; Fri, 10 Sep 1999 07:23:23 -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 HAA03595; Fri, 10 Sep 1999 07:23:21 -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 HAA18217; Fri, 10 Sep 1999 07:23:20 -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 JAA01437; Fri, 10 Sep 1999 09:23:08 -0500 (CDT) Message-Id: <199909101423.JAA01437@gungnir.fnal.gov> To: Yoshinobu Inoue Cc: jinmei@isl.rdc.toshiba.co.jp, tim@mentat.com, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Comments on 2292bis (Adv. API) In-reply-to: Your message of Fri, 10 Sep 1999 12:06:08 +0900. <19990910120608T.shin@nd.net.fujitsu.co.jp> Date: Fri, 10 Sep 1999 09:23:08 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk #define ICMP6_RR_FLAGS_SEGNUM 0x1 #define ICMP6_RR_FLAGS_TEST 0x2 #define ICMP6_RR_FLAGS_REQRESULT 0x4 #define ICMP6_RR_FLAGS_FORCEAPPLY 0x8 #define ICMP6_RR_FLAGS_SPECSITE 0x10 #define ICMP6_RR_FLAGS_PREVDONE 0x20 Either I'm confused, or these are a little mixed-up. I don't know what the first one is, and I would expect the others to have values 0x80, 0x40, 0x20, 0x10, 0x08 in that order. (I just tuned in to this thread and may have missed some key information.) 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 Sep 10 07:49:22 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8AEjlP02327 for ipng-dist; Fri, 10 Sep 1999 07:45:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8AEjc002320 for ; Fri, 10 Sep 1999 07:45: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 HAA05883 for ; Fri, 10 Sep 1999 07:45:38 -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 HAA25841 for ; Fri, 10 Sep 1999 07:45:36 -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 KAA31368; Fri, 10 Sep 1999 10:45:34 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA29344; Fri, 10 Sep 1999 10:45:33 -0400 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id KAA30163; Fri, 10 Sep 1999 10:42:50 -0400 Message-Id: <199909101442.KAA30163@rotala.raleigh.ibm.com> To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd In-Reply-To: Message from Dan Lanciani of "Thu, 09 Sep 1999 01:13:41 EDT." <199909090513.BAA17366@endor.deas.harvard.edu> Date: Fri, 10 Sep 1999 10:42:49 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, A few comments. Unfortunatley, I don't have the time right now to respond to all of your proposal in detail, but I will observe that there are a number of details missing. Unfortunately, the devil is in the details and without the details, its hard to call out specific issues. This has been one of recurring problems with discussing and analyzing alternate architectures -- it's easy to imagine a system working if one hand-waves some of the details. Yet, those details are often critical and important. Also, you raise an oft-expressed feeling that all that needs to happen is for some folks to go off and design such a system. At one level, that is correct. However, there have been a number of such attempts in the past, with unfortunately, the details/results mostly discussed in hallways and on various mailing lists (e.g., big-internet list). A number of the specific things you propose have a familiar ring. If you haven't done so already, I'd encourage you to have a look in the following places: - draft-ietf-ipngwg-esd-analysis-04.txt and Mike O'Dell's expired ID that this draft considers (available at ftp://munnari.oz.au/gseaddr-00.txt). The detailed meeting minutes from the february 1997 ipng meeting where the proposal was discussed in detail are also useful reading: http://playground.sun.com/ipng/minutes/ipng-minutes-feb97.txt - browse the big-internet archive at ftp://munnari.oz.au/big-internet Also, I don't think it is entirely a question of whether such a system can be built. No doubt it can. The relevant question is whether in the end we'd have a system that is implementable, deployable, and scalable to an internet with billions of nodes. And, (and this is _key_) would the resultant system be any better than what we already have in terms of total overall cost, understandabilty, robustness, operational complexity, etc? I often think that one of curses of IPv4 is that both its strengths and weaknesses are well understood. People tend to focus on the weaknesses (e.g., non-portable addresses) and consequently the grass looks greener on the other side of the hill. It also appears, however, that the alternate proposals don't really make the renumbering/portability issue go away, they just move a hard problem somewhere else, where it is not necessarly recognized as being a hard problem (at first) and hand-waved as solvable. Here again is where details are needed. One needs to understand what has been shifted elsewhere, and whether the new/shifted problem is any easier to solve. Case in point: if we separate the identifier and locator portions of an address, one almost certainly needs a way of mapping the identifier into an locator. This problem is one that we don't know if it can be reasonably solved without seeing the details of a specific proposal. Just saying "servers do the mapping" is hand waving. > |I agree that this is an undesireable state to > |be in. But going back to the idea that everyone's addresses are > |portable isn't tenable either. > Why isn't it? It seems to have become policy that users shouldn't > have portable addresses in _any_ context just because a side effect > of a RAM-saving hack under one routing system of one protocol that > equates addresses with routing happened to result in the current > situation. The leap from the hack to the abstract user restriction > is a big one... It is an enduring myth that backbone routing can scale arbitrarily and that the only issue is an implementation defficiency from one vendor (which has long since been fixed). The size of the forwarding tables that routers need to maintain is not the only (or even most important) issue. The issues is scalability of the routing computations that (as an end result) produce the forwarding table that routers use to actually forward packets. The cost of the calculation is dependent on the number of factors, including the number of routing prefixes one has to deal with, the number of peers a router is exchanging information with, plus the size/complexity of the policy database that BGP uses to shape its routing calculation, the frequency of updates (e.g., one can increase the number of routes one can deal with by slowing convergence time so that routing tables aren't required to react to routing changes quickly -- something many folks wouldn't react positively to), etc. The folks actually responsible for keeping routing working in the default free zones of the backbones are the ones that have pointed out these issues. > |There is disagreement today > |whether this is an engineering problem or a research problem. If it is > |really the latter, the implication is that we don't yet know how to > |solve the problem. > Again, I think you are making the problem far too abstract and > untouchable. Sometimes it's better to have a solution even if it > isn't the provably optimal one rather than to have no solution. > Sometimes even an obviously ugly solution is better than no > solution. Sometimes the design process gets so hung up in the > metaphysics of the problem that no solution is implemented. Given > that the Internet will always remain at least in part a research > project, I don't believe that failing to pigeonhole the problem to > engineering or research (or even deciding that it belongs to the > latter class) should preclude an attempt at a solution. But that's > just my opinion. And I'm starting to repeat myself. :) The reason I make the distinction between engineering and research is that the IETF is good at making engineering tradeoffs, and it also means the issues are well enough understood that its something we can likely build and deploy -- we just need to work through the details. If it's _research_, however, we have much less confidence that something can be built and deployed. The Internet is long past being a research toy. Before betting the future internet on a new architecture, we need to have confidence that it can be deployed and will work. The problem with "a solution ... even if not optimal", is that we may find that it doesn't work/scale once deployed and may not actually be any better than what we already have. That is not the kind of gamble I think we can make when we're talking about basic infrastructure. Hence, we need to work through the details first. Perhaps followups (on specific proposals) should go to big-internet@munnari.oz.au? There are likely a number of folks on that list that have an interest in this topic that do not subscribe to the ipng list. 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 Sep 10 08:53:50 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8AFo5Y02406 for ipng-dist; Fri, 10 Sep 1999 08:50:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8AFnt002396 for ; Fri, 10 Sep 1999 08:49:56 -0700 (PDT) Received: from fenris.spnusw.sun.com (halley.EBay.Sun.COM [129.150.111.35]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA15429; Fri, 10 Sep 1999 08:49:54 -0700 (PDT) Received: from orpheus.amdahl.com (orpheus.amdahl.com [129.212.11.6]) by fenris.spnusw.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12363; Fri, 10 Sep 1999 08:43:09 -0700 (PDT) Received: by orpheus.amdahl.com (8.9.3/8.9.3) id IAA09457; Fri, 10 Sep 1999 08:49:54 -0700 (PDT) Received: from fujitsuI.fujitsu.com (fujitsuI.fujitsu.com [133.164.11.1]) by orpheus.amdahl.com (8.9.3/8.9.3) with ESMTP id IAA09449; Fri, 10 Sep 1999 08:49:52 -0700 (PDT) Received: by fujitsuI.fujitsu.com (8.9.3/8.9.3) id IAA27082; Fri, 10 Sep 1999 08:49:21 -0700 (PDT) Received: from abroad2.proxy.fujitsu.co.jp ([133.161.11.2]) by fujitsuI.fujitsu.com (8.9.3/8.9.3) with ESMTP id IAA27030; Fri, 10 Sep 1999 08:49:13 -0700 (PDT) Received: from abroad.proxy.fujitsu.co.jp by abroad2.proxy.fujitsu.co.jp (8.9.3/3.7W-9909-Abroad Gateway) id AAA21505; Sat, 11 Sep 1999 00:49:12 +0900 (JST) Received: from m2.gw.fujitsu.co.jp by abroad.proxy.fujitsu.co.jp (8.9.3/3.7W-9909-Abroad Gateway) id AAA27248; Sat, 11 Sep 1999 00:49:11 +0900 (JST) Received: from incapgw.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.9.3/3.7W-9909-Fujitsu Domain Master) id AAA17965; Sat, 11 Sep 1999 00:49:11 +0900 (JST) Received: from localhost ([192.168.245.11]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-9908-MobileGateWay) id AAA15862; Sat, 11 Sep 1999 00:49:09 +0900 (JST) To: crawdad@fnal.gov Cc: jinmei@isl.rdc.toshiba.co.jp, tim@mentat.com, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: <199909101423.JAA01437@gungnir.fnal.gov> References: <199909101423.JAA01437@gungnir.fnal.gov> X-Mailer: Mew version 1.94b5 on XEmacs 20.4 (Emerald) X-Prom-Mew: Prom-Mew 1.93 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990911004852L.shin@nd.net.fujitsu.co.jp> Date: Sat, 11 Sep 1999 00:48:52 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990212(IM106) Lines: 84 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > #define ICMP6_RR_FLAGS_SEGNUM 0x1 > #define ICMP6_RR_FLAGS_TEST 0x2 > #define ICMP6_RR_FLAGS_REQRESULT 0x4 > #define ICMP6_RR_FLAGS_FORCEAPPLY 0x8 > #define ICMP6_RR_FLAGS_SPECSITE 0x10 > #define ICMP6_RR_FLAGS_PREVDONE 0x20 > > Either I'm confused, or these are a little mixed-up. I don't know > what the first one is, and I would expect the others to have values > 0x80, 0x40, 0x20, 0x10, 0x08 in that order. Sorry, several parts of the bit order was very confusing. I should have reviewed more before sending it. This is fixed version. struct icmp6_router_renum { /* router renumbering header */ struct icmp6_hdr rr_hdr; u_int8_t rr_segnum; u_int8_t rr_flags; u_int16_t rr_maxdelay; u_int32_t rr_reserved; }; #define ICMP6_RR_FLAGS_TEST 0x80 #define ICMP6_RR_FLAGS_REQRESULT 0x40 #define ICMP6_RR_FLAGS_FORCEAPPLY 0x20 #define ICMP6_RR_FLAGS_SPECSITE 0x10 #define ICMP6_RR_FLAGS_PREVDONE 0x08 #define rr_type rr_hdr.icmp6_type #define rr_code rr_hdr.icmp6_code #define rr_cksum rr_hdr.icmp6_cksum #define rr_seqnum rr_hdr.icmp6_data32[0] struct rr_pco_match { /* match prefix part */ u_int8_t rpm_code; u_int8_t rpm_len; u_int8_t rpm_ordinal; u_int8_t rpm_matchlen; u_int8_t rpm_minlen; u_int8_t rpm_maxlen; u_int16_t rpm_reserved; struct in6_addr rpm_prefix; }; #define RPM_PCO_ADD 1 #define RPM_PCO_CHANGE 2 #define RPM_PCO_SETGLOBAL 3 struct rr_pco_use { /* use prefix part */ u_int8_t rpu_uselen; u_int8_t rpu_keeplen; u_int8_t rpu_ramask; u_int8_t rpu_raflags; u_int32_t rpu_vltime; u_int32_t rpu_pltime; u_int32_t rpu_flags; struct in6_addr rpu_prefix; }; #define ICMP6_RR_PCOUSE_RAFLAGS_ONLINK 0x20 #define ICMP6_RR_PCOUSE_RAFLAGS_AUTO 0x10 #if BYTE_ORDER == BIG_ENDIAN #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80000000 #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40000000 #elif BYTE_ORDER == LITTLE_ENDIAN #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80 #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40 #endif struct rr_result { /* router renumbering result message */ u_int16_t rrr_flags; u_int8_t rrr_ordinal; u_int8_t rrr_matchedlen; u_int32_t rrr_ifid; struct in6_addr rrr_prefix; }; #if BYTE_ORDER == BIG_ENDIAN #define ICMP6_RR_RESULT_FLAGS_OOB 0x0002 #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0001 #elif BYTE_ORDER == LITTLE_ENDIAN #define ICMP6_RR_RESULT_FLAGS_OOB 0x02 #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x01 #endif -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 10 11:52:57 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8AISL202830 for ipng-dist; Fri, 10 Sep 1999 11:28:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8AISC002823 for ; Fri, 10 Sep 1999 11:28: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 LAA19325 for ; Fri, 10 Sep 1999 11:28:11 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01480 for ; Fri, 10 Sep 1999 11:28:09 -0700 (PDT) Received: from world.std.com (qqi@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id OAA14534 for ; Fri, 10 Sep 1999 14:28:06 -0400 (EDT) Received: from localhost (qqi@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id OAA20730 for ; Fri, 10 Sep 1999 14:28:06 -0400 (EDT) Date: Fri, 10 Sep 1999 14:28:05 -0400 (EDT) From: Quality Quorum To: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd In-Reply-To: <199909101442.KAA30163@rotala.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have simple Joe-six-pack question about renumbering. If I have IP session (TCP or UDP) and renumbering event happen on either end of the connection, then I suppose that my connection will not survive. It does not seem like a big deal if session reestablishment will be transparently handled by a protocol stack, however, it seems like it is not the case, moreover, it seems like say UPD client has no way to figure out that UDP server experienced renumbering events, am I correct about it ? Thanks, Aleksey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 06:01:45 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8BCnx403765 for ipng-dist; Sat, 11 Sep 1999 05:49:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8BCnn003758 for ; Sat, 11 Sep 1999 05:49:51 -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 FAA21969; Sat, 11 Sep 1999 05:49:48 -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 FAA03788; Sat, 11 Sep 1999 05:49:47 -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 OAA17830; Sat, 11 Sep 1999 14:49:46 +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 OAA20081; Sat, 11 Sep 1999 14:49:44 +0200 (MET DST) Message-Id: <199909111249.OAA20081@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-reply-to: Your message of Fri, 03 Sep 1999 21:32:28 +0900. <14287.49116.94774.30564X@condor.isl.rdc.toshiba.co.jp> Date: Sat, 11 Sep 1999 14:49:44 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >>>>> On Wed, 1 Sep 1999 22:22:35 -0700 (PDT), >>>>> Erik Nordmark said: >> => multicast addresses are exactly like link-local addresses even >> they have their own scope because a multicast destination without >> the outgoing interface is incomplete. > Hmm, the IPv4 code (and our IPv6 code as well) can send multicast > packets without any interface information. > If there is no IP*_MULTICAST_IF (or sin6_scope_id, or IPV6_PKTINFO with > ifindex) then the kernel will do a *unicast* route lookup for 224.0.0.0 > in the IPv4 case. This will find the "default multicast interface". > If we preserve this behavior in IPv6 we can treat the multicast scope > issues the same as the unicast scope issues. That's right, but my impression is that it was a workaround for those who didn't have enough API to specify the outgoing interface of a multicast packet. Even if we install a route for ff00::/8 to an interface, we have to specify another interface via some API after all. IMO, we should not rely on a `default route' in the kernel for sending a multicast packet. => I agree. In fact I have a ff00::/8 router per interface with multicast support then I've got another reason to remplace the old route lookup hack (which is incorrect in most of kernels because the route structure is in the stack and not fully initialized) by a "default interface" notion (as suggested by the ipi6_ifindex 0 text in the I-D)... Regards Francis.Dupont@inria.fr PS: I use a sysctl() for the "default interface". This sysctl() gives the interface index to use when sin6_scope_id and others are 0. When the "default interface" index is 0 (which should happen only with multiple interfaces) then an error is returned (this can be convenient for a router in some situations). I share the same "default interface" for multicasts and link-local unicast (because for both scope_id is an interface index). I don't know if this is the best choice? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 06:38:07 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8BDQik03804 for ipng-dist; Sat, 11 Sep 1999 06:26:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8BDQY003797 for ; Sat, 11 Sep 1999 06:26: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 GAA07088 for ; Sat, 11 Sep 1999 06:26:32 -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 HAA13922 for ; Sat, 11 Sep 1999 07:26:32 -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 PAA18499; Sat, 11 Sep 1999 15:22:43 +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 PAA11466; Sat, 11 Sep 1999 15:22:43 +0200 (MET DST) Message-Id: <199909111322.PAA11466@givry.inria.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: Draft IPng Interim Meeting Agenda In-reply-to: Your message of Sat, 04 Sep 1999 19:18:29 PDT. <3.0.5.32.19990904191829.03e4a100@mailhost.iprg.nokia.com> Date: Sat, 11 Sep 1999 15:22:42 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Thursday / 30 September 1999 ---------------------------- 09:00 - 12:00 Multihoming (continues) - Router Only Mechanisms / Itojun o RFC2260 Style for IPv6 o Multiple Prefix ISP Support => I propose to add something like "Mobility Mechanisms Reuse" here before the renumbering stuff. I'll try to get enough time to (slightly) update by I-D about this in order to republish it as an IPng document (current name is draft-ietf-ngtrans-6bone-multi-01.txt). Regards Francis.Dupont@inria.fr PS: I still recommend the two year old presentation by Matt Crawford at http://www-dcg.fnal.gov/~crawdad/mhome/index.htm named "Non-Corrosive Multihoming". -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 08:35:58 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8BFRJw03873 for ipng-dist; Sat, 11 Sep 1999 08:27:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8BFR8003862 for ; Sat, 11 Sep 1999 08: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 IAA24931 for ; Sat, 11 Sep 1999 08:27:07 -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 JAA24383 for ; Sat, 11 Sep 1999 09:27:06 -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 RAA20712; Sat, 11 Sep 1999 17:27:04 +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 RAA01039; Sat, 11 Sep 1999 17:27:04 +0200 (MET DST) Message-Id: <199909111527.RAA01039@givry.inria.fr> From: Francis Dupont To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: ipng@sunroof.eng.sun.com Subject: Re: Identifier and routing IPv6 addresses? Would Mobile-IP solve any? In-reply-to: Your message of Thu, 09 Sep 1999 10:57:31 +0300. <199909090757.KAA02336@anise.tte.vtt.fi> Date: Sat, 11 Sep 1999 17:27:03 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'm just wondering if Mobile-IP architecture would bring some solutions for this problem? => I believe your idea is: a home ISP gives (home) addresses which are more stable than current (care-of) addresses? There are some issues: - home agents must be "in" the home prefix then the problem is still the same even you can expect far better stability for the virtual home ISP. - before bindings and/or with correspondents which don't manage bindings the traffic to you will go through the home agent which is expensive (these two points show a good solution should not use home agents) - even with bindings there is an overhead then this kind of solutions should not be permanent. - I assume there are at least some organizations or entities that can have fairly permanent globally routable addresses (phone companies could run home agent service for phonenumbers mapped as IPv6 addresses, for example) => there is only one case where permanent globally routable addresses are very important: root DNS servers. Such client could then sign on with any ISP as mobile host, the ISPs dynamically allocated address would just be the care address. Assuming mobile-ip6 would be present on ipv6 stacks, and that the assigned "care address" is fairly permanent, the home agent would be needed only at connection setup. The ISP's don't need to do anything special to support this (other than allowing true end-to-end IP connections, get rid of the pesky NATs!) => your idea seems to be the virtual home ISP, isn't it? Additionally, the client could always use the care address explicitly for short term connections (like web browsing etc). => in any case bindings should be used for multihoming purposes only for long term connections because of the overhead and the need for authentication. One thing though: it should be possible to have "home agent" for a network. I'm not sure this is possible with current Mobile-ip, the documents always use examples of single host. => you can have a home agent (or a set) for each individual nodes in a network. Regards Francis.Dupont@inria.fr PS: you should read my I-D about another usage of mobility "bindings" for multi-homing in a very light way (without home agents for instance). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 08:50:40 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8BFjuG03944 for ipng-dist; Sat, 11 Sep 1999 08:45:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8BFjl003937 for ; Sat, 11 Sep 1999 08:45:47 -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 IAA04504 for ; Sat, 11 Sep 1999 08:45:46 -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 JAA26186 for ; Sat, 11 Sep 1999 09:45:45 -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 RAA21079; Sat, 11 Sep 1999 17:45:43 +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 RAA04404; Sat, 11 Sep 1999 17:45:43 +0200 (MET DST) Message-Id: <199909111545.RAA04404@givry.inria.fr> From: Francis Dupont To: Quality Quorum cc: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd In-reply-to: Your message of Fri, 10 Sep 1999 14:28:05 EDT. Date: Sat, 11 Sep 1999 17:45:42 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: If I have IP session (TCP or UDP) and renumbering event happen on either end of the connection, then I suppose that my connection will not survive. => it should be the case only when the old address becomes invalid: when a site is renumbered a new prefix is used and the old one is first deprecated, then invalided and at the end removed. You can stay in the intermediate/deprecated state for typically a month (*) then renumbering is an issue only for sessions with a lifetime longer than a renumbering period. Regards Francis.Dupont@inria.fr PS (*): a deprecated address is not used by definition for new connections then the only good reason to make it invalid (and to garbage collect very long term connections which are still using it) is because the prefix will be reused. This gives delays in months both in IPv6 specs (RFC 2461 has 7 and 30 days for AdvPreferredLifetime and AdvValidLifetime) and in regional NIC documents as ripe-196 (at least 12 months to return the sub-TLA space). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 20:13:39 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8D3AUn04743 for ipng-dist; Sun, 12 Sep 1999 20:10:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8D3AJ004736 for ; Sun, 12 Sep 1999 20:10:20 -0700 (PDT) Received: from fenris.spnusw.sun.com (halley.EBay.Sun.COM [129.150.111.35]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA10607 for ; Sun, 12 Sep 1999 20:10:18 -0700 (PDT) Received: from orpheus.amdahl.com (orpheus.amdahl.com [129.212.11.6]) by fenris.spnusw.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA20305 for ; Sun, 12 Sep 1999 20:03:31 -0700 (PDT) Received: by orpheus.amdahl.com (8.9.3/8.9.3) id UAA29926 for ipng@sunroof.eng.sun.com; Sun, 12 Sep 1999 20:10:20 -0700 (PDT) Received: from fujitsuI.fujitsu.com (fujitsuI.fujitsu.com [133.164.11.1]) by orpheus.amdahl.com (8.9.3/8.9.3) with ESMTP id UAA29917 for ; Sun, 12 Sep 1999 20:10:18 -0700 (PDT) Received: by fujitsuI.fujitsu.com (8.9.3/8.9.3) id UAA28651 for ipng@sunroof.eng.sun.com; Sun, 12 Sep 1999 20:09:45 -0700 (PDT) Received: from abroad2.proxy.fujitsu.co.jp ([133.161.11.2]) by fujitsuI.fujitsu.com (8.9.3/8.9.3) with ESMTP id UAA28643 for ; Sun, 12 Sep 1999 20:09:43 -0700 (PDT) Received: from abroad.proxy.fujitsu.co.jp by abroad2.proxy.fujitsu.co.jp (8.9.3/3.7W-9909-Abroad Gateway) id MAA06436; Mon, 13 Sep 1999 12:09:43 +0900 (JST) Received: from fdmnews.fujitsu.co.jp by abroad.proxy.fujitsu.co.jp (8.9.3/3.7W-9909-Abroad Gateway) id MAA24865; Mon, 13 Sep 1999 12:09:42 +0900 (JST) Received: from chisato.nd.net.fujitsu.co.jp by fdmnews.fujitsu.co.jp (8.9.3/3.7W-9909-Fujitsu Domain Master) id MAA29955; Mon, 13 Sep 1999 12:09:41 +0900 (JST) Received: from localhost (dhcp7186.nd.net.fujitsu.co.jp [10.18.7.186]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id MAA14168 for ; Mon, 13 Sep 1999 12:09:40 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: <19990910150956I.shin@nd.net.fujitsu.co.jp> References: <199909030702.AAA10814@feller.mentat.com> <14287.50689.861424.62646Q@condor.isl.rdc.toshiba.co.jp> <19990910150956I.shin@nd.net.fujitsu.co.jp> X-Mailer: Mew version 1.94b5 on XEmacs 20.4 (Emerald) X-Prom-Mew: Prom-Mew 1.93 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990913120919X.shin@nd.net.fujitsu.co.jp> Date: Mon, 13 Sep 1999 12:09:19 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990212(IM106) Lines: 22 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry, there is still a bug in router renum structure proposal. (Thanks for Francis Dupont for checking this.) struct rr_result { /* router renumbering result message */ u_int16_t rrr_flags; u_int8_t rrr_ordinal; u_int8_t rrr_matchedlen; u_int32_t rrr_ifid; struct in6_addr rrr_prefix; }; #if BYTE_ORDER == BIG_ENDIAN #define ICMP6_RR_RESULT_FLAGS_OOB 0x0002 #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0001 #elif BYTE_ORDER == LITTLE_ENDIAN -#define ICMP6_RR_RESULT_FLAGS_OOB 0x02 -#define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x01 +#define ICMP6_RR_RESULT_FLAGS_OOB 0x0200 +#define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0100 #endif Yoshinobu Inoue -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 20:13:47 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8D3A3S04734 for ipng-dist; Sun, 12 Sep 1999 20:10:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8D39s004727 for ; Sun, 12 Sep 1999 20:09:55 -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 UAA12668; Sun, 12 Sep 1999 20:09:52 -0700 (PDT) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA06796; Sun, 12 Sep 1999 21:09:50 -0600 (MDT) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id MAA01158; Mon, 13 Sep 1999 12:09:48 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id MAA24500; Mon, 13 Sep 1999 12:09:48 +0900 (JST) Received: from localhost (condor.isl.rdc.toshiba.co.jp [133.196.16.140]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id MAA28843; Mon, 13 Sep 1999 12:09:48 +0900 (JST) Date: Mon, 13 Sep 1999 12:12:32 +0900 Message-ID: <14300.27552.622349.74466C@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik.Nordmark@eng.sun.com Cc: Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Tue, 7 Sep 1999 14:07:26 -0700 (PDT)" References: <14287.49116.94774.30564X@condor.isl.rdc.toshiba.co.jp> User-Agent: Wanderlust/2.1.4 (Tears In Heaven) 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: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 7 Sep 1999 14:07:26 -0700 (PDT), >>>>> Erik Nordmark said: > It makes sense having the kernel pick one if neither the user nor > the application specifies one. > (Of course, the user or application might want to override this but that > doesn't change the question of where the default comes from). > IPv4 applications can use the kernel default today. > Why should we not provide the same ability for IPv6 applications? I didn't intend to get rid of `a default route for multicast'. I meant that an application should not *RELY ON* the default route, i.e. it should provide an explicit way to specify an interface(e.g. as a command line option) as well as using the kernel's default route. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Sep 12 23:23:54 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8D6KAC05008 for ipng-dist; Sun, 12 Sep 1999 23:20:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8D6K1005001 for ; Sun, 12 Sep 1999 23:20: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 XAA20108 for ; Sun, 12 Sep 1999 23:20:02 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA05649 for ; Mon, 13 Sep 1999 00:20:01 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 12 Sep 1999 23:19:36 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2448.0) id ; Sun, 12 Sep 1999 23:19:36 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515981@RED-MSG-50> From: Richard Draves To: "'Francis Dupont'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Draft IPng Interim Meeting Agenda Date: Sun, 12 Sep 1999 23:19:35 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > PS: I still recommend the two year old presentation by Matt Crawford > at http://www-dcg.fnal.gov/~crawdad/mhome/index.htm named > "Non-Corrosive > Multihoming". I just looked at this presentation. Using the terminology of the example, I don't see how HR sends packets to HL after the link breaks. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 13 01:52:50 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8D8mZH05104 for ipng-dist; Mon, 13 Sep 1999 01:48:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8D8mN005097 for ; Mon, 13 Sep 1999 01:48: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 BAA07254 for ; Mon, 13 Sep 1999 01:48:23 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA18033 for ; Mon, 13 Sep 1999 01:48:22 -0700 (PDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id LAA07950; Mon, 13 Sep 1999 11:48:15 +0300 (EET DST) Date: Mon, 13 Sep 1999 11:48:15 +0300 (EET DST) From: Markku Savela Message-Id: <199909130848.LAA07950@anise.tte.vtt.fi> To: Francis.Dupont@inria.fr CC: ipng@sunroof.eng.sun.com In-reply-to: <199909111527.RAA01039@givry.inria.fr> (message from Francis Dupont on Sat, 11 Sep 1999 17:27:03 +0200) Subject: Re: Identifier and routing IPv6 addresses? Would Mobile-IP solve any? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Francis Dupont > In your previous mail you wrote: > > I'm just wondering if Mobile-IP architecture would bring some > solutions for this problem? > > => I believe your idea is: a home ISP gives (home) addresses which > are more stable than current (care-of) addresses? Yes, in part. As an impelementor I was worried about overlapping solutions. But, from your draft-ietf-ngtrans-6bone-multi-01.txt I see that things appear to go into right direction. Seems that mobile IP can be seen as levels Level 1 (simple address change) - home address option (or Level 0) - binding requests directly between corresponging nodes Level 2 (mobility) - home agent functionality > => your idea seems to be the virtual home ISP, isn't it? I suppose, I wish every one should have a right to addressable identity on the network without any cost (you don't pay for you name now, why should one pay for network identity). "Virtual home ISP" might be one way, but who would run such things is another matter. Technical problems are minor compared to all possible privacy issues, spam or abuse of such system. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 02:50:59 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8D9lWP05191 for ipng-dist; Mon, 13 Sep 1999 02:47:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8D9lN005184 for ; Mon, 13 Sep 1999 02:47: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 CAA09493 for ; Mon, 13 Sep 1999 02:47:23 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA01361 for ; Mon, 13 Sep 1999 02:47:22 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id SAA26242 for ; Mon, 13 Sep 1999 18:47:21 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id SAA23424 for ; Mon, 13 Sep 1999 18:47:20 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id SAA26751 for ; Mon, 13 Sep 1999 18:47:20 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: Fw: interim registration/hotel reservation From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Sep_13_18:46:30_1999_179)--" Content-Transfer-Encoding: 7bit Message-Id: <19990913184640B.kazu@iijlab.net> Date: Mon, 13 Sep 1999 18:46:40 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 114 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----Next_Part(Mon_Sep_13_18:46:30_1999_179)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit As I announced, the registration web page of IPng interim meeting is now available. A routing information disappeared when I announced. This was not our fault and the trouble have been already resolved. Please register as soon as possible. I made a link to a page which contains the current participant list from the interim meeting page: http://www.wide.ad.jp/events/199909.ipng-interim/ 45 people have registered. 45 chairs are left currently. --Kazu ----Next_Part(Mon_Sep_13_18:46:30_1999_179)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Received: from mgi.iij.ad.jp (mgi.iij.ad.jp [192.168.2.5]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA20344 for ; Wed, 8 Sep 1999 12:00:46 +0900 (JST) Received: from sh1.iijlab.net (sh1.iijlab.net [202.232.15.98]) by mgi.iij.ad.jp (8.8.8/MGI2.0) with ESMTP id MAA27417 for ; Wed, 8 Sep 1999 12:00:46 +0900 (JST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by sh1.iijlab.net (8.8.8/3.7W) with ESMTP id LAA15101 for ; Wed, 8 Sep 1999 11:58:42 +0900 (JST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA06257; Tue, 7 Sep 1999 19:58:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA24775; Tue, 7 Sep 1999 19:56:21 -0700 (PDT) Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d882qON06947 for ipng-dist; Tue, 7 Sep 1999 19:52:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d882qE806940 for ; Tue, 7 Sep 1999 19:52:15 -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 TAA23254 for ; Tue, 7 Sep 1999 19:52:09 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA23046 for ; Tue, 7 Sep 1999 20:52:07 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA29993; Wed, 8 Sep 1999 11:52:06 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA19016; Wed, 8 Sep 1999 11:52:05 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA06212; Wed, 8 Sep 1999 11:52:05 +0900 (JST) To: ipng@sunroof.eng.sun.com Cc: junsec@wide.ad.jp, yumi@kame.net Subject: interim registration/hotel reservation From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.94 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: <19990908115116D.kazu@iijlab.net> Date: Wed, 08 Sep 1999 11:51:16 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-UIDL: 39ec9570d2fb39696ee0ec1b4f9debfa Folks, Sorry for the delay but I think we are ready now. Those who are planing to atenda the next interim meeting in Japan should gain accece to: http://www.wide.ad.jp/events/199909.ipng-interim/ Participants MUST register through this page. If not, you can't take a chair through the meeting. Due to the room space, the number of paticipants is limited to 90. Optionally, you can book room(s) of Mita Miyako hotel through the page. Probably some guys feel that this page is inconvenient. For example, you may want to check out on 3rd Oct. You may want to register the meeting first and book a room later. In such cases, please feel free to send email messages to Scott Macdonald, JCOM (scott@jtbcom.co.jp). Scott will help you. Currently we are not sure that the discount rate can be applied to the other days. It is important to understand that JCOM treats Mita Miyako hotel only. If you want to stay in another hotel, please book a room by yourself. Scott will NOT help you. After the interim meeting, Japanese session will be held. Some Japanese guys explain what's going on in Japan to foreigners. This is optional. Please feel free to leave at noon without attending this session. Likewise, please feel free to attend this session. I believe this is worth listing. :-) If you will get in trouble, please tell me. I have responsibility on the local arrange. See you in Japan soon. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ----Next_Part(Mon_Sep_13_18:46:30_1999_179)---- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 05:11:17 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8DC7tX05262 for ipng-dist; Mon, 13 Sep 1999 05:07:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8DC7k005255 for ; Mon, 13 Sep 1999 05:07: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 FAA14310 for ; Mon, 13 Sep 1999 05:07:46 -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 GAA16088 for ; Mon, 13 Sep 1999 06:07:43 -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 OAA00925; Mon, 13 Sep 1999 14:07:37 +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 OAA15808; Mon, 13 Sep 1999 14:07:36 +0200 (MET DST) Message-Id: <199909131207.OAA15808@givry.inria.fr> From: Francis Dupont To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: Re: Draft IPng Interim Meeting Agenda In-reply-to: Your message of Sun, 12 Sep 1999 23:19:35 PDT. <4D0A23B3F74DD111ACCD00805F31D81014515981@RED-MSG-50> Date: Mon, 13 Sep 1999 14:07:35 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > PS: I still recommend the two year old presentation by Matt Crawford > at http://www-dcg.fnal.gov/~crawdad/mhome/index.htm named > "Non-Corrosive > Multihoming". I just looked at this presentation. Using the terminology of the example, I don't see how HR sends packets to HL after the link breaks. => there are some details which have been updated since the presentation: - in slide 7 the new "B" (for Broken) flag in prefix info option has been replaced by "preferred lifetime falls to zero" condition: * no new flag / change to draft standard RFC 2461/2462 * the side effect on source selection is exactly what is needed (ie no new connection will use the "broken" prefix) - in slide 8 the mobility mechanism is not fully explained (mobile IPv6 was very new). The idea is to simulate a move with B:S:HL (used/primary but "broken" address) as the home address and with A:S:HL (new preferred "secondary" address) as the care-of address for any connection between the local host HL and a remote host HR when the connectivity between the site S and the universe via the ISP B fails. For more details I believe there is what you need in my I-D... 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 Mon Sep 13 12:11:29 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8DIrk605929 for ipng-dist; Mon, 13 Sep 1999 11:53:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8DIrZ005922 for ; Mon, 13 Sep 1999 11:53:37 -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 LAA18126 for ; Mon, 13 Sep 1999 11:53:32 -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 LAA15360 for ; Mon, 13 Sep 1999 11:53:31 -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 TAA280090; Mon, 13 Sep 1999 19:53:29 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA33272; Mon, 13 Sep 1999 19:53:21 +0100 (BST) Message-ID: <37DD4850.BAD8740C@hursley.ibm.com> Date: Mon, 13 Sep 1999 13:54:08 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Ben Black CC: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: <19990907025426.U77014@layer8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ben, I can't see anything in your arguments that suggests any realistic, deployable alternative to the current proposal, unless you can explain in concrete detail what this means: > Solutions which avoid the use of multihoming with a single address > space are possible and offer more hope for a robust network than those > currently proposed. Brian Ben Black wrote: > > I'm not familiar with the workings of the IPng group, so please let me > know if this violates any procedural or etiquette boundaries. I've > just finished reading several of the IPv6 drafts and hoped my thoughts > on one recently submitted draft might be of use. > > IPv6 multihoming is a thorny problem and I don't pretend to have a > solution. I don't know that there is one possible as the network layer. > > Ben > > -- > > The IPv6 address allocation and routing hierarchy defined in [AGGR] > and [ARCH] poses serious difficulties for implementation of multihomed > networks. Rather than the usual practice of allocating a single > prefix, or set of prefixes for multiple networks, network operators > must either home to a single provider or allocate multiple prefixes > for the same set of nodes. The draft "A Simple Solution for IPv6 > Multihoming" [SMPL] profers an approach to achieving multihomed > networks within the constraints of the IPv6 route aggregation > hierarchy. > > Unfortunately, the fundamental assumptions regarding the purposes of > multihoming lead the author of the document astray. The main goals > of multihoming are: redundancy in the face of link and/or network > failure, load balancing, and performance improvement. Of these, only > load balancing is directly addressed, and even then with limited > success. Similarly, although improving performance by connecting > directly to networks which are common destinations is effective, the > document does not provide options for accessing content providers > accessible through other networks. > > A selection of quotes from the document will help in clarifying its > shortcomings as a solution to multihoming within the existing, > documented IPv6 routing framework. > > >From section 2 (Proposal): > > ISP-3 ---- ISP-4 > | / | > | / | > | / | > ISP-1 ---- ISP-2 > link-1 \ / link-2 > Customer-A > > A multi-homed customer will designate a primary ISP and receive IP > address from its primary ISP's IPv6 aggregation block. In this > example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A > to the customer. Customer-A will advertise addr-1-A to ISP-1 and > ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to > ISP-1 only. ISP-1 will, of course, advertise its own aggregation > Addr-1 to the entire Internet. > > It is clear from this description that the only redundancy provided > with this solution is for the customer links (link-1 and link-2) and > not for the ISPs themselves. Specifically, if ISP-1 suffers from a > failure within the POP to which link-1 terminates, whether as an > isolated failure or a more extensive failure within ISP-1, then > Customer-A is no longer able to maintain connectivity despite their > possession of a perfectly good alternate path through ISP-2. From an > engineering perspective, no robustness has been gained through this > multihoming which could not be gained more simply with multiple links > to ISP-1. > > >From section 2 (Proposal): > > For inbound traffic to Customer-A, traffic will first be forwarded to > ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will > then forward the traffic destined to Customer-A via its connection to > ISP-2 and/or its direct link to customer-A, according to certain > polices. Most common policy would be the use of the shortest exit. By > using both connections to forward traffic to Customer-A, load sharing > is achieved. > > >From this statement it is unclear exactly how inbound load balancing > is to be achieved. Is the author suggesting use of the (rather > troublesome) concept of eBGP multipath? In the topology described in > the diagram above, implementation of a load sharing mechanism across > link-1 and link-2 would be a decidedly non-trivial matter. Again, > given the lack of redundancy outlined above, it would be far more > efficient for Customer-A to simply purchase multiple links to ISP-1. > > Additionally, Customer-A must now depend heavily on the connectivity > between ISP-1 and ISP-2. Often, links to multiple providers are > purchased specifically to avoid traffic crossing these (often > congested) peerings. > > >From Section 4 (Concerns): > > - The primary ISP of a multihoming customer (such as ISP-1 in the > example) would need to do more work in terms of distributing the > traffic among other connected ISPs and the customer link. This > can be done using BGP policy (BGP community) and using shortest > exit. It will also carry more traffic for the customer. However, > this is a value added service to the customer and the primary ISP > can charge more fees for such services. > > Stating that the primary ISP "would need to do more work" is putting > the problem a bit lightly. The addition of references to BGP policies > and BGP communities does little to clarify how exactly the author > believes traffic could effectively be distributed. > > >From Section 4 (Concerns): > > - The primary ISP is the sole interface for the multihomed > customer to the Internet other than the ISPs the customer has > directly connection with. Outages such as one between ISP-1 and > ISP-4 would impact the reachability from customers of ISP-4 to > Customer-A even though ISP-2 still has good connection to ISP-4. > However, if the primary ISP is a good quality ISP, this sort of > situation should happen rarely. The reason is that it's common > practice that an ISP, especially good quality ISP, has multiple > connections to other big ISPs at different geographical locations. > Good quality ISPs also have robust network design to prevent any > failure to impact the whole network. Choosing a good quality and > robust ISP as primary ISP is a good practice. > > This is really the crux of the problem with the solution put forth in > the document. The assumption that a given ISP will never have > failures, or that rare failures are acceptable to customers who > multihomed for redundancy, is simply not valid from an engineering > perspective. If the primary goal of multihoming were load sharing, > this solution would provide one, potentially very complicated, > answer. However, the issue of multihoming for redundancy is totally > ignored, drawing into question the need for a second ISP in the > equation at all. Why not simply purchase additional bandwidth from > the same ISP? > > >From Section 4 (Concerns): > > It is desirable to have solution which provides perfect redundancy > and, at the same time, simplicity to scale management and operation. > In the absence of a perfect solution, the trade-off needs to be made. > The author believes that it is very important that the solution has > to be simple and manageable. Manageability should be the top > consideration. > > If manageability of the solution is to be the top consideration, the > response put forward does not measure up. In the name of avoiding > routing table growth the author has suggested adding significant > complexity to the configuration and management of multihomed customers > without showing any benefit for the effort. > > An area not addressed at all in the document is that of multihoming > for access to networks attached to a given ISP, rather than access to > that ISP. For example, using the diagram above, if Customer-A > purchased connectivity to ISP-2 because ISP-2 had better connectivity > to ISP-4, then the offered multihoming solution is of no use. ISP-4 > will never see reachability to Customer-A via ISP-2. > > The primary lesson of the draft proposal is that the proposed, forced > aggregation hierarchy places sever restrictions upon the engineering > of reliable, high poerformance networks. To multihome effectively, a > network operator must somehow qualify as a "long-haul provider" or > other entity appropriate for allocation of its own address space. In > this author's opinion, the current IPv6 addressing architecture > creates an environment which provides scalability of the global > routing table at the expense of any real hope for redundancy through > multihoming. > > Solutions which avoid the use of multihoming with a single address > space are possible and offer more hope for a robust network than those > currently proposed. > > REFERENCES > > [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An > Aggregatable Global Unicast Address Format", RFC 2374, July > 1998. > > [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", > RFC 2373, July 1998. > > [SMPL] Yu, J., "A Simple Solution for IPv6 Multihoming", > draft-yu-simple-ipv6multihoming-00.txt, August 1999. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 13 13:36:01 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8DKRuS06110 for ipng-dist; Mon, 13 Sep 1999 13:27:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8DKRl006103 for ; Mon, 13 Sep 1999 13:27:47 -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 NAA05435 for ; Mon, 13 Sep 1999 13:27:45 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA23463 for ; Mon, 13 Sep 1999 13:27:45 -0700 (PDT) Received: (qmail 7433 invoked by uid 1001); 13 Sep 1999 20:27:41 -0000 Date: Mon, 13 Sep 1999 13:27:41 -0700 From: Ben Black To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990913132740.A6617@layer8.net> References: <19990907025426.U77014@layer8.net> <37DD4850.BAD8740C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <37DD4850.BAD8740C@hursley.ibm.com>; from Brian E Carpenter on Mon, Sep 13, 1999 at 01:54:08PM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think the only viable solution, in the face of the constraints placed on advertisement of IPv6 aggregates, is similar to that proposed in RFC2260 and further detailed for IPv6 by itojun. The "current" proposal is not viable at all, despite some minor similarities with RFC2260. Although it would be rather involved, I can see application of tunnel networks overlayed on a large scale as a solution allowing an ISP to provide backup for another ISP. I don't really think it is attractive because of the significantly higher complexity and administrative overhead compared to RFC2260 and itojun's proposal. Ben On Mon, Sep 13, 1999 at 01:54:08PM -0500, Brian E Carpenter wrote: > Ben, > > I can't see anything in your arguments that suggests any realistic, > deployable alternative to the current proposal, unless you can explain > in concrete detail what this means: > > > Solutions which avoid the use of multihoming with a single address > > space are possible and offer more hope for a robust network than those > > currently proposed. > > Brian > > Ben Black wrote: > > > > I'm not familiar with the workings of the IPng group, so please let me > > know if this violates any procedural or etiquette boundaries. I've > > just finished reading several of the IPv6 drafts and hoped my thoughts > > on one recently submitted draft might be of use. > > > > IPv6 multihoming is a thorny problem and I don't pretend to have a > > solution. I don't know that there is one possible as the network layer. > > > > Ben > > > > -- > > > > The IPv6 address allocation and routing hierarchy defined in [AGGR] > > and [ARCH] poses serious difficulties for implementation of multihomed > > networks. Rather than the usual practice of allocating a single > > prefix, or set of prefixes for multiple networks, network operators > > must either home to a single provider or allocate multiple prefixes > > for the same set of nodes. The draft "A Simple Solution for IPv6 > > Multihoming" [SMPL] profers an approach to achieving multihomed > > networks within the constraints of the IPv6 route aggregation > > hierarchy. > > > > Unfortunately, the fundamental assumptions regarding the purposes of > > multihoming lead the author of the document astray. The main goals > > of multihoming are: redundancy in the face of link and/or network > > failure, load balancing, and performance improvement. Of these, only > > load balancing is directly addressed, and even then with limited > > success. Similarly, although improving performance by connecting > > directly to networks which are common destinations is effective, the > > document does not provide options for accessing content providers > > accessible through other networks. > > > > A selection of quotes from the document will help in clarifying its > > shortcomings as a solution to multihoming within the existing, > > documented IPv6 routing framework. > > > > >From section 2 (Proposal): > > > > ISP-3 ---- ISP-4 > > | / | > > | / | > > | / | > > ISP-1 ---- ISP-2 > > link-1 \ / link-2 > > Customer-A > > > > A multi-homed customer will designate a primary ISP and receive IP > > address from its primary ISP's IPv6 aggregation block. In this > > example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A > > to the customer. Customer-A will advertise addr-1-A to ISP-1 and > > ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to > > ISP-1 only. ISP-1 will, of course, advertise its own aggregation > > Addr-1 to the entire Internet. > > > > It is clear from this description that the only redundancy provided > > with this solution is for the customer links (link-1 and link-2) and > > not for the ISPs themselves. Specifically, if ISP-1 suffers from a > > failure within the POP to which link-1 terminates, whether as an > > isolated failure or a more extensive failure within ISP-1, then > > Customer-A is no longer able to maintain connectivity despite their > > possession of a perfectly good alternate path through ISP-2. From an > > engineering perspective, no robustness has been gained through this > > multihoming which could not be gained more simply with multiple links > > to ISP-1. > > > > >From section 2 (Proposal): > > > > For inbound traffic to Customer-A, traffic will first be forwarded to > > ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will > > then forward the traffic destined to Customer-A via its connection to > > ISP-2 and/or its direct link to customer-A, according to certain > > polices. Most common policy would be the use of the shortest exit. By > > using both connections to forward traffic to Customer-A, load sharing > > is achieved. > > > > >From this statement it is unclear exactly how inbound load balancing > > is to be achieved. Is the author suggesting use of the (rather > > troublesome) concept of eBGP multipath? In the topology described in > > the diagram above, implementation of a load sharing mechanism across > > link-1 and link-2 would be a decidedly non-trivial matter. Again, > > given the lack of redundancy outlined above, it would be far more > > efficient for Customer-A to simply purchase multiple links to ISP-1. > > > > Additionally, Customer-A must now depend heavily on the connectivity > > between ISP-1 and ISP-2. Often, links to multiple providers are > > purchased specifically to avoid traffic crossing these (often > > congested) peerings. > > > > >From Section 4 (Concerns): > > > > - The primary ISP of a multihoming customer (such as ISP-1 in the > > example) would need to do more work in terms of distributing the > > traffic among other connected ISPs and the customer link. This > > can be done using BGP policy (BGP community) and using shortest > > exit. It will also carry more traffic for the customer. However, > > this is a value added service to the customer and the primary ISP > > can charge more fees for such services. > > > > Stating that the primary ISP "would need to do more work" is putting > > the problem a bit lightly. The addition of references to BGP policies > > and BGP communities does little to clarify how exactly the author > > believes traffic could effectively be distributed. > > > > >From Section 4 (Concerns): > > > > - The primary ISP is the sole interface for the multihomed > > customer to the Internet other than the ISPs the customer has > > directly connection with. Outages such as one between ISP-1 and > > ISP-4 would impact the reachability from customers of ISP-4 to > > Customer-A even though ISP-2 still has good connection to ISP-4. > > However, if the primary ISP is a good quality ISP, this sort of > > situation should happen rarely. The reason is that it's common > > practice that an ISP, especially good quality ISP, has multiple > > connections to other big ISPs at different geographical locations. > > Good quality ISPs also have robust network design to prevent any > > failure to impact the whole network. Choosing a good quality and > > robust ISP as primary ISP is a good practice. > > > > This is really the crux of the problem with the solution put forth in > > the document. The assumption that a given ISP will never have > > failures, or that rare failures are acceptable to customers who > > multihomed for redundancy, is simply not valid from an engineering > > perspective. If the primary goal of multihoming were load sharing, > > this solution would provide one, potentially very complicated, > > answer. However, the issue of multihoming for redundancy is totally > > ignored, drawing into question the need for a second ISP in the > > equation at all. Why not simply purchase additional bandwidth from > > the same ISP? > > > > >From Section 4 (Concerns): > > > > It is desirable to have solution which provides perfect redundancy > > and, at the same time, simplicity to scale management and operation. > > In the absence of a perfect solution, the trade-off needs to be made. > > The author believes that it is very important that the solution has > > to be simple and manageable. Manageability should be the top > > consideration. > > > > If manageability of the solution is to be the top consideration, the > > response put forward does not measure up. In the name of avoiding > > routing table growth the author has suggested adding significant > > complexity to the configuration and management of multihomed customers > > without showing any benefit for the effort. > > > > An area not addressed at all in the document is that of multihoming > > for access to networks attached to a given ISP, rather than access to > > that ISP. For example, using the diagram above, if Customer-A > > purchased connectivity to ISP-2 because ISP-2 had better connectivity > > to ISP-4, then the offered multihoming solution is of no use. ISP-4 > > will never see reachability to Customer-A via ISP-2. > > > > The primary lesson of the draft proposal is that the proposed, forced > > aggregation hierarchy places sever restrictions upon the engineering > > of reliable, high poerformance networks. To multihome effectively, a > > network operator must somehow qualify as a "long-haul provider" or > > other entity appropriate for allocation of its own address space. In > > this author's opinion, the current IPv6 addressing architecture > > creates an environment which provides scalability of the global > > routing table at the expense of any real hope for redundancy through > > multihoming. > > > > Solutions which avoid the use of multihoming with a single address > > space are possible and offer more hope for a robust network than those > > currently proposed. > > > > REFERENCES > > > > [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An > > Aggregatable Global Unicast Address Format", RFC 2374, July > > 1998. > > > > [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", > > RFC 2373, July 1998. > > > > [SMPL] Yu, J., "A Simple Solution for IPv6 Multihoming", > > draft-yu-simple-ipv6multihoming-00.txt, August 1999. > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 14:44:52 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8DLbYw06213 for ipng-dist; Mon, 13 Sep 1999 14:37:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8DLbP006206 for ; Mon, 13 Sep 1999 14:37: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 OAA23722 for ; Mon, 13 Sep 1999 14:37:24 -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 OAA21625 for ; Mon, 13 Sep 1999 14:37:21 -0700 (PDT) Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id QAA16317; Mon, 13 Sep 1999 16:36:58 -0500 (CDT) Received: from dal-tx11-50.ix.netcom.com(207.94.124.178) by dfw-ix15.ix.netcom.com via smap (V1.3) id rma016255; Mon Sep 13 16:36:21 1999 Message-ID: <37DCFED4.A1A6EC88@ix.netcom.com> Date: Mon, 13 Sep 1999 14:40:40 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Ben Black CC: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: <19990907025426.U77014@layer8.net> <37DD4850.BAD8740C@hursley.ibm.com> <19990913132740.A6617@layer8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ben, Brian and all, I am in agreement with Ben here. Althoughh we have had great success with our "Interface Facility" I think Ben is essentially correct here. The need for multihoming is here for awhile anyway. Ben Black wrote: > I think the only viable solution, in the face of the constraints placed > on advertisement of IPv6 aggregates, is similar to that proposed in RFC2260 > and further detailed for IPv6 by itojun. The "current" proposal is not > viable at all, despite some minor similarities with RFC2260. > > Although it would be rather involved, I can see application of tunnel > networks overlayed on a large scale as a solution allowing an ISP to > provide backup for another ISP. I don't really think it is attractive > because of the significantly higher complexity and administrative > overhead compared to RFC2260 and itojun's proposal. > > Ben > > On Mon, Sep 13, 1999 at 01:54:08PM -0500, Brian E Carpenter wrote: > > Ben, > > > > I can't see anything in your arguments that suggests any realistic, > > deployable alternative to the current proposal, unless you can explain > > in concrete detail what this means: > > > > > Solutions which avoid the use of multihoming with a single address > > > space are possible and offer more hope for a robust network than those > > > currently proposed. > > > > Brian > > > > Ben Black wrote: > > > > > > I'm not familiar with the workings of the IPng group, so please let me > > > know if this violates any procedural or etiquette boundaries. I've > > > just finished reading several of the IPv6 drafts and hoped my thoughts > > > on one recently submitted draft might be of use. > > > > > > IPv6 multihoming is a thorny problem and I don't pretend to have a > > > solution. I don't know that there is one possible as the network layer. > > > > > > Ben > > > > > > -- > > > > > > The IPv6 address allocation and routing hierarchy defined in [AGGR] > > > and [ARCH] poses serious difficulties for implementation of multihomed > > > networks. Rather than the usual practice of allocating a single > > > prefix, or set of prefixes for multiple networks, network operators > > > must either home to a single provider or allocate multiple prefixes > > > for the same set of nodes. The draft "A Simple Solution for IPv6 > > > Multihoming" [SMPL] profers an approach to achieving multihomed > > > networks within the constraints of the IPv6 route aggregation > > > hierarchy. > > > > > > Unfortunately, the fundamental assumptions regarding the purposes of > > > multihoming lead the author of the document astray. The main goals > > > of multihoming are: redundancy in the face of link and/or network > > > failure, load balancing, and performance improvement. Of these, only > > > load balancing is directly addressed, and even then with limited > > > success. Similarly, although improving performance by connecting > > > directly to networks which are common destinations is effective, the > > > document does not provide options for accessing content providers > > > accessible through other networks. > > > > > > A selection of quotes from the document will help in clarifying its > > > shortcomings as a solution to multihoming within the existing, > > > documented IPv6 routing framework. > > > > > > >From section 2 (Proposal): > > > > > > ISP-3 ---- ISP-4 > > > | / | > > > | / | > > > | / | > > > ISP-1 ---- ISP-2 > > > link-1 \ / link-2 > > > Customer-A > > > > > > A multi-homed customer will designate a primary ISP and receive IP > > > address from its primary ISP's IPv6 aggregation block. In this > > > example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A > > > to the customer. Customer-A will advertise addr-1-A to ISP-1 and > > > ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to > > > ISP-1 only. ISP-1 will, of course, advertise its own aggregation > > > Addr-1 to the entire Internet. > > > > > > It is clear from this description that the only redundancy provided > > > with this solution is for the customer links (link-1 and link-2) and > > > not for the ISPs themselves. Specifically, if ISP-1 suffers from a > > > failure within the POP to which link-1 terminates, whether as an > > > isolated failure or a more extensive failure within ISP-1, then > > > Customer-A is no longer able to maintain connectivity despite their > > > possession of a perfectly good alternate path through ISP-2. From an > > > engineering perspective, no robustness has been gained through this > > > multihoming which could not be gained more simply with multiple links > > > to ISP-1. > > > > > > >From section 2 (Proposal): > > > > > > For inbound traffic to Customer-A, traffic will first be forwarded to > > > ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will > > > then forward the traffic destined to Customer-A via its connection to > > > ISP-2 and/or its direct link to customer-A, according to certain > > > polices. Most common policy would be the use of the shortest exit. By > > > using both connections to forward traffic to Customer-A, load sharing > > > is achieved. > > > > > > >From this statement it is unclear exactly how inbound load balancing > > > is to be achieved. Is the author suggesting use of the (rather > > > troublesome) concept of eBGP multipath? In the topology described in > > > the diagram above, implementation of a load sharing mechanism across > > > link-1 and link-2 would be a decidedly non-trivial matter. Again, > > > given the lack of redundancy outlined above, it would be far more > > > efficient for Customer-A to simply purchase multiple links to ISP-1. > > > > > > Additionally, Customer-A must now depend heavily on the connectivity > > > between ISP-1 and ISP-2. Often, links to multiple providers are > > > purchased specifically to avoid traffic crossing these (often > > > congested) peerings. > > > > > > >From Section 4 (Concerns): > > > > > > - The primary ISP of a multihoming customer (such as ISP-1 in the > > > example) would need to do more work in terms of distributing the > > > traffic among other connected ISPs and the customer link. This > > > can be done using BGP policy (BGP community) and using shortest > > > exit. It will also carry more traffic for the customer. However, > > > this is a value added service to the customer and the primary ISP > > > can charge more fees for such services. > > > > > > Stating that the primary ISP "would need to do more work" is putting > > > the problem a bit lightly. The addition of references to BGP policies > > > and BGP communities does little to clarify how exactly the author > > > believes traffic could effectively be distributed. > > > > > > >From Section 4 (Concerns): > > > > > > - The primary ISP is the sole interface for the multihomed > > > customer to the Internet other than the ISPs the customer has > > > directly connection with. Outages such as one between ISP-1 and > > > ISP-4 would impact the reachability from customers of ISP-4 to > > > Customer-A even though ISP-2 still has good connection to ISP-4. > > > However, if the primary ISP is a good quality ISP, this sort of > > > situation should happen rarely. The reason is that it's common > > > practice that an ISP, especially good quality ISP, has multiple > > > connections to other big ISPs at different geographical locations. > > > Good quality ISPs also have robust network design to prevent any > > > failure to impact the whole network. Choosing a good quality and > > > robust ISP as primary ISP is a good practice. > > > > > > This is really the crux of the problem with the solution put forth in > > > the document. The assumption that a given ISP will never have > > > failures, or that rare failures are acceptable to customers who > > > multihomed for redundancy, is simply not valid from an engineering > > > perspective. If the primary goal of multihoming were load sharing, > > > this solution would provide one, potentially very complicated, > > > answer. However, the issue of multihoming for redundancy is totally > > > ignored, drawing into question the need for a second ISP in the > > > equation at all. Why not simply purchase additional bandwidth from > > > the same ISP? > > > > > > >From Section 4 (Concerns): > > > > > > It is desirable to have solution which provides perfect redundancy > > > and, at the same time, simplicity to scale management and operation. > > > In the absence of a perfect solution, the trade-off needs to be made. > > > The author believes that it is very important that the solution has > > > to be simple and manageable. Manageability should be the top > > > consideration. > > > > > > If manageability of the solution is to be the top consideration, the > > > response put forward does not measure up. In the name of avoiding > > > routing table growth the author has suggested adding significant > > > complexity to the configuration and management of multihomed customers > > > without showing any benefit for the effort. > > > > > > An area not addressed at all in the document is that of multihoming > > > for access to networks attached to a given ISP, rather than access to > > > that ISP. For example, using the diagram above, if Customer-A > > > purchased connectivity to ISP-2 because ISP-2 had better connectivity > > > to ISP-4, then the offered multihoming solution is of no use. ISP-4 > > > will never see reachability to Customer-A via ISP-2. > > > > > > The primary lesson of the draft proposal is that the proposed, forced > > > aggregation hierarchy places sever restrictions upon the engineering > > > of reliable, high poerformance networks. To multihome effectively, a > > > network operator must somehow qualify as a "long-haul provider" or > > > other entity appropriate for allocation of its own address space. In > > > this author's opinion, the current IPv6 addressing architecture > > > creates an environment which provides scalability of the global > > > routing table at the expense of any real hope for redundancy through > > > multihoming. > > > > > > Solutions which avoid the use of multihoming with a single address > > > space are possible and offer more hope for a robust network than those > > > currently proposed. > > > > > > REFERENCES > > > > > > [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An > > > Aggregatable Global Unicast Address Format", RFC 2374, July > > > 1998. > > > > > > [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", > > > RFC 2373, July 1998. > > > > > > [SMPL] Yu, J., "A Simple Solution for IPv6 Multihoming", > > > draft-yu-simple-ipv6multihoming-00.txt, August 1999. > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > -- > --b > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mon Sep 13 15:47:04 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8DMgl806297 for ipng-dist; Mon, 13 Sep 1999 15:42:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8DMgc006290 for ; Mon, 13 Sep 1999 15:42:39 -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 PAA08277 for ; Mon, 13 Sep 1999 15:42:37 -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 PAA15893 for ; Mon, 13 Sep 1999 15:42:35 -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 XAA203478; Mon, 13 Sep 1999 23:42:33 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA31518; Mon, 13 Sep 1999 23:42:30 +0100 (BST) Message-ID: <37DD7E05.4378C33A@hursley.ibm.com> Date: Mon, 13 Sep 1999 17:43:17 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Ben Black CC: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: <19990907025426.U77014@layer8.net> <37DD4850.BAD8740C@hursley.ibm.com> <19990913132740.A6617@layer8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK, there is clearly a problem with the way this has been written up. Those of us who attended the second design team meeting on this before Oslo were, I think, pretty clear that the RFC 2260 approach was a required part of the total solution (i.e. in my mind at least, the "simple solution" is by no means a complete proposal). Thanks for the clarification Brian Ben Black wrote: > > I think the only viable solution, in the face of the constraints placed > on advertisement of IPv6 aggregates, is similar to that proposed in RFC2260 > and further detailed for IPv6 by itojun. The "current" proposal is not > viable at all, despite some minor similarities with RFC2260. > > Although it would be rather involved, I can see application of tunnel > networks overlayed on a large scale as a solution allowing an ISP to > provide backup for another ISP. I don't really think it is attractive > because of the significantly higher complexity and administrative > overhead compared to RFC2260 and itojun's proposal. > > Ben > > On Mon, Sep 13, 1999 at 01:54:08PM -0500, Brian E Carpenter wrote: > > Ben, > > > > I can't see anything in your arguments that suggests any realistic, > > deployable alternative to the current proposal, unless you can explain > > in concrete detail what this means: > > > > > Solutions which avoid the use of multihoming with a single address > > > space are possible and offer more hope for a robust network than those > > > currently proposed. > > > > Brian > > > > Ben Black wrote: > > > > > > I'm not familiar with the workings of the IPng group, so please let me > > > know if this violates any procedural or etiquette boundaries. I've > > > just finished reading several of the IPv6 drafts and hoped my thoughts > > > on one recently submitted draft might be of use. > > > > > > IPv6 multihoming is a thorny problem and I don't pretend to have a > > > solution. I don't know that there is one possible as the network layer. > > > > > > Ben > > > > > > -- > > > > > > The IPv6 address allocation and routing hierarchy defined in [AGGR] > > > and [ARCH] poses serious difficulties for implementation of multihomed > > > networks. Rather than the usual practice of allocating a single > > > prefix, or set of prefixes for multiple networks, network operators > > > must either home to a single provider or allocate multiple prefixes > > > for the same set of nodes. The draft "A Simple Solution for IPv6 > > > Multihoming" [SMPL] profers an approach to achieving multihomed > > > networks within the constraints of the IPv6 route aggregation > > > hierarchy. > > > > > > Unfortunately, the fundamental assumptions regarding the purposes of > > > multihoming lead the author of the document astray. The main goals > > > of multihoming are: redundancy in the face of link and/or network > > > failure, load balancing, and performance improvement. Of these, only > > > load balancing is directly addressed, and even then with limited > > > success. Similarly, although improving performance by connecting > > > directly to networks which are common destinations is effective, the > > > document does not provide options for accessing content providers > > > accessible through other networks. > > > > > > A selection of quotes from the document will help in clarifying its > > > shortcomings as a solution to multihoming within the existing, > > > documented IPv6 routing framework. > > > > > > >From section 2 (Proposal): > > > > > > ISP-3 ---- ISP-4 > > > | / | > > > | / | > > > | / | > > > ISP-1 ---- ISP-2 > > > link-1 \ / link-2 > > > Customer-A > > > > > > A multi-homed customer will designate a primary ISP and receive IP > > > address from its primary ISP's IPv6 aggregation block. In this > > > example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A > > > to the customer. Customer-A will advertise addr-1-A to ISP-1 and > > > ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to > > > ISP-1 only. ISP-1 will, of course, advertise its own aggregation > > > Addr-1 to the entire Internet. > > > > > > It is clear from this description that the only redundancy provided > > > with this solution is for the customer links (link-1 and link-2) and > > > not for the ISPs themselves. Specifically, if ISP-1 suffers from a > > > failure within the POP to which link-1 terminates, whether as an > > > isolated failure or a more extensive failure within ISP-1, then > > > Customer-A is no longer able to maintain connectivity despite their > > > possession of a perfectly good alternate path through ISP-2. From an > > > engineering perspective, no robustness has been gained through this > > > multihoming which could not be gained more simply with multiple links > > > to ISP-1. > > > > > > >From section 2 (Proposal): > > > > > > For inbound traffic to Customer-A, traffic will first be forwarded to > > > ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will > > > then forward the traffic destined to Customer-A via its connection to > > > ISP-2 and/or its direct link to customer-A, according to certain > > > polices. Most common policy would be the use of the shortest exit. By > > > using both connections to forward traffic to Customer-A, load sharing > > > is achieved. > > > > > > >From this statement it is unclear exactly how inbound load balancing > > > is to be achieved. Is the author suggesting use of the (rather > > > troublesome) concept of eBGP multipath? In the topology described in > > > the diagram above, implementation of a load sharing mechanism across > > > link-1 and link-2 would be a decidedly non-trivial matter. Again, > > > given the lack of redundancy outlined above, it would be far more > > > efficient for Customer-A to simply purchase multiple links to ISP-1. > > > > > > Additionally, Customer-A must now depend heavily on the connectivity > > > between ISP-1 and ISP-2. Often, links to multiple providers are > > > purchased specifically to avoid traffic crossing these (often > > > congested) peerings. > > > > > > >From Section 4 (Concerns): > > > > > > - The primary ISP of a multihoming customer (such as ISP-1 in the > > > example) would need to do more work in terms of distributing the > > > traffic among other connected ISPs and the customer link. This > > > can be done using BGP policy (BGP community) and using shortest > > > exit. It will also carry more traffic for the customer. However, > > > this is a value added service to the customer and the primary ISP > > > can charge more fees for such services. > > > > > > Stating that the primary ISP "would need to do more work" is putting > > > the problem a bit lightly. The addition of references to BGP policies > > > and BGP communities does little to clarify how exactly the author > > > believes traffic could effectively be distributed. > > > > > > >From Section 4 (Concerns): > > > > > > - The primary ISP is the sole interface for the multihomed > > > customer to the Internet other than the ISPs the customer has > > > directly connection with. Outages such as one between ISP-1 and > > > ISP-4 would impact the reachability from customers of ISP-4 to > > > Customer-A even though ISP-2 still has good connection to ISP-4. > > > However, if the primary ISP is a good quality ISP, this sort of > > > situation should happen rarely. The reason is that it's common > > > practice that an ISP, especially good quality ISP, has multiple > > > connections to other big ISPs at different geographical locations. > > > Good quality ISPs also have robust network design to prevent any > > > failure to impact the whole network. Choosing a good quality and > > > robust ISP as primary ISP is a good practice. > > > > > > This is really the crux of the problem with the solution put forth in > > > the document. The assumption that a given ISP will never have > > > failures, or that rare failures are acceptable to customers who > > > multihomed for redundancy, is simply not valid from an engineering > > > perspective. If the primary goal of multihoming were load sharing, > > > this solution would provide one, potentially very complicated, > > > answer. However, the issue of multihoming for redundancy is totally > > > ignored, drawing into question the need for a second ISP in the > > > equation at all. Why not simply purchase additional bandwidth from > > > the same ISP? > > > > > > >From Section 4 (Concerns): > > > > > > It is desirable to have solution which provides perfect redundancy > > > and, at the same time, simplicity to scale management and operation. > > > In the absence of a perfect solution, the trade-off needs to be made. > > > The author believes that it is very important that the solution has > > > to be simple and manageable. Manageability should be the top > > > consideration. > > > > > > If manageability of the solution is to be the top consideration, the > > > response put forward does not measure up. In the name of avoiding > > > routing table growth the author has suggested adding significant > > > complexity to the configuration and management of multihomed customers > > > without showing any benefit for the effort. > > > > > > An area not addressed at all in the document is that of multihoming > > > for access to networks attached to a given ISP, rather than access to > > > that ISP. For example, using the diagram above, if Customer-A > > > purchased connectivity to ISP-2 because ISP-2 had better connectivity > > > to ISP-4, then the offered multihoming solution is of no use. ISP-4 > > > will never see reachability to Customer-A via ISP-2. > > > > > > The primary lesson of the draft proposal is that the proposed, forced > > > aggregation hierarchy places sever restrictions upon the engineering > > > of reliable, high poerformance networks. To multihome effectively, a > > > network operator must somehow qualify as a "long-haul provider" or > > > other entity appropriate for allocation of its own address space. In > > > this author's opinion, the current IPv6 addressing architecture > > > creates an environment which provides scalability of the global > > > routing table at the expense of any real hope for redundancy through > > > multihoming. > > > > > > Solutions which avoid the use of multihoming with a single address > > > space are possible and offer more hope for a robust network than those > > > currently proposed. > > > > > > REFERENCES > > > > > > [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An > > > Aggregatable Global Unicast Address Format", RFC 2374, July > > > 1998. > > > > > > [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", > > > RFC 2373, July 1998. > > > > > > [SMPL] Yu, J., "A Simple Solution for IPv6 Multihoming", > > > draft-yu-simple-ipv6multihoming-00.txt, August 1999. > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > -- > --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 17:28:00 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8E0O2R06405 for ipng-dist; Mon, 13 Sep 1999 17:24:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8E0Nr006398 for ; Mon, 13 Sep 1999 17:23:53 -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 RAA22906 for ; Mon, 13 Sep 1999 17:23:52 -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 SAA28934 for ; Mon, 13 Sep 1999 18:23:50 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA04983; Tue, 14 Sep 1999 10:23:26 +1000 (EST) Date: Tue, 14 Sep 1999 10:23:26 +1000 (EST) From: Peter Tattam To: Ben Black cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <19990913132740.A6617@layer8.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I know I have said this over and over, but I am very concerned that the Ipv6 team may be painting themselves into a corner over this issue. None of the proposed solutions to Ipv6 multihoming sit easy with me. The issue is primarily a conceptual one based on the assumption that aggregation and CIDR are the best way to deal with the size & complexity of the internet. I know there have been many hand waving solutions put forth and they have all been generally discounted by the notion that "the devil is in the details". What I believe we are facing here is a crisis in the design of the Internet similar to that faced by hardware designers of computers back in the '70s. Around that time, there were many innovations like paged virtual memory, and filing systems that being progressed from fixed file size allocation to dynamic sized allocation and so forth. Those innovations were often brought out either through serious academic research or by private research within companies that had sufficient clout in the industry to forge a direction. I wish some computer scientists would add their weight to this problem, because I believe the answer may lay there. Let us not ignore the lessons that history has shown us. Some of us in key industry positions recognize that there is a problem and while accusations have been made that certain prominent ones have been stalling Ipv6, it may well not be without cause. For me personally, I believe the answer lies in considering the default free zone as a cloud and using alternative routing techniques like route labelling to propagate data, thus allowing *all* addresses to be relatively portable. It is regretable that a lot of work has gone into dynamic renumbering of sites, but the reality may be that not too many people outside the Ipv6 scene will want the facility of rapid site renumbering. Peter On Mon, 13 Sep 1999, Ben Black wrote: > I think the only viable solution, in the face of the constraints placed > on advertisement of IPv6 aggregates, is similar to that proposed in RFC2260 > and further detailed for IPv6 by itojun. The "current" proposal is not > viable at all, despite some minor similarities with RFC2260. > > Although it would be rather involved, I can see application of tunnel > networks overlayed on a large scale as a solution allowing an ISP to > provide backup for another ISP. I don't really think it is attractive > because of the significantly higher complexity and administrative > overhead compared to RFC2260 and itojun's proposal. > > > Ben > > -- 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 Mon Sep 13 17:34:18 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8E0WSp06441 for ipng-dist; Mon, 13 Sep 1999 17:32:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8E0WJ006434 for ; Mon, 13 Sep 1999 17:32:20 -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 RAA06439; Mon, 13 Sep 1999 17:32:18 -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 RAA23807; Mon, 13 Sep 1999 17:32:18 -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 RAA00703; Mon, 13 Sep 1999 17:31:41 -0700 (PDT) Message-Id: <3.0.5.32.19990913172956.03e1a5d0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 13 Sep 1999 17:29:56 -0700 To: narten@raleigh.ibm.com, nordmark@eng.sun.com From: Bob Hinden Subject: Request to Advance "Preferred Format for Literal IPv6 Addresses in URL's" Cc: scoya@ietf.org, 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 : 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 A working group last call for this document was completed on August 3, 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 Tue Sep 14 05:48:48 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8ECjJL06810 for ipng-dist; Tue, 14 Sep 1999 05:45:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8ECjA006803 for ; Tue, 14 Sep 1999 05:45:10 -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 FAA03886 for ; Tue, 14 Sep 1999 05:45:09 -0700 (PDT) Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA22823 for ; Tue, 14 Sep 1999 06:45:08 -0600 (MDT) Received: from newton.ebina.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id VAA07507; Tue, 14 Sep 1999 21:45:07 +0900 (JST) Received: from ppp ([172.16.110.11]) by newton.ebina.hitachi.co.jp (8.9.0/3.7W-EBINA) with SMTP id VAA13754; Tue, 14 Sep 1999 21:45:06 +0900 (JST) Message-Id: <199909141245.VAA13754@newton.ebina.hitachi.co.jp> X-Sender: tsuchi@gpc.ebina.hitachi.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Tue, 14 Sep 1999 21:47:19 +0900 To: ipng@sunroof.eng.sun.com From: Kazuaki Tsuchiya Subject: Toolnet6 installation workshop Cc: imv@kame.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng folks, I hope you (especially folks who plan to attend IETF IPng Interim Meeting in Tokyo) have interest in the following information. I look forward to your participation. Thanks. -- Kazuaki Tsuchiya. --------------------------------------------------------------- Toolnet6 installation workshop at the Sasakawa Hall in Tokyo Sept. 28, 1999 We are happy to announce that we get a chance to hold Toolnet6 installation workshop for persons who attend IETF IPng Interim Meeting, thanks to the WIDE project. It is a transition tool based on the "Bump-in-the-stack (BIS)" draft argued at ngtrans-wg. As you know, there will be no IPv4 reachability to outside during the meeting. IPv6-only network is provided. Then Toolnet6 allows your Windows PC to communicate with IPv6 hosts using existing IPv4 applications. How about trying IPv6 from your Windows PC using it on this opportunity? We look forward to your participation. SCHEDULE: Tuesday, September 28 15:00 -17:00 Toolnet6 installation workshop PLACE: At the same place as IETF IPng Interim Meeting. The Sasakawa Hall, 12-12, Mita, 3-chome, Minato-ku, Tokyo, 108-0073, Japan Tel : (03) 3454-5062 Fax : (03) 3454-5544 REQUIREMENTS: It is required that you bring your Windows PC with the following environment in order to use Toolnet6. OS: Windows98, Windows95, WindowsNT4.0 NIC: 3Com Corp. EtherLink III (3C589C, 3C589D, 3CCE589ET, 3CXE589ET,...) NE2000 Compatible Adapter (D-Link Systems Inc. DE660T/J Ethernet Adapter, ...) -------------------------------------------------------------- For that matter, we recommend that you bring PC with Windows98 + EtherLink III. -------------------------------------------------------------- We are planning to pre-distribute a new version which supports address-autoconfiguration function, only to participants. It enables to set up Toolnet6 much easily, but it can run only on the environment, Windows98 + EtherLink3 now. FEES: Free of charge. REGISTRATION: Please send the registration form to the following e-mail address by Monday, September 27, 1999: mailto:tsuchi@ebina.hitachi.co.jp --------------- Registration form --------------- Name : E-mail: ------------------------------------------------- DRINKS: On your own. (Any drinks will not be provided to participants by us.) * All times are in JAPAN Time. -------------------------------------------------------- Kazuaki Tsuchiya (mailto:tsuchi@ebina.hitachi.co.jp) Hitachi,Ltd. Enterprise Server Division Phone: +81-46-235-8268(Dial-in) Fax: +81-46-235-8324 <> http://www.v6.hitachi.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 Sep 14 06:35:04 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8EDROb06900 for ipng-dist; Tue, 14 Sep 1999 06:27:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8EDRG006893 for ; Tue, 14 Sep 1999 06:27:16 -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 GAA16388 for ; Tue, 14 Sep 1999 06:27:15 -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 HAA05111 for ; Tue, 14 Sep 1999 07:27: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 OAA256084; Tue, 14 Sep 1999 14:27:11 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA30280; Tue, 14 Sep 1999 14:27:10 +0100 (BST) Message-ID: <37DE4D5E.FEF2014D@hursley.ibm.com> Date: Tue, 14 Sep 1999 08:27:58 -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@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, I submit that you are asking for magic. The reason we need aggregatable addresses is that we simply don't know any other routing system that scales to a few billion nodes and to backbone trunks at WDM speeds for packet-switched networks. > For me personally, I believe the answer lies in considering the default free > zone as a cloud and using alternative routing techniques like route labelling > to propagate data, thus allowing *all* addresses to be relatively portable. This certainly sounds like magic to me. 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 Sep 14 08:09:30 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8EF5gp07019 for ipng-dist; Tue, 14 Sep 1999 08:05:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8EF5S007012 for ; Tue, 14 Sep 1999 08:05: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 IAA18741 for ; Tue, 14 Sep 1999 08:05:27 -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 JAA17026 for ; Tue, 14 Sep 1999 09:05:22 -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 LAA23279; Tue, 14 Sep 1999 11:05:19 -0400 (EDT) Message-Id: <199909141505.LAA23279@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 14 Sep 1999 11:05:19 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider Preferred Format for Literal IPv6 Addresses in URL's as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by September 28, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-url-literal-02.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 14 08:15:11 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8EFDWk07074 for ipng-dist; Tue, 14 Sep 1999 08:13:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8EFDN007067 for ; Tue, 14 Sep 1999 08:13:23 -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 IAA15421 for ; Tue, 14 Sep 1999 08:13:23 -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 JAA20218 for ; Tue, 14 Sep 1999 09:13:21 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id BAA04675; Wed, 15 Sep 1999 01:13:12 +1000 (EST) Date: Wed, 15 Sep 1999 01:13:12 +1000 (EST) From: Peter Tattam To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <37DE4D5E.FEF2014D@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 Tue, 14 Sep 1999, Brian E Carpenter wrote: > Peter, > > I submit that you are asking for magic. > > The reason we need aggregatable addresses is that we simply don't > know any other routing system that scales to a few billion nodes > and to backbone trunks at WDM speeds for packet-switched networks. > > > For me personally, I believe the answer lies in considering the default free > > zone as a cloud and using alternative routing techniques like route labelling > > to propagate data, thus allowing *all* addresses to be relatively portable. I made a slight error. I should have said all sites, but you get the idea. > > This certainly sounds like magic to me. > I could quote a well known science fiction writer's comment on magic... > Brian > Curiously, the concepts being raised have not necessarily originated by myself. Other's have come to vaguely similar conclusions independently. When scientifc breakthroughs occur, they often spontaneously occur in independent camps. While I don't predict a breakthrough in the immediate future, the possibility of some new technique or algorithm being born that could manage such a cloud *may* still eventuate. It might seem like magic to us at this point in time, but then, I have seen so many revolutions in computer science over the past 20 years that I could not even have imagined. One small example of this would be the latest techniques in audio compression using adaptive psycho acoustic modelling which enables compression of CD quality audio to 128Kbps. This would have been unimaginable say 10(?) years ago. Even the possibility of digital audio recording onto hard disk systems on a home system was unimaginable 20 years ago due to the sheer cost of doing it. You will have to pardon me, I am not a conventional thinker. I dare to dream and try to be a visionary. I may be living in fantasy land, but when my intuition grabs hold of something it is often hard to let go. I will continue to cogitate on the problem to see where it leads. I certainly may not have the solution yet, but I sense I could be heading in the right direction. I might be bold enough to add that I am also a spiritual person, and that I have relied on divine inspiration on many occasions during my working life. There have been many occasions where I have been totally stumped for days, even weeks in resolving extremely stubborn and elusive bugs in some of the real time operating systems that I have built. A quiet prayer has often resulted in major breakthroughs in such situations which when I reflect upon later make me realize that there was *no* way possible to resolve that bug on purely analytical grounds, or using my own intellect. I now treat such activity as normal, and even essential for me to achieve the desired quality of my software & have learned to trust that inspiration when it is needed. Perhaps this is one of those times. That others share the restlessness over the current issue indicates that there may indeed be a higher intelligence prompting the issue. I will leave you with a quote which I am not sure where was derived from. The quote was on the wall of the electronics workshop at my previous employment, the University of Tasmania, Psychology department. "The impossible we do at once, miracles take a little longer" That was the climate which was expected of me as the norm in my formative years as a computer programmer. 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 Sep 14 08:27:48 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8EFO9I07116 for ipng-dist; Tue, 14 Sep 1999 08:24:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8EFO1007109 for ; Tue, 14 Sep 1999 08:24:01 -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 IAA27989 for ; Tue, 14 Sep 1999 08:23:54 -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 JAA24256 for ; Tue, 14 Sep 1999 09:23:53 -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 RAA08915; Tue, 14 Sep 1999 17:23:46 +0200 (MET DST) Message-Id: <4.2.0.58.19990914171604.00b2f990@brahma.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 14 Sep 1999 17:19:57 +0200 To: Kazuaki Tsuchiya , ipng@sunroof.eng.sun.com From: Alain Durand Subject: Re: Toolnet6 installation workshop Cc: imv@kame.net In-Reply-To: <199909141245.VAA13754@newton.ebina.hitachi.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 21:47 14/09/99 +0900, Kazuaki Tsuchiya wrote: >I >REQUIREMENTS: > It is required that you bring your Windows PC with the > following environment in order to use Toolnet6. > > OS: Windows98, Windows95, WindowsNT4.0 > NIC: 3Com Corp. EtherLink III > (3C589C, 3C589D, 3CCE589ET, 3CXE589ET,...) > NE2000 Compatible Adapter > (D-Link Systems Inc. DE660T/J Ethernet Adapter, ...) This is very nice, unfortunately I do not use 3com nor NE2000 adapter, I use a COM1 platinium pcmcia card. I suppose others may be in a similar situation... Could you have several pcmcia card that you support to loan us for the duration of the meeting? - 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 Tue Sep 14 09:15:11 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8EGBPZ07221 for ipng-dist; Tue, 14 Sep 1999 09:11:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8EGBF007214 for ; Tue, 14 Sep 1999 09:11:15 -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 JAA24432 for ; Tue, 14 Sep 1999 09:11:11 -0700 (PDT) Received: from iscone.res.sprintlink.net (gate2.sprintlink.net [199.0.233.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23158 for ; Tue, 14 Sep 1999 09:11:10 -0700 (PDT) Received: from localhost (rrockell@localhost) by iscone.res.sprintlink.net (8.7.3/8.6.12) with SMTP id MAA17470; Tue, 14 Sep 1999 12:10:56 -0400 (EDT) X-Authentication-Warning: iscone.res.sprintlink.net: rrockell owned process doing -bs Date: Tue, 14 Sep 1999 12:10:56 -0400 (EDT) From: "Robert J. Rockell" X-Sender: rrockell@iscone To: Brian E Carpenter cc: Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to the response regarding "A Simple Solution for IPv6 Multihoming" In-Reply-To: <37DD7E05.4378C33A@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 I'll be the first to admit that the "simple solution" is one that has some policy to work out, but I want to point out that it does add to the otehr proposed solutions. RFC2260 has two management holes that may be big from the operatioal standpoint of a TLA> 1. When a route gets injected from a downstream due to their other provider's link going down, how does the provider(s) who accept the non-aggregate know when the other provider gets the line back up? This one is important, as the control of aggregation is removed from the people who need to DO the aggregating, the core. 2. How can we implement in such a way that we KNOW that the downstream will "play nice", and act per 2260? Backbone providers will need to have some way to ensure that the downstream is only doing this during an outage. We know that this is sometimes not the case today, with other issues (otherwise we woudl all do AS filtering for EBGP...; it is easier after all). #3 while RFC2260, section 5.2 attempts to look at this, I think there will be some major design limitations asscociated. (details excluded). The "simple solution" proposal minimizes the management woes of #1 and #2. It at least sets expectations that a backbone designer can work with, and attempt to implement in a way that is scalable. Although there are management problems with the "simple solution" as well, I think it deserves some sort of trial, perhaps on the 6bone. The possibility of an efficient community-tagging policy is one way that the simple solution can work, and still provide some scalability (though not as much as we all would like, perhaps). Now the problem, with the "simple solution" instead of #1 and #2 above, becomes: -how do we know that the other provider is only announcing this route back to us, and not to everyone, breaking aggregation? I would argue that this is less to worry about than above, in that I would put more trust into the BGP policy of a backbone provider than a downstream to aggregate and export the correct routes at the right locations. The problem, however, still remains; management of one's own TLA; it just shifts a bit. In regards to Ben's comments, I would argue that load-balancing is not addressed, but the redundancy is. If the subnet (to use a soon-to-be-outdated-term) of the TLA is announced back to the TLA, redundancy is there with the "simple solution", but the load-balancing becomes problematic. One can no longer use AS padding, for instance, for multi-homing load-balancing. The redundancy is there; the routing just gets messy. If a t-1 goes down, then the packets will go to the other provider, albeit via the primary provider, so long as a peering between the two exists (which in itself is a whole other issue). However, if the whole backbone goes down, then the redundancy would be removed (but if a whole backbone goes down today, we all feel it, regardless of where we home; remember the various "internet drains" that occured over the last couple of years; I won't mention AS numbers). As I haven't seen any implementations of 2260 working, and this one actually is something that can be set up, I would like to test this. If anyone who has 6bone transit woudl be interested in testing, I say we give it a whirl, and see how it scales in the small picture, before we cast it away for the big picture totally. I apologize in advance if these opinions are redundant, or I missed something here, but I am afraid we may be throwing somethign aside which may at the very least provide more insight into how to tackle this most difficult and important problem of the protocol. Also, in regards to how this can be done ( deploy the "simple solution"; I don't know if this is the right place, but I believe it is possible, even with limited implementations of IPv6 that we have, to make this work, if we ignore some scaling problems that aren't there yet on the 6bone). Thanks Rob Rockell Sprintlink Internet Service Center Operations Engineering 703-689-6322 1-800-724-3329, PIN 385-8833 Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne? On Mon, 13 Sep 1999, Brian E Carpenter wrote: ->OK, there is clearly a problem with the way this has been ->written up. Those of us who attended the second design team meeting ->on this before Oslo were, I think, pretty clear that the RFC 2260 ->approach was a required part of the total solution (i.e. in my ->mind at least, the "simple solution" is by no means a ->complete proposal). -> ->Thanks for the clarification -> -> Brian -> ->Ben Black wrote: ->> ->> I think the only viable solution, in the face of the constraints placed ->> on advertisement of IPv6 aggregates, is similar to that proposed in RFC2260 ->> and further detailed for IPv6 by itojun. The "current" proposal is not ->> viable at all, despite some minor similarities with RFC2260. ->> ->> Although it would be rather involved, I can see application of tunnel ->> networks overlayed on a large scale as a solution allowing an ISP to ->> provide backup for another ISP. I don't really think it is attractive ->> because of the significantly higher complexity and administrative ->> overhead compared to RFC2260 and itojun's proposal. ->> ->> Ben ->> ->> On Mon, Sep 13, 1999 at 01:54:08PM -0500, Brian E Carpenter wrote: ->> > Ben, ->> > ->> > I can't see anything in your arguments that suggests any realistic, ->> > deployable alternative to the current proposal, unless you can explain ->> > in concrete detail what this means: ->> > ->> > > Solutions which avoid the use of multihoming with a single address ->> > > space are possible and offer more hope for a robust network than those ->> > > currently proposed. ->> > ->> > Brian ->> > ->> > Ben Black wrote: ->> > > ->> > > I'm not familiar with the workings of the IPng group, so please let me ->> > > know if this violates any procedural or etiquette boundaries. I've ->> > > just finished reading several of the IPv6 drafts and hoped my thoughts ->> > > on one recently submitted draft might be of use. ->> > > ->> > > IPv6 multihoming is a thorny problem and I don't pretend to have a ->> > > solution. I don't know that there is one possible as the network layer. ->> > > ->> > > Ben ->> > > ->> > > -- ->> > > ->> > > The IPv6 address allocation and routing hierarchy defined in [AGGR] ->> > > and [ARCH] poses serious difficulties for implementation of multihomed ->> > > networks. Rather than the usual practice of allocating a single ->> > > prefix, or set of prefixes for multiple networks, network operators ->> > > must either home to a single provider or allocate multiple prefixes ->> > > for the same set of nodes. The draft "A Simple Solution for IPv6 ->> > > Multihoming" [SMPL] profers an approach to achieving multihomed ->> > > networks within the constraints of the IPv6 route aggregation ->> > > hierarchy. ->> > > ->> > > Unfortunately, the fundamental assumptions regarding the purposes of ->> > > multihoming lead the author of the document astray. The main goals ->> > > of multihoming are: redundancy in the face of link and/or network ->> > > failure, load balancing, and performance improvement. Of these, only ->> > > load balancing is directly addressed, and even then with limited ->> > > success. Similarly, although improving performance by connecting ->> > > directly to networks which are common destinations is effective, the ->> > > document does not provide options for accessing content providers ->> > > accessible through other networks. ->> > > ->> > > A selection of quotes from the document will help in clarifying its ->> > > shortcomings as a solution to multihoming within the existing, ->> > > documented IPv6 routing framework. ->> > > ->> > > >From section 2 (Proposal): ->> > > ->> > > ISP-3 ---- ISP-4 ->> > > | / | ->> > > | / | ->> > > | / | ->> > > ISP-1 ---- ISP-2 ->> > > link-1 \ / link-2 ->> > > Customer-A ->> > > ->> > > A multi-homed customer will designate a primary ISP and receive IP ->> > > address from its primary ISP's IPv6 aggregation block. In this ->> > > example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A ->> > > to the customer. Customer-A will advertise addr-1-A to ISP-1 and ->> > > ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to ->> > > ISP-1 only. ISP-1 will, of course, advertise its own aggregation ->> > > Addr-1 to the entire Internet. ->> > > ->> > > It is clear from this description that the only redundancy provided ->> > > with this solution is for the customer links (link-1 and link-2) and ->> > > not for the ISPs themselves. Specifically, if ISP-1 suffers from a ->> > > failure within the POP to which link-1 terminates, whether as an ->> > > isolated failure or a more extensive failure within ISP-1, then ->> > > Customer-A is no longer able to maintain connectivity despite their ->> > > possession of a perfectly good alternate path through ISP-2. From an ->> > > engineering perspective, no robustness has been gained through this ->> > > multihoming which could not be gained more simply with multiple links ->> > > to ISP-1. ->> > > ->> > > >From section 2 (Proposal): ->> > > ->> > > For inbound traffic to Customer-A, traffic will first be forwarded to ->> > > ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will ->> > > then forward the traffic destined to Customer-A via its connection to ->> > > ISP-2 and/or its direct link to customer-A, according to certain ->> > > polices. Most common policy would be the use of the shortest exit. By ->> > > using both connections to forward traffic to Customer-A, load sharing ->> > > is achieved. ->> > > ->> > > >From this statement it is unclear exactly how inbound load balancing ->> > > is to be achieved. Is the author suggesting use of the (rather ->> > > troublesome) concept of eBGP multipath? In the topology described in ->> > > the diagram above, implementation of a load sharing mechanism across ->> > > link-1 and link-2 would be a decidedly non-trivial matter. Again, ->> > > given the lack of redundancy outlined above, it would be far more ->> > > efficient for Customer-A to simply purchase multiple links to ISP-1. ->> > > ->> > > Additionally, Customer-A must now depend heavily on the connectivity ->> > > between ISP-1 and ISP-2. Often, links to multiple providers are ->> > > purchased specifically to avoid traffic crossing these (often ->> > > congested) peerings. ->> > > ->> > > >From Section 4 (Concerns): ->> > > ->> > > - The primary ISP of a multihoming customer (such as ISP-1 in the ->> > > example) would need to do more work in terms of distributing the ->> > > traffic among other connected ISPs and the customer link. This ->> > > can be done using BGP policy (BGP community) and using shortest ->> > > exit. It will also carry more traffic for the customer. However, ->> > > this is a value added service to the customer and the primary ISP ->> > > can charge more fees for such services. ->> > > ->> > > Stating that the primary ISP "would need to do more work" is putting ->> > > the problem a bit lightly. The addition of references to BGP policies ->> > > and BGP communities does little to clarify how exactly the author ->> > > believes traffic could effectively be distributed. ->> > > ->> > > >From Section 4 (Concerns): ->> > > ->> > > - The primary ISP is the sole interface for the multihomed ->> > > customer to the Internet other than the ISPs the customer has ->> > > directly connection with. Outages such as one between ISP-1 and ->> > > ISP-4 would impact the reachability from customers of ISP-4 to ->> > > Customer-A even though ISP-2 still has good connection to ISP-4. ->> > > However, if the primary ISP is a good quality ISP, this sort of ->> > > situation should happen rarely. The reason is that it's common ->> > > practice that an ISP, especially good quality ISP, has multiple ->> > > connections to other big ISPs at different geographical locations. ->> > > Good quality ISPs also have robust network design to prevent any ->> > > failure to impact the whole network. Choosing a good quality and ->> > > robust ISP as primary ISP is a good practice. ->> > > ->> > > This is really the crux of the problem with the solution put forth in ->> > > the document. The assumption that a given ISP will never have ->> > > failures, or that rare failures are acceptable to customers who ->> > > multihomed for redundancy, is simply not valid from an engineering ->> > > perspective. If the primary goal of multihoming were load sharing, ->> > > this solution would provide one, potentially very complicated, ->> > > answer. However, the issue of multihoming for redundancy is totally ->> > > ignored, drawing into question the need for a second ISP in the ->> > > equation at all. Why not simply purchase additional bandwidth from ->> > > the same ISP? ->> > > ->> > > >From Section 4 (Concerns): ->> > > ->> > > It is desirable to have solution which provides perfect redundancy ->> > > and, at the same time, simplicity to scale management and operation. ->> > > In the absence of a perfect solution, the trade-off needs to be made. ->> > > The author believes that it is very important that the solution has ->> > > to be simple and manageable. Manageability should be the top ->> > > consideration. ->> > > ->> > > If manageability of the solution is to be the top consideration, the ->> > > response put forward does not measure up. In the name of avoiding ->> > > routing table growth the author has suggested adding significant ->> > > complexity to the configuration and management of multihomed customers ->> > > without showing any benefit for the effort. ->> > > ->> > > An area not addressed at all in the document is that of multihoming ->> > > for access to networks attached to a given ISP, rather than access to ->> > > that ISP. For example, using the diagram above, if Customer-A ->> > > purchased connectivity to ISP-2 because ISP-2 had better connectivity ->> > > to ISP-4, then the offered multihoming solution is of no use. ISP-4 ->> > > will never see reachability to Customer-A via ISP-2. ->> > > ->> > > The primary lesson of the draft proposal is that the proposed, forced ->> > > aggregation hierarchy places sever restrictions upon the engineering ->> > > of reliable, high poerformance networks. To multihome effectively, a ->> > > network operator must somehow qualify as a "long-haul provider" or ->> > > other entity appropriate for allocation of its own address space. In ->> > > this author's opinion, the current IPv6 addressing architecture ->> > > creates an environment which provides scalability of the global ->> > > routing table at the expense of any real hope for redundancy through ->> > > multihoming. ->> > > ->> > > Solutions which avoid the use of multihoming with a single address ->> > > space are possible and offer more hope for a robust network than those ->> > > currently proposed. ->> > > ->> > > REFERENCES ->> > > ->> > > [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An ->> > > Aggregatable Global Unicast Address Format", RFC 2374, July ->> > > 1998. ->> > > ->> > > [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", ->> > > RFC 2373, July 1998. ->> > > ->> > > [SMPL] Yu, J., "A Simple Solution for IPv6 Multihoming", ->> > > draft-yu-simple-ipv6multihoming-00.txt, August 1999. ->> > > ->> > > -------------------------------------------------------------------- ->> > > IETF IPng Working Group Mailing List ->> > > IPng Home Page: http://playground.sun.com/ipng ->> > > FTP archive: ftp://playground.sun.com/pub/ipng ->> > > Direct all administrative requests to majordomo@sunroof.eng.sun.com ->> > > -------------------------------------------------------------------- ->> ->> -- ->> --b ->-------------------------------------------------------------------- ->IETF IPng Working Group Mailing List ->IPng Home 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 Sep 14 09:33:26 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8EGTUQ07257 for ipng-dist; Tue, 14 Sep 1999 09:29:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8EGTL007250 for ; Tue, 14 Sep 1999 09:29: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 JAA10284 for ; Tue, 14 Sep 1999 09:29:20 -0700 (PDT) Received: from happy.cow.org (happy.cow.org [198.88.20.7]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00913 for ; Tue, 14 Sep 1999 09:29:20 -0700 (PDT) Received: from localhost (brad@localhost) by happy.cow.org (8.9.3/8.9.3) with ESMTP id MAA15376; Tue, 14 Sep 1999 12:28:00 -0400 (EDT) (envelope-from brad@qual.net) X-Authentication-Warning: happy.cow.org: brad owned process doing -bs Date: Tue, 14 Sep 1999 12:28:00 -0400 (EDT) From: Bradley Reynolds X-Sender: brad@happy.cow.org To: Brian E Carpenter cc: Peter Tattam , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <37DE4D5E.FEF2014D@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 > The reason we need aggregatable addresses is that we simply don't > know any other routing system that scales to a few billion nodes > and to backbone trunks at WDM speeds for packet-switched networks. > the function of address aggregation is independent of this imposed aggregation hierarchy. simply take away the brain damaged aggregation mandates and allow service providers to aggregate their address space as deemed appropriate. until the multihoming problem is fixed, i don't understand further progress in the ipv6 wg. BR -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 09:35:27 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8EGXqU07275 for ipng-dist; Tue, 14 Sep 1999 09:33:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8EGXe007268 for ; Tue, 14 Sep 1999 09:33:42 -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 JAA28434 for ; Tue, 14 Sep 1999 09:33:36 -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 KAA25124 for ; Tue, 14 Sep 1999 10:33:34 -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 BAA17893; Wed, 15 Sep 1999 01:32:43 +0900 (JST) To: "Robert J. Rockell" cc: Brian E Carpenter , Ben Black , ipng@sunroof.eng.sun.com In-reply-to: rrockell's message of Tue, 14 Sep 1999 12:10:56 -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: a response to the response regarding "A Simple Solution for IPv6 Multihoming" From: itojun@iijlab.net Date: Wed, 15 Sep 1999 01:32:43 +0900 Message-ID: <17891.937326763@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >RFC2260 has two management holes that may be big from the operatioal >standpoint of a TLA> RFC2260 comes with two proposal, section 5.1 and 5.2. Your points (1 and 2) are about section 5.1 of RFC2260. I believe this is not very suitable to IPv6. My draft (draft-itojun-ipv6-2260-00) tries to understand section 5.2 of RFC2260, in context of IPv6. Please take a look and give me comments so that we can talk about it better in Tokyo interim meeting. 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 Sep 14 10:30:01 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8EHPcg07460 for ipng-dist; Tue, 14 Sep 1999 10:25:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8EHPM007444 for ; Tue, 14 Sep 1999 10:25:23 -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 KAA21389 for ; Tue, 14 Sep 1999 10:25:21 -0700 (PDT) Received: from happy.cow.org (happy.cow.org [198.88.20.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19587 for ; Tue, 14 Sep 1999 11:25:21 -0600 (MDT) Received: from localhost (brad@localhost) by happy.cow.org (8.9.3/8.9.3) with ESMTP id NAA16220; Tue, 14 Sep 1999 13:23:48 -0400 (EDT) (envelope-from brad@qual.net) X-Authentication-Warning: happy.cow.org: brad owned process doing -bs Date: Tue, 14 Sep 1999 13:23:48 -0400 (EDT) From: Bradley Reynolds X-Sender: brad@happy.cow.org To: "Robert J. Rockell" cc: Brian E Carpenter , Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to the response regarding "A Simple Solution for IPv6 Multihoming" 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 > In regards to Ben's comments, I would argue that load-balancing is not > addressed, but the redundancy is. try again you want to advertise a prefix through diverse administrative domains so that issues in one administrative domain will not affect your reachability. this 'simple solution' is no solution for said redundancy issue. it is not even a hack or a kludge (both of those seem to fix the problem, even if they are ugly) there are two seperate issues in your post. 1. possible deficiencies in 2260 2. something related to the yu id. possible deficiencies in 1 do not make 2 any more acceptable. BR -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 11:48:34 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8EIiC207824 for ipng-dist; Tue, 14 Sep 1999 11:44:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8EIi3007817 for ; Tue, 14 Sep 1999 11:44: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 LAA09629 for ; Tue, 14 Sep 1999 11:44:01 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA02005 for ; Tue, 14 Sep 1999 11:44:01 -0700 (PDT) Received: (qmail 12516 invoked by uid 1001); 14 Sep 1999 18:43:56 -0000 Date: Tue, 14 Sep 1999 11:43:56 -0700 From: Ben Black To: "Robert J. Rockell" Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: a response to the response regarding "A Simple Solution for IPv6 Multihoming" Message-ID: <19990914114356.H6617@layer8.net> References: <37DD7E05.4378C33A@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Robert J. Rockell on Tue, Sep 14, 1999 at 12:10:56PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just to set our terms up front: The "simple solution" is Jessica Yu's draft. The "complex solution" RFC2260/itojun proposal. Since I don't believe Yu's draft actually solves any problems, I don't really agree with these definitions, but they will allow less confusion about which draft I mean below. On Tue, Sep 14, 1999 at 12:10:56PM -0400, Robert J. Rockell wrote: > I'll be the first to admit that the "simple solution" is one that has some > policy to work out, but I want to point out that it does add to the otehr > proposed solutions. > > RFC2260 has two management holes that may be big from the operatioal > standpoint of a TLA> > [ points 1 and 2 deleted because they are not relevant to the complex solution] > > #3 while RFC2260, section 5.2 attempts to look at this, I think there will be > some major design limitations asscociated. (details excluded). > Unfortunately, it is just those excluded details which are relevant here. > The "simple solution" proposal minimizes the management woes of #1 and #2. > It at least sets expectations that a backbone designer can work with, and > attempt to implement in a way that is scalable. Although there are > management problems with the "simple solution" as well, I think it deserves > some sort of trial, perhaps on the 6bone. > > The possibility of an efficient community-tagging policy is one way that the > simple solution can work, and still provide some scalability (though not as > much as we all would like, perhaps). > > Now the problem, with the "simple solution" instead of #1 and #2 above, becomes: > > -how do we know that the other provider is only announcing this route back > to us, and not to everyone, breaking aggregation? > The other problem becomes: - why am I paying for this second link when I can't send traffic over it if my primary ISP fails? > I would argue that this is less to worry about than above, in that I would > put more trust into the BGP policy of a backbone provider than a downstream > to aggregate and export the correct routes at the right locations. The > problem, however, still remains; management of one's own TLA; > it just shifts a bit. > > > In regards to Ben's comments, I would argue that load-balancing is not > addressed, but the redundancy is. If the subnet (to use a > soon-to-be-outdated-term) of the TLA is announced back to the TLA, > redundancy is there with the "simple solution", but the load-balancing > becomes problematic. One can no longer use AS padding, for instance, for > multi-homing load-balancing. The redundancy is there; the routing just gets > messy. If a t-1 goes down, then the packets will go to the other provider, > albeit via the primary provider, so long as a peering between the two exists > (which in itself is a whole other issue). > However, if the whole backbone goes down, then the redundancy would be > removed (but if a whole backbone goes down today, we all feel it, regardless > of where we home; remember the various "internet drains" that occured over > the last couple of years; I won't mention AS numbers). > > As I haven't seen any implementations of 2260 working, and this one actually > is something that can be set up, I would like to test this. If anyone who > has 6bone transit woudl be interested in testing, I say we give it a whirl, > and see how it scales in the small picture, before we cast it away for the > big picture totally. > > I apologize in advance if these opinions are redundant, or I missed > something here, but I am afraid we may be throwing somethign aside which may > at the very least provide more insight into how to tackle this most > difficult and important problem of the protocol. > A key point you may have missed from the simple solution: "A multi-homed customer will designate a primary ISP and receive IP address from its primary ISP's IPv6 aggregation block." What this means is that, since the *single* prefix used by the customer can only be advertised by the *primary* ISP into the global backbone, if that ISP has a failure (AS0, sun spots, fiber cut, whatever), the customer is completely unreachable, even though they have a viable, alternate path through their secondary ISP. If only they had address space from that ISP. Which they do in the complex solution. This doesn't even begin to address the problem of homing to more than 2 providers. > Also, in regards to how this can be done ( deploy the "simple solution"; I > don't know if this is the right place, but I believe it is possible, even > with limited implementations of IPv6 that we have, to make this work, if we > ignore some scaling problems that aren't there yet on the 6bone). > Sure, you could deploy it, but realize the simple solution is 50% of the complex solution. Add a second prefix and a second tunnel and it is magically upgraded to a system which actually *can* survive the failure of an upstream. Ben > On Mon, 13 Sep 1999, Brian E Carpenter wrote: > > ->OK, there is clearly a problem with the way this has been > ->written up. Those of us who attended the second design team meeting > ->on this before Oslo were, I think, pretty clear that the RFC 2260 > ->approach was a required part of the total solution (i.e. in my > ->mind at least, the "simple solution" is by no means a > ->complete proposal). > -> > ->Thanks for the clarification > -> > -> Brian > -> > ->Ben Black wrote: > ->> > ->> I think the only viable solution, in the face of the constraints placed > ->> on advertisement of IPv6 aggregates, is similar to that proposed in RFC2260 > ->> and further detailed for IPv6 by itojun. The "current" proposal is not > ->> viable at all, despite some minor similarities with RFC2260. > ->> > ->> Although it would be rather involved, I can see application of tunnel > ->> networks overlayed on a large scale as a solution allowing an ISP to > ->> provide backup for another ISP. I don't really think it is attractive > ->> because of the significantly higher complexity and administrative > ->> overhead compared to RFC2260 and itojun's proposal. > ->> > ->> Ben > ->> > ->> On Mon, Sep 13, 1999 at 01:54:08PM -0500, Brian E Carpenter wrote: > ->> > Ben, > ->> > > ->> > I can't see anything in your arguments that suggests any realistic, > ->> > deployable alternative to the current proposal, unless you can explain > ->> > in concrete detail what this means: > ->> > > ->> > > Solutions which avoid the use of multihoming with a single address > ->> > > space are possible and offer more hope for a robust network than those > ->> > > currently proposed. > ->> > > ->> > Brian > ->> > > ->> > Ben Black wrote: > ->> > > > ->> > > I'm not familiar with the workings of the IPng group, so please let me > ->> > > know if this violates any procedural or etiquette boundaries. I've > ->> > > just finished reading several of the IPv6 drafts and hoped my thoughts > ->> > > on one recently submitted draft might be of use. > ->> > > > ->> > > IPv6 multihoming is a thorny problem and I don't pretend to have a > ->> > > solution. I don't know that there is one possible as the network layer. > ->> > > > ->> > > Ben > ->> > > > ->> > > -- > ->> > > > ->> > > The IPv6 address allocation and routing hierarchy defined in [AGGR] > ->> > > and [ARCH] poses serious difficulties for implementation of multihomed > ->> > > networks. Rather than the usual practice of allocating a single > ->> > > prefix, or set of prefixes for multiple networks, network operators > ->> > > must either home to a single provider or allocate multiple prefixes > ->> > > for the same set of nodes. The draft "A Simple Solution for IPv6 > ->> > > Multihoming" [SMPL] profers an approach to achieving multihomed > ->> > > networks within the constraints of the IPv6 route aggregation > ->> > > hierarchy. > ->> > > > ->> > > Unfortunately, the fundamental assumptions regarding the purposes of > ->> > > multihoming lead the author of the document astray. The main goals > ->> > > of multihoming are: redundancy in the face of link and/or network > ->> > > failure, load balancing, and performance improvement. Of these, only > ->> > > load balancing is directly addressed, and even then with limited > ->> > > success. Similarly, although improving performance by connecting > ->> > > directly to networks which are common destinations is effective, the > ->> > > document does not provide options for accessing content providers > ->> > > accessible through other networks. > ->> > > > ->> > > A selection of quotes from the document will help in clarifying its > ->> > > shortcomings as a solution to multihoming within the existing, > ->> > > documented IPv6 routing framework. > ->> > > > ->> > > >From section 2 (Proposal): > ->> > > > ->> > > ISP-3 ---- ISP-4 > ->> > > | / | > ->> > > | / | > ->> > > | / | > ->> > > ISP-1 ---- ISP-2 > ->> > > link-1 \ / link-2 > ->> > > Customer-A > ->> > > > ->> > > A multi-homed customer will designate a primary ISP and receive IP > ->> > > address from its primary ISP's IPv6 aggregation block. In this > ->> > > example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A > ->> > > to the customer. Customer-A will advertise addr-1-A to ISP-1 and > ->> > > ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to > ->> > > ISP-1 only. ISP-1 will, of course, advertise its own aggregation > ->> > > Addr-1 to the entire Internet. > ->> > > > ->> > > It is clear from this description that the only redundancy provided > ->> > > with this solution is for the customer links (link-1 and link-2) and > ->> > > not for the ISPs themselves. Specifically, if ISP-1 suffers from a > ->> > > failure within the POP to which link-1 terminates, whether as an > ->> > > isolated failure or a more extensive failure within ISP-1, then > ->> > > Customer-A is no longer able to maintain connectivity despite their > ->> > > possession of a perfectly good alternate path through ISP-2. From an > ->> > > engineering perspective, no robustness has been gained through this > ->> > > multihoming which could not be gained more simply with multiple links > ->> > > to ISP-1. > ->> > > > ->> > > >From section 2 (Proposal): > ->> > > > ->> > > For inbound traffic to Customer-A, traffic will first be forwarded to > ->> > > ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will > ->> > > then forward the traffic destined to Customer-A via its connection to > ->> > > ISP-2 and/or its direct link to customer-A, according to certain > ->> > > polices. Most common policy would be the use of the shortest exit. By > ->> > > using both connections to forward traffic to Customer-A, load sharing > ->> > > is achieved. > ->> > > > ->> > > >From this statement it is unclear exactly how inbound load balancing > ->> > > is to be achieved. Is the author suggesting use of the (rather > ->> > > troublesome) concept of eBGP multipath? In the topology described in > ->> > > the diagram above, implementation of a load sharing mechanism across > ->> > > link-1 and link-2 would be a decidedly non-trivial matter. Again, > ->> > > given the lack of redundancy outlined above, it would be far more > ->> > > efficient for Customer-A to simply purchase multiple links to ISP-1. > ->> > > > ->> > > Additionally, Customer-A must now depend heavily on the connectivity > ->> > > between ISP-1 and ISP-2. Often, links to multiple providers are > ->> > > purchased specifically to avoid traffic crossing these (often > ->> > > congested) peerings. > ->> > > > ->> > > >From Section 4 (Concerns): > ->> > > > ->> > > - The primary ISP of a multihoming customer (such as ISP-1 in the > ->> > > example) would need to do more work in terms of distributing the > ->> > > traffic among other connected ISPs and the customer link. This > ->> > > can be done using BGP policy (BGP community) and using shortest > ->> > > exit. It will also carry more traffic for the customer. However, > ->> > > this is a value added service to the customer and the primary ISP > ->> > > can charge more fees for such services. > ->> > > > ->> > > Stating that the primary ISP "would need to do more work" is putting > ->> > > the problem a bit lightly. The addition of references to BGP policies > ->> > > and BGP communities does little to clarify how exactly the author > ->> > > believes traffic could effectively be distributed. > ->> > > > ->> > > >From Section 4 (Concerns): > ->> > > > ->> > > - The primary ISP is the sole interface for the multihomed > ->> > > customer to the Internet other than the ISPs the customer has > ->> > > directly connection with. Outages such as one between ISP-1 and > ->> > > ISP-4 would impact the reachability from customers of ISP-4 to > ->> > > Customer-A even though ISP-2 still has good connection to ISP-4. > ->> > > However, if the primary ISP is a good quality ISP, this sort of > ->> > > situation should happen rarely. The reason is that it's common > ->> > > practice that an ISP, especially good quality ISP, has multiple > ->> > > connections to other big ISPs at different geographical locations. > ->> > > Good quality ISPs also have robust network design to prevent any > ->> > > failure to impact the whole network. Choosing a good quality and > ->> > > robust ISP as primary ISP is a good practice. > ->> > > > ->> > > This is really the crux of the problem with the solution put forth in > ->> > > the document. The assumption that a given ISP will never have > ->> > > failures, or that rare failures are acceptable to customers who > ->> > > multihomed for redundancy, is simply not valid from an engineering > ->> > > perspective. If the primary goal of multihoming were load sharing, > ->> > > this solution would provide one, potentially very complicated, > ->> > > answer. However, the issue of multihoming for redundancy is totally > ->> > > ignored, drawing into question the need for a second ISP in the > ->> > > equation at all. Why not simply purchase additional bandwidth from > ->> > > the same ISP? > ->> > > > ->> > > >From Section 4 (Concerns): > ->> > > > ->> > > It is desirable to have solution which provides perfect redundancy > ->> > > and, at the same time, simplicity to scale management and operation. > ->> > > In the absence of a perfect solution, the trade-off needs to be made. > ->> > > The author believes that it is very important that the solution has > ->> > > to be simple and manageable. Manageability should be the top > ->> > > consideration. > ->> > > > ->> > > If manageability of the solution is to be the top consideration, the > ->> > > response put forward does not measure up. In the name of avoiding > ->> > > routing table growth the author has suggested adding significant > ->> > > complexity to the configuration and management of multihomed customers > ->> > > without showing any benefit for the effort. > ->> > > > ->> > > An area not addressed at all in the document is that of multihoming > ->> > > for access to networks attached to a given ISP, rather than access to > ->> > > that ISP. For example, using the diagram above, if Customer-A > ->> > > purchased connectivity to ISP-2 because ISP-2 had better connectivity > ->> > > to ISP-4, then the offered multihoming solution is of no use. ISP-4 > ->> > > will never see reachability to Customer-A via ISP-2. > ->> > > > ->> > > The primary lesson of the draft proposal is that the proposed, forced > ->> > > aggregation hierarchy places sever restrictions upon the engineering > ->> > > of reliable, high poerformance networks. To multihome effectively, a > ->> > > network operator must somehow qualify as a "long-haul provider" or > ->> > > other entity appropriate for allocation of its own address space. In > ->> > > this author's opinion, the current IPv6 addressing architecture > ->> > > creates an environment which provides scalability of the global > ->> > > routing table at the expense of any real hope for redundancy through > ->> > > multihoming. > ->> > > > ->> > > Solutions which avoid the use of multihoming with a single address > ->> > > space are possible and offer more hope for a robust network than those > ->> > > currently proposed. > ->> > > > ->> > > REFERENCES > ->> > > > ->> > > [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An > ->> > > Aggregatable Global Unicast Address Format", RFC 2374, July > ->> > > 1998. > ->> > > > ->> > > [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", > ->> > > RFC 2373, July 1998. > ->> > > > ->> > > [SMPL] Yu, J., "A Simple Solution for IPv6 Multihoming", > ->> > > draft-yu-simple-ipv6multihoming-00.txt, August 1999. > ->> > > > ->> > > -------------------------------------------------------------------- > ->> > > IETF IPng Working Group Mailing List > ->> > > IPng Home Page: http://playground.sun.com/ipng > ->> > > FTP archive: ftp://playground.sun.com/pub/ipng > ->> > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ->> > > -------------------------------------------------------------------- > ->> > ->> -- > ->> --b > ->-------------------------------------------------------------------- > ->IETF IPng Working Group Mailing List > ->IPng Home Page: http://playground.sun.com/ipng > ->FTP archive: ftp://playground.sun.com/pub/ipng > ->Direct all administrative requests to majordomo@sunroof.eng.sun.com > ->-------------------------------------------------------------------- > -> -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 14:47:45 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8ELiiD08110 for ipng-dist; Tue, 14 Sep 1999 14:44:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8ELiY008103 for ; Tue, 14 Sep 1999 14:44:34 -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 OAA14368 for ; Tue, 14 Sep 1999 14:44: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 OAA14888 for ; Tue, 14 Sep 1999 14:44:32 -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 WAA178738; Tue, 14 Sep 1999 22:44:29 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA23544; Tue, 14 Sep 1999 22:44:23 +0100 (BST) Message-ID: <37DEC1E5.CDD8978B@hursley.ibm.com> Date: Tue, 14 Sep 1999 16:45:09 -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@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, Sure, if someone makes a breakthrough that will be great. I haven't seen it yet though, and people have been looking for many years. Brian Peter Tattam wrote: > > On Tue, 14 Sep 1999, Brian E Carpenter wrote: > > > Peter, > > > > I submit that you are asking for magic. > > > > The reason we need aggregatable addresses is that we simply don't > > know any other routing system that scales to a few billion nodes > > and to backbone trunks at WDM speeds for packet-switched networks. > > > > > For me personally, I believe the answer lies in considering the default free > > > zone as a cloud and using alternative routing techniques like route labelling > > > to propagate data, thus allowing *all* addresses to be relatively portable. > > I made a slight error. I should have said all sites, but you get the idea. > > > > > This certainly sounds like magic to me. > > > > I could quote a well known science fiction writer's comment on magic... > > > Brian > > > > Curiously, the concepts being raised have not necessarily originated by myself. > Other's have come to vaguely similar conclusions independently. When scientifc > breakthroughs occur, they often spontaneously occur in independent camps. > > While I don't predict a breakthrough in the immediate future, the possibility > of some new technique or algorithm being born that could manage such a cloud > *may* still eventuate. It might seem like magic to us at this point in time, > but then, I have seen so many revolutions in computer science over the past 20 > years that I could not even have imagined. One small example of this would be > the latest techniques in audio compression using adaptive psycho acoustic > modelling which enables compression of CD quality audio to 128Kbps. This would > have been unimaginable say 10(?) years ago. Even the possibility of digital > audio recording onto hard disk systems on a home system was unimaginable 20 > years ago due to the sheer cost of doing it. > > You will have to pardon me, I am not a conventional thinker. I dare to dream > and try to be a visionary. I may be living in fantasy land, but when my > intuition grabs hold of something it is often hard to let go. I will continue > to cogitate on the problem to see where it leads. I certainly may not have the > solution yet, but I sense I could be heading in the right direction. > > I might be bold enough to add that I am also a spiritual person, and that I > have relied on divine inspiration on many occasions during my working life. > There have been many occasions where I have been totally stumped for days, even > weeks in resolving extremely stubborn and elusive bugs in some of the real time > operating systems that I have built. A quiet prayer has often resulted in > major breakthroughs in such situations which when I reflect upon later make me > realize that there was *no* way possible to resolve that bug on purely > analytical grounds, or using my own intellect. I now treat such activity as > normal, and even essential for me to achieve the desired quality of my software > & have learned to trust that inspiration when it is needed. Perhaps this is one > of those times. That others share the restlessness over the current issue > indicates that there may indeed be a higher intelligence prompting the issue. > > I will leave you with a quote which I am not sure where was derived from. > The quote was on the wall of the electronics workshop at my previous > employment, the University of Tasmania, Psychology department. > > "The impossible we do at once, miracles take a little longer" > > That was the climate which was expected of me as the norm in my formative years > as a computer programmer. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 14:47:55 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8ELgRH08101 for ipng-dist; Tue, 14 Sep 1999 14:42:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8ELgI008094 for ; Tue, 14 Sep 1999 14:42:18 -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 OAA15936 for ; Tue, 14 Sep 1999 14:42: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 PAA09241 for ; Tue, 14 Sep 1999 15:42:16 -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 WAA261400; Tue, 14 Sep 1999 22:42:12 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA32202; Tue, 14 Sep 1999 22:42:05 +0100 (BST) Message-ID: <37DEC155.B5BE20A4@hursley.ibm.com> Date: Tue, 14 Sep 1999 16:42:45 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Bradley Reynolds CC: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bradley Reynolds wrote: > > > The reason we need aggregatable addresses is that we simply don't > > know any other routing system that scales to a few billion nodes > > and to backbone trunks at WDM speeds for packet-switched networks. > > > the function of address aggregation is independent of this imposed > aggregation hierarchy. simply take away the brain damaged aggregation > mandates and allow service providers to aggregate their address space > as deemed appropriate. Can you please explain this? Where is the document that describes how aggregation is done without aggregatable addresses? 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 Sep 14 15:21:51 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8EMHK508187 for ipng-dist; Tue, 14 Sep 1999 15:17:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8EMHB008180 for ; Tue, 14 Sep 1999 15:17:11 -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 PAA21247 for ; Tue, 14 Sep 1999 15:17:10 -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 PAA26902 for ; Tue, 14 Sep 1999 15:17:09 -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 PAA14291; Tue, 14 Sep 1999 15:16:16 -0700 (PDT) Message-Id: <3.0.5.32.19990914151430.00aaa9d0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 14 Sep 1999 15:14:30 -0700 To: Peter Tattam From: Bob Hinden Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <37DEC1E5.CDD8978B@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 04:45 PM 9/14/99 -0500, Brian E Carpenter wrote: >Peter, > >Sure, if someone makes a breakthrough that will be great. I haven't >seen it yet though, and people have been looking for many years. I would add that if a breakthrough happens we should be able to use it to route the IPv6 aggregatable addresses and then start assigning addresses under some new scheme. We should not hold up the current work waiting for a breakthrough. I hope a breakthrough does happen. Route aggregation has lots of problems (we can make a long list), but it is the only thing we have available today that we are reasonably confident has the needed scaling properties. 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 Tue Sep 14 16:14:13 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8EN9mt08342 for ipng-dist; Tue, 14 Sep 1999 16:09:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8EN9d008335 for ; Tue, 14 Sep 1999 16:09:39 -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 QAA22005 for ; Tue, 14 Sep 1999 16:09:37 -0700 (PDT) Received: from happy.cow.org (happy.cow.org [198.88.20.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA12369 for ; Tue, 14 Sep 1999 17:09:37 -0600 (MDT) Received: from localhost (brad@localhost) by happy.cow.org (8.9.3/8.9.3) with ESMTP id TAA33965; Tue, 14 Sep 1999 19:08:30 -0400 (EDT) (envelope-from brad@qual.net) X-Authentication-Warning: happy.cow.org: brad owned process doing -bs Date: Tue, 14 Sep 1999 19:08:30 -0400 (EDT) From: Bradley Reynolds X-Sender: brad@happy.cow.org To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <37DEC155.B5BE20A4@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 > > the function of address aggregation is independent of this imposed > > aggregation hierarchy. simply take away the brain damaged aggregation > > mandates and allow service providers to aggregate their address space > > as deemed appropriate. > > Can you please explain this? Where is the document that describes > how aggregation is done without aggregatable addresses? > > Brian > hmm.. core bgp tables are growing linearly and i haven't seen a document describing an IPv4 aggregation hierarchy. how can that be? BR -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 16:29:55 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8ENPgM08380 for ipng-dist; Tue, 14 Sep 1999 16:25:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8ENPU008373 for ; Tue, 14 Sep 1999 16:25:30 -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 QAA05589 for ; Tue, 14 Sep 1999 16:25:29 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21249 for ; Tue, 14 Sep 1999 16:25:28 -0700 (PDT) Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by mail-green.research.att.com (Postfix) with ESMTP id 9F4461E00E; Tue, 14 Sep 1999 19:25:27 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id TAA21285; Tue, 14 Sep 1999 19:25:24 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id C37C641F16; Tue, 14 Sep 1999 19:25:26 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id B4702400B4; Tue, 14 Sep 1999 19:25:21 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Bradley Reynolds Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Sep 1999 19:25:21 -0400 Message-Id: <19990914232526.C37C641F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Bradley Rey nolds writes: > > > the function of address aggregation is independent of this imposed > > > aggregation hierarchy. simply take away the brain damaged aggregation > > > mandates and allow service providers to aggregate their address space > > > as deemed appropriate. > > > > Can you please explain this? Where is the document that describes > > how aggregation is done without aggregatable addresses? > > > > Brian > > > hmm.. core bgp tables are growing linearly and i haven't seen > a document describing an IPv4 aggregation hierarchy. how can that be? It's called CIDR -- see RFC 1517-1519. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 17:14:40 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8F0AA908568 for ipng-dist; Tue, 14 Sep 1999 17:10:10 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8F0A1008561 for ; Tue, 14 Sep 1999 17:10:02 -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 RAA09258 for ; Tue, 14 Sep 1999 17:10:00 -0700 (PDT) Received: from happy.cow.org (happy.cow.org [198.88.20.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA00522 for ; Tue, 14 Sep 1999 18:09:59 -0600 (MDT) Received: from localhost (brad@localhost) by happy.cow.org (8.9.3/8.9.3) with ESMTP id UAA34403; Tue, 14 Sep 1999 20:08:54 -0400 (EDT) (envelope-from brad@qual.net) X-Authentication-Warning: happy.cow.org: brad owned process doing -bs Date: Tue, 14 Sep 1999 20:08:54 -0400 (EDT) From: Bradley Reynolds X-Sender: brad@happy.cow.org To: "Steven M. Bellovin" cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <19990914232526.C37C641F16@SIGABA.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Can you please explain this? Where is the document that describes > > > how aggregation is done without aggregatable addresses? > > > > > > Brian > > > > > hmm.. core bgp tables are growing linearly and i haven't seen > > a document describing an IPv4 aggregation hierarchy. how can that be? > > It's called CIDR -- see RFC 1517-1519. > > --Steve Bellovin > that is not analogous in the least to the hierarchy imposed in the ipv6 addressing architecture. cidr only specifies more possible subdivisions of the addressing space which permits you to aggregate in more flexible fashion. it does not mandate an aggregation hierarchy in the least. please point me to the document that shows me where the registry id and provider id are in the ipv4 address and i will withdraw my comments. BR -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 17:31:10 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8F0Qsx08595 for ipng-dist; Tue, 14 Sep 1999 17:26:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8F0Qh008588 for ; Tue, 14 Sep 1999 17:26:43 -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 RAA16859 for ; Tue, 14 Sep 1999 17:26:40 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA11155 for ; Tue, 14 Sep 1999 17:26:40 -0700 (PDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id D132D4CE16; Tue, 14 Sep 1999 20:26:35 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id UAA01522; Tue, 14 Sep 1999 20:26:12 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id 5BC3541F16; Tue, 14 Sep 1999 20:26:33 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id 4CC82400B4; Tue, 14 Sep 1999 20:26:28 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Bradley Reynolds Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Sep 1999 20:26:24 -0400 Message-Id: <19990915002633.5BC3541F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Bradley Rey nolds writes: > > > that is not analogous in the least to the hierarchy imposed in the ipv6 > addressing architecture. cidr only specifies more possible subdivisions > of the addressing space which permits you to aggregate in more flexible > fashion. it does not mandate an aggregation hierarchy in the least. See RFC 1466. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 17:33:38 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8F0Vnv08619 for ipng-dist; Tue, 14 Sep 1999 17:31:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8F0Ve008612 for ; Tue, 14 Sep 1999 17:31:40 -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 RAA15016 for ; Tue, 14 Sep 1999 17:31:38 -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 SAA05817 for ; Tue, 14 Sep 1999 18:31:38 -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 RAA25955; Tue, 14 Sep 1999 17:30:57 -0700 (PDT) Message-Id: <3.0.5.32.19990914172912.00a74610@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 14 Sep 1999 17:29:12 -0700 To: Bradley Reynolds From: Bob Hinden Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: "Steven M. Bellovin" , Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: References: <19990914232526.C37C641F16@SIGABA.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk BR, >please point me to the document that shows me where the registry id and >provider id are in the ipv4 address and i will withdraw my comments. > There are no "registry id" and "provider id" fields in IPv6 addresses. RFC2374 "An Ipv6 Aggregatable Global Unicast Address Format" replaced RFC2073 (that contained these fields). Regards, 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 Tue Sep 14 17:43:38 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8F0bdZ08641 for ipng-dist; Tue, 14 Sep 1999 17:37:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8F0bU008634 for ; Tue, 14 Sep 1999 17:37: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 RAA15889 for ; Tue, 14 Sep 1999 17:37:28 -0700 (PDT) Received: from happy.cow.org (happy.cow.org [198.88.20.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA07399 for ; Tue, 14 Sep 1999 18:37:28 -0600 (MDT) Received: from localhost (brad@localhost) by happy.cow.org (8.9.3/8.9.3) with ESMTP id UAA34684; Tue, 14 Sep 1999 20:36:25 -0400 (EDT) (envelope-from brad@qual.net) X-Authentication-Warning: happy.cow.org: brad owned process doing -bs Date: Tue, 14 Sep 1999 20:36:24 -0400 (EDT) From: Bradley Reynolds X-Sender: brad@happy.cow.org To: "Steven M. Bellovin" cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <19990915002633.5BC3541F16@SIGABA.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > that is not analogous in the least to the hierarchy imposed in the ipv6 > > addressing architecture. cidr only specifies more possible subdivisions > > of the addressing space which permits you to aggregate in more flexible > > fashion. it does not mandate an aggregation hierarchy in the least. > > See RFC 1466. > rfc1466 has to do with cidr? it mandates an allocation hierarchy, not an aggregation hierarchy. aggregation can be done in conformance to the allocation hierarchy, but is not necessary. people are still free to announce whatever specificity they want. BR -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 17:48:31 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8F0krK08663 for ipng-dist; Tue, 14 Sep 1999 17:46:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8F0ki008656 for ; Tue, 14 Sep 1999 17:46:44 -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 RAA14736 for ; Tue, 14 Sep 1999 17:46:44 -0700 (PDT) Received: from happy.cow.org (happy.cow.org [198.88.20.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA09770 for ; Tue, 14 Sep 1999 18:46:43 -0600 (MDT) Received: from localhost (brad@localhost) by happy.cow.org (8.9.3/8.9.3) with ESMTP id UAA34792; Tue, 14 Sep 1999 20:45:23 -0400 (EDT) (envelope-from brad@qual.net) X-Authentication-Warning: happy.cow.org: brad owned process doing -bs Date: Tue, 14 Sep 1999 20:45:23 -0400 (EDT) From: Bradley Reynolds X-Sender: brad@happy.cow.org To: Bob Hinden cc: "Steven M. Bellovin" , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <3.0.5.32.19990914172912.00a74610@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There are no "registry id" and "provider id" fields in IPv6 addresses. > the terms are not so important (though of course mine were a bit dated :). what is important is that there is hierarchy imposed here which allows for simple aggregation. this hierarchy has a benefit: good aggregation this hierarchy has a drawback: how do i multihome? my question is to whether the current IPv4 scheme of letting the providers choose how to aggregate their prefixes is broken and needs to be fixed by this hierarchy. it is important to understand that the cost of this hierachy is that it has eliminated multihoming as known to ipv4 people today. (and we have no solution to this problem as of yet) BR -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 19:47:39 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8F2i2708830 for ipng-dist; Tue, 14 Sep 1999 19:44:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8F2ho008823 for ; Tue, 14 Sep 1999 19:43:51 -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 TAA26017 for ; Tue, 14 Sep 1999 19:43:50 -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 UAA07791 for ; Tue, 14 Sep 1999 20:43:49 -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 90C4E4CE23; Tue, 14 Sep 1999 22:43:48 -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 WAA01066; Tue, 14 Sep 1999 22:43:48 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id EB82E41F16; Tue, 14 Sep 1999 22:43:47 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id DC859400B4; Tue, 14 Sep 1999 22:43:42 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Bradley Reynolds Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Sep 1999 22:43:42 -0400 Message-Id: <19990915024347.EB82E41F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Bradley Rey nolds writes: > > > that is not analogous in the least to the hierarchy imposed in the ipv6 > > > addressing architecture. cidr only specifies more possible subdivisions > > > of the addressing space which permits you to aggregate in more flexible > > > fashion. it does not mandate an aggregation hierarchy in the least. > > > > See RFC 1466. > > > > rfc1466 has to do with cidr? Yes -- it's cited by RFC 1517 as the way allocation should be done to support aggregation. > > it mandates an allocation hierarchy, not an aggregation hierarchy. > aggregation can be done in conformance to the allocation hierarchy, > but is not necessary. > > people are still free to announce whatever specificity they want. In theory, yes; in practice, not really. First, almost everyone currently receives addresses in conformance with that policy and its successors, precisely to permit aggregation. Second, some major ISPs won't accept route advertisements for overly-long -- that is, unaggregated -- prefixes. The IPv6 allocation policy is simply a cleaner version of what we are currently doing. Yes, there are bad side-effects. We'd all love to have multi-homing, portable /32s (or /128s), etc. We -- as a profession -- simply don't know how to do it. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 22:15:46 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8F5Bxm08948 for ipng-dist; Tue, 14 Sep 1999 22:11:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8F5Bn008941 for ; Tue, 14 Sep 1999 22:11: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 WAA27909 for ; Tue, 14 Sep 1999 22:11:48 -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 XAA06087 for ; Tue, 14 Sep 1999 23:11:47 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id PAA01491; Wed, 15 Sep 1999 15:11:33 +1000 (EST) Date: Wed, 15 Sep 1999 15:11:33 +1000 (EST) From: Peter Tattam To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <37DEC1E5.CDD8978B@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 Tue, 14 Sep 1999, Brian E Carpenter wrote: > Peter, > > Sure, if someone makes a breakthrough that will be great. I haven't > seen it yet though, and people have been looking for many years. > > Brian > I put my thinking cap on last night.. I have a very simple proposal which I would humbly ask be given serious consideration. I did raise a version of it before with Jim but he felt it would get the thumbs down. This is not exactly the same, but draws also on ideas from Dan's proposal, so some of the credit I owe to Dan. My proposal goes thus. 1. Keep the existing CIDR allocation exactly as it is. (not the routing policy, this is dealt with later). 2. sacrifice one bit of the flow label to define a routing label. This would leave 31 bits available for a routing ID. 3. Use sparingly those 31 bits for a heiarchical routing tree. 4a. Have an extension to the DNS system which defines the *current* mapping of the hostname to routing ID. It is a host's responsibilty to place the correct routing ID in the packet prior to transmission. This is no different in security level to existing DNS practice. The DNS would need interaction to reflect the dynamic nature of routing cloud changes. DDNS is I believe suitable for this purpose. 4b. An alternative to DDNS would be multiple RRs combined with stale route detection to trigger automatic replacement of the routing ID at the originating host. 5. The non-site routing cloud then uses this routing ID for interdomain routing instead of the regular dest address. Current practice as used in the 6bone for aggregation. I believe I can sufficiently flesh out a full implementation of this on paper if there is enough interest, but I won't bother if the cost of sacrificing one bit of flow label, altering routing practice, and extending Ipv6 stacks to cope with the changes are impractical. 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 Sep 15 05:46:07 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8FCgR109161 for ipng-dist; Wed, 15 Sep 1999 05:42:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8FCgI009154 for ; Wed, 15 Sep 1999 05:42: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 FAA25339 for ; Wed, 15 Sep 1999 05:42:17 -0700 (PDT) Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25997 for ; Wed, 15 Sep 1999 06:42:16 -0600 (MDT) Received: from newton.ebina.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id VAA16490; Wed, 15 Sep 1999 21:42:15 +0900 (JST) Received: from ppp ([172.16.110.11]) by newton.ebina.hitachi.co.jp (8.9.0/3.7W-EBINA) with SMTP id VAA19105; Wed, 15 Sep 1999 21:42:15 +0900 (JST) Message-Id: <199909151242.VAA19105@newton.ebina.hitachi.co.jp> X-Sender: tsuchi@gpc.ebina.hitachi.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Wed, 15 Sep 1999 21:44:28 +0900 To: ipng@sunroof.eng.sun.com From: Kazuaki Tsuchiya Subject: Re: Toolnet6 installation workshop Cc: imv@kame.net, tsuchi@ebina.hitachi.co.jp In-Reply-To: <4.2.0.58.19990914171604.00b2f990@brahma.imag.fr> References: <199909141245.VAA13754@newton.ebina.hitachi.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, Sure. We will be glad to prepare some NICs to lend to you and other participants. Thanks. -- Kazuaki Tsuchiya. At 17:19 99/09/14 +0200, Alain Durand wrote: > >REQUIREMENTS: > > It is required that you bring your Windows PC with the > > following environment in order to use Toolnet6. > > > > OS: Windows98, Windows95, WindowsNT4.0 > > NIC: 3Com Corp. EtherLink III > > (3C589C, 3C589D, 3CCE589ET, 3CXE589ET,...) > > NE2000 Compatible Adapter > > (D-Link Systems Inc. DE660T/J Ethernet Adapter, ...) > > This is very nice, unfortunately I do not use 3com nor NE2000 adapter, > I use a COM1 platinium pcmcia card. > I suppose others may be in a similar situation... > Could you have several pcmcia card that you support > to loan us for the duration of the meeting? > > - Alain. > -------------------------------------------------------- Kazuaki Tsuchiya (mailto:tsuchi@ebina.hitachi.co.jp) Hitachi,Ltd. Enterprise Server Division Phone: +81-46-235-8268(Dial-in) Fax: +81-46-235-8324 <> http://www.v6.hitachi.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 Wed Sep 15 07:32:13 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8FERj510595 for ipng-dist; Wed, 15 Sep 1999 07:27:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8FERa010588 for ; Wed, 15 Sep 1999 07:27: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 HAA09313 for ; Wed, 15 Sep 1999 07:27:36 -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 HAA22706 for ; Wed, 15 Sep 1999 07:27:34 -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 PAA68088 for ; Wed, 15 Sep 1999 15:27:32 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA33194 for ; Wed, 15 Sep 1999 15:27:31 +0100 (BST) Message-ID: <37DFAD00.9D32FB91@hursley.ibm.com> Date: Wed, 15 Sep 1999 09:28:16 -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: a response to "A Simple Solution for IPv6 Multihoming" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bradley Reynolds wrote: > > > > that is not analogous in the least to the hierarchy imposed in the ipv6 > > > addressing architecture. cidr only specifies more possible subdivisions > > > of the addressing space which permits you to aggregate in more flexible > > > fashion. it does not mandate an aggregation hierarchy in the least. > > > > See RFC 1466. > > > > rfc1466 has to do with cidr? It would be completely meaningless without CIDR > it mandates an allocation hierarchy, not an aggregation hierarchy. > aggregation can be done in conformance to the allocation hierarchy, > but is not necessary. Mathematically, it *is* necessary. Binary trees are binary trees. > > people are still free to announce whatever specificity they want. Fortunately, the major ISPs have been very responsible about this, which is why the default free table has been growing so slowly, and why there are relatively few holes in CIDR blocks. 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 Sep 15 07:36:17 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8FEYuc10617 for ipng-dist; Wed, 15 Sep 1999 07:34:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8FEYl010610 for ; Wed, 15 Sep 1999 07:34:48 -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 HAA09913 for ; Wed, 15 Sep 1999 07:34:47 -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 IAA01658 for ; Wed, 15 Sep 1999 08:34:45 -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 PAA43578; Wed, 15 Sep 1999 15:34:39 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA33270; Wed, 15 Sep 1999 15:34:38 +0100 (BST) Message-ID: <37DFAEAA.F0CFEA21@hursley.ibm.com> Date: Wed, 15 Sep 1999 09:35:22 -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@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, Please don't treat this as a brush-off; I don't consider myself competent in this area. One recommendation of the July IAB workshop is that work on a "next generation" routing system on should be pursued in the IRTF routing research group (i.e. by people with routing clue). I think your idea fits there, not here. Brian Peter Tattam wrote: > > On Tue, 14 Sep 1999, Brian E Carpenter wrote: > > > Peter, > > > > Sure, if someone makes a breakthrough that will be great. I haven't > > seen it yet though, and people have been looking for many years. > > > > Brian > > > > I put my thinking cap on last night.. > > I have a very simple proposal which I would humbly ask be given serious > consideration. I did raise a version of it before with Jim but he felt it > would get the thumbs down. This is not exactly the same, but draws also on > ideas from Dan's proposal, so some of the credit I owe to Dan. > > My proposal goes thus. > > 1. Keep the existing CIDR allocation exactly as it is. (not the routing > policy, this is dealt with later). > > 2. sacrifice one bit of the flow label to define a routing label. This would > leave 31 bits available for a routing ID. > > 3. Use sparingly those 31 bits for a heiarchical routing tree. > > 4a. Have an extension to the DNS system which defines the *current* mapping of > the hostname to routing ID. It is a host's responsibilty to place the correct > routing ID in the packet prior to transmission. This is no different in > security level to existing DNS practice. The DNS would need interaction to > reflect the dynamic nature of routing cloud changes. DDNS is I believe > suitable for this purpose. > > 4b. An alternative to DDNS would be multiple RRs combined with stale > route detection to trigger automatic replacement of the routing ID at the > originating host. > > 5. The non-site routing cloud then uses this routing ID for interdomain > routing instead of the regular dest address. Current practice as used in the > 6bone for aggregation. > > I believe I can sufficiently flesh out a full implementation of this on paper > if there is enough interest, but I won't bother if the cost of sacrificing one > bit of flow label, altering routing practice, and extending Ipv6 stacks to > cope with the changes are impractical. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 07:44:27 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8FEeDi10647 for ipng-dist; Wed, 15 Sep 1999 07:40:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8FEdk010640 for ; Wed, 15 Sep 1999 07:40: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 HAA04111 for ; Wed, 15 Sep 1999 07:39:45 -0700 (PDT) Received: from neonet_server1.nexabit.com (neonetserver1.nexabit.com [209.6.34.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03480 for ; Wed, 15 Sep 1999 08:39:45 -0600 (MDT) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 15 Sep 1999 10:39:44 -0400 Message-ID: <1180113EC576D011AADE0060975B88B38AF5EA@neonet_server1.nexabit.com> From: Dimitry Haskin To: Peter Tattam Cc: ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Wed, 15 Sep 1999 10:39:43 -0400 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, Apart from location of the routing ID, your proposal is not much different from the earlier GSE (64+64) proposal of separating endstation identifiers and routing locators. This proposal was taken seriously but under scrutiny (please read draft-ietf-ipngwg-esd-analysis-04.txt) the proposal showed a number of fatal flaws (e.g. hijacking of TCP connections gets much easier). ---------------------------------------------------------------------- Dimitry Haskin Lucent Technologies Internetworking Systems > -----Original Message----- > From: Peter Tattam [mailto:peter@jazz-1.trumpet.com.au] > Sent: Wednesday, September 15, 1999 1:12 AM > To: Brian E Carpenter > Cc: ipng@sunroof.eng.sun.com > Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" > > > On Tue, 14 Sep 1999, Brian E Carpenter wrote: > > > Peter, > > > > Sure, if someone makes a breakthrough that will be great. I haven't > > seen it yet though, and people have been looking for many years. > > > > Brian > > > > I put my thinking cap on last night.. > > I have a very simple proposal which I would humbly ask be > given serious > consideration. I did raise a version of it before with Jim > but he felt it > would get the thumbs down. This is not exactly the same, but > draws also on > ideas from Dan's proposal, so some of the credit I owe to Dan. > > My proposal goes thus. > > 1. Keep the existing CIDR allocation exactly as it is. (not > the routing > policy, this is dealt with later). > > 2. sacrifice one bit of the flow label to define a routing > label. This would > leave 31 bits available for a routing ID. > > 3. Use sparingly those 31 bits for a heiarchical routing tree. > > 4a. Have an extension to the DNS system which defines the > *current* mapping of > the hostname to routing ID. It is a host's responsibilty to > place the correct > routing ID in the packet prior to transmission. This is no > different in > security level to existing DNS practice. The DNS would need > interaction to > reflect the dynamic nature of routing cloud changes. DDNS is > I believe > suitable for this purpose. > > 4b. An alternative to DDNS would be multiple RRs combined with stale > route detection to trigger automatic replacement of the > routing ID at the > originating host. > > 5. The non-site routing cloud then uses this routing ID for > interdomain > routing instead of the regular dest address. Current > practice as used in the > 6bone for aggregation. > > I believe I can sufficiently flesh out a full implementation > of this on paper > if there is enough interest, but I won't bother if the cost > of sacrificing one > bit of flow label, altering routing practice, and extending > Ipv6 stacks to > cope with the changes are impractical. > > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 08:29:20 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8FFPS312825 for ipng-dist; Wed, 15 Sep 1999 08:25:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8FFPF012807 for ; Wed, 15 Sep 1999 08:25: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 IAA10145 for ; Wed, 15 Sep 1999 08:25:14 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14242 for ; Wed, 15 Sep 1999 08:25:13 -0700 (PDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id LAA21567; Wed, 15 Sep 1999 11:24:59 -0400 (EDT) Message-Id: <199909151524.LAA21567@cannes.aa.ans.net> To: black@layer8.net cc: ipng@sunroof.eng.sun.com, jyy@ans.net Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Wed, 15 Sep 1999 11:24:59 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Ben: Thanks for spending time looking into the proposal. Looks like your main issue is the mendatory route aggregation for IPv6. You should raise this to IPv6 WG. My proposal just try to work out a solution for multihoming given this constrain. It's not an endorsement of such restriction. Your other issues with my proposal are addressed point-by-point below which are inbedded in the message. Some of them seems to be based on incorrect understanding of the proposal and some of them are due to the lack of more detailed explanation of current common routing practice among ISPs. For the latter, I will put more detailed explanation in to the writing, I should not assume that everyone would familar these mechanisms. >I'm not familiar with the workings of the IPng group, so please let me >know if this violates any procedural or etiquette boundaries. I've >just finished reading several of the IPv6 drafts and hoped my thoughts >on one recently submitted draft might be of use. >IPv6 multihoming is a thorny problem and I don't pretend to have a >solution. I don't know that there is one possible as the network layer. > > >Ben >- -- >The IPv6 address allocation and routing hierarchy defined in [AGGR] >and [ARCH] poses serious difficulties for implementation of multihomed >networks. Rather than the usual practice of allocating a single >prefix, or set of prefixes for multiple networks, network operators >must either home to a single provider or allocate multiple prefixes >for the same set of nodes. The draft "A Simple Solution for IPv6 >Multihoming" [SMPL] profers an approach to achieving multihomed >networks within the constraints of the IPv6 route aggregation >hierarchy. Aggregation and allowing no more specific prefixes advertising into the global routing table is a contrain imposed by the IPv6 WG as one of the design of IPv6 routing architecture. Because of this constrain, multihoming routing becomes a hard problem and needs solution. Therefore, my proposal, of course, has to work under this contrain. Do you have any suggestion of maitaining the scaling of the global routing table but not by imposing the restrict aggregation? If not, we still have to work under the assumption. >Unfortunately, the fundamental assumptions regarding the purposes of >multihoming lead the author of the document astray. The main goals >of multihoming are: redundancy in the face of link and/or network >failure, load balancing, and performance improvement. Of these, only >load balancing is directly addressed, and even then with limited >success. Similarly, although improving performance by connecting >directly to networks which are common destinations is effective, the >document does not provide options for accessing content providers >accessible through other networks. I'd argue that the realistic goal of multihoming are a) Redundancy and b) load sharing. The simple multihoming proposal (SMPL) addressed both. 'performance improvement' you used here is a vague term, redundancy and load sharing are performance improvement. If you mean the improve throughput or goodput of the traffic from/to a multihomed site, this is not a realistic goal to achieve via multihoming. >A selection of quotes from the document will help in clarifying its >shortcomings as a solution to multihoming within the existing, >documented IPv6 routing framework. >From section 2 (Proposal): > ISP-3 ---- ISP-4 > | / | > | / | > | / | > ISP-1 ---- ISP-2 > link-1 \ / link-2 > Customer-A > A multi-homed customer will designate a primary ISP and receive IP > address from its primary ISP's IPv6 aggregation block. In this > example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A > to the customer. Customer-A will advertise addr-1-A to ISP-1 and > ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to > ISP-1 only. ISP-1 will, of course, advertise its own aggregation > Addr-1 to the entire Internet. >It is clear from this description that the only redundancy provided >with this solution is for the customer links (link-1 and link-2) and >not for the ISPs themselves. Specifically, if ISP-1 suffers from a >failure within the POP to which link-1 terminates, whether as an >isolated failure or a more extensive failure within ISP-1, then >Customer-A is no longer able to maintain connectivity despite their >possession of a perfectly good alternate path through ISP-2. From an >engineering perspective, no robustness has been gained through this >multihoming which could not be gained more simply with multiple links >to ISP-1. This is not correct. If the POP to which link-1 connects goes down, the connectivity to Customer-A will still remain and link-2 will be used. This is because even the POP is down, ISP-1 will still advertising Addr-1 which including the address of Customer-A to the Internet (ISP-1 will still advertise its block). So traffic destinted to Customer-A will still be sent to ISP-1. Since ISP-2 advertises the specific address of Customer-A to ISP-1, so ISP-1 will just forward the traffic to ISP-2 which will further forward traffic to Customer-A vis link-2. >From section 2 (Proposal): > For inbound traffic to Customer-A, traffic will first be forwarded to > ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will > then forward the traffic destined to Customer-A via its connection to > ISP-2 and/or its direct link to customer-A, according to certain > polices. Most common policy would be the use of the shortest exit. By > using both connections to forward traffic to Customer-A, load sharing > is achieved. >From this statement it is unclear exactly how inbound load balancing >is to be achieved. Is the author suggesting use of the (rather >troublesome) concept of eBGP multipath? In the topology described in >the diagram above, implementation of a load sharing mechanism across >link-1 and link-2 would be a decidedly non-trivial matter. Again, >given the lack of redundancy outlined above, it would be far more >efficient for Customer-A to simply purchase multiple links to ISP-1. No, I am not suggesting the use of eBGP multipath. The method is the same as the common mechanism used by ISPs today to deal with forwarding traffic to routes learned from multiple network points i.e. to use IGP metric to find the closest exit to forward the traffic. It could use to ISP-2 or could use its direct link to Customer-A. I assumed that the reader would be familiar with the mechanism since it's so commonly used. But maybe I can not assume this and in next revision, I should put more details to explain it. >Additionally, Customer-A must now depend heavily on the connectivity >between ISP-1 and ISP-2. Often, links to multiple providers are >purchased specifically to avoid traffic crossing these (often >congested) peerings. Unless the traffic are sourced and destined within the multihoming site and its directly connected ISPs (e.g. from customer-A to src/dst behind ISP-1 or ISP-2), the traffic has to go through links between ISPs. This is the case today. Even without the SMPL, in today's network, a multihomed site just can not dictate how the traffic goes back to it. It's all depends a other ISPs' routing policy. Looks at the picture, even not using the SMPL, it does not gaurantee that ISP4 will use ISP-2 to send traffic to customer-A, it may well be sending the traffic via its link to ISP-1. I also think it's wrong to assume that the links between ISPs are by default congested. It was more so the case when all ISPs exchange traffic at NAPs (i.e. Public exchange point). There are a lot of private links between ISPs at multiple locations and the situation is different now. >From Section 4 (Concerns): > - The primary ISP of a multihoming customer (such as ISP-1 in the > example) would need to do more work in terms of distributing the > traffic among other connected ISPs and the customer link. This > can be done using BGP policy (BGP community) and using shortest > exit. It will also carry more traffic for the customer. However, > this is a value added service to the customer and the primary ISP > can charge more fees for such services. >Stating that the primary ISP "would need to do more work" is putting >the problem a bit lightly. The addition of references to BGP policies >and BGP communities does little to clarify how exactly the author >believes traffic could effectively be distributed. Again, these are common practice which are already in place. I should not have assumed the everyone would familiar with it. I will give more detailed explanation to it. >From Section 4 (Concerns): > - The primary ISP is the sole interface for the multihomed > customer to the Internet other than the ISPs the customer has > directly connection with. Outages such as one between ISP-1 and > ISP-4 would impact the reachability from customers of ISP-4 to > Customer-A even though ISP-2 still has good connection to ISP-4. > However, if the primary ISP is a good quality ISP, this sort of > situation should happen rarely. The reason is that it's common > practice that an ISP, especially good quality ISP, has multiple > connections to other big ISPs at different geographical locations. > Good quality ISPs also have robust network design to prevent any > failure to impact the whole network. Choosing a good quality and > robust ISP as primary ISP is a good practice. >This is really the crux of the problem with the solution put forth in >the document. The assumption that a given ISP will never have >failures, or that rare failures are acceptable to customers who >multihomed for redundancy, is simply not valid from an engineering >perspective. If the primary goal of multihoming were load sharing, >this solution would provide one, potentially very complicated, >answer. However, the issue of multihoming for redundancy is totally >ignored, drawing into question the need for a second ISP in the >equation at all. Why not simply purchase additional bandwidth from >the same ISP? Since noboday can gaurantee absolutely and 100% no outage, the measure of 'rarely happen' is really quite a good measure. Even with today's practice, nobody can ganrantee that the two ISPs the multihoming site connecting to, will not go down at the same time thus leave the site with no connection. But one can say, it rarely happen so we will have two ISP connections instead of 3 or 4 or more. Also, if the alternatives to SMPL is to have multiple address assigned to all my hosts (could hundread thousands) or complcated tunnels,etc. My feeling (based on my network operationa and engieering experience) the chances of my connectivity will be impacted due operation error, misconfigurations, etc. woulud be much more high than use of SMPL. >From Section 4 (Concerns): > It is desirable to have solution which provides perfect redundancy > and, at the same time, simplicity to scale management and operation. > In the absence of a perfect solution, the trade-off needs to be made. > The author believes that it is very important that the solution has > to be simple and manageable. Manageability should be the top > consideration. >If manageability of the solution is to be the top consideration, the >response put forward does not measure up. In the name of avoiding >routing table growth the author has suggested adding significant >complexity to the configuration and management of multihomed customers >without showing any benefit for the effort. As mentioned above, the routing aggregation is a given contrain that this proposal works under. The simplicity I am mentioned here is more in compare of other proposals in terms of complicated tunnel and mulit addressing for every single host in a multihoming site. Compare to that, this proposal is highly scalable and managable. >An area not addressed at all in the document is that of multihoming >for access to networks attached to a given ISP, rather than access to >that ISP. For example, using the diagram above, if Customer-A >purchased connectivity to ISP-2 because ISP-2 had better connectivity >to ISP-4, then the offered multihoming solution is of no use. ISP-4 >will never see reachability to Customer-A via ISP-2. Again, as mentioned above, even without the SMPL, in today's network, a multihomed site just can not dictate how the traffic goes back to it. It's all depends a other ISPs' routing policy. ISP-4 may well have the policy of sending traffic to ISP-1 instead of using its link of ISP-2. There are many reasons which led ISP-4 do that. In short, ISP-4 will look into the interets of itself rather Customer-A's interests, especially Customer-A is not even directly pay for ISP-4. If someone expects the incomming traffic will take the path it wished, then he or she needs to be more realistic. Likewise, one should not ask a multihoming proposal address this. >The primary lesson of the draft proposal is that the proposed, forced >aggregation hierarchy places sever restrictions upon the engineering >of reliable, high poerformance networks. To multihome effectively, a >network operator must somehow qualify as a "long-haul provider" or >other entity appropriate for allocation of its own address space. In >this author's opinion, the current IPv6 addressing architecture >creates an environment which provides scalability of the global >routing table at the expense of any real hope for redundancy through >multihoming. >Solutions which avoid the use of multihoming with a single address >space are possible and offer more hope for a robust network than those >currently proposed. Looks like you have an issue of the mendetory aggregation for IPv6. You should raise this to IPv6 WG for this. My proposal just works under contrain of this assumption. It's not an endorsement of such restriction. >REFERENCES > [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An > Aggregatable Global Unicast Address Format", RFC 2374, July > 1998. > > [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", > RFC 2373, July 1998. > > [SMPL] Yu, J., "A Simple Solution for IPv6 Multihoming", > draft-yu-simple-ipv6multihoming-00.txt, August 1999. --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 09:10:57 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8FG6vc15425 for ipng-dist; Wed, 15 Sep 1999 09:06:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8FG6j015409 for ; Wed, 15 Sep 1999 09:06:45 -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 JAA16415 for ; Wed, 15 Sep 1999 09:06:44 -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 KAA13664 for ; Wed, 15 Sep 1999 10:06:43 -0600 (MDT) Received: from quarry.zk3.dec.com ([16.141.40.15]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id MAA08203; Wed, 15 Sep 1999 12:06:41 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000010340; Wed, 15 Sep 1999 12:06:40 -0400 (EDT) From: Jim Bound Message-Id: <199909151606.MAA0000010340@quarry.zk3.dec.com> To: Bob Hinden cc: ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: Draft IPng Interim Meeting Agenda In-reply-to: Your message of "Sat, 04 Sep 1999 19:18:29 PDT." <3.0.5.32.19990904191829.03e4a100@mailhost.iprg.nokia.com> Date: Wed, 15 Sep 1999 12:06:38 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, I won't be able to attend this Interim meeting. But as you saw on another thread I have some very strong assertions and have defined a solution for the src/dst address selection that I would have presented had I been able to attend. So I just want you to know that my views on this particular issue are very strong and I consider it very important to product plans for IPv6. It could be depending on what happens in Japan this may need to be discussed also at Wash D.C. at the IETF regular meeting, I think this entire Multihome issue will need much more discussion as did our Addressing Proposal from 8+8, to GSE, to what we are actually deploying now for IPv6. Sincerely, /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 Sep 15 12:20:54 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8FJ79b20916 for ipng-dist; Wed, 15 Sep 1999 12:07:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8FJ6s020898 for ; Wed, 15 Sep 1999 12:06: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 MAA08444 for ; Wed, 15 Sep 1999 12:06:51 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA08506 for ; Wed, 15 Sep 1999 13:06:50 -0600 (MDT) Received: (qmail 18018 invoked by uid 1001); 15 Sep 1999 19:06:49 -0000 Date: Wed, 15 Sep 1999 12:06:49 -0700 From: Ben Black To: Jessica Yu Cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990915120648.P6617@layer8.net> References: <199909151524.LAA21567@cannes.aa.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199909151524.LAA21567@cannes.aa.ans.net>; from Jessica Yu on Wed, Sep 15, 1999 at 11:24:59AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Sep 15, 1999 at 11:24:59AM -0400, Jessica Yu wrote: > > >The IPv6 address allocation and routing hierarchy defined in [AGGR] > >and [ARCH] poses serious difficulties for implementation of multihomed > >networks. Rather than the usual practice of allocating a single > >prefix, or set of prefixes for multiple networks, network operators > >must either home to a single provider or allocate multiple prefixes > >for the same set of nodes. The draft "A Simple Solution for IPv6 > >Multihoming" [SMPL] profers an approach to achieving multihomed > >networks within the constraints of the IPv6 route aggregation > >hierarchy. > > Aggregation and allowing no more specific prefixes advertising > into the global routing table is a contrain imposed by the IPv6 > WG as one of the design of IPv6 routing architecture. Because of > this constrain, multihoming routing becomes a hard problem and > needs solution. Therefore, my proposal, of course, has to work > under this contrain. > Thank you for paraphrasing exactly what I said in the quoted paragraph. > Do you have any suggestion of maitaining the scaling of the global > routing table but not by imposing the restrict aggregation? If not, > we still have to work under the assumption. > Yes, realize that the routing table has sustained linear growth, while computing power has increased exponentially. This argues for using existing aggregation and multihoming mechanisms. > > >Unfortunately, the fundamental assumptions regarding the purposes of > >multihoming lead the author of the document astray. The main goals > >of multihoming are: redundancy in the face of link and/or network > >failure, load balancing, and performance improvement. Of these, only > >load balancing is directly addressed, and even then with limited > >success. Similarly, although improving performance by connecting > >directly to networks which are common destinations is effective, the > >document does not provide options for accessing content providers > >accessible through other networks. > > I'd argue that the realistic goal of multihoming are > a) Redundancy and b) load sharing. The simple multihoming > proposal (SMPL) addressed both. > > 'performance improvement' you used here is a vague term, > redundancy and load sharing are performance improvement. > If you mean the improve throughput or goodput of the traffic > from/to a multihomed site, this is not a realistic goal to > achieve via multihoming. > Nonsense. If I am sending a large amount of traffic to ISP-A, but I only have connectivity to ISP-B and ISP-B has poor connectivity to ISP-A, then adding connectivity directly to ISP-A will improve the performance, as measured by such factors as latency, packet loss, etc. > >A selection of quotes from the document will help in clarifying its > >shortcomings as a solution to multihoming within the existing, > >documented IPv6 routing framework. > > >From section 2 (Proposal): > > > ISP-3 ---- ISP-4 > > | / | > > | / | > > | / | > > ISP-1 ---- ISP-2 > > link-1 \ / link-2 > > Customer-A > > > A multi-homed customer will designate a primary ISP and receive IP > > address from its primary ISP's IPv6 aggregation block. In this > > example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A > > to the customer. Customer-A will advertise addr-1-A to ISP-1 and > > ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to > > ISP-1 only. ISP-1 will, of course, advertise its own aggregation > > Addr-1 to the entire Internet. > > >It is clear from this description that the only redundancy provided > >with this solution is for the customer links (link-1 and link-2) and > >not for the ISPs themselves. Specifically, if ISP-1 suffers from a > >failure within the POP to which link-1 terminates, whether as an > >isolated failure or a more extensive failure within ISP-1, then > >Customer-A is no longer able to maintain connectivity despite their > >possession of a perfectly good alternate path through ISP-2. From an > >engineering perspective, no robustness has been gained through this > >multihoming which could not be gained more simply with multiple links > >to ISP-1. > > This is not correct. If the POP to which link-1 connects goes > down, the connectivity to Customer-A will still remain and > link-2 will be used. > > This is because even the POP is down, ISP-1 will still > advertising Addr-1 which including the address of Customer-A > to the Internet (ISP-1 will still advertise its block). So > traffic destinted to Customer-A will still be sent to ISP-1. > Since ISP-2 advertises the specific address of Customer-A to > ISP-1, so ISP-1 will just forward the traffic to ISP-2 which > will further forward traffic to Customer-A vis link-2. > Your eggs are still all in the ISP-1 basket. Even the best ISPs have wide-scale failures. Your later assertion that this is reasonable and acceptable is contrary to the redundancy goals you agreed with for multihoming. > > > >From section 2 (Proposal): > > > For inbound traffic to Customer-A, traffic will first be forwarded to > > ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will > > then forward the traffic destined to Customer-A via its connection to > > ISP-2 and/or its direct link to customer-A, according to certain > > polices. Most common policy would be the use of the shortest exit. By > > using both connections to forward traffic to Customer-A, load sharing > > is achieved. > > >From this statement it is unclear exactly how inbound load balancing > >is to be achieved. Is the author suggesting use of the (rather > >troublesome) concept of eBGP multipath? In the topology described in > >the diagram above, implementation of a load sharing mechanism across > >link-1 and link-2 would be a decidedly non-trivial matter. Again, > >given the lack of redundancy outlined above, it would be far more > >efficient for Customer-A to simply purchase multiple links to ISP-1. > > No, I am not suggesting the use of eBGP multipath. The method > is the same as the common mechanism used by ISPs today to deal > with forwarding traffic to routes learned from multiple network > points i.e. to use IGP metric to find the closest exit to forward > the traffic. It could use to ISP-2 or could use its direct link > to Customer-A. > Why would there be more than route to the destination in ISP-1s IGP? ISP-1 would pick the *single* best path in BGP and use that *single* path when sending traffic to the customer. Are you suggesting that the IGP would see multiple paths to the same destination even though BGP only saw one? Or are you suggesting that BGP would carry multiple routes to the same destination? > I assumed that the reader would be familiar with the mechanism > since it's so commonly used. But maybe I can not assume this > and in next revision, I should put more details to explain it. > > >Additionally, Customer-A must now depend heavily on the connectivity > >between ISP-1 and ISP-2. Often, links to multiple providers are > >purchased specifically to avoid traffic crossing these (often > >congested) peerings. > > Unless the traffic are sourced and destined within the multihoming > site and its directly connected ISPs (e.g. from customer-A to src/dst > behind ISP-1 or ISP-2), the traffic has to go through links between > ISPs. This is the case today. > Except that today if there is poor connectivity between a pair of given ISPs the result is that you have poor reachability to one of those ISPs. In the configuration you describe, the result is poor *global* reachability in the case of failure of a *single* ISP. > Even without the SMPL, in today's network, a multihomed site > just can not dictate how the traffic goes back to it. It's > all depends a other ISPs' routing policy. Looks at the > picture, even not using the SMPL, it does not gaurantee > that ISP4 will use ISP-2 to send traffic to customer-A, > it may well be sending the traffic via its link to ISP-1. > The point is that *both* of the paths to the customer are *usable*. In the current system of multihoming, if ISP-1 failed, all traffic would flow through ISP-2. The issue is now how well the customer can control reachability to their own network, but whether there is reachability at all in the case of upstream failure. > I also think it's wrong to assume that the links between > ISPs are by default congested. It was more so the case when > all ISPs exchange traffic at NAPs (i.e. Public exchange point). > There are a lot of private links between ISPs at multiple > locations and the situation is different now. > No, the situation is not different now. Private peerings are quite often congested and neither ISP involved in a private peering has any reason to change that. > >From Section 4 (Concerns): > > > - The primary ISP of a multihoming customer (such as ISP-1 in the > > example) would need to do more work in terms of distributing the > > traffic among other connected ISPs and the customer link. This > > can be done using BGP policy (BGP community) and using shortest > > exit. It will also carry more traffic for the customer. However, > > this is a value added service to the customer and the primary ISP > > can charge more fees for such services. > > >Stating that the primary ISP "would need to do more work" is putting > >the problem a bit lightly. The addition of references to BGP policies > >and BGP communities does little to clarify how exactly the author > >believes traffic could effectively be distributed. > > Again, these are common practice which are already in place. > I should not have assumed the everyone would familiar with > it. I will give more detailed explanation to it. > Please do. > > >From Section 4 (Concerns): > > > - The primary ISP is the sole interface for the multihomed > > customer to the Internet other than the ISPs the customer has > > directly connection with. Outages such as one between ISP-1 and > > ISP-4 would impact the reachability from customers of ISP-4 to > > Customer-A even though ISP-2 still has good connection to ISP-4. > > However, if the primary ISP is a good quality ISP, this sort of > > situation should happen rarely. The reason is that it's common > > practice that an ISP, especially good quality ISP, has multiple > > connections to other big ISPs at different geographical locations. > > Good quality ISPs also have robust network design to prevent any > > failure to impact the whole network. Choosing a good quality and > > robust ISP as primary ISP is a good practice. > > >This is really the crux of the problem with the solution put forth in > >the document. The assumption that a given ISP will never have > >failures, or that rare failures are acceptable to customers who > >multihomed for redundancy, is simply not valid from an engineering > >perspective. If the primary goal of multihoming were load sharing, > >this solution would provide one, potentially very complicated, > >answer. However, the issue of multihoming for redundancy is totally > >ignored, drawing into question the need for a second ISP in the > >equation at all. Why not simply purchase additional bandwidth from > >the same ISP? > > Since noboday can gaurantee absolutely and 100% no outage, > the measure of 'rarely happen' is really quite a good measure. > But irrelevant since you must rely entirely on a single ISP, despite the fact that you have more than 1 connection. > Even with today's practice, nobody can ganrantee that the two > ISPs the multihoming site connecting to, will not go down at the > same time thus leave the site with no connection. But one > can say, it rarely happen so we will have two ISP connections instead > of 3 or 4 or more. > Yes, and people do exactly that. But using the technique described in your draft, adding those additional ISPs would provide no benefit. > Also, if the alternatives to SMPL is to have multiple address > assigned to all my hosts (could hundread thousands) or complcated > tunnels,etc. My feeling (based on my network operationa and engieering > experience) the chances of my connectivity will be impacted due > operation error, misconfigurations, etc. woulud be much more high > than use of SMPL. > My feeling, also based on my network operations and engineering experience, is that I would rather rely on a slightly more complicated configuration which allows arbitrary increases in connectivity to provide additional redundancy than on a system that is "simple" but allows almost no redundancy and absolutely no scaling. > >From Section 4 (Concerns): > > > It is desirable to have solution which provides perfect redundancy > > and, at the same time, simplicity to scale management and operation. > > In the absence of a perfect solution, the trade-off needs to be made. > > The author believes that it is very important that the solution has > > to be simple and manageable. Manageability should be the top > > consideration. > > >If manageability of the solution is to be the top consideration, the > >response put forward does not measure up. In the name of avoiding > >routing table growth the author has suggested adding significant > >complexity to the configuration and management of multihomed customers > >without showing any benefit for the effort. > > As mentioned above, the routing aggregation is a given > contrain that this proposal works under. The simplicity > I am mentioned here is more in compare of other proposals > in terms of complicated tunnel and mulit addressing for > every single host in a multihoming site. Compare to > that, this proposal is highly scalable and managable. > You are half right. > >An area not addressed at all in the document is that of multihoming > >for access to networks attached to a given ISP, rather than access to > >that ISP. For example, using the diagram above, if Customer-A > >purchased connectivity to ISP-2 because ISP-2 had better connectivity > >to ISP-4, then the offered multihoming solution is of no use. ISP-4 > >will never see reachability to Customer-A via ISP-2. > > Again, as mentioned above, even without the SMPL, in today's > network, a multihomed site just can not dictate how the traffic > goes back to it. It's all depends a other ISPs' routing policy. > ISP-4 may well have the policy of sending traffic to ISP-1 > instead of using its link of ISP-2. There are many reasons which > led ISP-4 do that. In short, ISP-4 will look into the interets > of itself rather Customer-A's interests, especially Customer-A > is not even directly pay for ISP-4. > Yes, but ISP-4 will *never* send traffic *directly* to ISP-2 even though there is connectivity to the customer via ISP-2. Even if ISP-4 loses connectivity to ISP-1. > If someone expects the incomming traffic will take the path it > wished, then he or she needs to be more realistic. Likewise, > one should not ask a multihoming proposal address this. > No, I expect a multihoming proposal to provide a realistic level of redundancy. SMPL does not meet this requirement. > >The primary lesson of the draft proposal is that the proposed, forced > >aggregation hierarchy places sever restrictions upon the engineering > >of reliable, high poerformance networks. To multihome effectively, a > >network operator must somehow qualify as a "long-haul provider" or > >other entity appropriate for allocation of its own address space. In > >this author's opinion, the current IPv6 addressing architecture > >creates an environment which provides scalability of the global > >routing table at the expense of any real hope for redundancy through > >multihoming. > > >Solutions which avoid the use of multihoming with a single address > >space are possible and offer more hope for a robust network than those > >currently proposed. > > Looks like you have an issue of the mendetory aggregation for > IPv6. You should raise this to IPv6 WG for this. My proposal > just works under contrain of this assumption. It's not an > endorsement of such restriction. > I do indeed have an issue with the aggregation policies. However, working within them, I believe the RFC2260/itojun proposal provides value as a mechanism for improving reachability for a customer network and SMPL does not. > > >REFERENCES > > > [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An > > Aggregatable Global Unicast Address Format", RFC 2374, July > > 1998. > > > > [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", > > RFC 2373, July 1998. > > > > [SMPL] Yu, J., "A Simple Solution for IPv6 Multihoming", > > draft-yu-simple-ipv6multihoming-00.txt, August 1999. > > > > --Jessica -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 13:04:54 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8FJuRN23053 for ipng-dist; Wed, 15 Sep 1999 12:56:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8FJuC023031 for ; Wed, 15 Sep 1999 12:56:14 -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 MAA18404 for ; Wed, 15 Sep 1999 12:55:44 -0700 (PDT) Received: from happy.cow.org (happy.cow.org [198.88.20.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA29435 for ; Wed, 15 Sep 1999 13:55:43 -0600 (MDT) Received: from localhost (brad@localhost) by happy.cow.org (8.9.3/8.9.3) with ESMTP id PAA45675; Wed, 15 Sep 1999 15:54:24 -0400 (EDT) (envelope-from brad@qual.net) X-Authentication-Warning: happy.cow.org: brad owned process doing -bs Date: Wed, 15 Sep 1999 15:54:24 -0400 (EDT) From: Bradley Reynolds X-Sender: brad@happy.cow.org To: Jessica Yu cc: black@layer8.net, ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <199909151524.LAA21567@cannes.aa.ans.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk comments below > Do you have any suggestion of maitaining the scaling of the global > routing table but not by imposing the restrict aggregation? If not, > we still have to work under the assumption. > this is not germane to your document, but seems like ipv4 is working fine without such a restriction. > I'd argue that the realistic goal of multihoming are > a) Redundancy and b) load sharing. The simple multihoming > proposal (SMPL) addressed both. > > 'performance improvement' you used here is a vague term, > redundancy and load sharing are performance improvement. > If you mean the improve throughput or goodput of the traffic > from/to a multihomed site, this is not a realistic goal to > achieve via multihoming. > > > > ISP-3 ---- ISP-4 > > | / | > > | / | > > | / | > > ISP-1 ---- ISP-2 > > link-1 \ / link-2 > > Customer-A > > >It is clear from this description that the only redundancy provided > >with this solution is for the customer links (link-1 and link-2) and > >not for the ISPs themselves. Specifically, if ISP-1 suffers from a > >failure within the POP to which link-1 terminates, whether as an > >isolated failure or a more extensive failure within ISP-1, then > >Customer-A is no longer able to maintain connectivity despite their > >possession of a perfectly good alternate path through ISP-2. From an > >engineering perspective, no robustness has been gained through this > >multihoming which could not be gained more simply with multiple links > >to ISP-1. > > This is not correct. If the POP to which link-1 connects goes > down, the connectivity to Customer-A will still remain and > link-2 will be used. > > This is because even the POP is down, ISP-1 will still > advertising Addr-1 which including the address of Customer-A > to the Internet (ISP-1 will still advertise its block). So > traffic destinted to Customer-A will still be sent to ISP-1. > Since ISP-2 advertises the specific address of Customer-A to > ISP-1, so ISP-1 will just forward the traffic to ISP-2 which > will further forward traffic to Customer-A vis link-2. > you need to be explicitly clear as to how traffic passes from ISP-1 to ISP-2. if this is a tunnel through isp 3 and 4, the load sharing is worthless. if it is a direct connection, then you are implying multiple direct conenctions (not in this figure) because of ISP-2 is connected to ISP-1 at the failed pop, suddenly we have no reachability for this prefix. > No, I am not suggesting the use of eBGP multipath. The method > is the same as the common mechanism used by ISPs today to deal > with forwarding traffic to routes learned from multiple network > points i.e. to use IGP metric to find the closest exit to forward > the traffic. It could use to ISP-2 or could use its direct link > to Customer-A. > it works ok for large networks. because large networks have multiple distributed interconnects. when you are looking at two paths to forward data to a given network, figuring out how to space them IGP wise on your backbone to obtain some sort of 'balance' is a joke. the complexityy of this problem becomes unacceptable when you are trying to manage multiple customers under this scenario who all want favourable IGP spacing based on traffic flows on your network. if you start interconnecting multiple times with ISP-2, you are in terrible shape because igp metric decisions will favor the path to isp-2 more often than your own internal path. > I assumed that the reader would be familiar with the mechanism > since it's so commonly used. But maybe I can not assume this > and in next revision, I should put more details to explain it. > yeah, explain how it works in this scenario to achieve load balancing. i am not able to see it. > >Additionally, Customer-A must now depend heavily on the connectivity > >between ISP-1 and ISP-2. Often, links to multiple providers are > >purchased specifically to avoid traffic crossing these (often > >congested) peerings. > > Unless the traffic are sourced and destined within the multihoming > site and its directly connected ISPs (e.g. from customer-A to src/dst > behind ISP-1 or ISP-2), the traffic has to go through links between > ISPs. This is the case today. > you are making a logical fallacy there. the traffic has to go through links between ISPs but not over links between the two ISPs customer-a is multihomed to. the issue is that ISP-1 is now providing free transit to ISP-2 fo rthat multihomed customer. that is just silly. and to contend that isp-2 should be paying isp-1 because a customer desires to multihome to isp-2 is also silly. > Even without the SMPL, in today's network, a multihomed site > just can not dictate how the traffic goes back to it. It's > all depends a other ISPs' routing policy. Looks at the > picture, even not using the SMPL, it does not gaurantee > that ISP4 will use ISP-2 to send traffic to customer-A, > it may well be sending the traffic via its link to ISP-1. > however, it does say that when isp-1 goes away, isp4 will use isp2 > >Stating that the primary ISP "would need to do more work" is putting > >the problem a bit lightly. The addition of references to BGP policies > >and BGP communities does little to clarify how exactly the author > >believes traffic could effectively be distributed. > > Again, these are common practice which are already in place. > I should not have assumed the everyone would familiar with > it. I will give more detailed explanation to it. we understand how bgp path selection works. we understand how traffic flows across large backbones. what we don't understand is how you can have any kind of simple balance in egress traffic bnetween isp-2 and isp-1s links to customer-a. when you introduce this scenario, you are tying gordian knot of complexity into interconnections between providers. you are also missing another point. when you multihome, there should be no 'primary ISP'. primary isp introduces single points of failure whether on the technical side the administrative side. > >This is really the crux of the problem with the solution put forth in > >the document. The assumption that a given ISP will never have > >failures, or that rare failures are acceptable to customers who > >multihomed for redundancy, is simply not valid from an engineering > >perspective. If the primary goal of multihoming were load sharing, > >this solution would provide one, potentially very complicated, > >answer. However, the issue of multihoming for redundancy is totally > >ignored, drawing into question the need for a second ISP in the > >equation at all. Why not simply purchase additional bandwidth from > >the same ISP? > > Since noboday can gaurantee absolutely and 100% no outage, > the measure of 'rarely happen' is really quite a good measure. > > Even with today's practice, nobody can ganrantee that the two > ISPs the multihoming site connecting to, will not go down at the > same time thus leave the site with no connection. But one > can say, it rarely happen so we will have two ISP connections instead > of 3 or 4 or more. > you are putting forth a hastily described scenario where a provider multihomes to isp-1 and isp-2. what happens when a provider wants to multihome to isp-1 isp-2 isp-3 and isp-4. suddenly things become extremely complex. the point of redundancy is to engineer out as many single points of failure as possible. this proposal introduces _more_ single points of failure than we are used to under the current operational deployment of ipv4 and its associate routing protocols. this is not a debate of the ipv6 addressing architecture, but a statement that this draft does not solve the ipv6 multihoming problem. > Also, if the alternatives to SMPL is to have multiple address > assigned to all my hosts (could hundread thousands) or complcated > tunnels,etc. My feeling (based on my network operationa and engieering > experience) the chances of my connectivity will be impacted due > operation error, misconfigurations, etc. woulud be much more high > than use of SMPL. i belive this document has no operational sanity check. and if it does, i would like to hear the opinions of the operators who are favouring this scenario when compared to the current ipv4 multihoming scenario. i would be interested in hearing their justifications > As mentioned above, the routing aggregation is a given > contrain that this proposal works under. The simplicity > I am mentioned here is more in compare of other proposals > in terms of complicated tunnel and mulit addressing for > every single host in a multihoming site. Compare to > that, this proposal is highly scalable and managable. > compared to unmanagable things, this draft is less unmagable? scalability and managability are not relative terms unless we have exhauseted all possible scenarios for multihoming. > Again, as mentioned above, even without the SMPL, in today's > network, a multihomed site just can not dictate how the traffic > goes back to it. It's all depends a other ISPs' routing policy. > ISP-4 may well have the policy of sending traffic to ISP-1 > instead of using its link of ISP-2. There are many reasons which > led ISP-4 do that. In short, ISP-4 will look into the interets > of itself rather Customer-A's interests, especially Customer-A > is not even directly pay for ISP-4. i don't think you understand that isp-4 has multiple AS paths to customer-a today. it is advantageous to have traffic flowing through diverse administrative domains. that is why diverse as-path is an advantage. > > If someone expects the incomming traffic will take the path it > wished, then he or she needs to be more realistic. Likewise, > one should not ask a multihoming proposal address this. > again, this is a logical fallacy. you are assuming that since one person cannot have as much granularity as they desire on multihomed links, they should be happy to only have one AS path. > Looks like you have an issue of the mendetory aggregation for > IPv6. You should raise this to IPv6 WG for this. My proposal > just works under contrain of this assumption. It's not an > endorsement of such restriction. it absolutely does not work under that restriction. BR -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 15:34:45 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8FMTqd00569 for ipng-dist; Wed, 15 Sep 1999 15:29:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8FMTg000557 for ; Wed, 15 Sep 1999 15:29:42 -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 PAA24009 for ; Wed, 15 Sep 1999 15:29: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 PAA15173 for ; Wed, 15 Sep 1999 15:29:39 -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 XAA47758; Wed, 15 Sep 1999 23:29:36 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA24968; Wed, 15 Sep 1999 23:29:33 +0100 (BST) Message-ID: <37E01DF7.C7279BFE@hursley.ibm.com> Date: Wed, 15 Sep 1999 17:30:15 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Bradley Reynolds CC: Jessica Yu , black@layer8.net, ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bradley Reynolds wrote: > > comments below > > > Do you have any suggestion of maitaining the scaling of the global > > routing table but not by imposing the restrict aggregation? If not, > > we still have to work under the assumption. > > > this is not germane to your document, but seems like ipv4 is working > fine without such a restriction. I find this pretty rich, being addressed to one of the authors of the CIDR proposal that saved the Internet routing tables from exponential growth a few years ago. IPv4 has survived only because of exactly such a restriction. 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 Sep 15 15:39:29 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8FMbf501026 for ipng-dist; Wed, 15 Sep 1999 15:37:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8FMbU001013 for ; Wed, 15 Sep 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 PAA05424 for ; Wed, 15 Sep 1999 15:37:29 -0700 (PDT) Received: from null0.qual.net (209-128-81-085.bayarea.net [209.128.81.85] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08563 for ; Wed, 15 Sep 1999 16:37:28 -0600 (MDT) Received: from localhost (brad@localhost) by null0.qual.net (8.9.1/8.9.1) with ESMTP id WAA04643; Wed, 15 Sep 1999 22:36:37 GMT (envelope-from brad@qual.net) X-Authentication-Warning: null0.qual.net: brad owned process doing -bs Date: Wed, 15 Sep 1999 22:36:35 +0000 (GMT) From: Bradley Reynolds To: Brian E Carpenter cc: Jessica Yu , black@layer8.net, ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <37E01DF7.C7279BFE@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 > > > Do you have any suggestion of maitaining the scaling of the global > > > routing table but not by imposing the restrict aggregation? If not, > > > we still have to work under the assumption. > > > > > this is not germane to your document, but seems like ipv4 is working > > fine without such a restriction. > > I find this pretty rich, being addressed to one of the authors > of the CIDR proposal that saved the Internet routing tables > from exponential growth a few years ago. IPv4 has survived > only because of exactly such a restriction. > how many times do i have to explain that it does not MANDATE aggregation. you are free to deaggregate. BR -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 16:29:35 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8FNOdo03328 for ipng-dist; Wed, 15 Sep 1999 16:24:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8FNOP003312 for ; Wed, 15 Sep 1999 16:24:25 -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 QAA15529 for ; Wed, 15 Sep 1999 16:24:23 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA04841 for ; Wed, 15 Sep 1999 16:24:23 -0700 (PDT) Received: from world.std.com (qqi@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id TAA18805; Wed, 15 Sep 1999 19:24:17 -0400 (EDT) Received: from localhost (qqi@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id TAA21813; Wed, 15 Sep 1999 19:24:12 -0400 (EDT) Date: Wed, 15 Sep 1999 19:24:12 -0400 (EDT) From: Quality Quorum To: Brian E Carpenter cc: Bradley Reynolds , Jessica Yu , black@layer8.net, ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <37E01DF7.C7279BFE@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 Wed, 15 Sep 1999, Brian E Carpenter wrote: > Bradley Reynolds wrote: > > > > comments below > > > > > Do you have any suggestion of maitaining the scaling of the global > > > routing table but not by imposing the restrict aggregation? If not, > > > we still have to work under the assumption. > > > > > this is not germane to your document, but seems like ipv4 is working > > fine without such a restriction. > > I find this pretty rich, being addressed to one of the authors > of the CIDR proposal that saved the Internet routing tables > from exponential growth a few years ago. IPv4 has survived > only because of exactly such a restriction. It does not matter anymore (or it will not matter soon) due to recent tech advances - so, it seems to me that there is no reason to discuss any proposal from this angle. > Brian Thanks, Aleksey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 16:35:06 1999 Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8FNWqI03707 for ipng-dist; Wed, 15 Sep 1999 16:32:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8FNWf003700 for ; Wed, 15 Sep 1999 16:32:41 -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 QAA442571; Wed, 15 Sep 1999 16:32:40 -0700 (PDT) Date: Wed, 15 Sep 1999 16:30:19 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" To: Peter Tattam Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My proposal goes thus. > > 1. Keep the existing CIDR allocation exactly as it is. (not the routing > policy, this is dealt with later). > > 2. sacrifice one bit of the flow label to define a routing label. This would > leave 31 bits available for a routing ID. NIT: the flow label is 20 bits - not 32. (4 bits version, 8 bits traffic class, 20 bits flow label). But one of the fundamental issues is that you only propose a routing label for the destination. This implies: - non-site routers that need to send ICMP errors (e.g. for path mtu discovery or just regular unreachable messages) do not know the source routing label. Are they supposed to do a DNS lookup to somehow determine this? - the destination doesn't know the source routing label. This implies that either the stack (TCP before returning the SYN|ACK) or the (UDP) applications need to do some magic DNS lookup to map from the source IP address to the source routing label. I'm sure this can be done. But if nothing else it introduces a new class of denial of service attacks. For instance you can send UDP packets with bogus IP source addresses to the IKE/isakmp port and tie up some amount of resources waiting for the DNS lookup to time out. IMHO as long as we have a datagram model we need to have both a source and destination "routing label" in the packet. Once you have that there are the issues about the security implications of using the source routing label for return traffic as outlined in draft-ietf-ipngwg-esd-analysis-04.txt. Some people argue that those issues can be removed if we require IPsec (AH or ESP) on all IP packets. > 3. Use sparingly those 31 bits for a heiarchical routing tree. > > 4a. Have an extension to the DNS system which defines the *current* mapping > of the hostname to routing ID. It is a host's responsibilty to place the > correct routing ID in the packet prior to transmission. This is no > different in security level to existing DNS practice. The DNS would need > interaction to reflect the dynamic nature of routing cloud changes. DDNS is > I believe suitable for this purpose. How would the host know to ask the DNS for a new routing label? Are you assuming ICMP unreachable messages will trigger this? What if unreachables are discarded as is done in many IPv4 firewalls today? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 15 18:50:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.9.1) id d8G1oCv00433 for ipng-dist; Wed, 15 Sep 1999 18:50:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id SAA00426 for ; Wed, 15 Sep 1999 18:50: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 SAA24477 for ; Wed, 15 Sep 1999 18:04:58 -0700 (PDT) Received: from null0.qual.net (209-128-81-085.bayarea.net [209.128.81.85] (may be forged)) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA08012 for ; Wed, 15 Sep 1999 18:04:57 -0700 (PDT) Received: from localhost (brad@localhost) by null0.qual.net (8.9.1/8.9.1) with ESMTP id BAA04886; Thu, 16 Sep 1999 01:04:51 GMT (envelope-from brad@qual.net) X-Authentication-Warning: null0.qual.net: brad owned process doing -bs Date: Thu, 16 Sep 1999 01:04:50 +0000 (GMT) From: Bradley Reynolds To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <3.0.5.32.19990915173736.00ad4250@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Nor does anything in IPv6. We have an IPv6 addressing allocation plan that > facilitates route aggregation (IMHO better than IPv4 today). If a provider > chooses to not aggregate and advertise /64 routes (or even /128) there is > nothing to stop them. Just like IPv4. > so then why this big debate and address architecture drafting if multihoming can work just as well in ipv6 as it does in ipv4. just allocate blocks to regional registries who can then dole out addresses. no structure other than that. isps aggregate however they see fit. advertise your /64 out transit provider A and transit provider B and you are finished. > I would love to have an internet routing system that does not need > aggregation in order to scale. However, given the growth we expect to > see in the near future, I don't see that happening soon. Route > aggregation is the best tool we have today to keep the internet > routing system working. > i am not arguing against aggregation. just let the ISPs do it. they have a vested interest in not melting the core. BR -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 18:53:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.9.1) id d8G1ruV00487 for ipng-dist; Wed, 15 Sep 1999 18:53:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id SAA00476 for ; Wed, 15 Sep 1999 18:53:47 -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 RAA20623 for ; Wed, 15 Sep 1999 17:40:32 -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 SAA18533 for ; Wed, 15 Sep 1999 18:40:32 -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 RAA07879; Wed, 15 Sep 1999 17:39:24 -0700 (PDT) Message-Id: <3.0.5.32.19990915173736.00ad4250@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 15 Sep 1999 17:37:36 -0700 To: Bradley Reynolds From: Bob Hinden Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <37E01DF7.C7279BFE@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I find this pretty rich, being addressed to one of the authors >> of the CIDR proposal that saved the Internet routing tables >> from exponential growth a few years ago. IPv4 has survived >> only because of exactly such a restriction. >> >how many times do i have to explain that it does not MANDATE >aggregation. you are free to deaggregate. Nor does anything in IPv6. We have an IPv6 addressing allocation plan that facilitates route aggregation (IMHO better than IPv4 today). If a provider chooses to not aggregate and advertise /64 routes (or even /128) there is nothing to stop them. Just like IPv4. We are working to ensure that route aggregation works well (via good assignment plans, multiple prefix multihoming, renumbering, etc.), but just like IPv4 there no mechanism or law that requires providers to do any route aggregation. They do it because it keeps the internet routing system working. I would love to have an internet routing system that does not need aggregation in order to scale. However, given the growth we expect to see in the near future, I don't see that happening soon. Route aggregation is the best tool we have today to keep the internet routing system working. 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 Wed Sep 15 23:32:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8G6PI211158 for ipng-dist; Wed, 15 Sep 1999 23:25:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8G6P6K11151 for ; Wed, 15 Sep 1999 23:25:06 -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 XAA06670 for ; Wed, 15 Sep 1999 23:25:06 -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 XAA25963 for ; Wed, 15 Sep 1999 23:25: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 PAA08171 for ; Thu, 16 Sep 1999 15:24:57 +0900 (JST) To: ipng@sunroof.eng.sun.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: Tokyo interim meeting: Japan activities session From: itojun@iijlab.net Date: Thu, 16 Sep 1999 15:24:56 +0900 Message-ID: <8169.937463096@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, we'll be having "Japan activities session" on 3rd day of Tokyo ipngwg interim meeting (PM of Oct 1, 1999). The session is optional as some of you may fly back on the day, however, this should be *really* exciting and encouraging, so I would suggest you to reschedule your flight :-) Attached please find a tentative agenda. If you want to get a slot, want a reorder of talk, or something else, Please contact me before Sep 22. Since we need to reclaim the room by 17:00 I will be able to accomodate only couple more talk. itojun Oct 1 1999 AM: ipngwg meeting Lunch: optional (under negotiation - payment on your own) 13:30-: Japan activities session - KAME (TBD) - Hitachi (Munechika Sumikawa, sumikawa@kame.net) - IIJ IPv6 trial service (Jun-ichiro itojun Hagino, itojun@iijlab.net) - WIDE 6bone (Kengo Nagahashi, kenken@wide.ad.jp) - Report from JANOG IPv6 stack install convention (HEO SeonMeyong, seirios@Matrix.iri.co.jp) - TAHI IPv6 conformance test (Hiroshi Miyata, miyata@ydc.co.jp) I expect to have 15min (10min presentation + 5min questions) per topic, but is subject to change based on # of talks. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 01:28:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8G8P7j11252 for ipng-dist; Thu, 16 Sep 1999 01:25:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8G8OwK11245 for ; Thu, 16 Sep 1999 01:24:58 -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 BAA13296; Thu, 16 Sep 1999 01:24:57 -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 CAA28578; Thu, 16 Sep 1999 02:24:55 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id SAA07744; Thu, 16 Sep 1999 18:24:53 +1000 (EST) Date: Thu, 16 Sep 1999 18:24:53 +1000 (EST) From: Peter Tattam To: Erik Nordmark cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" 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 Thank you for giving it the time. My answers interspersed. On Wed, 15 Sep 1999, Erik Nordmark wrote: > > > My proposal goes thus. > > > > 1. Keep the existing CIDR allocation exactly as it is. (not the routing > > policy, this is dealt with later). > > > > 2. sacrifice one bit of the flow label to define a routing label. This would > > leave 31 bits available for a routing ID. > > NIT: the flow label is 20 bits - not 32. > (4 bits version, 8 bits traffic class, 20 bits flow label). Oops. Sorry about that. The idea remains essentially the same. 19 bits is still possible given aggressive conservation of bits, and also given that the A-S number is currently still being kept artificially at 16 bits. At the expense of losing routing heirachy, the A-S number could be encoded here, but I have not yet considered this. A few months ago I also scratchpadded a binary tree style of dynamic address aggregation management which could be used to get the most efficient use of bits. A later I-D also proposed something there too. As the basic idea is to keep core routing tables relatively bounded, I think it would still pass the test. As it is a scarce resource, it would be subject to economic explotiation if not regulated correctly. A-S numbers have escaped so far, but this could not be guarenteed in the future. > > But one of the fundamental issues is that you only propose a routing > label for the destination. This implies: > - non-site routers that need to send ICMP errors (e.g. for path mtu discovery > or just regular unreachable messages) do not know the source routing > label. Are they supposed to do a DNS lookup to somehow determine this? > - the destination doesn't know the source routing label. This implies that > either the stack (TCP before returning the SYN|ACK) or the (UDP) > applications > need to do some magic DNS lookup to map from the source IP address to > the source routing label. I'm sure this can be done. But if nothing else > it introduces a new class of denial of service attacks. > For instance you can send UDP packets with bogus IP source addresses > to the IKE/isakmp port and tie up some amount of resources waiting > for the DNS lookup to time out. True... might I be permitted to change references of "DNS" to "Router Label Lookup Protocol" for the continued purpose of this discussion. I also neglected to consider lookups based on address rather than name, but the concept remains virtually the same. If we need two addresses, then we would have to a) steal bits from somewhere else, b) extend the header or c) use option headers?. Neither of these is desirable.. a) steal bits from the addresses... breaks TCP/UDP checksum model. b) not possible because that would have far too wide reaching implications. c) possible, but adds extra bulk. A thought occurs to me that one would then also lose the benefit of the dynamic updates necessary to support multihoming if this happened. The RLLP would need to be designed in such a way that a) it only works on a restricted part of the IPv6 address, and b) returns a undefined answer rapidly. To do this would probably require caching substantial parts of routing map tree, but since we are talking non-router technology, this might scale better with technology advances. > > IMHO as long as we have a datagram model we need to have both a source > and destination "routing label" in the packet. Granted for the reasons you outlined. > > Once you have that there are the issues about the security implications > of using the source routing label for return traffic as outlined in > draft-ietf-ipngwg-esd-analysis-04.txt. > Some people argue that those issues can be removed if we require IPsec > (AH or ESP) on all IP packets. The message I am getting is that anything that separates end point indentifiers from routing identifiers will always have security implications like hijacking and man in the middle attacks. Is this axiomatic? > > > 3. Use sparingly those 31 bits for a heiarchical routing tree. > > > > 4a. Have an extension to the DNS system which defines the *current* mapping > > of the hostname to routing ID. It is a host's responsibilty to place the > > correct routing ID in the packet prior to transmission. This is no > > different in security level to existing DNS practice. The DNS would need > > interaction to reflect the dynamic nature of routing cloud changes. DDNS is > > I believe suitable for this purpose. > > How would the host know to ask the DNS for a new routing label? > Are you assuming ICMP unreachable messages will trigger this? > What if unreachables are discarded as is done in many IPv4 firewalls today? Very good point. It could be solved by mandating that the routing cloud honour these unreachable messages and doing the lookups at the edge of the clouds rather than the hosts. This would then degenerate to the classic route labelling solutions which have already been discussed. Doing lookups at the edges also solve the need for srce & dest routing labels. However I would have to concede that it would be too expensive to do this lookup for each packet. It is convenient to push this load back to the hosts & DNS-like servers for this very reason. I can't help thinking that a similar issue also might affect source address selection procedures. Is this the case? > > 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 > -------------------------------------------------------------------- > As the fundamental objection to route labelling ideas centres on security aspects, I will probably not pursue this area of research much further, and rather focus on ways to make the aggregated multihomed solution work for long lived TCP/UDP sessions. However, I believe that such solutions will fail the security tests without manadatory AH/ESP to manage it. Thanks for your thoughts. 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 Sep 16 04:04:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GB0Mb11617 for ipng-dist; Thu, 16 Sep 1999 04:00:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GB09K11610 for ; Thu, 16 Sep 1999 04:00: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 EAA18932 for ; Thu, 16 Sep 1999 04:00: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 EAA23610 for ; Thu, 16 Sep 1999 04:00: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 HAA08789; Thu, 16 Sep 1999 07:00:05 -0400 (EDT) Message-Id: <199909161100.HAA08789@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-multi-isp-00.txt Date: Thu, 16 Sep 1999 07:00:04 -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 : Multihomed routing domain issues for IPv6 aggregatable scheme Author(s) : F. Dupont Filename : draft-ietf-ipngwg-multi-isp-00.txt Pages : 13 Date : 15-Sep-99 This document exposes some issues for multihomed routing domains using the aggregatable addressing and routing scheme. A routing domain is multihomed when it uses two or more providers of the upper level. Most of these issues are not specific to IPv6 but are consequences of the addressing and routing scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-multi-isp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-multi-isp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-multi-isp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990915101332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-multi-isp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-multi-isp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990915101332.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 Sep 16 08:27:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GFNai11750 for ipng-dist; Thu, 16 Sep 1999 08:23:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GFNQK11743 for ; Thu, 16 Sep 1999 08:23: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 IAA00921 for ; Thu, 16 Sep 1999 08:23:27 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05958 for ; Thu, 16 Sep 1999 08:23:26 -0700 (PDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id LAA23300; Thu, 16 Sep 1999 11:23:19 -0400 (EDT) Message-Id: <199909161523.LAA23300@cannes.aa.ans.net> To: black@layer8.net cc: ipng@sunroof.eng.sun.com, jyy@ans.net Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Date: Thu, 16 Sep 1999 11:23:19 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Do you have any suggestion of maitaining the scaling of the global >> routing table but not by imposing the restrict aggregation? If not, >> we still have to work under the assumption. >> > >Yes, realize that the routing table has sustained linear growth, while >computing power has increased exponentially. This argues for using >existing aggregation and multihoming mechanisms. Six years ago when we developing CIDR for IPv4, many folks did not think route aggregation was needed at all. Their argument was that memory was cheap and computing power was increasing fast. I am not sure if there are still people think that CIDR was not needed for IPv4 now. The need for mandatory aggregation for IPv6 could well be a different story. I think it's a good topic to debate on the list and as a separate topic from SMPL. Again SMPL is working under the assumption. So if we want to continue this thread, let's discuss under the mandatory aggregation assumption. If the result is that mandatory aggregation is not needed for IPv6, then SMPL is not needed at all and I'd be happy to put it to rest. >> >Unfortunately, the fundamental assumptions regarding the purposes of >> >multihoming lead the author of the document astray. The main goals >> >of multihoming are: redundancy in the face of link and/or network >> >failure, load balancing, and performance improvement. Of these, only >> >load balancing is directly addressed, and even then with limited >> >success. Similarly, although improving performance by connecting >> >directly to networks which are common destinations is effective, the >> >document does not provide options for accessing content providers >> >accessible through other networks. >> >> I'd argue that the realistic goal of multihoming are >> a) Redundancy and b) load sharing. The simple multihoming >> proposal (SMPL) addressed both. >> >> 'performance improvement' you used here is a vague term, >> redundancy and load sharing are performance improvement. >> If you mean the improve throughput or goodput of the traffic >> from/to a multihomed site, this is not a realistic goal to >> achieve via multihoming. >> > >Nonsense. If I am sending a large amount of traffic to ISP-A, but I only >have connectivity to ISP-B and ISP-B has poor connectivity to ISP-A, then >adding connectivity directly to ISP-A will improve the performance, as >measured by such factors as latency, packet loss, etc. If this is what you mean, then SMPL allows that. With SMPL, customer will using its direct link to send traffic to destinations directly connected to its ISPs. Look at the picture below, Customer-A will send traffic to customers of ISP-2 using link-2 and that of ISP-1 using link-1. Again, please read the proposal carefully. If you expect an ISP which Customer-A has no direct connection with to send traffic to customer-A according to the path dictate by customer-A, then it's unrealistic. >> >A selection of quotes from the document will help in clarifying its >> >shortcomings as a solution to multihoming within the existing, >> >documented IPv6 routing framework. >> >> >From section 2 (Proposal): >> >> > ISP-3 ---- ISP-4 >> > | / | >> > | / | >> > | / | >> > ISP-1 ---- ISP-2 >> > link-1 \ / link-2 >> > Customer-A >> >> > A multi-homed customer will designate a primary ISP and receive IP >> > address from its primary ISP's IPv6 aggregation block. In this >> > example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A >> > to the customer. Customer-A will advertise addr-1-A to ISP-1 and >> > ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to >> > ISP-1 only. ISP-1 will, of course, advertise its own aggregation >> > Addr-1 to the entire Internet. >> >> >It is clear from this description that the only redundancy provided >> >with this solution is for the customer links (link-1 and link-2) and >> >not for the ISPs themselves. Specifically, if ISP-1 suffers from a >> >failure within the POP to which link-1 terminates, whether as an >> >isolated failure or a more extensive failure within ISP-1, then >> >Customer-A is no longer able to maintain connectivity despite their >> >possession of a perfectly good alternate path through ISP-2. From an >> >engineering perspective, no robustness has been gained through this >> >multihoming which could not be gained more simply with multiple links >> >to ISP-1. >> >> This is not correct. If the POP to which link-1 connects goes >> down, the connectivity to Customer-A will still remain and >> link-2 will be used. >> >> This is because even the POP is down, ISP-1 will still >> advertising Addr-1 which including the address of Customer-A >> to the Internet (ISP-1 will still advertise its block). So >> traffic destinted to Customer-A will still be sent to ISP-1. >> Since ISP-2 advertises the specific address of Customer-A to >> ISP-1, so ISP-1 will just forward the traffic to ISP-2 which >> will further forward traffic to Customer-A vis link-2. >> > >Your eggs are still all in the ISP-1 basket. Even the best ISPs have >wide-scale failures. Your later assertion that this is reasonable >and acceptable is contrary to the redundancy goals you agreed with >for multihoming. Ok, so looks like we agree that a pop failure should not affect the connectivity of the multihoming site. Now, you are talking about the connectivity of the multihoming site will be affected if ISP-1 has a massive failure. In order for customer-A complete lost connection, ISP-1 will have to lost all its mutliple internet connections at the same time, since as long as ISP-1 has external connection, the aggregated routes including Customer-A's block will be advertised to the Internet and the connectivity for customer-A will still be there, which is very very rare. Even for a good quality ISP to lost half of its external connections at the same time is very rare. The risk won't be higher than the current multihomed site with failure to both links to its directly connected ISPs at the same time. So this certainly not introduce less redundancy that a multihoming site has today. This is also documented in my draft, chosing a good quality of primary ISP is strongly recommended. >> >> >> >From section 2 (Proposal): >> >> > For inbound traffic to Customer-A, traffic will first be forwarded to >> > ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will >> > then forward the traffic destined to Customer-A via its connection to >> > ISP-2 and/or its direct link to customer-A, according to certain >> > polices. Most common policy would be the use of the shortest exit. By >> > using both connections to forward traffic to Customer-A, load sharing >> > is achieved. >> >> >From this statement it is unclear exactly how inbound load balancing >> >is to be achieved. Is the author suggesting use of the (rather >> >troublesome) concept of eBGP multipath? In the topology described in >> >the diagram above, implementation of a load sharing mechanism across >> >link-1 and link-2 would be a decidedly non-trivial matter. Again, >> >given the lack of redundancy outlined above, it would be far more >> >efficient for Customer-A to simply purchase multiple links to ISP-1. >> >> No, I am not suggesting the use of eBGP multipath. The method >> is the same as the common mechanism used by ISPs today to deal >> with forwarding traffic to routes learned from multiple network >> points i.e. to use IGP metric to find the closest exit to forward >> the traffic. It could use to ISP-2 or could use its direct link >> to Customer-A. >> > >Why would there be more than route to the destination in ISP-1s IGP? ISP-1 >would pick the *single* best path in BGP and use that *single* path when >sending traffic to the customer. Are you suggesting that the IGP would >see multiple paths to the same destination even though BGP only saw one? >Or are you suggesting that BGP would carry multiple routes to the same >destination? BGP routes of Customer-A's block will be learned by ISP-1 from both connections (ISP-2 and Customer-A), BGP routes are with same local_pref,etc. so the next tier of BGP route selection comes down to IGP metric within the ISP-1 network. The lower IGP metric won and the traffic will be send to that exit point. That's called shortest out routing. >>> I assumed that the reader would be familiar with the mechanism >>> since it's so commonly used. But maybe I can not assume this >>> and in next revision, I should put more details to explain it. >>> >> >Additionally, Customer-A must now depend heavily on the connectivity >> >between ISP-1 and ISP-2. Often, links to multiple providers are >> >purchased specifically to avoid traffic crossing these (often >> >congested) peerings. >> >> Unless the traffic are sourced and destined within the multihoming >> site and its directly connected ISPs (e.g. from customer-A to src/dst >> behind ISP-1 or ISP-2), the traffic has to go through links between >> ISPs. This is the case today. >> >Except that today if there is poor connectivity between a pair of given ISPs >the result is that you have poor reachability to one of those ISPs. In the >configuration you describe, the result is poor *global* reachability in >the case of failure of a *single* ISP. No, you still did not get it. As a multihome site, you have no way of dictating what path the incomming traffic will take. So your traffic may well be sent to the 'bad path' regardless. It's all depends on the policy of the ISP and those ISP could be far far away from you and have no interests of taking care of your concern since you do not pay them directly. >> Even without the SMPL, in today's network, a multihomed site >> just can not dictate how the traffic goes back to it. It's >> all depends a other ISPs' routing policy. Looks at the >> picture, even not using the SMPL, it does not gaurantee >> that ISP4 will use ISP-2 to send traffic to customer-A, >> it may well be sending the traffic via its link to ISP-1. >> > >The point is that *both* of the paths to the customer are *usable*. In >the current system of multihoming, if ISP-1 failed, all traffic would >flow through ISP-2. The issue is now how well the customer can control >reachability to their own network, but whether there is reachability at >all in the case of upstream failure. Are you talking about the redundancy again? See the discussion to this topic above. >> I also think it's wrong to assume that the links between >> ISPs are by default congested. It was more so the case when >> all ISPs exchange traffic at NAPs (i.e. Public exchange point). >> There are a lot of private links between ISPs at multiple >> locations and the situation is different now. >> > >No, the situation is not different now. Private peerings are quite often >congested and neither ISP involved in a private peering has any reason >to change that. That's simple not true. I worked on ANSNET's private peering and now we are part of UUNET. In the case of both ISPs, a great effort has been made to create private peering at many locations and to add bandwidth to improve performance there. Also, since I worked with many other ISPs to create private peering, I can say they are equally care for private peering to work well. May I ask which ISP do you work for? I hope you speaking for your own experience not just speculation. >> >From Section 4 (Concerns): >> >> > - The primary ISP of a multihoming customer (such as ISP-1 in the >> > example) would need to do more work in terms of distributing the >> > traffic among other connected ISPs and the customer link. This >> > can be done using BGP policy (BGP community) and using shortest >> > exit. It will also carry more traffic for the customer. However, >> > this is a value added service to the customer and the primary ISP >> > can charge more fees for such services. >> >> >Stating that the primary ISP "would need to do more work" is putting >> >the problem a bit lightly. The addition of references to BGP policies >> >and BGP communities does little to clarify how exactly the author >> >believes traffic could effectively be distributed. >> >> Again, these are common practice which are already in place. >> I should not have assumed the everyone would familiar with >> it. I will give more detailed explanation to it. >> > >Please do. >> >> >From Section 4 (Concerns): >> >> > - The primary ISP is the sole interface for the multihomed >> > customer to the Internet other than the ISPs the customer has >> > directly connection with. Outages such as one between ISP-1 and >> > ISP-4 would impact the reachability from customers of ISP-4 to >> > Customer-A even though ISP-2 still has good connection to ISP-4. >> > However, if the primary ISP is a good quality ISP, this sort of >> > situation should happen rarely. The reason is that it's common >> > practice that an ISP, especially good quality ISP, has multiple >> > connections to other big ISPs at different geographical locations. >> > Good quality ISPs also have robust network design to prevent any >> > failure to impact the whole network. Choosing a good quality and >> > robust ISP as primary ISP is a good practice. >> >> >This is really the crux of the problem with the solution put forth in >> >the document. The assumption that a given ISP will never have >> >failures, or that rare failures are acceptable to customers who >> >multihomed for redundancy, is simply not valid from an engineering >> >perspective. If the primary goal of multihoming were load sharing, >> >this solution would provide one, potentially very complicated, >> >answer. However, the issue of multihoming for redundancy is totally >> >ignored, drawing into question the need for a second ISP in the >> >equation at all. Why not simply purchase additional bandwidth from >> >the same ISP? >> >> Since noboday can gaurantee absolutely and 100% no outage, >> the measure of 'rarely happen' is really quite a good measure. >> > >But irrelevant since you must rely entirely on a single ISP, despite the >fact that you have more than 1 connection. Again, see the dicussion above. >> Even with today's practice, nobody can ganrantee that the two >> ISPs the multihoming site connecting to, will not go down at the >> same time thus leave the site with no connection. But one >> can say, it rarely happen so we will have two ISP connections instead >> of 3 or 4 or more. >> >Yes, and people do exactly that. But using the technique described in >your draft, adding those additional ISPs would provide no benefit. For this type of company, which is in minority, may deserve other treatment. >> Also, if the alternatives to SMPL is to have multiple address >> assigned to all my hosts (could hundread thousands) or complcated >> tunnels,etc. My feeling (based on my network operationa and engieering >> experience) the chances of my connectivity will be impacted due >> operation error, misconfigurations, etc. woulud be much more high >> than use of SMPL. >> >My feeling, also based on my network operations and engineering experience, >is that I would rather rely on a slightly more complicated configuration >which allows arbitrary increases in connectivity to provide additional >redundancy than on a system that is "simple" but allows almost no >redundancy and absolutely no scaling. You are welcome to propose something which are just slightly more complicated. This proposal has to address managibility to the satisfaction of ISPs who will potentially have to manage hundreds if not thousands of such connections. If it fails on this, then it'd be hard to convince ISPs to deploy it. > >> >From Section 4 (Concerns): >> >> > It is desirable to have solution which provides perfect redundancy >> > and, at the same time, simplicity to scale management and operation. >> > In the absence of a perfect solution, the trade-off needs to be made. >> > The author believes that it is very important that the solution has >> > to be simple and manageable. Manageability should be the top >> > consideration. >> >> >If manageability of the solution is to be the top consideration, the >> >response put forward does not measure up. In the name of avoiding >> >routing table growth the author has suggested adding significant >> >complexity to the configuration and management of multihomed customers >> >without showing any benefit for the effort. >> >> As mentioned above, the routing aggregation is a given >> contrain that this proposal works under. The simplicity >> I am mentioned here is more in compare of other proposals >> in terms of complicated tunnel and mulit addressing for >> every single host in a multihoming site. Compare to >> that, this proposal is highly scalable and managable. >> >You are half right. Do you mind to explain? >> >An area not addressed at all in the document is that of multihoming >> >for access to networks attached to a given ISP, rather than access to >> >that ISP. For example, using the diagram above, if Customer-A >> >purchased connectivity to ISP-2 because ISP-2 had better connectivity >> >to ISP-4, then the offered multihoming solution is of no use. ISP-4 >> >will never see reachability to Customer-A via ISP-2. >> >> Again, as mentioned above, even without the SMPL, in today's >> network, a multihomed site just can not dictate how the traffic >> goes back to it. It's all depends a other ISPs' routing policy. >> ISP-4 may well have the policy of sending traffic to ISP-1 >> instead of using its link of ISP-2. There are many reasons which >> led ISP-4 do that. In short, ISP-4 will look into the interets >> of itself rather Customer-A's interests, especially Customer-A >> is not even directly pay for ISP-4. >> > >Yes, but ISP-4 will *never* send traffic *directly* to ISP-2 even though >there is connectivity to the customer via ISP-2. Even if ISP-4 loses >connectivity to ISP-1. >> If someone expects the incomming traffic will take the path it >> wished, then he or she needs to be more realistic. Likewise, >> one should not ask a multihoming proposal address this. >> > >No, I expect a multihoming proposal to provide a realistic level of >redundancy. SMPL does not meet this requirement. I think SMPL provide a reasonable and realistic level of redundancy. Again, see the redundancy discussion above. >> >The primary lesson of the draft proposal is that the proposed, forced >> >aggregation hierarchy places sever restrictions upon the engineering >> >of reliable, high poerformance networks. To multihome effectively, a >> >network operator must somehow qualify as a "long-haul provider" or >> >other entity appropriate for allocation of its own address space. In >> >this author's opinion, the current IPv6 addressing architecture >> >creates an environment which provides scalability of the global >> >routing table at the expense of any real hope for redundancy through >> >multihoming. >> > >Solutions which avoid the use of multihoming with a single address > >space are possible and offer more hope for a robust network than those > >currently proposed. > > Looks like you have an issue of the mendetory aggregation for > IPv6. You should raise this to IPv6 WG for this. My proposal > just works under contrain of this assumption. It's not an > endorsement of such restriction. > >I do indeed have an issue with the aggregation policies. However, working >within them, I believe the RFC2260/itojun proposal provides value as >a mechanism for improving reachability for a customer network and SMPL >does not. With the RFC2260/itojun proposal as is, I am not total convinced that it provides managment scalability for ISPs who potentially have to manage hundreds or more of them. I like to be convinced otherwise. >> >> >REFERENCES >> >> > [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An >> > Aggregatable Global Unicast Address Format", RFC 2374, July >> > 1998. >> > >> > [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", >> > RFC 2373, July 1998. >> > >> > [SMPL] Yu, J., "A Simple Solution for IPv6 Multihoming", >> > draft-yu-simple-ipv6multihoming-00.txt, August 1999. >> >> >> >> --Jessica > >- -- > --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 08:42:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GFavZ11780 for ipng-dist; Thu, 16 Sep 1999 08:36:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GFamK11773 for ; Thu, 16 Sep 1999 08:36:48 -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 IAA06199 for ; Thu, 16 Sep 1999 08:36:48 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12168 for ; Thu, 16 Sep 1999 09:36:47 -0600 (MDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id LAA23379; Thu, 16 Sep 1999 11:36:45 -0400 (EDT) Message-Id: <199909161536.LAA23379@cannes.aa.ans.net> To: Bradley Reynolds cc: Jessica Yu , black@layer8.net, ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of "Wed, 15 Sep 1999 15:54:24 EDT." Date: Thu, 16 Sep 1999 11:36:45 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Bradley: I'd like to respond your message point-by-point but I felt that I most of my answer would be similar to the loooong message I responsed to Ben's message that I just sent out. So let me be brief here: a. There is no tunnel whatsoever involved in this proposal. ISP-1 learn specific route of customer-A from ISP-2 and can send traffic destined to Customer-A via its link to ISP-2. NO tunnels. b. In multihome case today, a site can achieve the most is load sharing not load balancing (in terms of inbound traffic since the site just has no control), it can load balancing when sending outbound traffic with or without SMPL. So we talk about load sharing. Shortest out routing achieves load sharing. c. I think whether there should be a manadate aggregation for IPv6 is a good topic itself to discuss on the list. Thanks! --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 09:36:37 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GGVti11836 for ipng-dist; Thu, 16 Sep 1999 09:31:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GGVjK11829 for ; Thu, 16 Sep 1999 09:31:45 -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 JAA518949; Thu, 16 Sep 1999 09:31:43 -0700 (PDT) Date: Thu, 16 Sep 1999 09:29:21 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" To: Peter Tattam Cc: Erik Nordmark , Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The message I am getting is that anything that separates end point > indentifiers from routing identifiers will always have security implications > like hijacking and man in the middle attacks. Is this axiomatic? We definitely have hijacking and man in the middle issues with IPv4 today. The point is that decoupling routing from identification creates a new place that an attacker can take advantage of. I also don't think we fully understand the issues. At some level you can view separate identifiers and locators as packets with a two-element source route (containing the source routing label and the destination routing label in your terminology) and automatic source route reversal. > Very good point. It could be solved by mandating that the routing cloud > honour these unreachable messages and doing the lookups at the edge of the > clouds rather than the hosts. This would then degenerate to the classic > route labelling solutions which have already been discussed. Doing lookups > at the edges also solve the need for srce & dest routing labels. However I > would have to concede that it would be too expensive to do this lookup for > each packet. It is convenient to push this load back to the hosts & > DNS-like servers for this very reason. > > I can't help thinking that a similar issue also might affect source address > selection procedures. Is this the case? I'm not sure what similarity you are referring to. One possible similarity is that when using multihoming to get higher availability there is a tradeoff between the hosts selecting source and destination address (and independently from each other discover what prefixes work) and having the routing fabric detect failed paths. But I don't know if that was what your were thinking about. > As the fundamental objection to route labelling ideas centres on security > aspects, I will probably not pursue this area of research much further, and > rather focus on ways to make the aggregated multihomed solution work for > long lived TCP/UDP sessions. However, I believe that such solutions will > fail the security tests without manadatory AH/ESP to manage it. I'd agree that for the general case of session survivability you need authentication during the recovery i.e. when the session switches to using the new addresses. But it appears that when indentifiers and locators are separated the *all* or *most* of the packets need to be authenticated to avoid creating security holes not present in the current architecture. 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 Thu Sep 16 09:57:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GGpXb11866 for ipng-dist; Thu, 16 Sep 1999 09:51:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GGpLK11859 for ; Thu, 16 Sep 1999 09:51:22 -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 JAA20488 for ; Thu, 16 Sep 1999 09:51:21 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17371 for ; Thu, 16 Sep 1999 10:51:20 -0600 (MDT) Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by mail-green.research.att.com (Postfix) with ESMTP id AA47F1E041; Thu, 16 Sep 1999 12:51:19 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id MAA18089; Thu, 16 Sep 1999 12:51:14 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id C0E4541F16; Thu, 16 Sep 1999 12:51:11 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id B1EED400B4; Thu, 16 Sep 1999 12:51:06 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Erik Nordmark Cc: Peter Tattam , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Sep 1999 12:50:56 -0400 Message-Id: <19990916165111.C0E4541F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Erik Nordmark w rites: > I'd agree that for the general case of session survivability you need > authentication during the recovery i.e. when the session switches to using > the new addresses. > But it appears that when indentifiers and locators are separated > the *all* or *most* of the packets need to be authenticated to avoid > creating security holes not present in the current architecture. I mostly agree -- I'd change your note to say that that applies to sessions where you care about the integrity of the data. I'm not convinced that that applies to most http traffic, and that's ~75% of backbone traffic today. Of course, sessions can be hijacked today, on IPv4 -- in fact, I saw a pointer to a canned tool go past on some mailing list just this morning. But there's no doubt that most forms of separate identifier and locator lower the threshhold of difficulty for the attacker. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 10:29:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GHPaS11974 for ipng-dist; Thu, 16 Sep 1999 10:25:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GHPPK11967 for ; Thu, 16 Sep 1999 10:25:25 -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 KAA529436; Thu, 16 Sep 1999 10:25:25 -0700 (PDT) Date: Thu, 16 Sep 1999 10:23:03 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" To: "Steven M. Bellovin" Cc: Erik Nordmark , Peter Tattam , Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <19990916165111.C0E4541F16@SIGABA.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I mostly agree -- I'd change your note to say that that applies to sessions > where you care about the integrity of the data. I'm not convinced that that > applies to most http traffic, and that's ~75% of backbone traffic today. One could envision a future where AH would be also used as a course level filter against DoS attacks. Traffic protected by AH is less likely to be a DoS attack (since the attackers would have provided a certificate which can be used to hunt them down). In such a world a node could be more suspicious (rate limiting things, logging more things, etc) for requests that are not covered by AH or ESP. This would be useful for http as well as other traffic. In addition using AH for http traffic protects TCP i.e. no injected TCP RST packets. So even though it is likely to take a lot longer (if ever) for http to use IPsec I think we need to keep in mind that at some day all traffic might benefit enough from end-end IPsec. 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 Thu Sep 16 10:45:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GHcAN12014 for ipng-dist; Thu, 16 Sep 1999 10:38:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GHc1K12007 for ; Thu, 16 Sep 1999 10:38:01 -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 KAA27053 for ; Thu, 16 Sep 1999 10:38:01 -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 KAA07415 for ; Thu, 16 Sep 1999 10:38:00 -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 KAA10348; Thu, 16 Sep 1999 10:37:19 -0700 (PDT) Message-Id: <3.0.5.32.19990916103530.00a78100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 16 Sep 1999 10:35:30 -0700 To: Bradley Reynolds From: Bob Hinden Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <3.0.5.32.19990915173736.00ad4250@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk BR, >so then why this big debate and address architecture drafting if >multihoming can work just as well in ipv6 as it does in ipv4. just >allocate blocks to regional registries who can then dole out addresses. >no structure other than that. isps aggregate however they see fit. > >advertise your /64 out transit provider A and transit provider B and you >are finished. We want the routing system to scale. If we allow anyone who wants one to get a top level prefix, then we are pretty sure that the routing system will not scale. We are designing for a much larger internet. The core routing tables would be quite large if every one could advertise a /64. 2^^64 is a big number! I would also note that it is a lot easier going from an aggregated system to an non-aggregated, than the other way around. >i am not arguing against aggregation. just let the ISPs do it. they >have a vested interest in not melting the core. Good. We all have a vested interest in not melting the core. 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 Sep 16 11:10:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GI5SN12110 for ipng-dist; Thu, 16 Sep 1999 11:05:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GI5JK12103 for ; Thu, 16 Sep 1999 11:05:19 -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 LAA07409 for ; Thu, 16 Sep 1999 11:05:18 -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 MAA21747 for ; Thu, 16 Sep 1999 12:05:17 -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 TAA43172; Thu, 16 Sep 1999 19:05:13 +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 TAA24836; Thu, 16 Sep 1999 19:05:12 +0100 (BST) Message-ID: <37E10257.F2A25E3A@hursley.ibm.com> Date: Thu, 16 Sep 1999 09:44:39 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Quality Quorum CC: Bradley Reynolds , Jessica Yu , black@layer8.net, ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quality Quorum wrote: > > On Wed, 15 Sep 1999, Brian E Carpenter wrote: > > > Bradley Reynolds wrote: > > > > > > comments below > > > > > > > Do you have any suggestion of maitaining the scaling of the global > > > > routing table but not by imposing the restrict aggregation? If not, > > > > we still have to work under the assumption. > > > > > > > this is not germane to your document, but seems like ipv4 is working > > > fine without such a restriction. > > > > I find this pretty rich, being addressed to one of the authors > > of the CIDR proposal that saved the Internet routing tables > > from exponential growth a few years ago. IPv4 has survived > > only because of exactly such a restriction. > > It does not matter anymore (or it will not matter soon) due to > recent tech advances - Please tell us *exactly* what this means and how it works. 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 Sep 16 12:42:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GJXbs12198 for ipng-dist; Thu, 16 Sep 1999 12:33:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GJX1K12191 for ; Thu, 16 Sep 1999 12:33: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 MAA21456 for ; Thu, 16 Sep 1999 12:33:00 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA02031 for ; Thu, 16 Sep 1999 13:32:59 -0600 (MDT) Received: (qmail 22867 invoked by uid 1001); 16 Sep 1999 19:32:48 -0000 Date: Thu, 16 Sep 1999 12:32:48 -0700 From: Ben Black To: Jessica Yu Cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990916123248.U6617@layer8.net> References: <199909161523.LAA23300@cannes.aa.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199909161523.LAA23300@cannes.aa.ans.net>; from Jessica Yu on Thu, Sep 16, 1999 at 11:23:19AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Sep 16, 1999 at 11:23:19AM -0400, Jessica Yu wrote: > > > >Your eggs are still all in the ISP-1 basket. Even the best ISPs have > >wide-scale failures. Your later assertion that this is reasonable > >and acceptable is contrary to the redundancy goals you agreed with > >for multihoming. > > Ok, so looks like we agree that a pop failure should not > affect the connectivity of the multihoming site. > > Now, you are talking about the connectivity of the multihoming > site will be affected if ISP-1 has a massive failure. In order > for customer-A complete lost connection, ISP-1 will have to lost > all its mutliple internet connections at the same time, since > as long as ISP-1 has external connection, the aggregated routes > including Customer-A's block will be advertised to the Internet > and the connectivity for customer-A will still be there, which > is very very rare. Even for a good quality ISP to lost half > of its external connections at the same time is very rare. The > risk won't be higher than the current multihomed site with > failure to both links to its directly connected ISPs at the same > time. So this certainly not introduce less redundancy that a > multihoming site has today. > > This is also documented in my draft, chosing a good quality of > primary ISP is strongly recommended. > And as documented in my response, one should select a quality ISP no matter what your final connectivity goals. However, since SMPL relies entirely on a *single* ISP for its "redundancy", why not simply connect to the same ISP twice at different POPs? Then there is no special configuration requirement and no need for *any* added complexity. > > > >Why would there be more than route to the destination in ISP-1s IGP? ISP-1 > >would pick the *single* best path in BGP and use that *single* path when > >sending traffic to the customer. Are you suggesting that the IGP would > >see multiple paths to the same destination even though BGP only saw one? > >Or are you suggesting that BGP would carry multiple routes to the same > >destination? > > BGP routes of Customer-A's block will be learned by ISP-1 from both > connections (ISP-2 and Customer-A), BGP routes are with same > local_pref,etc. so the next tier of BGP route selection comes down > to IGP metric within the ISP-1 network. The lower IGP metric won > and the traffic will be send to that exit point. That's called > shortest out routing. > You mean the lower IGP metric that won't ever be used for tie-breaking since the the direct advertisement from the customer will have a shorter AS Path than the advertisement from the second ISP? Or did you have a different metric in mind? > > >Except that today if there is poor connectivity between a pair of given ISPs > >the result is that you have poor reachability to one of those ISPs. In the > >configuration you describe, the result is poor *global* reachability in > >the case of failure of a *single* ISP. > > No, you still did not get it. As a multihome site, you have > no way of dictating what path the incomming traffic will > take. So your traffic may well be sent to the 'bad path' > regardless. It's all depends on the policy of the ISP and > those ISP could be far far away from you and have no interests > of taking care of your concern since you do not pay them > directly. > The issue is not whether you can dictate *which* of the several paths is used for inbound traffic, but whether the multiple paths are even visible to the global network. In both the current IPv4 multihoming system and the RFC2260/ itojun proposal there are multiple visible paths, such that in the case of loss of one of those paths, for whatever reason, there is still reachability. SMPL simply does not provide for redundancy in the case of primary ISP failure. > > > >The point is that *both* of the paths to the customer are *usable*. In > >the current system of multihoming, if ISP-1 failed, all traffic would > >flow through ISP-2. The issue is now how well the customer can control > >reachability to their own network, but whether there is reachability at > >all in the case of upstream failure. > > Are you talking about the redundancy again? See the discussion > to this topic above. > Yes, I am talking about the illusory redundancy in SMPL again. See the discussion of this topic above. > > > >No, the situation is not different now. Private peerings are quite often > >congested and neither ISP involved in a private peering has any reason > >to change that. > > That's simple not true. I worked on ANSNET's private peering and > now we are part of UUNET. In the case of both ISPs, a great > effort has been made to create private peering at many locations > and to add bandwidth to improve performance there. Also, since > I worked with many other ISPs to create private peering, I can say > they are equally care for private peering to work well. > > May I ask which ISP do you work for? I hope you speaking for > your own experience not just speculation. > I am. > >> > >> >This is really the crux of the problem with the solution put forth in > >> >the document. The assumption that a given ISP will never have > >> >failures, or that rare failures are acceptable to customers who > >> >multihomed for redundancy, is simply not valid from an engineering > >> >perspective. If the primary goal of multihoming were load sharing, > >> >this solution would provide one, potentially very complicated, > >> >answer. However, the issue of multihoming for redundancy is totally > >> >ignored, drawing into question the need for a second ISP in the > >> >equation at all. Why not simply purchase additional bandwidth from > >> >the same ISP? > >> > >> Since noboday can gaurantee absolutely and 100% no outage, > >> the measure of 'rarely happen' is really quite a good measure. > >> > > > >But irrelevant since you must rely entirely on a single ISP, despite the > >fact that you have more than 1 connection. > > Again, see the dicussion above. > Please quantify "rarely". Where exactly does it fall in the range between "not bloody likely" and "shyah right!"? > >Yes, and people do exactly that. But using the technique described in > >your draft, adding those additional ISPs would provide no benefit. > > For this type of company, which is in minority, may deserve > other treatment. > So your SMPL proposal is not sufficiently general to handle any but the absolute minimum case with absolutely minimal redundancy, requiring still another solution if an engineer wants more than 2 links and more than "rarely happen" levels of reliability. Why not just have a single solution for all cases? > >> > >> As mentioned above, the routing aggregation is a given > >> contrain that this proposal works under. The simplicity > >> I am mentioned here is more in compare of other proposals > >> in terms of complicated tunnel and mulit addressing for > >> every single host in a multihoming site. Compare to > >> that, this proposal is highly scalable and managable. > >> > > >You are half right. > > Do you mind to explain? > It's manageable. > > >> If someone expects the incomming traffic will take the path it > >> wished, then he or she needs to be more realistic. Likewise, > >> one should not ask a multihoming proposal address this. > >> > > > >No, I expect a multihoming proposal to provide a realistic level of > >redundancy. SMPL does not meet this requirement. > > I think SMPL provide a reasonable and realistic level of redundancy. > Again, see the redundancy discussion above. > It provides very little redundancy and, again, please define "realistic" as the RFC2260/itojun proposal provides significantly higher levels of redundancy and yet still falls short of current practice in IPv4 multi- homing. > > >I do indeed have an issue with the aggregation policies. However, working > >within them, I believe the RFC2260/itojun proposal provides value as > >a mechanism for improving reachability for a customer network and SMPL > >does not. > > With the RFC2260/itojun proposal as is, I am not total convinced > that it provides managment scalability for ISPs who potentially > have to manage hundreds or more of them. I like to be convinced > otherwise. > Given that RFC2260/itojun is the only proposal presented that actually meets the goals of multihoming, I don't understand the need for convincing. -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 13:39:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GKZB912316 for ipng-dist; Thu, 16 Sep 1999 13:35:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GKZ1K12309 for ; Thu, 16 Sep 1999 13:35: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 NAA07048 for ; Thu, 16 Sep 1999 13:35:00 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03587 for ; Thu, 16 Sep 1999 14:34:59 -0600 (MDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id QAA24356; Thu, 16 Sep 1999 16:34:57 -0400 (EDT) Message-Id: <199909162034.QAA24356@cannes.aa.ans.net> To: black@layer8.net cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Date: Thu, 16 Sep 1999 16:34:57 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think with this rounds discussion, many things has been clarified and the remain issue is "Does SMPL provide reasonable redundancy?" For this issue, I have already stated my reason of why it'd provide reasonable redundancy and I do not seem to be able to convince you. I do not wish to continue beating a dead horse but let me ask you a question: In the last 2-3 years, how many times a good quality ISP went complete isolated from the Internet? I do not recall one. Many good quality ISPs are building very redundant physical network to the extend every device is mirrored. Now some ISPs (at least one of them) offer 100% uptime service. If it's not met, a fee will be repaid to the customer. It's more incentive for ISP to have a robust network. No one claims it is a perfect solution. As I am sure you know how hard to have a perfect solution under the contrains of mandatory aggregation and also meet the management scalability. Multihoming to the same ISP with multiple (usually 2) connections as you suggested is certainly a method many multihomed customer use today for IPv4. It helps avoid leaking longer prefix to the Internet and is very much encouraged by ISPs. Some still choose still use different ISPs to multihome with to avoid completely locked in with one ISP and we can understand why they do that. >> With the RFC2260/itojun proposal as is, I am not total convinced >> that it provides managment scalability for ISPs who potentially >> have to manage hundreds or more of them. I like to be convinced >> otherwise. >> > >Given that RFC2260/itojun is the only proposal presented that actually meets >the goals of multihoming, I don't understand the need for convincing. You missed my point. I am saying I am not convinced for it's management scalability. Tunnel in general is a network management nightmare. It's easy to make config mistake and hard to debug. Tunnel between ISPs routers is even scareier. >>- -- >>--b --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 14:07:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GL4Ff12387 for ipng-dist; Thu, 16 Sep 1999 14:04:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GL45K12380 for ; Thu, 16 Sep 1999 14:04: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 OAA15429 for ; Thu, 16 Sep 1999 14:04:04 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA18916 for ; Thu, 16 Sep 1999 15:04:03 -0600 (MDT) Received: (qmail 23509 invoked by uid 1001); 16 Sep 1999 21:04:03 -0000 Date: Thu, 16 Sep 1999 14:04:03 -0700 From: Ben Black To: Jessica Yu Cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990916140403.V6617@layer8.net> References: <199909162034.QAA24356@cannes.aa.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199909162034.QAA24356@cannes.aa.ans.net>; from Jessica Yu on Thu, Sep 16, 1999 at 04:34:57PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Sep 16, 1999 at 04:34:57PM -0400, Jessica Yu wrote: > I think with this rounds discussion, many things has been clarified and > the remain issue is "Does SMPL provide reasonable redundancy?" > > For this issue, I have already stated my reason of why it'd provide > reasonable redundancy and I do not seem to be able to convince you. > I do not wish to continue beating a dead horse but let me ask you > a question: > > In the last 2-3 years, how many times a good quality ISP went complete > isolated from the Internet? I do not recall one. Many good quality ISPs I am not going to name names because I don't think it is appropriate. Given where you work, I would suggest investigating events associated with AS0. Even the very best ISPs, and I definitely include UUNet in that group have catastrophic failures. It happens. One way to enormously reduce the risk of such a single event eliminating all global reachability for a customer is to multihome to multiple ISPs in such a way that total failure of one does not imply total reachability failure for the customer. In the case of SMPL, that single point of failure is inherent and unacceptable. > are building very redundant physical network to the extend every device > is mirrored. Now some ISPs (at least one of them) offer 100% uptime service. > If it's not met, a fee will be repaid to the customer. It's more > incentive for ISP to have a robust network. So a fee is repaid and the company is out all the revenue they would have generated by being up, not to mention the longer term market effects of failures. Justifying the single point of failure in SMPL is not going to make it go away. > > No one claims it is a perfect solution. As I am sure you know how hard > to have a perfect solution under the contrains of mandatory aggregation > and also meet the management scalability. > > Multihoming to the same ISP with multiple (usually 2) connections as > you suggested is certainly a method many multihomed customer use today > for IPv4. It helps avoid leaking longer prefix to the Internet and is > very much encouraged by ISPs. Some still choose still use different > ISPs to multihome with to avoid completely locked in with one ISP and > we can understand why they do that. > > >> With the RFC2260/itojun proposal as is, I am not total convinced > >> that it provides managment scalability for ISPs who potentially > >> have to manage hundreds or more of them. I like to be convinced > >> otherwise. > >> > > > >Given that RFC2260/itojun is the only proposal presented that actually meets > >the goals of multihoming, I don't understand the need for convincing. > > You missed my point. I am saying I am not convinced for it's management > scalability. Tunnel in general is a network management nightmare. It's > easy to make config mistake and hard to debug. Tunnel between ISPs > routers is even scareier. > Tunnels are inferior to simply advertising a single prefix for your network into multiple ISPs. However, the tunnels required in RFC2260/itojun are a necessary evil to accomodate constraints in the IPv6 routing architecture. SMPL may lack tunnels, but it similarly lacks removal of a single point of failure. > >>- -- > >>--b > > --Jessica -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 14:07:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GL2Mq12378 for ipng-dist; Thu, 16 Sep 1999 14:02:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GL2DK12371 for ; Thu, 16 Sep 1999 14:02:13 -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 OAA10705 for ; Thu, 16 Sep 1999 14:02:11 -0700 (PDT) Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA17837 for ; Thu, 16 Sep 1999 15:02:10 -0600 (MDT) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Thu, 16 Sep 1999 22:01:21 +0100 Date: Thu, 16 Sep 1999 22:01:45 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Jessica Yu cc: black@layer8.net, ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <199909162034.QAA24356@cannes.aa.ans.net> 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 Thu, 16 Sep 1999, Jessica Yu wrote: > In the last 2-3 years, how many times a good quality ISP went complete > isolated from the Internet? I do not recall one. That is a meaningless statement, since good-quality ISPs by definition don't have isolation outages. I'm pretty sure an entire redneck US state accidentally got cut off from the rest of the planet for sixteen hours by a backhoe at one point. A more concrete counterexample? http://www.ntk.net/index.cgi?back=archive99/now0226.txt&line=18#l or search www.ntk.net for 'Telehouse'. L. there are still too many chokepoints, and not enough redundant meshing. 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 Thu Sep 16 14:19:10 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GLEjU12429 for ipng-dist; Thu, 16 Sep 1999 14:14:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GLEaK12422 for ; Thu, 16 Sep 1999 14:14: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 OAA14807 for ; Thu, 16 Sep 1999 14:14:35 -0700 (PDT) Received: from iscone.res.sprintlink.net (gate2.sprintlink.net [199.0.233.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA25152 for ; Thu, 16 Sep 1999 15:14:34 -0600 (MDT) Received: from localhost (rrockell@localhost) by iscone.res.sprintlink.net (8.7.3/8.6.12) with SMTP id RAA05259 for ; Thu, 16 Sep 1999 17:14:34 -0400 (EDT) X-Authentication-Warning: iscone.res.sprintlink.net: rrockell owned process doing -bs Date: Thu, 16 Sep 1999 17:14:33 -0400 (EDT) From: "Robert J. Rockell" X-Sender: rrockell@iscone To: ipng@sunroof.eng.sun.com Subject: Re: a response to the response regarding "A Simple Solution for IPv6 Multihoming" In-Reply-To: <19990914114356.H6617@layer8.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Not directly aimed at the last response, more generally to the thread as a whole. Let me apologize for the brain fart that assumed that 2260, 5.1 is what we was referred to as the part of the RFC that seems promising. I'll be the first to admit that I am not on the "in crowd" on this lately. However, I fear that 5.2, while technically feasible, will be a major work-around, rather than a solution. How many of you would build a tunnel through one provider, over the MAE, to another provider, to that other provider's border router, for failure. The reason more people are multi-homed these days has to DO with the peering points, as much as for redundancy. I worry that, while this solution presents an alternative, is not necessarily a viable one. I am not trying to insight any philosophies on peering, or the motivation for why we multi-home. I do want to make the point that the solution that IPv6 comes up with that we adopt has to: 1. work as good as today, or people won't buy it.(this is IMPORTANT). 2. be easy, so administrator's can comprehend it. While I will buy that we have #2 here, I don't know that we are quite there with #1. I also do not mean to defend the "simple" solution when it appears that most people have already cast it off, but I do see some form of #1 here, argueably more or less than that of the 2260, or any 2260-based, approaches. I have read the threads up to the current, and reply to this, simply to extend this trhead, and not to say that I haven't read the new points regarding ISP isolation. Again, I think that ISP isolation, as the point made below, is very rare. Furtehrmore, ISP isolaion, with tunnel-based appraches, would have the same effect... If the world can't see it, you can't see it, so I don't see how the aggreation via the "simple solution" or the tunnel-based solution have a different set of constraints. You still have to get to your other provider (through a tunnel or natively) somehow. Scalability: This one, I would argue both have problems. The "simple solution" pushes the scalability problems back to the providers, in that they would need to learn to use communities, etc, to filter routes to certain people. While a pain to implement with most current policy based routing implementations, I don't know that this is undoable. It was mentioned that 3 or more providers would be a problem, as complexity increases non-linearly with number of providers per downstream increases. That just means you have N statements in your route-map (apologies for being cisco-centric in my syntax). As policy implementations get better, I can see this being easy to implement. if x : tag AS:x if y : tag AS:y if z : tag AS:z at Z's peering, community-filter permit AS:z permit deny any Not the easiest thing, but since this is important stuff, I like the bulk of the responsibility being on the providers (they ARE the ones who suffer when it all breaks, after all). The tunnelled solutions (all of them) push the scalability back to the downstream which is multi-homed. As a provider, we are filtering the heck out of downstreams anyways... Now we just make their work harder. >From a business standpoint (which we have to think about) customers generally want everything possible done for them. That is why they pay a LOT of money for Internet service. I would tend to favor pushing the scalability problems back towards the people who are equipped to handle them (providers). Again, sorry for the confusion earlier. Thanks Rob Rockell Sprintlink Internet Service Center Operations Engineering 703-689-6322 1-800-724-3329, PIN 385-8833 Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne? On Tue, 14 Sep 1999, Ben Black wrote: ->Just to set our terms up front: -> -> The "simple solution" is Jessica Yu's draft. -> The "complex solution" RFC2260/itojun proposal. -> ->Since I don't believe Yu's draft actually solves any problems, I don't ->really agree with these definitions, but they will allow less confusion ->about which draft I mean below. -> ->On Tue, Sep 14, 1999 at 12:10:56PM -0400, Robert J. Rockell wrote: ->> I'll be the first to admit that the "simple solution" is one that has some ->> policy to work out, but I want to point out that it does add to the otehr ->> proposed solutions. ->> ->> RFC2260 has two management holes that may be big from the operatioal ->> standpoint of a TLA> ->> -> ->[ points 1 and 2 deleted because they are not relevant to the complex solution] -> ->> ->> #3 while RFC2260, section 5.2 attempts to look at this, I think there will be ->> some major design limitations asscociated. (details excluded). ->> -> ->Unfortunately, it is just those excluded details which are relevant here. -> ->> The "simple solution" proposal minimizes the management woes of #1 and #2. ->> It at least sets expectations that a backbone designer can work with, and ->> attempt to implement in a way that is scalable. Although there are ->> management problems with the "simple solution" as well, I think it deserves ->> some sort of trial, perhaps on the 6bone. ->> ->> The possibility of an efficient community-tagging policy is one way that the ->> simple solution can work, and still provide some scalability (though not as ->> much as we all would like, perhaps). ->> ->> Now the problem, with the "simple solution" instead of #1 and #2 above, becomes: ->> ->> -how do we know that the other provider is only announcing this route back ->> to us, and not to everyone, breaking aggregation? ->> -> ->The other problem becomes: -> ->- why am I paying for this second link when I can't send traffic over it if -> my primary ISP fails? -> ->> I would argue that this is less to worry about than above, in that I would ->> put more trust into the BGP policy of a backbone provider than a downstream ->> to aggregate and export the correct routes at the right locations. The ->> problem, however, still remains; management of one's own TLA; ->> it just shifts a bit. ->> ->> ->> In regards to Ben's comments, I would argue that load-balancing is not ->> addressed, but the redundancy is. If the subnet (to use a ->> soon-to-be-outdated-term) of the TLA is announced back to the TLA, ->> redundancy is there with the "simple solution", but the load-balancing ->> becomes problematic. One can no longer use AS padding, for instance, for ->> multi-homing load-balancing. The redundancy is there; the routing just gets ->> messy. If a t-1 goes down, then the packets will go to the other provider, ->> albeit via the primary provider, so long as a peering between the two exists ->> (which in itself is a whole other issue). ->> However, if the whole backbone goes down, then the redundancy would be ->> removed (but if a whole backbone goes down today, we all feel it, regardless ->> of where we home; remember the various "internet drains" that occured over ->> the last couple of years; I won't mention AS numbers). ->> ->> As I haven't seen any implementations of 2260 working, and this one actually ->> is something that can be set up, I would like to test this. If anyone who ->> has 6bone transit woudl be interested in testing, I say we give it a whirl, ->> and see how it scales in the small picture, before we cast it away for the ->> big picture totally. ->> ->> I apologize in advance if these opinions are redundant, or I missed ->> something here, but I am afraid we may be throwing somethign aside which may ->> at the very least provide more insight into how to tackle this most ->> difficult and important problem of the protocol. ->> -> ->A key point you may have missed from the simple solution: -> ->"A multi-homed customer will designate a primary ISP and receive IP ->address from its primary ISP's IPv6 aggregation block." -> ->What this means is that, since the *single* prefix used by the customer can ->only be advertised by the *primary* ISP into the global backbone, if that ISP ->has a failure (AS0, sun spots, fiber cut, whatever), the customer is ->completely unreachable, even though they have a viable, alternate path through ->their secondary ISP. If only they had address space from that ISP. Which ->they do in the complex solution. -> ->This doesn't even begin to address the problem of homing to more than 2 ->providers. -> ->> Also, in regards to how this can be done ( deploy the "simple solution"; I ->> don't know if this is the right place, but I believe it is possible, even ->> with limited implementations of IPv6 that we have, to make this work, if we ->> ignore some scaling problems that aren't there yet on the 6bone). ->> -> ->Sure, you could deploy it, but realize the simple solution is 50% of the ->complex solution. Add a second prefix and a second tunnel and it is ->magically upgraded to a system which actually *can* survive the failure of ->an upstream. -> -> ->Ben -> ->> On Mon, 13 Sep 1999, Brian E Carpenter wrote: ->> ->> ->OK, there is clearly a problem with the way this has been ->> ->written up. Those of us who attended the second design team meeting ->> ->on this before Oslo were, I think, pretty clear that the RFC 2260 ->> ->approach was a required part of the total solution (i.e. in my ->> ->mind at least, the "simple solution" is by no means a ->> ->complete proposal). ->> -> ->> ->Thanks for the clarification ->> -> ->> -> Brian ->> -> ->> ->Ben Black wrote: ->> ->> ->> ->> I think the only viable solution, in the face of the constraints placed ->> ->> on advertisement of IPv6 aggregates, is similar to that proposed in RFC2260 ->> ->> and further detailed for IPv6 by itojun. The "current" proposal is not ->> ->> viable at all, despite some minor similarities with RFC2260. ->> ->> ->> ->> Although it would be rather involved, I can see application of tunnel ->> ->> networks overlayed on a large scale as a solution allowing an ISP to ->> ->> provide backup for another ISP. I don't really think it is attractive ->> ->> because of the significantly higher complexity and administrative ->> ->> overhead compared to RFC2260 and itojun's proposal. ->> ->> ->> ->> Ben ->> ->> ->> ->> On Mon, Sep 13, 1999 at 01:54:08PM -0500, Brian E Carpenter wrote: ->> ->> > Ben, ->> ->> > ->> ->> > I can't see anything in your arguments that suggests any realistic, ->> ->> > deployable alternative to the current proposal, unless you can explain ->> ->> > in concrete detail what this means: ->> ->> > ->> ->> > > Solutions which avoid the use of multihoming with a single address ->> ->> > > space are possible and offer more hope for a robust network than those ->> ->> > > currently proposed. ->> ->> > ->> ->> > Brian ->> ->> > ->> ->> > Ben Black wrote: ->> ->> > > ->> ->> > > I'm not familiar with the workings of the IPng group, so please let me ->> ->> > > know if this violates any procedural or etiquette boundaries. I've ->> ->> > > just finished reading several of the IPv6 drafts and hoped my thoughts ->> ->> > > on one recently submitted draft might be of use. ->> ->> > > ->> ->> > > IPv6 multihoming is a thorny problem and I don't pretend to have a ->> ->> > > solution. I don't know that there is one possible as the network layer. ->> ->> > > ->> ->> > > Ben ->> ->> > > ->> ->> > > -- ->> ->> > > ->> ->> > > The IPv6 address allocation and routing hierarchy defined in [AGGR] ->> ->> > > and [ARCH] poses serious difficulties for implementation of multihomed ->> ->> > > networks. Rather than the usual practice of allocating a single ->> ->> > > prefix, or set of prefixes for multiple networks, network operators ->> ->> > > must either home to a single provider or allocate multiple prefixes ->> ->> > > for the same set of nodes. The draft "A Simple Solution for IPv6 ->> ->> > > Multihoming" [SMPL] profers an approach to achieving multihomed ->> ->> > > networks within the constraints of the IPv6 route aggregation ->> ->> > > hierarchy. ->> ->> > > ->> ->> > > Unfortunately, the fundamental assumptions regarding the purposes of ->> ->> > > multihoming lead the author of the document astray. The main goals ->> ->> > > of multihoming are: redundancy in the face of link and/or network ->> ->> > > failure, load balancing, and performance improvement. Of these, only ->> ->> > > load balancing is directly addressed, and even then with limited ->> ->> > > success. Similarly, although improving performance by connecting ->> ->> > > directly to networks which are common destinations is effective, the ->> ->> > > document does not provide options for accessing content providers ->> ->> > > accessible through other networks. ->> ->> > > ->> ->> > > A selection of quotes from the document will help in clarifying its ->> ->> > > shortcomings as a solution to multihoming within the existing, ->> ->> > > documented IPv6 routing framework. ->> ->> > > ->> ->> > > >From section 2 (Proposal): ->> ->> > > ->> ->> > > ISP-3 ---- ISP-4 ->> ->> > > | / | ->> ->> > > | / | ->> ->> > > | / | ->> ->> > > ISP-1 ---- ISP-2 ->> ->> > > link-1 \ / link-2 ->> ->> > > Customer-A ->> ->> > > ->> ->> > > A multi-homed customer will designate a primary ISP and receive IP ->> ->> > > address from its primary ISP's IPv6 aggregation block. In this ->> ->> > > example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A ->> ->> > > to the customer. Customer-A will advertise addr-1-A to ISP-1 and ->> ->> > > ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to ->> ->> > > ISP-1 only. ISP-1 will, of course, advertise its own aggregation ->> ->> > > Addr-1 to the entire Internet. ->> ->> > > ->> ->> > > It is clear from this description that the only redundancy provided ->> ->> > > with this solution is for the customer links (link-1 and link-2) and ->> ->> > > not for the ISPs themselves. Specifically, if ISP-1 suffers from a ->> ->> > > failure within the POP to which link-1 terminates, whether as an ->> ->> > > isolated failure or a more extensive failure within ISP-1, then ->> ->> > > Customer-A is no longer able to maintain connectivity despite their ->> ->> > > possession of a perfectly good alternate path through ISP-2. From an ->> ->> > > engineering perspective, no robustness has been gained through this ->> ->> > > multihoming which could not be gained more simply with multiple links ->> ->> > > to ISP-1. ->> ->> > > ->> ->> > > >From section 2 (Proposal): ->> ->> > > ->> ->> > > For inbound traffic to Customer-A, traffic will first be forwarded to ->> ->> > > ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will ->> ->> > > then forward the traffic destined to Customer-A via its connection to ->> ->> > > ISP-2 and/or its direct link to customer-A, according to certain ->> ->> > > polices. Most common policy would be the use of the shortest exit. By ->> ->> > > using both connections to forward traffic to Customer-A, load sharing ->> ->> > > is achieved. ->> ->> > > ->> ->> > > >From this statement it is unclear exactly how inbound load balancing ->> ->> > > is to be achieved. Is the author suggesting use of the (rather ->> ->> > > troublesome) concept of eBGP multipath? In the topology described in ->> ->> > > the diagram above, implementation of a load sharing mechanism across ->> ->> > > link-1 and link-2 would be a decidedly non-trivial matter. Again, ->> ->> > > given the lack of redundancy outlined above, it would be far more ->> ->> > > efficient for Customer-A to simply purchase multiple links to ISP-1. ->> ->> > > ->> ->> > > Additionally, Customer-A must now depend heavily on the connectivity ->> ->> > > between ISP-1 and ISP-2. Often, links to multiple providers are ->> ->> > > purchased specifically to avoid traffic crossing these (often ->> ->> > > congested) peerings. ->> ->> > > ->> ->> > > >From Section 4 (Concerns): ->> ->> > > ->> ->> > > - The primary ISP of a multihoming customer (such as ISP-1 in the ->> ->> > > example) would need to do more work in terms of distributing the ->> ->> > > traffic among other connected ISPs and the customer link. This ->> ->> > > can be done using BGP policy (BGP community) and using shortest ->> ->> > > exit. It will also carry more traffic for the customer. However, ->> ->> > > this is a value added service to the customer and the primary ISP ->> ->> > > can charge more fees for such services. ->> ->> > > ->> ->> > > Stating that the primary ISP "would need to do more work" is putting ->> ->> > > the problem a bit lightly. The addition of references to BGP policies ->> ->> > > and BGP communities does little to clarify how exactly the author ->> ->> > > believes traffic could effectively be distributed. ->> ->> > > ->> ->> > > >From Section 4 (Concerns): ->> ->> > > ->> ->> > > - The primary ISP is the sole interface for the multihomed ->> ->> > > customer to the Internet other than the ISPs the customer has ->> ->> > > directly connection with. Outages such as one between ISP-1 and ->> ->> > > ISP-4 would impact the reachability from customers of ISP-4 to ->> ->> > > Customer-A even though ISP-2 still has good connection to ISP-4. ->> ->> > > However, if the primary ISP is a good quality ISP, this sort of ->> ->> > > situation should happen rarely. The reason is that it's common ->> ->> > > practice that an ISP, especially good quality ISP, has multiple ->> ->> > > connections to other big ISPs at different geographical locations. ->> ->> > > Good quality ISPs also have robust network design to prevent any ->> ->> > > failure to impact the whole network. Choosing a good quality and ->> ->> > > robust ISP as primary ISP is a good practice. ->> ->> > > ->> ->> > > This is really the crux of the problem with the solution put forth in ->> ->> > > the document. The assumption that a given ISP will never have ->> ->> > > failures, or that rare failures are acceptable to customers who ->> ->> > > multihomed for redundancy, is simply not valid from an engineering ->> ->> > > perspective. If the primary goal of multihoming were load sharing, ->> ->> > > this solution would provide one, potentially very complicated, ->> ->> > > answer. However, the issue of multihoming for redundancy is totally ->> ->> > > ignored, drawing into question the need for a second ISP in the ->> ->> > > equation at all. Why not simply purchase additional bandwidth from ->> ->> > > the same ISP? ->> ->> > > ->> ->> > > >From Section 4 (Concerns): ->> ->> > > ->> ->> > > It is desirable to have solution which provides perfect redundancy ->> ->> > > and, at the same time, simplicity to scale management and operation. ->> ->> > > In the absence of a perfect solution, the trade-off needs to be made. ->> ->> > > The author believes that it is very important that the solution has ->> ->> > > to be simple and manageable. Manageability should be the top ->> ->> > > consideration. ->> ->> > > ->> ->> > > If manageability of the solution is to be the top consideration, the ->> ->> > > response put forward does not measure up. In the name of avoiding ->> ->> > > routing table growth the author has suggested adding significant ->> ->> > > complexity to the configuration and management of multihomed customers ->> ->> > > without showing any benefit for the effort. ->> ->> > > ->> ->> > > An area not addressed at all in the document is that of multihoming ->> ->> > > for access to networks attached to a given ISP, rather than access to ->> ->> > > that ISP. For example, using the diagram above, if Customer-A ->> ->> > > purchased connectivity to ISP-2 because ISP-2 had better connectivity ->> ->> > > to ISP-4, then the offered multihoming solution is of no use. ISP-4 ->> ->> > > will never see reachability to Customer-A via ISP-2. ->> ->> > > ->> ->> > > The primary lesson of the draft proposal is that the proposed, forced ->> ->> > > aggregation hierarchy places sever restrictions upon the engineering ->> ->> > > of reliable, high poerformance networks. To multihome effectively, a ->> ->> > > network operator must somehow qualify as a "long-haul provider" or ->> ->> > > other entity appropriate for allocation of its own address space. In ->> ->> > > this author's opinion, the current IPv6 addressing architecture ->> ->> > > creates an environment which provides scalability of the global ->> ->> > > routing table at the expense of any real hope for redundancy through ->> ->> > > multihoming. ->> ->> > > ->> ->> > > Solutions which avoid the use of multihoming with a single address ->> ->> > > space are possible and offer more hope for a robust network than those ->> ->> > > currently proposed. ->> ->> > > ->> ->> > > REFERENCES ->> ->> > > ->> ->> > > [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An ->> ->> > > Aggregatable Global Unicast Address Format", RFC 2374, July ->> ->> > > 1998. ->> ->> > > ->> ->> > > [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", ->> ->> > > RFC 2373, July 1998. ->> ->> > > ->> ->> > > [SMPL] Yu, J., "A Simple Solution for IPv6 Multihoming", ->> ->> > > draft-yu-simple-ipv6multihoming-00.txt, August 1999. ->> ->> > > ->> ->> > > -------------------------------------------------------------------- ->> ->> > > IETF IPng Working Group Mailing List ->> ->> > > IPng Home Page: http://playground.sun.com/ipng ->> ->> > > FTP archive: ftp://playground.sun.com/pub/ipng ->> ->> > > Direct all administrative requests to majordomo@sunroof.eng.sun.com ->> ->> > > -------------------------------------------------------------------- ->> ->> ->> ->> -- ->> ->> --b ->> ->-------------------------------------------------------------------- ->> ->IETF IPng Working Group Mailing List ->> ->IPng Home Page: http://playground.sun.com/ipng ->> ->FTP archive: ftp://playground.sun.com/pub/ipng ->> ->Direct all administrative requests to majordomo@sunroof.eng.sun.com ->> ->-------------------------------------------------------------------- ->> -> -> ->-- -> --b -> -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 15:02:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GLvUc12518 for ipng-dist; Thu, 16 Sep 1999 14:57:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GLvJK12511 for ; Thu, 16 Sep 1999 14:57:19 -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 OAA576184; Thu, 16 Sep 1999 14:57:15 -0700 (PDT) Date: Thu, 16 Sep 1999 14:54:54 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) To: Vladislav Yasevich Cc: Erik Nordmark , IPNG Working Group In-Reply-To: "Your message with ID" <37C1A3E5.91C3DB81@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 I'm catching up on old email making sure I have all the 2292bis issues written down. > For the case above the implementation can define a pointer to the addresses > in the routing header and use that pointer to reference all the addresses. > It will get rid of the cast you showed. If we remove the ip6r0_addr field there will still be one case needed in the applications (assuming they don't use the inet6_rth_ functions) to get the pointer to the array of addresses. But I'll go ahead and remove this field. > > Spec already says "By default, this socket option is disabled." > > The option has no meaning for ICMPv6 sockets since they always do their > > checksum. > > > > Could you state that in the spec? Will do. > After a closer look at the option processing, I found that there is an > ambiguity between 2292 and 2292bis. In particular, the ambiguity exists with > IPV6_HOPLIMIT option. With the 2292, this was an 'on/off' options. With > 2292bis sticky options, this now takes the actually hop limit itself. If the > implementaion decides to support both specs, how is it to pick which option > to set (both values are int)? Go point. I'll remove the 2292 compatibility attempt since I haven't heard one voice asking that we keep it. > The problem that we saw with this specification is that it heavily depends > on Appendix B of 2460. In particular that the fields have to be ordered by > size. If someone does not follow this specification then the API as it > stands right now will not be able to calculate allignment function correctly. > For example, considere these 2 options: > > OPT1:(doesn't follow Appendix B) OPT2: > Length = 12 Length = 12 > Data1 = 8 bytes Data1 = 4 bytes > Data2 = 4 bytes Data2 = 4 bytes > Data3 = 4 bytes > > The alignment of the end of both of these options is 4 since the last data > field is only 4 bytes. If that is the case, then when setting up OPT1, the > Data1 field may not be aligned on a natural boundry and may break the > applications and cause > alignment faults. > > If we were to fix OPT1 to follow Appendix B, everything works fine. At a minimum I'll make then spec clearly state this assumption. > There reason we are advocating for 'alignX' and 'alignY' as arguments to the > API is that they will already be defined in the Option Specification and > easily used ('length' will be the 3 argument). If the Option Specification > does not follow Appendix B (it doesn't have to), then this API will still > align the data correctly and conserve as much space as possible (one of the > goals stated in 2460). Are you arguing that there is a benefit in defining options differently than the recommendation in 2460 i.e. that this will save space? That doesn't appear to be the case for a single option in an extension header. If you have multiple options you might save space. Here is what I think is the worst case with 2 options: Imagine OPT1 with two 4 byte fields and one 8 byte field and OPT2 with one 2 byte field and one 8 byte field. The rules state that the layout should be: OPT1 type, len 4 byte field 4 byte field 8 byte field OPT2 type len 2 byte field 8 byte field But if you put them in an extension header you end up with ehdr nexthop, len 4 pad bytes OPT1 4 pad bytes OPT2 But if you allowed OPT1 to be layed out as OPT1 type, len 4 byte field 8 byte field 4 byte field You could handle OPT1 + OPT2 without any padding (saving 8 bytes). But as appendix B in 2260 states the assumption is that there is usually only one option in an extension header. > Yes, I was refering to sticky otions. It looks like you are advocating > caching the options. In you implementation if the user were to set both > IPV6_RTHDRDSTOPTS and IPV6_RTHDR options, and then unset IPV6_RTHDR, you > would still have the IPV6_RTHDRDSTOPTS option set, but will ignore it. Is my > understanding correct? That is what our current implementation does. While I'm not strongly advocating this it is simple to implement and allows the application to set options in any order (i.e. the application can issue a setsockopt for IPV6_RTHDRDSTOPTS before the setsockopt for IPV6_RTHDR). An alternative was suggested by Tim: make IPV6_RTHDRDSTOPTS just specify a second destination header which is sent whether or not there is a routing header. This is as easy to implement as far as I can tell, but it doesn't quite match the IPV6_RTHDRDSTOPTS name. It would make sense to change the name to e.g. IPV6_DSTOPTS2 if we go this path. > > I guess zero is the only too small value that is a multiple of 8. > > Thus it is really" > > If the extlen value is not a positive multiple of 8 the > > function fails and returns -1. > > > > Will this be in the new spec? Yes. 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 Thu Sep 16 15:05:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GM3B012545 for ipng-dist; Thu, 16 Sep 1999 15:03:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GM2wK12538 for ; Thu, 16 Sep 1999 15:02:59 -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 PAA577188; Thu, 16 Sep 1999 15:02:52 -0700 (PDT) Date: Thu, 16 Sep 1999 15:00:31 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) To: Francis Dupont Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199908241137.NAA09294@givry.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't think so. First, a problematic situation could happen even > without IPV6_PKTINFO. For example, consider the following sample code. > > struct sockaddr_in6 sa1, sa2; > sa1.sin6_scope_id = 1; > sa1.sin6_addr = fe80::1; > sa2.sin6_scope_id = 2; > sa2.sin6_addr = fe80::2; > bind(sa1); > sendto(sa2); > > then, what should happen? In the above example, we don't use > IPV6_PKTINFO at all! Well, then it is an issue for the basic API document and not 2292bis :-) Seriously, we can certainly try to specify the interaction of the different ways to specify ifindex and scope id. But I'd appreciate a complete proposal containing all the rules. The fact that sin6_scope_id applies to bind() should really be part of the basic API. Does anybody want to send a comment to XNET for that one? 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 Thu Sep 16 15:18:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GMEb612583 for ipng-dist; Thu, 16 Sep 1999 15:14:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GMERK12576 for ; Thu, 16 Sep 1999 15:14:27 -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 PAA579492; Thu, 16 Sep 1999 15:14:28 -0700 (PDT) Date: Thu, 16 Sep 1999 15:12:07 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Typo in RFC 2461 To: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <19990902174259.A21195@theory.cs.uni-bonn.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you for catching this one. It will be fixed when we get this document ready for Standard status. Erik >----- Begin Included Message -----< Date: Thu, 2 Sep 1999 17:42:59 +0200 From: "Ignatios Souvatzis" Subject: Typo in RFC 2461 To: ipng@sunroof.eng.sun.com Hello, when re-reading the RFC 2461, I found a typo... In ``3.1 Comparison with IPv4'' on page 14, it says: Address resolution multicasts are "spread" over 4 billion (2^32) multicast addresses greatly reducing address resolution related interrupts on nodes other than the target. Moreover, non-IPv6 machines should not be interrupted at all. However, according to the Address Architecture document (RFC 2373), only 2^24 addresses are used. In a future revision of the document, this should be corrected, like this: Address resolution multicasts are "spread" over 16 million (2^24) multicast addresses greatly reducing address resolution related interrupts on nodes other than the target. Moreover, non-IPv6 machines should not be interrupted at all. [This should not cause any problems; this is not in the protocol description part of the document.] Regards, Ignatios Souvatzis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- >----- End Included Message -----< -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 16 16:12:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GN77F12700 for ipng-dist; Thu, 16 Sep 1999 16:07:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GN6wK12693 for ; Thu, 16 Sep 1999 16:06:58 -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 QAA18200 for ; Thu, 16 Sep 1999 16:06:58 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA10147 for ; Thu, 16 Sep 1999 16:06:58 -0700 (PDT) Received: from world.std.com (qqi@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id TAA22438; Thu, 16 Sep 1999 19:06:56 -0400 (EDT) Received: from localhost (qqi@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id TAA26343; Thu, 16 Sep 1999 19:06:51 -0400 (EDT) Date: Thu, 16 Sep 1999 19:06:51 -0400 (EDT) From: Quality Quorum To: Brian E Carpenter cc: Bradley Reynolds , Jessica Yu , black@layer8.net, ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <37E10257.F2A25E3A@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, 16 Sep 1999, Brian E Carpenter wrote: > Quality Quorum wrote: > > > > On Wed, 15 Sep 1999, Brian E Carpenter wrote: > > > > > Bradley Reynolds wrote: > > > > > > > > comments below > > > > > > > > > Do you have any suggestion of maitaining the scaling of the global > > > > > routing table but not by imposing the restrict aggregation? If not, > > > > > we still have to work under the assumption. > > > > > > > > > this is not germane to your document, but seems like ipv4 is working > > > > fine without such a restriction. > > > > > > I find this pretty rich, being addressed to one of the authors > > > of the CIDR proposal that saved the Internet routing tables > > > from exponential growth a few years ago. IPv4 has survived > > > only because of exactly such a restriction. > > > > It does not matter anymore (or it will not matter soon) due to > > recent tech advances - > > Please tell us *exactly* what this means and how it works. E.g. look at the following paper by Nick McKeown: http://tiny-tera.stanford.edu/~nickm/papers/Infocom98_lookup.pdf One can build 3 level device described there with 24,4 and 4 bits per level. Then one would need only 48M of 25-bit words in order to handle ALL class A, B and C routes plus 1M of longer routes. It is not that much for SRAM implementation, and once announced 167MHz SDRAM will become available (so uncorrelated row read will fall under 50ns), it will be possible to build ideal look up device running at OC-192 dirt cheap. BTW, I suspect that this is not the only available solution, which could be scaled that high. In other words, it seems like we can disregard the necessity of aggregation as a primary requirement to any scheme being discussed. - this is a point I was trying to make. > Brian Thanks, Aleksey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 16:12:35 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8GN9qU12709 for ipng-dist; Thu, 16 Sep 1999 16:09:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8GN9gK12702 for ; Thu, 16 Sep 1999 16:09:42 -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 QAA25496 for ; Thu, 16 Sep 1999 16:09:42 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA19500 for ; Thu, 16 Sep 1999 17:09:41 -0600 (MDT) Received: (qmail 24043 invoked by uid 1001); 16 Sep 1999 23:09:41 -0000 Date: Thu, 16 Sep 1999 16:09:40 -0700 From: Ben Black To: Quality Quorum Cc: Brian E Carpenter , Bradley Reynolds , Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990916160940.W6617@layer8.net> References: <37E10257.F2A25E3A@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Quality Quorum on Thu, Sep 16, 1999 at 07:06:51PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Level-compressed tries are an effective mechanism for reducing the size of a routing table, but they do not reduce the size of a BGP table significantly as they are not applicable to the numerous attributes associated with a given prefix. On Thu, Sep 16, 1999 at 07:06:51PM -0400, Quality Quorum wrote: > > > On Thu, 16 Sep 1999, Brian E Carpenter wrote: > > > Quality Quorum wrote: > > > > > > On Wed, 15 Sep 1999, Brian E Carpenter wrote: > > > > > > > Bradley Reynolds wrote: > > > > > > > > > > comments below > > > > > > > > > > > Do you have any suggestion of maitaining the scaling of the global > > > > > > routing table but not by imposing the restrict aggregation? If not, > > > > > > we still have to work under the assumption. > > > > > > > > > > > this is not germane to your document, but seems like ipv4 is working > > > > > fine without such a restriction. > > > > > > > > I find this pretty rich, being addressed to one of the authors > > > > of the CIDR proposal that saved the Internet routing tables > > > > from exponential growth a few years ago. IPv4 has survived > > > > only because of exactly such a restriction. > > > > > > It does not matter anymore (or it will not matter soon) due to > > > recent tech advances - > > > > Please tell us *exactly* what this means and how it works. > > E.g. look at the following paper by Nick McKeown: > > http://tiny-tera.stanford.edu/~nickm/papers/Infocom98_lookup.pdf > > One can build 3 level device described there with 24,4 and 4 bits > per level. Then one would need only 48M of 25-bit words in order to > handle ALL class A, B and C routes plus 1M of longer routes. > > It is not that much for SRAM implementation, and once announced 167MHz > SDRAM will become available (so uncorrelated row read will fall under > 50ns), it will be possible to build ideal look up device running at > OC-192 dirt cheap. > > BTW, I suspect that this is not the only available solution, which could > be scaled that high. > > In other words, it seems like we can disregard the necessity of > aggregation as a primary requirement to any scheme being discussed. - > this is a point I was trying to make. > > > Brian > > Thanks, > > Aleksey > -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 18:12:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H18SP12931 for ipng-dist; Thu, 16 Sep 1999 18:08:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H18NK12924 for ; Thu, 16 Sep 1999 18:08:23 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id SAA17912 for ipng@sunroof.eng.sun.com; Thu, 16 Sep 1999 18:06:22 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H0rOK12875 for ; Thu, 16 Sep 1999 17:53: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 RAA03045 for ; Thu, 16 Sep 1999 17:53:24 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA23403 for ; Thu, 16 Sep 1999 17:53:24 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id F17AD1E04A; Thu, 16 Sep 1999 20:53:22 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id UAA26831; Thu, 16 Sep 1999 20:53:21 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id RAA19624; Thu, 16 Sep 1999 17:53:20 -0700 (PDT) Message-Id: <199909170053.RAA19624@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: iesg@ietf.org Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard Cc: ipng@sunroof.eng.sun.com Date: Thu, 16 Sep 1999 17:53:20 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I find that the issue of using brackets (a common UNIX shell metacharacter) to surround the address was discussed on the ipng list in July. There are two arguments for using brackets: 1. There are lots of URLs with other shell metacharacters in them (like "?"). 2. Brackets don't cause a problem in commonly used shells unless there is a file that matches the stuff inside the brackets. 1 is specious; just because some URLs have problems does not mean that all should. 2 is incorrect. While sh and bash will accept command line arguments like this, csh and tcsh will not: fenestro% sh $ echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html $ tcsh fenestro% echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html echo: No match. fenestro% csh fenestro% echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html echo: No match. I would suggest "{}" as a replacement for "[]". 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 Sep 16 18:16:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H1F8T12960 for ipng-dist; Thu, 16 Sep 1999 18:15:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H1ExK12953 for ; Thu, 16 Sep 1999 18:14:59 -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 SAA06014 for ; Thu, 16 Sep 1999 18:14:59 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA01948 for ; Thu, 16 Sep 1999 18:14:59 -0700 (PDT) Received: from world.std.com (qqi@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id VAA11863; Thu, 16 Sep 1999 21:14:57 -0400 (EDT) Received: from localhost (qqi@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id VAA14480; Thu, 16 Sep 1999 21:14:57 -0400 (EDT) Date: Thu, 16 Sep 1999 21:14:56 -0400 (EDT) From: Quality Quorum To: Ben Black cc: Brian E Carpenter , Bradley Reynolds , Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <19990916160940.W6617@layer8.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 16 Sep 1999, Ben Black wrote: > Level-compressed tries are an effective mechanism for reducing the size > of a routing table, but they do not reduce the size of a BGP table > significantly as they are not applicable to the numerous attributes > associated with a given prefix. I do not think that this comment is applicable to this work, however, it seems like further discussion in this direction is a way beyond scope of IPng. > > > > > E.g. look at the following paper by Nick McKeown: > > > > http://tiny-tera.stanford.edu/~nickm/papers/Infocom98_lookup.pdf > > > > One can build 3 level device described there with 24,4 and 4 bits > > per level. Then one would need only 48M of 25-bit words in order to > > handle ALL class A, B and C routes plus 1M of longer routes. > > > > It is not that much for SRAM implementation, and once announced 167MHz > > SDRAM will become available (so uncorrelated row read will fall under > > 50ns), it will be possible to build ideal look up device running at > > OC-192 dirt cheap. > > > > BTW, I suspect that this is not the only available solution, which could > > be scaled that high. > > > > In other words, it seems like we can disregard the necessity of > > aggregation as a primary requirement to any scheme being discussed. - > > this is a point I was trying to make. > > > > > Brian > > > > Thanks, > > > > Aleksey > > > > -- > --b > Thanks, Aleksey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 18:25:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H1Lin13008 for ipng-dist; Thu, 16 Sep 1999 18:21:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H1LaK13001 for ; Thu, 16 Sep 1999 18:21: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 SAA15509 for ; Thu, 16 Sep 1999 18:21:36 -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 TAA00176 for ; Thu, 16 Sep 1999 19:21:35 -0600 (MDT) Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA21466; Thu, 16 Sep 1999 18:21:02 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <199909151524.LAA21567@cannes.aa.ans.net> References: <199909151524.LAA21567@cannes.aa.ans.net> Date: Thu, 16 Sep 1999 18:21:01 -0700 To: Jessica Yu , ipng@sunroof.eng.sun.com From: Steve Deering Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:24 AM -0400 9/15/99, Jessica Yu wrote: > Aggregation and allowing no more specific prefixes advertising > into the global routing table is a constraint imposed by the IPv6 > WG as one of the design of IPv6 routing architecture. Jessica and everyone else: The above-quoted statement is incorrect. Unfortunately, this misconception seems to have taken firm hold here recently. IPv6 does *not* mandate route aggregation! - An ISP is free to carry IPv6 prefixes of any value and any length in its routing tables. - If a customer obtains an IPv6 site prefix from one ISP, and can convince other ISPs to carry that prefix in their routing tables, nothing in the IPv6 protocol, routing architecture, or working group utterances forbids that from happening. - If routing technology improves to the point where the the routing system can successfully route independently to every site or every subnet or every node in the future Internet, that would be wonderful, and there is nothing in the design of IPv6 that would prevent it from taking advantage of that capability. What *is* true is that the IPv6 address architecture is designed to make route aggregation *possible*. The reason is that current and at least near-term IP routing technology depends vitally on route aggregation to handle an internet anywhere near the size of today's Internet, not to mention tomorrow's. We did not and do not wish to make IPv6's success contingent on solving the flat routing problem. We are working on new multihoming mechanisms *not* because we have forbidden global advertisement of individual site or customer prefixes. If the ISPs are willing and able to offer that service for IPv6 prefixes, then customers are certainly free to use that service. Rather, we are working on new multihoming mechanisms because we want to be prepared to handle the case where the number of multihomed sites exceeds the ability or willingness of the ISPs to carry the prefixes of those sites globally, or where such carriage is offered only at a price that is prohibitive for many customers. And even if new routing technology comes along to make it cheap and easy to route individually to many millions of sites, some of the mechanisms we are exploring will -- if they work out -- improve support for multihomed *hosts*, even if they are not needed to support multihomed sites. That alone would be a valuable advance in the state of the art. 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 Sep 16 18:43:32 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H1ZLB13038 for ipng-dist; Thu, 16 Sep 1999 18:35:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H1ZCK13031 for ; Thu, 16 Sep 1999 18:35:12 -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 SAA11735 for ; Thu, 16 Sep 1999 18:35:12 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA09693 for ; Thu, 16 Sep 1999 18:35:11 -0700 (PDT) Received: (qmail 24715 invoked by uid 1001); 17 Sep 1999 01:35:11 -0000 Date: Thu, 16 Sep 1999 18:35:11 -0700 From: Ben Black To: Quality Quorum Cc: Brian E Carpenter , Bradley Reynolds , Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990916183511.B6617@layer8.net> References: <19990916160940.W6617@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Quality Quorum on Thu, Sep 16, 1999 at 09:14:56PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry, I meant to include LC-trie URLs, not to say the URL you included referenced them. Here are the URLs I intended: http://www.nada.kth.se/~snilsson/public/papers/router/index.html http://www.nada.kth.se/~snilsson/public/papers/router2/index.html Apologies for the confusion. There are obviously many ways to skin this particular cat, which argues for a close re-evaluation of the assumptions behind the current IPv6 aggregation constraints. On Thu, Sep 16, 1999 at 09:14:56PM -0400, Quality Quorum wrote: > > > On Thu, 16 Sep 1999, Ben Black wrote: > > > Level-compressed tries are an effective mechanism for reducing the size > > of a routing table, but they do not reduce the size of a BGP table > > significantly as they are not applicable to the numerous attributes > > associated with a given prefix. > > I do not think that this comment is applicable to this work, > however, it seems like further discussion in this direction > is a way beyond scope of IPng. > > > > > > > > > E.g. look at the following paper by Nick McKeown: > > > > > > http://tiny-tera.stanford.edu/~nickm/papers/Infocom98_lookup.pdf > > > > > > One can build 3 level device described there with 24,4 and 4 bits > > > per level. Then one would need only 48M of 25-bit words in order to > > > handle ALL class A, B and C routes plus 1M of longer routes. > > > > > > It is not that much for SRAM implementation, and once announced 167MHz > > > SDRAM will become available (so uncorrelated row read will fall under > > > 50ns), it will be possible to build ideal look up device running at > > > OC-192 dirt cheap. > > > > > > BTW, I suspect that this is not the only available solution, which could > > > be scaled that high. > > > > > > In other words, it seems like we can disregard the necessity of > > > aggregation as a primary requirement to any scheme being discussed. - > > > this is a point I was trying to make. > > > > > > > Brian > > > > > > Thanks, > > > > > > Aleksey > > > > > > > -- > > --b > > > > Thanks, > > Aleksey > -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 20:03:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H2xo913169 for ipng-dist; Thu, 16 Sep 1999 19:59:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H2xeK13162 for ; Thu, 16 Sep 1999 19:59: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 TAA17646 for ; Thu, 16 Sep 1999 19:59:40 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA14139 for ; Thu, 16 Sep 1999 19:59:39 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA04240 for ; Fri, 17 Sep 1999 11:59:38 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA03794 for ; Fri, 17 Sep 1999 11:59:38 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA14191 for ; Fri, 17 Sep 1999 11:59:37 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: Fw: interim registration/hotel reservation From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Sep_17_11:58:54_1999_518)--" Content-Transfer-Encoding: 7bit Message-Id: <19990917115905H.kazu@iijlab.net> Date: Fri, 17 Sep 1999 11:59:05 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 105 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----Next_Part(Fri_Sep_17_11:58:54_1999_518)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit The deadline of interim meeting registration is 23:00 JST (GMT+9), September 20 (Mon.), 1999. Please remainder. --Kazu ----Next_Part(Fri_Sep_17_11:58:54_1999_518)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Received: from mgi.iij.ad.jp (mgi.iij.ad.jp [192.168.2.5]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA20344 for ; Wed, 8 Sep 1999 12:00:46 +0900 (JST) Received: from sh1.iijlab.net (sh1.iijlab.net [202.232.15.98]) by mgi.iij.ad.jp (8.8.8/MGI2.0) with ESMTP id MAA27417 for ; Wed, 8 Sep 1999 12:00:46 +0900 (JST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by sh1.iijlab.net (8.8.8/3.7W) with ESMTP id LAA15101 for ; Wed, 8 Sep 1999 11:58:42 +0900 (JST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA06257; Tue, 7 Sep 1999 19:58:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA24775; Tue, 7 Sep 1999 19:56:21 -0700 (PDT) Received: by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d882qON06947 for ipng-dist; Tue, 7 Sep 1999 19:52:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d882qE806940 for ; Tue, 7 Sep 1999 19:52:15 -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 TAA23254 for ; Tue, 7 Sep 1999 19:52:09 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA23046 for ; Tue, 7 Sep 1999 20:52:07 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA29993; Wed, 8 Sep 1999 11:52:06 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA19016; Wed, 8 Sep 1999 11:52:05 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA06212; Wed, 8 Sep 1999 11:52:05 +0900 (JST) To: ipng@sunroof.eng.sun.com Cc: junsec@wide.ad.jp, yumi@kame.net Subject: interim registration/hotel reservation From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.94 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: <19990908115116D.kazu@iijlab.net> Date: Wed, 08 Sep 1999 11:51:16 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-UIDL: 39ec9570d2fb39696ee0ec1b4f9debfa Folks, Sorry for the delay but I think we are ready now. Those who are planing to atenda the next interim meeting in Japan should gain accece to: http://www.wide.ad.jp/events/199909.ipng-interim/ Participants MUST register through this page. If not, you can't take a chair through the meeting. Due to the room space, the number of paticipants is limited to 90. Optionally, you can book room(s) of Mita Miyako hotel through the page. Probably some guys feel that this page is inconvenient. For example, you may want to check out on 3rd Oct. You may want to register the meeting first and book a room later. In such cases, please feel free to send email messages to Scott Macdonald, JCOM (scott@jtbcom.co.jp). Scott will help you. Currently we are not sure that the discount rate can be applied to the other days. It is important to understand that JCOM treats Mita Miyako hotel only. If you want to stay in another hotel, please book a room by yourself. Scott will NOT help you. After the interim meeting, Japanese session will be held. Some Japanese guys explain what's going on in Japan to foreigners. This is optional. Please feel free to leave at noon without attending this session. Likewise, please feel free to attend this session. I believe this is worth listing. :-) If you will get in trouble, please tell me. I have responsibility on the local arrange. See you in Japan soon. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ----Next_Part(Fri_Sep_17_11:58:54_1999_518)---- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 20:16:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H3CJR13195 for ipng-dist; Thu, 16 Sep 1999 20:12:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H3CAK13188 for ; Thu, 16 Sep 1999 20:12: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 UAA18403 for ; Thu, 16 Sep 1999 20:12:09 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA18909 for ; Thu, 16 Sep 1999 20:12:09 -0700 (PDT) Received: from world.std.com (qqi@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id XAA28286; Thu, 16 Sep 1999 23:12:07 -0400 (EDT) Received: from localhost (qqi@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id XAA23458; Thu, 16 Sep 1999 23:12:06 -0400 (EDT) Date: Thu, 16 Sep 1999 23:12:06 -0400 (EDT) From: Quality Quorum To: Ben Black cc: Brian E Carpenter , Bradley Reynolds , Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <19990916183511.B6617@layer8.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 16 Sep 1999, Ben Black wrote: > Sorry, I meant to include LC-trie URLs, not to say the URL you included > referenced them. Here are the URLs I intended: > > http://www.nada.kth.se/~snilsson/public/papers/router/index.html > http://www.nada.kth.se/~snilsson/public/papers/router2/index.html > > Apologies for the confusion. There are obviously many ways to skin this > particular cat, which argues for a close re-evaluation of the assumptions > behind the current IPv6 aggregation constraints. And a new stuff keeps coming in. This was precisely my point: reevaluation of some basic IPV6 requirements may prove to be fruitful. Thanks, Aleksey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 16 20:35:02 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H3V2T13224 for ipng-dist; Thu, 16 Sep 1999 20:31:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H3UqK13217 for ; Thu, 16 Sep 1999 20:30:52 -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 UAA19270 for ; Thu, 16 Sep 1999 20:30:50 -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 VAA01415 for ; Thu, 16 Sep 1999 21:30: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 MAA20980; Fri, 17 Sep 1999 12:30:20 +0900 (JST) To: Steve Deering cc: ipng@sunroof.eng.sun.com In-reply-to: deering's message of Thu, 16 Sep 1999 18:21:01 MST. 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: a response to "A Simple Solution for IPv6 Multihoming" From: itojun@iijlab.net Date: Fri, 17 Sep 1999 12:30:20 +0900 Message-ID: <20978.937539020@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm not objecting anything, just need a clarification or two. >IPv6 does *not* mandate route aggregation! > - An ISP is free to carry IPv6 prefixes of any value and any length in > its routing tables. If it is in a single ISP, it is okay to exchange non-aggregated routes. I believed that, in DFZ, there will be only 8192 routes (for TLA ISPs) will be exchanged (RFC2374 3.2). Am I correct? If the above is correct, for a multihoming technology proposal, - to be usable with site exit links toward different TLA ISP (TLA ISP A and TLA ISP B), the proposal should not rely on non-aggregated route advertisement. - if the proposal is for use within one TLA ISP, is may use non-aggregated route advertisement. I believe it is safer to design multihoming proposals, without using non-aggregated route advertisements. Otherwise the proposal will have less use. > - If a customer obtains an IPv6 site prefix from one ISP, and can > convince other ISPs to carry that prefix in their routing tables, > nothing in the IPv6 protocol, routing architecture, or working > group utterances forbids that from happening. To clarify, "other ISP" cannot inject the route to DFZ (again RFC2374 3.2). Therefore, when site exit link toward primary ISP goes down, the site will be reachable only from peers directly connected to "other ISP". 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 Sep 16 22:33:01 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H5OKf13328 for ipng-dist; Thu, 16 Sep 1999 22:24:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H5OAB13321 for ; Thu, 16 Sep 1999 22:24:11 -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 WAA00174 for ; Thu, 16 Sep 1999 22:24:10 -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 XAA23703 for ; Thu, 16 Sep 1999 23:24:08 -0600 (MDT) Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id WAA01639; Thu, 16 Sep 1999 22:23:21 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <20978.937539020@coconut.itojun.org> References: <20978.937539020@coconut.itojun.org> Date: Thu, 16 Sep 1999 22:23:24 -0700 To: itojun@iijlab.net From: Steve Deering Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:30 PM +0900 9/17/99, itojun@iijlab.net wrote: > If it is in a single ISP, it is okay to exchange non-aggregated > routes. I believed that, in DFZ, there will be only 8192 routes > (for TLA ISPs) will be exchanged (RFC2374 3.2). Am I correct? itojun, The architecture is designed to work when only TLA and subTLA prefixes are exchanged among [sub]TLA ISPs and exchanges (a maximum of 2 * 8192 prefixes). However, a TLA ISP may *choose* to exchange longer prefixes with one or more other TLA ISPs, by private agreement among those ISPs. > I believe it is safer to design multihoming proposals, without > using non-aggregated route advertisements. Otherwise the proposal > will have less use. Yes, the multihoming mechanisms must work in the case that routes are aggregated, because we cannot assume or require that all ISPs will exchange and maintain non-aggregated routes for all (or any) multi- homed sites. > To clarify, "other ISP" cannot inject the route to DFZ (again > RFC2374 3.2). The DFZ does not exist apart from the TLA ISPs, so a TLA ISP does not in reality inject a route "to the DFZ", but rather injects a route into other TLA ISPs (and/or exchanges). If some TLA ISPs agree to accept longer prefixes from some other TLA ISPs, that's OK. That's a private matter between those ISPs. The IPv6 architecture neither requires it nor forbids it. Is that clear now? 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 Sep 16 22:44:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H5VJd13337 for ipng-dist; Thu, 16 Sep 1999 22:31:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H5V8B13330 for ; Thu, 16 Sep 1999 22:31:08 -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 WAA21178 for ; Thu, 16 Sep 1999 22:31:06 -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 WAA09026 for ; Thu, 16 Sep 1999 22:31:05 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id PAA29925; Fri, 17 Sep 1999 15:30:47 +1000 (EST) Date: Fri, 17 Sep 1999 15:30:47 +1000 (EST) From: Peter Tattam To: itojun@iijlab.net cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <20978.937539020@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 Fri, 17 Sep 1999 itojun@iijlab.net wrote: > I'm not objecting anything, just need a clarification or two. > > >IPv6 does *not* mandate route aggregation! > > - An ISP is free to carry IPv6 prefixes of any value and any length in > > its routing tables. > > If it is in a single ISP, it is okay to exchange non-aggregated > routes. I believed that, in DFZ, there will be only 8192 routes > (for TLA ISPs) will be exchanged (RFC2374 3.2). Am I correct? > > If the above is correct, for a multihoming technology proposal, > - to be usable with site exit links toward different TLA ISP > (TLA ISP A and TLA ISP B), the proposal should not rely on > non-aggregated route advertisement. > - if the proposal is for use within one TLA ISP, is may use > non-aggregated route advertisement. > > I believe it is safer to design multihoming proposals, without > using non-aggregated route advertisements. Otherwise the proposal > will have less use. > > > - If a customer obtains an IPv6 site prefix from one ISP, and can > > convince other ISPs to carry that prefix in their routing tables, > > nothing in the IPv6 protocol, routing architecture, or working > > group utterances forbids that from happening. > > To clarify, "other ISP" cannot inject the route to DFZ (again > RFC2374 3.2). Therefore, when site exit link toward primary ISP > goes down, the site will be reachable only from peers directly > connected to "other ISP". > > itojun Correct me if I am wrong, but I recall that A-S numbers are also currently limited to 16 bits (artificially?). Will this also have an impact on the current solutions that are at the front of the pack? i.e. it may limit the total number of ISP that can be multihomed in a global context. Presumably if the multihoming proposals are agreed on, then will this A-S limitation will be removed by extending BGP somewhat? 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 Sep 16 22:49:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H5bnC13360 for ipng-dist; Thu, 16 Sep 1999 22:37:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H5bXB13353 for ; Thu, 16 Sep 1999 22:37:35 -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 WAA00996 for ; Thu, 16 Sep 1999 22:37:32 -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 XAA26199 for ; Thu, 16 Sep 1999 23:37:30 -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 OAA22791; Fri, 17 Sep 1999 14:37:05 +0900 (JST) To: Steve Deering cc: ipng@sunroof.eng.sun.com In-reply-to: deering's message of Thu, 16 Sep 1999 22:23:24 MST. 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: a response to "A Simple Solution for IPv6 Multihoming" From: itojun@iijlab.net Date: Fri, 17 Sep 1999 14:37:05 +0900 Message-ID: <22789.937546625@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Is that clear now? I think so, thanks for clarification. I checked draft-ietf-ngtrans-harden-01.txt and it says like this: >>All pTLAs MUST NOT advertise prefixes longer than a given pTLA >>delegation (currently /24 or /28) to other pTLAs unless special peering >>arrangements are implemented. When such special peering aggreements are in >>place between any two or more pTLAs, care MUST be taken not to leak the more >>specifics to other pTLAs not participating in the peering aggreement. pTLAs >>which have such agreements in place MUST NOT advertise other pTLA more >>specifics to downstream pNLAs or leaf sites, as this will break the >>best-path routing decision. 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 Sep 16 22:59:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H5lZw13385 for ipng-dist; Thu, 16 Sep 1999 22:47:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H5lNB13378 for ; Thu, 16 Sep 1999 22:47:24 -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 WAA21913 for ; Thu, 16 Sep 1999 22:47:22 -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 XAA28123 for ; Thu, 16 Sep 1999 23:47:21 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id PAA00968 for ; Fri, 17 Sep 1999 15:47:19 +1000 (EST) Date: Fri, 17 Sep 1999 15:47:19 +1000 (EST) From: Peter Tattam To: IPNG Mailing List Subject: Summary of Multi Homed proposals Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Would it be prudent at this point considering the imminence of the Interim IETF meeting that a brief summary of all the proposals be put together? I would suggest that we table the following.. 1. The title of the proposal, and the author(s). 2. A brief summary of how the proposal works. A *short* abstract should be appropriate. 3. A reference to a formal document describing the proposal if one exists. If not, one should be prepared ASAP. Once this is done, this order of the proposals should be randomized to reduce any bias, and then published to the list to see if there are any inadvertent omissions. For my part, there has been much discussion on such wide fronts that I have had difficulty in keeping up. As some of us (myself included) are unable to attend, and the list is the only opportunity to have any say, this exercise will be important as a means of at least knowning what the meeting will be discussing and should adequately prepare those at the meeting to make a fair and just decision on this very important topic. Those who will be attending the meeting would do well to agree on the necessary criteria that need to be applied to a successful solution beforehand since they will be representing the interests of the wider IPv6 community. To this end, I suggest that a clear and concise statement of the multihoming problem be tabled and the necessary criteria for a successful solution should also be stated. 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 Sep 16 23:02:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H5rW113415 for ipng-dist; Thu, 16 Sep 1999 22:53:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H5rLB13404 for ; Thu, 16 Sep 1999 22:53:21 -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 WAA01780 for ; Thu, 16 Sep 1999 22:53:17 -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 WAA16825 for ; Thu, 16 Sep 1999 22:53:16 -0700 (PDT) Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id WAA02774; Thu, 16 Sep 1999 22:52:40 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <22789.937546625@coconut.itojun.org> References: <22789.937546625@coconut.itojun.org> Date: Thu, 16 Sep 1999 22:52:42 -0700 To: itojun@iijlab.net From: Steve Deering Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:37 PM +0900 9/17/99, itojun@iijlab.net wrote: > I checked draft-ietf-ngtrans-harden-01.txt and it says like this: > > >>All pTLAs MUST NOT advertise prefixes longer than a given pTLA > >>delegation (currently /24 or /28) to other pTLAs unless special peering > >>arrangements are implemented. When such special peering aggreements are in > >>place between any two or more pTLAs, care MUST be taken not to leak the more > >>specifics to other pTLAs not participating in the peering aggreement. pTLAs > >>which have such agreements in place MUST NOT advertise other pTLA more > >>specifics to downstream pNLAs or leaf sites, as this will break the > >>best-path routing decision. Yes, that's consistent with what I said. 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 Sep 17 01:32:03 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8H8SUj13520 for ipng-dist; Fri, 17 Sep 1999 01:28:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8H8SLB13513 for ; Fri, 17 Sep 1999 01:28:21 -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 BAA09911 for ; Fri, 17 Sep 1999 01:28:21 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA09142 for ; Fri, 17 Sep 1999 01:27:01 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA04267; Fri, 17 Sep 1999 10:23:06 +0200 (MET DST) Message-ID: <19990917102305.A4188@theory.cs.uni-bonn.de> Date: Fri, 17 Sep 1999 10:23:05 +0200 From: Ignatios Souvatzis To: Bill Fenner , iesg@ietf.org Cc: ipng@sunroof.eng.sun.com Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard References: <199909170053.RAA19624@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199909170053.RAA19624@windsor.research.att.com>; from Bill Fenner on Thu, Sep 16, 1999 at 05:53:20PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Sep 16, 1999 at 05:53:20PM -0700, Bill Fenner wrote: > > I find that the issue of using brackets (a common UNIX shell > metacharacter) to surround the address was discussed on the ipng list > in July. There are two arguments for using brackets: > > 1. There are lots of URLs with other shell metacharacters in them > (like "?"). > > 2. Brackets don't cause a problem in commonly used shells unless there > is a file that matches the stuff inside the brackets. > > 1 is specious; just because some URLs have problems does not mean that all > should. > > 2 is incorrect. While sh and bash will accept command line arguments like > this, csh and tcsh will not: > > fenestro% sh > $ echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > $ tcsh > fenestro% echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > echo: No match. > fenestro% csh > fenestro% echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > echo: No match. > > I would suggest "{}" as a replacement for "[]". sounds good to me... as long as commata aren't part of the IPv6 notation ;-) which they aren't. Was this discussed earlier and discarded? -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 Fri Sep 17 03:41:51 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HAarO13615 for ipng-dist; Fri, 17 Sep 1999 03:36:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HAaiB13608 for ; Fri, 17 Sep 1999 03:36:45 -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 DAA04923 for ; Fri, 17 Sep 1999 03:36:43 -0700 (PDT) From: george.tsirtsis@bt.com 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 DAA16912 for ; Fri, 17 Sep 1999 03:36:41 -0700 (PDT) Received: from cbtlipnt01.btlabs.bt.co.uk by babelbrox.axion.bt.co.uk (local) with ESMTP; Fri, 17 Sep 1999 11:22:22 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id ; Fri, 17 Sep 1999 11:21:34 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB202DBA074@mbtlipnt02.btlabs.bt.co.uk> To: deering@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Fri, 17 Sep 1999 11:16:37 +0100 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 Steve, Can I also clarify the purpose of this discussion? In the light of what Steve clarified do we try to single out a multihoming technique and abandon all others? I would hope not! Different networks, customers and ISPs will have different requirements and in general multihoming is more an administration/net. management issue i.e: we do not try to develop a new protocol here (not so far anyway...). I would say that both Jessica's and Itojun/RFC2260 and probably others are workable solutions with different limitations. As long as we *understand* what the limitations/advantages are in each case we should be very careful dismissing configurations and system designs that some might find useful now or in the future. I think Peter Tattam's suggestion to summarise the proposals and hopefully the discussion in the Interim meeting will help us to objectively document options and allow net.admins and customers to evaluate solution for THEIR! requirements. Regards George > -----Original Message----- > From: Steve Deering [SMTP:deering@cisco.com] > Sent: Friday, September 17, 1999 6:53 AM > To: itojun@iijlab.net > Cc: ipng@sunroof.eng.sun.com > Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" > > At 2:37 PM +0900 9/17/99, itojun@iijlab.net wrote: > > I checked draft-ietf-ngtrans-harden-01.txt and it says like this: > > > > >>All pTLAs MUST NOT advertise prefixes longer than a given pTLA > > >>delegation (currently /24 or /28) to other pTLAs unless special > peering > > >>arrangements are implemented. When such special peering aggreements > are in > > >>place between any two or more pTLAs, care MUST be taken not to leak > the more > > >>specifics to other pTLAs not participating in the peering aggreement. > pTLAs > > >>which have such agreements in place MUST NOT advertise other pTLA more > > >>specifics to downstream pNLAs or leaf sites, as this will break the > > >>best-path routing decision. > > Yes, that's consistent with what I said. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 05:06:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HC37G13668 for ipng-dist; Fri, 17 Sep 1999 05:03:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HC2uB13661 for ; Fri, 17 Sep 1999 05:02:56 -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 FAA07826 for ; Fri, 17 Sep 1999 05:02:54 -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 GAA05043 for ; Fri, 17 Sep 1999 06:02:54 -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 IAA04064; Fri, 17 Sep 1999 08:02:51 -0400 (EDT) Message-Id: <199909171202.IAA04064@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-03.txt Date: Fri, 17 Sep 1999 08:02:50 -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, L. Masinter Filename : draft-ietf-ipngwg-url-literal-03.txt Pages : 4 Date : 16-Sep-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-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-url-literal-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-url-literal-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: <19990916072143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-url-literal-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-url-literal-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990916072143.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 Sep 17 06:06:34 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HD2rx13724 for ipng-dist; Fri, 17 Sep 1999 06:02:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HD2iB13717 for ; Fri, 17 Sep 1999 06:02:45 -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 GAA14333 for ; Fri, 17 Sep 1999 06:02:45 -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 HAA17521 for ; Fri, 17 Sep 1999 07:02:44 -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 OAA277190; Fri, 17 Sep 1999 14:02:41 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA15912; Fri, 17 Sep 1999 14:02:31 +0100 (BST) Message-ID: <37E23C0E.E8788A4E@hursley.ibm.com> Date: Fri, 17 Sep 1999 08:03:10 -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: Bill Fenner , iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard References: <199909170053.RAA19624@windsor.research.att.com> <19990917102305.A4188@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 Life is a compromise. Needing to use shell escapes with certain shells might be part of the compromise. Somebody will come up with an issue with {} no doubt. Has the shell issue been a problem with the [] notation for literals in SMTP addresses? Brian Ignatios Souvatzis wrote: > > On Thu, Sep 16, 1999 at 05:53:20PM -0700, Bill Fenner wrote: > > > > I find that the issue of using brackets (a common UNIX shell > > metacharacter) to surround the address was discussed on the ipng list > > in July. There are two arguments for using brackets: > > > > 1. There are lots of URLs with other shell metacharacters in them > > (like "?"). > > > > 2. Brackets don't cause a problem in commonly used shells unless there > > is a file that matches the stuff inside the brackets. > > > > 1 is specious; just because some URLs have problems does not mean that all > > should. > > > > 2 is incorrect. While sh and bash will accept command line arguments like > > this, csh and tcsh will not: > > > > fenestro% sh > > $ echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > > http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > > $ tcsh > > fenestro% echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > > echo: No match. > > fenestro% csh > > fenestro% echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > > echo: No match. > > > > I would suggest "{}" as a replacement for "[]". > > sounds good to me... as long as commata aren't part of the IPv6 notation ;-) > which they aren't. > > Was this discussed earlier and discarded? > > -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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 06:19:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HDFsC13755 for ipng-dist; Fri, 17 Sep 1999 06:15:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HDFhB13748 for ; Fri, 17 Sep 1999 06:15:43 -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 GAA15078 for ; Fri, 17 Sep 1999 06:15:43 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA08013 for ; Fri, 17 Sep 1999 06:15:41 -0700 (PDT) Received: from alden (ALDEN.maxware.no [10.128.1.79]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id OAA23369; Fri, 17 Sep 1999 14:42:50 +0200 Message-Id: <4.2.0.58.19990917143919.01c11d50@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 17 Sep 1999 14:43:58 +0200 To: Bill Fenner , iesg@ietf.org From: Harald Tveit Alvestrand Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199909170053.RAA19624@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 17:53 16.09.99 -0700, Bill Fenner wrote: >2 is incorrect. While sh and bash will accept command line arguments like >this, csh and tcsh will not: > >fenestro% sh >$ echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html >http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html >$ tcsh >fenestro% echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html >echo: No match. >fenestro% csh >fenestro% echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html >echo: No match. > >I would suggest "{}" as a replacement for "[]". Unfortunately, tcsh won't do much good with {} either. [hta@dokka]$ echo http://{FEDC:BA98:7654:3210:FEDC:BA98:7654:3210}:80/index.html http://FEDC:BA98:7654:3210:FEDC:BA98:7654:3210:80/index.html TCSH strips out the curly brackets. (6.07.02). Let's face it. There are NO painless delimiters left. Harald -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 06:37:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HDUWN13778 for ipng-dist; Fri, 17 Sep 1999 06:30:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HDU2B13771 for ; Fri, 17 Sep 1999 06:30: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 GAA12104 for ; Fri, 17 Sep 1999 06:29:22 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA13586 for ; Fri, 17 Sep 1999 06:29:22 -0700 (PDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 72D914CE35; Fri, 17 Sep 1999 09:29:21 -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 JAA15639; Fri, 17 Sep 1999 09:29:21 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id C4ECD41F16; Fri, 17 Sep 1999 09:29:20 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id B5ECA400B4; Fri, 17 Sep 1999 09:29:15 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Harald Tveit Alvestrand Cc: Bill Fenner , iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Sep 1999 09:29:11 -0400 Message-Id: <19990917132920.C4ECD41F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4.2.0.58.19990917143919.01c11d50@dokka.maxware.no>, Harald Tveit Al vestrand writes: > At 17:53 16.09.99 -0700, Bill Fenner wrote: > > >2 is incorrect. While sh and bash will accept command line arguments like > >this, csh and tcsh will not: > > > >fenestro% sh > >$ echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > >http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > >$ tcsh > >fenestro% echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.htm > l > >echo: No match. > >fenestro% csh > >fenestro% echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.htm > l > >echo: No match. > > > >I would suggest "{}" as a replacement for "[]". > > Unfortunately, tcsh won't do much good with {} either. > > [hta@dokka]$ echo > http://{FEDC:BA98:7654:3210:FEDC:BA98:7654:3210}:80/index.html > http://FEDC:BA98:7654:3210:FEDC:BA98:7654:3210:80/index.html > > TCSH strips out the curly brackets. (6.07.02). > Let's face it. There are NO painless delimiters left. Right. And it's not really that much of an issue anyway, since URLs are rarely used at the shell level. (Note: I didn't say "never", I said "rarely".) Given that literals are used in URLs only as an emergency measure anyway, I'm not concerned. Besides -- all of this was taken into account when the document was being written. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 06:43:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HDf1m13814 for ipng-dist; Fri, 17 Sep 1999 06:41:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HDeaB13806 for ; Fri, 17 Sep 1999 06:40: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 GAA12979 for ; Fri, 17 Sep 1999 06:40:36 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA17547 for ; Fri, 17 Sep 1999 06:39:11 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id PAA02187; Fri, 17 Sep 1999 15:38:32 +0200 (MET DST) Message-ID: <19990917153832.B1581@theory.cs.uni-bonn.de> Date: Fri, 17 Sep 1999 15:38:32 +0200 From: Ignatios Souvatzis To: Harald Tveit Alvestrand , Bill Fenner , iesg@ietf.org Cc: ipng@sunroof.eng.sun.com Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard References: <199909170053.RAA19624@windsor.research.att.com> <4.2.0.58.19990917143919.01c11d50@dokka.maxware.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <4.2.0.58.19990917143919.01c11d50@dokka.maxware.no>; from Harald Tveit Alvestrand on Fri, Sep 17, 1999 at 02:43:58PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Sep 17, 1999 at 02:43:58PM +0200, Harald Tveit Alvestrand wrote: > At 17:53 16.09.99 -0700, Bill Fenner wrote: > > >2 is incorrect. While sh and bash will accept command line arguments like > >this, csh and tcsh will not: > > > >fenestro% sh > >$ echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > >http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > >$ tcsh > >fenestro% echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > >echo: No match. > >fenestro% csh > >fenestro% echo http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > >echo: No match. > > > >I would suggest "{}" as a replacement for "[]". > > Unfortunately, tcsh won't do much good with {} either. > > [hta@dokka]$ echo > http://{FEDC:BA98:7654:3210:FEDC:BA98:7654:3210}:80/index.html > http://FEDC:BA98:7654:3210:FEDC:BA98:7654:3210:80/index.html > > TCSH strips out the curly brackets. (6.07.02). > Let's face it. There are NO painless delimiters left. Uh... right. This was a thinko on my side. -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 07:49:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HEjeb13918 for ipng-dist; Fri, 17 Sep 1999 07:45:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HEjUB13911 for ; Fri, 17 Sep 1999 07:45:31 -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 HAA05907 for ; Fri, 17 Sep 1999 07:45:30 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16583 for ; Fri, 17 Sep 1999 07:45:29 -0700 (PDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id KAA25398; Fri, 17 Sep 1999 10:45:23 -0400 (EDT) Message-Id: <199909171445.KAA25398@cannes.aa.ans.net> To: Lloyd Wood cc: Jessica Yu , black@layer8.net, ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of "Thu, 16 Sep 1999 22:01:45 BST." Date: Fri, 17 Sep 1999 10:45:23 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, there has been fiber cuts which affect part of the service area of some ISPs. But to put this into the context of our discussion, this does not mean that the ISP is completely isolated so that it can not announce the aggregate including the multihoming site (customer-A in our example) out to the Internet. So the customer can still utilize the 2nd ISP for its connectivity. Also, there is highly a chance that a massive fiber cut in an area effects mutliple ISPs in the area, so a multihoming site is very likely to loose all its connections even with today's arrangement. By the way, your URL does not seems to pointing to something relevant. --jessica Date: Thu, 16 Sep 1999 22:01:45 BST To: Jessica Yu cc: black@layer8.net, ipng@sunroof.eng.sun.com From: Lloyd Wood Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Return-Path: L.Wood@surrey.ac.uk X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood In-Reply-To: <199909162034.QAA24356@cannes.aa.ans.net> 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 Content-Length: 697 On Thu, 16 Sep 1999, Jessica Yu wrote: > In the last 2-3 years, how many times a good quality ISP went complete > isolated from the Internet? I do not recall one. That is a meaningless statement, since good-quality ISPs by definition don't have isolation outages. I'm pretty sure an entire redneck US state accidentally got cut off from the rest of the planet for sixteen hours by a backhoe at one point. A more concrete counterexample? http://www.ntk.net/index.cgi?back=archive99/now0226.txt&line=18#l or search www.ntk.net for 'Telehouse'. L. there are still too many chokepoints, and not enough redundant meshing. 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 Fri Sep 17 07:50:38 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HEnPJ13929 for ipng-dist; Fri, 17 Sep 1999 07:49:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HEn9B13920 for ; Fri, 17 Sep 1999 07:49: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 HAA06276 for ; Fri, 17 Sep 1999 07:49:10 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21770 for ; Fri, 17 Sep 1999 08:49:08 -0600 (MDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id KAA06960; Fri, 17 Sep 1999 10:42:48 -0400 (EDT) Message-Id: <199909171442.KAA06960@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Ignatios Souvatzis , Bill Fenner , iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard In-reply-to: Your message of "Fri, 17 Sep 1999 08:03:10 CDT." <37E23C0E.E8788A4E@hursley.ibm.com> Date: Fri, 17 Sep 1999 10:42:48 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Has the shell issue been a problem with the [] notation for > literals in SMTP addresses? brackets do not create any problem for shell scripts which doesn't exist already. Other characters that need shell quoting (e.g. ? ; and & ) are already very common in URLs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 08:22:20 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HFIUJ14008 for ipng-dist; Fri, 17 Sep 1999 08:18:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HFIIB14001 for ; Fri, 17 Sep 1999 08:18: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 IAA21630 for ; Fri, 17 Sep 1999 08:18:18 -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 JAA03037 for ; Fri, 17 Sep 1999 09:18:18 -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 KAA13899; Fri, 17 Sep 1999 10:16:59 -0500 (CDT) Message-Id: <199909171516.KAA13899@gungnir.fnal.gov> To: Bill Fenner Cc: iesg@ietf.org, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard In-reply-to: Your message of Thu, 16 Sep 1999 17:53:20 PDT. <199909170053.RAA19624@windsor.research.att.com> Date: Fri, 17 Sep 1999 10:16:53 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > in July. There are two arguments for using brackets: > > 1. There are lots of URLs with other shell metacharacters in them > (like "?"). > [...] > 1 is specious; just because some URLs have problems does not mean that all > should. That rebuttal is itself specious. There should be far fewer URLs in use with literal addresses than with '?' characters. "All" would be an exaggeration of many orders of magnitude. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 08:47:34 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HFhnC14082 for ipng-dist; Fri, 17 Sep 1999 08:43:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HFhcB14072 for ; Fri, 17 Sep 1999 08:43:38 -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 IAA04111 for ; Fri, 17 Sep 1999 08:43:37 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14683 for ; Fri, 17 Sep 1999 08:43:36 -0700 (PDT) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.9.3/8.8.5) with ESMTP id RAA16830 for ; Fri, 17 Sep 1999 17:43:36 +0200 (MET DST) Message-Id: <4.2.0.58.19990917173705.00b22ba0@brahma.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 17 Sep 1999 17:42:18 +0200 To: ipng@sunroof.eng.sun.com From: Alain Durand Subject: source routing & multi-homing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Trying to be imaginative to find solutions for multi-homing, I wonder, is there something in the specs to prevent a router to include a source route option in a transiting packet? I have a proposal that could use such a mechanism, but before I go any further to explore it, I would like to know if there is a one line killer argument against it. - 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 Fri Sep 17 09:30:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HGQBY14152 for ipng-dist; Fri, 17 Sep 1999 09:26:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HGQ2B14145 for ; Fri, 17 Sep 1999 09:26: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 JAA11237 for ; Fri, 17 Sep 1999 09:26:02 -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 JAA04873 for ; Fri, 17 Sep 1999 09:26:02 -0700 (PDT) Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA26572; Fri, 17 Sep 1999 09:25:40 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <4.2.0.58.19990917173705.00b22ba0@brahma.imag.fr> References: <4.2.0.58.19990917173705.00b22ba0@brahma.imag.fr> Date: Fri, 17 Sep 1999 09:25:41 -0700 To: Alain Durand From: Steve Deering Subject: Re: source routing & multi-homing Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:42 PM +0200 9/17/99, Alain Durand wrote: >Trying to be imaginative to find solutions for multi-homing, >I wonder, is there something in the specs to prevent a router >to include a source route option in a transiting packet? > >I have a proposal that could use such a mechanism, >but before I go any further to explore it, I would like to know >if there is a one line killer argument against it. The two line argument against it is: Inserting options into IPv6 packets en-route (or doing anything else that increases the packet's length) breaks PMTU Discovery. It also breaks the TCP MSS option behavior, unless the inserted material is removed before delivery to the destination node(s). If you want the longer description of exactly how those mechanisms fail, let me know, and I'll dig through my email archive to find an old message I once sent that explained that. The safe way to add additional items to an IPv6 packet en-route is to use encapsulation. Encapsulation does not break PMTU Discovery or TCP MSS. 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 Sep 17 09:43:56 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HGc6q14190 for ipng-dist; Fri, 17 Sep 1999 09:38:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HGbtB14183 for ; Fri, 17 Sep 1999 09:37:56 -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 JAA04248 for ; Fri, 17 Sep 1999 09:37:54 -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 KAA06707 for ; Fri, 17 Sep 1999 10:37:52 -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 BAA28847; Sat, 18 Sep 1999 01:37:45 +0900 (JST) To: Alain Durand cc: ipng@sunroof.eng.sun.com In-reply-to: Alain.Durand's message of Fri, 17 Sep 1999 17:42:18 +0200. <4.2.0.58.19990917173705.00b22ba0@brahma.imag.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: source routing & multi-homing From: itojun@iijlab.net Date: Sat, 18 Sep 1999 01:37:45 +0900 Message-ID: <28845.937586265@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Trying to be imaginative to find solutions for multi-homing, >I wonder, is there something in the specs to prevent a router >to include a source route option in a transiting packet? >I have a proposal that could use such a mechanism, >but before I go any further to explore it, I would like to know >if there is a one line killer argument against it. Unfortunately AH will not work with intermediate insertion of routing header. Also, fragmentation will make thing much trickier. 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 Sep 17 09:51:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HGn8R14233 for ipng-dist; Fri, 17 Sep 1999 09:49:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HGn0B14226 for ; Fri, 17 Sep 1999 09:49:00 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA18442 for ipng@sunroof.eng.sun.com; Fri, 17 Sep 1999 09:46:58 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HCW8B13692 for ; Fri, 17 Sep 1999 05:32: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 FAA19453 for ; Fri, 17 Sep 1999 05:32:09 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA21568 for ; Fri, 17 Sep 1999 05:32:08 -0700 (PDT) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by thumper.research.telcordia.com (8.9.3/8.9.1) with ESMTP id IAA12089; Fri, 17 Sep 1999 08:32:04 -0400 (EDT) Received: from seascape.bellcore.com (pya-1-as5200-d6.cc.telcordia.com [128.96.1.6]) by mailee.research.telcordia.com (8.8.8/8.8.8) with SMTP id IAA01297; Fri, 17 Sep 1999 08:32:01 -0400 (EDT) Message-Id: <4.1.19990917082246.00965ac0@mailee.bellcore.com> X-Sender: huitema@mailee.bellcore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 17 Sep 1999 08:30:52 -0400 To: Jessica Yu , black@layer8.net From: Christian Huitema Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: ipng@sunroof.eng.sun.com, jyy@ans.net In-Reply-To: <199909161523.LAA23300@cannes.aa.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:23 AM 9/16/99 -0400, Jessica Yu wrote: > ... As a multihome site, you have > no way of dictating what path the incomming traffic will > take. So your traffic may well be sent to the 'bad path' > regardless. It's all depends on the policy of the ISP and > those ISP could be far far away from you and have no interests > of taking care of your concern since you do not pay them > directly. May I point out that, in the current architecture, the only way to specify the path for incoming traffic is by specifying one of several alternative addresses, i.e. a different address for each incoming path? This is exactly what you get with the combination of aggregatable addresses and DNS "A6" records. One may argue however that there are two missing pieces in the puzzle: 1) a way to quickly update the DNS records, or otherwise affect the choice of addresses, during partial loss of connectivity, or when some of the ISPs undergo severe congestion. 2) a way to migrate TCP connections from one pair of addresses to another. In fact, combining AH or ESP and Mobile IPv6 provides a solution to the second problem. Maybe we should concentrate on the first one, which is a subset of the general problem of "choosing the nearest server." -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 17 09:51:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HGoBj14267 for ipng-dist; Fri, 17 Sep 1999 09:50:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HGo6B14260 for ; Fri, 17 Sep 1999 09:50:06 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA18471 for ipng@sunroof.eng.sun.com; Fri, 17 Sep 1999 09:48:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HGHUB14126 for ; Fri, 17 Sep 1999 09:17: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 JAA09402 for ; Fri, 17 Sep 1999 09:17:29 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28251 for ; Fri, 17 Sep 1999 10:17:28 -0600 (MDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 21D9E1E023; Fri, 17 Sep 1999 12:17:28 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA12437; Fri, 17 Sep 1999 12:17:27 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA25577; Fri, 17 Sep 1999 09:17:27 -0700 (PDT) Message-Id: <199909171617.JAA25577@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: iesg@ietf.org Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard Cc: ipng@sunroof.eng.sun.com References: <199909170053.RAA19624@windsor.research.att.com> <19990917102305.A4188@theory.cs.uni-bonn.de> <37E23C0E.E8788A4E@hursley.ibm.com> Date: Fri, 17 Sep 1999 09:17:26 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks to Harald for pointing out that {} won't work either. How about some innocuous character that may not appear in hostnames, like a comma? http://,FEDC:BA98:7654:3210:FEDC:BA98:7654:3210,:80/index.html It's not particularly pretty, but you're never really supposed to use it very often anyway. I'm afraid that I don't really buy the argument that there's no reason not to make this harder to use for some population because you're not supposed to use it anyway. If it's possible to make it easier to use and not damage the proposal, then why not do so? 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 Fri Sep 17 10:04:30 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HH03t14359 for ipng-dist; Fri, 17 Sep 1999 10:00:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HGxrB14352 for ; Fri, 17 Sep 1999 09:59:54 -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 JAA08862 for ; Fri, 17 Sep 1999 09:59:52 -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 KAA16062 for ; Fri, 17 Sep 1999 10:59:44 -0600 (MDT) Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA29557; Fri, 17 Sep 1999 09:58:53 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <199909171617.JAA25577@windsor.research.att.com> References: <199909170053.RAA19624@windsor.research.att.com> <19990917102305.A4188@theory.cs.uni-bonn.de> <37E23C0E.E8788A4E@hursley.ibm.com> <199909171617.JAA25577@windsor.research.att.com> Date: Fri, 17 Sep 1999 09:58:54 -0700 To: Bill Fenner From: Steve Deering Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard Cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:17 AM -0700 9/17/99, Bill Fenner wrote: >I'm afraid that I don't really buy the argument that there's no reason >not to make this harder to use for some population because you're not >supposed to use it anyway. If it's possible to make it easier to use >and not damage the proposal, then why not do so? Bill, The problem is that changing the punctuation to solve one population's problem creates a problem for another population. Every non-alphanumeric, printable ASCII character has a special meaning to some command line or config file parser somewhere. So a choice had to made. The choice of "[]" was based on an existing precedent for distinguishing IP addresses from DNS names in Internet application-layer protocols (specifically SMTP). It was understood that this might require use of some parsers' special escape syntax for inputting "special" characters. The observation that URLs containing literal IPv6 addresses URLs ought to be rarely used was invoked to support the argument that this requirement for escaping in some parsers is not a show-stopper. 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 Sep 17 10:28:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HHOiS14408 for ipng-dist; Fri, 17 Sep 1999 10:24:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HHOZB14401 for ; Fri, 17 Sep 1999 10:24:35 -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 KAA23174 for ; Fri, 17 Sep 1999 10:24:34 -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 KAA28809 for ; Fri, 17 Sep 1999 10:24:34 -0700 (PDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id NAA24365 for ; Fri, 17 Sep 1999 13:24:33 -0400 (EDT) Received: from whitestar.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000014271; Fri, 17 Sep 1999 13:24:31 -0400 (EDT) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA25501; Fri, 17 Sep 1999 13:24:30 -0400 Message-Id: <37E2794E.E19C65D4@zk3.dec.com> Date: Fri, 17 Sep 1999 13:24:30 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.51 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: IPNG Working Group Subject: Re: Comments on 2292bis (Adv. API) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > > > There reason we are advocating for 'alignX' and 'alignY' as arguments to the > > API is that they will already be defined in the Option Specification and > > easily used ('length' will be the 3 argument). If the Option Specification > > does not follow Appendix B (it doesn't have to), then this API will still > > align the data correctly and conserve as much space as possible (one of the > > goals stated in 2460). > > Are you arguing that there is a benefit in defining options differently > than the recommendation in 2460 i.e. that this will save space? No, the argument was that by replacing 'align' with 'alignX' and 'alignY' we illiminate the dependency on Appendix B of 2460. Granted, we see the benefit only if the option is NOT designed to follow Appendix B and when multiple such options are specified. I don't know how common this particular case will be, but why restrict the API. > > > Yes, I was refering to sticky otions. It looks like you are advocating > > caching the options. In you implementation if the user were to set both > > IPV6_RTHDRDSTOPTS and IPV6_RTHDR options, and then unset IPV6_RTHDR, you > > would still have the IPV6_RTHDRDSTOPTS option set, but will ignore it. Is my > > understanding correct? > > That is what our current implementation does. > While I'm not strongly advocating this it is simple to implement > and allows the application to set options in any order (i.e. the > application can issue a setsockopt for IPV6_RTHDRDSTOPTS before the > setsockopt for IPV6_RTHDR). > An alternative was suggested by Tim: make IPV6_RTHDRDSTOPTS just specify a > second destination header which is sent whether or not there is a routing > header. This is as easy to implement as far as I can tell, but it doesn't > quite match the IPV6_RTHDRDSTOPTS name. It would make sense to change the > name to e.g. IPV6_DSTOPTS2 if we go this path. > Thanks for clearing this up. Given the options, I would pick your implementation. > > Erik Thanks -vlad +++++++++++++++++++++++++++++++ Vladislav Yasevich Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 (603) 884-1079 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 10:35:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HHXxS14430 for ipng-dist; Fri, 17 Sep 1999 10:33:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HHXpB14423 for ; Fri, 17 Sep 1999 10:33:51 -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 KAA25269 for ; Fri, 17 Sep 1999 10:33:50 -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 LAA00867 for ; Fri, 17 Sep 1999 11:33:49 -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 SAA79294 for ; Fri, 17 Sep 1999 18:33:47 +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 SAA30450 for ; Fri, 17 Sep 1999 18:33:46 +0100 (BST) Message-ID: <37E25474.347C0CEA@hursley.ibm.com> Date: Fri, 17 Sep 1999 09:47:16 -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: table size is not the problem [Re: a response to "A Simple Solution for IPv6 Multihoming" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sure, we can build big fast lookup engines. That is not the problem, unfortunately. The problem is convergence time of the route table computations, which is a distributed computing problem. I'm not an expert on this, but people who are experts assure me of this. Is there anyone here who can expand on this? Brian Quality Quorum wrote: > > On Thu, 16 Sep 1999, Ben Black wrote: > > > Sorry, I meant to include LC-trie URLs, not to say the URL you included > > referenced them. Here are the URLs I intended: > > > > http://www.nada.kth.se/~snilsson/public/papers/router/index.html > > http://www.nada.kth.se/~snilsson/public/papers/router2/index.html > > > > Apologies for the confusion. There are obviously many ways to skin this > > particular cat, which argues for a close re-evaluation of the assumptions > > behind the current IPv6 aggregation constraints. > > And a new stuff keeps coming in. > > This was precisely my point: reevaluation of some basic IPV6 > requirements may prove to be fruitful. > > Thanks, > > Aleksey > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 17 10:35:51 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HHYD814446 for ipng-dist; Fri, 17 Sep 1999 10:34:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HHY0B14432 for ; Fri, 17 Sep 1999 10:34: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 KAA25302 for ; Fri, 17 Sep 1999 10:33:59 -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 LAA00905 for ; Fri, 17 Sep 1999 11:33:58 -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 SAA39780; Fri, 17 Sep 1999 18:33:52 +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 SAA19192; Fri, 17 Sep 1999 18:33:50 +0100 (BST) Message-ID: <37E2552D.3A5ED5AD@hursley.ibm.com> Date: Fri, 17 Sep 1999 09:50:21 -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: Summary of Multi Homed proposals References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a good idea. As someone else pointed out, there is nothing wrong with having several multihoming methodologies defined, but at least they should be summarized in one place. Brian Peter Tattam wrote: > > Would it be prudent at this point considering the imminence of the Interim IETF > meeting that a brief summary of all the proposals be put together? > > I would suggest that we table the following.. > > 1. The title of the proposal, and the author(s). > > 2. A brief summary of how the proposal works. A *short* abstract should be > appropriate. > > 3. A reference to a formal document describing the proposal if one exists. If > not, one should be prepared ASAP. > > Once this is done, this order of the proposals should be randomized to reduce > any bias, and then published to the list to see if there are any inadvertent > omissions. > > For my part, there has been much discussion on such wide fronts that I have had > difficulty in keeping up. > > As some of us (myself included) are unable to attend, and the list is the only > opportunity to have any say, this exercise will be important as a means of at > least knowning what the meeting will be discussing and should adequately > prepare those at the meeting to make a fair and just decision on this very > important topic. Those who will be attending the meeting would do well to > agree on the necessary criteria that need to be applied to a successful > solution beforehand since they will be representing the interests of the wider > IPv6 community. > > To this end, I suggest that a clear and concise statement of the multihoming > problem be tabled and the necessary criteria for a successful solution should > also be stated. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 11:06:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HI2eR14514 for ipng-dist; Fri, 17 Sep 1999 11:02:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HI2SB14507 for ; Fri, 17 Sep 1999 11:02:29 -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 LAA01440 for ; Fri, 17 Sep 1999 11:02:28 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15694 for ; Fri, 17 Sep 1999 11:02:27 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 13D594CE0C; Fri, 17 Sep 1999 14:02:22 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA15067; Fri, 17 Sep 1999 14:02:21 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA26416; Fri, 17 Sep 1999 11:02:21 -0700 (PDT) Message-Id: <199909171802.LAA26416@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: deering@cisco.com Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard Cc: iesg@ietf.org, ipng@sunroof.eng.sun.com References: <199909170053.RAA19624@windsor.research.att.com> <19990917102305.A4188@theory.cs.uni-bonn.de> <37E23C0E.E8788A4E@hursley.ibm.com> <199909171617.JAA25577@windsor.research.att.com> Date: Fri, 17 Sep 1999 11:02:20 -0700 Versions: dmail (solaris) 2.2e/makemail 2.8u Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, I certainly understand that there are other populations which might have trouble with any given character. To some extent, the size of those populations might be of interest when choosing which one to inconvenience. However, although it's easy to describe one segment of the population that has trouble with the current proposal (anyone using csh, tcsh, zsh, and possibly other UNIX shells who needs to use a literal IPv6 address in a URL on the command line), it's hard to describe who might be affected by a suggested change like using commas. My gut tells me that literal addresses are often used when things are broken, and UNIX command-line utilites are often used when things are broken, so the combination of literal IPv6 addresses in URLs and UNIX shells has a higher weight than whatever breaks when you use a comma, but that's just me being handwavy and self-centered =) I believe that the [] precedent for SMTP is not very relevant; it's much less common to have a SMTP server on a machine that you have to address via a literal address than a web server. 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 Fri Sep 17 11:08:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HI6u014533 for ipng-dist; Fri, 17 Sep 1999 11:06:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HI6hB14526 for ; Fri, 17 Sep 1999 11:06:44 -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 LAA02254 for ; Fri, 17 Sep 1999 11:05:59 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15652 for ; Fri, 17 Sep 1999 12:05:59 -0600 (MDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id OAA25854; Fri, 17 Sep 1999 14:02:40 -0400 (EDT) Message-Id: <199909171802.OAA25854@cannes.aa.ans.net> To: Ben Black cc: Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of "Thu, 16 Sep 1999 14:04:03 PDT." <19990916140403.V6617@layer8.net> Date: Fri, 17 Sep 1999 14:02:40 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >Given that RFC2260/itojun is the only proposal presented that actually meets >> >the goals of multihoming, I don't understand the need for convincing. >> >> You missed my point. I am saying I am not convinced for it's management >> scalability. Tunnel in general is a network management nightmare. It's >> easy to make config mistake and hard to debug. Tunnel between ISPs >> routers is even scareier. >> > >Tunnels are inferior to simply advertising a single prefix for your network >into multiple ISPs. However, the tunnels required in RFC2260/itojun are >a necessary evil to accomodate constraints in the IPv6 routing architecture. >SMPL may lack tunnels, but it similarly lacks removal of a single point of >failure. I just read draft-itojun-ipv6-2260-00.txt again and turns out that same redundancy issue you worried about SMPL would happend to that scheme as well. Let me explain. The prosaol have a subset of hosts in a multihoming site assigned with address space from ISP-A and a subset with that from ISP-B. And under the assumption of aggregation, only ISP-A advertise it's aggregate (say address-A) to the entire Internet and only ISP-B advertise address-B to the entire Internet e.g. ISP-C, ISP-D ect. If ISP-A has massive failure, half of the hosts assigned to address space from A at the multihoming site is not going to be reachable. If ISP-A lost all its connection to ISP-D, then ISP-D and anything behind it can not reach the hosts in address-A space of the site. Same thing applies if ISP-B had massive failure. So the reachability of a multihoming site realies on a single ISP as much as that in SMPL's situation. If anyone claim SMPL does not provide reasonable redundancy, then RFC2260/itojun does not do it either. The second issue with RFC2260/itojun proposal that I hope to get clarification is that how exactly the tunnel or the secondary link is exactly built. Any tunnel has to have physical path underneath it. Just use the picture in the I-D (ISP A) (ISP B) ISP-BR-A ISP-BR-B | | | | | \-----------------------+ | | | Secondary link | | | | +----------------------|-/ | | | | | | | | | | | | | | | | | +---|--|----------------------|---|--+ | E-BR-A E-BR-B | | | | | +------------------------------------+_ The Secondary link (tunnel) between ISP-BR-A and E-BR-B has to be built either on physical link ISP-BR-A to E-BR-A or some links between ISP-A and ISP-B. Obviously, one can not use the former since the tunnel is servered as the backup when the link between ISP-BR-A/E-BR-A goes down. So the tunnel has to be using links between ISP-A and ISP-B which will entirely depend on how they route each other. If someone worries about link congestion between ISPs, you can not avoid it here as well. I think Rob from Sprint pointed out the same issue in his earlier message although I have not read it carefully yet. One issue with tunnels is that it will make packets which would normally fit in max MTU size exceed the max MTU size due to the adding of IP header for encapsulation. This will cause routers to waste resource for packet fragmentation which led to very poor performance. Many Tunnel based VPN users suffer from the problem. Another issue with tunnel is the performance. It certainly cause router resource to encapsulate and decapsulate every single packet using tunnels. A large ISP's border router (or customer aggregation router) usually connects hundreds of end customers. It has scaling impact to have that router to do all these extra resource comsuming tasks. Also, the performance would be bad for the multihoming customer as well with the tunnel. When the tunnel is in use, that's means one connection is down, all the traffic will concentrate on the other sole connection and the sole poor router. Adding more burden on it (it has to decapsulate every packet) it just not wise. Also, with this scheme, the operator of the multihoming site has to be very clueful and ip routing savor since it's a complexed routing setup (just read the RFC2260/itojun draft and try to config your site). Most of the site do not have such expertises. As a result, misconfiguration or error happen will very likely to happen. For example, if the priority is not set right, traffic may well use the tunnel even thought the primary link is health. That will very much impace the performance. Connectivity will be impact if tunnel is not set right, tunnel associated problem is usually very hard to detect. Anyway, I can go on and on but I think the point is made and I will stop. In summary, RFC2260/itojun does not seem to provide better redundancy than SMPL. The problem associated with tunnel mechanism should not be overlooked. --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 11:11:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HIAH914555 for ipng-dist; Fri, 17 Sep 1999 11:10:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HIA8B14548 for ; Fri, 17 Sep 1999 11:10: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 LAA23466 for ; Fri, 17 Sep 1999 11:10:07 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA19142 for ; Fri, 17 Sep 1999 11:10:06 -0700 (PDT) Received: (qmail 370 invoked by uid 1001); 17 Sep 1999 18:10:06 -0000 Date: Fri, 17 Sep 1999 11:10:06 -0700 From: Ben Black To: Christian Huitema Cc: Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990917111006.A345@layer8.net> References: <199909161523.LAA23300@cannes.aa.ans.net> <4.1.19990917082246.00965ac0@mailee.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <4.1.19990917082246.00965ac0@mailee.bellcore.com>; from Christian Huitema on Fri, Sep 17, 1999 at 08:30:52AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There may also be a 0th option: use the existing multihoming and aggregation mechanism for IPv4 in IPv6. On Fri, Sep 17, 1999 at 08:30:52AM -0400, Christian Huitema wrote: > At 11:23 AM 9/16/99 -0400, Jessica Yu wrote: > > > ... As a multihome site, you have > > no way of dictating what path the incomming traffic will > > take. So your traffic may well be sent to the 'bad path' > > regardless. It's all depends on the policy of the ISP and > > those ISP could be far far away from you and have no interests > > of taking care of your concern since you do not pay them > > directly. > > May I point out that, in the current architecture, the only way to specify > the path for incoming traffic is by specifying one of several alternative > addresses, i.e. a different address for each incoming path? This is exactly > what you get with the combination of aggregatable addresses and DNS "A6" > records. One may argue however that there are two missing pieces in the puzzle: > > 1) a way to quickly update the DNS records, or otherwise affect the choice > of addresses, during partial loss of connectivity, or when some of the ISPs > undergo severe congestion. > > 2) a way to migrate TCP connections from one pair of addresses to another. > > In fact, combining AH or ESP and Mobile IPv6 provides a solution to the > second problem. Maybe we should concentrate on the first one, which is a > subset of the general problem of "choosing the nearest server." > -- Christian Huitema -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 11:29:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HIPBx14651 for ipng-dist; Fri, 17 Sep 1999 11:25:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HIP0B14644 for ; Fri, 17 Sep 1999 11:25: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 LAA17371 for ; Fri, 17 Sep 1999 11:24:59 -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 MAA24489 for ; Fri, 17 Sep 1999 12:24:57 -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 DAA00187; Sat, 18 Sep 1999 03:24:28 +0900 (JST) To: Ben Black cc: ipng@sunroof.eng.sun.com In-reply-to: black's message of Fri, 17 Sep 1999 11:10:06 MST. <19990917111006.A345@layer8.net> 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: a response to "A Simple Solution for IPv6 Multihoming" From: itojun@iijlab.net Date: Sat, 18 Sep 1999 03:24:28 +0900 Message-ID: <185.937592668@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> 2) a way to migrate TCP connections from one pair of addresses to another. >> In fact, combining AH or ESP and Mobile IPv6 provides a solution to the >> second problem. Maybe we should concentrate on the first one, which is a >> subset of the general problem of "choosing the nearest server." >> -- Christian Huitema Is it really possible? From my understanding currently available mobile-ipv6 draft does not address key setup (interaction with IKE). If you can clarify how you will be configuring keys on TCP connection time, and address pair change, it would be really helpful. 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 Sep 17 12:03:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HIXHw14683 for ipng-dist; Fri, 17 Sep 1999 11:33:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HIX5B14676 for ; Fri, 17 Sep 1999 11:33:07 -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 LAA19048 for ; Fri, 17 Sep 1999 11:33:03 -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 LAA29215 for ; Fri, 17 Sep 1999 11:33:02 -0700 (PDT) Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA09829; Fri, 17 Sep 1999 11:32:59 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19990917111006.A345@layer8.net> References: <199909161523.LAA23300@cannes.aa.ans.net> <4.1.19990917082246.00965ac0@mailee.bellcore.com> <19990917111006.A345@layer8.net> Date: Fri, 17 Sep 1999 11:33:00 -0700 To: Ben Black From: Steve Deering Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:10 AM -0700 9/17/99, Ben Black wrote: >There may also be a 0th option: use the existing multihoming and aggregation >mechanism for IPv4 in IPv6. Ben, The mechanism used in IPv4 does not scale to millions of multihomed sites, using existing routing technology. We would like to be able to support many millions of multihomed sites in IPv6 (e.g., many small enterprises connected to multiple ISPs for reliability, households connected to the Internet via their phone wire and their cable TV wire, etc.). So yes, we could (and probably will) use the same mechanism as in IPv4, but only for some relatively small number of lucky or rich customers. That still leaves a requirement to develop new multihoming mechanisms for all the other potential multihomed sites. 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 Sep 17 12:03:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HIaLR14722 for ipng-dist; Fri, 17 Sep 1999 11:36:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HIa8B14715 for ; Fri, 17 Sep 1999 11:36:08 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id LAA18694 for ipng@sunroof.eng.sun.com; Fri, 17 Sep 1999 11:34:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HIIwB14594 for ; Fri, 17 Sep 1999 11:18:58 -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 LAA09230 for ; Fri, 17 Sep 1999 11:18:57 -0700 (PDT) Received: from zappa.esys.ca (zappa.esys.ca [198.161.92.28]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21850 for ; Fri, 17 Sep 1999 12:18:56 -0600 (MDT) Received: (from lyndon@localhost) by zappa.esys.ca (8.9.3/8.9.3) id MAA445398; Fri, 17 Sep 1999 12:18:47 -0600 (MDT) Message-Id: <199909171818.MAA445398@zappa.esys.ca> To: Bill Fenner cc: deering@cisco.com, iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard In-reply-to: Your message of "Fri, 17 Sep 1999 11:02:20 PDT." <199909171802.LAA26416@windsor.research.att.com> Date: Fri, 17 Sep 1999 12:18:46 -0600 From: Lyndon Nerenberg Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Bill" == Bill Fenner writes: Bill> My gut tells me that literal addresses Bill> are often used when things are broken, and UNIX command-line Bill> utilites are often used when things are broken, so the Bill> combination of literal IPv6 addresses in URLs and UNIX Bill> shells has a higher weight than whatever breaks when you use Bill> a comma, but that's just me being handwavy and self-centered But as a debugging tool literals are going to be used very infrequently (one would hope), and the people using them should be cognizant of shell meta-characters, so I simply don't see this as an issue. Using []'s for literals is a very well entrenched practise, and I see no reason for changing it. --lyndon -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 12:03:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HIZkU14712 for ipng-dist; Fri, 17 Sep 1999 11:35:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HIZUB14705 for ; Fri, 17 Sep 1999 11:35: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 LAA19578 for ; Fri, 17 Sep 1999 11:35:22 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA29265 for ; Fri, 17 Sep 1999 12:35:21 -0600 (MDT) Received: (qmail 635 invoked by uid 1001); 17 Sep 1999 18:35:12 -0000 Date: Fri, 17 Sep 1999 11:35:12 -0700 From: Ben Black To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990917113512.A595@layer8.net> References: <199909161523.LAA23300@cannes.aa.ans.net> <4.1.19990917082246.00965ac0@mailee.bellcore.com> <19990917111006.A345@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Steve Deering on Fri, Sep 17, 1999 at 11:33:00AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is it realistic to assume 1) millions of multihomed sites sooner than the current growth rate would indicate and 2) that the networking hardware will not be up to the task by then? On Fri, Sep 17, 1999 at 11:33:00AM -0700, Steve Deering wrote: > At 11:10 AM -0700 9/17/99, Ben Black wrote: > >There may also be a 0th option: use the existing multihoming and aggregation > >mechanism for IPv4 in IPv6. > > Ben, > > The mechanism used in IPv4 does not scale to millions of multihomed sites, > using existing routing technology. We would like to be able to support > many millions of multihomed sites in IPv6 (e.g., many small enterprises > connected to multiple ISPs for reliability, households connected to > the Internet via their phone wire and their cable TV wire, etc.). > > So yes, we could (and probably will) use the same mechanism as in IPv4, > but only for some relatively small number of lucky or rich customers. > That still leaves a requirement to develop new multihoming mechanisms > for all the other potential multihomed sites. > > Steve -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 12:04:30 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HIeNv14741 for ipng-dist; Fri, 17 Sep 1999 11:40:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HIdiB14734 for ; Fri, 17 Sep 1999 11:39: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 LAA10138 for ; Fri, 17 Sep 1999 11:39:44 -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 LAA01712 for ; Fri, 17 Sep 1999 11:39:42 -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 DAA00362; Sat, 18 Sep 1999 03:39:31 +0900 (JST) To: Jessica Yu cc: ipng@sunroof.eng.sun.com In-reply-to: jyy's message of Fri, 17 Sep 1999 14:02:40 -0400. <199909171802.OAA25854@cannes.aa.ans.net> 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: a response to "A Simple Solution for IPv6 Multihoming" From: itojun@iijlab.net Date: Sat, 18 Sep 1999 03:39:31 +0900 Message-ID: <360.937593571@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk First of all, let me clearify this: As draft-itojun-ipv6-2260 states in very early part of the document, the draft covers only part of multihoming problems. There are so many goals in multihoming. To name a few: - load balancing - low delay - various failure modes ISP links ISP routers, site border routers the whole-smash shutdown in ISP draft-itojun-ipv6-2260 covers ISP link failure, no others. For other issues too many policies are involved, and most of those need global knowledge about the network (like current bandwidth usage in both ISP links) so I don't feel like we have any generic solution. I think my draft is clear enough about the scope of the problem. There's no single solution against this kind of problem. Also, we do not really need to pick only single technology against the problem. We can pick techniques depending on site configuration. (we may need to suggest "default combo" of technologies, though) > The second issue with RFC2260/itojun proposal that I hope to > get clarification is that how exactly the tunnel or the > secondary link is exactly built. Any tunnel has to have > physical path underneath it. > > Just use the picture in the I-D > > (ISP A) (ISP B) > > ISP-BR-A ISP-BR-B > | | | | > | \-----------------------+ | | > | Secondary link | | | > | +----------------------|-/ | > | | | | > | | | | > | | | | > | | | | > +---|--|----------------------|---|--+ > | E-BR-A E-BR-B | > | | > | | > +------------------------------------+_ > > > The Secondary link (tunnel) between ISP-BR-A and E-BR-B has to > be built either on physical link ISP-BR-A to E-BR-A or some links > between ISP-A and ISP-B. Obviously, one can not use the former > since the tunnel is servered as the backup when the link between > ISP-BR-A/E-BR-A goes down. So the tunnel has to be using links > between ISP-A and ISP-B which will entirely depend on how they > route each other. If someone worries about link congestion > between ISPs, you can not avoid it here as well. I think Rob > from Sprint pointed out the same issue in his earlier message > although I have not read it carefully yet. Secondary link to ISP-A must be configured to go through different physical medium than primary link to ISP-A. There's no other requirement imposed. It is up to you to choose appropriate medium for secondary link. Secondary link can be configured in various ways depending on configuration in your site (explored in section 6). For example, - if primary link is RFC1933 tunnel, you can configure another RFC1933 tunnel. There'll be no MTU issue raised. - If primary link is IPv6 leased line, you can of course configure secondary link as IPv6-over-IPv6 tunnel. In this case you have MTU issue. - you may be able to purchase extra leased line for secondary link, of course. > One issue with tunnels is that it will make packets which would > normally fit in max MTU size exceed the max MTU size due to the > adding of IP header for encapsulation. This will cause routers > to waste resource for packet fragmentation which led to very > poor performance. Many Tunnel based VPN users suffer from the > problem. I think the above statement is not correct. If you properly send icmp6 need fragment message, the end nodes will do path MTU discovery and edge routers do not need to fragment the packets. I agree lower path MTU may degrade performance, but I believe edge routers do not need to perform extra fragmentation on tunnel ingress. 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 Sep 17 12:09:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HItY614785 for ipng-dist; Fri, 17 Sep 1999 11:55:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HItJB14778 for ; Fri, 17 Sep 1999 11:55:21 -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 LAA17367 for ; Fri, 17 Sep 1999 11:55:15 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07030 for ; Fri, 17 Sep 1999 12:55:14 -0600 (MDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id OAA26062; Fri, 17 Sep 1999 14:55:05 -0400 (EDT) Message-Id: <199909171855.OAA26062@cannes.aa.ans.net> To: Ben Black cc: Christian Huitema , Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of "Fri, 17 Sep 1999 11:10:06 PDT." <19990917111006.A345@layer8.net> Date: Fri, 17 Sep 1999 14:55:04 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ben, If I understand Christian's message correctly, he is talking about possible mechanisms for an end user site to dictate the path for incomming traffic. Not that I am against using the current multihoming mechanism for IPv6 (I am really not) but I completely fail to see the relevance of your comment below to his, unless you still think that a site is able to dictate the path for its incomming traffic which is really a fantacy. Look at the following example: x | ISP-F ----------ISP-G | \ | ISP-A - ISP-B ISP-H | | | ISP-C - ISP-D - ISP-E \ / site-1 | y x sends traffic y of site-1, site-1 may wish the traffic go through path ISP-F - ISP-B - ISP-D. But with current mechanism, ISP-F and ISPs along the way will choose whatever next hot it think is appropriate to forward traffic. At every hop, ISP will just consider it's own policy with its own interests to choose the next hop for the traffic. Site-1 do not get any say nor ISP-F, ISP-B ... would care about what site-1 wants since it is not even their own direct customer. --Jessica Date: Fri, 17 Sep 1999 11:10:06 PDT To: Christian Huitema cc: Jessica Yu , ipng@sunroof.eng.sun.com From: Ben Black Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Return-Path: black@osbie.layer8.net References: <199909161523.LAA23300@cannes.aa.ans.net> <4.1.19990917082246.00965 ***ac0@mailee.bellcore.com> Mime-Version: 1.0 X-Mailer: Mutt 0.95.3i In-Reply-To: <4.1.19990917082246.00965ac0@mailee.bellcore.com>; from Christian ***Huitema on Fri, Sep 17, 1999 at 08:30:52AM -0400 Content-Type: text/plain; charset=us-ascii Content-Length: 1500 There may also be a 0th option: use the existing multihoming and aggregation mechanism for IPv4 in IPv6. On Fri, Sep 17, 1999 at 08:30:52AM -0400, Christian Huitema wrote: > At 11:23 AM 9/16/99 -0400, Jessica Yu wrote: > > > ... As a multihome site, you have > > no way of dictating what path the incomming traffic will > > take. So your traffic may well be sent to the 'bad path' > > regardless. It's all depends on the policy of the ISP and > > those ISP could be far far away from you and have no interests > > of taking care of your concern since you do not pay them > > directly. > > May I point out that, in the current architecture, the only way to specify > the path for incoming traffic is by specifying one of several alternative > addresses, i.e. a different address for each incoming path? This is exactly > what you get with the combination of aggregatable addresses and DNS "A6" > records. One may argue however that there are two missing pieces in the puzzl e: > > 1) a way to quickly update the DNS records, or otherwise affect the choice > of addresses, during partial loss of connectivity, or when some of the ISPs > undergo severe congestion. > > 2) a way to migrate TCP connections from one pair of addresses to another. > > In fact, combining AH or ESP and Mobile IPv6 provides a solution to the > second problem. Maybe we should concentrate on the first one, which is a > subset of the general problem of "choosing the nearest server." > -- Christian Huitema -- --b^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 Fri Sep 17 12:09:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HIpNX14764 for ipng-dist; Fri, 17 Sep 1999 11:51:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HIpBB14757 for ; Fri, 17 Sep 1999 11:51:12 -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 LAA16566 for ; Fri, 17 Sep 1999 11:51:07 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA05380 for ; Fri, 17 Sep 1999 12:51:06 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 17 Sep 1999 11:26:44 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2524.0) id ; Fri, 17 Sep 1999 11:26:43 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145159EF@RED-MSG-50> From: Richard Draves To: "'Jessica Yu'" , Ben Black Cc: ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Fri, 17 Sep 1999 11:26:40 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The prosaol have a subset of hosts in a multihoming > site assigned > with address space from ISP-A and a subset with that from ISP-B. > And under the assumption of aggregation, only ISP-A advertise > it's aggregate (say address-A) to the entire Internet and only > ISP-B advertise address-B to the entire Internet e.g. > ISP-C, ISP-D > ect. If ISP-A has massive failure, half of the hosts > assigned to > address space from A at the multihoming site is not going to be > reachable. If ISP-A lost all its connection to ISP-D, then ISP-D > and anything behind it can not reach the hosts in > address-A space > of the site. Same thing applies if ISP-B had massive > failure. So > the reachability of a multihoming site realies on a > single ISP as > much as that in SMPL's situation. If anyone claim SMPL > does not > provide reasonable redundancy, then RFC2260/itojun does > not do it > either. I thought the RFC2260/itojun approach used prefixes obtained from ISP-A and ISP-B to number the entire site, ie hosts in the site all have two addresses? > The Secondary link (tunnel) between ISP-BR-A and E-BR-B has to > be built either on physical link ISP-BR-A to E-BR-A or > some links > between ISP-A and ISP-B. Obviously, one can not use the former > since the tunnel is servered as the backup when the link between > ISP-BR-A/E-BR-A goes down. So the tunnel has to be using links > between ISP-A and ISP-B which will entirely depend on how they > route each other. If someone worries about link congestion > between ISPs, you can not avoid it here as well. I think Rob > from Sprint pointed out the same issue in his earlier message > although I have not read it carefully yet. If the tunnel endpoint addresses are chosen properly (out of the correct prefixes belonging to ISP-A & ISP-B), won't they automatically be routed properly over the physical links between ISP-A & ISP-B? > One issue with tunnels is that it will make packets which would > normally fit in max MTU size exceed the max MTU size due to the > adding of IP header for encapsulation. This will cause routers > to waste resource for packet fragmentation which led to very > poor performance. Many Tunnel based VPN users suffer from the > problem. This isn't an issue for v6, is it? The router will not do fragmentation, instead the path MTU change will get propogated back to the originating host. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 17 12:09:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HIw4c14799 for ipng-dist; Fri, 17 Sep 1999 11:58:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HIvkB14791 for ; Fri, 17 Sep 1999 11:57:48 -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 LAA13446 for ; Fri, 17 Sep 1999 11:57:46 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA07973 for ; Fri, 17 Sep 1999 12:57:45 -0600 (MDT) Received: (qmail 898 invoked by uid 1001); 17 Sep 1999 18:57:44 -0000 Date: Fri, 17 Sep 1999 11:57:44 -0700 From: Ben Black To: Jessica Yu Cc: Christian Huitema , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990917115744.D595@layer8.net> References: <19990917111006.A345@layer8.net> <199909171855.OAA26062@cannes.aa.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199909171855.OAA26062@cannes.aa.ans.net>; from Jessica Yu on Fri, Sep 17, 1999 at 02:55:04PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I was suggesting use of the existing mechanism as an alternative to using the IPv6 aggregation architecture currently specified. There is no relation to issues of dictating inbound traffic. On Fri, Sep 17, 1999 at 02:55:04PM -0400, Jessica Yu wrote: > Ben, > > If I understand Christian's message correctly, he is talking about > possible mechanisms for an end user site to dictate the path for incomming > traffic. Not that I am against using the current multihoming mechanism for > IPv6 (I am really not) but I completely fail to see the relevance of your > comment below to his, unless you still think that a site is able to dictate > the path for its incomming traffic which is really a fantacy. > > Look at the following example: > > x > | > ISP-F ----------ISP-G > | \ | > ISP-A - ISP-B ISP-H > | | | > ISP-C - ISP-D - ISP-E > \ / > site-1 > | > y > > > x sends traffic y of site-1, site-1 may wish the traffic go through path > ISP-F - ISP-B - ISP-D. But with current mechanism, ISP-F and ISPs along > the way will choose whatever next hot it think is appropriate to forward > traffic. At every hop, ISP will just consider it's own policy with its own > interests to choose the next hop for the traffic. Site-1 do not get > any say nor ISP-F, ISP-B ... would care about what site-1 wants since it > is not even their own direct customer. > > --Jessica > > Date: Fri, 17 Sep 1999 11:10:06 PDT > To: Christian Huitema > cc: Jessica Yu , ipng@sunroof.eng.sun.com > > From: Ben Black > Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" > > Return-Path: black@osbie.layer8.net > References: <199909161523.LAA23300@cannes.aa.ans.net> <4.1.19990917082246.00965 > ***ac0@mailee.bellcore.com> > Mime-Version: 1.0 > X-Mailer: Mutt 0.95.3i > In-Reply-To: <4.1.19990917082246.00965ac0@mailee.bellcore.com>; from Christian > ***Huitema on Fri, Sep 17, 1999 at 08:30:52AM -0400 > Content-Type: text/plain; charset=us-ascii > Content-Length: 1500 > > There may also be a 0th option: use the existing multihoming and aggregation > mechanism for IPv4 in IPv6. > > On Fri, Sep 17, 1999 at 08:30:52AM -0400, Christian Huitema wrote: > > At 11:23 AM 9/16/99 -0400, Jessica Yu wrote: > > > > > ... As a multihome site, you have > > > no way of dictating what path the incomming traffic will > > > take. So your traffic may well be sent to the 'bad path' > > > regardless. It's all depends on the policy of the ISP and > > > those ISP could be far far away from you and have no interests > > > of taking care of your concern since you do not pay them > > > directly. > > > > May I point out that, in the current architecture, the only way to specify > > the path for incoming traffic is by specifying one of several alternative > > addresses, i.e. a different address for each incoming path? This is exactly > > what you get with the combination of aggregatable addresses and DNS "A6" > > records. One may argue however that there are two missing pieces in the puzzl > e: > > > > 1) a way to quickly update the DNS records, or otherwise affect the choice > > of addresses, during partial loss of connectivity, or when some of the ISPs > > undergo severe congestion. > > > > 2) a way to migrate TCP connections from one pair of addresses to another. > > > > In fact, combining AH or ESP and Mobile IPv6 provides a solution to the > > second problem. Maybe we should concentrate on the first one, which is a > > subset of the general problem of "choosing the nearest server." > > -- Christian Huitema > > -- > --b^C -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 12:21:03 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HJFMS14918 for ipng-dist; Fri, 17 Sep 1999 12:15:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HJF9B14907 for ; Fri, 17 Sep 1999 12:15:10 -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 MAA17418 for ; Fri, 17 Sep 1999 12:15:08 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14264 for ; Fri, 17 Sep 1999 13:15:07 -0600 (MDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id PAA26121; Fri, 17 Sep 1999 15:15:05 -0400 (EDT) Message-Id: <199909171915.PAA26121@cannes.aa.ans.net> To: richdr@microsoft.com cc: ipng@sunroof.eng.sun.com, jyy@ans.net Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Fri, 17 Sep 1999 15:15:05 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The prosaol have a subset of hosts in a multihoming site assigned >> with address space from ISP-A and a subset with that from ISP-B. >> And under the assumption of aggregation, only ISP-A advertise >> it's aggregate (say address-A) to the entire Internet and only >> ISP-B advertise address-B to the entire Internet e.g. ISP-C, ISP-D >> ect. If ISP-A has massive failure, half of the hosts assigned to >> address space from A at the multihoming site is not going to be >> reachable. If ISP-A lost all its connection to ISP-D, then ISP-D >> and anything behind it can not reach the hosts in address-A space >> of the site. Same thing applies if ISP-B had massive > failure. So >> the reachability of a multihoming site realies on a >> single ISP as much as that in SMPL's situation. If anyone claim SMPL >> does not provide reasonable redundancy, then RFC2260/itojun does >> not do it either. > >I thought the RFC2260/itojun approach used prefixes obtained from ISP-A and >ISP-B to number the entire site, ie hosts in the site all have two >addresses? I do not believe RFC2260 intend to have each host assigned with multiple IP addresses. itojun's extention does not require each host be assigned with multiple IP addresses. If multiple IP address per host is a requirement for that proposal, then we are opening another big can of worms. Besides, with multiple address per host, need to use tunnels as backup diminishes. >> The Secondary link (tunnel) between ISP-BR-A and E-BR-B has to >> be built either on physical link ISP-BR-A to E-BR-A or some links >> between ISP-A and ISP-B. Obviously, one can not use the former >> since the tunnel is servered as the backup when the link between >> ISP-BR-A/E-BR-A goes down. So the tunnel has to be using links >> between ISP-A and ISP-B which will entirely depend on how they >> route each other. If someone worries about link congestion >> between ISPs, you can not avoid it here as well. I think Rob >> from Sprint pointed out the same issue in his earlier message >> although I have not read it carefully yet. >If the tunnel endpoint addresses are chosen properly (out of the correct >prefixes belonging to ISP-A & ISP-B), won't they automatically be routed >properly over the physical links between ISP-A & ISP-B? Yes. It will be routed on one of the links between ISP-A and ISP-B. But this does not change my point above. >> One issue with tunnels is that it will make packets which would >> normally fit in max MTU size exceed the max MTU size due to the >> adding of IP header for encapsulation. This will cause routers >> to waste resource for packet fragmentation which led to very >> poor performance. Many Tunnel based VPN users suffer from the >> problem. > >This isn't an issue for v6, is it? The router will not do fragmentation, >instead the path MTU change will get propogated back to the originating >host. I do not know if this will be in place anywhere in the v6 world. Would someone comment on this? > >Rich Thanks! --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 12:44:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HJXVm14969 for ipng-dist; Fri, 17 Sep 1999 12:33:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HJX0B14962 for ; Fri, 17 Sep 1999 12:33:06 -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 MAA10480 for ; Fri, 17 Sep 1999 12:32:58 -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 MAA21109 for ; Fri, 17 Sep 1999 12:32: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 EAA00981; Sat, 18 Sep 1999 04:32:54 +0900 (JST) To: Jessica Yu cc: ipng@sunroof.eng.sun.com In-reply-to: jyy's message of Fri, 17 Sep 1999 15:15:05 -0400. <199909171915.PAA26121@cannes.aa.ans.net> 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: a response to "A Simple Solution for IPv6 Multihoming" From: itojun@iijlab.net Date: Sat, 18 Sep 1999 04:32:54 +0900 Message-ID: <979.937596774@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >>> The prosaol have a subset of hosts in a multihoming site assigned >>> with address space from ISP-A and a subset with that from ISP-B. >>> And under the assumption of aggregation, only ISP-A advertise >>> it's aggregate (say address-A) to the entire Internet and only >>> ISP-B advertise address-B to the entire Internet e.g. ISP-C, ISP-D >>> ect. If ISP-A has massive failure, half of the hosts assigned to >>> address space from A at the multihoming site is not going to be >>> reachable. If ISP-A lost all its connection to ISP-D, then ISP-D >>> and anything behind it can not reach the hosts in address-A space >>> of the site. Same thing applies if ISP-B had massive > failure. So >>> the reachability of a multihoming site realies on a >>> single ISP as much as that in SMPL's situation. If anyone claim SMPL >>> does not provide reasonable redundancy, then RFC2260/itojun does >>> not do it either. >> >>I thought the RFC2260/itojun approach used prefixes obtained from ISP-A and >>ISP-B to number the entire site, ie hosts in the site all have two >>addresses? > > I do not believe RFC2260 intend to have each host assigned > with multiple IP addresses. itojun's extention does not > require each host be assigned with multiple IP addresses. RFC2260 does not intend to, but draft-itojun-ipv6-2260 does. see 4.2. The document does not *mandate* assignment of two addresses, though. > If multiple IP address per host is a requirement for that > proposal, then we are opening another big can of worms. > Besides, with multiple address per host, need to use tunnels > as backup diminishes. Site administrators are free to choose address assignment. If you do not assign both, the node will not be reachable when one of your ISP is totally unusable. If you assign both prefixes to a node, a node needs to do some source address selection. 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 Sep 17 12:44:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HJb0n14979 for ipng-dist; Fri, 17 Sep 1999 12:37:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HJalB14972 for ; Fri, 17 Sep 1999 12:36:49 -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 MAA01154 for ; Fri, 17 Sep 1999 12:36:19 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22342 for ; Fri, 17 Sep 1999 12:36:18 -0700 (PDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id PAA26193; Fri, 17 Sep 1999 15:36:16 -0400 (EDT) Message-Id: <199909171936.PAA26193@cannes.aa.ans.net> To: richdr@microsoft.com cc: ipng@sunroof.eng.sun.com, jyy@ans.net Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Fri, 17 Sep 1999 15:36:16 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> One issue with tunnels is that it will make packets which would >>> normally fit in max MTU size exceed the max MTU size due to the >>> adding of IP header for encapsulation. This will cause routers >>> to waste resource for packet fragmentation which led to very >>> poor performance. Many Tunnel based VPN users suffer from the >>> problem. >> >>This isn't an issue for v6, is it? The router will not do fragmentation, >>instead the path MTU change will get propogated back to the originating >>host. > > I do not know if this will be in place anywhere in the v6 world. > ^^^^^^^^ > Would someone comment on this? I really meant everywhere instead of anywhere. Also, can someone tell me if the implementation is avaialble now? Thanks! --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 12:55:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HJnJO15080 for ipng-dist; Fri, 17 Sep 1999 12:49:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HJn9B15069 for ; Fri, 17 Sep 1999 12:49: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 MAA22711 for ; Fri, 17 Sep 1999 12:49:08 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27450 for ; Fri, 17 Sep 1999 12:49:07 -0700 (PDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id PAA26229; Fri, 17 Sep 1999 15:49:01 -0400 (EDT) Message-Id: <199909171949.PAA26229@cannes.aa.ans.net> To: itojun@itojun.org cc: ipng@sunroof.eng.sun.com, jyy@ans.net Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Date: Fri, 17 Sep 1999 15:49:01 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >>>> The prosaol have a subset of hosts in a multihoming site assigned >>>> with address space from ISP-A and a subset with that from ISP-B. >>>> And under the assumption of aggregation, only ISP-A advertise >>>> it's aggregate (say address-A) to the entire Internet and only >>>> ISP-B advertise address-B to the entire Internet e.g. ISP-C, ISP-D >>>> ect. If ISP-A has massive failure, half of the hosts assigned to >>>> address space from A at the multihoming site is not going to be >>>> reachable. If ISP-A lost all its connection to ISP-D, then ISP-D >>>> and anything behind it can not reach the hosts in address-A space >>>> of the site. Same thing applies if ISP-B had massive > failure. So >>>> the reachability of a multihoming site realies on a >>>> single ISP as much as that in SMPL's situation. If anyone claim SMPL >>>> does not provide reasonable redundancy, then RFC2260/itojun does >>>> not do it either. >>> >>>I thought the RFC2260/itojun approach used prefixes obtained from ISP-A and >>>ISP-B to number the entire site, ie hosts in the site all have two >>>addresses? >> >> I do not believe RFC2260 intend to have each host assigned >> with multiple IP addresses. itojun's extention does not >> require each host be assigned with multiple IP addresses. > RFC2260 does not intend to, but draft-itojun-ipv6-2260 does. > see 4.2. The document does not *mandate* assignment of two addresses, > though. We are saying the same thing. That is good that we have the same understanding. >> If multiple IP address per host is a requirement for that >> proposal, then we are opening another big can of worms. >> Besides, with multiple address per host, need to use tunnels >> as backup diminishes. > Site administrators are free to choose address assignment. > If you do not assign both, the node will not be reachable when > one of your ISP is totally unusable. If you assign both prefixes > to a node, a node needs to do some source address selection. Agree. Source address selection could be a tough cookie to bite. More study is needed to exactly how to do it. It may also presents issues for DNS, etc. If a site choose to not assign multiple address, then SMPL might be attractive since it is simple to manage (no tunnles) thus less chance to mess up and provide comparable funcationality such as redundancy, load sharing,etc. >itojun Thanks! --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 13:27:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HKKQD15122 for ipng-dist; Fri, 17 Sep 1999 13:20:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HKKDB15115 for ; Fri, 17 Sep 1999 13:20: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 NAA27664 for ; Fri, 17 Sep 1999 13:20:12 -0700 (PDT) Received: from neonet_server1.nexabit.com (neonetserver1.nexabit.com [209.6.34.254]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09111 for ; Fri, 17 Sep 1999 13:20:11 -0700 (PDT) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Fri, 17 Sep 1999 16:20:10 -0400 Message-ID: <1180113EC576D011AADE0060975B88B38C2B97@neonet_server1.nexabit.com> From: Dimitry Haskin To: Jessica Yu , richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Fri, 17 Sep 1999 16:20:07 -0400 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >>This isn't an issue for v6, is it? The router will not do > fragmentation, > >>instead the path MTU change will get propogated back to the > originating > >>host. > > > > I do not know if this will be in place anywhere in > the v6 world. > > ^^^^^^^^ > > Would someone comment on this? > > > I really meant everywhere instead of anywhere. > Also, can someone tell me if the implementation is avaialble now? > Thanks! > > --Jessica Hosts that don't implement the Part MTU discovery should limit their packet sizes to 1280 octets. For all practical purposes it leaves rooms for possible encapsulations. Hosts that send packets larger than 1280 bytes should be prepared that such packets may not get through. V6 routers are required to implement their portion of the Path MTU discovery, i.e. sending Packet-Too-Big ICMP messages. V6 routers don't fragment transit traffic, if this is your question. ---------------------------------------------------------------------- Dimitry Haskin Lucent Technologies Internetworking Systems > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 14:20:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HLFFH15277 for ipng-dist; Fri, 17 Sep 1999 14:15:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HLF6B15270 for ; Fri, 17 Sep 1999 14:15:07 -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 OAA14765 for ; Fri, 17 Sep 1999 14:15:06 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA02220 for ; Fri, 17 Sep 1999 15:15:05 -0600 (MDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 17 Sep 1999 12:54:15 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id ; Fri, 17 Sep 1999 12:54:15 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145159F4@RED-MSG-50> From: Richard Draves To: "'Jessica Yu'" Cc: ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Fri, 17 Sep 1999 12:54:10 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >>This isn't an issue for v6, is it? The router will not do > fragmentation, > >>instead the path MTU change will get propogated back to the > originating > >>host. > > > > I do not know if this will be in place anywhere in > the v6 world. > > ^^^^^^^^ > > Would someone comment on this? > > > I really meant everywhere instead of anywhere. > Also, can someone tell me if the implementation is avaialble now? > Thanks! Yes, it will be in place everywhere - it's a standard part of IPv6. As far as I know, it's how all implementations work today. Certainly that's how MSR IPv6 will behave when forwarding into a tunnel. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 17 14:34:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HLTNB15311 for ipng-dist; Fri, 17 Sep 1999 14:29:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HLTEB15304 for ; Fri, 17 Sep 1999 14:29: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 OAA12031 for ; Fri, 17 Sep 1999 14:29:14 -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 OAA06851 for ; Fri, 17 Sep 1999 14:29:14 -0700 (PDT) Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA25038; Fri, 17 Sep 1999 14:29:12 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19990917113512.A595@layer8.net> References: <199909161523.LAA23300@cannes.aa.ans.net> <4.1.19990917082246.00965ac0@mailee.bellcore.com> <19990917111006.A345@layer8.net> <19990917113512.A595@layer8.net> Date: Fri, 17 Sep 1999 14:29:12 -0700 To: Ben Black From: Steve Deering Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:35 AM -0700 9/17/99, Ben Black wrote: >Is it realistic to assume 1) millions of multihomed sites sooner than >the current growth rate would indicate (a) I don't know what the current growth rate is, or how much latent demand has been suppressed by the current difficulties in getting a new prefix advertised globally. Do you have any data on that? (b) Even if the current growth rate in multihoming is low, I think it would be foolish to bet on that continuing to be the case. (c) A number of ISP people have said many times that IPv6 had better *reduce* the size of the routing tables in the default-free zone, because what you call the "current IPv4 multihoming solution" is just barely working at the present scale. > and 2) that the networking hardware will not be up to the task by then? Workable flat routing to many millions of sites in an Internet built by multiple, competing ISPs will require something other than just Moore's Law improvements in hardware. 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 Sep 17 15:12:57 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HM7q615479 for ipng-dist; Fri, 17 Sep 1999 15:07:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HM7hB15472 for ; Fri, 17 Sep 1999 15:07:44 -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 PAA00613 for ; Fri, 17 Sep 1999 15:07:44 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA21541 for ; Fri, 17 Sep 1999 15:07:43 -0700 (PDT) Received: (qmail 1995 invoked by uid 1001); 17 Sep 1999 22:07:43 -0000 Date: Fri, 17 Sep 1999 15:07:43 -0700 From: Ben Black To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990917150743.J595@layer8.net> References: <199909161523.LAA23300@cannes.aa.ans.net> <4.1.19990917082246.00965ac0@mailee.bellcore.com> <19990917111006.A345@layer8.net> <19990917113512.A595@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Steve Deering on Fri, Sep 17, 1999 at 02:29:12PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Sep 17, 1999 at 02:29:12PM -0700, Steve Deering wrote: > At 11:35 AM -0700 9/17/99, Ben Black wrote: > >Is it realistic to assume 1) millions of multihomed sites sooner than > >the current growth rate would indicate > > (a) I don't know what the current growth rate is, or how much latent > demand has been suppressed by the current difficulties in getting > a new prefix advertised globally. Do you have any data on that? > > (b) Even if the current growth rate in multihoming is low, I think it > would be foolish to bet on that continuing to be the case. > However, it would be equally foolish to expend a large amount of effort designing and implementing the current IPv6 aggregation mechanism. What is needed for realistic design is a body of information addressing (a) above. I know this information exists, but is also extremely proprietary. > (c) A number of ISP people have said many times that IPv6 had better > *reduce* the size of the routing tables in the default-free zone, > because what you call the "current IPv4 multihoming solution" is > just barely working at the present scale. > I suspect this information is either old or provided by ISP people who need to upgrade to current router platforms. An AGS+ is just not a core router, but an RSP4 can certainly handle at least 250k routes (the limiting factor is not memory, but CPU). Other manufacturers are using higher performance CPUs and that trend will only increase. I am confident that routers capable of handling over 1 million routes will ship within 12 months. By the time IPv6 could even be deployed with the number of routes in the current IPv4 backbone, I would expect at least 2 million routes could be handled, if not more. > > and 2) that the networking hardware will not be up to the task by then? > > Workable flat routing to many millions of sites in an Internet built > by multiple, competing ISPs will require something other than just > Moore's Law improvements in hardware. > Perhaps on the management side, but definitely not on the hardware side. The "something" that would be required to handle millions of routes is an efficient automated management system. I think it is naive to think we can constrain routing table growth just because we want to avoid figuring out how to manage the network. This thread alone has shown that there are numerous problems associated with putting constraints in place, particularly whent he reasons for those constraints are not supported by facts. > Steve -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 16:08:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HN3Zh15633 for ipng-dist; Fri, 17 Sep 1999 16:03:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HN3QB15626 for ; Fri, 17 Sep 1999 16:03: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 QAA18892 for ; Fri, 17 Sep 1999 16:03:26 -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 QAA10010 for ; Fri, 17 Sep 1999 16:03:26 -0700 (PDT) Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA03253; Fri, 17 Sep 1999 16:03:23 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19990917150743.J595@layer8.net> References: <199909161523.LAA23300@cannes.aa.ans.net> <4.1.19990917082246.00965ac0@mailee.bellcore.com> <19990917111006.A345@layer8.net> <19990917113512.A595@layer8.net> <19990917150743.J595@layer8.net> Date: Fri, 17 Sep 1999 16:03:24 -0700 To: Ben Black From: Steve Deering Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:07 PM -0700 9/17/99, Ben Black wrote: >However, it would be equally foolish to expend a large amount of effort >designing and implementing the current IPv6 aggregation mechanism. The IPv6 aggregation mechanism is just CIDR with bigger addresses. CIDR was designed and implemented years ago. No particular additional effort is required, other than the effort of responding to email like yours :-). >I suspect this information is either old or provided by ISP people who >need to upgrade to current router platforms. Your suspicions are wrong, on both counts. > This thread alone has shown >that there are numerous problems associated with putting constraints >in place, particularly whent he reasons for those constraints are not >supported by facts. There's that misunderstanding again. IPv6 places no constraints on the amount of route de-aggregation. We are doing prudent address allocation that enables the degree of aggregation that works well with the current state of routing technology (hardware, policy, people, etc.) However, any ISP or group of ISPs that are able and willing to do less aggregated routing are free to do so. I suspect and hope that will be the direction of evolution of Internet routing, but I am unwilling to bet the farm on it. 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 Sep 17 16:25:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HNLCV15678 for ipng-dist; Fri, 17 Sep 1999 16:21:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HNL2B15671 for ; Fri, 17 Sep 1999 16:21:03 -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 QAA22038 for ; Fri, 17 Sep 1999 16:21:02 -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 RAA20347 for ; Fri, 17 Sep 1999 17:21:02 -0600 (MDT) Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA04396; Fri, 17 Sep 1999 16:20:59 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19990917150743.J595@layer8.net> References: <199909161523.LAA23300@cannes.aa.ans.net> <4.1.19990917082246.00965ac0@mailee.bellcore.com> <19990917111006.A345@layer8.net> <19990917113512.A595@layer8.net> <19990917150743.J595@layer8.net> Date: Fri, 17 Sep 1999 16:21:00 -0700 To: Ben Black From: Steve Deering Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You: "Is it realistic to assume...millions of multihomed sites sooner than the current growth rate would indicate...?" Me: "I don't know what the current growth rate is, or how much latent demand has been suppressed by the current difficulties in getting a new prefix advertised globally. Do you have any data on that?" You: "I know this information exists, but is also extremely proprietary." In other words, you don't know either. That makes your initial rhetorical question specious. 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 Sep 17 16:36:57 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HNWmA15721 for ipng-dist; Fri, 17 Sep 1999 16:32:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HNWdB15714 for ; Fri, 17 Sep 1999 16:32:40 -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 QAA15652 for ; Fri, 17 Sep 1999 16:32:40 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA23740 for ; Fri, 17 Sep 1999 17:32:39 -0600 (MDT) Received: (qmail 2479 invoked by uid 1001); 17 Sep 1999 23:32:38 -0000 Date: Fri, 17 Sep 1999 16:32:38 -0700 From: Ben Black To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990917163238.K595@layer8.net> References: <199909161523.LAA23300@cannes.aa.ans.net> <4.1.19990917082246.00965ac0@mailee.bellcore.com> <19990917111006.A345@layer8.net> <19990917113512.A595@layer8.net> <19990917150743.J595@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Steve Deering on Fri, Sep 17, 1999 at 04:21:00PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Sep 17, 1999 at 04:21:00PM -0700, Steve Deering wrote: > You: "Is it realistic to assume...millions of multihomed sites sooner > than the current growth rate would indicate...?" > > Me: "I don't know what the current growth rate is, or how much latent > demand has been suppressed by the current difficulties in getting > a new prefix advertised globally. Do you have any data on that?" > > You: "I know this information exists, but is also extremely proprietary." > > In other words, you don't know either. That makes your initial rhetorical > question specious. > That is one interpretation. > Steve -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 16:43:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HNeEM15781 for ipng-dist; Fri, 17 Sep 1999 16:40:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HNdgB15771 for ; Fri, 17 Sep 1999 16:39: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 QAA25042 for ; Fri, 17 Sep 1999 16:39:42 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA25668 for ; Fri, 17 Sep 1999 17:39:41 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 17 Sep 1999 16:33:58 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2524.0) id ; Fri, 17 Sep 1999 16:33:57 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515A0A@RED-MSG-50> From: Richard Draves To: "'Steve Deering'" , Ben Black Cc: ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Fri, 17 Sep 1999 16:33:52 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Me: "I don't know what the current growth rate is, or how > much latent > demand has been suppressed by the current difficulties > in getting > a new prefix advertised globally. Do you have any data > on that?" I don't know either, but I suspect that the latent demand may be significant. So another way of looking at this is, if we provide reasonable support for multihoming in IPv6 without the need for a globally visible prefix (hard to get in v4), this could give people a reason to use IPv6. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 17 16:54:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8HNlmh15816 for ipng-dist; Fri, 17 Sep 1999 16:47:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8HNldB15809 for ; Fri, 17 Sep 1999 16:47: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 QAA05630 for ; Fri, 17 Sep 1999 16:47:39 -0700 (PDT) Received: from osbie.layer8.net (osbie.layer8.net [166.88.69.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA23083 for ; Fri, 17 Sep 1999 16:47:39 -0700 (PDT) Received: (qmail 2555 invoked by uid 1001); 17 Sep 1999 23:47:39 -0000 Date: Fri, 17 Sep 1999 16:47:39 -0700 From: Ben Black To: Richard Draves Cc: "'Steve Deering'" , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Message-ID: <19990917164739.L595@layer8.net> References: <4D0A23B3F74DD111ACCD00805F31D81014515A0A@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515A0A@RED-MSG-50>; from Richard Draves on Fri, Sep 17, 1999 at 04:33:52PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Sep 17, 1999 at 04:33:52PM -0700, Richard Draves wrote: > > Me: "I don't know what the current growth rate is, or how > > much latent > > demand has been suppressed by the current difficulties > > in getting > > a new prefix advertised globally. Do you have any data > > on that?" > > I don't know either, but I suspect that the latent demand may be > significant. > Based on what? > So another way of looking at this is, if we provide reasonable support for > multihoming in IPv6 without the need for a globally visible prefix (hard to > get in v4), this could give people a reason to use IPv6. > Heh, I think it is pretty clear at this point it isn't easier in IPv6. > Rich -- --b -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 17:14:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I0AJ816008 for ipng-dist; Fri, 17 Sep 1999 17:10:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I0AAB16001 for ; Fri, 17 Sep 1999 17:10: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 RAA29586 for ; Fri, 17 Sep 1999 17:10:09 -0700 (PDT) Received: from mailserver-ng.cs.umbc.edu (mailserver-ng.cs.umbc.edu [130.85.100.230]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03384 for ; Fri, 17 Sep 1999 18:10:05 -0600 (MDT) Received: from localhost (wrath@localhost) by mailserver-ng.cs.umbc.edu (8.9.3/8.9.3) with SMTP id UAA01357; Fri, 17 Sep 1999 20:09:50 -0400 (EDT) Date: Fri, 17 Sep 1999 20:09:50 -0400 (EDT) From: Vijay Gill Reply-To: Vijay Gill To: Steve Deering cc: Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" 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, 17 Sep 1999, Steve Deering wrote: > >I suspect this information is either old or provided by ISP people who > >need to upgrade to current router platforms. > > Your suspicions are wrong, on both counts. The IBGP route table of some promising local isps is substantially larger than the global routing table. Thus ISP's that can barely handle the current default free routing table need to buy faster boxes. The critical path is not amount of RAM, but rather the amount of CPU needed to crunch the routing tables and disseminate the information to peers. Given a linear (albeit steeper) curve, Moore's law still outstrips prefix growth. Another issue to consider is speed at which you can do lookups for forwarding. Using 256-way mtries allows you to do a (current) longest prefix match using 4 memory cycles. OC-192c lookups and forwarding at wirespeed for small packets is doable today. With v6, this issue becomes harder. It has been proven in the backbone of promising local isp's that current traffic patterns are not ameneable to caching. The argument for having a few entries in routing tables is that they result in a smaller forwarding table, allowing implementation tricks and very fast ram to do lookups and perhaps cache a certain amount of information with less churn than in the v4 forwarding tables, allowing for wirespeed forwarding at 192c and better. However, one could argue that the optics and electronics to drive the interfaces comprise most of the cost of a high speed forwarding board and that the saving on forwarding engines is thus noise. > routing are free to do so. I suspect and hope that will be the direction > of evolution of Internet routing, but I am unwilling to bet the farm > on it. Given that multiple circuits to the enduser is still expensive, it is perhaps overly pessimistic to assume a massive growth in the number of routing table entries from multihoming punching through aggregated blocks. The number of routes resulting from applying the current CIDR/mhoming techniques to v6 will scale with O(# of multihomed organizations) rather than O(# of NSP's). Planning to engineer for users multihoming cellphone/set top boxes may be overkill. Given we have an linear growth today, it would perhaps seem wise to let the market speak on this matter and see how things shape up. Waiting to see what technologies and techniques are available at the time this starts to be a problem and then applying those techniques to the issue at hand might seem to be a good approach? /vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 17:45:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I0dcN16123 for ipng-dist; Fri, 17 Sep 1999 17:39:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I0dLB16116 for ; Fri, 17 Sep 1999 17:39:22 -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 RAA12277 for ; Fri, 17 Sep 1999 17:39:21 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA05473 for ; Fri, 17 Sep 1999 17:39:21 -0700 (PDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id A0B6E4CE1F; Fri, 17 Sep 1999 20:39:20 -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 UAA13125; Fri, 17 Sep 1999 20:39:16 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id 216A941F16; Fri, 17 Sep 1999 20:39:16 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id 12695400B4; Fri, 17 Sep 1999 20:39:11 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Vijay Gill Cc: Steve Deering , Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Sep 1999 20:39:10 -0400 Message-Id: <19990918003916.216A941F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Vijay Gill writes: > > Given a linear (albeit steeper) curve, Moore's law still outstrips prefix > growth. Why do you assume that routing table calculation is linear? I'm fairly certain it isn't. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 18:25:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I1KnP16212 for ipng-dist; Fri, 17 Sep 1999 18:20:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I1KeB16205 for ; Fri, 17 Sep 1999 18:20:41 -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 SAA00350 for ; Fri, 17 Sep 1999 18:20:41 -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 TAA17992 for ; Fri, 17 Sep 1999 19:20:40 -0600 (MDT) Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA13455; Fri, 17 Sep 1999 18:20:06 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Fri, 17 Sep 1999 18:20:06 -0700 To: Vijay Gill From: Steve Deering Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:09 PM -0400 9/17/99, Vijay Gill wrote: >The IBGP route table of some promising local isps is substantially larger >than the global routing table. Thus ISP's that can barely handle the >current default free routing table need to buy faster boxes. The critical >path is not amount of RAM, but rather the amount of CPU needed to crunch >the routing tables and disseminate the information to peers. I seem to recall (but this may be wrong, or no longer true) that another gating issue was the need for a human in each ISP to make a decision whenever a new prefix is introduced into the DFZ, to decide whether or not they are willing to offer transit service to traffic destined to the new prefix, and to record that decision in a policy database. This would presumably not apply to intra-ISP-only prefixes. >Given that multiple circuits to the enduser is still expensive, it is >perhaps overly pessimistic to assume a massive growth in the number of >routing table entries from multihoming punching through aggregated blocks. Or perhaps it is overly optimistic to assume that circuits will remain expensive enough to discourage major growth in multihoming? >The number of routes resulting from applying the current CIDR/mhoming >techniques to v6 will scale with O(# of multihomed organizations) rather >than O(# of NSP's). Planning to engineer for users multihoming >cellphone/set top boxes may be overkill. I think the consequences of over-engineering in this case are much less severe than the consequences of under-engineering. And we certainly have a history of under-predicting, rather than over-predicting, Internet growth. >Given we have an linear growth today, it would perhaps seem wise to let >the market speak on this matter and see how things shape up. If the growth is only linear today, that may be largely due to the current IP address rationing policies, prefix-length filtering policies, and the costs and complexities for a customer to join the unaggregated- prefix club. Therefore, it seems unwise to assume the same growth rate if those barriers were removed. Anyway, if the market wishes to support large-scale hole-punching for IPv6 site prefixes, there's nothing to prevent that from happening, and I would be happy to see it. However, I think it would be foolish of us not to be prepared for the case that such a market does not materialize, or in which the market price of a "hole" is the dominant disincentive to multihoming. >Waiting to see what technologies and techniques are available at the time >this starts to be a problem and then applying those techniques to the >issue at hand might seem to be a good approach? As Bob Hinden pointed out a few days ago, it is much easier to start with aggregated addresses and then do less aggregated routing on them, than to start with de-aggregated addresses and try to impose aggregation later. 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 Sep 17 19:22:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I2HYB16340 for ipng-dist; Fri, 17 Sep 1999 19:17:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I2HPB16333 for ; Fri, 17 Sep 1999 19:17:25 -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 TAA20712 for ; Fri, 17 Sep 1999 19:17:24 -0700 (PDT) Received: from mailserver-ng.cs.umbc.edu (mailserver-ng.cs.umbc.edu [130.85.100.230]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA24478 for ; Fri, 17 Sep 1999 19:17:24 -0700 (PDT) Received: from localhost (wrath@localhost) by mailserver-ng.cs.umbc.edu (8.9.3/8.9.3) with SMTP id WAA03952; Fri, 17 Sep 1999 22:17:20 -0400 (EDT) Date: Fri, 17 Sep 1999 22:17:20 -0400 (EDT) From: Vijay Gill To: "Steven M. Bellovin" cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <19990918003916.216A941F16@SIGABA.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 17 Sep 1999, Steven M. Bellovin wrote: > In message > , > Vijay Gill writes: > > > > > Given a linear (albeit steeper) curve, Moore's law still outstrips prefix > > growth. > > Why do you assume that routing table calculation is linear? I'm fairly > certain it isn't. The total time taken before a router has converged and has started forwarding packets can be broken down into the following time steps 1 - compute the routing table 2 - populate forwarding tables 3 - update neighbors For this discussion, we are concerned with item #1. It is trivially obvious that (1) is a function (f) of number of prefixes (P). The O(f(P)) being the running time of BGP for purposes of this discussion is fairly non trivial to calculate, and is probably implementation dependent as well, but a BOE using an SPF calculation as a check, gives me a result that O(f(P)) is very likely a polynomial (N^2) and less than exponential. Now, oddly enough, I also happen to have some emperical data points from a study to determine routing scaling for a promising local ISP, and the curve fitting to the dataset results in a polynomial in ^2. These data were collected from instrumenting two fairly well known implementations and were measured using prefix injection mechanisms that generated NLRI and associated attributes that were consistent with the internal IBGP table data for an ISP. This gives a result that given linear growth, and exponential Moore's law, we might be safe for a while. /vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 19:57:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I2roJ16417 for ipng-dist; Fri, 17 Sep 1999 19:53:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I2rgB16410 for ; Fri, 17 Sep 1999 19:53:42 -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 TAA22487 for ; Fri, 17 Sep 1999 19:53:41 -0700 (PDT) Received: from mailserver-ng.cs.umbc.edu (mailserver-ng.cs.umbc.edu [130.85.100.230]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA02303 for ; Fri, 17 Sep 1999 20:53:40 -0600 (MDT) Received: from localhost (wrath@localhost) by mailserver-ng.cs.umbc.edu (8.9.3/8.9.3) with SMTP id WAA04599; Fri, 17 Sep 1999 22:53:37 -0400 (EDT) Date: Fri, 17 Sep 1999 22:53:37 -0400 (EDT) From: Vijay Gill To: Steve Deering cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" 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, 17 Sep 1999, Steve Deering wrote: > At 8:09 PM -0400 9/17/99, Vijay Gill wrote: > I seem to recall (but this may be wrong, or no longer true) that another > gating issue was the need for a human in each ISP to make a decision > whenever a new prefix is introduced into the DFZ, to decide whether or > not they are willing to offer transit service to traffic destined to > the new prefix, and to record that decision in a policy database. This > would presumably not apply to intra-ISP-only prefixes. For most ISP's, the scenario goes something like this: Peering in this case is defined as a settlement free, non-transit connection. ISP A has a peering relationship with ISP B C D and buys transit from ISP P. Now ISP P is a promising local ISP with strong _prefix_ filtering applied to data it accepts from it's "customers", ISP A in this case. ISP P also has peering relationships with B and D. For peering circuits, ISP P applies no filters, relying upon (presumably) clued B and D to do the right thing at the edges. ISP A applies for, and gets a /16 from a registery. ISP A immediately sends mail to a ISP P and tells them to allow the new /16 through the prefix filter P has applied to the BGP session between A and P. A updates the RADB with the /16 as well. Customer C comes in and buys a T-1 from A. A allocates a /24 to C, statically routed. All is good. C now has global transit. C now wants to multihome for purposes of redundancy and gets a T-1 from B as well. But since they've already used numbered their machines from the /24 allocated by A, they tell B that they'll just use that ip block. B says ok, sets up a BGP session with C Now, Customer C's /24 is reannounced to A and to B both of them annouce the /24. P accepts the /24 since it is already covered by the /16 in the filter for C. B accepts it because it has a peering relationship with A. Repeat till you run out of /16. There is only one human step in the way and assuming P has setup an auto filter generator (with sanity checking), even that step is now just a mouse click away. > >Given that multiple circuits to the enduser is still expensive, it is > >perhaps overly pessimistic to assume a massive growth in the number of > >routing table entries from multihoming punching through aggregated blocks. > > Or perhaps it is overly optimistic to assume that circuits will remain > expensive enough to discourage major growth in multihoming? I don't see many people multihoming their houses with a DSL link to provider A and a cable link to provider B. It is fairly time intensive to setup and configure on part of all parties involved. Also, most people don't have dual phone lines for redundancy, but rather for convenience. And phonelines have lifeline services. I just don't see multihoming every maytag and subzero unit. > >The number of routes resulting from applying the current CIDR/mhoming > >techniques to v6 will scale with O(# of multihomed organizations) > rather >than O(# of NSP's). Planning to engineer for users multihoming > >cellphone/set top boxes may be overkill. > > I think the consequences of over-engineering in this case are much less > severe than the consequences of under-engineering. And we certainly have > a history of under-predicting, rather than over-predicting, Internet growth. Growth will slow down as the market saturates. The upper steady state bound is the GDP of the nation. _Bandwidth_ demand is separate from this issue. > If the growth is only linear today, that may be largely due to the > current IP address rationing policies, prefix-length filtering policies, > and the costs and complexities for a customer to join the unaggregated- > prefix club. Therefore, it seems unwise to assume the same growth rate > if those barriers were removed. Why should some of those policies be changed for v6 when they are in place for v4? Specially things like prefix-length filtering, prefix filtering and ASN requirements? These things serve as a small buffer against things like 7007 and their ilk. > Anyway, if the market wishes to support large-scale hole-punching for > IPv6 site prefixes, there's nothing to prevent that from happening, and > I would be happy to see it. However, I think it would be foolish of us > not to be prepared for the case that such a market does not materialize, > or in which the market price of a "hole" is the dominant disincentive to > multihoming. The market is driven by money. ISP's will go out of business if they cannot support the routing table growth and as such, there is a strong motivator to keep things under control. It is completely clear from discussions here that there is not a clue as to how to make multihoming in V6 work and be consistent with the desire for super-aggregation. Maybe some more operational experience with v6 will result in a method that works. Maybe the problem is intractable. > As Bob Hinden pointed out a few days ago, it is much easier to start with > aggregated addresses and then do less aggregated routing on them, than to > start with de-aggregated addresses and try to impose aggregation later. This is would be consistent with the post-CIDR allocation policies applied today. /vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 20:49:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I3jqC16492 for ipng-dist; Fri, 17 Sep 1999 20:45:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I3jkB16485 for ; Fri, 17 Sep 1999 20:45:46 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id UAA19786 for ipng@sunroof.eng.sun.com; Fri, 17 Sep 1999 20:43:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I0IUB16035 for ; Fri, 17 Sep 1999 17:18: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 RAA22631 for ; Fri, 17 Sep 1999 17:18:29 -0700 (PDT) Received: from turbot.pdc.kth.se (turbot.pdc.kth.se [130.237.221.42]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA05272 for ; Fri, 17 Sep 1999 18:18:28 -0600 (MDT) Received: (from d95-mah@localhost) by turbot.pdc.kth.se (8.8.8+Sun/8.8.7) id CAA21068; Sat, 18 Sep 1999 02:17:51 +0200 (MET DST) To: Quality Quorum Cc: Brian E Carpenter , Bradley Reynolds , Jessica Yu , black@layer8.net, ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: From: Magnus Ahltorp Content-Type: text/plain; charset="iso-8859-1" Content-Language: en Date: 18 Sep 1999 02:17:51 +0200 In-Reply-To: Quality Quorum's message of "Thu, 16 Sep 1999 19:06:51 -0400 (EDT)" Message-ID: Lines: 24 X-Mailer: Gnus v5.6.45/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One can build 3 level device described there with 24,4 and 4 bits > per level. Then one would need only 48M of 25-bit words in order to > handle ALL class A, B and C routes plus 1M of longer routes. [...] > In other words, it seems like we can disregard the necessity of > aggregation as a primary requirement to any scheme being discussed. - > this is a point I was trying to make. Aggregation is not only a way to make the routing tables smaller, it is also a way to push many routing decisions from the DFZ to the TLA routers and below. A small mumber of routes in the DFZ will the tables quite stable. This is not the case if every site in the world is going to be in the routing table, instead, the routing table will change all the time, making the routers spend a lot of time updating the tables. Fast route lookup algorithms are necessary, not to allow for bigger routing tables, but to allow an insane amount of packets per second. Magnus Ahltorp Department of Teleinformatics Royal Institute of Technology Stockholm, Sweden -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 20:49:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I3low16518 for ipng-dist; Fri, 17 Sep 1999 20:47:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I3leB16511 for ; Fri, 17 Sep 1999 20:47:40 -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 UAA08226 for ; Fri, 17 Sep 1999 20:47:39 -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 VAA09556 for ; Fri, 17 Sep 1999 21:47:38 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id NAA27895; Sat, 18 Sep 1999 13:47:11 +1000 (EST) Date: Sat, 18 Sep 1999 13:47:11 +1000 (EST) From: Peter Tattam To: Richard Draves cc: "'Steve Deering'" , Ben Black , ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515A0A@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 17 Sep 1999, Richard Draves wrote: > > Me: "I don't know what the current growth rate is, or how > > much latent > > demand has been suppressed by the current difficulties > > in getting > > a new prefix advertised globally. Do you have any data > > on that?" > > I don't know either, but I suspect that the latent demand may be > significant. > > So another way of looking at this is, if we provide reasonable support for > multihoming in IPv6 without the need for a globally visible prefix (hard to > get in v4), this could give people a reason to use IPv6. > > Rich Would a quick measure be the number of A-S numbers? Or are people using private A-S space, or non BGP solutions to multi-homing. I'm sure there would be plenty of people willing to provide statistics on the size of the DFZ BGP tables as viewed by them. For us I am told that the Aus-only BGP table will fit in < 32Meg, for a full worldwide table, it is more, but not significantly so, but certainly not as large as it would be without CIDR. One thing I can't answer is if CIDR is working fully. I.e. are there sites that think they are multihomed but indeed are not because their routes are not really being fully advertised in the DFZ due to aggregation. I could envisage this happening. If it were, it would be a rude awakening for us all. 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 Fri Sep 17 20:56:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I3tV516546 for ipng-dist; Fri, 17 Sep 1999 20:55:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I3tQB16539 for ; Fri, 17 Sep 1999 20:55:26 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id UAA19825 for ipng@sunroof.eng.sun.com; Fri, 17 Sep 1999 20:53:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I20hB16297 for ; Fri, 17 Sep 1999 19:00:43 -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 TAA19646 for ; Fri, 17 Sep 1999 19:00:42 -0700 (PDT) Received: from turbot.pdc.kth.se (turbot.pdc.kth.se [130.237.221.42]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25001 for ; Fri, 17 Sep 1999 20:00:42 -0600 (MDT) Received: (from d95-mah@localhost) by turbot.pdc.kth.se (8.8.8+Sun/8.8.7) id EAA21276; Sat, 18 Sep 1999 04:00:38 +0200 (MET DST) To: Jessica Yu Cc: Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: <199909171802.OAA25854@cannes.aa.ans.net> From: Magnus Ahltorp Content-Type: text/plain; charset="iso-8859-1" Content-Language: en Date: 18 Sep 1999 04:00:38 +0200 In-Reply-To: Jessica Yu's message of "Fri, 17 Sep 1999 14:02:40 -0400" Message-ID: Lines: 44 X-Mailer: Gnus v5.6.45/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One issue with tunnels is that it will make packets which would > normally fit in max MTU size exceed the max MTU size due to the > adding of IP header for encapsulation. This will cause routers > to waste resource for packet fragmentation which led to very > poor performance. Many Tunnel based VPN users suffer from the > problem. This is not true. In IPv6, routers do not fragment packets. > Another issue with tunnel is the performance. It certainly > cause router resource to encapsulate and decapsulate every single > packet using tunnels. A large ISP's border router (or customer > aggregation router) usually connects hundreds of end customers. > It has scaling impact to have that router to do all these > extra resource comsuming tasks. Also, the performance would be > bad for the multihoming customer as well with the tunnel. When > the tunnel is in use, that's means one connection is down, all > the traffic will concentrate on the other sole connection and > the sole poor router. Adding more burden on it (it has to > decapsulate every packet) it just not wise. I fail to see the performance problem. When encapsulating a packet in a IPv6 packet, there is *one* field (the size) that needs to be filled in. The rest of the packet is static for a specific tunnel. It will cost one more routing table lookup, but not more. If the current routers you're using cannot do this simple operation in full speed, go buy one that will. If the router manufacturer is really clever, even the extra lookup is not needed. Decapsulating packets is even simpler. It's just a matter of stripping the header off the packet an reinserting it into the routing table lookup. Cost: one more routing table lookup. > In summary, RFC2260/itojun does not seem to provide better > redundancy than SMPL. The problem associated with tunnel mechanism > should not be overlooked. Yes it does, since you can assign multiple addresses to each host. Magnus Ahltorp Department of Teleinformatics Royal Institute of Technology Stockholm, Sweden -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 21:00:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I3udI16576 for ipng-dist; Fri, 17 Sep 1999 20:56:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I3uVB16569 for ; Fri, 17 Sep 1999 20:56:32 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id UAA19854 for ipng@sunroof.eng.sun.com; Fri, 17 Sep 1999 20:54:28 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I2k2B16380 for ; Fri, 17 Sep 1999 19:46: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 TAA12614 for ; Fri, 17 Sep 1999 19:46:01 -0700 (PDT) Received: from turbot.pdc.kth.se (turbot.pdc.kth.se [130.237.221.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA28527 for ; Fri, 17 Sep 1999 19:46:01 -0700 (PDT) Received: (from d95-mah@localhost) by turbot.pdc.kth.se (8.8.8+Sun/8.8.7) id EAA21344; Sat, 18 Sep 1999 04:45:51 +0200 (MET DST) To: Ben Black Cc: Richard Draves , "'Steve Deering'" , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: <4D0A23B3F74DD111ACCD00805F31D81014515A0A@RED-MSG-50> <19990917164739.L595@layer8.net> From: Magnus Ahltorp Content-Type: text/plain; charset="iso-8859-1" Content-Language: en Date: 18 Sep 1999 04:45:51 +0200 In-Reply-To: Ben Black's message of "Fri, 17 Sep 1999 16:47:39 -0700" Message-ID: Lines: 33 X-Mailer: Gnus v5.6.45/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I don't know either, but I suspect that the latent demand may be > > significant. > > > > Based on what? If multihoming would be as cheap as buying IP connectivity from two providers, and not having them care about you meing multihomed, I know many sites in Sweden that would be multihomed. As far as I know, there is only one site (not counting major operators) that is multihomed in Sweden. Not even normal ISP:s are multihomed. Please give me counterexamples. I don't think Sweden is the only country with this problem. > > So another way of looking at this is, if we provide reasonable support for > > multihoming in IPv6 without the need for a globally visible prefix (hard to > > get in v4), this could give people a reason to use IPv6. > > > > Heh, I think it is pretty clear at this point it isn't easier in IPv6. "Isn't easier" = "is harder or equal". It cannot be harder, since the same addressing policies can be applied to IPv6. I don't really think it's equal, since it is easier to get several addresses for one host, not because it's mandatory to allow that, but since the address space is larger. Magnus Ahltorp Department of Teleinformatics Royal Institute of Technology Stockholm, Sweden -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 21:19:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I4GCX16604 for ipng-dist; Fri, 17 Sep 1999 21:16:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I4G3B16597 for ; Fri, 17 Sep 1999 21:16:04 -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 VAA09215 for ; Fri, 17 Sep 1999 21:16:02 -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 WAA13415 for ; Fri, 17 Sep 1999 22:16:01 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id OAA29787 for ; Sat, 18 Sep 1999 14:15:59 +1000 (EST) Date: Sat, 18 Sep 1999 14:15:59 +1000 (EST) From: Peter Tattam To: IPNG Mailing List Subject: Closer examination of aggregation. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If we go with the assumption that aggregation is essential for managing future growth (I don't want to argue this point, but rather treat is as an assertion for the benefit of this discussion), I wonder if aggregation can be structured in such a way as to be able to contain the hole punching that might happen in a less regulated internet. The way I understand aggregation is that TLAs are either regionally based, or mega-ISP based. If the aggregation model of TLA allocation was fine tuned and mapped more closely the physical topology of the internet, could it not be arranged so that multihoming would continue to function in a more efficient manner. I see the real enemy of successful aggregation being cases where a global organization wants to have address allocation which is independent of the overall physical topology. I would propose then that if an ISP wants to operate in multiple regions then they should use address allocation that is applicable to that region. Since we would consider that multihoming is likely to grow significantly in the 2nd or 3rd tier ISP, it should be able to be arranged that multihoming be confined to ISP's within that region. Given this case, one strategy would be to ensure that the DFZ need not require hole punching at all even though ISP further down the tree hole puch to the heart's desire. It's just a matter of arranging the addresses to minimize the hole punching in the DFZ. This has been expressed in one form or another, but I don't believe the selection of TLAs and structuring at the top level has been sufficiently well explored to get the best benefit of the aggregation model. This may of course be a totally unrealistic view of the polotics of the internet, & I suspect the egos of some ISPs might be severely offended by the notion that they can't have a world wide TLA, but operate with a number of smaller NLAs. Another possibility would be to treat the internet as two parts. Those that want to be multi-homed and those that don't, and maintain two independent DFZs for the purpose. Anyway, my main suggestion is that it would be important for us to examine *very* carefully how the TLA/NLA model should work for future growth. 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 Fri Sep 17 23:02:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I5tXJ16667 for ipng-dist; Fri, 17 Sep 1999 22:55:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I5tKB16660 for ; Fri, 17 Sep 1999 22:55:20 -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 WAA12324; Fri, 17 Sep 1999 22:55:18 -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 XAA24831; Fri, 17 Sep 1999 23:55:13 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1045:200:ff:fe00:0]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id OAA25168; Sat, 18 Sep 1999 14:45:56 +0900 (JST) Date: Sat, 18 Sep 1999 14:26:56 +0900 Message-ID: <14307.8864.664575.10612R@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik.Nordmark@eng.sun.com Cc: Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Thu, 16 Sep 1999 15:00:31 -0700 (PDT)" References: <199908241137.NAA09294@givry.inria.fr> User-Agent: Wanderlust/2.2.1 (Wild World) 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: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 16 Sep 1999 15:00:31 -0700 (PDT), >>>>> Erik Nordmark said: > Seriously, we can certainly try to specify the interaction of the different > ways to specify ifindex and scope id. But I'd appreciate a complete proposal > containing all the rules. Okay, I'll try to make a proposal. > The fact that sin6_scope_id applies to bind() should really be part of > the basic API. Does anybody want to send a comment to XNET for that one? Let me make the situation clear...is the basic API now handled in XNET? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Sep 18 00:48:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I7hqr16701 for ipng-dist; Sat, 18 Sep 1999 00:43:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I7heB16694 for ; Sat, 18 Sep 1999 00:43:40 -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 AAA15742 for ; Sat, 18 Sep 1999 00:43:40 -0700 (PDT) Received: from hefeweizen.linnaean.org (hefeweizen.linnaean.org [128.52.224.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA07125 for ; Sat, 18 Sep 1999 01:43:39 -0600 (MDT) Received: from neuralgia.linnaean.org (neuralgia.linnaean.org [128.52.224.5]) by hefeweizen.linnaean.org (8.9.3/8.9.3/AI2.13/linnaean.master:2.3) with ESMTP id DAA29770; Sat, 18 Sep 1999 03:43:29 -0400 (EDT) Received: (from hag@localhost) by neuralgia.linnaean.org (8.9.3/8.9.3/AI2.12/linnaean.client:2.1) id DAA19314; Sat, 18 Sep 1999 03:43:29 -0400 (EDT) Message-Id: <199909180743.DAA19314@neuralgia.linnaean.org> X-Authentication-Warning: neuralgia.linnaean.org: hag set sender to hag@linnaean.org using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Vijay Gill Cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: References: X-Mailer: VM 6.34 under Emacs 20.3.1 Reply-To: Daniel Hagerty From: Daniel Hagerty Date: Sat, 18 Sep 1999 03:43:29 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't see many people multihoming their houses with a DSL link to > provider A and a cable link to provider B. It is fairly time intensive to > setup and configure on part of all parties involved. Also, most people > don't have dual phone lines for redundancy, but rather for convenience. > And phonelines have lifeline services. I just don't see multihoming every > maytag and subzero unit. You must be living on a different internet than I do, or at least do different things with it. The current, IPv4 based internet has a number of limitations for what one sees as the ultimate goal of it. Let's not worry about all this fancy talk about aggregation and algorithm run times, yada, yada, yada. What's the idea here again? The variety of applications (with different needs of the underlying transport) that people hope to haul across this bearer service is always growing. The unachievable goal is zero delay and infinite end-to-end potentially bidirectional bandwidth through the network. The customer is expecting the technology to work with the reliability of a telephone, if not better. If a person calls "the data-services company" and the answer to "it doesn't work" is a hurricane (current events for US East), they'll often accept that. They won't take much short of that. In short, the end user only cares about the application. They don't care about the network connecting them; it's supposed to be "invisible". The result is that end to end quality of service for a given application can be quite variable over any time granularity. Personally, I fit the description of people you don't see many of. I spend a lot of time typing on distant computers using this internet thang. Trust me. It can suck, and I'm far from the only one who thinks so. This application has very low tolerance to delay, due to the human at the local keyboard & display, engaged in a tight feedback loop with the distant machine. Life as an end customer of an IPv4 internet provider in 1999, interested in the this application "typing" can be damned frustrating at times. It often consists of suffering from pessimal routing policies of different ASes in relation to the actual available connectivity and the service needs of my application's traffic. For US$90 a month, one can get connectivity over two physical plants to two different, high-Kwality ISPs, and getting there isn't *too* much pain to setup. (as long as you act clueless and temporarily run win98 for the cable modem guys... ;-) Being in this position I can select the provider with a better path for what I'm doing at the moment. I know that I'm not the only one doing this sort of thing. Other than knowing how to deal with two interfaces, and how to pick and choose routing, and grok random failures due to poor source address selection, it can be setup as a windows box and do small-values of reasonable with routing. More reasonable things can do even more. You will note that the problems experienced are all end host issues; the providers have no knowledge of one another. Since that the only way that seems to work to provide high reliability in the backend tends to involve two of the object, what makes you think the local-loop and the terminating provider are any different? As you pointed out, dealing with most of the issues with a multihomed customer can be automated to a few mouse click based decisions by the human (given development), and auto-provisioned from there. So can we stop beating this dead horse? There are a number of much harder issues that go hand in hand with the technology; TCP session address renumbering, multihomed *host* address selection, provider network management issues and how it relates to customer needs, etc. - Just another guy in the trenches -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 18 02:22:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8I9JQe16732 for ipng-dist; Sat, 18 Sep 1999 02:19:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8I9JHB16725 for ; Sat, 18 Sep 1999 02:19: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 CAA17970 for ; Sat, 18 Sep 1999 02:19:16 -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 DAA15588 for ; Sat, 18 Sep 1999 03:19:15 -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 LAA14350; Sat, 18 Sep 1999 11:19:14 +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 LAA30184; Sat, 18 Sep 1999 11:19:13 +0200 (MET DST) Message-Id: <199909180919.LAA30184@givry.inria.fr> From: Francis Dupont To: Alain Durand cc: ipng@sunroof.eng.sun.com Subject: Re: source routing & multi-homing In-reply-to: Your message of Fri, 17 Sep 1999 17:42:18 +0200. <4.2.0.58.19990917173705.00b22ba0@brahma.imag.fr> Date: Sat, 18 Sep 1999 11:19:13 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Trying to be imaginative to find solutions for multi-homing, I wonder, is there something in the specs to prevent a router to include a source route option in a transiting packet? => include == add ? I have a proposal that could use such a mechanism, but before I go any further to explore it, I would like to know if there is a one line killer argument against it. => this breaks end-to-end security. The correct way to change routing is to encapsulate the packet (or to use mobility bindings). 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 Sat Sep 18 06:22:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8IDIrn16807 for ipng-dist; Sat, 18 Sep 1999 06:18:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8IDIiB16800 for ; Sat, 18 Sep 1999 06:18: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 GAA01861 for ; Sat, 18 Sep 1999 06:18:43 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05945 for ; Sat, 18 Sep 1999 07:18:43 -0600 (MDT) Received: from world.std.com (qqi@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id JAA13914; Sat, 18 Sep 1999 09:18:42 -0400 (EDT) Received: from localhost (qqi@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id JAA28862; Sat, 18 Sep 1999 09:18:31 -0400 (EDT) Date: Sat, 18 Sep 1999 09:18:31 -0400 (EDT) From: Quality Quorum To: Peter Tattam cc: IPNG Mailing List Subject: Re: Closer examination of 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 > Another possibility would be to treat the internet as two parts. Those that > want to be multi-homed and those that don't, and maintain two independent DFZs > for the purpose. What about enforcing "restricted multihoming" in the following sense: There ar two primary reasons for multihoming: (a) fault tolerance, (b) big organizations with big local nets which maintain multiple connections to the big net. (a)Fault tolerance has following characteristics: 1. During normal operation only one (primary) route is advertized (and (supposedly) is aggregated) to DFZ. 2. Total amount of organizations with necessity to go into DFZ for fault tolerance reason is low. 3. Probability of major simultaneous failures is low: if probability of single failure is p, then probability of n simultaneous failures is pow(p,n), etc.. 4. Backup ISP should aggregate routes from other ISPs (in any case SLA part should not be visible in DFZ). Note: it does not prevent multihoming below SLA: it just establish the rule that ISP have insulate it from DFZ. So, it seems to me that Internet can easily manage this kind of route spilling. There is a number of measures which will guarantee problemless fault tolerance related multihoming for years and years to come: 1. Make customers pay for this service. 2. Make ISPs pay for resources: establish fees per every potential non-aggregated route to be spilled. 3. Require DFZ routers to handle 1M 48-bit routes from the start and be upgradable to 2M 48-bit routes. (b)Big organizations will be required to split there networks into subnets with each subnet being single-homed wrt DFZ. So, how this approach will affect various groups of customers ? 1. Most customers are multihomed within big ISPs anyway, so corresponding routes have no chance of spillage into DFZ and these customers will not be affected by these rules. 2. Customers who really want fault tolerance at the DFZ scale are able to pay for it. 3. Big organizations have to have routers :):):):):) - the only difference is that subnets will have different global prefix - and who cares about it - static DNS will handle it perfectly well and local routers will have no problem handling a few but loooooong routes. 4. Multihoming for traffic optimization should be outlawed anyway. Opinions ? > Peter Thanks, Aleksey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 18 06:59:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8IDtis16836 for ipng-dist; Sat, 18 Sep 1999 06:55:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8IDtZB16829 for ; Sat, 18 Sep 1999 06:55: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 GAA23873 for ; Sat, 18 Sep 1999 06:55:35 -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 GAA15702 for ; Sat, 18 Sep 1999 06:55:34 -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 PAA18277; Sat, 18 Sep 1999 15:55:24 +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 PAA29723; Sat, 18 Sep 1999 15:55:23 +0200 (MET DST) Message-Id: <199909181355.PAA29723@givry.inria.fr> From: Francis Dupont To: Kazuaki Tsuchiya cc: ipng@sunroof.eng.sun.com, imv@kame.net Subject: Re: Toolnet6 installation workshop In-reply-to: Your message of Tue, 14 Sep 1999 21:47:19 +0900. <199909141245.VAA13754@newton.ebina.hitachi.co.jp> Date: Sat, 18 Sep 1999 15:55:21 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Toolnet6 installation workshop It is a transition tool based on the "Bump-in-the-stack (BIS)" draft argued at ngtrans-wg. => have you IPv6 mobility support (for instance correspondent support) ? I am not a BIS expert (on *BSD we have dual stacks) but I believe if you know how to manage extra headers/options in the outer IPv6 level then you can transparently use some parts of IPv6 mobility support. NIC: 3Com Corp. EtherLink III (3C589C, 3C589D, 3CCE589ET, 3CXE589ET,...) NE2000 Compatible Adapter (D-Link Systems Inc. DE660T/J Ethernet Adapter, ...) => I have both and I should bring extra NICs for the TAHI test event (routers are finer with more than one LAN :-). Thanks Francis.Dupont@inria.fr PS: MSR IPv6 for WNT4.0/W2000 has correspondent support but I don't know if a W95/W98 IPv6 device with this is currently available. PPS: about IPv6 restriction: we have IPv4 over IPv6, in fact X over Y is easy and even very easy when X != Y... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 18 16:24:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8INMNF17146 for ipng-dist; Sat, 18 Sep 1999 16:22:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8INMEB17139 for ; Sat, 18 Sep 1999 16:22: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 QAA23490 for ; Sat, 18 Sep 1999 16:22:10 -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 QAA20852 for ; Sat, 18 Sep 1999 16:22:10 -0700 (PDT) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Sun, 19 Sep 1999 00:21:21 +0100 Date: Sun, 19 Sep 1999 00:21:56 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Jessica Yu cc: black@layer8.net, ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <199909171445.KAA25398@cannes.aa.ans.net> 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 Fri, 17 Sep 1999, Jessica Yu wrote: > Yes, there has been fiber cuts which affect part of the service area > of some ISPs. But to put this into the context of our discussion, this > does not mean that the ISP is completely isolated so that it can not > announce the aggregate including the multihoming site (customer-A in our > example) out to the Internet. So the customer can still utilize the 2nd > ISP for its connectivity. The examples I gave to answer your question are where this did not occur. L. interesting definition of 'isolated'. > Also, there is highly a chance that a massive fiber cut in an area > effects mutliple ISPs in the area, so a multihoming site is very likely > to loose all its connections even with today's arrangement. > > By the way, your URL does not seems to pointing to something relevant. > > > --jessica > > Date: Thu, 16 Sep 1999 22:01:45 BST > To: Jessica Yu > cc: black@layer8.net, ipng@sunroof.eng.sun.com > > From: Lloyd Wood > Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" > > Return-Path: L.Wood@surrey.ac.uk > X-Sender: eep1lw@petra.ee.surrey.ac.uk > Reply-To: Lloyd Wood > In-Reply-To: <199909162034.QAA24356@cannes.aa.ans.net> > 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 > Content-Length: 697 > > On Thu, 16 Sep 1999, Jessica Yu wrote: > > > In the last 2-3 years, how many times a good quality ISP went complete > > isolated from the Internet? I do not recall one. > > That is a meaningless statement, since good-quality ISPs by definition > don't have isolation outages. I'm pretty sure an entire redneck US > state accidentally got cut off from the rest of the planet for sixteen > hours by a backhoe at one point. > > A more concrete counterexample? > http://www.ntk.net/index.cgi?back=archive99/now0226.txt&line=18#l > or search www.ntk.net for 'Telehouse'. > > L. > > there are still too many chokepoints, and not enough redundant meshing. > > 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 > -------------------------------------------------------------------- > 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 Sat Sep 18 16:27:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8INQF317164 for ipng-dist; Sat, 18 Sep 1999 16:26:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8INQ5B17157 for ; Sat, 18 Sep 1999 16:26:05 -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 QAA12330 for ; Sat, 18 Sep 1999 16:26:06 -0700 (PDT) Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA10504 for ; Sat, 18 Sep 1999 17:26:05 -0600 (MDT) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Sun, 19 Sep 1999 00:25:21 +0100 Date: Sun, 19 Sep 1999 00:25:58 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Bill Fenner cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard In-Reply-To: <199909171617.JAA25577@windsor.research.att.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 Fri, 17 Sep 1999, Bill Fenner wrote: > Thanks to Harald for pointing out that {} won't work either. How about > some innocuous character that may not appear in hostnames, like a comma? > > http://,FEDC:BA98:7654:3210:FEDC:BA98:7654:3210,:80/index.html > > It's not particularly pretty, but you're never really supposed to use > it very often anyway. commas break URL parsing in many text-to-html converters, including Mhonarc (which can't handle news.com numerical urls as a result, e.g. http://www.news.com/News/Item/0,4,28358,00.html?st.ne.1.head ) You'd end up with converted documentation with truncated hostnames. Next! L. > I'm afraid that I don't really buy the argument that there's no reason > not to make this harder to use for some population because you're not > supposed to use it anyway. If it's possible to make it easier to use > and not damage the proposal, then why not do so? > > Bill 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 Sat Sep 18 23:08:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8J65be17428 for ipng-dist; Sat, 18 Sep 1999 23:05:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8J65SB17421 for ; Sat, 18 Sep 1999 23:05:28 -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 XAA03804 for ; Sat, 18 Sep 1999 23:05:26 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA05138 for ; Sat, 18 Sep 1999 23:05:24 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id GA05713; Sun, 19 Sep 1999 16:05:05 +1000 (from kre@munnari.OZ.AU) To: Lloyd Wood Cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard In-Reply-To: Lloyd Wood's message of "Sun, 19 Sep 1999 00:25:58 +0100." References: Date: Sun, 19 Sep 1999 16:05:04 +1000 Message-Id: <2705.937721104@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 19 Sep 1999 00:25:58 +0100 (BST) From: Lloyd Wood Message-ID: | commas break URL parsing in many text-to-html converters, While I think comma gains nothing at all over [], this is no objection to it at all. Keeping IPv6 address literals away from anwhere that any kind of URL trawler might find them, and wreaking havoc if that ever happens, has to be an aim. For v6 we really have to move to a position where no-one ever embeds literal addresses anywhere where there is any other choice (almost no matter how difficult the other choice may be). That is, we have to make it as cheap as possible to change the things when needed - and having literal addresses in e-mail archives is one of those places where it is essentially impossible to update to the new address. I think it would be a very good thing if doc parsers that hunt for URLs in various files were never updated to handle IPv6 literal addresses correctly, whatever syntax is adopted. Clearly it is impossible to prevent someone writing one in some e-mail, or even in an html doc (editors tend not to have very many restrictions) but we can make it almost useless for anyone to do so ... that is, I could e-mail a literal IPv6 URL to comeone who could cut/paste that into their browser, if that's what is necessary to debug some problem, but if that e-mail ends up in some service organisation's archives, the URL should not forever after be just "clickable" for anyone who happens to chance across it. I can sort of see (and concede that I lost the argument on) the need to have IPv6 addresses pasteable into URLs (so the ':' syntax has to remain a part of it) - I am not convinced, but I understand the argument - but there seem to be way too many people with some desire to make literal IPv6 URLs work just like any otehr URLs. That's not just unnecessary, it is positively the wrong thing to do. These things need to be understood, and correctly parsed, only by the kind of browser that someone diagnosing problems or doing configuration would use (that is, any general gui or text based browser type thing), by the kind of equipment that will be fixed or configured by such means (which necessarily must be IPv6 based equipment), and perhaps by any proxy that might come between. Nothing else at all (including all kinds of URL converters, html parsers, ...) needs to be able to handle the things at all, and it is much better for the net as a whole if none of it ever does. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Sep 19 00:18:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8J7Fij17495 for ipng-dist; Sun, 19 Sep 1999 00:15:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8J7FZB17488 for ; Sun, 19 Sep 1999 00:15:36 -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 AAA05661 for ; Sun, 19 Sep 1999 00:15:35 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA12104 for ; Sun, 19 Sep 1999 00:15:35 -0700 (PDT) Received: from endor.eas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id DAA08735; Sun, 19 Sep 1999 03:15:29 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.eas.harvard.edu (8.8.8/8.8.8) id DAA19582; Sun, 19 Sep 1999 03:15:28 -0400 (EDT) Date: Sun, 19 Sep 1999 03:15:28 -0400 (EDT) Message-Id: <199909190715.DAA19582@endor.eas.harvard.edu> To: IPng@sunroof.eng.sun.com Subject: portable identifiers for session stability, multi-homing, etc. (Was: AN interesting article. FYI...) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [combining responses] nisse@lysator.liu.se (Niels Mvller) wrote: |Is there any particular reason why not allocate the identifiers as a |subspace of the IPv6 address spase (outside of the aggregatable |unicast space, of course)? As I pointed out, the existing space could be split on one bit to do exactly that. I did not make that part of the base proposal because I feared it would meet with objections that the routable space absolutely needs every one of the existing bits. It would also make the approach depend on the cooperation of an addressing authority where otherwise it need not. |I imagine that would make gradual |deployment easier; to a host that doesn't know how to map identifier |addresses, those addresses will simply appear to be unreachable. (It's |even conceivable to let the local router do the mapping and |source-route them to the right aggregatable address). I believe I covered this. |> I propose a set of servers, similar in many respects to the DNS but |> designed to facilitate efficient and secure dynamic data updates |> throughout its fabric while also allowing easy and transparent |> splitting of zones (i.e., dynamic delegation) to insure scalability. | |I suspect this is the difficult part of it all. I believe I mentioned that as well. :) |You need some sort of |hierarchy in order to distribute management and allocation of the |"identity addresses", where higher nodes delegates part of the space |to lower nodes, just like in DNS. You need (or at least would like) a computational hierarchy. I'm not sure you need or want a hierarchy of providers if it can be avoided. |And there are some other interesting |points comparing this to DNS: | |1. Switching "identity provider" is analogous to switching DNS | provider. I.e. it implies that your identity or FQDN changes, as | the point where it is attached in the delegation hierarchy changes. You are introducing a concept which virtually defeats the purpose of my proposal. I think this is a situation that does not benefit from multiple administrations. |2. Currently, DNS-space is not much of a hierarchy. It seems all | "sites" buy a name of the type "foo.com.", and put all externally | visible machines there. Really large sites or corporations may have | one more step of internal delegation. The point is, that this | appears to actually work. So perhaps it's good enough to have a flat | identity space, or at most two-level space? As I explained, it would be best to have a space which can split transparently as it grows, much like DBM hash key space. It can start out with a single server and grow as necessary. Growth does not imply new political registry entities, just more machines. At least in an ideal world. But I suppose we start getting back to monopoly arguments... |Another question is exactly what advantage the short "binary" |addresses have over dns names. You say that they fit easier into |packet headers, tcp control blocks, etc. They also fit the existing socket API with no changes. In other words, my proposal could work today without wholesale changes above the stack. |If that is the main reason to |use them rather than FQDN:s, perhaps we could get away with |representing a FQDN with its md5 sum, and we will have at least one |step in the lookup process for free. Or if that won't work, I think |the reason why may give some information about the nature of the |problem. You seem to be talking about a somewhat different model where user-level applications probably interact with the mapping. I'm not saying this isn't a useful model, but it probably has little to do with the one I proposed. |Hmm. Anyway, I don't think this problem will be solved by me or |anybody else popping ideas from their head. Well, if the ideas don't come from anybody's head, where will they come from? Even big committees get their ideas from the members' heads... I continue to be perplexed by the untouchable status accorded to this issue. Thomas Narten wrote: |A few comments. Unfortunatley, I don't have the time right now to |respond to all of your proposal in detail, No problem. If there is in fact interest, I'm sure others will respond. :) |but I will observe that |there are a number of details missing. Unfortunately, the devil is in |the details and without the details, its hard to call out specific |issues. Actually, I believe I outlined an approach at a sufficient level of detail for a skilled and motivated implementor to prototype a sample in a few weeks. A key point is that most of the protocol interactions are sufficiently similar to existing material that they (and even the code to implement them) could be readily borrowed. I'm not sure that it benefits a discussion to start with a significantly lower-level description than what I gave, but perhaps that's because I'm too familiar with the kind of code in question. |Also, you raise an oft-expressed feeling that all that needs to happen |is for some folks to go off and design such a system. Not at all. If I believed that this were true then I would happily design and implement such a system. We first should answer the questions I posed: >>>Do we wish to make it so or not? If not, why not? If so, what price >>>are we willing to pay resource-wise? There is no point in implementing a solution if in fact _any_ solution is already deemed undesirable simply because it is a solution or because it has any non-zero cost. I happen to think that it would be very useful to at least get the hooks for some kind of portable identifiers (it certainly doesn't have to be my proposal) into the protocol before extensive deployment makes retrofit impossible, but others may well disagree that it is worth the price. However, without something along these lines, useful features like multi-homing may well remain expensive value-added services available only to big/rich players. This would be unfortunate, but such is life... |And, (and this is _key_) would |the resultant system be any better than what we already have in terms |of total overall cost, understandabilty, robustness, operational |complexity, etc? It's extremely difficult to define "better" in this context without knowing for whom it is better. Portable identifiers offer benefits mainly to end users in the form of flexibility. They offer little to ISPs and may even be a negative. Some of the other attributes you site are mainly the concern of those ISPs. It will always be possible for someone in some camp to claim that there is absolutely no benefit _for them_ in portable identifiers and thus no tradeoff with any kind of cost is allowable to achieve them. To understand total _overall_ cost we would have to know how much non-portable addresses are going to cost end users. That is very hard to quantify, though I maintain that it is by no means negligible. |I often think that one of curses of IPv4 is that |both its strengths and weaknesses are well understood. People tend to |focus on the weaknesses (e.g., non-portable addresses) and |consequently the grass looks greener on the other side of the hill. Oddly, I've always looked at portable addresses as a strength of IPv4. I guess it's just a matter of how long one has been involved... |Case in point: if we separate the identifier and locator portions of |an address, one almost certainly needs a way of mapping the identifier |into an locator. This problem is one that we don't know if it can be |reasonably solved without seeing the details of a specific |proposal. Just saying "servers do the mapping" is hand waving. Ah, but I have a really _good_ hand waving argument. It's not an argument that what I suggested can be done, but it's the next best thing. Again: any argument that we can't provide a mapping from one fixed-length identifier to another with current DNS-like technology in the face of currently anticipated levels of renumbering is equally an argument that we can't support the DNS itself. If we can't support the DNS then IPv6 is dead. On the other hand, assuming IPv6 is not dead and the DNS can work then we can certainly deploy an identifier mapping implementation that is at least as scalable as that DNS. I would argue that by engineering that implementation for this kind of service in the first place we can do even better than the DNS, in particular with respect to dynamic updating. But that would be gravy, and even if I'm completely wrong the implementation could always evolve at least as rapidly as the DNS itself could. Of course, to the extent that my proposal was deployed, the DNS would not have to evolve (since it would be dealing with the portable/stable identifiers) and redundant effort could be avoided. (Note that I am not proposing to use the DNS to map the identifiers. I am merely making an analogy to the complexity and scalability.) A couple more hand waving arguments that are less convoluted: -There is a class of problems that can be solved by adding another level of indirection. (The mobile IP efforts generally recognize this, though they typically deal with indirection of each packet through an intermediate.) I believe that the portability/stability/multi-homing problem is of this class. I have a question for those who follow IP mobility more closely than I: if we assume hypothetically that my proposal were deployed, could it subsume the functions of mobile IP/IP mobility or are there collateral services needed beyond the indirection? -My approach tends to distribute part of the routing table computation and storage (i.e., that part dealing with the aspect of portable addresses which is thought to be so troublesome for core router scaling) to the end nodes. This can readily transform an O(nodes) problem in the core into an O(1) problem in each node: the same growth that works against a centralized solution cancels itself in a distributed one. There is nothing particularly new here; it's just the source routing argument without explicit source routes. Looking at it from a different perspective, routable IPv6 addresses *are* routes. |It is an enduring myth that backbone routing can scale arbitrarily and |that the only issue is an implementation defficiency from one vendor |(which has long since been fixed). As I said, it's really hard to discuss scalability without a basis in various economic assumptions. IMHO, the myth is that it is completely obvious that portable address routing cannot scale in general based on experience with one particular full-knowledge flat model. I'm not saying it isn't true (and I'm not saying it is), but I don't believe it is obvious. I hope we can agree to disagree on this point and simply sidestep the issue. I designed my proposal to place no additional routing table load on the core and in fact to require no cooperation at all therefrom. So far the main objection to my proposal has been the header bloat from carrying around the portable source & destination identifiers. I agree that this is unfortunate and I think that, if necessary, the identifiers can be removed and inferred on reception. There is some cost in complexity and flexibility, so perhaps the inclusion of the identifiers could be turned on and off at a host's option. Also, I haven't thought through the details as carefully as for the base proposal, but I think the following would work: -The destination routable address can easily be mapped to the the destination host's portable identifier based on that host's own knowledge. This is trivial. -The source routable address can be mapped to a portable identifier if the forward mapping is already in the destination host's cache. If it is not then the destination host would send a query to the source routable address to request its portable identifier. The destination host would then perform a forward lookup to verify the mapping before putting it in the cache. The intent of the forward lookup is to avoid reducing the trustability of source addresses: although it's a bad idea to trust addresses in the first place, we would probably prefer not to significantly worsen the situation for programs that do just that. -As an optimization to reduce traffic, a host could send a preemptive hint of its identifier mapping concurrently with its first communication to a host which was not already in its cache. This saves the initial "reverse- lookup" but does not relieve the target host of the forward lookup. Quality Quorum wrote: |Hi, | |I have simple Joe-six-pack question about renumbering. | |If I have IP session (TCP or UDP) and renumbering event happen on |either end of the connection, then I suppose that my connection will |not survive. Unless something changes, it will not. |It does not seem like a big deal if session reestablishment |will be transparently handled by a protocol stack, Even if this were the case, it would work only if your application didn't need to know its address or figured out that it had changed. |however, it seems like |it is not the case, moreover, it seems like say UPD client has no |way to figure out that UDP server experienced renumbering events, am |I correct about it ? Pretty much. There is a continuum of applications from ones that are largely oblivious to their address (or even domain name) to ones that constantly pass binary addresses across the API and across the net. TCP tends to make the former possible and UDP tends to encourage the latter, but you can conceive counter-examples. A UDP application could do a DNS lookup before each send. Assuming a DDNS implementation that is updated by the renumbering event, the application could survive. There is talk of an API based only on names (no numbers) but it will be hard to retrofit all applications to use it and there are still issues with the protocol's own recovery from a renumbering event. Unfortunately, there seems to be some resistance to a names-based API even for applications that really have no need to deal with a lower-level representation. Back in the days of tcp/ip API chaos on the PC (this is long before winsock at a time when both DOS and Windows interfaces were important with DOS perhaps more so) I pushed hard for a names-based API for simple client-only applications including mail and news readers. I even offered to write the appropriate shims for a few of the popular stacks. Most folks were violently opposed to the idea. I never really understood, especially the part about wanting to keep domain resolution in the application (in spite of the fact that this didn't work for sites using YP). Very strange... Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Sep 19 10:29:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8JHQoV17782 for ipng-dist; Sun, 19 Sep 1999 10:26:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8JHQfB17775 for ; Sun, 19 Sep 1999 10:26:42 -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 KAA05567 for ; Sun, 19 Sep 1999 10:26:37 -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 KAA07536 for ; Sun, 19 Sep 1999 10:26:36 -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 TAA19921; Sun, 19 Sep 1999 19:26: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 TAA01532; Sun, 19 Sep 1999 19:26:29 +0200 (MET DST) Message-Id: <199909191726.TAA01532@givry.inria.fr> From: Francis Dupont To: Christian Huitema cc: Jessica Yu , black@layer8.net, ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of Fri, 17 Sep 1999 08:30:52 EDT. <4.1.19990917082246.00965ac0@mailee.bellcore.com> Date: Sun, 19 Sep 1999 19:26:23 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: One may argue however that there are two missing pieces in the puzzle: 1) a way to quickly update the DNS records, or otherwise affect the choice of addresses, during partial loss of connectivity, or when some of the ISPs undergo severe congestion. => A6 RRs are supposed to help us there but we have no experience with them and in the BIND worker list the discussion is about the idea to enforce minimum RR TTLs in order to save money with dialup connections (with short TTLs DNS caches are less effecient and DNS traffic increases). (Perhaps DNS is again not the good tool for a solution to this problem?) This is an optimization issue (because with a non-brain damaged application enough addresses will be tried) which should be discussed at the interim meeting (long term mechanisms?). 2) a way to migrate TCP connections from one pair of addresses to another. In fact, combining AH or ESP and Mobile IPv6 provides a solution to the second problem. => I have tested this, it should be usable when mobile IPv6 implementations will use IPSec and correspondent node code will be in every IPv6 stacks (this should happen!) 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 Sun Sep 19 10:47:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8JHj4O17809 for ipng-dist; Sun, 19 Sep 1999 10:45:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8JHitB17802 for ; Sun, 19 Sep 1999 10:44:56 -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 KAA07421 for ; Sun, 19 Sep 1999 10:44:55 -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 KAA09748 for ; Sun, 19 Sep 1999 10:44:54 -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 TAA20140; Sun, 19 Sep 1999 19:44:51 +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 TAA03002; Sun, 19 Sep 1999 19:44:51 +0200 (MET DST) Message-Id: <199909191744.TAA03002@givry.inria.fr> From: Francis Dupont To: itojun@iijlab.net cc: Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of Sat, 18 Sep 1999 03:24:28 +0900. <185.937592668@coconut.itojun.org> Date: Sun, 19 Sep 1999 19:44:50 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >> 2) a way to migrate TCP connections from one pair of addresses to another. >> In fact, combining AH or ESP and Mobile IPv6 provides a solution to the >> second problem. Maybe we should concentrate on the first one, which is a >> subset of the general problem of "choosing the nearest server." >> -- Christian Huitema Is it really possible? From my understanding currently available mobile-ipv6 draft does not address key setup (interaction with IKE). If you can clarify how you will be configuring keys on TCP connection time, and address pair change, it would be really helpful. => there are two solutions: - build the Security Association at the connection establishment (ie before a path failure). This has no cost if the connection uses a security service, for instance in order to avoid TCP reset from the bad guy. - build the Security Association when needed, ie after the path failure and before sending binding updates. In this case an address in a right prefix (the care-of address) should be used as the source. Multi-homing is a favourable case because this address is a regular, valid and long term address of the node (in real mobility care-of addresses will change at each movement and become invalid, ie packets to an old care-of address can jump in a dark hole). We discussed last week about security implications of IPv6 mobility at the IPv6 mobility test week (where no security was used unfortunately). The only requirement which should be added in the draft is a SA with a mobile node as the source SHOULD use wildcard source as a selector. Of course this is a constraint for security policies... 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 Sun Sep 19 11:01:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8JHx7I17840 for ipng-dist; Sun, 19 Sep 1999 10:59:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8JHwwB17833 for ; Sun, 19 Sep 1999 10:58:58 -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 KAA07753 for ; Sun, 19 Sep 1999 10:58:58 -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 LAA21866 for ; Sun, 19 Sep 1999 11:58:57 -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 TAA20328; Sun, 19 Sep 1999 19:58:55 +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 TAA01761; Sun, 19 Sep 1999 19:58:54 +0200 (MET DST) Message-Id: <199909191758.TAA01761@givry.inria.fr> From: Francis Dupont To: itojun@iijlab.net cc: Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of Sat, 18 Sep 1999 03:24:28 +0900. <185.937592668@coconut.itojun.org> Date: Sun, 19 Sep 1999 19:58:49 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My main concern about solutions based on RFC 2260 is this is a solution only for the link failure case (there are many other problems like management cost of tunnels, MTU, ... but this one directly makes the RFC 2260 scheme unusable for me). In France almost all ISPs use a so-called "subscriber equipment" which is a router managed by the ISP at your end of the link. Typically you get in your site: +--------+ +--------+ | your | | ISP | | router | | router |<===== link to ISP ====//===> +--------+ +--------+ ^ ^ | | V V ============================== dedicated LAN (Ethernet, FDDI, ...) RFC 2260 is applicable only if the ISP would like to setup the tunnel from its router (the "subscribe equipment") and of course they don't like this! I can send a list of E-mail addresses of French ISP if you need to enrich your French... The issue is not the same for the other end of the tunnel because the ISP can believe (if you don't speak too much about RFC 2260) it is the primary ISP. 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 Sun Sep 19 11:14:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8JIBRP17867 for ipng-dist; Sun, 19 Sep 1999 11:11:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8JIBIB17860 for ; Sun, 19 Sep 1999 11:11:18 -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 LAA08244 for ; Sun, 19 Sep 1999 11:11:18 -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 LAA12728 for ; Sun, 19 Sep 1999 11:11:16 -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 UAA20551; Sun, 19 Sep 1999 20:10:22 +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 UAA01727; Sun, 19 Sep 1999 20:10:22 +0200 (MET DST) Message-Id: <199909191810.UAA01727@givry.inria.fr> From: Francis Dupont To: itojun@iijlab.net cc: Ben Black , ipng@sunroof.eng.sun.com cc: Vernon Schryver Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of Sat, 18 Sep 1999 03:24:28 +0900. <185.937592668@coconut.itojun.org> Date: Sun, 19 Sep 1999 20:10:08 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the end2end mailing list Vernon Schryver wrote: >From what I've seen, assymetric routes are far more common in LANs >and corporate campus networks than on the Internet. They come from the >the prudent provisioning of redundant routers. Dual-homing a single >Ethernet within a campus is cheap and painless, unlike dual-homing >a network on the Internet. => if multi-homing inside a site is very common this can change many things because main issues with the multi-ISP multi-homing are not technical (cost, ISP ill will, ...). For instance routing based strategy (like Jessica's one) should regain our interest. I work in a nearly academic environment (with no backup :-) then I don't know if this is an important case? 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 Sun Sep 19 21:49:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8K4lF018698 for ipng-dist; Sun, 19 Sep 1999 21:47:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8K4l5B18691 for ; Sun, 19 Sep 1999 21:47:07 -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 VAA15628 for ; Sun, 19 Sep 1999 21:47:04 -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 VAA10694 for ; Sun, 19 Sep 1999 21:47:04 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 19 Sep 1999 21:46:30 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2448.0) id ; Sun, 19 Sep 1999 21:46:30 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515A13@RED-MSG-50> From: Richard Draves To: "'Vijay Gill'" , Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Sun, 19 Sep 1999 21:46:29 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't see many people multihoming their houses with a DSL link to > provider A and a cable link to provider B. I'm probably not a typical consumer, but that happens to be exactly how my house is set up. 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 Sun Sep 19 22:05:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8K532718737 for ipng-dist; Sun, 19 Sep 1999 22:03:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8K52sB18730 for ; Sun, 19 Sep 1999 22:02: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 WAA07614 for ; Sun, 19 Sep 1999 22:02:52 -0700 (PDT) Received: from mailserver-ng.cs.umbc.edu (mailserver-ng.cs.umbc.edu [130.85.100.230]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA16500 for ; Sun, 19 Sep 1999 23:02:52 -0600 (MDT) Received: from localhost (wrath@localhost) by mailserver-ng.cs.umbc.edu (8.9.3/8.9.3) with SMTP id BAA08786; Mon, 20 Sep 1999 01:02:51 -0400 (EDT) Date: Mon, 20 Sep 1999 01:02:51 -0400 (EDT) From: Vijay Gill To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515A13@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 19 Sep 1999, Richard Draves wrote: > > I don't see many people multihoming their houses with a DSL link to > > provider A and a cable link to provider B. > > I'm probably not a typical consumer, but that happens to be exactly how my > house is set up. Whats the AS number? /vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 22:28:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8K5Q6B18785 for ipng-dist; Sun, 19 Sep 1999 22:26:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8K5PwB18778 for ; Sun, 19 Sep 1999 22:25:58 -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 WAA17339 for ; Sun, 19 Sep 1999 22:25:57 -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 WAA17699 for ; Sun, 19 Sep 1999 22:25:56 -0700 (PDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 19 Sep 1999 22:25:23 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2524.0) id ; Sun, 19 Sep 1999 22:25:22 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515A16@RED-MSG-50> From: Richard Draves To: "'Vijay Gill'" Cc: ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Sun, 19 Sep 1999 22:25:22 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I'm probably not a typical consumer, but that happens to be > exactly how my > > house is set up. > > Whats the AS number? That's just it, I'm a lowly consumer so I don't get to have an AS number and a globally visible prefix. I mostly manually choose which ISP I want to use when. 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 Sun Sep 19 22:32:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8K5V1X18807 for ipng-dist; Sun, 19 Sep 1999 22:31:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8K5UrB18800 for ; Sun, 19 Sep 1999 22:30: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 WAA04803 for ; Sun, 19 Sep 1999 22:30:52 -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 WAA18627 for ; Sun, 19 Sep 1999 22:30:51 -0700 (PDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 19 Sep 1999 22:30:48 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2524.0) id ; Sun, 19 Sep 1999 22:30:47 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515A18@RED-MSG-50> From: Richard Draves To: "'Ben Black'" Cc: "'Steve Deering'" , ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Sun, 19 Sep 1999 22:30:48 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I don't know either, but I suspect that the latent demand may be > > significant. > > > > Based on what? I suspect that as businesses come to rely on the internet (business processes like dealing with customers & suppliers, running VPNs, etc), they will be increasingly interested in multi-homing. 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 Sun Sep 19 22:34:35 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8K5XTN18825 for ipng-dist; Sun, 19 Sep 1999 22:33:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8K5XKB18818 for ; Sun, 19 Sep 1999 22:33:20 -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 WAA17715 for ; Sun, 19 Sep 1999 22:33:19 -0700 (PDT) Received: from mailserver-ng.cs.umbc.edu (mailserver-ng.cs.umbc.edu [130.85.100.230]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA21209 for ; Sun, 19 Sep 1999 23:33:18 -0600 (MDT) Received: from localhost (wrath@localhost) by mailserver-ng.cs.umbc.edu (8.9.3/8.9.3) with SMTP id BAA09304; Mon, 20 Sep 1999 01:33:17 -0400 (EDT) Date: Mon, 20 Sep 1999 01:33:17 -0400 (EDT) From: Vijay Gill To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515A16@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 19 Sep 1999, Richard Draves wrote: > > > I'm probably not a typical consumer, but that happens to be > > exactly how my > > > house is set up. > > > > Whats the AS number? > > That's just it, I'm a lowly consumer so I don't get to have an AS number and > a globally visible prefix. I mostly manually choose which ISP I want to use > when. > > Rich Precisely. /vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 01:38:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8K8aIA18974 for ipng-dist; Mon, 20 Sep 1999 01:36:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8K8a8B18966 for ; Mon, 20 Sep 1999 01:36: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 BAA13857 for ; Mon, 20 Sep 1999 01:36: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 BAA23776 for ; Mon, 20 Sep 1999 01:36:07 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id SAA22005; Mon, 20 Sep 1999 18:35:55 +1000 (EST) Date: Mon, 20 Sep 1999 18:35:55 +1000 (EST) From: Peter Tattam To: Vijay Gill cc: Richard Draves , ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" 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, 20 Sep 1999, Vijay Gill wrote: > On Sun, 19 Sep 1999, Richard Draves wrote: > > > > > I'm probably not a typical consumer, but that happens to be > > > exactly how my > > > > house is set up. > > > > > > Whats the AS number? > > > > That's just it, I'm a lowly consumer so I don't get to have an AS number and > > a globally visible prefix. I mostly manually choose which ISP I want to use > > when. > > > > Rich > > Precisely. > > /vijay > > This is a growing trend. One of the selling points of our product is that it is only a key click away from completely reconfiguring the network setup, and the changes applying instantly. One customer who is an online stock broker recently indicated that this was very important for the stability of their business model. I suspect there are many internet applications emerging which require high levels of redundancy at the desktop. Perhaps this is a strong motivation for making the multiple prefix per host model work much better than currently since even a successfuly multihomed ISP would still not satisfy the above customer. If we really solved that problem, the multihoming issue could go away. If we can satisfy the following constraints, we will have solved the problem. 1) TCP/UDP session survivability. 2) accurate source address selection. 3) rapid renumbering event notification to hosts. Have these constraints been met yet? If not, can they? 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 Mon Sep 20 04:15:32 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8KBDpB19063 for ipng-dist; Mon, 20 Sep 1999 04:13:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8KBDfB19056 for ; Mon, 20 Sep 1999 04:13:41 -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 EAA19452 for ; Mon, 20 Sep 1999 04:13:40 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA09967 for ; Mon, 20 Sep 1999 04:13:37 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id NAA19779 for ipng@sunroof.eng.sun.com; Mon, 20 Sep 1999 13:13:24 +0200 (MET DST) Message-ID: <19990920131323.A19609@theory.cs.uni-bonn.de> Date: Mon, 20 Sep 1999 13:13:24 +0200 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: IPv6 over ARCnet: NetBSD implementation References: <3.0.5.32.19990810174304.03387200@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <3.0.5.32.19990810174304.03387200@mailhost.iprg.nokia.com>; from Bob Hinden on Tue, Aug 10, 1999 at 05:43:04PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, you folks might want to know that a partial implementation of IPv6 over ARCnet is now available for NetBSD-current. Correct MTU handling is still missing, but neighbour discovery and ping work fine. Regards, Ignatios Souvatzis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 04:15:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8KBClI19054 for ipng-dist; Mon, 20 Sep 1999 04:12:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8KBCcB19047 for ; Mon, 20 Sep 1999 04:12:39 -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 EAA19393 for ; Mon, 20 Sep 1999 04:12:38 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA09635 for ; Mon, 20 Sep 1999 04:12:37 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id UAA25235 for ; Mon, 20 Sep 1999 20:12:36 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA18556 for ; Mon, 20 Sep 1999 20:12:35 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA20457 for ; Mon, 20 Sep 1999 20:12:35 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: foods From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b1 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: <19990920201209O.kazu@iijlab.net> Date: Mon, 20 Sep 1999 20:12:09 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To those who will participate in the interim meeting. I'm now negotiating about lunch and reception diner. If you have special requests (e.g. vegetarian), please feel free to tell me. We will do our best. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 04:25:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8KBN4919099 for ipng-dist; Mon, 20 Sep 1999 04:23:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8KBMrB19092 for ; Mon, 20 Sep 1999 04:22: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 EAA26880 for ; Mon, 20 Sep 1999 04:22:53 -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 EAA12017 for ; Mon, 20 Sep 1999 04:22:52 -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 UAA29410; Mon, 20 Sep 1999 20:21:37 +0900 (JST) To: Ignatios Souvatzis cc: ipng@sunroof.eng.sun.com In-reply-to: ignatios's message of Mon, 20 Sep 1999 13:13:24 +0200. <19990920131323.A19609@theory.cs.uni-bonn.de> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 over ARCnet: NetBSD implementation From: itojun@iijlab.net Date: Mon, 20 Sep 1999 20:21:37 +0900 Message-ID: <29408.937826497@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >you folks might want to know that a partial implementation of IPv6 over ARCnet >is now available for NetBSD-current. Correct MTU handling is still missing, >but neighbour discovery and ping work fine. ... and the above change is backported into KAME, so you can try IPv6 over ARCnet with NetBSD141 + KAME as well. 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 Sep 20 05:26:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8KCNa219182 for ipng-dist; Mon, 20 Sep 1999 05:23:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8KCNRB19175 for ; Mon, 20 Sep 1999 05:23: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 FAA22108 for ; Mon, 20 Sep 1999 05:23:26 -0700 (PDT) Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19091 for ; Mon, 20 Sep 1999 06:23:25 -0600 (MDT) Received: from newton.ebina.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id VAA03102; Mon, 20 Sep 1999 21:23:24 +0900 (JST) Received: from ppp ([172.16.110.11]) by newton.ebina.hitachi.co.jp (8.9.0/3.7W-EBINA) with SMTP id VAA12841; Mon, 20 Sep 1999 21:23:23 +0900 (JST) Message-Id: <199909201223.VAA12841@newton.ebina.hitachi.co.jp> X-Sender: tsuchi@gpc.ebina.hitachi.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Mon, 20 Sep 1999 21:25:37 +0900 To: ipng@sunroof.eng.sun.com From: Kazuaki Tsuchiya Subject: Re: Toolnet6 installation workshop Cc: imv@kame.net In-Reply-To: <199909181355.PAA29723@givry.inria.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, At 15:55 99/09/18 +0200, Francis Dupont wrote: > > Toolnet6 installation workshop > > It is a transition tool based on the "Bump-in-the-stack (BIS)" draft > argued at ngtrans-wg. > > => have you IPv6 mobility support (for instance correspondent support) ? > I am not a BIS expert (on *BSD we have dual stacks) but I believe if > you know how to manage extra headers/options in the outer IPv6 level > then you can transparently use some parts of IPv6 mobility support. > Thank you for your suggestion. We have not supported IPv6 mobility yet, but now are groping for the realization. > NIC: 3Com Corp. EtherLink III > (3C589C, 3C589D, 3CCE589ET, 3CXE589ET,...) > NE2000 Compatible Adapter > (D-Link Systems Inc. DE660T/J Ethernet Adapter, ...) > > => I have both and I should bring extra NICs for the TAHI test event > (routers are finer with more than one LAN :-). > Thank you for your offer. I plan to prepare about 10 NICs for participants who don't have neither EtherLink3 nor NE2000. But would you please lend your extra NICs to us if not sufficient? Thanks in advance. -- Kazuaki Tsuchiya. -------------------------------------------------------- Kazuaki Tsuchiya (mailto:tsuchi@ebina.hitachi.co.jp) Hitachi,Ltd. Enterprise Server Division Phone: +81-46-235-8268(Dial-in) Fax: +81-46-235-8324 <> http://www.v6.hitachi.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 Sep 20 07:21:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8KEI3519313 for ipng-dist; Mon, 20 Sep 1999 07:18:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8KEHsB19306 for ; Mon, 20 Sep 1999 07:17:54 -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 HAA29957 for ; Mon, 20 Sep 1999 07:17:55 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25396 for ; Mon, 20 Sep 1999 07:17:54 -0700 (PDT) Received: from world.std.com (qqi@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id KAA12526; Mon, 20 Sep 1999 10:17:53 -0400 (EDT) Received: from localhost (qqi@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id KAA19961; Mon, 20 Sep 1999 10:17:52 -0400 (EDT) Date: Mon, 20 Sep 1999 10:17:51 -0400 (EDT) From: Quality Quorum To: Richard Draves cc: "'Vijay Gill'" , Steve Deering , ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515A13@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 19 Sep 1999, Richard Draves wrote: > > I don't see many people multihoming their houses with a DSL link to > > provider A and a cable link to provider B. > > I'm probably not a typical consumer, but that happens to be exactly how my > house is set up. Do you expect that second route will be visible in DFZ ? > Rich Thanks, Aleksey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 07:41:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8KEbf119383 for ipng-dist; Mon, 20 Sep 1999 07:37:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8KEbWB19376 for ; Mon, 20 Sep 1999 07:37: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 HAA11856 for ; Mon, 20 Sep 1999 07:37:33 -0700 (PDT) From: bmanning@ISI.EDU 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 HAA02674 for ; Mon, 20 Sep 1999 07:37:33 -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 HAA00607; Mon, 20 Sep 1999 07:37:32 -0700 (PDT) Posted-Date: Mon, 20 Sep 1999 07:37:30 -0700 (PDT) Message-Id: <199909201437.AA09053@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Mon, 20 Sep 1999 07:37:30 -0700 Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" To: qqi@world.std.com (Quality Quorum) Date: Mon, 20 Sep 1999 07:37:30 -0700 (PDT) Cc: richdr@microsoft.com, wrath@cs.umbc.edu, deering@cisco.com, ipng@sunroof.eng.sun.com In-Reply-To: from "Quality Quorum" at Sep 20, 99 10:17:51 am 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 > > > > On Sun, 19 Sep 1999, Richard Draves wrote: > > > > I don't see many people multihoming their houses with a DSL link to > > > provider A and a cable link to provider B. > > > > I'm probably not a typical consumer, but that happens to be exactly how my > > house is set up. > > Do you expect that second route will be visible in DFZ ? > > > Rich > > Thanks, > > Aleksey > I my case it does. lots of providers carry it. -- --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 Mon Sep 20 08:49:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8KFkqZ19474 for ipng-dist; Mon, 20 Sep 1999 08:46:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8KFkhB19467 for ; Mon, 20 Sep 1999 08:46:43 -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 IAA10056 for ; Mon, 20 Sep 1999 08:46:43 -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 IAA01419 for ; Mon, 20 Sep 1999 08:46:42 -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 QAA106954; Mon, 20 Sep 1999 16:46:39 +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 QAA30306; Mon, 20 Sep 1999 16:46:30 +0100 (BST) Message-ID: <37E656F2.303A53E1@hursley.ibm.com> Date: Mon, 20 Sep 1999 10:46:58 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Vijay Gill CC: "Steven M. Bellovin" , ipng@sunroof.eng.sun.com Subject: Safe for a while? [Re: a response to "A Simple Solution for IPv6 Multihoming" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vijay Gill wrote: ... > The total time taken before a router has converged and has started > forwarding packets can be broken down into the following time steps > > 1 - compute the routing table > 2 - populate forwarding tables > 3 - update neighbors > > For this discussion, we are concerned with item #1. > > It is trivially obvious that (1) is a function (f) of number of prefixes > (P). > > The O(f(P)) being the running time of BGP for purposes of this discussion > is fairly non trivial to calculate, and is probably implementation > dependent as well, but a BOE using an SPF calculation as a check, gives me > a result that O(f(P)) is very likely a polynomial (N^2) and less than > exponential. > > Now, oddly enough, I also happen to have some emperical data points from a > study to determine routing scaling for a promising local ISP, and the > curve fitting to the dataset results in a polynomial in ^2. > > These data were collected from instrumenting two fairly well known > implementations and were measured using prefix injection mechanisms that > generated NLRI and associated attributes that were consistent with the > internal IBGP table data for an ISP. > > This gives a result that given linear growth, and exponential Moore's law, > we might be safe for a while. But the only reason we currently have linear growth in the BGP tables is because of CIDR. In any case, "safe for a while" is not very reassuring for the long term. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 20 10:39:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8KHa7R19667 for ipng-dist; Mon, 20 Sep 1999 10:36:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8KHZwB19660 for ; Mon, 20 Sep 1999 10:35: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 KAA05653 for ; Mon, 20 Sep 1999 10:35:58 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20281 for ; Mon, 20 Sep 1999 10:35:58 -0700 (PDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id NAA29897; Mon, 20 Sep 1999 13:35:46 -0400 (EDT) Message-Id: <199909201735.NAA29897@cannes.aa.ans.net> To: Magnus Ahltorp cc: Jessica Yu , Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of "18 Sep 1999 04:00:38 +0200." Date: Mon, 20 Sep 1999 13:35:46 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> In summary, RFC2260/itojun does not seem to provide better >> redundancy than SMPL. The problem associated with tunnel mechanism >> should not be overlooked. > >Yes it does, since you can assign multiple addresses to each host. If multiple addresses per host is used then there is not necessary of using tunnle to gain redundancy. If multiple addresses per host is not used, then as I mentioned above, it does not provide better redundancy than SMPL. Please also be aware that using multiple addresses per host will introducing another array of difficult technical issues in addition to complex management issues. --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 10:56:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8KHrPe19698 for ipng-dist; Mon, 20 Sep 1999 10:53:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8KHrGB19691 for ; Mon, 20 Sep 1999 10:53:16 -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 KAA10247 for ; Mon, 20 Sep 1999 10:53:15 -0700 (PDT) Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02240 for ; Mon, 20 Sep 1999 11:53:14 -0600 (MDT) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id RAA13094; Mon, 20 Sep 1999 17:52:46 GMT Message-Id: <199909201752.RAA13094@orchard.arlington.ma.us> To: Jessica Yu cc: Magnus Ahltorp , Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: Message from Jessica Yu of "Mon, 20 Sep 1999 13:35:46 EDT." <199909201735.NAA29897@cannes.aa.ans.net> Date: Mon, 20 Sep 1999 13:52:46 -0400 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Please also be aware that using multiple addresses per host > will introducing another array of difficult technical issues > in addition to complex management issues. well, given that v6 introduces link-local and particularly site-local addresses, you have to tackle these issues anyway... - 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 Mon Sep 20 12:05:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8KIcVU19766 for ipng-dist; Mon, 20 Sep 1999 11:38:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8KIbwB19759 for ; Mon, 20 Sep 1999 11:38: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 LAA19351 for ; Mon, 20 Sep 1999 11:37:46 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22703 for ; Mon, 20 Sep 1999 12:37:44 -0600 (MDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id OAA00040; Mon, 20 Sep 1999 14:37:29 -0400 (EDT) Message-Id: <199909201837.OAA00040@cannes.aa.ans.net> To: george.tsirtsis@bt.com cc: deering@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of "Fri, 17 Sep 1999 11:16:37 BST." <5104D4DBC598D211B5FE0000F8FE7EB202DBA074@mbtlipnt02.btlabs.bt.co.uk> Date: Mon, 20 Sep 1999 14:37:29 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Can I also clarify the purpose of this discussion? >In the light of what Steve clarified do we try to single out a multihoming >technique and abandon all others? I would hope not! Different networks, >customers and ISPs will have different requirements and in general >multihoming is more an administration/net. management issue i.e: we do not >try to develop a new protocol here (not so far anyway...). I gather that you are saying that there could be more than one multhoming solutions. The selection of such mechanism is largely depending on customers' requirements such as, the level of desirable redundancy and financial constrains (this could vary from customer to customer) and ISPs' own considerations such as managibility, scalability and charging mechanism. I agree. My sense is that the requirements of many multihoming sites would be: a) reasonable redundancy and b) less complexed solution. Since most of such sites do not have in-house expertises to deal with on site complexed configuration and network management and neither can they afford to hire one. --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 12:09:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8KIwE319788 for ipng-dist; Mon, 20 Sep 1999 11:58:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8KIw2B19781 for ; Mon, 20 Sep 1999 11:58: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 LAA23482 for ; Mon, 20 Sep 1999 11:57:58 -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 LAA28055 for ; Mon, 20 Sep 1999 11:57:53 -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 TAA53550; Mon, 20 Sep 1999 19:57:45 +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 TAA16040; Mon, 20 Sep 1999 19:57:43 +0100 (BST) Message-ID: <37E683BF.E2A5ECAB@hursley.ibm.com> Date: Mon, 20 Sep 1999 13:58:07 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Bill Sommerfeld CC: Jessica Yu , Magnus Ahltorp , Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: <199909201752.RAA13094@orchard.arlington.ma.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Sommerfeld wrote: > > > Please also be aware that using multiple addresses per host > > will introducing another array of difficult technical issues > > in addition to complex management issues. > > well, given that v6 introduces link-local and particularly site-local > addresses, you have to tackle these issues anyway... Indeed. It's a baseline assumption that IPv6 hosts may have multiple addresses, including multiple global addresses. That's exactly why we can have more complex multihoming solutions.... it's a feature, not a bug. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 20 13:14:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8KK9Up19876 for ipng-dist; Mon, 20 Sep 1999 13:09:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8KK9HB19869 for ; Mon, 20 Sep 1999 13:09:19 -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 NAA11467 for ; Mon, 20 Sep 1999 13:09:05 -0700 (PDT) From: george.tsirtsis@bt.com 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 NAA28511 for ; Mon, 20 Sep 1999 13:09:05 -0700 (PDT) Received: from cbtlipnt01.btlabs.bt.co.uk by babelbrox.axion.bt.co.uk (local) with ESMTP; Mon, 20 Sep 1999 21:08:46 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id ; Mon, 20 Sep 1999 21:08:45 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB202DBA085@mbtlipnt02.btlabs.bt.co.uk> To: jyy@ans.net Cc: ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Mon, 20 Sep 1999 21:08:38 +0100 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 > -----Original Message----- > From: Jessica Yu [SMTP:jyy@ans.net] > Sent: Monday, September 20, 1999 7:37 PM > To: george.tsirtsis@bt.com > Cc: deering@cisco.com; ipng@sunroof.eng.sun.com > Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" > .... > I gather that you are saying that there could be more than > one multhoming solutions. The selection of such mechanism > is largely depending on customers' requirements such as, > the level of desirable redundancy and financial constrains > (this could vary from customer to customer) and ISPs' own > considerations such as managibility, scalability and charging > mechanism. I agree. > Exactly! and I am glad you agree. > My sense is that the requirements of many multihoming sites would > be: a) reasonable redundancy and b) less complexed solution. > Many but not necessarily all. In any case (as someone frequently sais) "the market will decide". As others also have said multihoming applies (or may apply soon) to many different levels in the internet i.e: single node, Home network, small site, large site, ISP etc etc... > Since most of such sites do not have in-house expertises to deal > with on site complexed configuration and network management and > neither can they afford to hire one. > Some, however, buy this as a service and let their ISPs manage it (if its is cheaper than in-house expertise). Some big customer sites also have a lot of expertise (more than some ISPs even!) In anycase we should not try to guess the business case but only to adequately describe the different options and technical solutions so people, sites and ISPs know what they get into when they pick one up. On a different note I will agree with you that some of the multihoming proposals are going to be very complex in management terms for some time (e.g: itojun'sRFC2260 + Router Renumbering). IMO, this is largely due to the embryonic state of Internet operations and management (no offence to the management folks!) What I am saying is that as the Internet matures, it takes up new services (i.e: multicast, QoS, VoiP, VPNs, IPSEC etc) and as such it becomes more complex. More complex systems demand more complex management and thus I expect that complex multihoming solutions will be supported sooner or later as management systems develop... Regards 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 Mon Sep 20 17:44:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8L0fKD20460 for ipng-dist; Mon, 20 Sep 1999 17:41:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8L0f3B20453 for ; Mon, 20 Sep 1999 17:41:06 -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 RAA10459 for ; Mon, 20 Sep 1999 17:40:26 -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 RAA12787 for ; Mon, 20 Sep 1999 17:40:25 -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 JAA06515; Tue, 21 Sep 1999 09:40:09 +0900 (JST) To: Jessica Yu cc: ipng@sunroof.eng.sun.com In-reply-to: jyy's message of Mon, 20 Sep 1999 13:35:46 -0400. <199909201735.NAA29897@cannes.aa.ans.net> 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: a response to "A Simple Solution for IPv6 Multihoming" From: itojun@iijlab.net Date: Tue, 21 Sep 1999 09:40:09 +0900 Message-ID: <6513.937874409@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Yes it does, since you can assign multiple addresses to each host. > If multiple addresses per host is used then there is not > necessary of using tunnle to gain redundancy. If multiple > addresses per host is not used, then as I mentioned above, it > does not provide better redundancy than SMPL. You need to provide redundancy (cope with link failure) when you have multiple addresses assigned to a host. Consider you have multiple address on a host (say A:x and B:x). You register A:x and B:x onto the DNS database. For inbound connection (outside to your site), it is up to outsider to choose which address to use. Outsider may send a packet to A:x even if ISP link A is down. Therefore, boundary routers need to provide reachability regardless of link failure. So you need 2260/itojun. For outbound (your site to outside) it is up to host (not the boundary routers) to choose source address for the connection. If ISP link A is down and the host happen to use A:x as the source address, reply packet will fail to come back. Therefore, again you need to provide reachability regardless of link failure. From my understanding (correct me if I'm wrong) SMPL assumes the adjacent ISPs to have specific connectivity. I think the assumption needs to be decreased. 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 Sep 20 18:13:34 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8L1Alx20509 for ipng-dist; Mon, 20 Sep 1999 18:10:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8L1AaB20502 for ; Mon, 20 Sep 1999 18:10:36 -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 SAA14945 for ; Mon, 20 Sep 1999 18:10:35 -0700 (PDT) Received: from turbot.pdc.kth.se (turbot.pdc.kth.se [130.237.221.42]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA01521 for ; Mon, 20 Sep 1999 19:10:35 -0600 (MDT) Received: (from d95-mah@localhost) by turbot.pdc.kth.se (8.8.8+Sun/8.8.7) id DAA28767; Tue, 21 Sep 1999 03:09:00 +0200 (MET DST) To: Jessica Yu Cc: Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: <199909201735.NAA29897@cannes.aa.ans.net> From: Magnus Ahltorp Content-Type: text/plain; charset="iso-8859-1" Content-Language: en Date: 21 Sep 1999 03:08:59 +0200 In-Reply-To: Jessica Yu's message of "Mon, 20 Sep 1999 13:35:46 -0400" Message-ID: Lines: 29 X-Mailer: Gnus v5.6.45/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If multiple addresses per host is used then there is not > necessary of using tunnle to gain redundancy. If multiple > addresses per host is not used, then as I mentioned above, it > does not provide better redundancy than SMPL. There is a reason to use tunnels even if multiple addresses are used. The reason is the simple fact that people want their connections to live through a failure. In Francis' draft, the same thing is achieved by using binding updates. > Please also be aware that using multiple addresses per host > will introducing another array of difficult technical issues > in addition to complex management issues. Since all IPv6 hosts must have a link-local address, each IPv6 host is in exactly one of these sets: 1. Those that have only link-local addresses. 2. Those that have multiple addresses. The members of the first set is not affected by any routing. The members of the second set obviously already have multiple addresses. Magnus Ahltorp Department of Teleinformatics Royal Institute of Technology Stockholm, Sweden -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 18:39:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8L1URh20537 for ipng-dist; Mon, 20 Sep 1999 18:30:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8L1UHB20530 for ; Mon, 20 Sep 1999 18:30:18 -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 SAA12266 for ; Mon, 20 Sep 1999 18:30:17 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA06802 for ; Mon, 20 Sep 1999 19:30:16 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA04639 for ; Tue, 21 Sep 1999 10:30:15 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA15249 for ; Tue, 21 Sep 1999 10:30:15 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA08869 for ; Tue, 21 Sep 1999 10:30:14 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: electric equipments From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b1 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: <19990921102949K.kazu@iijlab.net> Date: Tue, 21 Sep 1999 10:29:49 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 10 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI of the interim meeting. We will prepare the following equipments: VGA projector (800x600) x 2 (main and backup) Over head projector x 2 (right side and left side) with some slide sheets and pens Microphone x 3 (one is for speakers, the others is for audience) --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 18:49:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8L1jkM20568 for ipng-dist; Mon, 20 Sep 1999 18:45:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8L1jbB20561 for ; Mon, 20 Sep 1999 18:45:38 -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 SAA08059 for ; Mon, 20 Sep 1999 18:45:37 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA10572 for ; Mon, 20 Sep 1999 19:45:37 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA05026 for ; Tue, 21 Sep 1999 10:45:36 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA17264 for ; Tue, 21 Sep 1999 10:45:36 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA10394 for ; Tue, 21 Sep 1999 10:45:35 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: foods From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b1 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: <19990921104510W.kazu@iijlab.net> Date: Tue, 21 Sep 1999 10:45:10 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I realized that I should have listed up foods. I have not received the menu of lunch but here is the menu of reception diner. Sushi Tempura Soba (a kind of Japanese nuddle) Smoked salmon Some seafoods (I can't translate) Role of shrimp Salmon and spinach Sauteed chiken Baked beaf Packed beaf (uhhhm) Beaf stew Spaghetti Salad Dessert P.S. Marriage of sushi and sake is the best like wine and cheese. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 18:57:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8L1u4J20611 for ipng-dist; Mon, 20 Sep 1999 18:56:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8L1ttB20604 for ; Mon, 20 Sep 1999 18:55:56 -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 SAA20625 for ; Mon, 20 Sep 1999 18:55:56 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA02901 for ; Mon, 20 Sep 1999 18:55:55 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA05297 for ; Tue, 21 Sep 1999 10:55:54 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA18884 for ; Tue, 21 Sep 1999 10:55:54 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA11536 for ; Tue, 21 Sep 1999 10:55:53 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: IIJ local access service From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b1 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: <19990921105527Q.kazu@iijlab.net> Date: Tue, 21 Sep 1999 10:55:27 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 11 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When you in Tokyo, you may want to have local IPv4 access to ISPs from your hotel. But some guys may not find roaming services of your ISP in Tokyo. IIJ will provide you free accounts during 29 Sep - 1 Oct. You have to pay dial fee to your hotel, of course, but IIJ dial-up PPP account is free of charge. If you want to use this service, please let me know. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 19:06:38 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8L23fa20657 for ipng-dist; Mon, 20 Sep 1999 19:03:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8L23WB20650 for ; Mon, 20 Sep 1999 19:03:32 -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 TAA21130 for ; Mon, 20 Sep 1999 19:03:32 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA04788 for ; Mon, 20 Sep 1999 19:03:31 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA05430 for ; Tue, 21 Sep 1999 11:03:31 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA20052 for ; Tue, 21 Sep 1999 11:03:29 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA12346 for ; Tue, 21 Sep 1999 11:03:29 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: registration is still open From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b1 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: <19990921110304D.kazu@iijlab.net> Date: Tue, 21 Sep 1999 11:03:04 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 5 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Since the number of participants is under the limit (90), we decided to keep interim meeting registration/hotel reservation open. We will close it when reaches the limit. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 19:52:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8L2nC020695 for ipng-dist; Mon, 20 Sep 1999 19:49:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8L2n3B20688 for ; Mon, 20 Sep 1999 19:49: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 TAA12840 for ; Mon, 20 Sep 1999 19:49:03 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA15101 for ; Mon, 20 Sep 1999 19:49:03 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA06491 for ; Tue, 21 Sep 1999 11:49:02 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA26417 for ; Tue, 21 Sep 1999 11:49:02 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA16710 for ; Tue, 21 Sep 1999 11:49:01 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: Re: registration is still open From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <19990921110304D.kazu@iijlab.net> References: <19990921110304D.kazu@iijlab.net> X-Mailer: Mew version 1.95b1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-Id: <19990921114835W.kazu@iijlab.net> Date: Tue, 21 Sep 1999 11:48:35 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 15 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Kazu Yamamoto ($B;3K\OBI'(B) Subject: registration is still open > Since the number of participants is under the limit (90), we decided > to keep interim meeting registration/hotel reservation open. We will > close it when reaches the limit. I forgot to tell you this. All partipants are given the interim original T shirts. You can see the final design: http://www.kk.iij4u.or.jp/~akiko/dist/kame-s.jpg Hoping that this is a good motivation to come to Japan. :-) --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 20:06:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8L347h20718 for ipng-dist; Mon, 20 Sep 1999 20:04:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8L33wB20711 for ; Mon, 20 Sep 1999 20:03:58 -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 UAA13802 for ; Mon, 20 Sep 1999 20:03:57 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA28060 for ; Mon, 20 Sep 1999 21:03:57 -0600 (MDT) Received: from world.std.com (qqi@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id XAA24695; Mon, 20 Sep 1999 23:03:56 -0400 (EDT) Received: from localhost (qqi@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id XAA23853; Mon, 20 Sep 1999 23:03:55 -0400 (EDT) Date: Mon, 20 Sep 1999 23:03:55 -0400 (EDT) From: Quality Quorum Reply-To: Quality Quorum To: itojun@iijlab.net cc: Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-Reply-To: <6513.937874409@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 Tue, 21 Sep 1999 itojun@iijlab.net wrote: > You need to provide redundancy (cope with link failure) when > you have multiple addresses assigned to a host. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I am sorry but I do not see that it is so. It seems to me that correct expression is 'multiple prefixes assigned to a site'. ISP-A ISP-B Access-router-A Access-router-B Customer-subnet A Customer-subnet-B Host Customer-internal-router Say, your primary ISP is -A, your host has only one prefix (given by ISP-A), one address and one DNS entry. ISP-B advertizes an expensive route to customer subnet A - and this is it. > > Consider you have multiple address on a host (say A:x and B:x). > You register A:x and B:x onto the DNS database. > For inbound connection (outside to your site), it is up to outsider > to choose which address to use. Outsider may send a packet to A:x > even if ISP link A is down. Therefore, boundary routers need > to provide reachability regardless of link failure. So you need > 2260/itojun. So, it seems to me that (1) we do not need 2260/itojun here, (2) it will spill as many routes (namely one) into DFZ as 2260/itojun would. > itojun Thanks, Aleksey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 21:23:38 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8L4L2M20743 for ipng-dist; Mon, 20 Sep 1999 21:21:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8L4KrB20736 for ; Mon, 20 Sep 1999 21:20:54 -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 VAA18386 for ; Mon, 20 Sep 1999 21:20:53 -0700 (PDT) From: george.tsirtsis@bt.com Received: from dent.axion.bt.co.uk (dent.axion.bt.co.uk [132.146.16.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA06600 for ; Mon, 20 Sep 1999 21:20:52 -0700 (PDT) Received: from cbtlipnt01.btlabs.bt.co.uk by dent (local) with ESMTP; Tue, 21 Sep 1999 05:20:11 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id ; Mon, 20 Sep 1999 21:16:33 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB202DBA086@mbtlipnt02.btlabs.bt.co.uk> To: jyy@ans.net, map@it.kth.se Cc: black@layer8.net, ipng@sunroof.eng.sun.com Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Mon, 20 Sep 1999 21:16:23 +0100 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 > -----Original Message----- > From: Jessica Yu [SMTP:jyy@ans.net] > Sent: Monday, September 20, 1999 6:36 PM > To: Magnus Ahltorp > Cc: Jessica Yu; Ben Black; ipng@sunroof.eng.sun.com > Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" > > >> In summary, RFC2260/itojun does not seem to provide better > >> redundancy than SMPL. The problem associated with tunnel > mechanism > >> should not be overlooked. > > > >Yes it does, since you can assign multiple addresses to each host. > > > If multiple addresses per host is used then there is not > necessary of using tunnle to gain redundancy. > In fact it is because using the tunnels allows existing connections to be saved on link failure (just needs a bit more clever routing in the site). Also as a special(?) case a site might multihome to two ISPs from the SAME gateway router, this makes some of the config easier. 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 Tue Sep 21 08:21:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8LFI5i20993 for ipng-dist; Tue, 21 Sep 1999 08:18:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8LFHuB20986; Tue, 21 Sep 1999 08:17: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 IAA11525; Tue, 21 Sep 1999 08:17:56 -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 IAA14569; Tue, 21 Sep 1999 08:17:55 -0700 (PDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id LAA30694; Tue, 21 Sep 1999 11:17:45 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000004276; Tue, 21 Sep 1999 11:17:40 -0400 (EDT) From: Jim Bound Message-Id: <199909211517.LAA0000004276@quarry.zk3.dec.com> To: deployment@ipv6.org, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu, namedroppers@internic.net cc: tech@ipv6forum.com Subject: INFORMATIONAL ONLY: IPv6 Deploy Tech Dir Mail List Date: Tue, 21 Sep 1999 11:17:40 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please do not respond to this mail. The mail address for the directorate is tech@ipv6forum.com IPv6 Deployment Technical Directorate. Directorate: Jim Bound & Co-Chair Perry Metzger & Co-Chair Tim Hartrick Peter Tattam Cyndi Jung Jack McCann Brian Zill Francis Dupont Marc Blanchet Dale Finkelson Thomas Ekland Stig Venaas Brian Haberman Matt Crawford Bob Halley Carl Williams Ivano Guardini Henk Steenman Advisors: Bob Hinden Steve Deering Brian Carpenter Allison Mankin Christian Huitema Bob Fink Charlie Perkins Scott Bradner /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 Sep 21 08:42:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8LFc8b21082 for ipng-dist; Tue, 21 Sep 1999 08:38:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8LFbvB21073 for ; Tue, 21 Sep 1999 08:37:58 -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 IAA08807 for ; Tue, 21 Sep 1999 08:37:53 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23831 for ; Tue, 21 Sep 1999 09:37:52 -0600 (MDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id LAA01294; Tue, 21 Sep 1999 11:37:38 -0400 (EDT) Message-Id: <199909211537.LAA01294@cannes.aa.ans.net> To: Bill Sommerfeld cc: Jessica Yu , Magnus Ahltorp , Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of "Mon, 20 Sep 1999 13:52:46 EDT." <199909201752.RAA13094@orchard.arlington.ma.us> Date: Tue, 21 Sep 1999 11:37:37 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Please also be aware that using multiple addresses per host >> will introducing another array of difficult technical issues >> in addition to complex management issues. > >well, given that v6 introduces link-local and particularly site-local >addresses, you have to tackle these issues anyway... These really are different problem to tackle. Link-local and site-local addresses are not globally visible so there is no global routing associated issues. Contrastly, the multiple addresses per host for multihoming sites (relevant to this thread of discussion) DO have these issues (e.g. selection of one of multiaddress could have impact on the global connectivity or failure of connectivity). Therefore, having mechanism to deal with the link-local/site-local problem does not mean we also have a solutions for multi-address multihoming issues. --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 21 09:50:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8LGlMc21227 for ipng-dist; Tue, 21 Sep 1999 09:47:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8LGlCB21215 for ; Tue, 21 Sep 1999 09:47:12 -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 JAA29200 for ; Tue, 21 Sep 1999 09:47:12 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26449 for ; Tue, 21 Sep 1999 10:47:10 -0600 (MDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id MAA01471; Tue, 21 Sep 1999 12:47:08 -0400 (EDT) Message-Id: <199909211647.MAA01471@cannes.aa.ans.net> To: ipng@sunroof.eng.sun.com cc: jyy@ans.net Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Date: Tue, 21 Sep 1999 12:47:08 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have spent a lot of time on this thread of discussion (and my boss may start to wonder if I have anything better to do :). But before go to do some real work :), let me summarise (from my understanding) of general high level directions agreed upon in the discussion: o Although aggregation (i.e. no route longer than /64 be advertised to global routing table) is not mandatory for IPv6, it's a very desirable goal to reach. o There may be nothing to prevent the current IPv4 multihoming practice to be used in IPv6 environment (till it's become unmanageable). However, it's highly desirable to develop multihoming mechanism to reach the goal described above so such proposals have to work under the constrains of aggregation. o It is not necessary for the WG to come up with only ONE such mechanism. In fact, it's more realistic to have multimple mechanisms to meet the different requirements of users and ISPs. o Besides meeting requirements for multihoming, such as redundancy, load sharing ,etc., the manageability of a solution should not be overlooked. o The market will ultimately decide what solution(s) will be used. So the WG's job is not to decide a (or D) solution for the ISPs and multihoming customers but rather provide a set of possible solutions with pros and cons well documented. --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 21 09:56:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8LGsQh21262 for ipng-dist; Tue, 21 Sep 1999 09:54:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8LGsHB21255 for ; Tue, 21 Sep 1999 09:54: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 JAA18437 for ; Tue, 21 Sep 1999 09:54:17 -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 KAA29880 for ; Tue, 21 Sep 1999 10:54:14 -0600 (MDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id MAA03009 for ; Tue, 21 Sep 1999 12:54:14 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000029056; Tue, 21 Sep 1999 12:54:13 -0400 (EDT) From: Jim Bound Message-Id: <199909211654.MAA0000029056@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of "Tue, 21 Sep 1999 11:37:37 EDT." <199909211537.LAA01294@cannes.aa.ans.net> Date: Tue, 21 Sep 1999 12:54:13 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Catching up on mail on this subject. Seems we keep discussing the same thing over and over and I hope the Japan meeting is more productive than this mail. It seems to me that we need some guidelines for the meeting discussion or you will all be in questionable technical ratholes for the whole time. I think Steve Deering, Bob Hinden, and Christian Huitema provided the list with clear axioms about what IPv6 does do and whats its architecture can do and possibly what problems we should solve first and then what problems we can solve next. I also thought Vijay provided some good light on the axioms about computation and scaling that were valid too without making hard stats, which we cannot do until we see what the market does with IPv6 (esp ISPs and Telcos); hence, making radical changes is most likely not prudent right now for multihoming. That is why I am still convinced SMPL is the right proposal and Francis Dupont's recent draft raises some issues too. The other thing is that I am getting less tolerant of new folks on this list that blast the old folks and its clear they have not read all the IPv6 specs that affect this discussion. Lucky for you I am not on this discussion previously cause I am going to start being very direct with those folks and telling them publicly your input is sketchy cause you have obviously not read all the releative IPv6 specs and speaking without knowing what your talking about. All new folks owe the WG to go and sit down and read and understand all the specs before you tell folks that are on this list for a long time they are wrong. Also not listening to what folks say is pretty unsocial too. Folks still arguing against or only we provide aggregation really are clueless. I also thought Georges idea of summarizing the proposals is a good idea as that helped with the transition specs quite well. We also need once we are done to ascertain the implementation affects of all of this and what can be done at what speed and deployed. Lastly if you get to the point where one wants to swap IPv6 addresses on the fly discussion DO NOT ASSUME you have a valid solution if it does not address UDP and the affect to the APIs that are listening for connects on sockets. But I doubt you will have time to go here. I will be working offline with a few folks to get my algorithm and src/dst address suggestion if that is to be to the group in Japan thru Richard. 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 Tue Sep 21 10:10:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8LH5k921325 for ipng-dist; Tue, 21 Sep 1999 10:05:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8LH5bB21318 for ; Tue, 21 Sep 1999 10:05: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 KAA26800 for ; Tue, 21 Sep 1999 10:05:37 -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 KAA02459 for ; Tue, 21 Sep 1999 10:05:36 -0700 (PDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id NAA03651; Tue, 21 Sep 1999 13:05:36 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000004617; Tue, 21 Sep 1999 13:05:35 -0400 (EDT) From: Jim Bound Message-Id: <199909211705.NAA0000004617@quarry.zk3.dec.com> To: Jessica Yu cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of "Tue, 21 Sep 1999 12:47:08 EDT." <199909211647.MAA01471@cannes.aa.ans.net> Date: Tue, 21 Sep 1999 13:05:35 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk this sounds excellent and captures the points well. /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 Sep 21 11:08:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8LI4G621464 for ipng-dist; Tue, 21 Sep 1999 11:04:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8LI45B21457 for ; Tue, 21 Sep 1999 11:04:05 -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 LAA19165 for ; Tue, 21 Sep 1999 11:04: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 MAA05614 for ; Tue, 21 Sep 1999 12:04:04 -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 NAA08216; Tue, 21 Sep 1999 13:03:58 -0500 (CDT) Message-Id: <199909211803.NAA08216@gungnir.fnal.gov> To: Jessica Yu Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of Tue, 21 Sep 1999 12:47:08 EDT. <199909211647.MAA01471@cannes.aa.ans.net> Date: Tue, 21 Sep 1999 13:03:58 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ... let me summarise (from my understanding) of general high > level directions agreed upon in the discussion: > > o Although aggregation (i.e. no route longer than /64 be advertised to > global routing table) is not mandatory for IPv6, it's a very desirable > goal to reach. The original (for some choice of origin) scheme was not to require any prefix longer than * /16 * to be carried globally. The TLA size has been fudged a bit since then. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 21 12:05:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) id d8LJ2Lb21514 for ipng-dist; Tue, 21 Sep 1999 12:02:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta0+Sun/8.10.0.Beta0) with ESMTP id d8LJ2DB21507 for ; Tue, 21 Sep 1999 12:02:13 -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 MAA23047 for ; Tue, 21 Sep 1999 12:02:13 -0700 (PDT) Received: from minuet.das.harvard.edu (mail.eas.harvard.edu [140.247.50.251]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04058 for ; Tue, 21 Sep 1999 13:02:12 -0600 (MDT) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id PAA21070 for ; Tue, 21 Sep 1999 15:02:11 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id PAA02017 for ipng@sunroof.eng.sun.com; Tue, 21 Sep 1999 15:02:11 -0400 (EDT) Date: Tue, 21 Sep 1999 15:02:11 -0400 (EDT) Message-Id: <199909211902.PAA02017@endor.deas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: |Lastly if you get to the point where one wants to swap IPv6 addresses on |the fly discussion DO NOT ASSUME you have a valid solution if it does |not address UDP and the affect to the APIs that are listening for |connects on sockets. But I doubt you will have time to go here. Just wondering if this is a reference to my proposal, since it was the most recent mention of swapping addresses (well, really swapping addresses and identifiers)? If so, I just want to mention again that it is totally transparent to all the upper protocols including UDP and it has no effect on the listening APIs. Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 21 18:25:37 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8M1MPM22119 for ipng-dist; Tue, 21 Sep 1999 18:22:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8M1MCX22112 for ; Tue, 21 Sep 1999 18:22:12 -0700 (PDT) Received: from bobo.eng.sun.com (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA260577; Tue, 21 Sep 1999 18:22:12 -0700 (PDT) Date: Tue, 21 Sep 1999 18:22:11 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Comments on draft-ietf-svrloc-ipv6-06.txt To: srvloc@srvloc.org Cc: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't understand the text in section 3. Part of the problem is that terms like "link local advertisement" and "routable addresses" are not defined. (Is a link local advertisement an advertisement sent to a link-local address or an advertisement that contains a link-local address? All addresses are routable within some scope - does "routable" mean "globally routable" or something else.) But the more fundamental question is the need for these restrictions. Isn't it sufficient to tie the scope of the destination address of the packet to the scope of the address in the service: URL? Thus the limitation would be that a server: URL can not contain a literal IPv6 address which has a scope which is smaller than the scope of the IPv6 destination address. In addition, the section needs to clarify the issues for multihomed and multi-sited nodes (nodes connected to different sites) but there is no need to forbid the DA or SA to be multihomed. The constraint on multihomed and multi-sited nodes is that a service: URL with a literal IPv6 address that is less than global scope can only be advertised to the site (for site-local) or link (for link-local) over which the IPv6 address was learned. In section 5.1 is lists some multicast address with a wildcard 'X'. What does this mean for an implementation? Is it supposed to join the multicast group for all values of X (0 through 0xF)? How does the client determine which value of X to use? The examples in section 4 appear to use badly formed addresses. It would make sense to use addresses which follow the EUI 64 format i.e. with 0xfffe in the middle and with a non-zero subnet/SLA field. Thus change fec0::a3f9:251c:1291:109d to fec0::323:a3f9:25ff:fe91:109d and change fe80::015a:93c0:d85d:b098 to fe80::a15a:93ff:fe6d:b098 Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 21 20:33:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8M3UXx22209 for ipng-dist; Tue, 21 Sep 1999 20:30:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8M3UOX22202 for ; Tue, 21 Sep 1999 20:30:24 -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 UAA03674 for ; Tue, 21 Sep 1999 20:30:24 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA26631 for ; Tue, 21 Sep 1999 20:30:23 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id MAA29425 for ; Wed, 22 Sep 1999 12:30:22 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA18544 for ; Wed, 22 Sep 1999 12:30:22 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA07383 for ; Wed, 22 Sep 1999 12:30:21 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: videocast From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b1 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: <19990922122958X.kazu@iijlab.net> Date: Wed, 22 Sep 1999 12:29:58 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 10 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Videocast service over *IPv4* will be available during the interim meeting. For more information, pls refer to: http://www.wide.ad.jp/events/199909.ipng-interim/ P.S. We gave up multicast over IPv6 because of the limitation of external bandwidth. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 21 23:00:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8M5o4Q22274 for ipng-dist; Tue, 21 Sep 1999 22:50:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8M5noX22267 for ; Tue, 21 Sep 1999 22:49:51 -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 WAA14227 for ; Tue, 21 Sep 1999 22:49:49 -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 XAA12026 for ; Tue, 21 Sep 1999 23:49:48 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id PAA23070 for ; Wed, 22 Sep 1999 15:49:46 +1000 (EST) Date: Wed, 22 Sep 1999 15:49:46 +1000 (EST) From: Peter Tattam To: IPNG Mailing List Subject: Hostility between ISPs? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just a small aside, I was told yesterday by our primary bandwidth provider that they won't let us use their proxy cache unless we go single homed with them alone. For us bandwidth is a scarce commodity and so ways of maximizing and recycling the bandwidth are important as the competitive pressures on pricing are enormous. Caching data is an important cost recovery tool. I feel this sentiment should balanced with comments that ISPs typically have no problem coming to amicable arrangements regarding peering & BGP exchanges as there are implications for RFC 2260 & SMPL solutions to multihoming. This is not hot air, just the real world of ISPing. Under the current regime in Australia, I doubt if I could get 2260 or SMPL to happen. My providers just don't like cooperating. I accept that both 2260 & SMPL work technically and are implementable. Politically, I am having doubts as it leaves the small-medium ISPs at the mercy of inter ISP politics, and we so it would have to be pushed back to the internet regulators to find a solution to that issue. Solutions that give the end user greater control over multihoming issues should continue to be sought. 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 Sep 21 23:16:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8M68Td22299 for ipng-dist; Tue, 21 Sep 1999 23:08:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8M68IX22292 for ; Tue, 21 Sep 1999 23:08:19 -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 XAA12599 for ; Tue, 21 Sep 1999 23:08:20 -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 AAA16513 for ; Wed, 22 Sep 1999 00:08:18 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id QAA24380 for ; Wed, 22 Sep 1999 16:08:17 +1000 (EST) Date: Wed, 22 Sep 1999 16:08:17 +1000 (EST) From: Peter Tattam To: IPNG Mailing List Subject: multihoming proposals summary again. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't believe anybody has yet volunteered to put together this list. As I raised the topic, I guess the responsibility falls on my shoulders. If no volunteers come forward within a day, I can do it although I'm probably not the best for the job as I also have vested interest in at least one proposal from myself being considered. Are there any volunteers for an impartial person to create the summary list? I propose some ground rules should be laid... Once the list is published, it will be counter productive to argue over what is listed, or the contents of suggested proposals. I would strongly recommend that all discussion on the summary list be postponed until after the Interim meeting has concluded and minutes are published. Also, to be fair, no proposal should be left off the list provided it meets the technical standard of discussion acceptable to this mailing list. Whether it works or not should not matter - that would (hopefully) be decided fairly quickly at (or before?) the interim meeting. Of course a prudent course of action would be to get a couple of key opinions beforehand from knowledgeable individuals on the IPng working group (PRIVATELY!!!). If we can't agree on the ground rules... I won't bother. 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 Sep 22 01:17:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8M87g122440 for ipng-dist; Wed, 22 Sep 1999 01:07:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8M87LX22433 for ; Wed, 22 Sep 1999 01:07:22 -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 BAA19389 for ; Wed, 22 Sep 1999 01:07:21 -0700 (PDT) From: george.tsirtsis@bt.com Received: from babelfish.axion.bt.co.uk (babelfish.axion.bt.co.uk [132.146.17.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA12028 for ; Wed, 22 Sep 1999 02:07:20 -0600 (MDT) Received: from cbtlipnt01.btlabs.bt.co.uk by babelfish.axion.bt.co.uk (local) with ESMTP; Wed, 22 Sep 1999 09:06:49 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id ; Wed, 22 Sep 1999 09:06:48 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB202DBA08A@mbtlipnt02.btlabs.bt.co.uk> To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Cc: peter@jazz-1.trumpet.com.au Subject: RE: a response to "A Simple Solution for IPv6 Multihoming" Date: Wed, 22 Sep 1999 09:06:36 +0100 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 > -----Original Message----- > From: Jim Bound [SMTP:bound@zk3.dec.com] > Sent: Tuesday, September 21, 1999 5:54 PM > To: ipng@sunroof.eng.sun.com > Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" > ... > I also thought Georges idea of summarizing the proposals is a good idea > as that helped with the transition specs quite well. > Just to say that this was Peter Tattam's idea. I just thought it is a good one as you did. 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 Sep 22 01:33:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8M8Sqi22463 for ipng-dist; Wed, 22 Sep 1999 01:28:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8M8SiX22456 for ; Wed, 22 Sep 1999 01:28:44 -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 BAA23185 for ; Wed, 22 Sep 1999 01:28:32 -0700 (PDT) Received: from newman.itea.ntnu.no (newman.itea.ntnu.no [129.241.18.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16200 for ; Wed, 22 Sep 1999 02:28:31 -0600 (MDT) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by newman.itea.ntnu.no (8.9.1/8.9.1) with ESMTP id JAA02686; Wed, 22 Sep 1999 09:28:29 +0100 (WET DST) From: Stig Venaas Received: (from venaas@localhost) by alfa.itea.ntnu.no (8.7.3/8.7.3) id KAA03038; Wed, 22 Sep 1999 10:28:55 +0200 (MET DST) Message-ID: <19990922102855.A10812@itea.ntnu.no> Date: Wed, 22 Sep 1999 10:28:55 +0200 To: Kazu Yamamoto , ipng@sunroof.eng.sun.com Subject: Re: videocast References: <19990922122958X.kazu@iijlab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990922122958X.kazu@iijlab.net>; from Kazu Yamamoto on Wed, Sep 22, 1999 at 12:29:58PM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Sep 22, 1999 at 12:29:58PM +0900, Kazu Yamamoto wrote: > Videocast service over *IPv4* will be available during the interim > meeting. For more information, pls refer to: > http://www.wide.ad.jp/events/199909.ipng-interim/ It's great that you provide video, but I wish you would use a different format, it seems to require a RealVideo G2 player which is not available for any UNIX platforms. It might be easier for me to find a windows box, than it is for you to provide something else though. Stig -- Stig Venaas UNINETT/NTNU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 22 05:29:51 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MCRCl22574 for ipng-dist; Wed, 22 Sep 1999 05:27:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MCR3X22567 for ; Wed, 22 Sep 1999 05:27:04 -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 FAA00998 for ; Wed, 22 Sep 1999 05:27:04 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02376 for ; Wed, 22 Sep 1999 06:26:56 -0600 (MDT) Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA22902; Wed, 22 Sep 1999 13:26:45 +0100 (BST) Received: from pootle.ecs.soton.ac.uk (IDENT:krp@pootle.ecs.soton.ac.uk [152.78.68.89]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id NAA28229; Wed, 22 Sep 1999 13:26:43 +0100 (BST) Date: Wed, 22 Sep 1999 13:28:27 +0100 (BST) From: Kevin Page To: Stig Venaas cc: ipng@sunroof.eng.sun.com Subject: Re: videocast In-Reply-To: <19990922102855.A10812@itea.ntnu.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 22 Sep 1999, Stig Venaas wrote: > It's great that you provide video, but I wish you would use a different > format, it seems to require a RealVideo G2 player which is not available > for any UNIX platforms. It might be easier for me to find a windows box, Real Player G2 alpha for linux is available at: http://www.real.com/products/player/linux.html It's pretty stable in my experience. Regards, kev -- Kevin Page Multimedia Research Group (Systems and Networks Group) Department of Electronics and Computer Science, University of Southampton, UK -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 22 05:48:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MCkA322600 for ipng-dist; Wed, 22 Sep 1999 05:46:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MCk2X22593 for ; Wed, 22 Sep 1999 05:46:02 -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 FAA01754 for ; Wed, 22 Sep 1999 05:46:02 -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 GAA06532 for ; Wed, 22 Sep 1999 06:45:48 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id OAA13839; Wed, 22 Sep 1999 14:45:35 +0200 (MET DST) Message-ID: <19990922144535.B12622@theory.cs.uni-bonn.de> Date: Wed, 22 Sep 1999 14:45:35 +0200 From: Ignatios Souvatzis To: Kevin Page , Stig Venaas Cc: ipng@sunroof.eng.sun.com Subject: Re: videocast References: <19990922102855.A10812@itea.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Kevin Page on Wed, Sep 22, 1999 at 01:28:27PM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Sep 22, 1999 at 01:28:27PM +0100, Kevin Page wrote: > On Wed, 22 Sep 1999, Stig Venaas wrote: > > It's great that you provide video, but I wish you would use a different > > format, it seems to require a RealVideo G2 player which is not available > > for any UNIX platforms. It might be easier for me to find a windows box, > > Real Player G2 alpha for linux is available at: > http://www.real.com/products/player/linux.html Solaris/Sparc? NetBSD/arm32? Two name the preferred platforms I would use... -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 22 05:51:51 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MCoai22619 for ipng-dist; Wed, 22 Sep 1999 05:50:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MCoRX22612 for ; Wed, 22 Sep 1999 05:50:27 -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 FAA09506 for ; Wed, 22 Sep 1999 05:50:27 -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 FAA04923 for ; Wed, 22 Sep 1999 05:50:26 -0700 (PDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA06748; Wed, 22 Sep 1999 05:50:09 -0700 (PDT) From: Bill Manning Message-Id: <199909221250.FAA06748@zephyr.isi.edu> Subject: Re: videocast To: krp@ecs.soton.ac.uk (Kevin Page) Date: Wed, 22 Sep 1999 05:50:09 -0700 (PDT) Cc: venaas@itea.ntnu.no, ipng@sunroof.eng.sun.com In-Reply-To: from "Kevin Page" at Sep 22, 99 01:28:27 pm 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 Great! Is it available for Solaris? > > On Wed, 22 Sep 1999, Stig Venaas wrote: > > It's great that you provide video, but I wish you would use a different > > format, it seems to require a RealVideo G2 player which is not available > > for any UNIX platforms. It might be easier for me to find a windows box, > > Real Player G2 alpha for linux is available at: > http://www.real.com/products/player/linux.html > > It's pretty stable in my experience. > > Regards, > > kev > > -- > Kevin Page Multimedia Research Group (Systems and Networks Group) > Department of Electronics and Computer Science, University of Southampton, UK > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 22 07:36:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MEXbx22718 for ipng-dist; Wed, 22 Sep 1999 07:33:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MEXSX22711 for ; Wed, 22 Sep 1999 07:33:28 -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 HAA26555 for ; Wed, 22 Sep 1999 07:33:27 -0700 (PDT) Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA11511 for ; Wed, 22 Sep 1999 08:33:27 -0600 (MDT) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Wed, 22 Sep 1999 15:32:39 +0100 Date: Wed, 22 Sep 1999 15:33:01 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Stig Venaas cc: Kazu Yamamoto , ipng@sunroof.eng.sun.com Subject: Re: videocast In-Reply-To: <19990922102855.A10812@itea.ntnu.no> 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 Wed, 22 Sep 1999, Stig Venaas wrote: > On Wed, Sep 22, 1999 at 12:29:58PM +0900, Kazu Yamamoto wrote: > > Videocast service over *IPv4* will be available during the interim > > meeting. For more information, pls refer to: > > http://www.wide.ad.jp/events/199909.ipng-interim/ > > It's great that you provide video, but I wish you would use a different > format, it seems to require a RealVideo G2 player which is not available > for any UNIX platforms. It might be easier for me to find a windows box, > than it is for you to provide something else though. Realplayer 5.0 is available cross-platform (Solaris, FreeBSD, SCO, Irix): http://www.real.com/products/player/50player/50download.html (to save y'all inspecting Real's site and giving up since it's not at all easy to find) but G2's "upwardly compatible" in a hell-is-other-people's-copy-of- Acrobat-4.0 kind of way; 5.0 is generally not much use, since much content is G2-encoded. I spent a lot of time communicating with Real techsupport when trying to get 5.0 to work under Solaris; it turns out that 5.0's handling of LD_LIBRARY_PATH is barely functional if you don't have anything else in LD_LIBRARY_PATH at all - and I did. I then turned down their offer to betatest G2 for them for nothing, since they wouldn't fix 5.0. L. Not that they've released G2 on Solaris since. Hmmph. I'd say a pox on them - but I believe they're blackholed anyway. 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 Wed Sep 22 08:14:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MFBPO22801 for ipng-dist; Wed, 22 Sep 1999 08:11:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MFBGX22794 for ; Wed, 22 Sep 1999 08:11: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 IAA20346 for ; Wed, 22 Sep 1999 08:11:16 -0700 (PDT) Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22596 for ; Wed, 22 Sep 1999 08:11:11 -0700 (PDT) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id PAA20733; Wed, 22 Sep 1999 15:11:01 GMT Message-Id: <199909221511.PAA20733@orchard.arlington.ma.us> To: Peter Tattam cc: IPNG Mailing List Subject: Re: Hostility between ISPs? In-Reply-To: Message from Peter Tattam of "Wed, 22 Sep 1999 15:49:46 +1000." Date: Wed, 22 Sep 1999 11:11:00 -0400 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Politically, I am having doubts as it leaves the small-medium ISPs > at the mercy of inter ISP politics, and we so it would have to be > pushed back to the internet regulators to find a solution to that > issue. > Solutions that give the end user greater control over multihoming > issues should continue to be sought. Indeed, the main attraction of multi-homing through use of of multiple (provider-assigned) prefixes is that it doesn't require cooperation from ISP's, and thus has far better scalability -- it stands a chance of working if every household winds up being multi-homed. - 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 Sep 22 08:36:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MFXph22830 for ipng-dist; Wed, 22 Sep 1999 08:33:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MFXdX22823 for ; Wed, 22 Sep 1999 08:33:40 -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 IAA17220 for ; Wed, 22 Sep 1999 08:33:36 -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 JAA07858 for ; Wed, 22 Sep 1999 09:33:35 -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 KAA13820; Wed, 22 Sep 1999 10:32:40 -0500 (CDT) Message-Id: <199909221532.KAA13820@gungnir.fnal.gov> To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: videocast In-reply-to: Your message of Wed, 22 Sep 1999 12:29:58 +0900. <19990922122958X.kazu@iijlab.net> Date: Wed, 22 Sep 1999 10:32:34 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Videocast service over *IPv4* will be available during the interim > meeting. For more information, pls refer to: > http://www.wide.ad.jp/events/199909.ipng-interim/ I'm not an expert on these proprietary media formats, but when I click the test link http://www.wide.ad.jp/events/199909.ipng-interim/interim.ram, my "RealPlayer(tm) (SOLARIS - SPARC) Version 5.0 Gold" says this is "not a RealAudio or RealVideo document". As far as I can see, there is no newer version available for any Unix flavor. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 22 08:54:14 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MFoOm22880 for ipng-dist; Wed, 22 Sep 1999 08:50:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MFoFX22873 for ; Wed, 22 Sep 1999 08:50:15 -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 IAA03040 for ; Wed, 22 Sep 1999 08:50:14 -0700 (PDT) Received: from newman.itea.ntnu.no (newman.itea.ntnu.no [129.241.18.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15708 for ; Wed, 22 Sep 1999 09:50:13 -0600 (MDT) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by newman.itea.ntnu.no (8.9.1/8.9.1) with ESMTP id QAA25253; Wed, 22 Sep 1999 16:50:12 +0100 (WET DST) From: Stig Venaas Received: (from venaas@localhost) by alfa.itea.ntnu.no (8.7.3/8.7.3) id RAA06617; Wed, 22 Sep 1999 17:50:37 +0200 (MET DST) Message-ID: <19990922175037.A18092@itea.ntnu.no> Date: Wed, 22 Sep 1999 17:50:37 +0200 To: Matt Crawford , Kazu Yamamoto Cc: ipng@sunroof.eng.sun.com Subject: Re: videocast References: <19990922122958X.kazu@iijlab.net> <199909221532.KAA13820@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199909221532.KAA13820@gungnir.fnal.gov>; from Matt Crawford on Wed, Sep 22, 1999 at 10:32:34AM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Sep 22, 1999 at 10:32:34AM -0500, Matt Crawford wrote: > > Videocast service over *IPv4* will be available during the interim > > meeting. For more information, pls refer to: > > http://www.wide.ad.jp/events/199909.ipng-interim/ > > I'm not an expert on these proprietary media formats, but when I click > the test link http://www.wide.ad.jp/events/199909.ipng-interim/interim.ram, > my "RealPlayer(tm) (SOLARIS - SPARC) Version 5.0 Gold" says this is > "not a RealAudio or RealVideo document". As far as I can see, there > is no newer version available for any Unix flavor. Yes, that's what I found too. It seems that one needs a G2 player. But as Kevin Page wrote, there is at least an alfa G2 player for Linux at http://www.real.com/products/player/linux.html. I think Free/Net-BSD might be able to use this as well. Thanks Kevin, Stig -- Stig Venaas UNINETT/NTNU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 22 10:13:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MH5R523077 for ipng-dist; Wed, 22 Sep 1999 10:05:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MH5HX23070 for ; Wed, 22 Sep 1999 10:05:18 -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 KAA08885 for ; Wed, 22 Sep 1999 10:05:16 -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 KAA11463 for ; Wed, 22 Sep 1999 10:05:14 -0700 (PDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id NAA11756; Wed, 22 Sep 1999 13:05:10 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000031514; Wed, 22 Sep 1999 13:05:09 -0400 (EDT) From: Jim Bound Message-Id: <199909221705.NAA0000031514@quarry.zk3.dec.com> To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of "Tue, 21 Sep 1999 15:02:11 EDT." <199909211902.PAA02017@endor.deas.harvard.edu> Date: Wed, 22 Sep 1999 13:05:08 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >|Lastly if you get to the point where one wants to swap IPv6 addresses on >|the fly discussion DO NOT ASSUME you have a valid solution if it does >|not address UDP and the affect to the APIs that are listening for >|connects on sockets. But I doubt you will have time to go here. > >Just wondering if this is a reference to my proposal, since it was the >most recent mention of swapping addresses (well, really swapping addresses >and identifiers)? If so, I just want to mention again that it is totally >transparent to all the upper protocols including UDP and it has no effect >on the listening APIs. No. It is not to any specific proposal. What is the draft name of your proposal? I have about 60 specs to pull over and a bit behind? In Ipv6 we don't have identifiers. So that will be interesting to understand what you mean. We do have addresses though? If anyone wants to swap the IP address and fake out the upper layers that is bogus but I will reiterate further if I see such an idea. We have permitted that with mobile IPv6 but that is because of ingress filtering. Doing this in an IP stack implementation is like running your care with the wrong oil weight for different seasons. /jim /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 Sep 22 10:25:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MHHtm23176 for ipng-dist; Wed, 22 Sep 1999 10:17:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MHHhX23166 for ; Wed, 22 Sep 1999 10:17:43 -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 KAA19052 for ; Wed, 22 Sep 1999 10:17:41 -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 KAA17574 for ; Wed, 22 Sep 1999 10:17:40 -0700 (PDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id NAA11885; Wed, 22 Sep 1999 13:17:35 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000002197; Wed, 22 Sep 1999 13:17:34 -0400 (EDT) From: Jim Bound Message-Id: <199909221717.NAA0000002197@quarry.zk3.dec.com> To: cc: ipng@sunroof.eng.sun.com, peter@jazz-1.trumpet.com.au Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of "Wed, 22 Sep 1999 09:06:36 BST." <5104D4DBC598D211B5FE0000F8FE7EB202DBA08A@mbtlipnt02.btlabs.bt.co.uk> Date: Wed, 22 Sep 1999 13:17:33 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I also thought Georges idea of summarizing the proposals is a good idea >> as that helped with the transition specs quite well. >> > Just to say that this was Peter Tattam's idea. I just thought it is >a good one as you did. > > George Whoops thanks George sorry Peter...Read mail very fast.... Anyway I still like it and liked Peter's idea of ground rules too. Also that all proposals should be given a hearing as this evolves. /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 Sep 22 10:25:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MHKh423199 for ipng-dist; Wed, 22 Sep 1999 10:20:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MHKVX23187 for ; Wed, 22 Sep 1999 10:20:31 -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 KAA19898 for ; Wed, 22 Sep 1999 10:20:29 -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 KAA18869 for ; Wed, 22 Sep 1999 10:20:28 -0700 (PDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id NAA02940; Wed, 22 Sep 1999 13:20:27 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000002002; Wed, 22 Sep 1999 13:20:26 -0400 (EDT) From: Jim Bound Message-Id: <199909221720.NAA0000002002@quarry.zk3.dec.com> To: Stig Venaas cc: Kazu Yamamoto , ipng@sunroof.eng.sun.com Subject: Re: videocast In-reply-to: Your message of "Wed, 22 Sep 1999 10:28:55 +0200." <19990922102855.A10812@itea.ntnu.no> Date: Wed, 22 Sep 1999 13:20:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Videocast service over *IPv4* will be available during the interim >> meeting. For more information, pls refer to: >> http://www.wide.ad.jp/events/199909.ipng-interim/ > >It's great that you provide video, but I wish you would use a different >format, it seems to require a RealVideo G2 player which is not available >for any UNIX platforms. It might be easier for me to find a windows box, >than it is for you to provide something else though. Good catch Stig. Hey folks I know the world has PCs permeating the planet for most users. But many of us are engineers and have to use our work stations for such stuff. In my case I only have UNIX gear. So like Stig I would be more capable maybe of seeing this if it just used IPv4 multicast and in a format we can see on UNIX boxes 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 Wed Sep 22 12:05:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MIkpH23384 for ipng-dist; Wed, 22 Sep 1999 11:46:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MIkeX23377 for ; Wed, 22 Sep 1999 11:46:42 -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 LAA15191 for ; Wed, 22 Sep 1999 11:46:39 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11851 for ; Wed, 22 Sep 1999 12:46:39 -0600 (MDT) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id OAA11085 for ; Wed, 22 Sep 1999 14:46:38 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id OAA07082 for ipng@sunroof.eng.sun.com; Wed, 22 Sep 1999 14:46:38 -0400 (EDT) Date: Wed, 22 Sep 1999 14:46:38 -0400 (EDT) Message-Id: <199909221846.OAA07082@endor.deas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: |No. It is not to any specific proposal. | |What is the draft name of your proposal? It has no name. It is merely a simple model I proposed to this list in response to the need for portable identifiers in support of multi-homing, session stability, etc. under the constraint that routable addresses will likely never be portable. I don't claim that it is the only or even the best (or even a good) model, but I was hoping to move beyond the ``we don't know any way to do it'' stage with an example. You can refer to my previous couple of postings for the details. |In Ipv6 we don't have identifiers. Exactly. I proposed to add them in such a way that presents no load to the backbone routers, requires no changes to applications or protocols above IP, and which could probably (with a little fiddling) interoperate with nodes not participating in the protocol. |If anyone wants to swap the IP address and fake out the upper layers |that is bogus but I will reiterate further if I see such an idea. I don't want to swap IP addresses per se; I want to swap an IP address with a different identifier drawn from a separate address space that happens to be the same size as the routable IP address space (merely to make the operation transparent to higher levels). N.B. the portable identifiers never appear in an IP header on the wire so it isn't even really a ``swap'' so much as allowing higher levels to use the portable identifier as a handle. |We have permitted that with mobile IPv6 but that is because of ingress |filtering. Doing this in an IP stack implementation is like running |your care with the wrong oil weight for different seasons. Sorry, I don't understand the analogy... Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 22 12:05:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MIkMQ23375 for ipng-dist; Wed, 22 Sep 1999 11:46:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MIkAX23367 for ; Wed, 22 Sep 1999 11:46: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 LAA15056 for ; Wed, 22 Sep 1999 11:46:09 -0700 (PDT) Received: from eastern.pmei.com (mail.pmei.com [204.156.0.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11529 for ; Wed, 22 Sep 1999 12:46:08 -0600 (MDT) Received: (from steve@localhost) by eastern.pmei.com (8.8.7/8.8.7) id OAA19679; Wed, 22 Sep 1999 14:50:31 -0400 Date: Wed, 22 Sep 1999 14:50:31 -0400 From: Steve Friedman Message-Id: <199909221850.OAA19679@eastern.pmei.com> To: bound@zk3.dec.com, george.tsirtsis@bt.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Cc: ipng@sunroof.eng.sun.com, peter@jazz-1.trumpet.com.au Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 22 12:22:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MJGYC23436 for ipng-dist; Wed, 22 Sep 1999 12:16:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MJGPX23429 for ; Wed, 22 Sep 1999 12:16: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 MAA19684 for ; Wed, 22 Sep 1999 12:16:20 -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 NAA25087 for ; Wed, 22 Sep 1999 13:16:19 -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 PAA28434 for ; Wed, 22 Sep 1999 15:16:11 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA17124 for ; Wed, 22 Sep 1999 15:16:08 -0400 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id PAA01848 for ; Wed, 22 Sep 1999 15:13:59 -0400 Message-Id: <199909221913.PAA01848@rotala.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: The great IP crunch of 2010 Date: Wed, 22 Sep 1999 15:13:58 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk http://www.cnn.com/TECH/computing/9909/21/ip.crunch.idg/index.html The next best thing to IPv6? http://www.cnn.com/TECH/computing/9909/21/ipv6.alternative.idg/index.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 22 12:42:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8MJXZ523462 for ipng-dist; Wed, 22 Sep 1999 12:33:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8MJXAX23455 for ; Wed, 22 Sep 1999 12:33:15 -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 MAA23928 for ; Wed, 22 Sep 1999 12:33:08 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA02110 for ; Wed, 22 Sep 1999 13:33:08 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Sep 1999 12:22:15 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Sep 1999 12:22:14 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515A7E@RED-MSG-50> From: Richard Draves To: "'Francis Dupont'" Cc: "'IPng List'" Subject: RE: I-D ACTION:draft-ietf-ipngwg-multi-isp-00.txt Date: Wed, 22 Sep 1999 12:22:06 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I like the idea of using router renumbering to temporarily deprecate the prefix obtained from a broken ISP. This would improve source address selection. Is there a problem with the denial-of-service provisions in RFC 2462 (stateless address autoconf)? When I first implemented that provision I thought it should apply to both the valid lifetime and preferred lifetime (which would prevent abruptly setting the preferred lifetime down to zero), but rereading the text now it seems to apply to only the valid lifetime. I'm not satisfied with the proposed use of mobility mechanisms. There are several problems: - Will H immediately send a binding update to X, or will H wait until it has some data that it wants to send to X and then include the binding update? If the latter, then X can't reach H for an unbounded period of time. - What if this is not a TCP connection, but X is using UDP to send to H? Then H won't know to send a binding update to X. - X will keep the binding update that it receives from H in its binding cache. Note that this is a cache. If the binding update should get dropped from the cache, then X will not be able to reach H. (In the mobility case, this is OK because H is still reachabile via the home agent.) - What if H and X are both multi-homed. They have a connection to each other via a shared ISP A. H is also connected to ISP B and X is also connected to ISP C. ISPs B & C are connected to each other. H and X establish a TCP connection using ISP A (per src/dst address selection, the common prefix is preferred). Now ISP A goes down. The proposed mechanism will not recover from 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 Wed Sep 22 20:26:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8N3NrE24131 for ipng-dist; Wed, 22 Sep 1999 20:23:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8N3NiX24124 for ; Wed, 22 Sep 1999 20:23: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 UAA08889 for ; Wed, 22 Sep 1999 20:23:42 -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 VAA07011 for ; Wed, 22 Sep 1999 21:23:42 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id NAA17181 for ; Thu, 23 Sep 1999 13:23:40 +1000 (EST) Date: Thu, 23 Sep 1999 13:23:40 +1000 (EST) From: Peter Tattam Reply-To: Peter Tattam To: IPNG Mailing List Subject: Re: multihoming proposals summary again. 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, 22 Sep 1999, Peter Tattam wrote: > I don't believe anybody has yet volunteered to put together this list. As I > raised the topic, I guess the responsibility falls on my shoulders. If no > volunteers come forward within a day, I can do it although I'm probably not the > best for the job as I also have vested interest in at least one proposal from > myself being considered. > > Are there any volunteers for an impartial person to create the summary list? > > I propose some ground rules should be laid... > > Once the list is published, it will be counter productive to argue over what is > listed, or the contents of suggested proposals. I would strongly recommend > that all discussion on the summary list be postponed until after the Interim > meeting has concluded and minutes are published. > > Also, to be fair, no proposal should be left off the list provided it meets the > technical standard of discussion acceptable to this mailing list. Whether it > works or not should not matter - that would (hopefully) be decided fairly > quickly at (or before?) the interim meeting. Of course a prudent course of > action would be to get a couple of key opinions beforehand from knowledgeable > individuals on the IPng working group (PRIVATELY!!!). > > If we can't agree on the ground rules... I won't bother. > > 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 > In the absence of volunteers, I will need to do this as time is running short. If you have a proposal, send it to me ASAP. I need, 1. Name of proposal (if you haven't thought of one do so, make it short or provide acceptable acronym) 2. Author(s), please provide email address(s) for questions. 3. If possible a one paragraph description. Try to be brief, and also try to place the key concept in one sentence. 4. A URL for the full proposal. This is a must. A reference to a mail message is not sufficient. It should be in a form that makes it easy to print out & view from a web browser. It doesn't have to be RFC formatted, but as long as it has enough detail to determine if it works it will be ok. And as stated in the ground rules, it should meet the technical standard expected of this mailing list. I will acknowledge receipt of each proposal. If you don't get a receipt within a day, make a LOUD noise on the list or send me a FAX & my secretary will pick it up. Don't forget we are in GMT+1000 time zone, one hour before Japan, about 8-11 hours before Europe and around 7-10 hours after North America. I'm usually online till at least 12am which puts me in contact with most of Asia & Europe. I'm also online for North American evenings, but usually asleep or recreation for most of North American working hours, although there is usually a slight overlap at either end of the working day. For starters, could I ask the following... a) Itojun to provide RFC2260 proposal details. b) Jessica to provide SMPL proposal details. c) Dan Lanciani to provide his proposal details. d) I will table mine. I may have missed some, apologies - these are only the ones most recently discussed. And, (I might get roasted here :) if there are *serious* proposals relating to non-aggregation, now's your chance, but it better be *exceptionally* good because that decision is already laid in concrete, and people don't want to tear up that concrete. I will table them, but please don't shoot the messenger. No cutoff time has been decided for the list, so I will keep it open as long as possible, and also post the list to ipng and also on my web site. 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 Sep 23 01:25:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8N8Lnn24323 for ipng-dist; Thu, 23 Sep 1999 01:21:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8N8LdX24316 for ; Thu, 23 Sep 1999 01:21: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 BAA19754 for ; Thu, 23 Sep 1999 01:21:39 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA16881 for ; Thu, 23 Sep 1999 01:21:09 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA09015; Thu, 23 Sep 1999 10:20:31 +0200 (MET DST) Message-ID: <19990923102031.B8988@theory.cs.uni-bonn.de> Date: Thu, 23 Sep 1999 10:20:31 +0200 From: Ignatios Souvatzis To: Stig Venaas , Matt Crawford , Kazu Yamamoto Cc: ipng@sunroof.eng.sun.com Subject: Re: videocast References: <19990922122958X.kazu@iijlab.net> <199909221532.KAA13820@gungnir.fnal.gov> <19990922175037.A18092@itea.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990922175037.A18092@itea.ntnu.no>; from Stig Venaas on Wed, Sep 22, 1999 at 05:50:37PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Sep 22, 1999 at 05:50:37PM +0200, Stig Venaas wrote: > On Wed, Sep 22, 1999 at 10:32:34AM -0500, Matt Crawford wrote: > > > Videocast service over *IPv4* will be available during the interim > > > meeting. For more information, pls refer to: > > > http://www.wide.ad.jp/events/199909.ipng-interim/ > > > > I'm not an expert on these proprietary media formats, but when I click > > the test link http://www.wide.ad.jp/events/199909.ipng-interim/interim.ram, > > my "RealPlayer(tm) (SOLARIS - SPARC) Version 5.0 Gold" says this is > > "not a RealAudio or RealVideo document". As far as I can see, there > > is no newer version available for any Unix flavor. > > Yes, that's what I found too. It seems that one needs a G2 player. > But as Kevin Page wrote, there is at least an alfa G2 player for > Linux at http://www.real.com/products/player/linux.html. I think > Free/Net-BSD might be able to use this as well. Thats only Linux/386, and I'd need to compile linux compat stuff into the kernel, and install half a dozen Linux shared libraries, and hope that it doesn't use yet another new Linux system call that the NetBSD emulation doesn't know about. _AND_ the PC is a loud machine... I'd prefer to use a DNARD running NetBSD/arm32. completely diskless, completely fanless, no noise. -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 Sep 23 02:18:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8N9FOh24369 for ipng-dist; Thu, 23 Sep 1999 02:15:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8N9FFX24362 for ; Thu, 23 Sep 1999 02:15:15 -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 CAA27739 for ; Thu, 23 Sep 1999 02:15:10 -0700 (PDT) From: george.tsirtsis@bt.com Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11490 for ; Thu, 23 Sep 1999 03:15:07 -0600 (MDT) Received: from cbtlipnt01.btlabs.bt.co.uk by arthur (local) with ESMTP; Thu, 23 Sep 1999 10:10:55 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id ; Thu, 23 Sep 1999 10:10:51 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB202DBA094@mbtlipnt02.btlabs.bt.co.uk> To: peter@jazz-1.trumpet.com.au, ipng@sunroof.eng.sun.com Subject: RE: multihoming proposals summary again. Date: Thu, 23 Sep 1999 10:10:41 +0100 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 > 4. A URL for the full proposal. This is a must. A reference to a mail > message > is not sufficient. It should be in a form that makes it easy to print out > & > view from a web browser. It doesn't have to be RFC formatted, but as long > as > it has enough detail to determine if it works it will be ok. > Peter I do not agree with this. At least some of the ideas around are increments on existing proposals or in an early stage and thus not worth putting them up on a web site. I think your requirement can be satisfied later for the proposals that will get the green light from the Interim meeting next week. Regards 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 Thu Sep 23 04:27:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NBP7J24457 for ipng-dist; Thu, 23 Sep 1999 04:25:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NBOxX24450 for ; Thu, 23 Sep 1999 04:24: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 EAA10209 for ; Thu, 23 Sep 1999 04:24:58 -0700 (PDT) From: george.tsirtsis@bt.com Received: from dent.axion.bt.co.uk (dent.axion.bt.co.uk [132.146.16.161]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA02291 for ; Thu, 23 Sep 1999 05:24:57 -0600 (MDT) Received: from cbtlipnt02.btlabs.bt.co.uk by dent (local) with ESMTP; Thu, 23 Sep 1999 11:37:44 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id ; Thu, 23 Sep 1999 11:36:21 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB202DBA097@mbtlipnt02.btlabs.bt.co.uk> To: richdr@microsoft.com, Francis.Dupont@inria.fr Cc: ipng@sunroof.eng.sun.com Subject: RE: I-D ACTION:draft-ietf-ipngwg-multi-isp-00.txt Date: Thu, 23 Sep 1999 11:36:10 +0100 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 > -----Original Message----- > From: Richard Draves [SMTP:richdr@microsoft.com] > Sent: Wednesday, September 22, 1999 8:22 PM > To: 'Francis Dupont' > Cc: 'IPng List' > Subject: RE: I-D ACTION:draft-ietf-ipngwg-multi-isp-00.txt > > I like the idea of using router renumbering to temporarily deprecate the > prefix obtained from a broken ISP. This would improve source address > selection. > > Is there a problem with the denial-of-service provisions in RFC 2462 > (stateless address autoconf)? When I first implemented that provision I > thought it should apply to both the valid lifetime and preferred lifetime > (which would prevent abruptly setting the preferred lifetime down to > zero), > but rereading the text now it seems to apply to only the valid lifetime. > Wouldn't Authenticated RR servers solve the problem? RR assumes that you use it under secure infrastructure, otherwise the above might be the least of your problems? 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 Thu Sep 23 04:45:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NBgrq24505 for ipng-dist; Thu, 23 Sep 1999 04:42:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NBgiX24498 for ; Thu, 23 Sep 1999 04:42:45 -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 EAA10977 for ; Thu, 23 Sep 1999 04:42:44 -0700 (PDT) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA24205 for ; Thu, 23 Sep 1999 04:42:42 -0700 (PDT) Received: from hygro.adsl.duke.edu (localhost [127.0.0.1]) by hygro.adsl.duke.edu (8.8.7/8.8.7) with ESMTP id HAA00928; Thu, 23 Sep 1999 07:42:50 -0400 Message-Id: <199909231142.HAA00928@hygro.adsl.duke.edu> To: Richard Draves cc: "'Francis Dupont'" , "'IPng List'" Subject: Re: I-D ACTION:draft-ietf-ipngwg-multi-isp-00.txt In-Reply-To: Message from Richard Draves of "Wed, 22 Sep 1999 12:22:06 PDT." <4D0A23B3F74DD111ACCD00805F31D81014515A7E@RED-MSG-50> Date: Thu, 23 Sep 1999 07:42:50 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is there a problem with the denial-of-service provisions in RFC 2462 > (stateless address autoconf)? When I first implemented that provision I > thought it should apply to both the valid lifetime and preferred lifetime > (which would prevent abruptly setting the preferred lifetime down to zero), > but rereading the text now it seems to apply to only the valid lifetime. It was specifically made to apply only to the valid lifetime as resetting that to 0 has immediate fatal consequences. In contrast, tinkering with the preferred lifetime shouldn't break things. I.e., if the only address you have becomes deprecated, you are still allowed to use it. 2462 says you SHOULD NOT use a deprecated address for new communication if a preferred address of sufficient scope exists. Thus, it still make sense for an implementation to try using a deprecated address if their are no other better addresses available. 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 Thu Sep 23 04:57:34 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NBsR924532 for ipng-dist; Thu, 23 Sep 1999 04:54:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NBsIX24525 for ; Thu, 23 Sep 1999 04:54:18 -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 EAA04576 for ; Thu, 23 Sep 1999 04:54:17 -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 EAA26261 for ; Thu, 23 Sep 1999 04:53:58 -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 NAA01443; Thu, 23 Sep 1999 13:53:52 +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 NAA07915; Thu, 23 Sep 1999 13:53:52 +0200 (MET DST) Message-Id: <199909231153.NAA07915@givry.inria.fr> From: Francis Dupont To: Peter Tattam cc: IPNG Mailing List Subject: Re: multihoming proposals summary again. In-reply-to: Your message of Thu, 23 Sep 1999 13:23:40 +1000. Date: Thu, 23 Sep 1999 13:53:51 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 1. Name of proposal (if you haven't thought of one do so, make it short or provide acceptable acronym) => mutual backup 2. Author(s), please provide email address(s) for questions. => Francis Dupont (as the editor) E-mail: Francis.Dupont@inria.fr 3. If possible a one paragraph description. Try to be brief, and also try to place the key concept in one sentence. => Take a site attached to two ISPs, with a line (and an agreement) between the two ISPs you can get a scheme with no long prefix injected to upper levels and which can cope with any single failure. This is a pure routing scheme, a kind of symmetric extension of Jessica's SMPL. 4. A URL for the full proposal. => draft-ietf-ipngwg-multi-isp-00.txt Section 5 (read previous sections to understand the issue and the solution) Francis.Dupont@inria.fr PS: if you have not my I-D in a window on your screen: ^ A/x and B/x ^ B/x and A/x | | +-----+ +-----+ | |------ A/x ---->| | | A | | B | | |<------ B/x ----| | +-----+ +-----+ ^ | B:S/x+y ^ | | | A:S/x+y | | | +-- A/x -+ +--------+ | | | | | +--------+ | | +- B/x --+ A:S/x+y | | | | B:S/x+y | V | V +--------+ | | | S | | | +--------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 23 05:04:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NC2kI24576 for ipng-dist; Thu, 23 Sep 1999 05:02:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NC2bX24569 for ; Thu, 23 Sep 1999 05:02: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 FAA02804 for ; Thu, 23 Sep 1999 05:02:36 -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 GAA08555 for ; Thu, 23 Sep 1999 06:02: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 OAA01786; Thu, 23 Sep 1999 14:02: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 OAA08667; Thu, 23 Sep 1999 14:02:32 +0200 (MET DST) Message-Id: <199909231202.OAA08667@givry.inria.fr> From: Francis Dupont To: Peter Tattam cc: IPNG Mailing List Subject: Re: multihoming proposals summary again. In-reply-to: Your message of Thu, 23 Sep 1999 13:23:40 +1000. Date: Thu, 23 Sep 1999 14:02:31 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 1. Name of proposal (if you haven't thought of one do so, make it short or provide acceptable acronym) => use of mobility mechanisms 2. Author(s), please provide email address(s) for questions. => Francis Dupont (as an editor) Francis.Dupont@inria.fr 3. If possible a one paragraph description. Try to be brief, and also try to place the key concept in one sentence. => a mechanism developped for IPv6 mobility, "bindings", can be reused for multihoming. This makes connection resilient to provider failures. 4. A URL for the full proposal. => draft-ietf-ipngwg-multi-isp-00.txt Sections 6 and 7. Bindings are described in draft-ietf-mobileip-ipv6-08.txt (and previous), the first document about the proposal is still available at http://www-dcg.fnal.gov/~crawdad/mhome/index.htm 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 Thu Sep 23 06:07:13 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8ND47C24635 for ipng-dist; Thu, 23 Sep 1999 06:04:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8ND3wX24628 for ; Thu, 23 Sep 1999 06:03: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 GAA07700 for ; Thu, 23 Sep 1999 06:03:59 -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 GAA12836 for ; Thu, 23 Sep 1999 06:03:58 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id WAA24626; Thu, 23 Sep 1999 22:53:57 +1000 (EST) Date: Thu, 23 Sep 1999 22:53:57 +1000 (EST) From: Peter Tattam To: george.tsirtsis@bt.com cc: ipng@sunroof.eng.sun.com Subject: RE: multihoming proposals summary again. In-Reply-To: <5104D4DBC598D211B5FE0000F8FE7EB202DBA094@mbtlipnt02.btlabs.bt.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ok. If you say so. I just don't want to see bombshells dropped at the interim meeting though. Peter On Thu, 23 Sep 1999 george.tsirtsis@bt.com wrote: > > > > > 4. A URL for the full proposal. This is a must. A reference to a mail > > message > > is not sufficient. It should be in a form that makes it easy to print out > > & > > view from a web browser. It doesn't have to be RFC formatted, but as long > > as > > it has enough detail to determine if it works it will be ok. > > > Peter > > I do not agree with this. At least some of the ideas around are > increments on existing proposals or in an early stage and thus not worth > putting them up on a web site. I think your requirement can be satisfied > later for the proposals that will get the green light from the Interim > meeting next week. > > > Regards > George > -- 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 Sep 23 07:47:38 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NEiqw24739 for ipng-dist; Thu, 23 Sep 1999 07:44:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NEihX24732 for ; Thu, 23 Sep 1999 07:44: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 HAA13752 for ; Thu, 23 Sep 1999 07:44:43 -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 IAA29281 for ; Thu, 23 Sep 1999 08:44:42 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id AAA01097 for ; Fri, 24 Sep 1999 00:44:40 +1000 (EST) Date: Fri, 24 Sep 1999 00:44:40 +1000 (EST) From: Peter Tattam To: IPNG Mailing List Subject: Re: multihoming proposals summary again. 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 Here is the latest list from responses sent to me. I have filled in the gaps for some I haven't received yet. http://jazz-1.trumpet.com.au/ipv6-draft/multihoming_summary.html Let me know if you want also a copy sent to the mailing list. 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 Sep 23 08:44:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NFfRc24881 for ipng-dist; Thu, 23 Sep 1999 08:41:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NFfEX24874 for ; Thu, 23 Sep 1999 08:41:16 -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 IAA24471 for ; Thu, 23 Sep 1999 08:41:13 -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 IAA09193 for ; Thu, 23 Sep 1999 08:41:13 -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 KAA20242; Thu, 23 Sep 1999 10:40:30 -0500 (CDT) Message-Id: <199909231540.KAA20242@gungnir.fnal.gov> To: george.tsirtsis@bt.com Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: I-D ACTION:draft-ietf-ipngwg-multi-isp-00.txt In-reply-to: Your message of Thu, 23 Sep 1999 11:36:10 BST. <5104D4DBC598D211B5FE0000F8FE7EB202DBA097@mbtlipnt02.btlabs.bt.co.uk> Date: Thu, 23 Sep 1999 10:40:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Is there a problem with the denial-of-service provisions in RFC 2462 > > (stateless address autoconf)? When I first implemented that provision I > > thought it should apply to both the valid lifetime and preferred lifetime > > ... > > but rereading the text now it seems to apply to only the valid lifetime. > > Wouldn't Authenticated RR servers solve the problem? RR assumes that > you use it under secure infrastructure, otherwise the above might be the > least of your problems? No, Rich is talking about the router-to-host communication of the lifetimes which were modified by the (secure, I hope!) network- management-to-router RR transaction. The host does not participate in RR so all it sees is that some prefix which was recently advertised with a big preferred lifetime now has a zero. Securing the router advertisements is possible in theory, but I do not think it will be practical for quite some time. 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 Thu Sep 23 09:07:20 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NG2dm24940 for ipng-dist; Thu, 23 Sep 1999 09:02:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NG2VX24932 for ; Thu, 23 Sep 1999 09:02:31 -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 JAA10024 for ; Thu, 23 Sep 1999 09:02:31 -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 KAA03131 for ; Thu, 23 Sep 1999 10:02:29 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id CAA06510 for ; Fri, 24 Sep 1999 02:02:28 +1000 (EST) Date: Fri, 24 Sep 1999 02:02:27 +1000 (EST) From: Peter Tattam To: IPNG Mailing List Subject: Re: multihoming proposals summary again. 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 There was a broken link in summary. It has now been fixed, and I have verified that all other links now work. Peter On Fri, 24 Sep 1999, Peter Tattam wrote: > Here is the latest list from responses sent to me. I have filled in the gaps > for some I haven't received yet. > > http://jazz-1.trumpet.com.au/ipv6-draft/multihoming_summary.html > > Let me know if you want also a copy sent to the mailing list. > > 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 > -------------------------------------------------------------------- > -- 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 Sep 23 09:07:34 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NG5JH24953 for ipng-dist; Thu, 23 Sep 1999 09:05:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NG59X24946 for ; Thu, 23 Sep 1999 09:05:09 -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 JAA05329 for ; Thu, 23 Sep 1999 09:05:09 -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 KAA04412 for ; Thu, 23 Sep 1999 10:05:08 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA15087; Thu, 23 Sep 1999 09:04:31 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Thu, 23 Sep 1999 09:04:34 -0700 To: Peter Tattam From: Steve Deering Subject: Re: multihoming proposals summary again. Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, Thank-you for stepping forward to help organize and categorize recent multihoming ideas -- your web page looks good, and it will be very useful input to the working group. Note, however, that it is inappropriate for you to start declaring conditions on which ideas shall be considered (e.g., only those that have a URL) or which ideas will be discussed in which order at the interim meeting. The working group began the task of considering solutions to IPv6 multihoming problems at the last IETF meeting, and a consensus was reached on some basic aspects of the problem (e.g., that IPv6's support for multiple addresses per interface necessarily implies the need for host-based, not just router-based or ISP-based, mechanisms), and on some specific directions to pursue. Please see the minutes for both the summary and conclusions; we will review those previous understandings at the interim meeting. We continue to welcome additions to the agenda for the interim meeting, for anyone wishing to present additional ideas or proposals for solving aspects of multihoming. Peter: would you like an agenda slot to present your collation of ideas and/or a summary of the state of the mailing list discussions? We will, of course, also accept changes to the agenda in real time at the start of the meeting, as usual. Bob Hinden / Steve Deering IPng 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 Thu Sep 23 10:02:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NGr0k25098 for ipng-dist; Thu, 23 Sep 1999 09:53:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NGqkX25091 for ; Thu, 23 Sep 1999 09:52:51 -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 JAA19952 for ; Thu, 23 Sep 1999 09:52:46 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA26901 for ; Thu, 23 Sep 1999 10:52:45 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 23 Sep 1999 08:42:34 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Sep 1999 08:42:34 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515A90@RED-MSG-50> From: Richard Draves To: "'Thomas Narten'" Cc: "'Francis Dupont'" , "'IPng List'" Subject: RE: I-D ACTION:draft-ietf-ipngwg-multi-isp-00.txt Date: Thu, 23 Sep 1999 08:42:29 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It was specifically made to apply only to the valid lifetime as > resetting that to 0 has immediate fatal consequences. In contrast, > tinkering with the preferred lifetime shouldn't break things. I.e., if > the only address you have becomes deprecated, you are still allowed to > use it. 2462 says you SHOULD NOT use a deprecated address for new > communication if a preferred address of sufficient scope exists. Thus, > it still make sense for an implementation to try using a deprecated > address if their are no other better addresses available. OK, so I just misread it the first time. 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 Thu Sep 23 10:44:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NHaYP25232 for ipng-dist; Thu, 23 Sep 1999 10:36:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NHaOX25222 for ; Thu, 23 Sep 1999 10:36: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 KAA17064 for ; Thu, 23 Sep 1999 10:36:23 -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 LAA17897 for ; Thu, 23 Sep 1999 11:36:22 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id DAA12470; Fri, 24 Sep 1999 03:36:19 +1000 (EST) Date: Fri, 24 Sep 1999 03:36:19 +1000 (EST) From: Peter Tattam To: Steve Deering cc: ipng@sunroof.eng.sun.com Subject: Re: multihoming proposals summary again. 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 All, Just for the record, I want to publicly state that the preparation of the summary is not in any way intended to usurp the agenda of the meeting or the wishes of those chairing and organizing the meeting. The summary serves only to make sure that I (a self professed newbie) and possibly others know what the heck we are talking about and not waste valuable time going over old ground at the meeting itself. It is also a result of having been blasted a few times for not having read all the specs. I humbly apologize for any misunderstandings related to this issue. Regards Peter On Thu, 23 Sep 1999, Steve Deering wrote: > Peter, > > Thank-you for stepping forward to help organize and categorize recent > multihoming ideas -- your web page looks good, and it will be very > useful input to the working group. > > Note, however, that it is inappropriate for you to start declaring > conditions on which ideas shall be considered (e.g., only those that > have a URL) or which ideas will be discussed in which order at the > interim meeting. > > The working group began the task of considering solutions to IPv6 > multihoming problems at the last IETF meeting, and a consensus was > reached on some basic aspects of the problem (e.g., that IPv6's support > for multiple addresses per interface necessarily implies the need for > host-based, not just router-based or ISP-based, mechanisms), and on > some specific directions to pursue. Please see the minutes for both > the summary and conclusions; we will review those previous understandings > at the interim meeting. > > We continue to welcome additions to the agenda for the interim meeting, > for anyone wishing to present additional ideas or proposals for solving > aspects of multihoming. Peter: would you like an agenda slot to present > your collation of ideas and/or a summary of the state of the mailing list > discussions? > > We will, of course, also accept changes to the agenda in real time at > the start of the meeting, as usual. > > Bob Hinden / Steve Deering > IPng 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 > -------------------------------------------------------------------- > -- 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 Sep 23 11:25:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NILnr25367 for ipng-dist; Thu, 23 Sep 1999 11:21:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NILeX25360 for ; Thu, 23 Sep 1999 11:21: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 LAA11962 for ; Thu, 23 Sep 1999 11:21:39 -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 LAA24510 for ; Thu, 23 Sep 1999 11:21:38 -0700 (PDT) Received: by odin.digi-data.com id <15233>; Thu, 23 Sep 1999 14:18:07 -0400 Message-Id: <99Sep23.141807gmt-0400.15233@odin.digi-data.com> Date: Thu, 23 Sep 1999 14:24:06 -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: Peter Tattam CC: Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: multihoming proposals summary again. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Peter, You might also want to consider asking the authors for some way to contact them, so as to obtain a copy of their propositions, in lieu of a URL for their propositions. Some will not yet have their propositions published in any form yet. 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 Sep 23 12:45:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NJaVB25486 for ipng-dist; Thu, 23 Sep 1999 12:36:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NJaKX25479 for ; Thu, 23 Sep 1999 12:36: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 MAA27131 for ; Thu, 23 Sep 1999 12:36:19 -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 MAA28301 for ; Thu, 23 Sep 1999 12:36:19 -0700 (PDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id PAA08944; Thu, 23 Sep 1999 15:36:16 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000005598; Thu, 23 Sep 1999 15:36:15 -0400 (EDT) From: Jim Bound Message-Id: <199909231936.PAA0000005598@quarry.zk3.dec.com> To: robert@digi-data.com cc: Peter Tattam , Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: multihoming proposals summary again. In-reply-to: Your message of "Thu, 23 Sep 1999 14:24:06 EDT." <99Sep23.141807gmt-0400.15233@odin.digi-data.com> Date: Thu, 23 Sep 1999 15:36:15 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk good idea also check that all authors can be present at the meeting. if they can't the chairs probably know but thought I would add this logic check 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 Thu Sep 23 13:22:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8NKI2Z25696 for ipng-dist; Thu, 23 Sep 1999 13:18:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8NKHrX25689 for ; Thu, 23 Sep 1999 13:17: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 NAA04570 for ; Thu, 23 Sep 1999 13:17:52 -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 NAA16727 for ; Thu, 23 Sep 1999 13:17:51 -0700 (PDT) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id QAA15225; Thu, 23 Sep 1999 16:17:50 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id QAA0000014983; Thu, 23 Sep 1999 16:17:49 -0400 (EDT) From: Jim Bound Message-Id: <199909232017.QAA0000014983@quarry.zk3.dec.com> To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of "Wed, 22 Sep 1999 14:46:38 EDT." <199909221846.OAA07082@endor.deas.harvard.edu> Date: Thu, 23 Sep 1999 16:17:48 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Dan, |What is the draft name of your proposal? >It has no name. It is merely a simple model I proposed to this list in >response to the need for portable identifiers in support of multi-homing, >session stability, etc. under the constraint that routable addresses will >likely never be portable. I don't claim that it is the only or even the >best (or even a good) model, but I was hoping to move beyond the ``we don't >know any way to do it'' stage with an example. You can refer to my previous >couple of postings for the details. OK I found 1 posting which I will read. |In Ipv6 we don't have identifiers. >Exactly. I proposed to add them in such a way that presents no load to the >backbone routers, requires no changes to applications or protocols above IP, >and which could probably (with a little fiddling) interoperate with nodes not >participating in the protocol. OK will read. |If anyone wants to swap the IP address and fake out the upper layers |that is bogus but I will reiterate further if I see such an idea. >I don't want to swap IP addresses per se; I want to swap an IP address >with a different identifier drawn from a separate address space that >happens to be the same size as the routable IP address space (merely >to make the operation transparent to higher levels). N.B. the portable >identifiers never appear in an IP header on the wire so it isn't even >really a ``swap'' so much as allowing higher levels to use the portable >identifier as a handle. I will respond if I don't get it. >|We have permitted that with mobile IPv6 but that is because of ingress >|filtering. Doing this in an IP stack implementation is like running >|your care with the wrong oil weight for different seasons. > >Sorry, I don't understand the analogy... Last sentence had typo. "care" should have been "car". But... In IPv6 mobile when you send a packet in some instances the implementation must use an address which passes ingress filtering and is done at the virtual network layer. See the IPv6 mobile spec. I am concerned when we are asked as network implementors who ship products that we have to alter addresses in transit on an end system (not router) that was not specifically requested by the application layer, in the network layer (or anywhere in the virtual stack we speak of in the kernel of an OS). We can do it but we need to be very careful in doing so and should look for alternatives to any models that propose such a strategy. I was likening it to a automobile that can use a heavier weight oil in its engine during the summer months, but could have negative affects to the overall engine when temperatures get really hot like 90-100 degrees F'. It is nitpicking but thats what I do as an engineer. Its like my performance ranting in IPv6 when folks want to add a little code here and a little code here. For example if we loose 10 milsecs for mobility, 100 milsecs for addr selection, 200 milsecs for NUD in ND, 3000 milsecs for some transition scheme, 50000 milsecs for IPsec, etc. etc. etc while designing the outer edges of the IPv6 core we eventually will loose 50 seconds or more adding it all up. I look at IPv6 as an engineer with a Gestalt hat on and look at the big picture or as some say get off the playing field and sit in the grandstands once in awhile. This will be very important to do for multihoming fixes, renumbering, security, and changing addresses on the fly. Which I do see you do not propose by the way on my first read of your mail message. One reason I rant is a business reason. If IPv6 does not perform as equally as fast as IPv4 it is dead. No matter how many better functions we put in the protocol architecture, except for IPsec and other security which some of the market are willing to take a performance hit on (but not all and some won't use it). I don't agree with this personally because I think IPv6 is so superior to IPv4 its not even a race technically. But I am not and cannot be a salesman or marketeer so I go with the flow and the flow is right now IPv6 cannot perform worse than IPv4 for anything. 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 Thu Sep 23 19:38:03 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8O2Ykw26261 for ipng-dist; Thu, 23 Sep 1999 19:34:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8O2YbX26254 for ; Thu, 23 Sep 1999 19:34:37 -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 TAA12234 for ; Thu, 23 Sep 1999 19:34:36 -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 UAA27045 for ; Thu, 23 Sep 1999 20:34:35 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA17877; Fri, 24 Sep 1999 12:34:19 +1000 (EST) Date: Fri, 24 Sep 1999 12:34:19 +1000 (EST) From: Peter Tattam To: Robert Honore cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: multihoming proposals summary again. In-Reply-To: <99Sep23.141807gmt-0400.15233@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 On Thu, 23 Sep 1999, Robert Honore wrote: > Dear Peter, > > You might also want to consider asking the authors for some way to contact them, > so as to obtain a copy of their propositions, in lieu of a URL for their > propositions. Some will not yet have their propositions published in any form > yet. > > 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 > -------------------------------------------------------------------- > I will be happy to do this. Also, I will adding some temporary email addresses for authors who may be in transit at meetings over the next few weeks. And let me know if there are any other alterations to the document. 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 Sep 23 21:02:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8O3xb726312 for ipng-dist; Thu, 23 Sep 1999 20:59:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8O3xSX26305 for ; Thu, 23 Sep 1999 20:59:28 -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 UAA12878 for ; Thu, 23 Sep 1999 20:59:27 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06302 for ; Thu, 23 Sep 1999 20:59:26 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id MAA29601 for ; Fri, 24 Sep 1999 12:59:25 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA21743 for ; Fri, 24 Sep 1999 12:59:25 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA26756 for ; Fri, 24 Sep 1999 12:59:24 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: realvideo From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b1 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: <19990924125905B.kazu@iijlab.net> Date: Fri, 24 Sep 1999 12:59:05 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 12 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We decide to audio/videocast with the following formats: RealAudio v5 old format: audio only, some clients for Unix platforms RealVideo G2 new format: with video Also, we will probably provide archive services for both. If your firewall filters out RealAudio, please use this service. This is what we can do the best and we can't take further requests. Thank you for understanding. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 23 22:48:38 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8O5Ywc26410 for ipng-dist; Thu, 23 Sep 1999 22:34:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8O5YhX26403 for ; Thu, 23 Sep 1999 22:34: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 WAA05040 for ; Thu, 23 Sep 1999 22:34:41 -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 XAA11246 for ; Thu, 23 Sep 1999 23:34:42 -0600 (MDT) Received: from new (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id WAA09013; Thu, 23 Sep 1999 22:34:40 -0700 (PDT) Message-Id: <4.2.0.58.19990923222836.03c4bc90@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 23 Sep 1999 22:32:43 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Updated IPng Tokyo Meeting Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The updated agenda for next weeks IPng w.g. meeting in Tokyo is attached. Requests for changes and corrections to and . Bob ------------------------------------------------------------- Agenda for IETF IPng w.g. Meeting September 29, 1999 - October 1, 1999 Tokyo Meeting hosted by the WIDE Group Meeting information can be found at: http://www.wide.ad.jp/events/199909.ipng-interim/ Wednesday / 29 September 1999 ----------------------------- 10:00-12:00 Introduction / S. Deering, B. Hinden Local Site Introduction / Jun Murai ICANN IPv6 Status / Jun Murai Multihoming - IPv6 Address Scoping Model / S. Deering - Multihoming Overview / S. Deering - Near term host mechanisms / R. Draves o Source & Destination Address Selection o Policy Issues for Source & Destination Address Selection / G. Tsirtsis 13:00 - 17:00 - Mobile IP Mechanisms for Multihoming / F. Dupont - Longer term Host Mechanisms / E. Nordmark o API w/ DNS Names interface o Multiple addresses per Connection o Preserving Active TCP Sessions / P. Tattam Thursday / 30 September 1999 ---------------------------- 09:00 - 12:00 Multihoming (continued) - Router Only Mechanisms / Itojun o RFC2260 Style for IPv6 o Multiple Prefix ISP Support o Use of Router Renumbering for ISP Selection / G. Tsirtsis 13:00 - 17:00 Model for IPv6 Renumbering / B. Hinden Plug & Play Architecture / S. Deering Friday / 1 October 1999 ----------------------- 09:00 - 12:00 API Issues / E. Nordmark - Multihoming - Scoping -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 24 05:57:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8OCsRL26617 for ipng-dist; Fri, 24 Sep 1999 05:54:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8OCsIX26610 for ; Fri, 24 Sep 1999 05:54:19 -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 FAA14766 for ; Fri, 24 Sep 1999 05:54:19 -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 FAA25132 for ; Fri, 24 Sep 1999 05:54:09 -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 OAA12454; Fri, 24 Sep 1999 14:53:53 +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 OAA11373; Fri, 24 Sep 1999 14:53:52 +0200 (MET DST) Message-Id: <199909241253.OAA11373@givry.inria.fr> From: Francis Dupont To: Richard Draves Cc: IPng list Subject: Re: I-D ACTION:draft-ietf-ipngwg-multi-isp-00.txt In-reply-to: Your message of Thu, 23 Sep 1999 08:46:42 PDT. <4D0A23B3F74DD111ACCD00805F31D81014515A91@RED-MSG-50> Date: Fri, 24 Sep 1999 14:53:38 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > - X will keep the binding update that it receives from H > in its binding > cache. Note that this is a cache. If the binding update > should get dropped > from the cache, then X will not be able to reach H. (In > the mobility case, > this is OK because H is still reachabile via the home agent.) > > => I have already received a comment about this problem. I have to add > some statements about a reasonnable refreshing strategy for binding > updates (the real mobility uses by default detection of traffic at the > mobile end of the tunnel, more important for the real > mobility bindings > are only an optimization). I think it's a big problem. Even it you put in some refreshing strategy, it's not clear how that might interact with different caching strategies. There will likely be intermittent losses of connectivity. => perhaps we need a new bit in binding updates because for the real mobility when connectivity seems to be lost then bindings should be flushed which is the opposite. I've put back the IPng list in this discussion, if you are not familiar with IPv6 mobility skip this. When a mobile goes from home to visit a loss of a binding is not important because traffic will come through the tunnel via the home agent. When a mobile goes from visit to another place (visit or home) then the old care-of address can be no more usable then a binding update loss has an impact. If for some reasons all binding updates are lost then the correspondant will flush the binding (on timeout or because connectivity seems bad) and use again the tunnel via the home agent. Then the right action when something can be wrong is to flush bindings, this behavior is not what we'd like to get for mobility then we need a way to signal the condition (a bit or something else). Francis.Dupont@inria.fr PS: other issues are correspondent detection and security negociation. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 24 20:22:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8P3JkD27462 for ipng-dist; Fri, 24 Sep 1999 20:19:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8P3JbX27455 for ; Fri, 24 Sep 1999 20:19: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 UAA08450 for ; Fri, 24 Sep 1999 20:19:38 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25881 for ; Fri, 24 Sep 1999 20:19:37 -0700 (PDT) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id XAA28803 for ; Fri, 24 Sep 1999 23:19:36 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id XAA18423 for ipng@sunroof.eng.sun.com; Fri, 24 Sep 1999 23:19:35 -0400 (EDT) Date: Fri, 24 Sep 1999 23:19:35 -0400 (EDT) Message-Id: <199909250319.XAA18423@endor.deas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: [...] |It is nitpicking but thats what I do as an |engineer. Its like my performance ranting in IPv6 when folks want to |add a little code here and a little code here. Indeed, as an engineer myself I am very sympathetic to this. Unfortunately, as IPv6 nears deployment (or failure) we may have to be more salesmen than engineers. Sigh. |One reason I rant is a business reason. If IPv6 does not perform as |equally as fast as IPv4 it is dead. I would go beyond this to say that if IPv6 makes obtaining certain functionality significantly harder than it was under IPv4 the effect may be even worse than a mere speed deficit. (Increasing hardware capacity can quickly make up for minor fixed-cost overhead, but it will probably never bring back lost functionality.) Of course, my expectations may not correspond well to the current mass market. Although I don't pretend to be a pioneer in the area (my hands-on experience with tcp/ip protocol implementation didn't really start until ~1982), the level of flexibility available to end users in those "old days" probably spoiled me. As a result, I have a strong negative reaction when I see such services as multi-homing, session stability and the like being viewed as special cases likely available only to the few/big/rich customers. Now as I said, I may be spoiled. Over the course of the 17 or so years that I've been developing tcp/ip stacks and related protocols I've observed the incredible changes in the field, the emergence of the ISP industry, the beginnings of the web, etc. The expectations of mass market end users have certainly changed (hey, there was no mass market not too long ago!). In some ways those expectations have increased, e.g., who would have thought that you would be able to get information from just about any interesting company by typing its name between a www and a com? In other--perhaps more technical--ways those expectations have decreased. To many a net connection is a dialup with a dynamic IP address. If something breaks you just keep re-dialing or maybe you reinstall Windows. Only the techies (and maybe old timers) worry about 24/7 connectivity and multi-homing their little networks. Well, maybe the techies, the old timers, and big business. Or is it little business too? Or is it maybe everyone once we become even more net-dependent? I certainly don't know the answer, and, more importantly I don't know what potential users think the answer is (if they even think about the question). I know I'll always advocate making as much flexibility as possible available at all levels while trying to avoid implementation limits that support a high-price-by-scarcity market. But that's just me... Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Sep 25 07:12:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8PE5G427664 for ipng-dist; Sat, 25 Sep 1999 07:05:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8PE57X27657 for ; Sat, 25 Sep 1999 07:05: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 HAA26964 for ; Sat, 25 Sep 1999 07:05:03 -0700 (PDT) Received: from samantha.lysator.liu.se (samantha.lysator.liu.se [130.236.254.202]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14034 for ; Sat, 25 Sep 1999 08:05:02 -0600 (MDT) Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206]) by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id QAA06550; Sat, 25 Sep 1999 16:04:19 +0200 (MET DST) Received: (from nisse@localhost) by sanna.lysator.liu.se (8.8.8/8.8.7) id QAA01289; Sat, 25 Sep 1999 16:04:39 +0200 (MET DST) To: Francis Dupont Cc: itojun@iijlab.net, Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: <199909191744.TAA03002@givry.inria.fr> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 25 Sep 1999 16:04:38 +0200 In-Reply-To: Francis Dupont's message of "Sun, 19 Sep 1999 19:44:50 +0200" Message-ID: Lines: 51 X-Mailer: Gnus v5.4.59/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is one thing about the authentication needed to avoid making things like tcp-hijacking trivial, which I've been thinking about for a few days. Please correct me if the analysis is somehow flawed. Francis Dupont writes: > - build the Security Association at the connection establishment > (ie before a path failure). This has no cost if the connection > uses a security service, for instance in order to avoid TCP reset > from the bad guy. If you only want protection against tcp-hijacking, I suspect that it is good enough to use something like anonymous diffie-hellman to create a key that is used to authenticate any packet that requests subsequent tcp packets to be sent to (or accepted from, if any filtering based on source address is done) a new address or location. The reason is quite simple: Any attacker that can perform an active man in the middle attack in this handshake could do arbitrary evil things with the tcp session *without* hijacking it. The important thing here: Assume we want things like tcp to survive renumbering (using mobile-ip, or gse-like addresses, whatever), and we think that the (in)security of ordinary tcp is good enough for the application. Then we can get comparable level of (in)security, and survivability, *without* introducing any key management infrastructure, preshared secrets or certificates. I also think it would be a good thing to clarify exactly what level of security is wanted for (in)secure traffic. This does seem like a strange thing to be talking about, but I suspect it is important. It's definitely one of the main points of the esd-analysis. Perhaps it is good to be a little more concrete, so lets take an example of an reasonable application using insecure tcp: Say I'm using ssh to connect from a local machine (which might be mobile, or renumbered from time to time). I don't need any extra authentication for the _data_ in the tcp session (as sufficient authentication is provided by the application). Connections can live for a long time, and I'd like them to survive things like site renumbering, temporary ISP-failures of a multihomed site, i.e. all the scenarios that have been discussed here. What level of security is it reasonable to expect from the network and transport layers? As far as I can tell, we'd like it to at least not be trivial for an attacker to cause the tcp session to die. Is that true for ipv4? And is it correct that simple "anonymous" authentication as described above provides similar (or better) protection also in the presens of things like binding-update? /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 25 07:31:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8PEQbh27779 for ipng-dist; Sat, 25 Sep 1999 07:26:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8PEQSX27772 for ; Sat, 25 Sep 1999 07:26: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 HAA12638 for ; Sat, 25 Sep 1999 07:26:28 -0700 (PDT) Received: from deadprotocol.org (liahona.lightrealm.com [209.95.111.218]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17970 for ; Sat, 25 Sep 1999 08:26:27 -0600 (MDT) Received: from deadprotocol.org (dialupG66.omah.uswest.net [209.180.107.66]) by deadprotocol.org (8.8.7/8.8.5) with ESMTP id HAA06785 for ; Sat, 25 Sep 1999 07:25:16 -0700 (PDT) Message-ID: <37ECE996.4AB7D14E@deadprotocol.org> Date: Sat, 25 Sep 1999 09:26:24 -0600 From: Greg vdG Reply-To: backbone@deadprotocol.org Organization: Method-One Technologies X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: <199909250319.XAA18423@endor.deas.harvard.edu> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Concerning Dan's view here, I may dissagree. Yes, as far as I, and most other professionals who understand what they are working with, are concerned, performance mattters. But here we are talking about "selling" this product. We are selling it to the end user, who knows little about how it works, or even that it's there. Granted there are the more educated users out there, but markets do not catter to them, markets catter to whichever group will be spending the money. People thought windows95 was the greatest thing, upgraded to it, spent billions, even though they didn't understand it. Hell, people didn't even know if they needed it. It was 13% slower than Windows 3.x. The same happened for windows98, which in turn was 8% slower than Win95. Reduced performance will not be a hangup unless it hits figures above a 30-50% reduction in speed which so far we are well clear of. It's quite simple, people wil buy what is sold to them. As far as the manufacturers picking up IPv6, things seem to be in OK shape. Most large manufacturers are already develloping early support for their platforms, this includes Sun, SGI, Cisco, DEC, IBM, Novell, and many more. I do agree, however, that the loss of functionality presents a much larger impact than performance. Granted, some features have been removed. But we must remember why these features where removed. They were either inneficient, or seldom used, or simply broken. Remember also that new features have been added, some of which I view as tremendous. While I miss riding my bike where I could do power skids with my rear tire, I much prefer driving to work in a car. IPv4 simply cannot carry on forever. So, while IPv6 (in my humble opinion) may not be comming to the end user for quite some time, it is coming... Greg Dan Lanciani wrote: > Jim Bound wrote: > > [...] > |It is nitpicking but thats what I do as an > |engineer. Its like my performance ranting in IPv6 when folks want to > |add a little code here and a little code here. > > Indeed, as an engineer myself I am very sympathetic to this. Unfortunately, > as IPv6 nears deployment (or failure) we may have to be more salesmen than > engineers. Sigh. > *snip* -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 25 12:09:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8PJ1R427975 for ipng-dist; Sat, 25 Sep 1999 12:01:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8PJ1Hi27968 for ; Sat, 25 Sep 1999 12:01:18 -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 MAA18786 for ; Sat, 25 Sep 1999 12:01:17 -0700 (PDT) Received: from minuet.das.harvard.edu (mail.eas.harvard.edu [140.247.50.251]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20894 for ; Sat, 25 Sep 1999 13:01:16 -0600 (MDT) Received: from endor.eas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id PAA04088 for ; Sat, 25 Sep 1999 15:01:15 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.eas.harvard.edu (8.8.8/8.8.8) id PAA21786 for ipng@sunroof.eng.sun.com; Sat, 25 Sep 1999 15:01:15 -0400 (EDT) Date: Sat, 25 Sep 1999 15:01:15 -0400 (EDT) Message-Id: <199909251901.PAA21786@endor.eas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk nisse@lysator.liu.se (Niels Möller) wrote: |I also think it would be a good thing to clarify exactly what level of |security is wanted for (in)secure traffic. This does seem like a |strange thing to be talking about, but I suspect it is important. I agree that it is very important. I found myself having great difficulty responding quantitatively with respect to my portable identifier proposal to concerns about "less" security because the delta between insecure and more insecure is both small and elusive. If you have, say, 10 quick and easy ways to interfere with a tcp connection and then you make a change such that there are now 11, has the security really gone down? |What level of security is it reasonable to expect from the network and |transport layers? As far as I can tell, we'd like it to at least not |be trivial for an attacker to cause the tcp session to die. Is that |true for ipv4? No, it's pretty trivial under IPv4 to kill a session. The net seems to go about its business in spite of this... |And is it correct that simple "anonymous" |authentication as described above provides similar (or better) |protection also in the presens of things like binding-update? Protecting against everything but man-in-the-middle attacks certainly seems to be a step up since as a practical matter man-in-the-middle attacks (at least those not originating in one of the organizations of the endpoints) are harder for random users to implement. On the other hand, it isn't obviously worthwhile to implement such a solution in parallel to full crypto authentication: you add a lot more code and protocol complexity for an option that many would not understand as significantly different from "real" authentication. Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 27 00:15:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8R7CdU28758 for ipng-dist; Mon, 27 Sep 1999 00:12:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8R7CUi28751 for ; Mon, 27 Sep 1999 00:12: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 AAA03194 for ; Mon, 27 Sep 1999 00:12:31 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA14872 for ; Mon, 27 Sep 1999 01:12:30 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id QAA08933 for ; Mon, 27 Sep 1999 16:12:28 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id QAA02808 for ; Mon, 27 Sep 1999 16:12:28 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id QAA13174 for ; Mon, 27 Sep 1999 16:12:28 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: Re: Updated IPng Tokyo Meeting Agenda From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <4.2.0.58.19990923222836.03c4bc90@mailhost.iprg.nokia.com> References: <4.2.0.58.19990923222836.03c4bc90@mailhost.iprg.nokia.com> X-Mailer: Mew version 1.95b1 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: <19990927161213V.kazu@iijlab.net> Date: Mon, 27 Sep 1999 16:12:13 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 12 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Bob Hinden Subject: Updated IPng Tokyo Meeting Agenda > Wednesday / 29 September 1999 > ----------------------------- > > 10:00-12:00 Probably too late. But I believe that the starting time is 9:30 not 10:00. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 04:48:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8RBjKH28825 for ipng-dist; Mon, 27 Sep 1999 04:45:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8RBjBi28818 for ; Mon, 27 Sep 1999 04:45: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 EAA03995 for ; Mon, 27 Sep 1999 04:45:10 -0700 (PDT) Received: from web112.yahoomail.com (web112.yahoomail.com [205.180.60.82]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA02353 for ; Mon, 27 Sep 1999 05:45:09 -0600 (MDT) Message-ID: <19990927114320.11060.rocketmail@web112.yahoomail.com> Received: from [203.129.225.218] by web112.yahoomail.com; Mon, 27 Sep 1999 04:43:20 PDT Date: Mon, 27 Sep 1999 04:43:20 -0700 (PDT) From: Deepak Dandekar Subject: reallly sorry to disturb you all To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am really sorry to all of you if I am asking redundant or ridiculous question here. I am interested more in implementation issues related with IPv6, but it seems that I have joined wrong mailing list. I am more concerned in the migration of a typical device having IPv4 stack going towards Ipv6 and what all needs to be considered before taking any such decision. Please, suggest me something useful. Honestly speaking I could not understand a singly mail from the day I joined this mailing list till date. So I am a bit confused if I have joined appropriate mailing list or its happening because I might have missed lots of things earlier. Thanking you all in anticipation. regards, deepak. ===== ******************************************************** Excuses are the nails used to build the house of failure. ******************************************************** __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 27 05:04:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8RC1Dg28848 for ipng-dist; Mon, 27 Sep 1999 05:01:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8RC14i28841 for ; Mon, 27 Sep 1999 05:01:04 -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 FAA09365 for ; Mon, 27 Sep 1999 05:01:03 -0700 (PDT) Received: from thomson.uni2.net (thomson.uni2.net [195.82.195.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA05139 for ; Mon, 27 Sep 1999 06:01:01 -0600 (MDT) Received: from arhexch01.martin.dk (arhexch01.martin.dk [129.142.130.8]) by thomson.uni2.net (8.9.3/8.9.1) with SMTP id OAA16583 for ; Mon, 27 Sep 1999 14:01:01 +0200 Received: by arhexch01.martin.dk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BF08EF.B85EF4E0@arhexch01.martin.dk>; Mon, 27 Sep 1999 13:53:47 +0200 Message-ID: From: Ole Pedersen To: "'Deepak Dandekar'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: reallly sorry to disturb you all Date: Mon, 27 Sep 1999 13:53:46 +0200 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What kind of device? What OS? If you're an application writer, you do have to know all the details in these discussions. The important thing for you would be the interface to the protocol stack... Regards, Ole Pedersen Martin Professional A/S Email: ole.pedersen@martin.dk -----Original Message----- From: Deepak Dandekar [SMTP:dip_d@yahoo.com] Sent: 27. september 1999 13:43 To: ipng@sunroof.eng.sun.com Subject: reallly sorry to disturb you all Hi, I am really sorry to all of you if I am asking redundant or ridiculous question here. I am interested more in implementation issues related with IPv6, but it seems that I have joined wrong mailing list. I am more concerned in the migration of a typical device having IPv4 stack going towards Ipv6 and what all needs to be considered before taking any such decision. Please, suggest me something useful. Honestly speaking I could not understand a singly mail from the day I joined this mailing list till date. So I am a bit confused if I have joined appropriate mailing list or its happening because I might have missed lots of things earlier. Thanking you all in anticipation. regards, deepak. ===== ******************************************************** Excuses are the nails used to build the house of failure. ******************************************************** __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 27 08:28:30 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8RFC7V29006 for ipng-dist; Mon, 27 Sep 1999 08:12:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8RFC1i28999 for ; Mon, 27 Sep 1999 08:12:01 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id IAA00396 for ipng@sunroof.eng.sun.com; Mon, 27 Sep 1999 08:09:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8RCsBi28873 for ; Mon, 27 Sep 1999 05:54:11 -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 FAA06760 for ; Mon, 27 Sep 1999 05:54:11 -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 FAA25192 for ; Mon, 27 Sep 1999 05:54:07 -0700 (PDT) Received: by odin.digi-data.com id <15234>; Mon, 27 Sep 1999 08:50:28 -0400 Message-Id: <99Sep27.085028gmt-0400.15234@odin.digi-data.com> Date: Mon, 27 Sep 1999 08:56:35 -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: Deepak Dandekar CC: ipng@sunroof.eng.sun.com Subject: Re: reallly sorry to disturb you all References: <19990927114320.11060.rocketmail@web112.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Deepak, Perhaps you should consider the IPv6 Deployment mailing List or the IPv6 Users Mailing List. The subscription information follows. IPv6 Deployment: Mail to majordomo@ipv6.org and put the words "subscribe deployment" in the body of your mail. IPv6 Users : Mail to majordomo@ipv6.org and put the words "subscribe users" in the body of your mail. 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 Sep 27 20:13:01 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8S3ARv29931 for ipng-dist; Mon, 27 Sep 1999 20:10:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8S3AIi29924 for ; Mon, 27 Sep 1999 20:10:18 -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 UAA15909 for ; Mon, 27 Sep 1999 20:10:16 -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 UAA07483 for ; Mon, 27 Sep 1999 20:10:16 -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 FAA17179; Tue, 28 Sep 1999 05:10:05 +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 FAA11393; Tue, 28 Sep 1999 05:10:04 +0200 (MET DST) Message-Id: <199909280310.FAA11393@givry.inria.fr> From: Francis Dupont To: nisse@lysator.liu.se (Niels M ller) cc: itojun@iijlab.net, Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" In-reply-to: Your message of 25 Sep 1999 16:04:38 +0200. Date: Tue, 28 Sep 1999 05:09:59 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: If you only want protection against tcp-hijacking, I suspect that it is good enough to use something like anonymous diffie-hellman to create a key that is used to authenticate any packet that requests subsequent tcp packets to be sent to (or accepted from, if any filtering based on source address is done) a new address or location. => I believe you should simply use IPSec which provides the security services/levels you'd like to get. Mobility/bindings can add a major security problem then authentication and replay prevention are mandatory for some binding options. The reason is quite simple: Any attacker that can perform an active man in the middle attack in this handshake could do arbitrary evil things with the tcp session *without* hijacking it. => I think it is very/too easy to do arbitrary evil things with TCP sessions (then you'd like to protect them and to pay for security from the beginning). The important thing here: Assume we want things like tcp to survive renumbering (using mobile-ip, or gse-like addresses, whatever), and we think that the (in)security of ordinary tcp is good enough for the application. Then we can get comparable level of (in)security, and survivability, *without* introducing any key management infrastructure, preshared secrets or certificates. => IKE (IPSec SA & key management) gives many possibilities. Unfortunately it is a new protocol then we have not enough experience of it (perhaps it should be improved ?). Some of them would like to fully understand mobility (and now multihoming) implications for IKE... I also think it would be a good thing to clarify exactly what level of security is wanted for (in)secure traffic. This does seem like a strange thing to be talking about, but I suspect it is important. It's definitely one of the main points of the esd-analysis. Perhaps it is good to be a little more concrete, so lets take an example of an reasonable application using insecure tcp: => I agree, this should be a good thing... Say I'm using ssh to connect from a local machine (which might be mobile, or renumbered from time to time). I don't need any extra authentication for the _data_ in the tcp session (as sufficient authentication is provided by the application). Connections can live for a long time, and I'd like them to survive things like site renumbering, temporary ISP-failures of a multihomed site, i.e. all the scenarios that have been discussed here. => a problem with upper layer security services is they cannot protect TCP connections against RST attacks for instance. When network layer security services (aka IPSec for IP) are available they are better. (This comment does not apply for authenticated E-mail where the entities are human beings, not hosts or processes, but SSL/TLS or in most cases SSH should be replaced by IPSec IMHO). What level of security is it reasonable to expect from the network and transport layers? As far as I can tell, we'd like it to at least not be trivial for an attacker to cause the tcp session to die. => today this is trivial (just send a RST) for a man in the middle. Is that true for ipv4? => yes and it is true for IPv6 if you don't use IPSec (which is mandatory then should be available for IPv6). And is it correct that simple "anonymous" authentication as described above provides similar (or better) protection also in the presens of things like binding-update? => IPv6 mobility draft mandates some security services at the network layer (because binding-updates are at this layer). There is a (draft) standard which provides the service but it is only referenced (ie. the door is still open). 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 Wed Sep 29 10:25:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8THLiq01752 for ipng-dist; Wed, 29 Sep 1999 10:21:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8THLYi01745 for ; Wed, 29 Sep 1999 10:21:35 -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 KAA11202 for ; Wed, 29 Sep 1999 10:21:29 -0700 (PDT) Received: from samantha.lysator.liu.se (samantha.lysator.liu.se [130.236.254.202]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16939 for ; Wed, 29 Sep 1999 11:21:27 -0600 (MDT) Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206]) by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id TAA24862; Wed, 29 Sep 1999 19:20:25 +0200 (MET DST) Received: (from nisse@localhost) by sanna.lysator.liu.se (8.8.8/8.8.7) id TAA25628; Wed, 29 Sep 1999 19:20:45 +0200 (MET DST) To: Francis Dupont Cc: itojun@iijlab.net, Ben Black , ipng@sunroof.eng.sun.com Subject: Re: a response to "A Simple Solution for IPv6 Multihoming" References: <199909280310.FAA11393@givry.inria.fr> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 29 Sep 1999 19:20:45 +0200 In-Reply-To: Francis Dupont's message of "Tue, 28 Sep 1999 05:09:59 +0200" Message-ID: Lines: 53 X-Mailer: Gnus v5.4.59/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > In your previous mail you wrote: > > If you only want protection against tcp-hijacking, I suspect that it > is good enough to use something like anonymous diffie-hellman to > create a key that is used to authenticate any packet that requests > subsequent tcp packets to be sent to (or accepted from, if any > filtering based on source address is done) a new address or location. > > => I believe you should simply use IPSec which provides the security > services/levels you'd like to get. Mobility/bindings can add a major > security problem then authentication and replay prevention are > mandatory for some binding options. I didn't mention ipsec explicitly, because I haven't read all the relevant specs. If you can use ipsec in "anonymous" mode, that is great. Not because anonymous mode provides "real" security, but because it is trivial to manage, and because it is good enough to stop the kind of threats (hi-jacking, bogus rst or binding-update messages) that seem to be show-stoppers for all the session-stability proposals that I have seen here. If we happen to have a real, properly authenticated shared key with the other host, we should of course use that instead. But as usual, the cryptography and protocols are a lot easier than the management of keys and policies. > => a problem with upper layer security services is they cannot protect > TCP connections against RST attacks for instance. When network layer > security services (aka IPSec for IP) are available they are better. > (This comment does not apply for authenticated E-mail where the > entities are human beings, not hosts or processes, but SSL/TLS or > in most cases SSH should be replaced by IPSec IMHO). I think it makes sense to use a somewhat weak (MITM-vulnerable, shared keys shared by several parties, whatever) to get some protection against things like RST attacks, and use an application level secure protocol like ssh or tls on top of that. The primary reason is that with an application like ssh, a user can use his or her own security and trust model, without a lot of coordination with sysadms. In particular, the parties that the user is willing to trust may be somewhat different from the parties the sysadm trusts. > => IPv6 mobility draft mandates some security services at the > network layer (because binding-updates are at this layer). > There is a (draft) standard which provides the service but > it is only referenced (ie. the door is still open). I guess this is analogous to the authentication requirements for ipv6 source routing. /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 29 15:00:57 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8TLpUJ02099 for ipng-dist; Wed, 29 Sep 1999 14:51:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8TLpLi02092 for ; Wed, 29 Sep 1999 14:51:21 -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 OAA04988 for ; Wed, 29 Sep 1999 14:51:21 -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 PAA14182 for ; Wed, 29 Sep 1999 15:51:18 -0600 (MDT) Received: from new (h082.p102.iij4u.or.jp [210.130.102.82]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id OAA04827; Wed, 29 Sep 1999 14:50:33 -0700 (PDT) Message-Id: <4.2.0.58.19990929143851.03d7ac30@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 29 Sep 1999 14:49:32 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Changes to "Preferred Format for Literal IPv6 Addresses in URL's" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The current (-03) and soon to be published (-04) versions of "Preferred Format for Literal IPv6 Addresses in URL's" has two changes that the w.g. should be aware. These changes were requested during the IETF last call. The changes are: 1) There is a new section 3 that defines changes to RFC2396 "Uniform Resource Identifiers: Generic Syntax" for the IPv6 literal address format. The new text is as follows: --------------------------------------------------------------------- 3. Changes to RFC 2396 This document updates the generic syntax for Uniform Resource Identifiers defined in RFC 2396 [URL]. It defines a syntax for IPv6 addresses and allows the use of "[" and "]" within a URI explicitly for this reserved purpose. The following changes to the syntax in RFC 2396 are made: change the 'host' non-terminal to add an IPv6 option: host = hostname | IPv4address | IPv6reference ipv6reference = "[" IPv6address "]" where IPv6address is defined as in RFC2373. The definition of 'IPv4address' is also replaced with that of RFC 2373, as it correctly defines an IPv4address as consisting of at most three decimal digits per segment. In addition, add "[" and "]" to the set of 'reserved' characters: reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," | "[" | "]" and remove them from the 'unwise' set: unwise = "{" | "}" | "|" | "\" | "^" | "`" ---------------------------------------------------------------------- Larry Masinter suggested this text during the IETF last call period and is now listed as an author. 2) The title was changed to "Format for Literal IPv6 Addresses in URL's" in version -04. 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 Wed Sep 29 17:58:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8U0uJ302364 for ipng-dist; Wed, 29 Sep 1999 17:56:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8U0u9i02357 for ; Wed, 29 Sep 1999 17:56: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 RAA11081 for ; Wed, 29 Sep 1999 17:56: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 RAA03516 for ; Wed, 29 Sep 1999 17:56: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 JAA23391 for ; Thu, 30 Sep 1999 09:56:01 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: tokyo interim meeting realaudio/video 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 From: itojun@iijlab.net Date: Thu, 30 Sep 1999 09:56:00 +0900 Message-ID: <23389.938652960@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk the broadcast is up and running, so please try! itojun ------- Forwarded Message Return-Path: Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id NAA16052 for ; Fri, 24 Sep 1999 13:03:24 +0900 (JST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA26972; Thu, 23 Sep 1999 21:03:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA20460; Thu, 23 Sep 1999 21:03:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) id d8O3xb726312 for ipng-dist; Thu, 23 Sep 1999 20:59:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta1+Sun/8.10.0.Beta1) with ESMTP id d8O3xSX26305 for ; Thu, 23 Sep 1999 20:59:28 -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 UAA12878 for ; Thu, 23 Sep 1999 20:59:27 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06302 for ; Thu, 23 Sep 1999 20:59:26 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id MAA29601 for ; Fri, 24 Sep 1999 12:59:25 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA21743 for ; Fri, 24 Sep 1999 12:59:25 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA26756 for ; Fri, 24 Sep 1999 12:59:24 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: realvideo From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b1 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: <19990924125905B.kazu@iijlab.net> Date: Fri, 24 Sep 1999 12:59:05 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 12 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-Filter: mailagent [version 3.0 PL56] for itojun@itojun.org We decide to audio/videocast with the following formats: RealAudio v5 old format: audio only, some clients for Unix platforms RealVideo G2 new format: with video Also, we will probably provide archive services for both. If your firewall filters out RealAudio, please use this service. This is what we can do the best and we can't take further requests. Thank you for understanding. - --Kazu - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com - -------------------------------------------------------------------- ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 29 18:52:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8U1o5N02506 for ipng-dist; Wed, 29 Sep 1999 18:50:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8U1nvi02499 for ; Wed, 29 Sep 1999 18:49:57 -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 SAA16689 for ; Wed, 29 Sep 1999 18:49:56 -0700 (PDT) Received: from newman.itea.ntnu.no (newman.itea.ntnu.no [129.241.18.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA29668 for ; Wed, 29 Sep 1999 19:49:54 -0600 (MDT) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by newman.itea.ntnu.no (8.9.1/8.9.1) with ESMTP id CAA07926; Thu, 30 Sep 1999 02:49:53 +0100 (WET DST) From: Stig Venaas Received: (from venaas@localhost) by alfa.itea.ntnu.no (8.7.3/8.7.3) id DAA21025; Thu, 30 Sep 1999 03:50:20 +0200 (MET DST) Message-ID: <19990930035020.A21886@itea.ntnu.no> Date: Thu, 30 Sep 1999 03:50:20 +0200 To: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: tokyo interim meeting realaudio/video References: <23389.938652960@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <23389.938652960@coconut.itojun.org>; from itojun@iijlab.net on Thu, Sep 30, 1999 at 09:56:00AM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Sep 30, 1999 at 09:56:00AM +0900, itojun@iijlab.net wrote: > the broadcast is up and running, so please try! It works just great, thanks! There are two problems though, the first is that I had to use windows, the other is that I'm staying up all night in order to see it. It's nice to have an excuse for staying up all night though. BTW, you said something about prefix ordering or hinting in resolv.conf, I'm wondering if it might be a good idea to put information like this in router advertisements or DHCP options. Looks like the break is about to end, so I'll stop here. Stig -- Stig Venaas UNINETT/NTNU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 29 19:08:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8U25OR02532 for ipng-dist; Wed, 29 Sep 1999 19:05:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8U25Gi02525 for ; Wed, 29 Sep 1999 19:05:16 -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 TAA18165 for ; Wed, 29 Sep 1999 19:05:15 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA20743 for ; Wed, 29 Sep 1999 19:05:14 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA06499; Thu, 30 Sep 1999 11:05:07 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA26203; Thu, 30 Sep 1999 11:05:06 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA08104; Thu, 30 Sep 1999 11:05:06 +0900 (JST) To: venaas@itea.ntnu.no Cc: ipng@sunroof.eng.sun.com Subject: Re: tokyo interim meeting realaudio/video From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <19990930035020.A21886@itea.ntnu.no> References: <23389.938652960@coconut.itojun.org> <19990930035020.A21886@itea.ntnu.no> X-Mailer: Mew version 1.95b1 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: <19990930110457P.kazu@iijlab.net> Date: Thu, 30 Sep 1999 11:04:57 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 15 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Stig Venaas Subject: Re: tokyo interim meeting realaudio/video > There are two problems though, the first is that I had to use windows, > the other is that I'm staying up all night in order to see it. It's > nice to have an excuse for staying up all night though. Not really. You can use Unix stuff because we are providing realaudio with the old format as well as the new format. And you can use archive services. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 30 04:03:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8UB06302867 for ipng-dist; Thu, 30 Sep 1999 04:00:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8UAxui02860 for ; Thu, 30 Sep 1999 03:59:56 -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 DAA19286 for ; Thu, 30 Sep 1999 03:59:55 -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 DAA15895 for ; Thu, 30 Sep 1999 03:59:54 -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 GAA04423; Thu, 30 Sep 1999 06:59:52 -0400 (EDT) Message-Id: <199909301059.GAA04423@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-04.txt Date: Thu, 30 Sep 1999 06:59:42 -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, L. Masinter Filename : draft-ietf-ipngwg-url-literal-04.txt Pages : 4 Date : 29-Sep-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-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-url-literal-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-url-literal-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990929093011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-url-literal-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-url-literal-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990929093011.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 Sep 30 05:44:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8UCgIS02949 for ipng-dist; Thu, 30 Sep 1999 05:42:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8UCg9i02942 for ; Thu, 30 Sep 1999 05:42: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 FAA23435 for ; Thu, 30 Sep 1999 05:42:10 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA07113 for ; Thu, 30 Sep 1999 05:42:09 -0700 (PDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id IAA17057; Thu, 30 Sep 1999 08:41:56 -0400 (EDT) Message-Id: <199909301241.IAA17057@cannes.aa.ans.net> To: Peter Tattam cc: IPNG Mailing List Subject: Re: multihoming proposals summary again. In-reply-to: Your message of "Fri, 24 Sep 1999 02:02:27 +1000." Date: Thu, 30 Sep 1999 08:41:56 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ok, here is the summary of Simple Mulithoming solution. It was sent to Peter several days ago so it may be included in his summary already. --Jessica Summary of "Simple Multihoming Routing for IPv6" Main features: a. Providing redundancy and load sharing for the multi-homed sites b. Scaling the global IPv6 Internet routing table c. Simple and thus operationally manageable and viable, which is becoming a strong requirement of ISPs Other characteristics: - It's a routing approach using existing routing protocols and instrumentations. - No need for multi-address per host - No need for building tunnels - Economic and avoiding errors and outages likely introduced by complexed solutions - Applicable to most of the environment and it does not prevent certain sites use other solution for their special environment or requirements -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 30 09:35:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8UGWY703187 for ipng-dist; Thu, 30 Sep 1999 09:32:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8UGWUi03180 for ; Thu, 30 Sep 1999 09:32:30 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA04079 for ipng@sunroof.eng.sun.com; Thu, 30 Sep 1999 09:30:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8U9Z1i02805 for ; Thu, 30 Sep 1999 02:35:02 -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 CAA15792 for ; Thu, 30 Sep 1999 02:35:01 -0700 (PDT) Received: from dv.op.dlr.de (dv.op.dlr.de [129.247.188.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA20168 for ; Thu, 30 Sep 1999 03:34:48 -0600 (MDT) Received: from dlr.de ([129.247.173.188]) by dv.op.dlr.de (8.9.3/8.9.3) with ESMTP id LAA95924 for ; Thu, 30 Sep 1999 11:34:30 +0200 Message-ID: <37F32E10.B3DC01D@dlr.de> Date: Thu, 30 Sep 1999 11:32:00 +0200 From: Carlo Matarasso Organization: DLR X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: TCP/IP codes in C or C++ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi everybody, can anyone give me some addresses where I can download (paying if necessary) the source codes of the newest implementations in C or C++ of TCP and IP protocols. I' m looking for IPv6 or 4 and for the most satellite friendly version of TCP. I need also codes for the mobile IP protocol. If you reply to this mail, please do not forget to put my address among the recipients, because I' m not a member of this WG. Thank you in advance Carlo -- ------------------------------------------------------------------------------------------- DOTT. ING. CARLO MATARASSO carlo.matarasso@dlr.de TEL. +49 8153 28 2848 FAX +49 8153 28 2844 DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT GERMAN AEROSPACE CENTER www.dlr.de POSTFACH 1116 D - 82230 WESSLING - GERMANY ------------------------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 30 09:37:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) id d8UGaV403205 for ipng-dist; Thu, 30 Sep 1999 09:36:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta2+Sun/8.10.0.Beta2) with ESMTP id d8UGaKi03198 for ; Thu, 30 Sep 1999 09:36:20 -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 JAA21375 for ; Thu, 30 Sep 1999 09:36:19 -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 KAA29699 for ; Thu, 30 Sep 1999 10:35:51 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1041:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA11302; Fri, 1 Oct 1999 01:27:09 +0900 (JST) Date: Fri, 01 Oct 1999 01:39:14 +0900 Message-ID: <14323.37426.794051.3063M@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Cc: v6@wide.ad.jp Subject: patch to fix a bug User-Agent: Wanderlust/2.2.2 (You Could Be Mine) 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: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To those who participate in the ipng interim meeting and use the KAME stack; As you saw, we encountered sudden crash of KAME boxes yesterday. It was due to a bug in the KAME IPv6 stack and would be fixed with the following patch. If you want to make your PC more stable, please apply the patch. Sorry for your trouble. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp Index: ip6.h =================================================================== RCS file: /cvsroot/kame/kame/kame/sys/netinet6/ip6.h,v retrieving revision 1.3 diff -c -r1.3 ip6.h *** ip6.h 1999/08/16 20:33:13 1.3 --- ip6.h 1999/09/30 07:54:19 *************** *** 233,238 **** --- 233,245 ---- } \ } \ } \ + else { \ + if ((m)->m_len < (off) + (hlen)) { \ + ip6stat.ip6s_toosmall++; \ + m_freem(m); \ + return ret; \ + } \ + } \ } while (0) #endif /* not _NETINET_IPV6_H_ */ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------