From W. Richard Stevens" I'd like to join the 6bone. After following this mailing list for the past few weeks, and looking at the home page, it's not obvious how this happens. My guess is to just find someone "close" that is already connected, who is willing to provide a tunnel? I've got the current map, have done some pings and traceroutes, and it appears "Sun/US" is the "closest". I'm in Tucson and my network connectivity goes through either SprintLink is Anaheim or MCI in Los Angeles. (It's hard to tell from the names on the map, just where the site is located, physically and network-wise.) I am assuming that's its best to connect to one of the leaves (like Sun), and not the interior nodes (like Cisco). Rich Stevens (I apologize is this is a duplicate. I sent the same request out yesterday, but it was from an email account other than my 6bone subscription, so it appears to have been tossed, although majordomo did not return an error of any form.) From rja@cisco.com Mon Sep 2 20:07:59 1996 From: rja@cisco.com (Ran Atkinson) Date: Mon, 2 Sep 1996 12:07:59 PDT Subject: 6bone connection requested In-Reply-To: rstevens@kohala.com (W. Richard Stevens) "6bone connection requested" (Sep 1, 7:51am) Message-ID: <199609021907.MAA12079@puli.cisco.com> Rich, cisco is basically willing to provide a tunnel to anyone that is topologically nearby. If you want a tunnel with cisco, send me private email with the particulars. If you prefer to setup a tunnel with Sun or some other node, that's also fine with us. Ran rja@cisco.com -- From RLFink@lbl.gov Tue Sep 3 15:52:04 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 3 Sep 1996 07:52:04 -0700 Subject: 6bone map - tunnel from UNH/US to UNI-C/DK In-Reply-To: <199608302221.PAA05287@strat.iol.unh.edu> Message-ID: 6bone drawing version 12 (3 Sep 96) adds tunnel from UNH/US to UNI-C/DK. Bob http://www-6bone.lbl.gov/6bone/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At 3:21 PM -0700 8/30/96, Sebastien.Roy@unh.edu wrote: >Hello, > > My name is Sebastien Roy, and I am from the InterOperability >Laboratory at the University of New Hampshire. I know how much you >must love updating the 6bone map that you have so generously made >available to us. There is a tunnel that is not reflected in the map >however. It connects UNH and UNI-C. Thanks. By the way, the map is >very useful! > >-- >Sebastien C. Roy >RCC/IOL >University of New Hampshire >Sebastien.Roy@unh.edu From weiss@uni-mainz.de Tue Sep 3 16:53:49 1996 From: weiss@uni-mainz.de (Juergen Weiss) Date: Tue, 3 Sep 1996 17:53:49 +0200 (MET DST) Subject: IPv6 www Server on tick.ipv6.Uni-Mainz.DE Message-ID: <199609031553.RAA03791@bianca.ZDV.Uni-Mainz.DE> Hi all, to make our site more interesting I have installed a www server on tick.ipv6.Uni-Mainz.DE. This is an ipv6 only www server. It provides the same pages as the regular www server www.Uni-Mainz.DE (ipv4 only). But beware: No ipv6 specific information. Most pages are in German. Nevertheless better than icmp responses elicted by ping. The server is a quick port of apache 1.1.1 to ipv6 running on a Netbsd PC with the INRIA ipv6 code. Juergen Weiss -- Juergen Weiss | Universitaet Mainz, Zentrum f"ur Datenverarbeitung, weiss@uni-mainz.de | 55099 Mainz, Tel: 06131/39-6361, FAX: 06131/39-6407 From crawdad@fnal.gov Tue Sep 3 19:38:53 1996 From: crawdad@fnal.gov (Matt Crawford) Date: Tue, 03 Sep 1996 13:38:53 -0500 Subject: FNAL on 6bone Message-ID: <199609031838.NAA18874@munin.fnal.gov> Fermilab came up on a 6bone tunnel to ESNET as of August 31. We're routing 5f01:2500:83e1::/48 by the tunnel to ::131.225.57.207. I'm adding internal tunnels to our major workgroups so that by tomorrow IPv6 routing should be available to more than 80% of the site. Other DOE national labs are invited to request tunnels to FNAL (with ESNET coordination), as are universities directly connected to the Chicago NAP. Matt Crawford From W. Richard Stevens" Before adding AAAA records to my name server I started wondering just what my secondary was going to do when it got AAAA records in the zone transfers. As Mark Andrews pointed out to me, even if the secondary's server ignores them gracefully (which it isn't ovbious older versions of bind do) one's secondary server had better understand AAAA records too, since all servers are considered equal. Currently my ISP is providing my secondary, but they're not at bind-4.9.4 so I'd better find a new secondary. Is anyone willing to provide a secondary--I'm willing to reciprocate for anyone else needing an IPv6-knowledgable secondary. BTW, shouldn't this be added to some of the transition documentation somewhere--the fact that not only must one's name server be AAAA knowledgable, but also one's secondary server(s)? It could take many years for some vendors to ship a version of bind that understands AAAA records. Rich Stevens From crawdad@fnal.gov Tue Sep 3 20:48:21 1996 From: crawdad@fnal.gov (Matt Crawford) Date: Tue, 03 Sep 1996 14:48:21 -0500 Subject: secondary name server that understands AAAA records In-Reply-To: "03 Sep 1996 11:15:59 PDT." <"199609031815.LAA10378"@kohala.kohala.com> Message-ID: <199609031948.OAA19207@munin.fnal.gov> > Before adding AAAA records to my name server I started wondering > just what my secondary was going to do when it got AAAA records > in the zone transfers. After a couple of years without a peek in the BIND source code, I was shocked and dismayed last week to see that named-xfer uses a text-based intermediate file. This means that even though a non-authoritative server will correctly cache RRs it doesn't understand, a secondary server won't get them. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A From RLFink@lbl.gov Tue Sep 3 21:40:17 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 3 Sep 1996 13:40:17 -0700 Subject: 6bone map - new tunnels for FNAL/US and KEK/JP from ESnet/US Message-ID: 6bone map version 13 (3 Sep 96) adds tunnels from ESnet/US to FNAL/US and from ESnet/US to KEK/JP. Bob http://www-6bone.lbl.gov/6bone/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D To: Bob Fink LBNL Cc: Matt Crawford , routing@es.net Subject: Re: IPv6 forwarding code in place Date: Tue, 03 Sep 96 11:21:12 -0700 =46rom: "Rebecca L. Nitzan" Bob: We also brought up a tunnel to KEK this weekend. They are prefix 5F09:C900::/32 hosts: ping6 5f09:c900:8257:3900:0:20:aff8:84fa ping6 5f09:c900:8257:3900:0:800:2be4:4450 -- Becca =3D=3D Date: Tue, 03 Sep 1996 13:38:53 -0500 =46rom: Matt Crawford Subject: FNAL on 6bone To: 6bone Mailer <6bone@isi.edu> =46ermilab came up on a 6bone tunnel to ESNET as of August 31. We're routing 5f01:2500:83e1::/48 by the tunnel to ::131.225.57.207. I'm adding internal tunnels to our major workgroups so that by tomorrow IPv6 routing should be available to more than 80% of the site. Other DOE national labs are invited to request tunnels to FNAL (with ESNET coordination), as are universities directly connected to the Chicago NAP. Matt Crawford - From kml@nas.nasa.gov Wed Sep 4 01:39:52 1996 From: kml@nas.nasa.gov (Kevin M. Lahey) Date: Tue, 03 Sep 1996 17:39:52 -0700 Subject: secondary name server that understands AAAA records In-Reply-To: Your message of "Tue, 03 Sep 1996 11:15:59 PDT." <199609031815.LAA10378@kohala.kohala.com> Message-ID: <199609040039.RAA00685@galaxy.nas.nasa.gov> In message <199609031815.LAA10378@kohala.kohala.com>W. Richard Stevens writes >Before adding AAAA records to my name server I started wondering >just what my secondary was going to do when it got AAAA records >in the zone transfers. I just created a subdomain into which I put all of my AAAA records, ipv6.nas.nasa.gov. It looks like quite a few other sites are doing something similar. The documentation for the Inria code suggests that it can be difficult to deal with hosts that have both IPv4 and IPv6 address mappings: FIRST use DNS option "mapIPv6" ("options mapIPv6" in /etc/resolv.conf or "setenv RES_OPTIONS mapIPv6"). If you forget this any IPv6/IPv4 application will try to get AAAA RR before A RR and wait because there are no AAAA RR. With it you cannot use a name bound to both an IPv4 and an IPv6 address. Or is there something else at work here? I've noticed relatively little discussion of this, or of reverse DNS issues. Thanks, Kevin From kml@nas.nasa.gov Wed Sep 4 01:56:59 1996 From: kml@nas.nasa.gov (Kevin M. Lahey) Date: Tue, 03 Sep 1996 17:56:59 -0700 Subject: secondary name server that understands AAAA records In-Reply-To: Your message of "Tue, 03 Sep 1996 17:39:52 PDT." <199609040039.RAA00685@galaxy.nas.nasa.gov> Message-ID: <199609040057.RAA00774@galaxy.nas.nasa.gov> In message <199609040039.RAA00685@galaxy.nas.nasa.gov>"Kevin M. Lahey" writes >I just created a subdomain into which I put all of my AAAA records, >ipv6.nas.nasa.gov. It looks like quite a few other sites are doing >something similar. Which isn't to suggest that a secondary is unnecessary, but that you could chose a different secondary for the domain that contains the AAAA records. Sorry for the ambiguity. I'd be happy to serve as secondary for anyone who needs it. Thanks, Kevin From bound@zk3.dec.com Wed Sep 4 04:29:01 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Tue, 03 Sep 96 23:29:01 -0400 Subject: secondary name server that understands AAAA records In-Reply-To: Your message of "Tue, 03 Sep 96 17:56:59 PDT." <199609040057.RAA00774@galaxy.nas.nasa.gov> Message-ID: <9609040329.AA06503@fwasted.zk3.dec.com> Kevin, AAAA is just another RR type. If BIND don't find AAAA record condition is returned to resolver not found. Then go look for A RR type. I don't see what the problem is or would be unless folks are trying to alter BIND Server code? Good luck. As far as transition spec. Secondaries are not required in DNS (though useful). Some of the transition spec was left to common sense. If you want a secondary that supports AAAA records and it don't do IPv6 that just seems dumb. I don't think we should have to specify this in that spec. But clearly useful for documentation as we roll out our kits and products as vendors. /jim From Francis.Dupont@inria.fr Wed Sep 4 12:25:33 1996 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Wed, 04 Sep 1996 13:25:33 +0200 Subject: secondary name server that understands AAAA records In-Reply-To: Your message of Tue, 03 Sep 1996 23:29:01 EDT. <9609040329.AA06503@fwasted.zk3.dec.com> Message-ID: <199609041125.NAA27778@givry.inria.fr> In your previous mail you wrote: AAAA is just another RR type. If BIND don't find AAAA record condition is returned to resolver not found. Then go look for A RR type. I don't see what the problem is or would be unless folks are trying to alter BIND Server code? Good luck. => it is not so simple. You can look at the return code because with NXDOMAIN it is not useful to go look for an A RR (or any RR). Another problem is the order when you have a search list (and you should have one, see below). As far as transition spec. Secondaries are not required in DNS (though useful). Some of the transition spec was left to common sense. If you want a secondary that supports AAAA records and it don't do IPv6 that just seems dumb. I don't think we should have to specify this in that spec. But clearly useful for documentation as we roll out our kits and products as vendors. => the common solution to this problem is to have a special zone (for instance ipv6.) and to select secondaries with AAAA support. Two remarks: - common BINDs are enough for the reverse zone (which uses only PTR RRs). - it is very easy to add AAAA support to an old BIND. The diffs are small and can be applied to any architecture. Especially you have *not* to run IPv6 in order to support AAAA RRs for a secondary. Regards Francis.Dupont@inria.fr l to try to get an A record) or NOERROR (then there is likely an A RR). Or is there something else at work here? I've noticed relatively little discussion of this, or of reverse DNS issues. => reverse DNS is much simpler, there is only an issue for IPv4-compatible addresses... Regards Francis.Dupont@inria.fr From RLFink@lbl.gov Fri Sep 6 15:33:47 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 6 Sep 1996 07:33:47 -0700 Subject: no 6bone map changes till the 16th Sep Message-ID: 6bone folks, Am on travel all of next week (9th thru the 13th of Sep), and won't be dealing with email at all. So if you have 6bone map config change info, please note that I won't respond to it till the 16th of Sep. Gee, a week without email...how novel :-) Thanks, Bob From RLFink@lbl.gov Fri Sep 6 17:19:32 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 6 Sep 1996 09:19:32 -0700 Subject: 6bone map - new tunnel from Cisco/US to UOregon/US Message-ID: Dave Meyer caught me before I left! 6bone map version 14 (6 Sep 96) adds tunnels from Cisco/US to UOregon/US. Bob http://www-6bone.lbl.gov/6bone/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D To: Bob Fink LBNL Subject: Re: no 6bone map changes till the 16th Sep Date: Fri, 06 Sep 1996 08:33:09 -0700 =46rom: "David M. Meyer 541/346-1747" Bob, The University of Oregon has just brought up a tunnel to Cisco. Have a good trip (vacation, I hope). Thanks, Dave - From ahoag@nas.nasa.gov Sat Sep 7 22:43:35 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Sat, 7 Sep 1996 14:43:35 -0700 Subject: Geographically-based 3D map Message-ID: <9609071443.ZM26132@rennsport.nas.nasa.gov> There is now a geographically-based map available on the WWW. Using tools borrowed from the Mbone visualization, we at NAS have come up with a VRML model of the 6bone with all the tunnels that we could find represented. The URL for the new map is: http://www.nas.nasa.gov/NAS/Groups/netops/IPv6/viz/index.html There are static GIFs available as well, for those without VRML browsers. I am still missing IPv4 endpoints for U of Oregon and KEK/JP (I guessed on KEK). If anyone can provide those to me I will add them to the map. In the near future, we hope to publish a database of the available tunnels and allow for everyone to update it themselves. This hopefully will provide the most current repository for sites and contacts. Any questions, corrections or feedback can be addressed to . -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From yamagata@nwgpc.kek.jp Sun Sep 8 20:23:32 1996 From: yamagata@nwgpc.kek.jp (yamagata@nwgpc.kek.jp) Date: Mon, 09 Sep 1996 04:23:32 +0900 Subject: Geographically-based 3D map In-Reply-To: Your message of "Sat, 7 Sep 1996 14:43:35 -0700" References: <9609071443.ZM26132@rennsport.nas.nasa.gov> Message-ID: <19960909042332M/yamagata@nwgpc.kek.jp> > http://www.nas.nasa.gov/NAS/Groups/netops/IPv6/viz/index.html > There are static GIFs available as well, for those without VRML > browsers. I am still missing IPv4 endpoints for U of Oregon and > KEK/JP (I guessed on KEK). If anyone can provide those to me I will > add them to the map. Our KEK/JP endpoint machine is 130.87.57.37 5f09:c900:8257:3900:0:20:aff8:84fa yamagata From mdp@tbit.dk Thu Sep 12 01:16:04 1996 From: mdp@tbit.dk (Martin Peck) Date: Wed, 11 Sep 1996 17:16:04 -0700 Subject: 6Bone Mail Message-ID: <32375644.5193@tbit.dk> Hi All, Telebit Communications has now set up IPv6 tunnels to UNI-C and the JOIN team in Munster, to participate in the testing of IDRPv6. An update to the 6Bone map should follow shortly. Although the use of this routing protocol still requires configured tunnels to be established it does allow the propogation of routing information between domains. Its wider use in the 6Bone network could perhaps be discussed in parallel to the dialogue surrounding RIP. Feedback Requested. Martin Peck URL: http://www.tbit.dk/ From Francis.Dupont@inria.fr Wed Sep 11 15:37:48 1996 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Wed, 11 Sep 1996 16:37:48 +0200 Subject: 6Bone Mail In-Reply-To: Your message of Wed, 11 Sep 1996 17:16:04 PDT. <32375644.5193@tbit.dk> Message-ID: <199609111437.QAA03759@givry.inria.fr> In your previous mail you wrote: Although the use of this routing protocol (*) still requires configured tunnels to be established it does allow the propogation of routing information between domains. Its wider use in the 6Bone network could perhaps be discussed in parallel to the dialogue surrounding RIP. (*) = IDRPv6 => there are three solutions for the dynamic routing of the 6 bone: - RIPv6 but RIPv6 doesn't scale (remember DVMRP) and is not specified for the usage over tunnels. Obviously RIPv6 is a cheap protocol for the routing inside an IPv6 cloud (OSPFv6 has the same problem and is not cheap or available). - IDRPv6 but it is not available on all the platforms, the draft is not finished, etc... : it is not yet ready. I believe it is the good long term solution then we should test it ASAP but it is not possible to deploy it before many months. - the last solution is to consider the Internet as a NBMA and to use NHRP. If you look at one of the maps of the 6 bone you can understand a tool is hardly needed and both the short-cut facility and a server tree (a level smaller and easier to manage) are good things. I don't believe we can get all this stuff running in a few days then we have to do a choice (the same one :-) ASAP... Francis.Dupont@inria.fr PS: perhaps we should create a 6bone IETF WG or to resume the TACIT WG (one of the T of TACIT are for "tests" :-) ? From rja@cisco.com Wed Sep 11 17:05:16 1996 From: rja@cisco.com (Ran Atkinson) Date: Wed, 11 Sep 1996 09:05:16 PDT Subject: 6Bone routing In-Reply-To: Francis Dupont "Re: 6Bone Mail" (Sep 11, 4:37pm) Message-ID: <199609111605.JAA08401@puli.cisco.com> 6bone-router.cisco.com contains a full routing table. It also has a fairly large number of tunnels. It is managed by me in free time while waiting for builds and such like. The current 6bone is easily managed by humans using static routing. There is no immediate need to move to any routing protocol. Later this year or early next year, when there is more of a need, then it will begin to make sense to start using a routing protocol. There has been agreement that RIP for IPv6 will be the routing protocol initially used. I agree with that decision. It is not a permanent answer but it will provide a good testing vehicle and meet the needs for some while. According to someone close to the IDRPv2 spec, that spec is not yet stable so it is certainly premature to be considering deploying that at the current time. Down the road, yes, it should be considered. However, I do not view that as a sensible approach in the near-term. Ran rja@cisco.com -- From dhaskin@baynetworks.com Wed Sep 11 17:21:51 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Wed, 11 Sep 96 12:21:51 EDT Subject: 6Bone Mail Message-ID: <9609111621.AA16941@pobox.BayNetworks.com> > From: Francis Dupont > => there are three solutions for the dynamic routing of the 6 bone: > - RIPv6 but RIPv6 doesn't scale (remember DVMRP) and is not specified > for the usage over tunnels. How come? Why should RIPv6 work differently over tunnels? As I see it, tunnel is just an instance of 'normal' point-to-point interface. The fact that IPv6 packets are encapsulated into IPv4 frames at link layer should not matter at network layer. Do you tweak your network protocols for each meadia it may run over? I don't. Here at Bay we have a generic RIPv6 implementation which runs over tunnels as specified -- the same way it runs over other types of links. > Obviously RIPv6 is a cheap protocol > for the routing inside an IPv6 cloud (OSPFv6 has the same problem > and is not cheap or available). > - IDRPv6 but it is not available on all the platforms, the draft > is not finished, etc... : it is not yet ready. I believe it is > the good long term solution then we should test it ASAP but > it is not possible to deploy it before many months. > - the last solution is to consider the Internet as a NBMA > and to use NHRP. If you look at one of the maps of the 6 bone > you can understand a tool is hardly needed and both the short-cut > facility and a server tree (a level smaller and easier to manage) > are good things. NHRP is not a routing protocol. Are you proposing to confine 6bone to a single LIS so no routing would be necessary? > > I don't believe we can get all this stuff running in a few days > then we have to do a choice (the same one :-) ASAP... > > Francis.Dupont@inria.fr > > PS: perhaps we should create a 6bone IETF WG or to resume the TACIT WG > (one of the T of TACIT are for "tests" :-) ? > Dimitry From ganis@VNET.IBM.COM Wed Sep 11 17:47:48 1996 From: ganis@VNET.IBM.COM (Matthew R. Ganis (914) 684-4575) Date: Wed, 11 Sep 96 12:47:48 EDT Subject: ipv6 addresses Message-ID: <199609111647.AA25917@venera.isi.edu> Who is allocating ipv6 addresses ?? We're starting to bring up some ipv6 machines in our lab, get some experience, and then attempt to connect to the 6-bone. I'd like to get some officially assigned addresses now thanks, Matt Ganis - ganis@vnet.ibm.com *********************************************************************** "The best way to get praise | Return Address: is to die" | IBM VNET: GANIS at RHQVM19 Italian Proverb | Internet: ganis@vnet.ibm.com | IPNET: ganis@bacchus.ims.advantis.com From meyer@network-services.uoregon.edu Wed Sep 11 18:15:55 1996 From: meyer@network-services.uoregon.edu (David M. Meyer 541/346-1747) Date: Wed, 11 Sep 1996 10:15:55 -0700 Subject: ipv6 addresses In-Reply-To: ganis@vnet.ibm.com's message of Wed, 11 Sep 1996 12:47:48 -0400. <199609111647.AA25917@venera.isi.edu> Message-ID: <199609111715.KAA13437@wayback.uoregon.edu> Matt, My understanding is that everyone should be using RFC1897 (test) addressing. Dave -- -------------- David M. Meyer Voice: +1 541.346.1747 Director Cellular: +1 541.954.1103 Advanced Network Technology Center SkyPager: +1 888.691.7491 University Computing FAX: +1 541.346.4397 Computing Center Internet: meyer@ns.uoregon.edu University of Oregon URL: http://ns.uoregon.edu/~meyer 1225 Kincaid Eugene, OR 97403 PGP Fingerprint 9A 79 2B 07 9A D1 81 45 1A 99 74 59 4F A0 3E 43 From dino@cisco.com Wed Sep 11 18:23:40 1996 From: dino@cisco.com (Dino Farinacci) Date: Wed, 11 Sep 1996 10:23:40 -0700 Subject: 6Bone Mail In-Reply-To: <199609111437.QAA03759@givry.inria.fr> (message from Francis Dupont on Wed, 11 Sep 1996 16:37:48 +0200) Message-ID: <199609111723.KAA01887@stilton.cisco.com> >> => there are three solutions for the dynamic routing of the 6 bone: I say there is four. - Use static routing. Build a backbone of nodes so most connected (tail) sites use prefix 0/0 to get to the backbone. Their tunnel endpoint routers are configured with a /64 for the site (and other sites they connect). The backbone routers pass around /32 (routes on AS numbers only). This should hold us for a long time until the specs are stable. Dino From dino@cisco.com Wed Sep 11 18:44:02 1996 From: dino@cisco.com (Dino Farinacci) Date: Wed, 11 Sep 1996 10:44:02 -0700 Subject: ipv6 addresses In-Reply-To: <199609111715.KAA13437@wayback.uoregon.edu> (meyer@network-services.uoregon.edu) Message-ID: <199609111744.KAA02937@stilton.cisco.com> >> My understanding is that everyone should be using RFC1897 (test) >> addressing. That is, you can choose your own address but the high-order byte must be 0x5f and you must conform to the RFC 1897 format. Here is an example from 6bone-router.cisco.com. There is an ethernet and fddi ring running IPv6: 6bone-router>sh ipv route con IPv6 Routing Table - 26 entries Codes: C - Connected, L - Local, S - Static Timers: Uptime/Expires C 5F00:6D00:C01F:0700/80 [0/0] via 5F00:6D00:C01F:0700::0060:3E11:6772, Fddi0, 2d02h/never C 5F00:6D00:C01F:0700:0001/80 [0/0] via 5F00:6D00:C01F:0700:0001:0060:3E11:6770, Ethernet0, 2d02h/never The next-hop (after via) is the router's IPv6 address on the respective interface. We use a /80 for those interfaces. Dino From cmetz@inner.net Wed Sep 11 18:45:06 1996 From: cmetz@inner.net (Craig Metz) Date: Wed, 11 Sep 1996 13:45:06 -0400 Subject: 6Bone Mail In-Reply-To: Your message of "Wed, 11 Sep 1996 10:23:40 PDT." <199609111723.KAA01887@stilton.cisco.com> Message-ID: <199609111745.RAA00860@inner.net> In message <199609111723.KAA01887@stilton.cisco.com>, you write: >>> => there are three solutions for the dynamic routing of the 6 bone: > > I say there is four. > > - Use static routing. Build a backbone of nodes so most connected (tail) > sites use prefix 0/0 to get to the backbone. Their tunnel endpoint > routers are configured with a /64 for the site (and other sites they > connect). The backbone routers pass around /32 (routes on AS numbers > only). > > This should hold us for a long time until the specs are stable. This is exactly what is being done now, and it works just fine. I will make one critical correction, however: leaves should use a "default" route of 5f00::0/8 to help prevent implementation bugs from causing bogon (multicast, link-local, IPv4-compatible, etc.) addresses from going down tunnels. -Craig From dino@cisco.com Wed Sep 11 18:49:41 1996 From: dino@cisco.com (Dino Farinacci) Date: Wed, 11 Sep 1996 10:49:41 -0700 Subject: 6Bone Mail In-Reply-To: <199609111745.RAA00860@inner.net> (message from Craig Metz on Wed, 11 Sep 1996 13:45:06 -0400) Message-ID: <199609111749.KAA03233@stilton.cisco.com> >> I will make one critical correction, however: leaves should use a >> "default" route of 5f00::0/8 to help prevent implementation bugs from causing >> bogon (multicast, link-local, IPv4-compatible, etc.) addresses from going down >> tunnels. Well for the reason you state, I would use 0/0 so we can find those bugs. Dino From Francis.Dupont@inria.fr Wed Sep 11 19:01:14 1996 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Wed, 11 Sep 1996 20:01:14 +0200 Subject: 6Bone Mail In-Reply-To: Your message of Wed, 11 Sep 1996 12:21:51 EDT. <9609111621.AA16941@pobox.BayNetworks.com> Message-ID: <199609111801.UAA04456@givry.inria.fr> In your previous mail you wrote: > From: Francis Dupont > => there are three solutions for the dynamic routing of the 6 bone: > - RIPv6 but RIPv6 doesn't scale (remember DVMRP) and is not specified > for the usage over tunnels. How come? Why should RIPv6 work differently over tunnels? => it is not clear if a tunnel is an interface (with what kind of properties) and RIPv6 doesn't manage half connectivity. DVMRP is a distance vector routing protocol with special hooks for tunnel and is not the good solution for the Mbone. I believe we should avoid the same error... As I see it, tunnel is just an instance of 'normal' point-to-point interface. => have tunnels link-local addresses (interface => link-local address according to RFCs) ? Are tunnels point-to-point or NBMA ? How the "multicast" is done on tunnels ? It is not so clear. The fact that IPv6 packets are encapsulated into IPv4 frames at link layer should not matter at network layer. Do you tweak your network protocols for each meadia it may run over? I don't. => RIPv6 is specified for LANs (in the mind of its authors). Here at Bay we have a generic RIPv6 implementation which runs over tunnels as specified -- the same way it runs over other types of links. => do you detect half tunnels ? Do you aggregate prefixes ? RIPv6 is a cheap solution but I am not convinced it is the best today, NHRP is a good candidate too. NHRP is not a routing protocol. Are you proposing to confine 6bone to a single LIS so no routing would be necessary? => yes because we have a global connectivity on the Internet then no intermediate routers are needed between clouds... We need NHRP for other NBMAs too. > PS: perhaps we should create a 6bone IETF WG or to resume the TACIT WG > (one of the T of TACIT are for "tests" :-) ? => I still think we need a WG for the future of 6bone (and not mix it with immediate operational issues). Regards Francis.Dupont@inria.fr From Francis.Dupont@inria.fr Wed Sep 11 19:21:00 1996 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Wed, 11 Sep 1996 20:21:00 +0200 Subject: 6Bone Mail In-Reply-To: Your message of Wed, 11 Sep 1996 10:23:40 PDT. <199609111723.KAA01887@stilton.cisco.com> Message-ID: <199609111821.UAA04488@givry.inria.fr> In your previous mail you wrote: >> => there are three solutions for the dynamic routing of the 6 bone: I say there is four. - Use static routing. Build a backbone of nodes so most connected (tail) sites use prefix 0/0 to get to the backbone. Their tunnel endpoint routers are configured with a /64 for the site (and other sites they connect). The backbone routers pass around /32 (routes on AS numbers only). This should hold us for a long time until the specs are stable. => I can see two problems with this : - the AS number space is flat then we'll get a large number of static routes on the backbone boxes. We can develop special tools but we have limited man-power... - if you have a backbone everybody want to be in it. It is (too) human, if you don't believe me tell me what is the backbone router for the USA! Static routing still works today then we should think about next steps... Regards Francis.Dupont@inria.fr From W. Richard Stevens" A couple of other things to think about, when joining the 6bone, from recent experience. - You'll need a nameserver that understands AAAA records, along with secondaries that also understand these. I think a lot of people are making an ipv6 subdomain that they then get delegated to themselves within their organization for this. (I just upgraded my nameserver to BIND-4.9.4 but then have to change secondaries from my ISP, to a secondary that understands AAAA records.) - Don't forget the ip6.int delegation for reverse mapping. Bill Manning (bmanning@isi.edu) is doing these and he allocates them with a /32, so you need to coordinate this with whoever in your organization is responsible for your ASN. Rich Stevens From dhaskin@baynetworks.com Wed Sep 11 20:03:16 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Wed, 11 Sep 96 15:03:16 EDT Subject: 6Bone Mail Message-ID: <9609111903.AA25382@pobox.BayNetworks.com> > From Francis.Dupont@inria.fr Wed Sep 11 14:01:54 1996 > > > From: Francis Dupont > > => there are three solutions for the dynamic routing of the 6 bone: > > - RIPv6 but RIPv6 doesn't scale (remember DVMRP) and is not specified > > for the usage over tunnels. > > How come? Why should RIPv6 work differently over tunnels? > > => it is not clear if a tunnel is an interface (with what kind > of properties) and RIPv6 doesn't manage half connectivity. > DVMRP is a distance vector routing protocol with special hooks > for tunnel and is not the good solution for the Mbone. > I believe we should avoid the same error... > A statuc tunnel is an interface with the same properties as any other point-to-point interface/link. It has its own L2 encapsulation scheme, i.e. IPv4 header (or IPv6 header for IPv6-in-IPv6 tunnels). That is all to it. The RIPv6 problem that it does not manage half connectivity is not confound to p-to-p/tunnel links. The same problem exists on broadcast links -- e.g., you can have a bad Ethernet port that can transmit but does not receive. ND's NUD can help somewhat here (yes, on tunnels too). > As I see it, tunnel is just an instance of 'normal' point-to-point interface. > > => have tunnels link-local addresses (interface => link-local address > according to RFCs) ? They better have. My tunnels have. >Are tunnels point-to-point or NBMA ? Static tunnels are point-to-point. I guess you can play NBMA games with tunnels too but I don't see any point in it except making things much more complex than they ought to be. > How the "multicast" is done on tunnels ? It is not so clear. This is trivial -- there is only one recipient of multicast traffic over a tunnel (the same as a broadcast link with only two stations attached). > The fact that IPv6 packets are encapsulated into IPv4 frames at > link layer should not matter at network layer. Do you tweak > your network protocols for each meadia it may run over? I don't. > > => RIPv6 is specified for LANs (in the mind of its authors). > Not in the mind of a reader? :) > Here at Bay we have a generic RIPv6 implementation which runs over tunnels > as specified -- the same way it runs over other types of links. > > => do you detect half tunnels ? We can use NUD for that. I aggree that is may not be a perfect solution but as, I said, the problem is non confound to tunnels. >Do you aggregate prefixes ? If the routing policy say so? What is has to do with tunnels? > RIPv6 is a cheap solution but I am not convinced it is the best > today, NHRP is a good candidate too. > RIPv6 will be the most commonly avalable solution for dynamic IPv6 routing in a short run. > NHRP is not a routing protocol. Are you proposing to confine 6bone > to a single LIS so no routing would be necessary? > > => yes because we have a global connectivity on the Internet > then no intermediate routers are needed between clouds... > We need NHRP for other NBMAs too. > This going to be one monstrous LIS :) It will not scale and the most of all it is not needed. > > PS: perhaps we should create a 6bone IETF WG or to resume the TACIT WG > > (one of the T of TACIT are for "tests" :-) ? > > => I still think we need a WG for the future of 6bone > (and not mix it with immediate operational issues). > > Regards > > Francis.Dupont@inria.fr > Regards, Dimitry From crawdad@fnal.gov Wed Sep 11 20:19:51 1996 From: crawdad@fnal.gov (Matt Crawford) Date: Wed, 11 Sep 1996 14:19:51 -0500 Subject: 6Bone Mail In-Reply-To: "11 Sep 1996 10:23:40 PDT." <"199609111723.KAA01887"@stilton.cisco.com> Message-ID: <199609111919.OAA16707@munin.fnal.gov> > I [Dino] say there are four. > - Use static routing. Build a backbone of nodes so most connected (tail) > sites use prefix 0/0 to get to the backbone. Their tunnel endpoint > routers are configured with a /64 for the site (and other sites they > connect). The backbone routers pass around /32 (routes on AS numbers > only). That's exactly what FNAL is doing, with ESNET as the provider, with the modification that since I'm using a /16 IPv4 address in my RFC1897 template, I have a /48 IPv6 prefix. And note that I did indeed select 0::/0 as my default route to the provider, rather than 5f00::/8. Matt From Francis.Dupont@inria.fr Wed Sep 11 20:51:15 1996 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Wed, 11 Sep 1996 21:51:15 +0200 Subject: 6Bone Mail In-Reply-To: Your message of Wed, 11 Sep 1996 15:03:16 EDT. <9609111903.AA25382@pobox.BayNetworks.com> Message-ID: <199609111951.VAA04670@givry.inria.fr> Obviously there are very different ways to see tunnels (:-)! It is not a problem with an exception: the NUD detection. This issue has already been discussed but without a conclusion (no agreement). Francis.Dupont@inria.fr From dino@cisco.com Wed Sep 11 20:51:45 1996 From: dino@cisco.com (Dino Farinacci) Date: Wed, 11 Sep 1996 12:51:45 -0700 Subject: 6Bone Mail In-Reply-To: <199609111821.UAA04488@givry.inria.fr> (message from Francis Dupont on Wed, 11 Sep 1996 20:21:00 +0200) Message-ID: <199609111951.MAA13307@stilton.cisco.com> >> - the AS number space is flat then we'll get a large number of >> static routes on the backbone boxes. We can develop special tools >> but we have limited man-power... That is because the 6bone is using RFC1897. >> - if you have a backbone everybody want to be in it. It is (too) human, >> if you don't believe me tell me what is the backbone router for the USA! >> Static routing still works today then we should think about next steps... Right, so what. The ones that connect to it will be 2nd tier nodes. If they don't want to provide 2nd tier service, they don't tunnel with a backbone router. They tunnel with a 2nd tier node. Making the tunnel topology hierarchical from the start will avoid the constant entropy of meshing. I know this may be hard to enforce but backbone router tunnel subscriptions can be denied for tail users. If you don't understand what I mean. Just use the model that NSFnet had. One backbone with many regionals attaching to it. Then sites only attached to the regionals. It works and proved to scale to a specific size. Dino From dino@cisco.com Wed Sep 11 21:01:09 1996 From: dino@cisco.com (Dino Farinacci) Date: Wed, 11 Sep 1996 13:01:09 -0700 Subject: 6Bone Mail In-Reply-To: <9609111903.AA25382@pobox.BayNetworks.com> (dhaskin@baynetworks.com) Message-ID: <199609112001.NAA13678@stilton.cisco.com> >> RIPv6 will be the most commonly avalable solution for dynamic IPv6 routing >> in a short run. True. Then we should have the backbone routers that route on /32s pass them around with RIPv6. The 2nd tier routers and site routers still use static. Dino From meyer@network-services.uoregon.edu Wed Sep 11 21:17:12 1996 From: meyer@network-services.uoregon.edu (David M. Meyer 541/346-1747) Date: Wed, 11 Sep 1996 13:17:12 -0700 Subject: 6Bone routing looop [Was: Re: 6Bone Mail] Message-ID: <199609112017.NAA14168@wayback.uoregon.edu> Timely discussion. There there appears to be a routing loop between cisco-6bone-router (5F00:6D00:C01F:0700:0001:0060:3E11:6770) and netlag-chunnel (5F10:8800:C7AB:1500:0001::0001) Dave From rja@cisco.com Wed Sep 11 21:43:02 1996 From: rja@cisco.com (Ran Atkinson) Date: Wed, 11 Sep 1996 13:43:02 PDT Subject: 6Bone routing loop In-Reply-To: "David M. Meyer 541/346-1747" "6Bone routing looop [Was: Re: 6Bone Mail]" (Sep 11, 1:17pm) Message-ID: <199609112043.NAA09813@puli.cisco.com> Dave, You'll need to provide more data to me (perhaps offline so as not to disturb everyone else). I just checked and things seem fine from 6bone-router's perspective (details appended). Ran rja@cisco.com >From sho ipv6 route: S 5F10:8800/32 [1/0] via 0::0, Tunnel5, 2d05h/never >From traceroute ipv6 netlag-chunnel: Tracing the route to netlag-chunnel (5F10:8800:C7AB:1500:0001::0001) 1 netlag-chunnel (5F10:8800:C7AB:1500:0001::0001) 308 msec 296 msec 284 msec >From ping ipv6 netlag-chunnel: Sending 5, 100-byte ICMP Echos to 5F10:8800:C7AB:1500:0001::0001, timeout is 2 seconds: !!!.! Success rate is 80 percent (4/5), round-trip min/avg/max = 304/310/320 ms -- From bound@zk3.dec.com Thu Sep 12 00:01:25 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 11 Sep 96 19:01:25 -0400 Subject: 6Bone Mail In-Reply-To: Your message of "Wed, 11 Sep 96 13:01:09 PDT." <199609112001.NAA13678@stilton.cisco.com> Message-ID: <9609112301.AA26408@fwasted.zk3.dec.com> My two cents on this discussion. 1. I think NHRP is a bad idea per Francis. As Dimitry pointed out treating the 6bone as a LIS is not worthy of what I think its purpose is for presently. From a networking computer science perspective though tunnels are NBMA like, but a network 6bone tunnel to connect should not take on the semantics and limitations of NBMA or advantages its just a tunnel folks. 2. I think Dino's idea of static routes is a good one but agree with Craig on 5f00/8, as 0/0 just sends everything and I don't want to debug accidents in forwarding but only IPv6 configuration or prefix errors. But I think we need a mechanism a.s.a.p. to discover tunnels between two links connected by a router when one of the routers is an IPv4 node in the way between two IPv6 islands. I think hard conifguring this is going to be a pain real soon. Mike Shand had an idea and so do I so will connect with Mike off line. I prefer it not affecting RIPv6 but I think it might have too. 3. We also should not constrain again I say the 6bone and leave it open to any who want to forward packets. I already fear Czars who think they might own routing in a particular region in the context of some mail. Well just like in real life this will not fly. We need to be prepared for a very complicated topology where different sites will route packets based on some relationship unforseen at this point. No Czars. In addition folks who build routers and forwarding code in Hosts will want to test their implementation too. 4. This SHOULD NOT be an IETF activity. If we find an error in the IPv6 portfolio of specifications then we need to take that back to the IETF. Lets not get bogged down in a standards game as we evolve the 6bone. /jim From bound@zk3.dec.com Thu Sep 12 00:11:07 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 11 Sep 96 19:11:07 -0400 Subject: ipv6 addresses In-Reply-To: Your message of "Wed, 11 Sep 96 12:47:48 EDT." <199609111647.AA25917@venera.isi.edu> Message-ID: <9609112311.AA26778@fwasted.zk3.dec.com> >Who is allocating ipv6 addresses ?? We're starting to bring up >some ipv6 machines in our lab, get some experience, and then attempt >to connect to the 6-bone. I'd like to get some officially assigned >addresses now I for one took your message that you knew about RFC 1897 and want a "real" IPv6 address. For now to play 1897 will work. But this has come up before and a real issue for some end users today and I believe a lot within 1 year. The draft on the table that solves this problem is as follows: "An IPv6 Provider-Based Unicast Address Format", Y. Rekhter, P. Lothberg, R. Hinden,, 04/03/1996, The problem is that if you read it there is a place to define the registry bits and that requires some kind of international coordination with IANA and algorithm so it can move to Proposed Standard. People are working on it and I think it should be a topic of discussion at the IPng meeting in San Jose Dec 1996. This needs to get fixed and done a.s.a.p. We already have some folks who have annouced real IPv6 products (and I predict a lot more will by March 1997) and customers are going to buy them. Now we need real IPv6 addresses for them. This 1897 strategy is not going to fly with the buying public. /jim From cmetz@inner.net Thu Sep 12 21:27:45 1996 From: cmetz@inner.net (Craig Metz) Date: Thu, 12 Sep 1996 16:27:45 -0400 Subject: First (and early) version of v6tools Message-ID: <199609122027.UAA02233@inner.net> I'm making a few (currently two, but there are more on the way) IPv6- capable tools I've written available for anonymous ftp on ftp.ipv6.inner.net. The first tool, v6wrapper, is a minimal moral equivalent to tcp_wrappers -- it allows you to run different daemons and/or reject a connection based on service and address criteria. The second, addrform, is a simple program designed to be used with v6wrapper that uses the IPV6_ADDRFORM setsockopt() to up/downgrade a socket. Note that this ftp server is only reachable from the 6bone. If you don't have routing set up that would allow you to reach the server, please drop me a note. -Craig From bound@zk3.dec.com Fri Sep 13 16:26:24 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Fri, 13 Sep 96 11:26:24 -0400 Subject: FYI IPv6 Next Interoperability Event Message-ID: <9609131526.AA24972@fwasted.zk3.dec.com> Just to let you know this will be just before the next IETF meeting. WOuld be nice to see those on the 6bone whose implementations have not been at "any" bake-offs to show up and really test your code you can't do this on the 6bone. /jim ------- Forwarded Message Return-Path: owner-ipng@sunroof.eng.sun.com Received: from hunch.zk3.dec.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31645; Fri, 13 Sep 1996 08:04:19 -0400 Received: from mail12.digital.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA10202; Fri, 13 Sep 1996 08:04:16 -0400 Received: from mercury.Sun.COM by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id HAA24209; Fri, 13 Sep 1996 07:58:24 -0400 (EDT) Received: by mercury.Sun.COM (Sun.COM) id EAA10070; Fri, 13 Sep 1996 04:46:41 -0700 Received: from sunroof.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA25126; Fri, 13 Sep 1996 04:46:32 -0700 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04950; Fri, 13 Sep 96 04:51:34 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04944; Fri, 13 Sep 96 04:51:21 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA25099; Fri, 13 Sep 1996 04:45:38 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA09972; Fri, 13 Sep 1996 04:45:39 -0700 Received: from whitec.sr.unh.edu by unh.edu with SMTP id AA26524 (5.67b+/IDA-1.5 for <@unh.edu:ipng@sunroof.Eng.Sun.COM>); Fri, 13 Sep 1996 07:45:36 -0400 Received: by whitec.sr.unh.edu (940816.SGI.8.6.9/921111.SGI) for ipng@sunroof.Eng.Sun.COM id HAA28006; Fri, 13 Sep 1996 07:49:12 -0400 Date: Fri, 13 Sep 1996 07:49:12 -0400 From: Bill.Lenharth@unh.edu (William Lenharth) Message-Id: <199609131149.HAA28006@whitec.sr.unh.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 2101) Dec '96 - IPv6 test period X-Status: N X-Mailer: Applixware 4.0(429.85) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk UNH will hold it's third IPv6 test Period on Dec 1 - 5, 1996 at the New England Center in Durham, NH. Due to space restrictions that test period will be held at the New England Center for Continuing Education with setup to on Sunday the first of December and teardown to complete at 6pm on Thursday. We are sorry for any inconvience that this may cause and UNH personnel will be available to prestage your equipment on Sunday. The test period will cost $1250.00 for non-members and there will be a nominal charge for members to cover the increased food costs at the New England Center. Please check our Web page for updates and advisory information. We advise reserving rooms at the NEC early. We look foreward to seeing you here in sunny New Hampshire. William Lenharth - ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com ------- End of Forwarded Message From RLFink@lbl.gov Sat Sep 14 16:21:53 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Sat, 14 Sep 1996 08:21:53 -0700 Subject: Geographically-based 3D map In-Reply-To: <9609071443.ZM26132@rennsport.nas.nasa.gov> Message-ID: Andrew, >There is now a geographically-based map available on the WWW. Using tools >borrowed from the Mbone visualization, we at NAS have come up with a VRML >model >of the 6bone with all the tunnels that we could find represented. The URL f= or >the new map is: > >http://www.nas.nasa.gov/NAS/Groups/netops/IPv6/viz/index.html > >There are static GIFs available as well, for those without VRML browsers. I= am >still missing IPv4 endpoints for U of Oregon and KEK/JP (I guessed on KEK).= If >anyone can provide those to me I will add them to the map. Looks very neat, thanks for doing it. I will add a pointer to it from the 6bone web page. >In the near future, we hope to publish a database of the available tunnels = and >allow for everyone to update it themselves. This hopefully will provide the >most current repository for sites and contacts. Can you say more about the general intent of this database in comparison to Geert Jan's. Thanks, Bob From a030058t@bcfreenet.seflin.lib.fl.us Sun Sep 15 05:02:33 1996 From: a030058t@bcfreenet.seflin.lib.fl.us (Richard Belanger) Date: Sun, 15 Sep 1996 00:02:33 -0400 (EDT) Subject: 6bone map - new tunnel from Cisco/US to UOregon/US In-Reply-To: Message-ID: I live in South Florida near Fort Lauderdale, what is my closest contact point to the mbone? Is it possible to reach a transmission speed of 100 kbd/s on a SLIP OR PPP connection for videoconferencing. I'm looking for an ISP thas has nationwide internet access by local number. a030058t@bcfreenet.seflin.lib.fl.us On Fri, 6 Sep 1996, Bob Fink LBNL wrote: > Dave Meyer caught me before I left! > > 6bone map version 14 (6 Sep 96) adds tunnels from Cisco/US to UOregon/US. > > Bob > > http://www-6bone.lbl.gov/6bone/ > > > ============ > To: Bob Fink LBNL > Subject: Re: no 6bone map changes till the 16th Sep > Date: Fri, 06 Sep 1996 08:33:09 -0700 > From: "David M. Meyer 541/346-1747" > > > Bob, > > The University of Oregon has just brought up a tunnel to > Cisco. Have a good trip (vacation, I hope). > > Thanks, > > Dave > - > > From bound@zk3.dec.com Sun Sep 15 18:56:59 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Sun, 15 Sep 96 13:56:59 -0400 Subject: UPDATE: Digital Alpha UNIX IPv6 X5.1A Kit and 6bone Sites In Process Message-ID: <9609151756.AA12555@fwasted.zk3.dec.com> Attached is a pointer to our updated kit if you want to use IPv6 or participate on the 6bone. If you pull the kit across would you send a message to bound@zk3.dec.com just letting me know you pulled the kit across. There is also a pointer to a kit for an IPv6 WWW Server/Client/Browser too. Also you can get prototypes running IPv6 for a Digital Switch and Router running RIPv6: DECSwitch900EF - (also known as WGE) - 1 FDDI, 6 Ethernet ports. DECSwitch900EE - (also known as WGE) - 7 Ethernet ports. RouteAbout Access - (also known as AW90) - 1 Ethernet, 2 WAN ports RouteAbout Central - (also known as AW900) - 2 Ethernet, 8 WAN ports Digital will be bringing up soon with some other partners a 6bone routing point in Palo Alto CA and Karlsrue Germany to add to the points of routability on the 6bone. These implementations have and will continue to participate in the UNH Interoperability Events and at the next Connectathon event too. We will be ready to test IPSEC using the PF_KEY API for security at the next UNH event and key management maybe depending on if the IETF makes that critical decision before Nov 15, 1996. It won't go into the kit until we test with our colleagues via other vendors and other implementors as interoperating with yourself is a very minor proofpoint when doing Internet engineering. You can also view our IPv6 WWW page at: http://www.digital.com/info/ipv6/ It is under-construction and I just updated the html and it should be completed by the time I get to Interop next week. There is a public IPv6 White Paper there too we are disseminating via one of the hot-buttons. have fun IPv6ing, /jim --------------------------------- The Digital UNIX IPV6 Prototype team is pleased to announce the availability of the latest IPV6 Binary kit for Digital UNIX V3.2C or V3.2D. This kit is available via Anonymous FTP at the following location: ftp://sipper.zk3-x.dec.com/pub/ipv6_binary_X5.1a.tar.Z Also available at this time is an IPv6 capable Web Server and Browser kit. The kit can be found at: ftp://sipper.zk3-x.dec.com/pub/ipv6_www_X5.1.tar.Z The kits are also available on the 6bone at sipper.ipv6.zk3-x.dec.com (5F0D:E900:CE98:A300::800:2B39:F505). The IPv6 for Digital UNIX kit supports the IPV6 base protocol and addressing specifications, along with ICMPv6, Stateless Address Autoconfiguration, Path MTU Discovery, and Neighbor Discovery. It is capable of acting as a BIND server for AAAA records, and of forwarding packets as a router (via static routes only). Also, it includes the BSD API specified in Internet Draft draft-ietf-ipngwg-bsd-api-05.txt, a Work in Progress. There are a few limitations which should be pointed out: - Limit of 1 LAN interface. Only a single Ethernet or FDDI interface is supported in this release, in addition to the loopback and tunnelling interfaces. - Incompatible with Digital UNIX V3.2C ATM options. Due to differences in the kernel networking infrastructure, this kit prevents the ATM options from being linked into the kernel. - Multi-processor (SMP) systems are not currently supported. Further details on the installation, configuration, and use of this kit can be found in the kit, in file /usr/share/ipv6/icu_guide.txt. The following notes are corrections or modifications which should be read carefully, as they may require user action to make the IPv6 kit function as described in the icu_guide.txt. 1. The ping6 and netstat6 utilities have incorrect permission settings. Please execute the following commands after running ip6_install: # chmod 4755 /usr/sbin/ping6 # chmod 4755 /usr/sbin/netstat6 2. In the icu_guide.txt, the description of adding an ARP entry is incorrect. It should read as follows: # route6 add -inet -host -link -interface # route6 add -inet -host 3.4.5.6 -link le0:08:00:2b:00:34:56 -interface 3. If using the BIND server, execute the following commands to insure that the proper image is started: # mv /sbin/named /sbin/named.DIST # ln -s /usr/sbin/named /sbin/named 4. The BIND example file /usr/share/ipv6/named.boot should be modified so that the system is not listed as the primary server for the IP6.INT domain. Finally, this kit is available for use and evaluation, but is not officially supported by Digital Equipment Corporation. Its use in a production environment would not be recommended. We would appreciate any and all feedback about features, bugs, or wishlist items, but we may not be able to respond to every mail. Please send your comments and suggestions to: mailto:ipv6-uproto-feedback@netrix.lkg.dec.com ------- End of Forwarded Message From jcday@jpd.ch.man.ac.uk Mon Sep 16 23:43:39 1996 From: jcday@jpd.ch.man.ac.uk (Jonathan Day) Date: Mon, 16 Sep 1996 23:43:39 +0100 (BST) Subject: Quick query Message-ID: <199609162243.XAA01662@jpd.ch.man.ac.uk> Hi Sorry if this is the wrong place to ask, but I was wondering where to get information on getting attached to the 6bone. (Problem #1 -- this computer is in the UK - not a place that features heavily in the information I've seen so far. Problem #2 -- Linux IPv6 code is getting on, but it isn't what you might call state-of-the-art.) Any suggestions (other than getting a decent machine :) would be welcome. Jonathan From RLFink@lbl.gov Tue Sep 17 01:03:58 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 16 Sep 1996 17:03:58 -0700 Subject: 6bone map - new tunnel from Cisco/US to UOregon/US In-Reply-To: References: Message-ID: At 9:02 PM -0700 9/14/96, Richard Belanger wrote: >I live in South Florida near Fort Lauderdale, what is my closest >contact point to the mbone? Is it possible to reach a transmission speed of >100 kbd/s on a SLIP OR PPP connection for videoconferencing. I'm looking >for an ISP thas has nationwide internet access by local number. =46or mbone info you should look at an mbone site: http://www.best.com/~prince/techinfo/mbone.html I can't help you on mbone beyond that. Thanks, Bob From RLFink@lbl.gov Tue Sep 17 02:19:48 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 16 Sep 1996 18:19:48 -0700 Subject: database of the available tunnels Message-ID: I had recently asked Andrew Hoag to elaborate on his comment about a database of the available tunnels and received the following reply, reposted here with his permission. Bob =3D=3D=3D=3D > >In the near future, we hope to publish a database of the available >tunnels and > >allow for everyone to update it themselves. This hopefully will provide t= he > >most current repository for sites and contacts. > > Can you say more about the general intent of this database in comparison t= o > Geert Jan's. After discussing this with others in our group here, and a gauge of general feelings I think I misspoke. I do not intend to replace or obsolete Geert Ja= n's effort in the IPv6 Registry... My original issue was that in producing this map I had to cull information f= rom not only his registry, but several other sources as well. I wanted the map t= o be as complete as possible. Since I had all of the information in one place,= I thought it made sense to make that info available. However, short of contacting each individual IPv6 site, I would be making th= at information available generally without their consent. Maybe this is not an issue, but at least with Geert Jan's Registry the parties involved have to actively make their site info public, whereis I would be doing it for them (= at least initially). In any case, I have decided to hold off on publishing what I already have. I may still build the tools or work with Geert Jan to improve them, but for th= e time being I think I'll leave it well enough alone. -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From RLFink@lbl.gov Tue Sep 17 02:33:46 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 16 Sep 1996 18:33:46 -0700 Subject: draft of some hookup info Message-ID: In an attempt to provide some of the most often asked info about hooking up to the 6bone I've created the following page: http://www-6bone.lbl.gov/6bone/6bone_hookup.html Before I refer to it from the 6bone home page, please take a look and comment (to the list please) so I can refine or rewrite :-) it. The 6bone home page now has a pointer to the neat NAS provided 3D geographic 6bone maps. I will continue to keep up the simple "bubble" diagram until it becomes too unwieldy to do so. Thanks, Bob From bound@zk3.dec.com Tue Sep 17 03:32:09 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 16 Sep 96 22:32:09 -0400 Subject: database of the available tunnels In-Reply-To: Your message of "Mon, 16 Sep 96 18:19:48 PDT." Message-ID: <9609170232.AA15700@fwasted.zk3.dec.com> Fine... Would all who would like to please send me: 1. your ipv4 address to reach your tunnel. 2. the IPv6 prefix to route to your tunnel 3. nodes inside your tunnel we can test our ipv6 apps against. there are other lists out there and one our node sipper was on WITH INCORRECT information about its capabilities and being sent only to those who are routing packets. This is just bogus and lets keep this an open process. Especially since the node was updated with new functionality and we had no way to even know to tell the Czar to update the freakin database. For those who want this to be a closed process lets not let them do that and if necessary we can set up a routing network around them. I don't want to hear about what the Mbone did anymore. Its not a production network after many years and IPv6 can wait that long. Have you seen the various meltdown news flashes on the Internet and how some small ISPs packets are getting blocked and even potentially being put out of business. 6bone needs to be wide open and lots of testing even if it breaks which is part of testing. It also should not be held up from growing exponentially. There is nothing wrong with multiple sites routing packets for everyones tunnels. In fact you may find eventually some folks route IPv6 throught the tunnels faster and in fact competition of this nature will foster better and high performining implementations (again unlike the Mbone). Anything I get will be published widely I will state up front. /jim From ahoag@nas.nasa.gov Tue Sep 17 04:28:12 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Mon, 16 Sep 1996 20:28:12 -0700 Subject: database of the available tunnels In-Reply-To: "Re: database of the available tunnels" (Sep 16, 10:32pm) References: <9609170232.AA15700@fwasted.zk3.dec.com> Message-ID: <9609162028.ZM4777@rennsport.nas.nasa.gov> > Fine... > > Would all who would like to please send me: > > 1. your ipv4 address to reach your tunnel. > 2. the IPv6 prefix to route to your tunnel > 3. nodes inside your tunnel we can test our ipv6 apps against. > > there are other lists out there and one our node sipper was on WITH > INCORRECT information about its capabilities and being sent only to > those who are routing packets. This is just bogus and lets keep this an > open process. Especially since the node was updated with new > functionality and we had no way to even know to tell the Czar to update > the freakin database. If enough people feel this would beneficial, I would be happy to "fg" my registry project and throw up a quick web page where people can add their own tunnels and maintain their own contact information. I would set it up in either a shared password format (to keep out the pranksters) or an approval-based format, but I would like the lowest latency updates as possible. > There is nothing wrong with multiple sites routing packets for everyones > tunnels. In fact you may find eventually some folks route IPv6 throught > the tunnels faster and in fact competition of this nature will foster > better and high performining implementations (again unlike the Mbone). > > Anything I get will be published widely I will state up front. > > /jim >-- End of excerpt from Well put! -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From rja@cisco.com Tue Sep 17 04:39:10 1996 From: rja@cisco.com (Ran Atkinson) Date: Mon, 16 Sep 1996 20:39:10 PDT Subject: connectivity data Message-ID: <199609170339.UAA09444@cornpuffs.cisco.com> While I share Jim's desire to get the connectivity spread widely among the sites sending/receiving 6bone traffic, might it not be worth an effort for everyone to send a current picture of their site to Geert Jan so that we can really get the RIPE database current ?? Ran rja@cisco.com -- From bound@zk3.dec.com Tue Sep 17 04:49:39 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 16 Sep 96 23:49:39 -0400 Subject: database of the available tunnels In-Reply-To: Your message of "Mon, 16 Sep 96 20:28:12 PDT." <9609162028.ZM4777@rennsport.nas.nasa.gov> Message-ID: <9609170349.AA19205@fwasted.zk3.dec.com> Andrew, Thats a good idea. Good point on pranksters too. I am off to Interop and then have to travel on other place but count me in once I get back and anything I can do to help I will. How would we work the passwds? or whatever? Not my forte.... thanks /jim From roque@di.fc.ul.pt Tue Sep 17 11:34:37 1996 From: roque@di.fc.ul.pt (Pedro Roque Marques) Date: Tue, 17 Sep 1996 11:34:37 +0100 Subject: database of the available tunnels In-Reply-To: <9609170232.AA15700@fwasted.zk3.dec.com> References: <9609170232.AA15700@fwasted.zk3.dec.com> Message-ID: <199609171034.LAA12250@oberon.di.fc.ul.pt> >>>>> "bound" == bound writes: bound> For those who want this to be a closed process lets not let bound> them do that and if necessary we can set up a routing bound> network around them. Jim, i do share your global connectivity goals but i believe that the main problem with the 6bone is that everybody has been "routing around them" from the start. And it is not working too well. We've have, as far as i understand, several groups that manage routing information with little or no coordination among them. It will be also useless to try to finger point people for the current state of afairs. Personally, i believe we all have our share of resposability on it. My proposal is that we stablish an informal set peering etiquete rules. bound> There is nothing wrong with multiple sites routing packets bound> for everyones tunnels. No, nothing wrong it that as long as routing information is consistent. I doubt that currently that will be the case. My proposal for peering rules: a) Either a site runs default only to it's peer or it should distribute, on every update, a copy of it's routing table to everybody that peers with it. The idea is that you can run a distance vector algorithm this way (we should agree on the format for this files so that we can run scripts on them). Better yet, we can add path information to the routes exported this way and you have, in essence, a path based routing algorithm. b) Non default sites should deposit regularly a copy of their routing table and peering information on a well known place (RIPE or whatever). c) A site should not limit trafic unless it clrearly states so in the published information mentioned in b) (allow * policy by default) bound> In fact you may find eventually bound> some folks route IPv6 throught the tunnels faster and in bound> fact competition of this nature will foster better and high bound> performining implementations (again unlike the Mbone). Ok agreed, but instead of spliting in a miriad of different groups can we try, at least once, to run *one* 6bone ? regards, Pedro. From RLFink@lbl.gov Tue Sep 17 14:52:31 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 17 Sep 1996 06:52:31 -0700 Subject: 6bone map change - new tunnel from NRL/US to NIST/US Message-ID: 6bone drawing version 15 (17 Sep 96) adds tunnel from NRL/US to NIST/US. Bob http://www-6bone.lbl.gov/6bone/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =46rom: Robert Glenn Date: Tue, 17 Sep 1996 08:27:37 -0400 (EDT) To: rlfink@lbl.gov Subject: NIST on the 6bone Cc: rob.glenn@nist.gov Bob, NIST (National Institute of Standards and Technology) is now on the 6bone. We are connected through NRL. NIST's routing prefix is 5f00:3100::/32. If you need anymore information please feel free to contact me. Thanks, Rob G. rob.glenn@nist.gov (301)975-3667 From GeertJan.deGroot@ripe.net Tue Sep 17 09:36:04 1996 From: GeertJan.deGroot@ripe.net (Geert Jan de Groot) Date: Tue, 17 Sep 1996 10:36:04 +0200 Subject: database of the available tunnels In-Reply-To: Your message of "Mon, 16 Sep 1996 22:32:09 EDT." <9609170232.AA15700@fwasted.zk3.dec.com> Message-ID: <199609170836.KAA00565@berklix.ripe.net> On Mon, 16 Sep 96 22:32:09 -0400 bound@zk3.dec.com wrote: > 1. your ipv4 address to reach your tunnel. > 2. the IPv6 prefix to route to your tunnel > 3. nodes inside your tunnel we can test our ipv6 apps against. The first two points are already registered at the registry at the NCC; I'm looking forward to see a proposal to do point 3 but have not heard anything yet. The comments on the 'FTP partking place' so far have been roughly: - A few people wanted gegraphical info (which I did), and some didn't want geographical data because it is too hard to obtain (that's why it's optional) - Some people had problems with the SITE GROUP/SITE GPASS thing, I think I answered all of them. > there are other lists out there and one our node sipper was on WITH > INCORRECT information about its capabilities and being sent only to > those who are routing packets. This is just bogus and lets keep this an > open process. Especially since the node was updated with new > functionality and we had no way to even know to tell the Czar to update > the freakin database. I don't know if this comment was for me but in that case please elaborate? Geert Jan From crawdad@fnal.gov Tue Sep 17 15:40:12 1996 From: crawdad@fnal.gov (Matt Crawford) Date: Tue, 17 Sep 1996 09:40:12 -0500 Subject: draft of some hookup info In-Reply-To: "16 Sep 1996 18:33:46 PDT." <"v03007812ae63af96e93a"@[128.3.9.22]> Message-ID: <199609171440.JAA09933@munin.fnal.gov> Bob, Could you add some emphasis to draw attention to the fact that an RFC1897 format address includes the ASN of one's provider, not an ASN that belongs to one's own site? (But of course a provider uses its own ASN.) Matt From RLFink@lbl.gov Tue Sep 17 15:56:49 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 17 Sep 1996 07:56:49 -0700 Subject: draft of some hookup info In-Reply-To: <199609171440.JAA09933@munin.fnal.gov> References: "16 Sep 1996 18:33:46 PDT." <"v03007812ae63af96e93a"@[128.3.9.22]> Message-ID: Matt, >Could you add some emphasis to draw attention to the fact that an >RFC1897 format address includes the ASN of one's provider, not an ASN >that belongs to one's own site? (But of course a provider uses its >own ASN.) Will do! Thanks, Bob From RLFink@lbl.gov Tue Sep 17 16:02:23 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 17 Sep 1996 08:02:23 -0700 Subject: draft of some hookup info In-Reply-To: <199609170800.KAA17884@faui40.informatik.uni-erlangen.de> References: from "Bob Fink LBNL" at Sep 16, 96 06:33:46 pm Message-ID: Erich, >> In an attempt to provide some of the most often asked info about hooking = up >> to the 6bone I've created the following page: >> >> http://www-6bone.lbl.gov/6bone/6bone_hookup.html >> >> Before I refer to it from the 6bone home page, please take a look and >> comment (to the list please) so I can refine or rewrite :-) it. > >Maybe you should add the diagram below taken from rfc1897 to the page and >maybe >provide an example. This eases figuring out the IPv6 address a lot. > > | 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 | > +---+----------+----------+---+------------+---+--------+-------+ Sounds good, I'll do it! Thanks, Bob From RLFink@lbl.gov Tue Sep 17 16:03:13 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 17 Sep 1996 08:03:13 -0700 Subject: draft of some hookup info In-Reply-To: <199609170305.WAA00871@nyarlathotep.netlag.com> References: from "Bob Fink LBNL" at Sep 16, 1996 06:33:46 PM Message-ID: Matt, >> In an attempt to provide some of the most often asked info about hooking = up >> to the 6bone I've created the following page: >> >> http://www-6bone.lbl.gov/6bone/6bone_hookup.html >> >> Before I refer to it from the 6bone home page, please take a look and >> comment (to the list please) so I can refine or rewrite :-) it. >> >It may be useful to include a list of organisations which are willing >to provide tunnel services, with information such as site contact >and tunnel server address with which performance characteristics >can be obtained, helping the fledgling find the "nearest" provider. >In the near future, it may be best to contact your upstream provider >to find if they offer such services (why i liked the prefix listing on >early 6bone maps). I, for example, would be willing to offer tunnels >to others, but would be less than optimal for all but the closest >organisations. This one is a little hard for me to do without help from others. If there is sufficient response to the list from folks willing to provide service, as well as providing me with this info, I will do it. Comments anyone on the value of this?? >One more note is that it has been suggested by several persons that >sites connect only to a single tunnel server, in order to prevent loops >in the current topology. I'll at least put a cautionary note in. Thanks, Bob From rja@cisco.com Tue Sep 17 17:41:57 1996 From: rja@cisco.com (Ran Atkinson) Date: Tue, 17 Sep 1996 09:41:57 PDT Subject: 6bone map from LBL Message-ID: <199609171641.JAA10294@cornpuffs.cisco.com> Bob, I personally would find it easier to verify my routing table completeness and accuracy if your map went back to its former self and included the "Routing Prefix" for each site and also added a "Ping Address" for each site. Others might also find this useful in keeping their tables current. It might also be useful if at some future data (say 1 October 96) the map were revised to ONLY include data from the RIPE database (one has to register with RIPE in order to show up on the LBL-maintained map). It would be useful if Kevin at NASA/Ames did the same thing with his map, IMHO. This small action would provide a very strong incentive for folks to keep their data current in the RIPE IPv6 database. By announcing this 10-14 days before the policy took effect, everyone would have time to get their data online at RIPE. The only objective is to strongly encourage folks to keep their data online at RIPE (which is open to everyone) and to encourage everyone to keep that data accurate. Best regards, Ran rja@cisco.com PS: I'll be updating cisco's entry at RIPE once Geert Jan has time to clarify some points that I'm confused about. :-) -- From RLFink@lbl.gov Wed Sep 18 01:47:24 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 17 Sep 1996 17:47:24 -0700 Subject: 6bone map from LBL In-Reply-To: <199609171641.JAA10294@cornpuffs.cisco.com> Message-ID: Ran, > I personally would find it easier to verify my routing table completeness >and accuracy if your map went back to its former self and included the >"Routing Prefix" for each site and also added a "Ping Address" for each sit= e. >Others might also find this useful in keeping their tables current. > > It might also be useful if at some future data (say 1 October 96) the map >were revised to ONLY include data from the RIPE database (one has to regist= er >with RIPE in order to show up on the LBL-maintained map). It would be usef= ul >if Kevin at NASA/Ames did the same thing with his map, IMHO. > > This small action would provide a very strong incentive for folks to keep >their data current in the RIPE IPv6 database. By announcing this 10-14 day= s >before the policy took effect, everyone would have time to get their data >online at RIPE. The only objective is to strongly encourage folks to keep >their data online at RIPE (which is open to everyone) and to encourage >everyone to keep that data accurate. I have been thinking along similar lines to use the map as way of getting folk to register (and hopefully keep current) their RIPE-NCC IPv6 db info. This would also be a good time to add back at least the "Routing Prefix" for each site and possibly the "Ping Address". Gee, if I got sophisticated, I could maybe have a click sensitive map that allowed you to click on the net and go directly to the RIPE-NCC IPv6 db entry. Rather than shoot for 1 October I would like to shoot for 1 Nov or 1 Dec for practical reasons. How do others on the list feel about this?? Thanks, Bob From RLFink@lbl.gov Wed Sep 18 14:54:26 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 18 Sep 1996 06:54:26 -0700 Subject: 6bone map change - new tunnel from UNI-C/DK to Telebit/DK Message-ID: 6bone drawing version 16 (18 Sep 96) adds tunnel from NRL/US to NIST/US. Overlooked it on Monday when I returned, sorry. Thanks. Bob http://www-6bone.lbl.gov/6bone/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Date: Wed, 18 Sep 1996 08:33:10 +0200 (METDST) =46rom: "Gudrun R. Dalgeir" To: Bob Fink LBNL Subject: Re: 6bone map change - new tunnel from NRL/US to NIST/US Mime-Version: 1.0 Bob, could you please update the map to include the new tunnel between UNI-C and Telebit. Cheers, ---------------- 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 bound@zk3.dec.com Wed Sep 18 15:39:39 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 18 Sep 96 10:39:39 -0400 Subject: database of the available tunnels In-Reply-To: Your message of "Tue, 17 Sep 96 10:36:04 +0200." <199609170836.KAA00565@berklix.ripe.net> Message-ID: <9609181439.AA22364@fwasted.zk3.dec.com> Geert, Comment was not for you fyi. If anyone iws maintianing data about nodes on the 6bone then all data regarding those nodes needs to be updated. That should be done by the owner of those nodes not a registry or backbone router. So if anyone has questions about a Digital node aske me. If you have question about cisco node ask Ran, etc etc... Thats my point. How to I get that file from NCC you spoke of that tells about 1 and 2 from previous mail.? I am at Interop as I write this mail (its slowwwww) and I am having trouble getting to nodes on the 6bone with my route for 0/0 or 5f00/8 going thru UNH. I can get to UNH and back and sipper.zk3-x.dec.com thru UNH and Bay Networks but no where else? But when I telnet6 into sipper I can get tall the 6bone nodes. I will call UNH Sebastien this a.m. Here are our v6 addrs you can tunnel too our router ::45.12.64.248 on the show floor. 5f00:2100:2d0c:4000:0c40:0000:f822:56e6 ni30 (ipv4 addr above is 45.12.64.230) 5f00:2100:2d0c:4000:0c40:0000:f822:64f4 ni31 (ipv4 addr above is 45.12.64.231) should be able to set up route as: 5F00:2100:2D0C:4000::/80 ::45.12.64.248 thanks /jim From qv@sparky.iol.unh.edu Wed Sep 18 17:00:52 1996 From: qv@sparky.iol.unh.edu (Quaizar Vohra) Date: Wed, 18 Sep 1996 12:00:52 -0400 Subject: database of the available tunnels In-Reply-To: <9609181439.AA22364@fwasted.zk3.dec.com> References: <199609170836.KAA00565@berklix.ripe.net> <9609181439.AA22364@fwasted.zk3.dec.com> Message-ID: <199609181600.MAA01756@sparky.IOL.UNH.EDU> > > I am at Interop as I write this mail (its slowwwww) and I am having > trouble getting to nodes on the 6bone with my route for 0/0 or 5f00/8 > going thru UNH. I can get to UNH and back and sipper.zk3-x.dec.com thru > UNH and Bay Networks but no where else? But when I telnet6 into sipper > I can get tall the 6bone nodes. I will call UNH Sebastien this a.m. > > > Here are our v6 addrs you can tunnel too our router ::45.12.64.248 on > the show floor. > > 5f00:2100:2d0c:4000:0c40:0000:f822:56e6 ni30 > (ipv4 addr above is 45.12.64.230) > > 5f00:2100:2d0c:4000:0c40:0000:f822:64f4 ni31 > (ipv4 addr above is 45.12.64.231) > > should be able to set up route as: > 5F00:2100:2D0C:4000::/80 ::45.12.64.248 > > thanks > /jim > > Jim. since you are using UNH as a provider :-), let me assign you a prefix which is covered by our 32 bit prefix 5f02:3000::/32. Just use 5f02:3000:84b1:7400::/64. You can further divide this prefix into subnets as you like, using the 65-80 bits as subnet identifier. I will set up a route for you and the rest of the world won't have to bother. This will require you to reassign addresses on all your nodes, which is something you can demonstrate as easily done by IPv6 :-) Regards, Quaizar From rob.glenn@nist.gov Wed Sep 18 17:33:16 1996 From: rob.glenn@nist.gov (rob.glenn@nist.gov) Date: Wed, 18 Sep 1996 12:33:16 -0400 (EDT) Subject: Question regarding RFC1897? Message-ID: <199609181633.MAA05421@sloth.ncsl.nist.gov> Now that I've been bitten by the majordomo "sender must be subscribed" feature, here is my third attempt at sending this... While setting up our internal networks and DNS with RFC1897 addresses, I became puzzled by the address format. Assuming that there are very good reasons to use the *providers* ASN, wouldn't it make more sense to use the IPv4 Network Address to represent the Network Address given to you by the provider? In other words If you have a class A address the IPv4 Network Address field would be 0x0000AA, class B address would be 0x00BBBB, and so on. Then the Subnet field could contain the remaining bits. As it is currently defined, it is difficult to setup reverse DNS records. Providers will have to maintain records for each IPv4 subnet that sites want to run with IPv6. Collisions may occur when sites don't work with their providers. Or in some cases, sites won't setup the reverse DNS just to avoid this problem. Ofcourse, if you use your own ASN, the problems go away. Rob G. rob.glenn@nist.gov From RLFink@lbl.gov Wed Sep 18 18:11:46 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 18 Sep 1996 10:11:46 -0700 Subject: hookup page now linked thru the 6bone page Message-ID: I've added the hookup page reference to the 6bone home page. This hookup page incorporates comments to date. Please continue with the suggestions! When you click the "here" button on the hookup page, for 6bone attachment locations, you will only find Cisco as Ran is the only one that has sent explicit info so far. So please take that as incentive to advertize your own site, including relevant info that might assist the 6bone attachee looking for where to "home". I would like to suggest that one's site must be registered in Geert Jan's RIPE-NCC 6bone registry to advertize in the hookup list. Thanks, Bob From bound@zk3.dec.com Wed Sep 18 21:31:54 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 18 Sep 96 16:31:54 -0400 Subject: 6bone map from LBL In-Reply-To: Your message of "Tue, 17 Sep 96 09:41:57 PDT." <199609171641.JAA10294@cornpuffs.cisco.com> Message-ID: <9609182031.AA12081@fwasted.zk3.dec.com> > I personally would find it easier to verify my routing table completeness >and accuracy if your map went back to its former self and included the >"Routing Prefix" for each site and also added a "Ping Address" for each site. >Others might also find this useful in keeping their tables current. Me too. In fact for every node on the map and address to ping too. Also if we could all set up anon ftp and dummy telnet for IPv6 that would be good too. If it won't fit on the map we need such a table for every node on the 6bone. /jim From RLFink@lbl.gov Wed Sep 18 23:21:19 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 18 Sep 1996 15:21:19 -0700 Subject: Adding UCLA to 6bone map. In-Reply-To: <199609181943.MAA18079@pelican.cs.ucla.edu> Message-ID: Jong, > I've been wondering why our UCLA IPv6 nodes are in the very cool >3-D VRML diagram, but not on your overview graph. We set up two hosts >running IPv6 tunneling through CISCO a couple of weeks ago, but there are >more to come in the near future. Could you please kindly add our UCLA/US >node to your 6bone map? If you need more information, please let me know >at your earliest convenience. Thank you. I believe that no one has told me that UCLA is up - could be wrong. The "cool" 3D maps (I like them too :-) happen to show more stuff because Andrew Hoag, of NAS, had gone to a lot of trouble to build a tunnel table. If he doesn't continue the effort into maintaining this list, his map will become out of date unless he is explicitly told what has been added/removed/etc. I will soon invoke the rule that Ran proposed, i.e., that everyone must register with the RIPE-NCC 6bone registry to be put on the map. This will eventually lead to the possibility of automatic map generation by all of us - as well as other benefits! So... why don't you register, please: ftp://ftp.ripe.net/ipv6/ip6rr/ Anyway, I'll add UCLA to the map as soon as possible. Thanks for mentioning this. Bob From RLFink@lbl.gov Wed Sep 18 23:40:46 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 18 Sep 1996 15:40:46 -0700 Subject: 6bone sites registered Message-ID: 6bone folk, The following 6bone sites are already registered in the RIPE-NCC 6bone Registry: CISCO ESNET FAUERN G6 JOGUNET JOIN NAS NETLAG RIPE-NCC SICS UNH UNI-C As has been discussed, it is best when everyone is registered so we can have necessary info for operation of the 6bone. Ran Atkinson has suggested that we soon move to a mode where we don't put as site on the map unless you it is registered. So...I would like to propose that the following 6bone sites register over the next month or so, then we agree on a cutoff and follow the no registry, no visibility rule (I think 1 December is a reasonable time frame). Bay DEC FNAL Inner KEK Merit NIST NRL Telebit Sun UCLA ULisboa UOregon WIDE/JP Also, can someone suggest a consistent rule for the tunnel entry in the database. Some have both ends, some just the far end, some just one tunnel, some many, some include names as well as ip address, etc. We need some consistency. I'm sure others have similar frustrations and opinions about other fields in the registry entry as well. So, if we are going to try to move to a "must register" rule, we should probably get clearer than we are now as to what must be there and what the format is. This will be very important as this gets bigger and we try to do automatic things (like maps and testing) with the data. Comments any and all! Thanks, Bob From ahoag@nas.nasa.gov Wed Sep 18 23:41:58 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Wed, 18 Sep 1996 15:41:58 -0700 Subject: Adding UCLA to 6bone map. In-Reply-To: Bob Fink LBNL "Re: Adding UCLA to 6bone map." (Sep 18, 3:21pm) References: Message-ID: <9609181541.ZM11769@rennsport.nas.nasa.gov> > Andrew Hoag, of NAS, had gone to a lot of trouble to build a tunnel table. That's true -- at least 30% of my upfront work was assembling some sort of comprehensive list of the current tunnels involved. > I will soon invoke the rule that Ran proposed, i.e., that everyone must > register with the RIPE-NCC 6bone registry to be put on the map. This will > eventually lead to the possibility of automatic map generation by all of us > - as well as other benefits! I agree and will back Bob & Ran up on this one. At some next interrupt, I will be removing tunnels from the geographic map if they are not so listed in the RIPE NCC IPv6 registry. I also suggest to Bob that you look at your section entitled "Registering with the routing registry" and strengthen your language to imply that registering with RIPE is highly recommended ("required" :-). > So... why don't you register, please: > > ftp://ftp.ripe.net/ipv6/ip6rr/ -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From RLFink@lbl.gov Wed Sep 18 23:56:09 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 18 Sep 1996 15:56:09 -0700 Subject: Adding UCLA to 6bone map. In-Reply-To: <199609182235.PAA08244@pelican.cs.ucla.edu> References: from "Bob Fink LBNL" at Sep 18, 96 03:21:19 pm Message-ID: Jong, > I'm glad you bring this up. Because I've been looking all over >for the "how to register" information on the 6bone web page. But I >couldn't find anything. I'm not sure if I'm the only one that has this >problem or not. But could you kindly show me the process to register? >For instance, first I should get an example registry and follow the style >to create my own. Then I should mail to ip6ops@ripe.net to gain access >to that directory and put my registry in? If that is the correct >process, could we just use some kind of web-form, so people can fill it >out right on his(her) web browser? Just a suggestion, but I think it >would simplify the registration process. Thank you for adding us to the >map. Good point. I'll see if I can work out something with Geert Jan. Thanks, Bob From ahoag@nas.nasa.gov Thu Sep 19 00:06:01 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Wed, 18 Sep 1996 16:06:01 -0700 Subject: 6bone sites registry In-Reply-To: Bob Fink LBNL "6bone sites registered" (Sep 18, 3:40pm) References: Message-ID: <9609181606.ZM11843@rennsport.nas.nasa.gov> > Also, can someone suggest a consistent rule for the tunnel entry in the > database. Some have both ends, some just the far end, some just one > tunnel, some many, some include names as well as ip address, etc. We need > some consistency. I'm sure others have similar frustrations and opinions > about other fields in the registry entry as well. My suggestion would be at least signify "src" and "dst" pairs -- whether for each tunnel you repeat the src, or you default to a one-to-many sort of list, that is negotiable. My personal preference would be to use src and dst pairs that were closely coupled. Geert Jan, would it be feasible to include this information within the "tunnel:" tag? e.g. tunnel: src 129.99.237.71 dst 192.31.7.41 Or would it be preferable (from the RIPE db standpoint) to have: tunnel-src: 129.99.237.71 tunnel-dst: 192.31.7.41 Also of note we've been using network abbreviations for most locations that have kind of evolved as handles -- e.g. UNH, NAS, Cisco, UNI-C, NETLAG ....etc. Is this a practice we would like to incorporate in some manner? It makes it easier for me to identify sites in a small amount of space and even in discussions most people use the abbreviations. e.g. site: NAS, NASA Ames Research Center site-handle: NAS In some cases the handle is obvious, but more than once when I site has been referred to by its full name I had to look it up to realize what handle we'd been referring to it as. -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From RLFink@lbl.gov Thu Sep 19 00:14:16 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 18 Sep 1996 16:14:16 -0700 Subject: 6bone sites registry In-Reply-To: <9609181606.ZM11843@rennsport.nas.nasa.gov> References: Bob Fink LBNL "6bone sites registered" (Sep 18, 3:40pm) Message-ID: Andrew, >site: NAS, NASA Ames Research Center >site-handle: NAS Just realized that I should fix the map to show you as NAS, not NASA-Ames. Thanks for all the other good words and input. Bob From bound@zk3.dec.com Thu Sep 19 00:09:38 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 18 Sep 96 19:09:38 -0400 Subject: 6bone sites registered In-Reply-To: Your message of "Wed, 18 Sep 96 15:40:46 PDT." Message-ID: <9609182309.AA28318@fwasted.zk3.dec.com> Bob, I will register Digital (please folks not DEC). I think all being on RIPE NCC will work good. If your not there then we don't know about you. On the tunnel topic. I am sitting here looking at the map. See the Cisco/US hub. See all the nodes its routing too. I will in the next month with another partner offer an additional tunnel to route to those same nodes and addtional nodes. Cisco and Digital wil be providing the same routing. I have given my reasons for this in other mail. I will also have a router to WIDE Japan and directly back to UNH bypassing NRL connection completely. p.s. Showing the 6bone page and map to Interop attendees they are all very impressed and with implementation status on IPng Page. thanks /jim From ahoag@nas.nasa.gov Thu Sep 19 01:12:45 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Wed, 18 Sep 1996 17:12:45 -0700 Subject: 6bone sites registry In-Reply-To: davidk@ISI.EDU "Re: 6bone sites registry" (Sep 18, 5:12pm) References: <199609190012.AA05277@nam.isi.edu> Message-ID: <9609181712.ZM11994@rennsport.nas.nasa.gov> > Also, it is often a good idea to add a version number and/or some > protocol information for easy upgrading to newer/better formats in order > to keep things backwards compatibility. > > Example: > > tunnel: IPv6 src 129.99.237.71 dst 192.31.7.41 Yes, of course you should include the version / protocol info for the tunnel. I like that format there. -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From RLFink@lbl.gov Thu Sep 19 01:17:35 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 18 Sep 1996 17:17:35 -0700 Subject: new 6bone diagram with hot pointers to RIPE-NCC registry Message-ID: I've made the 6bone map have hot buttons to the RIPE-NCC registry database. The shaded nodes are hot buttons, the blank ones have no registry. Hopefully this helps the folks who want more info on the map as well. Bob From Francis.Dupont@inria.fr Thu Sep 19 09:02:04 1996 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Thu, 19 Sep 1996 10:02:04 +0200 Subject: Question regarding RFC1897? In-Reply-To: Your message of Wed, 18 Sep 1996 12:33:16 EDT. <199609181633.MAA05421@sloth.ncsl.nist.gov> Message-ID: <199609190802.KAA19367@givry.inria.fr> In your previous mail you wrote: While setting up our internal networks and DNS with RFC1897 addresses, I became puzzled by the address format. Assuming that there are very good reasons to use the *providers* ASN, wouldn't it make more sense to use the IPv4 Network Address to represent the Network Address given to you by the provider? In other words If you have a class A address the IPv4 Network Address field would be 0x0000AA, class B address would be 0x00BBBB, and so on. Then the Subnet field could contain the remaining bits. => in the current RFC the network number are "big endiens", ie 0xAA0000, 0xBBBB00, 0xCCCCCC but it doesn't matter. As it is currently defined, it is difficult to setup reverse DNS records. Providers will have to maintain records for each IPv4 subnet that sites want to run with IPv6. Collisions may occur when sites don't work with their providers. Or in some cases, sites won't setup the reverse DNS just to avoid this problem. => I don't see any problem, you have just to work with your provider. It is already the case for IPv4 networks since CIDR... Don't forget for the reverse domains any reasonnable BIND version is enough because they use only PTR RRs. Ofcourse, if you use your own ASN, the problems go away. => which ASN ? You can have many ASN, the provider ASN is registered then without ambiguity. You have a better aggregation too (perhaps not as good as we'd like to get). Providers will be involved when you'll use the provider-based addressing scheme then I think it is a good thing to involve them without real burden today... Regards Francis.Dupont@inria.fr From GeertJan.deGroot@ripe.net Thu Sep 19 10:56:21 1996 From: GeertJan.deGroot@ripe.net (Geert Jan de Groot) Date: Thu, 19 Sep 1996 11:56:21 +0200 Subject: RIPE routing registry Message-ID: <199609190956.LAA00194@berklix.ripe.net> Hi folks, I'm a little slow on mail as there is a meeting of the RIPE community next week, and the RIPE NCC is organizing that meeting. As I'm getting more and more questions on how to get write access, I'll re-post the original announcement below. Basically, I'd like to make the directory completely public writable, but I am concerned about people installing make_money_fast.txt files and similar misbehaviour. For this reason, I added a 'group password', which is a shared secret for all the 6bone folks. In short, if you want to write files there, do: $ ftp.ftp.ripe.net Name: anonymous Password: yourname@your.domain cd ipv6/ip6rr site group ip6rr site gpass 6bone (now you can write files there) I still want to answer each comment individually but may not be able to do so before the end of the meeting next week; my apologies. Geert Jan --- The 6bone, certainly in its current state, is quite a bit different from the regular IP4 network we all know. To rephrase, the 6bone in its current state, is - A virtual network - Exists of a dozen islands or so - Multiple prefixes on an island are possible - (for now), routes between islands are configured statically. - DNS IP6 is till in the startup phase and I think it's unwise to depend on it now. While the IPv4 RR uses IP addresses as its main search key, that is probably not very useful for the 6bone. Instead, I think that it is more important to find out about other islands on 6bone and how to get there. IPv6 index capabilities have been added in the RIPE database software last week. However, at this stage the database is not as useful as I want it to be because it is prefix-based too, and it it not possible to ask 'give me all the islands' currently. Also, I expect that the 6bone requirements are going to change fairly soon as the thing evolves. For this reason, I propose to use a public FTP server as drop-point at this time, but at the same time keep the data in the 'database' machine-readable as much as possible to allow for easy migration to the database as soon as there is a need for it. Using the FTP server now gives a little extra flexability which is probably useful at this stage. For instance, 'mget *' gets you a complete overview of the 6bone. To access the FTP 'database', use the following url: ftp://ftp.ripe.net/ipv6/ip6rr/ While I would like to have a public writable FTP directory, I'm concerned about people deleting files, adding 'makemoneyfast.txt' files, etc. For this reason, I added a group password; it is OK to publish the password on the 6bone list but it should probably be a shared secret among list members To get write-access, use: site group ip6rr site gpass 6bone For those who have never used the RIPE-database before, I think that a short introduction is helpful (while we don't use the database, we'll use the database format). The attributes for objects in the database have the following format: attribute1: value attribute2: value This helps to make the data machine-readable. Attributes can be mandatory or optional. Likewise, some attributes may only be allowed in single instances, while other attributes can have multiple instances. To introduce the proposed format, I'd like to show how our entry might look like: site: RIPE NCC location: Amsterdam, The Netherlands loc-string: 33 40 10n 117 49 20w 10m prefix: 5f0d:0500:c100:0000/64 ping: 5f0d:0500:c100:0000::234 tunnel: 193.0.0.234 10.10.10.10 other-site contact: IP6 operations status: example remark: this is only an example! changed: GeertJan.deGroot@ripe.net 960725 source: RIPE Attiribute-definition: site: [single, mandatory] This is the name of the 'island' in freetext format. Obvious examples are 'NRL', 'Digital', 'INRIA', ... location: [multiple, optional] This explains where the site is located. loc-string: [single, optional?] This is the location in lat/longitude format. There is a proposal in draft-ietf-rps-location-00.txt which I'm copying as I have not thought about this myself yet. prefix: / [multiple, mandatory] This documents which prefixes are used within the island. I hope this will be sufficient for 'route add' statements and the like. They should be RFC1897 addresses at this time. XXX ip6 compatible addresses? ping: [multiple, optional] Address of a host that is likely to be available to ping. tunnel: [multiple, mandatory] This documents how a tunnel is built. I'm not really confident if this is sufficient in all cases (automatic tunneling? single hosts? 'native' IPv6 lines?). other-site should be the name of another site: object. contact: [multiple, mandatory] The contact address for this island, for setup of new tunnels and all that. It has been suggested to me that NIC-handles (or RIPE-handles) should also be accepted here; is this acceptable to the group? status: [single, mandatory] The operational status of the island. remark: [multiple, optional] Other useful comments you may have changed: [multiple, mandatory] When the object was last changed, and by whom. While people are primary responsible for their objects themselves, experience has shown that in some cases others might want to make a change too. If you're changing your own object, replace the changed: line; if you're changing someone else's, append a new line and leave the old one intact. source: [single, mandatory] This is used for for exchange of data with other databases. It is currently a fixed value, 'RIPE'. Open issues: 1. I'm not confident about the tunnel syntax. I'd like to make it complete enough so that one stands a fighting chance setting up the local end of a tunnel correctly (so that one only has to send 'this is my end; I assume that's your end, can we tunnel') but I don't know if all cases can be described accurately. (single hosts with automatic tunneling?) 2. Do you think that the latitude/longitude thing is sufficient? I wouldn't know how to get to this information easily (the data in the example is from the draft and thus somewhere in California..) 3. In the 'regular' database, contact persons are split up in administrative and technical contacts, and the contact names point recursively to 'person objects'. (for those who never have seen this, telnet to whois.ripe.net and play around if you want). I don't think that that approach is appropiate at this time; we can always migrate to it once we're using the database. 4. Work on the database version is in progress, thanks to work by its current maintainer, David Kessens. This is an example of what is possible now: (keep in mind that the data is completely fake but the lookup mechanism works..) $ whoisd -r -M 0000:0000:0000:0000:0000:0000:0000:008e/126 ************************************************** * This is the TEST version of the RIPE database, * * please use whois.ripe.net for normal queries! * ************************************************** % Server is running at low priority for -M, -m and -k queries inet6num: ::8F/128 netname: ip61 descr: Norwegian Information Technology network country: NO admin-c: Asbjoern Saetran tech-c: Jan Holthe changed: Havard.Eidnes@runit.sintef.no 921006 changed: ripe-dbm@ripe.net 921007 source: TEST inet6num: ::8E/127 netname: ip62 descr: Norwegian Information Technology network country: NO admin-c: Asbjoern Saetran tech-c: Jan Holthe changed: Havard.Eidnes@runit.sintef.no 921006 changed: ripe-dbm@ripe.net 921007 source: TEST So, when it starts to make sense to store this data in a database, we can. That's as far as I got. Please advise if you think this is useful, or if I'm way off. From RLFink@lbl.gov Thu Sep 19 16:07:04 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 19 Sep 1996 08:07:04 -0700 Subject: new 6bone diagram with WIDE/JP registered In-Reply-To: <199609190113.KAA14982@onoe2.sm.sony.co.jp> References: Your message of "Wed, 18 Sep 1996 17:17:35 -0700" Message-ID: Eureka, 6bone folks are registering! New version of map shows WIDE/JP shaded and pointing to their RIPE-NCC db entry. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At 6:13 PM -0700 9/18/96, Atsushi Onoe wrote: >Bob, > >I've registered WIDE to RIPE-NCC database. >Please make hot button for WIDE :-) From RLFink@lbl.gov Thu Sep 19 16:11:37 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 19 Sep 1996 08:11:37 -0700 Subject: 6bone ,ap change - new tunnel from JOIN/DE to FAUERN/DE In-Reply-To: <199609190758.JAA18789@faui40.informatik.uni-erlangen.de> References: from "Bob Fink LBNL" at Sep 18, 96 03:15:40 pm Message-ID: New 6bone map with Univ. of Erlangen (FAUERN - Friedrich Alexander Universitaet Erlangen/Nuernberg) tunneling to JOIN/DE. =46AUERN is registered!! Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At 12:58 AM -0700 9/19/96, Erich Meier wrote: >Bob, > >> I see that the Univ. of Erlangen (FAUERN) has made an entry in the RIPE-N= CC >> 6bone registry. The tunnel info says that you are connected to JOIN/DE. >> >> The question is, if it is operational as your RIPE entry says, shall I ad= d >> you to the 6bone diagram? > >Why not? Maybe you should contact join@uni-muenster.de for information abou= t >further tunnels in .de. As to my knowledge the JOIN project tries to set up >(more or less internal) tunnels for the german academic research network >(WiN). > >If you need further details about our IPv6 infrastructure beyond the RIPE >entry feel free to ask. > >About operational, well sure it is, if this d**d Solaris Release 5.1 stuff >would >not freeze my 6bone gateway every few hours :-(((. > >Erich From GeertJan.deGroot@ripe.net Thu Sep 19 16:44:18 1996 From: GeertJan.deGroot@ripe.net (Geert Jan de Groot) Date: Thu, 19 Sep 1996 17:44:18 +0200 Subject: RIPE routing registry In-Reply-To: Your message of "Thu, 19 Sep 1996 10:48:36 EDT." <9609191448.AA14074@pobox.BayNetworks.com> Message-ID: <199609191544.RAA01699@office.ripe.net> > I was just trying to ftp BAY's registry file to the > registry area. The "site group ip6rr" command does not > seem to work. I get an invalid command when I try > this. Please let me know what I should do to get > my entry installed. My apologies for not realizing that the FTP site command wasn't always part of FTP... Can you try: quote site group ip6rr quote site gpass 6bone Thanks, Geert Jan From RLFink@lbl.gov Thu Sep 19 22:58:45 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 19 Sep 1996 14:58:45 -0700 Subject: new map - lots of changes Message-ID: Thanks to everyone for all the registry action. At this time only the following aren't registered: Telebit Sun Inner NRL Kohala UManch. Of these, two are new tunnels: UManchester/UK sitting between NRL/US and UL/PT Kohala/US on a tunnel to CISCO/US Welcome! Thanks!! Bob PS: note that the hot button format of the diagram needs Netscape 2 client coordinate mapping to work. From W. Richard Stevens" [In a message of Sep 19, 11:56am Geert Jan de Groot writes:] > > loc-string: [single, optional?] > This is the location in lat/longitude format. > There is a proposal in draft-ietf-rps-location-00.txt > which I'm copying as I have not thought about this myself yet. If anyone is interested (US sites), http://tiger.census.gov lets you enter a zip code and then draws a map of the area, allowing you to then zoom in on your exact location (identifiable by streets). You can then read off the exact latitude and longitude. Rich Stevens From RLFink@lbl.gov Fri Sep 20 16:26:42 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 20 Sep 1996 08:26:42 -0700 Subject: 6bone map change Message-ID: 6bone diagram version 20, 20 September. Some error corrections. Some name changes. Some newly registered sites. The hot buttons for the 6bone registry entries are now just the node, not the name. This will allow me to use the name in the future for pointers to other info. Just a few left to register. If I can get all registered sooner than 1 Dec, I will then require all new sites to register before they are entered, which will save me time and work. I'm still concerned that we all share the same registry data structure so we can eventually automate much of this! Keep it coming...gee, this is fun :-) Thanks. Bob From peter@sics.se Mon Sep 23 14:51:41 1996 From: peter@sics.se (Peter Sjodin) Date: Mon, 23 Sep 1996 15:51:41 +0200 Subject: Error in SICS entry in 6bone registry Message-ID: <199609231351.PAA16587@brahma.sics.se> There was an error in the SICS entry in the RIPE database. The prefix for SICS should be 5f0b:1700::/32, and nothing else. I have fixed that now. Sorry! Peter From RLFink@lbl.gov Mon Sep 23 15:01:54 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 23 Sep 1996 07:01:54 -0700 Subject: 6bone map change - add tunnels from JOIN to ESNET and TELEBIT Message-ID: 6bone diagram 21: Added tunnels from JOIN to ESNET and from JOIN to TELEBIT. U Manchester (UMAN/UK) now is registered. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Date: Mon, 23 Sep 1996 12:39:05 +0200 (MET DST) =46rom: JOIN Project Team To: RLFink@lbl.gov Subject: new tunnel(s) Hello Bob, we configured a new 6bone tunnel between JOIN and ESnet. I just included the tunnel info into our RIPE registry entry (ftp://ftp.ripe.net/ipv6/ip6rr/JOIN) - i think ESnet will do so later today. Another tunnel is up and running between JOIN and Telebit (using IDRPv6 :-). This tunnel info is also included in our registry (and i did remember the guys from Telebit to download there registration ;-) ... Thanks, all the best Guido ----------------------------------------------------------------------------= -- JOIN -- IP Version 6 in the WiN Guido Wessendorf A project of DFN Westfaelische Wilhelms-Universitaet Muenst= er Project Team email: Universitaetsrechenzentrum join@uni-muenster.de Einsteinstrasse 60 http://www.join.uni-muenster.de D-48149 Muenster / Germany phone: ++49 251 83 8459, fax: ++49 251 83 2678, email: wessend@uni-muenster.= de ----------------------------------------------------------------------------= -- =00 From RLFink@lbl.gov Mon Sep 23 16:06:07 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 23 Sep 1996 08:06:07 -0700 Subject: Submitting logo In-Reply-To: <31DB2D3B.702C@webwurx.com> Message-ID: Brad St Pierre has submitted a new 6bone logo entry in three variants. As before, you can view them at: http://www-6bone.lbl.gov/6bone/logos/6bone_logos.html It is still my intention to have a logo vote before the December IETF and make a bunch of t-shirts with the winning logo. Anyone have any clever ideas of text to go along with the logo and how to place it? =46or example, "the 6bone - IPv6 to the next generation Internet", or some such. Ideas please ! :-) Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At 7:32 PM -0700 7/3/96, Brad St. Pierre wrote: >Here's 3 logo's that I quickly made (I'm really busy). I will be making >more when I think of some. > >The images are at this address: > >http://www.hurry.com/6bone/6bone.htm > > >(=3D=3D Brad St Pierre =3D=3D) >- Graphic Designer >- 3D Designer/Animator > >(=3D=3DOne of my creations=3D=3D) >http://www.thearcade.com From bound@zk3.dec.com Mon Sep 23 16:25:21 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 23 Sep 96 11:25:21 -0400 Subject: 6bone map change In-Reply-To: Your message of "Fri, 20 Sep 96 08:26:42 PDT." Message-ID: <9609231525.AA00256@fwasted.zk3.dec.com> Geert/Bob/Andrew, Good job. thanks for your leadership and work, /jim From veum@cobra.gsfc.nasa.gov Mon Sep 23 17:42:15 1996 From: veum@cobra.gsfc.nasa.gov (Gary Veum) Date: Mon, 23 Sep 1996 12:42:15 -0400 Subject: need a new tunnel to nasa/gsfc Message-ID: <3246BDE7.41C6@cobra.gsfc.nasa.gov> hi, i'm at nasa/gsfc (east coast)with a a some ipv6 machines. i have both dec and sun boxes. can someone who could provide me a tunnel contact me? thanks. -gary ------------------------------------------------------------------------ Gary Veum NASA / Goddard Space Flight Center veum@cobra.gsfc.nasa.gov Code 505 / Hughes/STX PHONE 301-614-5153 Greenbelt MD 20771 FAX 301-614-5270 "responsbility is a heavy responsibility" - Tommy Chong From ahoag@nas.nasa.gov Mon Sep 23 19:19:50 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Mon, 23 Sep 1996 11:19:50 -0700 Subject: 6bone Registry Message-ID: <9609231119.ZM7609@rennsport.nas.nasa.gov> Geert Jan: First off, I am extremely glad the 6bone routing registry has taken off like it has. This should make things easier for all of us and benefit the 6bone's future... I appreciate your initiative in getting this going. In moving towards some sort of standard format, I would like to propose the following additions/enhancements to the 6bone registry: # Require 'loc-string' compliance with RFC1876 (DNS LOC RR format)... Some sort of standard method needs to be defined here, and since we have RFC1876, might as well use that as the standard. (Maybe that's what you are already using?) # Make the tunnel format more clear; my specific thoughts are to do something like the following: tunnel: in src [srchandle] dst [dsthandle] e.g. tunnel: IPv6 in IPv4 src 129.99.237.71 NAS dst 192.31.7.41 Cisco This makes it perfectly clear what is being tunnelled, and over what. I feel this would be the most extensible format for future use. (Also note the implications of a digraph network format as opposed to bidirectional tunnels). Of course, if we are just concerned about the here and now a more brief and simpler tunnel format (ala 'tunnel: ') may be sufficient. Any variations on the above are encouraged. I tend to lean towards the verbose, plus the previous makes for fairly easy regexp matching. :-) # Include the "site:" tag or similar for a site handle. This site handle then would be the filenames you are using in the registry and would uniquely identify a particular 6bone node. (node in the 6bone overview sense) These ideas are a culmination of discussions between myself, Bob Fink, David K, and other members of the list. As soon as some sort of standard is implemented, we can move ahead with some more automation and other enhancements. Comments / feedback requested! -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From ahoag@nas.nasa.gov Mon Sep 23 19:48:05 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Mon, 23 Sep 1996 11:48:05 -0700 Subject: 6bone Registry In-Reply-To: rja@cisco.com (Ran Atkinson) "Re: 6bone Registry" (Sep 23, 11:41am) References: <199609231841.LAA02980@cornpuffs.cisco.com> Message-ID: <9609231148.ZM7690@rennsport.nas.nasa.gov> On Sep 23, 11:41am, Ran Atkinson wrote: > Subject: Re: 6bone Registry > Sounds useful to me, except that we ought to insist that tunnels be > bidirectional for now (unidirectional tunnels are too hard to test > and are of limited value operationally) and keep the tunnel entry > format simple, IMHO. True, and if we do include the handle along with the addresses of the endpoints, that would clear up which was which. We then could eliminate the 'src' and 'dst' keywords and end up with something like: tunnel: IPv6 in IPv4 129.99.236.71 NAS to 192.xxx.xxx.xxx Cisco The insertion of the "to" keywoard could replace "src" & "dst" while still delimiting the string somewhat. Of course, we can over-engineer this, so hopefully Geert Jan can take our suggestions and come up with something we can live with. :-) -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From RLFink@lbl.gov Mon Sep 23 20:59:20 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 23 Sep 1996 12:59:20 -0700 Subject: 6bone map change - Add tunnel from G6/FR to NIST/US. In-Reply-To: <960923203200.ZM23184@rama.imag.fr> References: Bob Fink LBNL "Re: Submitting logo" (Sep 23, 8:06am) Message-ID: 6bone drawing 22: Add tunnel from G6/FR to NIST/US. Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At 11:31 AM -0700 9/23/96, Alain Durand wrote: >Hi bob > >There is a new tunnel between G6 and NIST. I have updated the G6 entry >of the RIPE database. Also note that G6 now connects 6 different sites in >france under our common prefix 5f06:b500::/32 > > - Alain. From davidk@ISI.EDU Mon Sep 23 21:47:19 1996 From: davidk@ISI.EDU (davidk@ISI.EDU) Date: Mon, 23 Sep 1996 13:47:19 -0700 (PDT) Subject: 6bone Registry In-Reply-To: <9609231148.ZM7690@rennsport.nas.nasa.gov> from "Andrew J. Hoag" at Sep 23, 96 11:48:05 am Message-ID: <199609232047.AA18959@nam.isi.edu> Hi Andrew, > Andrew J. Hoag writes : > > On Sep 23, 11:41am, Ran Atkinson wrote: > > Subject: Re: 6bone Registry > > Sounds useful to me, except that we ought to insist that tunnels be > > bidirectional for now (unidirectional tunnels are too hard to test > > and are of limited value operationally) and keep the tunnel entry > > format simple, IMHO. > > True, and if we do include the handle along with the addresses of the > endpoints, that would clear up which was which. We then could eliminate the > 'src' and 'dst' keywords and end up with something like: > > tunnel: IPv6 in IPv4 129.99.236.71 NAS to 192.xxx.xxx.xxx Cisco > > The insertion of the "to" keywoard could replace "src" & "dst" while still > delimiting the string somewhat. I like this idea. You might want to substitute 'to' by <-> for bidirectional tunnels and ->/<- for unidirectional tunnels (this might be an academic possibility, but who knows ?). This also avoids alpha-numeric characters and thus makes it easier for the software (and may be even for humans) to parse the tunnel line in the right parts. tunnel: IPv6 in IPv4 129.99.236.71 NAS <-> 192.xxx.xxx.xxx Cisco > Of course, we can over-engineer this, so hopefully Geert Jan can take our > suggestions and come up with something we can live with. :-) We can also do a simplification and see if it makes things more clear or not. The first site name is not really necessary if the first IP address is by default local to the site (in this case NAS): tunnel: IPv6 in IPv4 129.99.236.71 <-> 192.xxx.xxx.xxx Cisco And one step further: tunnel: IPv6 in IPv4 129.99.236.71 <-> 192.xxx.xxx.xxx The IP addresses already determines where the tunnel is going to. The database software is capable enough of finding the site names that have tunnels with a certain IP address on run time. This also avoids data duplication problems which is usually not a bad idea in database design ... The software could still return with: tunnel: IPv6 in IPv4 129.99.236.71 <-> 192.xxx.xxx.xxx Cisco or tunnel: IPv6 in IPv4 129.99.236.71 NAS <-> 192.xxx.xxx.xxx Cisco when people use the whois query mechanism for humans (=default mode). What are the opinions of the other people ? David K. From kml@nas.nasa.gov Mon Sep 23 22:06:50 1996 From: kml@nas.nasa.gov (Kevin M. Lahey) Date: Mon, 23 Sep 1996 14:06:50 -0700 Subject: prototype IPv6 echo host available Message-ID: <199609232106.OAA10488@galaxy.nas.nasa.gov> A prototype IPv6 echo host is now availble at echo.ipv6.nas.nasa.gov (5f01:2900:8163:cd00::2). The implementation is based on Craig Partridge's description of echo hosts in draft-rfced-exp-partridge-00.txt: An IP echo host returns IP datagrams to their original source host, with the IP source and destination addresses reversed, so that the returning datagram appears to be coming from the echo host to the original source. IP echo hosts are tremendously useful for debugging applications and protocols. They allow researchers to create looped back conversations across the Internet, exposing their traffic to all the vagaries of Internet behavior (congestion, cross traffic, variable round-trip times and the like) without having to distribute prototype software to a large number of test machines. The prototype implementation is intentionally conservative: It rejects packets with loopback, local, site, multicast, IPv4 compatibility or IPv4 mapped source addresses, packets with next header fields other than UDP or TCP, and packets with non-zero flow ids. If the 6bone community finds this service useful, I'll be happy to put in the work to remove most of these restrictions. If no one uses it, I'll probably drop support for it when I next upgrade the system, in a few more weeks. Enjoy, Kevin From davidk@ISI.EDU Mon Sep 23 22:15:53 1996 From: davidk@ISI.EDU (davidk@ISI.EDU) Date: Mon, 23 Sep 1996 14:15:53 -0700 (PDT) Subject: 6bone Registry In-Reply-To: <9609231348.ZM7957@rennsport.nas.nasa.gov> from "Andrew J. Hoag" at Sep 23, 96 01:48:11 pm Message-ID: <199609232115.AA19014@nam.isi.edu> Hi Andrew, > Andrew J. Hoag writes : > > That was my initial reasoning for the "src" keyword or at least listing the > source IP first. Then you could switch them around: > > site: NAS > tunnel: IPv6 in IPv6 dst 192.xxx.xxx.xxx Cisco src 129.99.236.71 NAS > > without worrying about it. But since this will go eventually into a database, I > would argue for requiring the "local" endpoint first. Yes, but the dst/src keyword addition has one advantage: The software can never find out which IP address is at which point of the tunnel and thus is syntax checking less reliable. Also, the software can automatically rearrange the order to have the src IP address listed first in the attribute line. The only possible check without the src/dst keywords is the check if the tunnel in the other object (if already existing) is defined in opposite order. My personal opinion is that this check is enough. > > And one step further: > > > > tunnel: IPv6 in IPv4 129.99.236.71 <-> 192.xxx.xxx.xxx > > > > The IP addresses already determines where the tunnel is going to. The > > database software is capable enough of finding the site names that have > > tunnels with a certain IP address on run time. This also avoids data > > duplication problems which is usually not a bad idea in database design ... > > Yes, you are right again. I was looking at this from the human-readable form > (e.g. source files) but that does not have to be the ending user interface. > > > tunnel: IPv6 in IPv4 129.99.236.71 NAS <-> 192.xxx.xxx.xxx Cisco > > I like the database parsing the tunnel endpoints, but what would this require > from the data-side? Would the database be able to grok Cisco's entry and search > for NAS's IP address on the right (remote) side and then backfill the record > accordingly? Yes, with one exception: If the other object (Cisco) is not updated yet with the new tunnel. However, this might be a good feature, a tunnel is regarded as working when both ends have updated their objects. Other question is: Do you want to use IP addresses of both end points and/or is the DNS host name instead of an IP address more flexible ?!? Allowing the possibility makes the backfill more difficult and error-prone but is certainly not impossible ( or only is easiest). David K. --- From Sebastien.Roy@unh.edu Tue Sep 24 01:28:23 1996 From: Sebastien.Roy@unh.edu (Sebastien.Roy@unh.edu) Date: Mon, 23 Sep 1996 17:28:23 -0700 Subject: need a new tunnel to nasa/gsfc In-Reply-To: <3246BDE7.41C6@cobra.gsfc.nasa.gov> References: <3246BDE7.41C6@cobra.gsfc.nasa.gov> Message-ID: <199609240028.RAA08155@strat.iol.unh.edu> Gary Veum writes: > hi, > i'm at nasa/gsfc (east coast)with a a some ipv6 machines. i have both > dec and sun boxes. can someone who could provide me a tunnel contact > me? > > thanks. > > -gary Hello, Do you still need a tunnel? I would be willing to provide one for you. The information for our end is contained in the RIPE database. Let me know if you want me to configure the tunnel. -- Sebastien C. Roy RCC/IOL University of New Hampshire Sebastien.Roy@unh.edu From rja@cisco.com Mon Sep 23 23:33:01 1996 From: rja@cisco.com (Ran Atkinson) Date: Mon, 23 Sep 1996 15:33:01 PDT Subject: 6bone-router.cisco.com status Message-ID: <199609232233.PAA04236@cornpuffs.cisco.com> I've just updated my routing table based on the RIPE Registry data. I have routes for each site with a RIPE entry. I don't have a route for Telebit/DK just yet -- only because I don't have accurate current data from them. It would be useful if someone from Telebit/DK would email me their routing prefix and also if they would update their entry with the RIPE Registry so that the data is available to everyone on the 6bone. IMHO it would be useful if sites having an AAAA-capable DNS server would list the domain name of their IPv6 ping'able host. This would let us all move towards use of DNS and away from use of or need for flat host tables of any sort. Ran rja@cisco.com -- From Alain.Durand@imag.fr Tue Sep 24 00:21:54 1996 From: Alain.Durand@imag.fr (Alain Durand) Date: Tue, 24 Sep 1996 01:21:54 +0200 Subject: RIPE registry In-Reply-To: rja@cisco.com (Ran Atkinson) "6bone-router.cisco.com status" (Sep 23, 3:33pm) References: <199609232233.PAA04236@cornpuffs.cisco.com> Message-ID: <960924012154.ZM22952@rama.imag.fr> Just an idea I had looking at the 6-bone map and trying to figure out which route shall I take to go to cisco: it might be usefull to give some kind of average RTT for each tunnel. I know, this is highly dynamic, but this will still provide some hints about the speed of the links and might be use as a rought metric. For example, tonight a 1:20 am G6 -> U-lisboa (pt): RTT = 1000 ms G6 -> UNH (us): RTT = 400 ms G6 -> UNI-C (dk): RTT = 200 ms G6 -> JOIN (de): RTT = 500 ms G6 -> MAINZ (de): RTT = 600 ms G6 -> NIST (us): RTT = 300 ms G6 -> SICS (se): RTT = 150 ms G6 -> WIDE (jp): down I made some observation at other times of the day, I had similar results. Comments? - Alain From Alain.Durand@imag.fr Mon Sep 23 23:47:31 1996 From: Alain.Durand@imag.fr (Alain Durand) Date: Tue, 24 Sep 1996 00:47:31 +0200 Subject: 6bone Registry & bidirectional tunnels In-Reply-To: davidk@ISI.EDU "Re: 6bone Registry" (Sep 23, 1:47pm) References: <199609232047.AA18959@nam.isi.edu> Message-ID: <960924004731.ZM23516@rama.imag.fr> On Sep 23, 1:47pm, davidk@ISI.EDU wrote: > Subject: Re: 6bone Registry > > > True, and if we do include the handle along with the addresses of the > > endpoints, that would clear up which was which. We then could eliminate the > > 'src' and 'dst' keywords and end up with something like: > > > > tunnel: IPv6 in IPv4 129.99.236.71 NAS to 192.xxx.xxx.xxx Cisco > > > > The insertion of the "to" keywoard could replace "src" & "dst" while still > > delimiting the string somewhat. > > I like this idea. You might want to substitute 'to' by <-> for > bidirectional tunnels and ->/<- for unidirectional tunnels (this might be > an academic possibility, but who knows ?). This also avoids alpha-numeric > characters and thus makes it easier for the software (and may be even for > humans) to parse the tunnel line in the right parts. humm... just that from what I understand of tunnels (at least in the implementations I'm working with) they are essentially asymetric. That is, you specify where your packets are going, not where they come from. So a tunnel is only bidirectional if both sides configure it in the same way. Maybe we should emphasize that this SHOULD always be the rule. I have already experiment misconfigured sites with asymetric tunnels, packets do not take the same path on their way back, and sometime we get very weird results and I feel it's more difficult to debug. - Alain. From bound@zk3.dec.com Tue Sep 24 03:39:29 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 23 Sep 96 22:39:29 -0400 Subject: RIPE registry In-Reply-To: Your message of "Tue, 24 Sep 96 01:21:54 +0200." <960924012154.ZM22952@rama.imag.fr> Message-ID: <9609240239.AA14006@fwasted.zk3.dec.com> Alain, This is really good thing to do. And why we want multiple entry points for testing. /jim From RLFink@lbl.gov Tue Sep 24 15:25:08 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 24 Sep 1996 07:25:08 -0700 Subject: 6bone map change - Sun registered and lines don't cross :-) In-Reply-To: <199609232204.PAA04102@cornpuffs.cisco.com> Message-ID: 6bone drawing 23: Sun is now RIPE registered, only Telebit is left. Give our success with the RIPE registry at this point I will no longer add to the map any site not registered at RIPE (why wait for December). Also, I've taken Ran's advice on line crossings. This map will be a challenge as it grows, but as long as it is useful in its current scale I'll continue it. Thanks, Bob From RLFink@lbl.gov Tue Sep 24 16:19:09 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 24 Sep 1996 08:19:09 -0700 Subject: please check Geert Jan's registry info email web page Message-ID: I've put Geert Jan's email on how to create and write your own 6bone registry entry (less id and password) into a web page accessible thru the 6bone home page. Please let me know if there is anything wrong with it. I'm assuming that, in spite of the discussions on changing the its structure/ content, that the original email still pertains. Let me know if this isn't so and I will change the page pronto! Thanks, Bob From strauss@ibr.cs.tu-bs.de Tue Sep 24 16:18:16 1996 From: strauss@ibr.cs.tu-bs.de (Frank Strauss) Date: 24 Sep 1996 17:18:16 +0200 Subject: RIPE registry In-Reply-To: "Alain Durand"'s message of Tue, 24 Sep 1996 01:21:54 +0200 References: <199609232233.PAA04236@cornpuffs.cisco.com> <960924012154.ZM22952@rama.imag.fr> Message-ID: "Alain Durand" writes: > which route shall I take to go to cisco: it might be usefull to give > some kind of average RTT for each tunnel. I know, this is highly dynamic, > but this will still provide some hints about the speed of the links > and might be use as a rought metric. > [...] > Comments? I like that idea. I've set up a short script grabbing pingable addresses out of the RIPE registry and sending out some echo requests every hour (that often probably just for the first few days). The results may be seen at http://www.cs.tu-bs.de/~strauss/ipng/stats.html. Note that TU-BS is one of the leaf sites with just one default tunnel. Therefore our values are not very representative for US residents, for example. From Bernard.Tuy@urec.fr Wed Sep 25 11:55:11 1996 From: Bernard.Tuy@urec.fr (Bernard TUY) Date: Wed, 25 Sep 1996 12:55:11 +0200 (MET DST) Subject: 6bone map change - Sun registered and lines don't cross :-) Message-ID: <199609251055.MAA13034@calypso.urec.fr> Thanx Bob for the nice job you've done. I'm just back from the RIPE meeting in A'dam where the IPv6-wg meet. Francis, GeertJan and me have presented the 6bone initiative and many other things related to IPv6. We have invited everybody attending the session to launch IPv6 hosts at their office and connect to the 6bone... after having been registered at the RIPE ! The group strongly recommand the RIPE NCC to have an active role in the coordination inside Europe. I think minutes of the meeting will be available sooner or later and I wonder if it's of intereset for people participating this mailing list to get them (or an URL where to pick them up) ? Regards, +Bernard Tuy. From RLFink@lbl.gov Wed Sep 25 14:44:48 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 25 Sep 1996 06:44:48 -0700 Subject: 6bone map change - Sun registered and lines don't cross :-) In-Reply-To: <199609251055.MAA13034@calypso.urec.fr> Message-ID: Bernard, > Thanx Bob for the nice job you've done. > I'm just back from the RIPE meeting in A'dam where the IPv6-wg > meet. Francis, GeertJan and me have presented the 6bone initiative > and many other things related to IPv6. We have invited everybody > attending the session to launch IPv6 hosts at their office and > connect to the 6bone... after having been registered at the RIPE ! > The group strongly recommand the RIPE NCC to have an active role > in the coordination inside Europe. > I think minutes of the meeting will be available sooner or later > and I wonder if it's of intereset for people participating this > mailing list to get them (or an URL where to pick them up) ? Glad things went well. Yes, please do let us know how to get the minutes. Thanks, Bob From ahoag@nas.nasa.gov Thu Sep 26 01:48:50 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Wed, 25 Sep 1996 17:48:50 -0700 Subject: www.ipv6.nas.nasa.gov - New IPv6 web server Message-ID: <9609251748.ZM5710@rennsport.nas.nasa.gov> We have patched Apache 1.1.1 to support IPv6 here and now have a server running at http://www.ipv6.nas.nasa.gov/. This returns both an A and a AAAA DNS record. If you want only an AAAA record, the address www6.ipv6.nas.nasa.gov will provide that. I will be posting our patches to Apache 1.1.1 to this server shortly. This server will also replace the old location for the geographical map. Please direct any questions or problems to . -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From ipng@uni-muenster.de Thu Sep 26 10:04:17 1996 From: ipng@uni-muenster.de (JOIN Project Team) Date: Thu, 26 Sep 1996 11:04:17 +0200 (MET DST) Subject: RIPE registry In-Reply-To: <960924012154.ZM22952@rama.imag.fr> Message-ID: On Tue, 24 Sep 1996, Alain Durand wrote: > Just an idea I had looking at the 6-bone map and trying to figure out > which route shall I take to go to cisco: it might be usefull to give > some kind of average RTT for each tunnel. I know, this is highly dynamic, > but this will still provide some hints about the speed of the links > and might be use as a rought metric. > > For example, tonight a 1:20 am > > G6 -> U-lisboa (pt): RTT = 1000 ms > G6 -> UNH (us): RTT = 400 ms > G6 -> UNI-C (dk): RTT = 200 ms > G6 -> JOIN (de): RTT = 500 ms > G6 -> MAINZ (de): RTT = 600 ms > G6 -> NIST (us): RTT = 300 ms > G6 -> SICS (se): RTT = 150 ms > G6 -> WIDE (jp): down > > I made some observation at other times of the day, I had similar results. Like Frank did i also have set up a www page showing a list of many 6bone addresses. Hourly the average round trip delays are updated... Look at http://www.join.uni-muenster.de/local/v6ping/v6answer.html -- Guido ------------------------------------------------------------------------------ JOIN -- IP Version 6 in the WiN Guido Wessendorf A project of DFN Westfaelische Wilhelms-Universitaet Muenster Project Team email: Universitaetsrechenzentrum join@uni-muenster.de Einsteinstrasse 60 http://www.join.uni-muenster.de D-48149 Muenster / Germany phone: ++49 251 83 8459, fax: ++49 251 83 2678, email: wessend@uni-muenster.de ------------------------------------------------------------------------------ From RLFink@lbl.gov Thu Sep 26 15:40:38 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 26 Sep 1996 07:40:38 -0700 Subject: 6bone stats In-Reply-To: References: <960924012154.ZM22952@rama.imag.fr> Message-ID: I've put up a page (accessible thru the 6bone home page) to point to Frank Strauss' and Guido Wessendorf's ping data pages. If other pages of useful (hopefully continually updated) data are available, please let me know and I will add them. A question for Frank and Guido: How often are your pages refreshed and what is the ping repeat cycle (Guido's refresh is one hour, but don't know the ping repeat). Thanks, Bob From RLFink@lbl.gov Thu Sep 26 15:51:37 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 26 Sep 1996 07:51:37 -0700 Subject: 6bone map change - TELEBIT/DK RIPE registered Message-ID: Eureka, we have now reached the point where all 6bone sites are RIPE-NCC registered. 6bone drawing version 24 shows TELEBIT/DK as registered. So now I will only take new sites/tunnels for the map that: Are RIPE-NCC registered Have their tunnel(s) validated By validated I mean the tunnel is known to work in both directions. Have there been agreements yet on registry format changes that I can record in the "how to register..." writeup? Thanks, Bob From ipng@uni-muenster.de Thu Sep 26 16:33:18 1996 From: ipng@uni-muenster.de (JOIN Project Team) Date: Thu, 26 Sep 1996 17:33:18 +0200 (MET DST) Subject: 6bone stats In-Reply-To: Message-ID: Hi Bob, On Thu, 26 Sep 1996, Bob Fink LBNL wrote: > I've put up a page (accessible thru the 6bone home page) to point to Frank > Strauss' and Guido Wessendorf's ping data pages. > > If other pages of useful (hopefully continually updated) data are > available, please let me know and I will add them. > > > A question for Frank and Guido: How often are your pages refreshed and > what is the ping repeat cycle (Guido's refresh is one hour, but don't know > the ping repeat). i send five ICMPv6 echo requests to each listed address hourly, using ping -s $v6address 56 5 on our Sun. All the best --Guido From RLFink@lbl.gov Thu Sep 26 17:51:36 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 26 Sep 1996 09:51:36 -0700 Subject: 6bone stats In-Reply-To: <199609261456.QAA16044@sol.ibr.cs.tu-bs.de> References: (message from Bob Fink LBNL on Thu, 26 Sep 1996 07:40:38 -0700) Message-ID: =46rank, >my page gets also updated once per hour. it's done by a simple ping6, >so the echo request frequency is one request per second. i added these >information to the script (and page). Changed the page to reflect this. Thanks, Bob From RLFink@lbl.gov Thu Sep 26 17:50:25 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 26 Sep 1996 09:50:25 -0700 Subject: 6bone stats In-Reply-To: References: Message-ID: Guido, >i send five ICMPv6 echo requests to each listed address hourly, using >ping -s $v6address 56 5 on our Sun. Page updated per above. Thanks, Bob From RLFink@lbl.gov Fri Sep 27 02:28:51 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 26 Sep 1996 18:28:51 -0700 Subject: another 6bone logo courtesy of Gustavo Sanchez Gomez Message-ID: Another neat logo from Gustavo Sanchez Gomez. http://www-6bone.lbl.gov/6bone/logos/6bone_logos.html Thanks, Bob =3D=3D=3D Date: Thu, 26 Sep 1996 22:48:30 +0200 =46rom: Gustavo Sanchez Gomez Reply-To: gustavo@convex.es Organization: Convex Supercomputer S.A.E. Mime-Version: 1.0 To: RLFink@lbl.gov Subject: Other logo ... This is a good logo ... and a good IPv6 address. I should like this address for my WS ... :-) If you don't receive the gif file well, say me please, and send once more time. Thanks. -- Gustavo Sanchez Gsmez Consultor Convex Supercomputer S.A.E. Tlf: 95-4530694 Luis de Morales 32, edif. Forum, msdulo 3-30 Sevilla, Spain e-mail: gustavo@convex.es --- From strauss@ibr.cs.tu-bs.de Fri Sep 27 12:00:07 1996 From: strauss@ibr.cs.tu-bs.de (Frank Strauss) Date: Fri, 27 Sep 1996 13:00:07 +0200 Subject: 6bone stats In-Reply-To: <96092713554127@kekvax.kek.jp> (karita@kekvax.kek.jp) Message-ID: <199609271100.NAA02248@sol.ibr.cs.tu-bs.de> Hi! Yukio> [...] Or, is Frank's ping not routed over the 6bone but routed Yukio> just as ipv4? I have just one default tunnel to JOIN as shown in Bob's map. Sorry, I'm actually short time and more unfortunately our IPv6 router fix.ipv6.ibr.cs.tu-bs.de is shut down in a few minutes for a yet unknown time, so there will be no way to ping it. But with the knowledge that JOIN is just one hop away in a static manner, it should be ok, if anyone want's to investigate any further. Frank From ahoag@nas.nasa.gov Fri Sep 27 19:37:04 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Fri, 27 Sep 1996 11:37:04 -0700 Subject: Updated Geographical map Message-ID: <9609271137.ZM4654@rennsport.nas.nasa.gov> I did one more quick update to the Geographical map (at http://www.ipv6.nas.nasa.gov/viz/ ) before I leave for LISA. I haven't done any updates lately while I've been waiting for a standardized format out of RIPE. Enjoy! -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From davidk@isi.edu Fri Sep 27 23:58:42 1996 From: davidk@isi.edu (davidk@isi.edu) Date: Fri, 27 Sep 1996 15:58:42 -0700 (PDT) Subject: Updated Geographical map In-Reply-To: <9609271137.ZM4654@rennsport.nas.nasa.gov> from "Andrew J. Hoag" at Sep 27, 96 11:37:04 am Message-ID: <9609272258.AA02474@old.isi.edu> Hi Andrew, > Andrew J. Hoag writes : > > I haven't done any > updates lately while I've been waiting for a standardized format out of RIPE. I am working on a proposal for a standarized format based on the recent discussion on the list and my knowledge of the current RIPE database implementation. I am currently discussing the document with Geert Jan. I will post the proposal for further discussion/amendments to the list when Geert Jan has helped me to fill in the missing pieces and obvious errors. Please expect that this process will take some time; Geert Jan is very busy right now as I understand it from private conversations with him. David K. --- From kann@CS.UCLA.EDU Sat Sep 28 04:26:56 1996 From: kann@CS.UCLA.EDU (Jong Kann) Date: Fri, 27 Sep 1996 20:26:56 -0700 (PDT) Subject: UCLA registry update. Message-ID: <199609280326.UAA06618@pelican.cs.ucla.edu> Thanks to the JOIN/DE stats, that I found out I had a typo in my original registry. Please use the latest version to update your IPv6 hosts database if you have one. I'm sorry for the inconvenience that this might cause you. Best Regards, Jong kann@cs.ucla.edu p.s. original addr: 5f0d:xxxxx correct addr: 5f00:xxxxx From rob.glenn@nist.gov Mon Sep 30 18:21:55 1996 From: rob.glenn@nist.gov (rob.glenn@nist.gov) Date: Mon, 30 Sep 1996 13:21:55 -0400 (EDT) Subject: Stats from NIST site. Message-ID: <199609301721.NAA00336@sloth.ncsl.nist.gov> We had a major outage this weekend so I don't know if this made it... --------------------------------------------------------------------- Autogenerated and color-coded ping statistics from NIST can be found at: http://snad.ncsl.nist.gov/~ipng/NIST-6bone-status.html The script downloads the RIPE registries and attempts to ping every pingable site listed in each file. This include the v4 Tunnel address. Data is gathered using ping on a BSD/OS PC running the NRL Alpha-3 IPv6 code. The pinging system is two hops from the tunnel end-point. This implies that v6 RTTs are relative to the return trip times for NIST. Thus, computed RTT is given as SITE RTT - NIST RTT. v4 paths are different than the v6 tunnel paths. v4 Tunnel RTTs are listed but have little, if any, relation to v6 RTT. Each site is pinged 10 times using a packet size of 500 bytes. Statistics are gathered every hour. NOTE: I tried 1000 bytes but that failed too often. Rob G. rob.glenn@nist.gov PS - If anyone wants a copy of the script, let me know. FYI: To run it you need PERL 5 or better installed.