From mdp@tbit.dk Mon Jul 1 20:33:44 1996 From: mdp@tbit.dk (Martin Peck) Date: Mon, 01 Jul 1996 12:33:44 -0700 Subject: New IPv6 Release References: Message-ID: <31D82818.45B2@tbit.dk> This is a multi-part message in MIME format. --------------7E19389D242E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, Thanks for including us in your IPng page. Telebit Communications A/S now has a major new IPv6 router release which is detailed in the attachment (htm format, viewable from Netscape Mail). Thanks in advance for updating our contribution, Best Regards, Martin Peck --------------7E19389D242E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="HINDEN2.HTM" Bob,

Telebit Communications A/S has released a major new IPv6 router implementation which has been demonstrated at the Joint European Networking Conference in Budapest.

This includes IDRPv6 for the exchange of routing information between autonomous domains, IGP to dynamically exchange routing information within domains, SNMP support for IPv6, facilities to define static IPv6 routing information, neighbor discovery, automatic and manually configured tunneling, accounting facilities and packet filtering for both IPv4 and IPv6, a full ICMPv6 implementation, IPv6 multicast generation and termination, and IPv6 ping and traceroutes. We plan to make OSPFv6, RIPv6, neighbor discovery over ATM, and RSVP (for IPv4 and IPv6) available by the end of '96, and support of IPv6 multicasting in '97.

TELEBIT COMMUNICATIONS A/S

Tel: +45 86 28 81 76

fx: +45 86 28 81 86

em: info@tbit.dk

http://www.tbit.dk/

--------------7E19389D242E-- From unigrd@unidhp1.uni-c.dk Fri Jul 5 11:10:46 1996 From: unigrd@unidhp1.uni-c.dk (Gudrun R. Dalgeir) Date: Fri, 5 Jul 1996 12:10:46 +0200 (METDST) Subject: Tunnel request to WIDE and G6 Message-ID: To WIDE, G6, Geert Jan de Groot This is the list of the DENET nodes which are ready to participate in 6bone. DENET 6bone nodes ----------------- SUN station, femur.join.uni-c.dk, ::130.225.231.4 femur6.join.uni-c.dk, 5f07:2b00:82e1:e700:4:800:2020:dab4 SUN station, scapula.uni-c.dk, ::130.225.231.2 scapula6.join.uni-c.dk, 5f07:2b00:82e1:e700:2:800:2020:ab36 TBC router, unvea.denet.dk, ::130.225.231.5 unvea6.join.uni-c.dk, 5f07:2b00:82e1:e700:5:cccc:cccc:cccc TBC router, unlya.denet.dk, ::130.225.249.12 unlya6.join.uni-c.dk, 5f07:2b00:82e1:f900:2a:aaaa:aaaa:aaaa TBC router, unara.denet.dk, ::130.225.246.130 unara6.join.uni-c.dk 5f07:2b00:82e1:f600:82:bbbb:bbbb:bbbb The ipv6 addresses have been defined according to the format described in RFC1897. The DENET AS number is 1835. unvea.denet.dk will act as the tunnel node. The ipv6 DNS is running on femur.join.uni-c.dk. regards, ---------------- oo000oo ---------------------------------- Gudrun Dalgeir phone : (+) 45 35878532 UNI-C fax : (+) 45 35878890 Vermundsgade 5 e-mail : Gudrun.Dalgeir@uni-c.dk DK-2100 Kbh. O ----------------------------------------------------------- From Alain.Durand@imag.fr Fri Jul 5 12:37:53 1996 From: Alain.Durand@imag.fr (Alain.Durand@imag.fr) Date: Fri, 5 Jul 1996 13:37:53 +0200 Subject: Tunnel request to WIDE and G6 In-Reply-To: "Gudrun R. Dalgeir" "Tunnel request to WIDE and G6" (Jul 5, 12:10pm) References: Message-ID: <9607051337.ZM22212@brahma.imag.fr> On Jul 5, 12:10pm, Gudrun R. Dalgeir wrote: > Subject: Tunnel request to WIDE and G6 > To WIDE, G6, Geert Jan de Groot > > This is the list of the DENET nodes which are ready to participate > in 6bone. [...] > TBC router, unvea.denet.dk, ::130.225.231.5 > unvea6.join.uni-c.dk, 5f07:2b00:82e1:e700:5:cccc:cccc:cccc > [...] > The ipv6 addresses have been defined according to the format described > in RFC1897. The DENET AS number is 1835. > > unvea.denet.dk will act as the tunnel node. Gudrun, which prefix do you want us to route to your tunnel node? 5f07:2b00::/32 or 5f07:2b00:82e1:e700::/64 For G6, the entry point will be ::129.88.26.1 The prefix to route will be 5f06:b500::/32 The machine 129.88.26.1 is already up and running, but as it's my main ipv6 host, it will be replaced sometime next week by a dedicated host running inria's code with the same IPv4 address. They're several hosts you can ping or telnet to, I'll send a complete list later. Yours, From minami@sfc.wide.ad.jp Sat Jul 6 05:50:08 1996 From: minami@sfc.wide.ad.jp (=?ISO-2022-JP?B?GyRCJF8kSiRfJF4kNSQtGyhC?= (Masaki Minami)) Date: Sat, 06 Jul 1996 13:50:08 +0900 Subject: Tunnel request to WIDE and G6 In-Reply-To: Your message of "Fri, 5 Jul 1996 12:10:46 +0200 (METDST)" References: Message-ID: <199607060450.EAA12435@trf.sfc.wide.ad.jp> Hi, everyone. This is Masaki Minami, WIDE Project, Japan. We are going to take place "IPv6 Meeting on WIDE Project" at July 10(JST), now we are preparing to CONNECT to the "World Wide 6Bone". So, I will inform you that the LIST of all addresses on WIDE 6Bone. Regards, -------- // masaki // From minami@sfc.wide.ad.jp Sat Jul 13 13:36:38 1996 From: minami@sfc.wide.ad.jp (=?ISO-2022-JP?B?GyRCJF8kSiRfJF4kNSQtGyhC?= (Masaki Minami)) Date: Sat, 13 Jul 1996 21:36:38 +0900 Subject: Tunnel request to WIDE and G6 In-Reply-To: Your message of "Sat, 06 Jul 1996 13:50:08 +0900" References: <199607060450.EAA12435@trf.sfc.wide.ad.jp> Message-ID: <199607131236.MAA13074@trf.sfc.wide.ad.jp> Hi, everyone. The below is "6Bone Nodes Topology and Node Table" on WIDE Project, Japan. Now, we are ready to participate in Wolrd Wide 6Bone. ----------------------------------------------------------------- ********************************************************* ** 6Bone nodes ** ** WIDE Project, Japan ** ********************************************************* Current Topology Osaka-U +-----------------------------------+ |strawberry-jam.center.osaka-u.ac.jp| | 5f09:c200:8504:c00::2 | +-------------- | ------------------+ S NAIST S +---------- | -----------+ | 5f09:c200:8504:c00::1 | U-Tokyo | zeta.wide.ad.jp | +---------------------+ | 5f09:c200:8504:1500::2 | | pc1.nezu.wide.ad.jp | +---------- | -----------+ 5f09:c200:8504:600::2 | S /--------------------+ Tokyo S S +------------ | -------------+ S | 5f09:c200:8504:1500::1 | / | pc1.tokyo.wide.ad.jp 5f09:c200:8504:600::1 | 5f09:c200:8504:0200::2 | +------------ |--------------+ S SFC S +--------- |-------------+ | 5f09:c200:8504:0200::1 | | globe.sfc.wide.ad.jp | +------------------- 5f09:c200:8504:d00::1 \ S Hitachi S +-- \ --------------------+ | 5f09:c200:8504:d00::2 | |eagle.isrd.hitachi.co.jp | +-------------------------+ ******************************************************************* * Serial Line * 5f09:c200:XXXX:XX00::{1,2} * XXXX:XX00 24bit from IPv4 Address * Prefixlen 80 ******************************************************************* Tokyo - NAIST (133.4.21.33 - 133.4.21.34/27) Tokyo: 5f09:c200:8504:1500::1 NAIST: 5f09:c200:8504:1500::2 NAIST - Osaka (133.4.12.33 - 133.4.12.34/27) NAIST: 5f09:c200:8504:0c00::1 Osaka: 5f09:c200:8504:0c00::2 SFC - Tokyo(133.4.2.33 - 133.4.2.34/27) SFC: 5f09:c200:8504:0200::1 Tokyo: 5f09:c200:8504:0200::2 Tokyo - U-Tokyo (133.4.6.33 - 133.4.6.34/27) Tokyo: 5f09:c200:8504:0600::1 U-Tokyo: 5f09:c200:8504:0600::2 SFC - Hitachi (133.4.13.1 - 133.4.13.2/27) SFC: 5f09:c200:8504:0d00::1 Hitachi: 5f09:c200:8504:0d00::2 ******************************************************************* * Ethernet * 5f09:c200:XXXX:XX00:******* * XXXX:XX00: 24bits from IPv4 Address * *******: MAC Address * Example: * MAC Address of globe.sfc.wide.ad.jp is "00a0:2448:7a3c" * And IPv4 Address * So, IPv6 Address of globe.sfc.wide.ad.jp is * 5f09:c200:851b::00a0:2448:7a3c ******************************************************************* globe.sfc.wide.ad.jp 5f09:c200:851b::00a0:2448:7a3c eagle.isrd.hitachi.co.jp 5f09:c200:8590::00a0:243a:6f7c ------------------------------------------------------------- I wounder that we should decide the IPv6 Addresses that are both of our and your tunnel I/F. Regards, // masaki // From minami@sfc.wide.ad.jp Sat Jul 13 13:58:37 1996 From: minami@sfc.wide.ad.jp (=?ISO-2022-JP?B?GyRCJF8kSiRfJF4kNSQtGyhC?= (Masaki Minami)) Date: Sat, 13 Jul 1996 21:58:37 +0900 Subject: Tunnel request to WIDE and G6 In-Reply-To: Your message of "Sat, 13 Jul 1996 21:36:38 +0900" References: <199607131236.MAA13074@trf.sfc.wide.ad.jp> Message-ID: <199607131258.MAA13182@trf.sfc.wide.ad.jp> Everybody, Sorry, I had big mistake...... :p Please ignore the last message from me. This is correct "Topology and Nodes Table". Thanks, // masaki // ----------------------------------------------------------- ********************************************************* ** 6Bone nodes ** ** WIDE Project, Japan ** ********************************************************* Current Topology Osaka-U +-----------------------------------+ |strawberry-jam.center.osaka-u.ac.jp| | 5f09:c400:8504:c00::2 | +-------------- | ------------------+ S NAIST S +---------- | -----------+ | 5f09:c400:8504:c00::1 | U-Tokyo | zeta.wide.ad.jp | +---------------------+ | 5f09:c400:8504:1500::2 | | pc1.nezu.wide.ad.jp | +---------- | -----------+ 5f09:c400:8504:600::2 | S /--------------------+ Tokyo S S +------------ | -------------+ S | 5f09:c400:8504:1500::1 | / | pc1.tokyo.wide.ad.jp 5f09:c400:8504:600::1 | 5f09:c400:8504:0200::2 | +------------ |--------------+ S SFC S +--------- |-------------+ | 5f09:c400:8504:0200::1 | | globe.sfc.wide.ad.jp | +------------------- 5f09:c400:8504:d00::1 \ S Hitachi S +-- \ --------------------+ | 5f09:c400:8504:d00::2 | |eagle.isrd.hitachi.co.jp | +-------------------------+ ******************************************************************* * Serial Line * 5f09:c400:XXXX:XX00::{1,2} * XXXX:XX00 24bit from IPv4 Address * Prefixlen 80 ******************************************************************* Tokyo - NAIST (133.4.21.33 - 133.4.21.34/27) Tokyo: 5f09:c400:8504:1500::1 NAIST: 5f09:c400:8504:1500::2 NAIST - Osaka (133.4.12.33 - 133.4.12.34/27) NAIST: 5f09:c400:8504:0c00::1 Osaka: 5f09:c400:8504:0c00::2 SFC - Tokyo(133.4.2.33 - 133.4.2.34/27) SFC: 5f09:c400:8504:0200::1 Tokyo: 5f09:c400:8504:0200::2 Tokyo - U-Tokyo (133.4.6.33 - 133.4.6.34/27) Tokyo: 5f09:c400:8504:0600::1 U-Tokyo: 5f09:c400:8504:0600::2 SFC - Hitachi (133.4.13.1 - 133.4.13.2/27) SFC: 5f09:c400:8504:0d00::1 Hitachi: 5f09:c400:8504:0d00::2 ******************************************************************* * Ethernet * 5f09:c400:XXXX:XX00:******* * XXXX:XX00: 24bits from IPv4 Address * *******: MAC Address * Example: * MAC Address of globe.sfc.wide.ad.jp is "00a0:2448:7a3c" * And IPv4 Address * So, IPv6 Address of globe.sfc.wide.ad.jp is * 5f09:c400:851b::00a0:2448:7a3c ******************************************************************* globe.sfc.wide.ad.jp 5f09:c400:851b::00a0:2448:7a3c eagle.isrd.hitachi.co.jp 5f09:c400:8590::00a0:243a:6f7c From kazu@is.aist-nara.ac.jp Mon Jul 15 17:43:23 1996 From: kazu@is.aist-nara.ac.jp (Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) Date: Tue, 16 Jul 1996 01:43:23 +0900 Subject: 6/15 Message-ID: <886.837449003@mine.aist-nara.ac.jp> Hi 6bone guys, We've waited for the entire arrangement on this list, though, nothing is mentioned. So, let me say something. Today, Alian, a G6 guy, contacted us to set up a v6-over-v4 tunnel between France and Japan. Since he has left for Pari, I couldn't confirm. But I guess he tried to use an *automatic tunneling*. That is, the destination and source IPv6 address of the payload must be IPv4-compatible-IPv6 address. We believe that we must not use IPv4-compatible-IPv6 addresses on the 6bone. Rather, all IPv6 address must be test address. Anyway, WIDE is now ready. Our tunnel end point is "june.aist-nara.ac.jp"(163.221.11.21). All nodes on the WIDE IPv6 network has a prefix 5f09:c400::/32. If you would like to set up a v6-over-v4 tunnel to the WIDE IPv6 network, please post to this ML. We believe that an appropriate tunnel addressing is as follows: 5f09:c400:a3dd:400::1 5f09:c400:a3dd:400::2 june <------- v6 over v4 tunnel---------> yours | | -+- -+- 163.221.11.21 any IPv4 addr P.S. You can get the entire topology of the WIDE IPv6 network from: "http://www.wide.ad.jp/wg/ipv6/" --Kazu From deering@parc.xerox.com Mon Jul 15 18:37:42 1996 From: deering@parc.xerox.com (Steve Deering) Date: Mon, 15 Jul 1996 10:37:42 PDT Subject: 6/15 In-Reply-To: kazu's message of Mon, 15 Jul 96 09:43:23 -0800. <886.837449003@mine.aist-nara.ac.jp> Message-ID: <96Jul15.103743pdt."75270"@digit.parc.xerox.com> Kazu, > We believe that we must not use IPv4-compatible-IPv6 addresses on the > 6bone. Rather, all IPv6 address must be test address. That's correct, with one tiny exception: an IPv6 host with no neighboring IPv6 router may use an IPv4-compatible IPv6 address for itself; as soon as a neighboring IPv6 router is installed, the host must switch to using IPv6 "native" addresses (e.g., the test addresses). Automatic tunelling is not to be used between routers, only between a router and an isolated host. Steve From minami@sfc.wide.ad.jp Thu Jul 18 10:58:04 1996 From: minami@sfc.wide.ad.jp (=?ISO-2022-JP?B?GyRCJF8kSiRfJF4kNSQtGyhC?= (Masaki Minami)) Date: Thu, 18 Jul 1996 18:58:04 +0900 Subject: 6Bone Status Message-ID: <199607180958.JAA17606@trf.sfc.wide.ad.jp> Folks, Tunnel Link between WIDE and G6 is now UP at " Thu Jul 18 16:11:29 JST 1996". And we are ready to set the Tunnel Link between WIDE and UNI-C up. By the way, we, WIDE Project are going to take place the IPv6 demonstration on Interop, Tokyo. It is between July, 24 and July 26. You know, some company which is developing IPv6 protocol suite will join it. We will introduce the "World Wide 6Bone" and show the "ping" and "telnet" DEMO that are toward "World Wide 6Bone". Regards, Masaki Minami, WIDE Project, Japan From Alain.Durand@imag.fr Wed Jul 17 23:12:48 1996 From: Alain.Durand@imag.fr (Alain Durand) Date: Thu, 18 Jul 1996 00:12:48 +0200 Subject: 6Bone Status In-Reply-To: ( Text in unknown character set iso-2022-jp not shown ) (Masaki Minami) "6Bone Status" (Jul 18, 6:58pm) References: <199607180958.JAA17606@trf.sfc.wide.ad.jp> Message-ID: <960718001248.ZM8502@rama.imag.fr> Folks, I would like to inform you that the tunnel between G6 and UNI-C is UP since last friday. The tunnel with WIDE is also UP. Inside G6, hosts in the ipv6.imag.fr and ipv6.inria.fr are reachable, the other G6 domains will be connected soon. The 6-bone is starting! - Alain. ^_^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ U (* *) Alain DURAND | Preserve keyboards: | ( v ) I.M.A.G. | use completion. | /~~~\ Direction des Moyens Informatiques |----------------------------- <|=< BSD >= BP 53 38041 Grenoble Cedex 9 | E-Mail: Alain.Durand@imag.fr | \ / France | Phone: +33 76 63 57 03 | <~~< Postmaster@imag.fr | Fax: +33 76 51 49 64 ~ ~ From RLFink@lbl.gov Thu Jul 18 15:56:34 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 18 Jul 1996 07:56:34 -0700 Subject: No subject Message-ID: Congratulations to the WIDE/Japan, G6/France and UNI-C/Denmark groups for putting together the first "official" 6bone connections! We are on our way! Bob From deering@parc.xerox.com Thu Jul 18 16:01:14 1996 From: deering@parc.xerox.com (Steve Deering) Date: Thu, 18 Jul 1996 08:01:14 PDT Subject: 6Bone Status In-Reply-To: Alain.Durand's message of Wed, 17 Jul 96 15:12:48 -0800. <960718001248.ZM8502@rama.imag.fr> Message-ID: <96Jul18.080115pdt."75270"@digit.parc.xerox.com> > The 6-bone is starting! Congratulations, WIDE, G6, and UNI-C! Is anyone maintaining a map of 6bone? Good luck with the Interop Tokyo demos. Steve From RLFink@lbl.gov Thu Jul 18 23:38:03 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 18 Jul 1996 15:38:03 -0700 Subject: 6Bone Status In-Reply-To: <96Jul18.080115pdt."75270"@digit.parc.xerox.com> References: Alain.Durand's message of Wed, 17 Jul 96 15:12:48 -0800. <960718001248.ZM8502@rama.imag.fr> Message-ID: Steve, >> The 6-bone is starting! > >Congratulations, WIDE, G6, and UNI-C! > >Is anyone maintaining a map of 6bone? I had asked Geert Jan de Groot if he could include long/lat in the routing registry so we could possibly do this automatically in the future. Meanwhile, I hope to provide at least a rudimentary map for the 6bone web pages when I'm back from vacation next week (we'll see how that flies in the face of not having been in the office since before the Montreal IETF :-). Outside of simple network names, what should be shown on the map? All ideas appreciated. Would like to hear from Geert on this as he might have his own ideas on what to do. At any rate, something should be done soon (and referenced thru the 6bone web site at a minimum). Bob From minami@sfc.wide.ad.jp Fri Jul 19 04:43:10 1996 From: minami@sfc.wide.ad.jp (=?ISO-2022-JP?B?GyRCJF8kSiRfJF4kNSQtGyhC?= (Masaki Minami)) Date: Fri, 19 Jul 1996 12:43:10 +0900 Subject: 6Bone Status In-Reply-To: Your message of "Thu, 18 Jul 1996 08:01:14 PDT" References: <96Jul18.080115pdt."75270"@digit.parc.xerox.com> Message-ID: <199607190343.DAA23474@trf.sfc.wide.ad.jp> >> The 6-bone is starting! Steve> Congratulations, WIDE, G6, and UNI-C! Steve> Is anyone maintaining a map of 6bone? You can get the map which shows "WIDE 6Bone" topology from our WEB page. http://www.wide.ad.jp/wg/ipv6/index.html Steve> Good luck with the Interop Tokyo demos. Thanks, Steve. Masaki Minami, WIDE Project, Japan From dhaskin@baynetworks.com Fri Jul 19 16:17:36 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Fri, 19 Jul 96 11:17:36 EDT Subject: where to get an IPv6 prefix Message-ID: <9607191517.AA02684@pobox.BayNetworks.com> Hi, Would some one please to remind me what is the established procedure for getting a routable IPv6 prefix? We (Bay) would like to get connected to 6bone (as a stab site at this point). Dimitry From hinden@ipsilon.com Fri Jul 19 16:46:57 1996 From: hinden@ipsilon.com (Bob Hinden) Date: Fri, 19 Jul 1996 08:46:57 -0700 Subject: where to get an IPv6 prefix In-Reply-To: <9607191517.AA02684@pobox.BayNetworks.com> Message-ID: Dimitry, >Would some one please to remind me what is the established procedure for >getting >a routable IPv6 prefix? We (Bay) would like to get connected to 6bone >(as a stab site at this point). Use the algorithm in RFC1897 "IPv6 Testing Address Allocation". Bob From qv@cs.unh.edu Fri Jul 19 22:40:35 1996 From: qv@cs.unh.edu (Quaizar Vohra) Date: Fri, 19 Jul 1996 17:40:35 -0400 (EDT) Subject: tunnel request Message-ID: <199607192140.RAA17574@agate.cs.unh.edu> Hi G6, WIDE and UNI-C, This is a tunnel request from (UNH, BAY, DEC). Our prefix is 5f02:3000::/32 Our tunnel endpoint is ::132.177.118.22 The machines you can currently ping are : 5f02:3000:84b1:7600::800:912:241a and 5f02:3000:84b1:7600::800:5add:2217 I will post the entire topology later. Is it OK if I request tunnels to more than one prefix, the reason being that the general 5f02:3000::/32 covers all subnets under our autonomous system number, over which I don't have much control. I can ping UNI-C and G6 tunnel endpoint v4-compatible address but I can't ping WIDE's tunnel endpoint at ::163.221.11.21 . Can G6 supply me with some global IPv6 addresses to ping to. Quaizar ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-0090 From masaki@merit.edu Sat Jul 20 00:28:25 1996 From: masaki@merit.edu (Masaki Hirabaru) Date: Fri, 19 Jul 1996 19:28:25 -0400 Subject: How to configure a tunnel Message-ID: <199607192328.TAA27219@home.merit.edu> 6bone folks, Hi. I'd like to know how to configure a tunnel to 6bone or which implementation freely available supports configured tunneling. I tried to use solaris ipv6 first, but it seems to support only automatic tunneling. I next tried to check freebsd INRIA version, which supports automatic tunneling, but I'm not sure if it supports configured tunneling. By the way, I sent the following message before, but it seems not to reach at the 6bone mailing-list. I don't know the reason. Anyway, we're going to join 6bone when we are ready. Masaki To: 6bone@isi.edu cc: GeertJan.deGroot@ripe.net Cc: labovit@merit.edu Subject: Join 6bone Date: Wed, 03 Jul 1996 14:14:52 -0400 From: Masaki Hirabaru 6bone folks, I heard from Jun about 6bone after IETF meeting in Montreal was over. Craig Labovitz and I at Merit are much interested in joining 6bone in order to run MRT (Multi-threaded Routing Toolkit), which supports RIPng now, under real & wider v6 environment. I'd like to know who I should ask to connect our v6 island to the 6bone. Thanks. Masaki Hirabaru a member of WIDE Project but currently with Merit From Bernard.Tuy@urec.fr Sat Jul 20 10:22:20 1996 From: Bernard.Tuy@urec.fr (Bernard.Tuy@urec.fr) Date: Sat, 20 Jul 1996 11:22:20 +0200 Subject: How to configure a tunnel Message-ID: <199607200922.LAA13457@phoebe.urec.fr> | Date: Fri, 19 Jul 1996 19:28:25 -0400 | From: Masaki Hirabaru | | Hi. I'd like to know how to configure a tunnel to 6bone or which | implementation freely available supports configured tunneling. | | I tried to use solaris ipv6 first, but it seems to support only | automatic tunneling. I next tried to check freebsd INRIA version, | which supports automatic tunneling, but I'm not sure if it | supports configured tunneling. ====BT: Yes it does! since we -G6/France- and some others right now are running it for that purpose. | (...) Anyway, we're going to join 6bone when we are ready. ====BT: Welcome to the -still- small 6bone operations' group | (...) Craig Labovitz and I at Merit are much interested in | joining 6bone in order to run MRT (Multi-threaded Routing | Toolkit), which supports RIPng now, under real & wider v6 | environment. ====BT: Fine. Is your code freely available to play with ? | I'd like to know who I should ask to connect our v6 | island to the 6bone. Thanks. ====BT: to connect to G6/France, please ask Alain.Durand@imag.fr to connect to WIDE/Japan, ask minami@sfc.wide.ad.jp to connect to Uni-C/Denmark, ask unigrd@unidhp1.uni-c.dk In fact, the 6bone@ISI.EDU mailing list is the right place to reach everybody you need to connect to, since it'll become painful to enumerate email addresses for all ipv6 clouds connected all around the world... Cheers, +Bernard Tuy. G6/France From Bernard.Tuy@urec.fr Sat Jul 20 10:31:39 1996 From: Bernard.Tuy@urec.fr (Bernard.Tuy@urec.fr) Date: Sat, 20 Jul 1996 11:31:39 +0200 Subject: tunnel request Message-ID: <199607200931.LAA13465@phoebe.urec.fr> | From: qv@cs.unh.edu (Quaizar Vohra) | Date: Fri, 19 Jul 1996 17:40:35 -0400 (EDT) | | This is a tunnel request from (UNH, BAY, DEC). | Our prefix is 5f02:3000::/32 | Our tunnel endpoint is ::132.177.118.22 | I will post the entire topology later. | ====BT: Ok. It'd be nice to have a HTML page describing your IPv6 activities in general, and your IPv6 topology in particular. | | I can ping UNI-C and G6 tunnel endpoint v4-compatible address but I can't ping | WIDE's tunnel endpoint at ::163.221.11.21 . ====BT: I've right now the same problem... | | Can G6 supply me with some global IPv6 addresses to ping to. ====BT: for sure. Please refer to http://www.urec.fr/IPv6/G6-english.html (item "more detailed pictures") +Bernard Tuy. G6/France From RLFink@lbl.gov Sat Jul 20 15:44:33 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Sat, 20 Jul 1996 07:44:33 -0700 Subject: more tunnels and what to do next Message-ID: Two new groups have now asked for a tunnel to the 6bone via the 6bone list (Merit and the UNH/Bay/DEC consortium), and one to me privately (Dqavid Meyer, Univ. of Oregon). As I remember our plan from Montreal, we decided to use the G6/Wide/UNI-C folk as the trial 6bone setup to test out Geert Jan's routing registry, various 6bone operational issues, and whatever else came up in preparation to moving beyond these first three networks. I still think this is a good idea. So, I would propose that we wait to hear from Geert Jan (he was about to send something to the list on the registry early next week), as well as having some open discussion on this list (hopefully also during the next week) about how we should handle requests, how to decide where and how tunnels get built, etc.. Also, we are trying to learn from the MBONE experience so I want to hear from Steve Deering as well as to how he thinks what has gone on so far fits with what his experience with the mBONE has been. I'm concerned that if we don't move fairly carefully as tunnel requests come in we could end up with a messy mesh on our hands :-) Again, thanks to the G6/Wide/UNI-C folk for being the testers of all this. The 6bone is really poised to help the Internet's conversion to v6 (albeit over a long period of time). Thanks, Bob From niv6@is.aist-nara.ac.jp Sat Jul 20 16:47:21 1996 From: niv6@is.aist-nara.ac.jp (Jun-ichiro Itoh) Date: Sun, 21 Jul 1996 00:47:21 +0900 Subject: could you please set-up V6 httpd NetWorld+Interop96 tokyo demo? Message-ID: <515.837877641@itojun.csl.sony.co.jp> Hello, this is Jun-ichiro Itoh of Sony CSL/Keio Univ. We are trying to demonstrate 6bone and IPv6 at NetWorld+Interop96 which will be held next week, at tokyo. For demonstration, we would like to let the visitors play with IPv6-ready Mosaic, for demonstrating 6bone availability at this moment. So, apparently we need some IPv6-ready httpd servers on the 6bone. If you are already connected to Japanese 6bone (which is operated by WIDE project), and you are so kind to donate some CPU power for IPv6-ready httpd, could you please contact us? (niv6@is.aist-nara.ac.jp) 1. If you already have IPv6-ready httpd, please let me know IPv6 address/doain name for your http server. 2. If you do not have IPv6-ready httpd, don't worry! If you have inet6d, you can use very trivial httpd we have implemented. It should be able to run on any UNIX-based boxes. Contact us for the source code. Installation phase is also very trivial! Thanks for your future cooperation! itojun@csl.sony.co.jp Jun-ichiro Itoh From bound@zk3.dec.com Mon Jul 22 01:00:35 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Sun, 21 Jul 96 20:00:35 -0400 Subject: more tunnels and what to do next In-Reply-To: Your message of "Sat, 20 Jul 96 07:44:33 PDT." Message-ID: <9607220000.AA00038@fwasted.zk3.dec.com> Bob, I agree. But we cannot hold up the proliferation of the 6-bone I don't think for long if there is a single point of failure. Using RFC 1897 we can build the addresses but it better for now if Geert is in the loop. So if someone wants to send sipper.pa-x.dec.com an IPv6 packet they must go through Europe as opposed to the UNH-BAY-DEC point? If so that is not a good idea??? thanks /jim From masaki@merit.edu Mon Jul 22 18:16:39 1996 From: masaki@merit.edu (Masaki Hirabaru) Date: Mon, 22 Jul 1996 13:16:39 -0400 Subject: How to configure a tunnel In-Reply-To: Your message of "Fri, 19 Jul 1996 19:28:25 EDT." <199607192328.TAA27219@home.merit.edu> Message-ID: <199607221716.NAA24245@home.merit.edu> Hi. 6bone folks, My question was: > Hi. I'd like to know how to configure a tunnel to 6bone or which > implementation freely available supports configured tunneling. The answers are: INRIA, NRL, and Linux versions support configured tunneling. Solaris version seems not to support it now. So, I'm going to figure out how to configure it under INRIA version we've currently installed. I'm asking Francis Dupont. >> | (...) Craig Labovitz and I at Merit are much interested in >> | joining 6bone in order to run MRT (Multi-threaded Routing >> | Toolkit), which supports RIPng now, under real & wider v6 >> | environment. >> >> ====BT: Fine. Is your code freely available to play with ? If you are interested, please see http://compute.merit.edu/mrt/. Yes, it's freely available. The current released version has implemented the basic part of ripng, and the next release will have a lot of improvements. Thank you for responding my query. The following is its summary. Masaki Hirabaru Merit --- Date: Sat, 20 Jul 1996 01:56:47 +0100 From: Pedro Roque Marques I know that both NRL and Linux support configured tunneling. On Linux you have to bring the tunneling device up and then just do route add prefix gw ::ddd.ddd.ddd.ddd (the tunnel device just needs an ifconfig up, it will try to detect your v4 addresses and configure them as v4-compat) ./Pedro. From: Bernard.Tuy@urec.fr Date: Sat, 20 Jul 1996 11:22:20 +0200 ====BT: Yes it does! since we -G6/France- and some others right now are running it for that purpose. +Bernard Tuy. G6/France From: Francis Dupont Date: Sat, 20 Jul 1996 17:16:56 +0200 => according to my G6 colleagues, the Solaris implementation doesn't support configured tunneling (exactly the routed prefix must be an IPv4-compatible one). => My implementations support both automatic (via a direct cloning route for the ::/96 prefix) and configured tunnels (just create a route with an IPv4-compatible gateway). Thanks Francis.Dupont@inria.fr Date: Sun, 21 Jul 1996 13:27:34 -0400 From: Craig Metz Subject: Re: How to configure a tunnel The NRL IPv6 code will happily do configured tunnels, optionally with authentication and encryption. -Craig -- From bound@zk3.dec.com Mon Jul 22 20:41:53 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 22 Jul 96 15:41:53 -0400 Subject: How to configure a tunnel In-Reply-To: Your message of "Mon, 22 Jul 96 13:16:39 EDT." <199607221716.NAA24245@home.merit.edu> Message-ID: <9607221941.AA01587@fwasted.zk3.dec.com> >My question was: >> Hi. I'd like to know how to configure a tunnel to 6bone or which >> implementation freely available supports configured tunneling. > >The answers are: >INRIA, NRL, and Linux versions support configured tunneling. >Solaris version seems not to support it now. Digital UNIX and Digital Routers (WGE and Routabout) also support configured tunneling too. We also have RIPv2v6 working too. thanks /jim From bound@zk3.dec.com Mon Jul 22 20:41:53 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 22 Jul 96 15:41:53 -0400 Subject: How to configure a tunnel In-Reply-To: Your message of "Mon, 22 Jul 96 13:16:39 EDT." <199607221716.NAA24245@home.merit.edu> Message-ID: <9607221941.AA01587@fwasted.zk3.dec.com> >My question was: >> Hi. I'd like to know how to configure a tunnel to 6bone or which >> implementation freely available supports configured tunneling. > >The answers are: >INRIA, NRL, and Linux versions support configured tunneling. >Solaris version seems not to support it now. Digital UNIX and Digital Routers (WGE and Routabout) also support configured tunneling too. We also have RIPv2v6 working too. thanks /jim From nitzan@es.net Wed Jul 24 01:08:44 1996 From: nitzan@es.net (Rebecca L. Nitzan) Date: Tue, 23 Jul 96 17:08:44 -0700 Subject: ESnet tunnel up Message-ID: <199607240008.RAA24640@hershey.es.net> Hi: We have a host up on the 6bone routed via Cisco at the moment. Hopefully next week we'll be able to forward v6 traffic through this tunnel endpoint. So far I can ping the following hosts: NRL: 5f00:3000:84fa:0000:0000:0000:0000:0001 NRL: 5f00:3000:84fa:0000:0000:0000:0000:0002 NRL: 5f00:3000:84fa:0000:0000:0000:0000:0003 NRL: 5f00:3000:84fa:0000:0000:0000:0000:0004 PEDRO: 5f0c:b300:c043:4c00:0001:0000:0000:0002 CISCO: 5f00:6d00:c01f:0700:0003:0000:0000:0001 ------------------ ----------------------- | | ........ ........... | | | tw2.es.net |---: ESnet :--: bbnplanet :---| 6bone-router.cisco.com | | Dec Alpha | : AS293 : : AS1 : | Cisco | | LBL California | ........ ........... | PA area | ------------------ ------------------------ | | |<------v6 over v4 tunnel------>| ====> traffic defaults via Cisco tw2.es.net ipv6 address = 5f01:2500:c680:400:0:800:2bbc:4cc3 -- Becca ----------------------------------------------------------------------- Rebecca L. Nitzan Lawrence Berkeley National Lab Network Engineering Services Group 1 Cyclotron Rd, 50A/3101 MS 50C ESnet - Energy Sciences Network Berkeley, CA. 94720 phone: 510-486-6468 fax: 510-486-4300 nitzan@es.net ----------------------------------------------------------------------- From masaki@merit.edu Fri Jul 26 00:14:17 1996 From: masaki@merit.edu (Masaki Hirabaru) Date: Thu, 25 Jul 1996 19:14:17 -0400 Subject: How to configure a tunnel In-Reply-To: Your message of "Sat, 20 Jul 1996 11:22:20 +0200." <199607200922.LAA13457@phoebe.urec.fr> Message-ID: <199607252314.TAA22654@home.merit.edu> 6bone folks, Bernard Tuy writes, > | automatic tunneling. I next tried to check freebsd INRIA version, > | which supports automatic tunneling, but I'm not sure if it > | supports configured tunneling. > > ====BT: Yes it does! since we -G6/France- and some others right now are > running it for that purpose. After exchanging a couple of messages with Francis Dupont, we finally found that one file (netinet/in.c) had been missing in the released package of INRIA ipv6 for freebsd. It was very tiny modification, but confused me. I attached a diff based on Francis's information. So, Merit has become completely ready for making a tunnel to 6bone now. I'm waiting. For making a private (non-routable) ipv6 testing prefix for the private part of Merit ipv6 testbed network, we may use one of private AS numbers. FYI: Here is our /etc/rc.ipv6 on a INRIA ipv6 freebsd machine. Plese note if you have more than two interfaces, you have to add "options MULTI_HOMED" and "pseudo-device llink" in your kernel configuration in this release. And also, in order to use lnc and ep devices under ipv6, you have to modify these driver source codes. #! /bin/sh autoconf6 -v ifconfig lnc0 inet6 5f00:ed00:c66c:3c00::153 prefixlen 80 alias ifconfig lnc0 inet6 first 5f00:ed00:c66c:3c00::153 prefixlen 80 ifconfig ep0 inet6 5f00:ed00:c0a8:0c00::153/80 prefixlen 80 alias ifconfig ep0 inet6 first 5f00:ed00:c0a8:0c00::153/80 prefixlen 80 sysctl -w net.inet6.ipv6.forwarding=1 ndpd-router route -n add -inet6 -net 5f00:ed00:c0a8:0a00::/80 ::192.168.10.103 The last line is making a configured tunnel to 192.168.10.103 which is on 5f00:ed00:c0a8:0a00::/80. Masaki Hirabaru Merit *** in.c.orig Sat Jul 22 23:38:11 1995 --- in.c Wed Jul 24 15:10:35 1996 *************** *** 209,220 **** --- 209,222 ---- ifra->ifra_addr.sin_addr.s_addr) break; } + #ifndef INET6 if ((ifp->if_flags & IFF_POINTOPOINT) && (cmd == SIOCAIFADDR) && (ifra->ifra_dstaddr.sin_addr.s_addr == INADDR_ANY)) { return EDESTADDRREQ; } + #endif } if (cmd == SIOCDIFADDR && ia == 0) return (EADDRNOTAVAIL); From kazu@is.aist-nara.ac.jp Tue Jul 30 11:54:09 1996 From: kazu@is.aist-nara.ac.jp (Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) Date: Tue, 30 Jul 1996 19:54:09 +0900 Subject: SSD v6 at N+I tokyo Message-ID: <12254.838724049@mine.aist-nara.ac.jp> Hi all, I would like to report a big success of "Solution Showcase Demonstration" at NetWorld+Interop 96 Tokyo. As you know, we WIDE project opened one booth for IPv6 at SSD area through 7/24 to 7/26 at Makuhari messe, Japan. Four companies(Hitachi, SEI, Fujitsu, and DEC) and two universities(NAIST, Keio) got together to show their own implementations. We demonstrated: 1) 6bone connectivity with Web 2) IPv4 and IPv6 interaction(dual stack and translator) with NV 3) Plug and Play From kazu@is.aist-nara.ac.jp Tue Jul 30 11:06:09 1996 From: kazu@is.aist-nara.ac.jp (Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) Date: Tue, 30 Jul 1996 19:06:09 +0900 Subject: How to configure a tunnel In-Reply-To: Your message of "Mon, 22 Jul 1996 13:16:39 -0400" References: <199607221716.NAA24245@home.merit.edu> Message-ID: <12133.838721169@mine.aist-nara.ac.jp> Sorry for my late response. I have been stacked in Interop Tokyo. From: Masaki Hirabaru Subject: Re: How to configure a tunnel Date: Mon, 22 Jul 1996 13:16:39 -0400 > > Hi. I'd like to know how to configure a tunnel to 6bone or which > > implementation freely available supports configured tunneling. > > The answers are: > INRIA, NRL, and Linux versions support configured tunneling. > Solaris version seems not to support it now. > > So, I'm going to figure out how to configure it under INRIA > version we've currently installed. I'm asking Francis Dupont. Gee. Why don't you, a member of WIDE project, use one of WIDE implementations? Actually Nara implementation provides a good and generic tunneling model. Currently you can make a tunnel for v6 in v6, v6 in v4, v4 in v6, v4 in v4 and I will support ESP and AH soon. If you have BSD/OS 2.0, please let me know. Mr. Shima will port the BSD/OS version to FreeBSD soon. --Kazu From hinden@ipsilon.com Tue Jul 30 16:32:48 1996 From: hinden@ipsilon.com (Bob Hinden) Date: Tue, 30 Jul 1996 08:32:48 -0700 Subject: [IPv6Imp] SSD v6 at N+I tokyo In-Reply-To: <12254.838724049@mine.aist-nara.ac.jp> Message-ID: Kazu, >I would like to report a big success of "Solution Showcase >Demonstration" at NetWorld+Interop 96 Tokyo. As you know, we WIDE >project opened one booth for IPv6 at SSD area through 7/24 to 7/26 at >Makuhari messe, Japan. Congratulations to all involved! Very nice work! Bob From nepsee@bnl.gov Tue Jul 30 19:05:26 1996 From: nepsee@bnl.gov (Tom Nepsee) Date: Tue, 30 Jul 1996 14:05:26 -0400 Subject: IPv6 for Linux ? Message-ID: <31FE4EE6.5D3F@bnl.gov> Hello, Does anyone know where I can get a Linux implementation of IPv6? If possible, I would like to run a SUN SPARC version of Linux with ipv6. Thanks for your help. -- =============================================================== Tom Nepsee nepsee@bnl.gov Network Services (516) 344-3886 Brookhaven National Laboratory =============================================================== From bound@zk3.dec.com Wed Jul 31 05:39:48 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 31 Jul 96 00:39:48 -0400 Subject: SSD v6 at N+I tokyo In-Reply-To: Your message of "Tue, 30 Jul 96 19:54:09 +0900." <12254.838724049@mine.aist-nara.ac.jp> Message-ID: <9607310439.AA27930@fwasted.zk3.dec.com> REally good job and progress. I wonder if NV app can be an app we can use as a means to show IPv6 worldwide? /jim From kazu@is.aist-nara.ac.jp Wed Jul 31 05:56:13 1996 From: kazu@is.aist-nara.ac.jp (Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) Date: Wed, 31 Jul 1996 13:56:13 +0900 Subject: SSD v6 at N+I tokyo In-Reply-To: Your message of "Wed, 31 Jul 96 00:39:48 -0400" References: <9607310439.AA27930@fwasted.zk3.dec.com> Message-ID: <12837.838788973@mine.aist-nara.ac.jp> Jim, From: bound@zk3.dec.com Subject: Re: SSD v6 at N+I tokyo Date: Wed, 31 Jul 96 00:39:48 -0400 > REally good job and progress. I wonder if NV app can be an app we can > use as a means to show IPv6 worldwide? The reason why we made use of NV is visibility of communication between v6 and v4. Perhaps telnet or ping are enough to prove connectivity but they are not appealing to attendees. Please keep in mind that all attendees are not engineer. P.S. Content of NV was Jun Murai... :) --Kazu From bound@zk3.dec.com Wed Jul 31 06:14:36 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 31 Jul 96 01:14:36 -0400 Subject: IPv6 for Linux ? In-Reply-To: Your message of "Tue, 30 Jul 96 14:05:26 EDT." <31FE4EE6.5D3F@bnl.gov> Message-ID: <9607310514.AA28505@fwasted.zk3.dec.com> Contact Pedro Roque at roque@di.fc.ul.pt /jim From bound@zk3.dec.com Wed Jul 31 06:20:40 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 31 Jul 96 01:20:40 -0400 Subject: SSD v6 at N+I tokyo In-Reply-To: Your message of "Wed, 31 Jul 96 13:56:13 +0900." <12837.838788973@mine.aist-nara.ac.jp> Message-ID: <9607310520.AA28617@fwasted.zk3.dec.com> Kazu, >> REally good job and progress. I wonder if NV app can be an app we can >> use as a means to show IPv6 worldwide? > >The reason why we made use of NV is visibility of communication >>between v6 and v4. Perhaps telnet or ping are enough to prove >connectivity but they are not appealing to attendees. Please keep in >mind that all attendees are not engineer. > >P.S. > >Content of NV was Jun Murai... :) > >--Kazu I agree. I am suggesting above we get it ported to all IPv6 platforms. For the reason you stated. /jim From kazu@is.aist-nara.ac.jp Wed Jul 31 08:24:53 1996 From: kazu@is.aist-nara.ac.jp (Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) Date: Wed, 31 Jul 1996 16:24:53 +0900 Subject: SSD v6 at N+I tokyo In-Reply-To: Your message of "Wed, 31 Jul 96 01:20:40 -0400" References: <9607310520.AA28617@fwasted.zk3.dec.com> Message-ID: <12985.838797893@mine.aist-nara.ac.jp> From: bound@zk3.dec.com Subject: Re: SSD v6 at N+I tokyo Date: Wed, 31 Jul 96 01:20:40 -0400 > I agree. I am suggesting above we get it ported to all IPv6 platforms. > For the reason you stated. Uhhm. Our NV is very ad-hoc, unicast only. We have not implemented multicast feature because we faced a scope problem for multicast. I'm planing to submit an I-D to address this issue soon. Anyway, our NV can be compiled on Nara kernel and yours, Jim. --Kazu From kazu@is.aist-nara.ac.jp Wed Jul 31 11:55:20 1996 From: kazu@is.aist-nara.ac.jp (Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) Date: Wed, 31 Jul 1996 19:55:20 +0900 Subject: tunnel request In-Reply-To: Your message of "Sat, 20 Jul 1996 11:31:39 +0200" References: <199607200931.LAA13465@phoebe.urec.fr> Message-ID: <13201.838810520@mine.aist-nara.ac.jp> From: Bernard.Tuy@urec.fr Subject: Re: tunnel request Date: Sat, 20 Jul 1996 11:31:39 +0200 > | I can ping UNI-C and G6 tunnel endpoint v4-compatible address but I can't ping > | WIDE's tunnel endpoint at ::163.221.11.21 . Please keep in mind that IPv6 test address must be used in the 6bone. There is no v4-compatible address in the WIDE 6bone. --Kazu From kazu@is.aist-nara.ac.jp Wed Jul 31 12:12:44 1996 From: kazu@is.aist-nara.ac.jp (Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) Date: Wed, 31 Jul 1996 20:12:44 +0900 Subject: more tunnels and what to do next In-Reply-To: Your message of "Sun, 21 Jul 96 20:00:35 -0400" References: <9607220000.AA00038@fwasted.zk3.dec.com> Message-ID: <13216.838811564@mine.aist-nara.ac.jp> From: Subject: Re: more tunnels and what to do next Date: Sun, 21 Jul 96 20:00:35 -0400 > So if someone wants to send sipper.pa-x.dec.com an IPv6 packet they must > go through Europe as opposed to the UNH-BAY-DEC point? If so that is > not a good idea??? The WIDE 6bone had been connected to Cisco and NRL before we set up a tunnel to UNI-C. Ask rja to set up an end point for you. As I said time to time, we have already drawn a 6bone map with our best knowledge. Access to "http://www.wide.ad.jp/wg/ipv6/6bone.ps". It seems to me that no one controls the entire policy. No routing technology is introduced. I'm very afraid that the 6bone would break down soon. Actually we WIDE project can't manage all routing information even for the WIDE 6bone so we start rejecting requests from some organizations in Japan. I suggest that we should discuss routing protocols as soon as possible. --Kazu From cmetz@inner.net Wed Jul 31 14:58:24 1996 From: cmetz@inner.net (Craig Metz) Date: Wed, 31 Jul 1996 09:58:24 -0400 Subject: more tunnels and what to do next In-Reply-To: Your message of "Wed, 31 Jul 1996 20:12:44 +0900." <13216.838811564@mine.aist-nara.ac.jp> Message-ID: <199608011221.IAA13984@inner.net> In message <13216.838811564@mine.aist-nara.ac.jp>, you write: >It seems to me that no one controls the entire policy. No routing >technology is introduced. I'm very afraid that the 6bone would break >down soon. > >Actually we WIDE project can't manage all routing information even for >the WIDE 6bone so we start rejecting requests from some organizations >in Japan. I do not believe that the current set of IPv6 test tunnels is in any danger of getting to a point where it will "break down soon". I believe that it is very easy to sit down and hammer out simple tools to manage static routing tables of the order of magnitude that you would currently need to deal with. >I suggest that we should discuss routing protocols as soon as >possible. Discuss all you want. There's no code. -Craig From bound@zk3.dec.com Wed Jul 31 14:57:55 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 31 Jul 96 09:57:55 -0400 Subject: more tunnels and what to do next In-Reply-To: Your message of "Wed, 31 Jul 96 20:12:44 +0900." <13216.838811564@mine.aist-nara.ac.jp> Message-ID: <9607311357.AA22894@fwasted.zk3.dec.com> What I think we need to do after configuring this with UNH on the east coast. Is determine a way of automating prefix distribution on the 6bone with the tunnel end points. You should be able to directly send to UNH which is our leg of the 6bone on the U.S. East coast. And not have to go through West Coast given the prefix of the node based on RFC 1897. We should have the East Coast end point up soon. If we could develop an algorithm to generate the IPv4-Tunnel end point from the prefix which may be possible using RFC 1897 that would help a lot. /jim From rja@cisco.com Wed Jul 31 16:41:08 1996 From: rja@cisco.com (Ran Atkinson) Date: Wed, 31 Jul 1996 08:41:08 PDT Subject: more tunnels and what to do next In-Reply-To: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= "Re: more tunnels and what to do next" (Jul 31, 8:12pm) Message-ID: <199607311541.IAA25565@puli.cisco.com> Kazu, I don't understand why you all are having trouble with routing. Both NRL and cisco are keeping full routing tables and not having any problems. If you can't act as a 6bone backbone router for Japan, then maybe the hub should be in Europe or North America ? I'm happy to nail up a tunnel to pretty much anyone topologically nearby that wants one, including to other Japanese sites that you are rejecting. Ran rja@cisco.com -- From qv@cs.unh.edu Wed Jul 31 17:37:58 1996 From: qv@cs.unh.edu (Quaizar Vohra) Date: Wed, 31 Jul 1996 12:37:58 -0400 (EDT) Subject: more tunnels and what to do next In-Reply-To: <9607311357.AA22894@fwasted.zk3.dec.com> from "bound@zk3.dec.com" at Jul 31, 96 09:57:55 am Message-ID: <199607311637.MAA22880@agate.cs.unh.edu> Hi Jim, > >What I think we need to do after configuring this with UNH on the east >coast. Is determine a way of automating prefix distribution on the >6bone with the tunnel end points. You should be able to directly send >to UNH which is our leg of the 6bone on the U.S. East coast. And not >have to go through West Coast given the prefix of the node based on RFC >1897. We should have the East Coast end point up soon. > >If we could develop an algorithm to generate the IPv4-Tunnel end point >from the prefix which may be possible using RFC 1897 that would help a >lot. > >/jim > Looks like a good idea. How about everyone having 24 bit IPv4 subnets. so that we have 64 bit prefixes formed from there. Ex 132.177.118.0 is 84b1:7600 when I form a prefix I get 5f02:3000:7600:84b1::/64. Then all can agree that some standard last octet can be used to find the v4 address for the tunnel endpoint. How abot using the last octet of your autonomous system # e.g. for us ASN is 0x0230 so the last octet is 0x30 so the the tunnel endpoint is 132.177.118.48. This is pretty restrictive though, may be something on similar lines. Quaizar -- ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-0090 From roque@di.fc.ul.pt Wed Jul 31 18:31:53 1996 From: roque@di.fc.ul.pt (Pedro Roque Marques) Date: Wed, 31 Jul 1996 18:31:53 +0100 Subject: more tunnels and what to do next In-Reply-To: <199607311637.MAA22880@agate.cs.unh.edu> References: <9607311357.AA22894@fwasted.zk3.dec.com> <199607311637.MAA22880@agate.cs.unh.edu> Message-ID: <199607311731.SAA10264@oberon.di.fc.ul.pt> >>>>> "Quaizar" == Quaizar Vohra writes: Quaizar> Hi Jim, >> What I think we need to do after configuring this with UNH on >> the east coast. Is determine a way of automating prefix >> distribution on the 6bone with the tunnel end points. You >> should be able to directly send to UNH which is our leg of the >> 6bone on the U.S. East coast. And not have to go through West >> Coast given the prefix of the node based on RFC 1897. We >> should have the East Coast end point up soon. >> >> If we could develop an algorithm to generate the IPv4-Tunnel >> end point from the prefix which may be possible using RFC 1897 >> that would help a lot. >> >> /jim >> Quaizar> Looks like a good idea. How about everyone having 24 bit Quaizar> IPv4 subnets. so that we have 64 bit prefixes formed from Quaizar> there. Ex 132.177.118.0 is 84b1:7600 when I form a prefix Quaizar> I get 5f02:3000:7600:84b1::/64. Then all can agree that Quaizar> some standard last octet can be used to find the v4 Quaizar> address for the tunnel endpoint. How abot using the last Quaizar> octet of your autonomous system # e.g. for us ASN is Quaizar> 0x0230 so the last octet is 0x30 so the the tunnel Quaizar> endpoint is 132.177.118.48. Quaizar> This is pretty restrictive though, may be something on Quaizar> similar lines. Sorry, but the idea seams terrible. This way to configure a tunnel you are requiring that end points have a particular IPv4 address which might be already in use by another system on your network, no matter what the scheme is. Also you impose that the is only one tunnel end-point per prefix. Some people already have more than one (for different tunnels of course), if i'm not mistaken, and i was planning on doing the same. The second point is that i really don't understand what you're trying to achieve. If we're talking about static configuration here, then all you need to know is the other end prefix and v4 end-point. As you've seen the end-point info doesn't add too much space to the prefix list that you need anyway. And, as things are today, you can configure unidirectional links, i.e. configure a tunnel for which the other end point knows nothing, if you have the prefix and v4 address. Your proposal makes this even easier to happen, which i don't think is a good idea. If you ask the DNS, it will happily tell you quad-A records for my network but i would apreciate that people wouldn't start dumping packets to my tunnel end-point without prior agreement. The original question is if packets from A should go to B before reaching C, C being closer to A. I believe the answer to be: set a tunnel between A and C and tell B about it. regards, Pedro. From Alain.Durand@imag.fr Wed Jul 31 04:06:29 1996 From: Alain.Durand@imag.fr (Alain Durand) Date: Wed, 31 Jul 1996 05:06:29 +0200 Subject: RFC1897 & more tunels In-Reply-To: rja@cisco.com (Ran Atkinson) "Re: more tunnels and what to do next" (Jul 31, 8:41am) References: <199607311541.IAA25565@puli.cisco.com> Message-ID: <960731050629.ZM10338@rama.imag.fr> The question now is how to grow from a 3 nodes 6-bone to a 10 or 15 nodes 6-bone Basicaly I see 3 solutions for the very short term 1) an n to n topology. Each node maintains routing tables to the other nodes. This is what we agreed on at last 6-bone meeting in Montreal. This just won't scale very well. 2) a star topology. Only the central node has to maintain all routes, the other just need a default route to it. The drawback is that scheme create a single point of failure. 3) a mix of the 2 solutions. In france, the G6-bone is made of 3 islands and will grow to 5 or 6 by the end of the year. We agreed on a star topology inside the G6-bone with a central node at imag (129.88.30.1, 6bone-gw.ipv6.imag.fr, 5f06:b500:8158:1a00:1:0:8158:1a01) What could be a solution will be to have a small number of core 6-bone nodes will a complete knowledge of the other core nodes. Typically one for each country. Then, other folks willing to join will just have to tunnel to the closest core 6-bone node. This is not as simple as it sounds. The problem is with the routing tables. We do not want to manage hundreds of static routes. The issue is RFC897. It specifies that the address is 5f + ASnumber of the IPv4 provider + ipv4 address of the network. This is simple and does not require any registry. But maybe it's too simple. We can not easily agregate routes that are not for the same AS, and inside an AS, we can not agregate routes for differents ipv4 networks that belong to the same institute. Let me take two examples: a) inside the G6-bone, we have an island at INRIA. They use 2 ipv4 networks with very differents numbers. I need two different routes for them. b) inside the 6-bone. I have asked people to route 5f06:b500::/32 to my entry point. Fine till now. But if someone inside G6 has a different ISP tham mine, this will not work anymore. So maybe it's time to revisit RFC1897. RFC1897 states: | 3 | 5 bits | 16 bits | 8 | 24 bits | 8 | 16 bits|48 bits| +---+----------+----------+---+------------+---+--------+-------+ | | |Autonomous| | IPv4 | | Subnet | Intf. | |010| 11111 | System |RES| Network |RES| | | | | | Number | | Address | | Address| ID | +---+----------+----------+---+------------+---+--------+-------+ maybe something more suitable will be: | 3 | 5 bits | 8bits| 16 bits | 8bits | 24 bits | 16 bits|48 bits| +---+----------+------+----------+-------+-----------+--------+-------+ | | | |Autonomous|IPv6 | IPv4 | Subnet | Intf. | |010| 11111 |6-bone| System |Island |Network | | | | | |node | Number |Number | Address | Address| ID | +---+----------+-----------------+-------------------+--------+-------+ The "6 bone node" will then be a number attributed to a core 6-bone node. As there will be very few core 6-bone node, this will be managable. Then, inside each island, we can attribute island numbers. Using this scheme, routing table will be very simple. The n core 6-bone nodes will only need n-1 "external" routes and m (the number of internal island) "internal" routes. Then as Jim said, we also need an algorithm to find the ipv4 address of a tunnel endpoint from it's ipv6 address. I have a suggestion: assign a special ipv6 global address for the tunnel endpoint and put the ipv4 address of the encapsulating interface into the last 32 bits. Example, my tunnel IPv4 address is: 129.88.26.1 (= 8158:1a01 hexa) It's IPv6 address is 6bone-gw.ipv6.imag.fr: 5f06:b500:8158:1a00:1:0:8158:1a01 according to RFC1897 and could be 5f01:06b5:0181:581a:0001:0000:8158:1a01 -> 6-bone node 1 -> AS 06b5 -> island number 1 -> ipv4 network address: 81:581a -> subnet address: 0001 -> interface: 0000:8158:1a01 -> ipv4 tunnel interface 129.88.26.1 according to the scheme I propose. - Alain. -- ^_^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ U (* *) Alain DURAND | Preserve keyboards: | ( v ) I.M.A.G. | use completion. | /~~~\ Direction des Moyens Informatiques |----------------------------- <|=< IP >= BP 53 38041 Grenoble Cedex 9 | E-Mail: Alain.Durand@imag.fr | \ v6/ France | Phone: +33 76 63 57 03 | <~~< Postmaster@imag.fr | Fax: +33 76 51 49 64 ~ ~ From cmetz@inner.net Wed Jul 31 19:42:21 1996 From: cmetz@inner.net (Craig Metz) Date: Wed, 31 Jul 1996 14:42:21 -0400 Subject: RFC1897 & more tunels In-Reply-To: Your message of "Wed, 31 Jul 1996 05:06:29 +0200." <960731050629.ZM10338@rama.imag.fr> Message-ID: <199608011705.NAA14208@inner.net> In message <960731050629.ZM10338@rama.imag.fr>, you write: >The question now is how to grow from a 3 nodes 6-bone >to a 10 or 15 nodes 6-bone I believe you are a month too late. I am concerned about recent discussions of going and changing address formats. People are creating problems that don't really exist and then trying to solve them. The current address syntax is not perfect, but it works fine. -Craig From qv@cs.unh.edu Wed Jul 31 21:32:35 1996 From: qv@cs.unh.edu (Quaizar Vohra) Date: Wed, 31 Jul 1996 16:32:35 -0400 (EDT) Subject: more tunnels and what to do next (fwd) Message-ID: <199607312032.QAA24799@agate.cs.unh.edu> Dear qv, From bogus@does.not.exist.com Wed Jul 31 19:32:04 1996 From: bogus@does.not.exist.com () Date: Wed, 31 Jul 1996 14:32:04 -0400 (EDT) Subject: more tunnels and what to do next In-Reply-To: <199607311731.SAA10264@oberon.di.fc.ul.pt> from "Pedro Roque Marques" at Jul 31, 96 06:31:53 pm > >>>>>> "Quaizar" == Quaizar Vohra writes: > > Quaizar> Hi Jim, > >> What I think we need to do after configuring this with UNH on > >> the east coast. Is determine a way of automating prefix > >> distribution on the 6bone with the tunnel end points. You > >> should be able to directly send to UNH which is our leg of the > >> 6bone on the U.S. East coast. And not have to go through West > >> Coast given the prefix of the node based on RFC 1897. We > >> should have the East Coast end point up soon. > >> > >> If we could develop an algorithm to generate the IPv4-Tunnel > >> end point from the prefix which may be possible using RFC 1897 > >> that would help a lot. > >> > >> /jim > >> > > Quaizar> Looks like a good idea. How about everyone having 24 bit > Quaizar> IPv4 subnets. so that we have 64 bit prefixes formed from > Quaizar> there. Ex 132.177.118.0 is 84b1:7600 when I form a prefix > Quaizar> I get 5f02:3000:7600:84b1::/64. Then all can agree that > Quaizar> some standard last octet can be used to find the v4 > Quaizar> address for the tunnel endpoint. How abot using the last > Quaizar> octet of your autonomous system # e.g. for us ASN is > Quaizar> 0x0230 so the last octet is 0x30 so the the tunnel > Quaizar> endpoint is 132.177.118.48. > > Quaizar> This is pretty restrictive though, may be something on > Quaizar> similar lines. > >Sorry, but the idea seams terrible. > >This way to configure a tunnel you are requiring that end points have >a particular IPv4 address which might be already in use by another >system on your network, no matter what the scheme is. Also you impose >that the is only one tunnel end-point per prefix. Some people already >have more than one (for different tunnels of course), if i'm not >mistaken, and i was planning on doing the same. > >The second point is that i really don't understand what you're trying >to achieve. If we're talking about static configuration here, then all >you need to know is the other end prefix and v4 end-point. As you've >seen the end-point info doesn't add too much space to the prefix list >that you need anyway. > >And, as things are today, you can configure unidirectional >links, i.e. configure a tunnel for which the other end point knows >nothing, if you have the prefix and v4 address. Your proposal makes >this even easier to happen, which i don't think is a good idea. > >If you ask the DNS, it will happily tell you quad-A records for my >network but i would apreciate that people wouldn't start dumping >packets to my tunnel end-point without prior agreement. > >The original question is if packets from A should go to B before >reaching C, C being closer to A. I believe the answer to be: set a >tunnel between A and C and tell B about it. > >regards, > Pedro. > I agree my idea is terrible. The question I think is to reduce the amount of static configuration. Currently we can live with these, but not for long. But wait for routing protocols till then. But I would prefer using prefixes which would aggregate routes in one region, i.e. into shorter prefixes. So that people do heirarchial routing and have less tunnels to configure. I agree that currenlty 6bone is like mbone, but I hope we don't want it to continue like that for long. For example here on East coast we can have one single tunnel end-point for Digital, UNH and Bay and possibly others. Quaizar ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-0090 -- ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-0090 From roque@di.fc.ul.pt Wed Jul 31 21:40:27 1996 From: roque@di.fc.ul.pt (Pedro Roque Marques) Date: Wed, 31 Jul 1996 21:40:27 +0100 Subject: RFC1897 & more tunels In-Reply-To: <960731050629.ZM10338@rama.imag.fr> References: <199607311541.IAA25565@puli.cisco.com> <960731050629.ZM10338@rama.imag.fr> Message-ID: <199607312040.VAA10574@oberon.di.fc.ul.pt> >>>>> "Alain" == Alain Durand writes: Hi Alain, Alain> So maybe it's time to revisit RFC1897. One of us has a interpretation problem with 1897. The way i read it is that it describes a way for automatic assigment of IPv6 prefixes, it does not limit what you can do with them. If you have your own prefix you can delegate how much of it to anyone you wish to. If you own an AS registration you have automatically a /24 prefix, so you can acomodate up to 2^40 sites and still give them a /64 prefix. hope it is enought ;-). regards, Pedro. From deering@parc.xerox.com Wed Jul 31 22:02:30 1996 From: deering@parc.xerox.com (Steve Deering) Date: Wed, 31 Jul 1996 14:02:30 PDT Subject: more tunnels and what to do next (fwd) Message-ID: <96Jul31.140231pdt."75270"@digit.parc.xerox.com> Obviously, manual configuration of routes gets unmanageable pretty quickly -- it's only tolerable for a few tens of routes. Routers in stub subtrees need not keep all the routes, just the local ones plus default, so we can can probably tolerate manual config at the edges for some time. However, for those more centrally located routers, I think we should exert effort to get RIPng deployed and working -- that ought to be relatively straightforward, and in my opinion, a better use of time than tryng to get agreement on yet another interim addressing plan. Flat routing with RIPng should suffice for hundreds of routes; beyond that, we clearly need hierarchical routing, but that should probably also coincide with moving to "real" addresses, rather than the test addresses. Steve From rja@cisco.com Wed Jul 31 22:11:12 1996 From: rja@cisco.com (Ran Atkinson) Date: Wed, 31 Jul 1996 14:11:12 PDT Subject: more tunnels and what to do next (fwd) In-Reply-To: qv@cs.unh.edu (Quaizar Vohra) "Re: more tunnels and what to do next (fwd)" (Jul 31, 4:32pm) Message-ID: <199607312111.OAA24495@puli.cisco.com> Quaizar, Your tunnel endpoint can contain a "default" (actually 5f00::/8) route pointing at NRL, a static route for DEC, a static route for Bay, and any routes needed with UNH. That is entirely sufficient to work properly with the 6bone and seems entirely managable by hand. So I don't see the need for any changes to the 1897 specification. Ran rja@cisco.com -- From qv@cs.unh.edu Wed Jul 31 22:20:00 1996 From: qv@cs.unh.edu (Quaizar Vohra) Date: Wed, 31 Jul 1996 17:20:00 -0400 (EDT) Subject: more tunnels and what to do next (fwd) In-Reply-To: <199607312111.OAA24495@puli.cisco.com> from "Ran Atkinson" at Jul 31, 96 02:11:12 pm Message-ID: <199607312120.RAA25165@agate.cs.unh.edu> Hi Ran, > >Quaizar, > > Your tunnel endpoint can contain a "default" (actually 5f00::/8) >route pointing at NRL, a static route for DEC, a static route >for Bay, and any routes needed with UNH. That is entirely >sufficient to work properly with the 6bone and seems entirely >managable by hand. > > So I don't see the need for any changes to the 1897 specification. > >Ran >rja@cisco.com > > >-- > That's what I am currently doing and it works, but as Alain pointed out that we don't want a star topology. I agree fully with Alain's idea which has always been my chant, i.e. do heirachial routing. Quaizar From deering@parc.xerox.com Wed Jul 31 23:00:19 1996 From: deering@parc.xerox.com (Steve Deering) Date: Wed, 31 Jul 1996 15:00:19 PDT Subject: more tunnels and what to do next (fwd) In-Reply-To: qv's message of Wed, 31 Jul 96 14:20:00 -0800. <199607312120.RAA25165@agate.cs.unh.edu> Message-ID: <96Jul31.150020pdt."75270"@digit.parc.xerox.com> > That's what I am currently doing and it works, but as Alain pointed > out that we don't want a star topology. I agree fully with Alain's > idea which has always been my chant, i.e. do heirachial routing. I think that an approximate star topology, i.e., a small mesh of "backbone" routers, with individual sites connected as leaves to the nearest one or two backbone routers, would be just fine for a while. If you want to exploit a richer topology and get out of the static configuration game, then use a dynamic routing protocol, like RIPng. Hierarchical routing is what you do when flat routing gets too big -- I don't think that'll be the case at least for the next 6 months. Steve From mankin@ISI.EDU Wed Jul 31 23:12:50 1996 From: mankin@ISI.EDU (Allison Mankin) Date: Wed, 31 Jul 1996 18:12:50 EDT Subject: more tunnels and what to do next (fwd) In-Reply-To: Your message of "Wed, 31 Jul 1996 14:02:30 PDT." <96Jul31.140231pdt."75270"@digit.parc.xerox.com> Message-ID: <199607312209.AA26407@metro.isi.edu> Steve, > for those more centrally located routers, I think we should exert effort > to get RIPng deployed and working -- that ought to be relatively > straightforward, and in my opinion, a better use of time than tryng to > get agreement on yet another interim addressing plan. > Yes. Craig Labovitz (MERIT) has developed a RIPv2 for IPv6, which some sites on this list have been testing. > Flat routing with RIPng should suffice for hundreds of routes; beyond that, > we clearly need hierarchical routing, but that should probably also > coincide with moving to "real" addresses, rather than the test addresses. > > Those quotes around real are very poignant. Can we later this year have an interim draft for aggregatable addresses? I would like to see it be geographic addressing without all the details resolved: Instead of Alain's "cores", your design team could give us interim neutral interconnects, leaving out for this cut how the "real" ones will manage internal routing. Just a wish, Allison From bound@zk3.dec.com Wed Jul 31 23:03:29 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 31 Jul 96 18:03:29 -0400 Subject: more tunnels and what to do next (fwd) In-Reply-To: Your message of "Wed, 31 Jul 96 14:11:12 PDT." <199607312111.OAA24495@puli.cisco.com> Message-ID: <9607312203.AA23604@fwasted.zk3.dec.com> Ran, > Your tunnel endpoint can contain a "default" (actually 5f00::/8) >route pointing at NRL, a static route for DEC, a static route >for Bay, and any routes needed with UNH. That is entirely >sufficient to work properly with the 6bone and seems entirely >managable by hand. I use this to get to UNH as I direct all traffic through to UNH as 5f00/8. But I don't want Quaizar doing this for the east coast. I want him to have a route to you, one to WIDE, one to Europe, one to NRL, et al. We should not have to go through you to get to WIDE that is not a good enough test. Or likewise I don't think you should have to go through us to get to G6 in Europe via UNH. /jim From bound@zk3.dec.com Wed Jul 31 23:07:02 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 31 Jul 96 18:07:02 -0400 Subject: RIPng Message-ID: <9607312207.AA23783@fwasted.zk3.dec.com> We have the following implementations running RIPng to start using routing: 1. Telebit Router 2. Digital Router 3. Bay Networks Router 4. Sun Host 5. Digital Host (Static Routes now) So lets use them. UNH will have both Digital and Bay Routers. There will also be a Digital IPv6 router at G6 soon. Telebit is already doing this I think. So lets just do it and quit talking about it the code does exist. /jim From qv@cs.unh.edu Wed Jul 31 04:01:27 1996 From: qv@cs.unh.edu (Quaizar Vohra) Date: Wed, 31 Jul 1996 23:01:27 +2000 (EDT) Subject: more tunnels and what to do next (fwd) Message-ID: <199608010301.XAA25567@agate.cs.unh.edu> Dear qv, From bogus@does.not.exist.com Wed Jul 31 03:54:07 1996 From: bogus@does.not.exist.com () Date: Wed, 31 Jul 1996 22:54:07 +2000 (EDT) Subject: more tunnels and what to do next (fwd) In-Reply-To: <96Jul31.150020pdt."75270"@digit.parc.xerox.com> from "Steve Deering" at Jul 31, 96 03:00:19 pm Dear Steve Deering, > >> That's what I am currently doing and it works, but as Alain pointed >> out that we don't want a star topology. I agree fully with Alain's >> idea which has always been my chant, i.e. do heirachial routing. > >I think that an approximate star topology, i.e., a small mesh of "backbone" >routers, with individual sites connected as leaves to the nearest one >or two backbone routers, would be just fine for a while. If you want to >exploit a richer topology and get out of the static configuration game, >then use a dynamic routing protocol, like RIPng. Hierarchical routing >is what you do when flat routing gets too big -- I don't think that'll >be the case at least for the next 6 months. > >Steve > > I actually meant almost the same, though stupid enough not to be able to express it well in my mails. Currently we have a single central node and I was against that. I has always been giving an example of UNH-BAY-CLOUD where there is one connection to the bone and that tunnel endpoint takes care of routing internally and I wanted a single autonomous number being used for all three of us and so that we have a common prefix. That's what I wrote to Craig Metz a few days back. Hence we have a few core routers each routing for a big cloud and the cloud should have one common prefix (desirable) or a few, not a lots, i.e. one for each subnet. How the cloud handles internal routing can be its own policy. By the way I thought the large addresses were created for heirachial routing and 6bone was something experimental where we can try this out. Regards Quaizar -- ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-0090 -- ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-0090