From jang@sps.nl Mon Mar 3 16:18:27 1997 From: jang@sps.nl (Gils van, Jan) Date: Mon, 3 Mar 1997 17:18:27 +0100 Subject: 6Bone Tunnel Netherlands ? Message-ID: Hi, Thanks for reading Are there 6bone tunnels active in the Netherlands, and is it possible to connect with one off them. I hope to here from someone. Greetings Jan van Gils ___________________________________________________________________ Jan H. van Gils | Software Productivity Solutions jang@sps.nl | P.O. box 92 2810 AB Reeuwijk +31 (0)182-396866 | Fokkerstraat 16 2811 ER Reeuwijk ------------------------------------------------------------------- From bmanning@ISI.EDU Mon Mar 3 21:53:50 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Mon, 3 Mar 1997 13:53:50 -0800 (PST) Subject: Getting attached... In-Reply-To: from "Jason Duerstock" at Feb 27, 97 08:15:51 pm Message-ID: <199703032153.AA29151@zed.isi.edu> > > Note that an RFC1897 format address includes the ASN (Autonomous System > > Number) of one's provider, not an ASN that belongs to one's own site. > > (Though a provider uses its own ASN.) > > This is would make my address > > 5F: (01011111 == first 8 bits) > 0D: T > E9: +- 3561 (for MCI's ASN) > 00: (RES == reserved...?) > CE: 206. \ > 9C: 156. > our IPv4 class C subnet > 94: 148. / > 00: (RES == reserved...) Hi, It looks like the 0.0.9.e.d.0.f.5.ip6.int. entry is registered to Jim Bound of DEC. It might be prudent to have MCI clarify is delegation procedures for these test address blocks. Jim? -- --bill From chong@mail52.mitretek.org Tue Mar 4 14:29:00 1997 From: chong@mail52.mitretek.org (Chongeun Lee) Date: Tue, 4 Mar 97 09:29:00 -0500 Subject: Connection to the 6bone Message-ID: <970304092859.30749@mail52.mitretek.org.0> I would like to request for the attachment point on the 6bone. I work for Mitretek Systems in McLean, Virginia, which is a non-profit organization working to research/develop technologies for public interest. We have 2 of desktop PC's (supporting IPv6), 2 of SunSparcStation 10, 1 of DEC Unix Alpha 500, 1 of ARN hub router from BayNetworks, and 1 of ATM 5000 from BayNetworks which would be used for the WAN connection. Let me know if you need more information. Thanks, Chongeun Lee From bmanning@ISI.EDU Tue Mar 4 16:23:05 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Tue, 4 Mar 1997 08:23:05 -0800 (PST) Subject: suspect routing? Message-ID: <199703041623.AA00864@zed.isi.edu> Hi, What is the general take on mapped IPv4 address prefixes being propogated within 6bone, e.g. ::192.0.2.10 And I've found a recent "feature" that allows the propogation of the loopback address ::1 So sorry to be causing grief and woe to the assembled multitude. -- bill From Alain.Durand@imag.fr Tue Mar 4 18:21:59 1997 From: Alain.Durand@imag.fr (Alain Durand) Date: Tue, 4 Mar 1997 19:21:59 +0100 Subject: suspect routing? In-Reply-To: bmanning@ISI.EDU "suspect routing?" (Mar 4, 8:23am) References: <199703041623.AA00864@zed.isi.edu> Message-ID: <970304192159.ZM4867@rama.imag.fr> On Mar 4, 8:23am, bmanning@ISI.EDU wrote: > Subject: suspect routing? > > Hi, > What is the general take on mapped IPv4 address prefixes being > propogated within 6bone, e.g. ::192.0.2.10 > > And I've found a recent "feature" that allows the propogation > of the loopback address ::1 My opinion is that: - IPv4 compatible routes should not be advertized - Static routes should be injected in RIPng only if they are for directly attached links or tunnels - No default route nor 5f00::/8 routes shld ever be advertized - more generaly, no routes with a prefixlength < 32 should ever be advertized. - Alain. From bmanning@ISI.EDU Tue Mar 4 18:08:30 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Tue, 4 Mar 1997 10:08:30 -0800 (PST) Subject: suspect routing? In-Reply-To: <970304192159.ZM4867@rama.imag.fr> from "Alain Durand" at Mar 4, 97 07:21:59 pm Message-ID: <199703041808.AA01106@zed.isi.edu> > > On Mar 4, 8:23am, bmanning@ISI.EDU wrote: > > Subject: suspect routing? > > > > Hi, > > What is the general take on mapped IPv4 address prefixes being > > propogated within 6bone, e.g. ::192.0.2.10 > > > > And I've found a recent "feature" that allows the propogation > > of the loopback address ::1 > > > My opinion is that: > > - IPv4 compatible routes should not be advertized Perhaps... > - Static routes should be injected in RIPng Why? > - No default route nor 5f00::/8 routes shld ever be advertized > - more generaly, no routes with a prefixlength < 32 should > ever be advertized. Here is an interesting question for the addressing crowd. Should CIDR style masking apply across the whole IPv6 address or do we respect the pro-forma segmenets in the preamble that indicate address type? For that matter, what happens with the new'n'improved RG+EID guck? For purposes of the discussion: bah#sh ipv6 rou sum IPv6 Routing Table Summary - 124 entries 4 local, 5 connected, 0 static, 115 RIP Number of prefixes: /1: 1, /2: 1, /32: 38, /48: 11, /64: 38, /80: 26, /127: 3, /128: 6 > - Alain. > -- --bill From bound@zk3.dec.com Tue Mar 4 19:29:13 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Tue, 04 Mar 97 14:29:13 -0500 Subject: Getting attached... In-Reply-To: Your message of "Mon, 03 Mar 97 13:53:50 PST." <199703032153.AA29151@zed.isi.edu> Message-ID: <9703041929.AA07146@wasted.zk3.dec.com> Bill, > > Note that an RFC1897 format address includes the ASN (Autonomous System > > Number) of one's provider, not an ASN that belongs to one's own site. > > (Though a provider uses its own ASN.) > > This is would make my address > > 5F: (01011111 == first 8 bits) > 0D: T > E9: +- 3561 (for MCI's ASN) > 00: (RES == reserved...?) > CE: 206. \ > 9C: 156. > our IPv4 class C subnet > 94: 148. / > 00: (RES == reserved...) >Hi, > It looks like the 0.0.9.e.d.0.f.5.ip6.int. entry is registered > to Jim Bound of DEC. It might be prudent to have MCI clarify > is delegation procedures for these test address blocks. > > Jim? I will have to check with MCI... This is a good point. Right now we are using 3561. But sipper is 206.152.163.3 so if one keeps searching on longest match it will eventually work out. But I would like to think we can stop per 1897 per the AS number. thanks /jim From guyd@uunet.pipex.com Tue Mar 4 21:44:27 1997 From: guyd@uunet.pipex.com (Guy Davies) Date: Tue, 4 Mar 1997 21:44:27 +0000 (GMT) Subject: suspect routing? In-Reply-To: <970304192159.ZM4867@rama.imag.fr> Message-ID: On Tue, 4 Mar 1997, Alain Durand wrote: > On Mar 4, 8:23am, bmanning@ISI.EDU wrote: > > Subject: suspect routing? > > > > Hi, > > What is the general take on mapped IPv4 address prefixes being > > propogated within 6bone, e.g. ::192.0.2.10 > > > > And I've found a recent "feature" that allows the propogation > > of the loopback address ::1 > > > My opinion is that: > > - IPv4 compatible routes should not be advertized I certainly agree with this. The injection of IPv6 compatible IPv4 addresses is bound to cause confusion and, as far as I can see, serves no useful purpose (please correct me on that last statement if I'm missing something obvious ;-) > - Static routes should be injected in RIPng > only if they are for directly attached links or tunnels This needs to be slightly widened to allow for any routes which are connected via a static route to an organisation using static routing to a RIPng site (I know this is unlikely but it's possible and so we should not preclude the injection of such routes into RIPng). I think the main aim of Alain's statement here is to avoid multihop statics which conflict with RIPng routes. I can say from first-hand experience that this can cause very strange problems which confused me and several others for most of a day. > - No default route nor 5f00::/8 routes shld ever be advertized Not onto the 6bone at large. You may want to advertise defaults to internal networks running RIPng which have access to only one router. > - more generaly, no routes with a prefixlength < 32 should > ever be advertized. Again, on the 6bone, this should _never_ be necessary. When mapped onto the "future Internet" running IPv6, it will clearly be feasible, given the proposed address usage (pre 8+8), for routes < /32 to be necessary. Just my thoughts. Guy > > - Alain. > From joda@pdc.kth.se Tue Mar 4 23:16:24 1997 From: joda@pdc.kth.se (Johan Danielsson) Date: 05 Mar 1997 00:16:24 +0100 Subject: ASNs and 1897 (was: Getting attached...) In-Reply-To: Jason Duerstock's message of Thu, 27 Feb 1997 20:15:51 -0500 (EST) References: Message-ID: Jason Duerstock writes: > > Note that an RFC1897 format address includes the ASN (Autonomous System > > Number) of one's provider, not an ASN that belongs to one's own site. > > (Though a provider uses its own ASN.) This is completely incomprehensible. Why should I use the ASN of my `provider' if I have one of my own (which is typically not the case)? Also, more or less by definition, if I have an AS number, I have more than one `provider'. Can someone clarify this? /Johan From bound@zk3.dec.com Wed Mar 5 03:17:49 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Tue, 04 Mar 97 22:17:49 -0500 Subject: ASNs and 1897 (was: Getting attached...) In-Reply-To: Your message of "05 Mar 97 00:16:24 +0100." Message-ID: <9703050317.AA12223@wasted.zk3.dec.com> Here is the issue for not having a unique ASN. I have to justify it. I have to do this in my spare time sorry. What I have to say is I am using IPv6 on the 6bone, etc. etc.. It will interesting if I get the unique ASN. See attached. /jim --------------------------------------------------------- Autonomous System (AS) is used for exchanging external routing information with other ASes through an exterior routing protocol. It is a connected group of IP networks which has a single and clearly defined routing policy. Unique Autonomous System Numbers (ASNs) are required for specific ASes. However, due to the finite number of available ASNs, care must be taken to determine which sites require unique ASNs and which do not. Those requests that do not require a unique AS should utilize one or more of the ASNs reserved by the Internet Assigned Numbers Authority (IANA) for private use. Those numbers are: 64512 through 65535. The following conditions must be met before being assigned a unique Autonomous System Number: Unique Routing Policy An AS is only needed when you have a routing policy which differs from your border gateway peers. ----------------- a) Unique Routing Policy Please explain how your routing policy is different from your provider. --------------------------------------------------- From hinden@ipsilon.com Wed Mar 5 06:21:00 1997 From: hinden@ipsilon.com (Bob Hinden) Date: Tue, 04 Mar 1997 22:21:00 -0800 Subject: ASNs and 1897 (was: Getting attached...) In-Reply-To: References: Message-ID: <3.0.1.32.19970304222100.00739448@mailhost.ipsilon.com> Johan, >> > Note that an RFC1897 format address includes the ASN (Autonomous System >> > Number) of one's provider, not an ASN that belongs to one's own site. >> > (Though a provider uses its own ASN.) > >This is completely incomprehensible. Why should I use the ASN of my >`provider' if I have one of my own (which is typically not the case)? >Also, more or less by definition, if I have an AS number, I have more >than one `provider'. The ASN of the provider was used because it would allow aggregation when there were multiple sites connected to the same provider. Also, as you point out not many sites have their own ASN. If a site has an ASN they essentially become a provider so in that case use your own ASN. Bob From dorian@cic.net Wed Mar 5 07:31:18 1997 From: dorian@cic.net (Dorian R. Kim) Date: Wed, 5 Mar 1997 02:31:18 -0500 (EST) Subject: New tunnels &c Message-ID: Added backbone tunnel to DIGITAL-CA Added tunnel to RISQ and added three "experimental" tunnels to ISI, Sprint and AATECH. site: CICNet primary AS location: Downers Grove, Illinois, USA prefix: 5F04:C900::/32 ping: 5F04:C900:8367:0100:0001::0C8E:50C2 6bone.chicago.cic.net tunnel: 131.103.1.54 192.31.7.104 CISCO - RIPng - operational tunnel: 131.103.1.54 132.250.90.3 NRL - RIPng - operational tunnel: 131.103.1.54 128.223.222.11 UOregon - RIPng - operational tunnel: 131.103.1.54 198.108.60.153 MERIT - RIPng - operational tunnel: 131.103.1.54 128.173.88.83 VT - static - operational tunnel: 131.103.1.54 192.87.110.60 SURFNET - RIPng - operational tunnel: 131.103.1.54 198.128.2.27 ESNET - RIPng - operational tunnel: 131.103.1.54 128.176.191.66 JOIN - RIPng - operational tunnel: 131.103.1.54 192.220.249.249 NWNET - RIPng - operational tunnel: 131.103.1.54 208.9.2.220 Sprint - RIPng - experimental tunnel: 131.103.1.54 128.9.160.26 ISI - RIPng - experimental tunnel: 131.103.1.54 206.156.148.9 AATECH - static - experimental tunnel: 131.103.1.54 204.123.2.236 DIGITAL-CA - RIPng - operational tunnel: 131.103.1.54 192.26.210.5 RISQ - static - operational contact: Dorian Kim contact: CICNet Network Systems status: operational since 1/21/97 remark: 6bone.chicago.cic.net is a transit only tunnel fanout box remark: 6bone.chicago.cic.net is a cisco 2501 remark: will happily add transit tunnels to folks with following ipv4 remark: connectivity: CICNet, OARnet, Michnet, ESnet, MCI, DIGEX remark: please report any problems to contact above. changed: dorian@cic.net 970305 source: RIPE -dorian From Alain.Durand@imag.fr Wed Mar 5 15:47:56 1997 From: Alain.Durand@imag.fr (Alain Durand) Date: Wed, 5 Mar 1997 16:47:56 +0100 Subject: suspect routing? In-Reply-To: Guy Davies "Re: suspect routing?" (Mar 4, 9:44pm) References: Message-ID: <970305164756.ZM5985@rama.imag.fr> On Mar 4, 9:44pm, Guy Davies wrote: > Subject: Re: suspect routing? > > - No default route nor 5f00::/8 routes shld ever be advertized > > Not onto the 6bone at large. You may want to advertise defaults to > internal networks running RIPng which have access to only one router. Perfectly right. I was only talking about route advertisements among core routers. - Alain. From crawdad@fnal.gov Wed Mar 5 14:43:40 1997 From: crawdad@fnal.gov (Matt Crawford) Date: Wed, 05 Mar 1997 08:43:40 -0600 Subject: ASNs and 1897 (was: Getting attached...) In-Reply-To: "05 Mar 1997 00:16:24 +0100." <"xofd8tfjliv.fsf"@blubb.pdc.kth.se> Message-ID: <199703051443.IAA02141@gungnir.fnal.gov> > Jason Duerstock writes: > > > Note that an RFC1897 format address includes the ASN (Autonomous System > > > Number) of one's provider, not an ASN that belongs to one's own site. > > > (Though a provider uses its own ASN.) > > This is completely incomprehensible. Why should I use the ASN of my > `provider' if I have one of my own (which is typically not the case)? Hoping that I am not the Nth to answer (for N >> 1) ... You use the ASN of the provider who gives you a 6bone link because that way the address prefixes aggregate well. My site has an ASN of its own, and has multiple connections to the world, but my IPv6 testing prefix incorporates the ASN of the provider who is at the other end of my external IPv6 tunnel. > Also, more or less by definition, if I have an AS number, I have more > than one `provider'. Consider just your primary, or your only, IPv6 connection. From bmanning@ISI.EDU Wed Mar 5 16:12:47 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Wed, 5 Mar 1997 08:12:47 -0800 (PST) Subject: The bad idea fairy Message-ID: <199703051612.AA02019@zed.isi.edu> > > I don't think you meant to announce these to me. I'll filter the defaults on > > my end: > > > While thats fine, its not clear to me why we are labeling these > prefixes "bad"/"martian" up front. > > Why are IPv4 mapped addresses "bad"? The current answer is that > they are "confusing". Not good enough by me. > > The other, larger question is, do the cidr rules apply across the > whole IPv6 address? If so, why? > > I'll note that in the IPv4 > world, I can aggregate across the whole address range and even > announce it (or large chucks thereof) (see the 1/4 default that > sprint was running for a brief period... 192/3) > > Then there is the subordinate query about the IPv6 equivalents of > /31 and /32 announcements. Yes, host routes are pathological. > Why can't ciscos generate a true /128 announcement? -- bill From bmanning@ISI.EDU Wed Mar 5 16:46:29 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Wed, 5 Mar 1997 08:46:29 -0800 (PST) Subject: IPv4 routes 'leaking' into RIPng (BIF) Message-ID: <199703051646.AA02190@zed.isi.edu> > > What benefit was it giving you? Surely, an IPv6 > > compatible IPv4 route is either going to be auto-tunnelled or routed via > > IPv4. > > Well, call me loony, but I thought that part of the idea behind 6bone was to > explore/examine the extent of the IPv6 feature set, particularly the -very- > primitive routing capabilities. > > I think the injection of this "spurious" route raised a couple of interesting > questions. One respones was, "its confusing" and there are your assertions > above about autotunneling or routed via IPv4. A careful examination of > the prefix I injected will show that the IPv4 equivalent is never supposed > to be routed in the IPv4 infrastructure. A rough equal to the RFC 1918 > blocks. > > I think that before we, as operators, start making restrictive choices on > IPv6 routing implementations, we should really have better criteria that > the subjective assertions that have thus far been made. The prefix in question was ::192.0.2.10 -- bill From tdyas@xenophanes.rutgers.edu Thu Mar 6 05:51:45 1997 From: tdyas@xenophanes.rutgers.edu (Tom Dyas) Date: Thu, 6 Mar 97 0:51:45 EST Subject: adding registry info Message-ID: What is the proper ftp group password to add an entry to the RIPE-NCC info list? Tom Tom Dyas tdyas@noc.rutgers.edu Network Operations Group http://www-no.rutgers.edu/~tdyas/ Rutgers University Computing Services 908-445-5683 From RLFink@lbl.gov Thu Mar 6 16:44:57 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 6 Mar 1997 08:44:57 -0800 Subject: 2nd Tshirt order list 6Mar97 0840 Message-ID: Current 2nd order list for 6bone Tshirts. This darn thing keeps growing...didn't know Tshirts were so popular. I'm gone 10-12 March, and thus plan to submit the order to the Tshirt printer next Friday (March 14). Get your changes and orders to me by then...this will be the LAST call. Thanks, Bob ================================================================================ Asayesh, Hamid 1 XXL no address on file Banerjee, Partha 2 L address on file Barnes, Greg 2 XL, 2 XXL address on file Behrle, Jeremy 1 XXL address on file Blanchet, Marc 4 L address on file Boneparth, David 1 XL aaddress on file Bourgeois, Judd 1 XL address on file Caron, Paul 2 L address on file Clark, Alex 4 M, 14 XL, 2 XXL address on file Cully, Brian 1 XL address on file Dewell, Aaron 1 L, 1 XL address on file Fenwick, Wynn 1 XL, 1 XXL address on file Hankins, Greg 1 M address on file Harrison, Jeff 1 XL address on file Hoag, Andrew 1 XXL address on file Jin, Bih-Huang 1 L address on file King, Paul 2 XXL address on file Kyriannis, Jimmy 1 L, 1 XL address on file Laird, Scott 5 L, 9 XL address on file Lekashman, John 2 S, 1 XL, 1 XXL address on file Lerperger, Michael 1 XL address on file Levenberg, Richard 2 L address on file Lewis, David 1 XXL address on file Mankin, Allison 2 M, 2 L address on file Markov, Igor 1 M address on file Martin, David 1 L address on file Metz, Craig 1 L address on file, prepaid Ramanan PS 2 L address on file Snyder, Larry 2 XL address on file Stewart, John 1 XL address on file Sullivan, Don 1 M address on file Tannenbaum, Andrew 1 XL address on file Virgilio, Vincenzo 2 XL, 1 L address on file Watson, Robert 3 XL address on file Wedgwood, Chris 1 L address on file Whalen, Matthew 1 L address on file Winchcombe, Charlie 5 XXL address on file, prepaid ================================================================================ Please send NO checks/money until after you have received your Tshirt(s) in the mail. When you do send a check (only upon receipt of Thsirts) please make it out to Robert L. Fink and mail to: Robert L. Fink 3085 Buena Vista Way Berkeley, CA 94708 USA ================================================================================ From vito@pan.cib.na.cnr.it Fri Mar 7 11:27:07 1997 From: vito@pan.cib.na.cnr.it (Franceso Vitobello) Date: Fri, 7 Mar 1997 12:27:07 +0100 Subject: No subject Message-ID: <199703071127.MAA01118@pan.cib.na.cnr.it> New site to ping : site: CIB-NA-CNR location: Arco Felice, Naples, ITALY prefix: 5f16:4d00:8ca4::/48 ping: 5f16:4d00:8ca4:100::2812:606b tunnel: 140.164.1.9 163.162.17.77 CSELT contact: Francesco Vitobello Luca Sabio status: operational since March 6, 1997 remark: report any problems please changed: Francesco Vitobello source: RIPE From Waltraud.Erber@ecrc.de Fri Mar 7 14:25:34 1997 From: Waltraud.Erber@ecrc.de (Waltraud Erber) Date: Fri, 07 Mar 1997 15:25:34 +0100 Subject: ECRC newly connected Message-ID: <199703071423.PAA11133@scorpio.ecrc.de> Hello, hopefully ping-able is: site: ECRC location: Munich, Germany loc-string: ??? prefix: 5f04:f900::0/32 ping: 5f04:f900:8d01:200:2:800:2071:18ae tunnel: 141.1.2.3 130.225.231.5 UNI-C contact: Waltraud.Erber@ecrc.de, Joerg.Lehrke@ecrc.de status: operational remark: Solaris 2.5 - ipv6 Version5-0 source: RIPE changed: wer@ecrc.de 970226 -- -- Waltraud Erber => Tel. +49 89 926 99180 ECRC European Computer Research Centre => Fax. +49 89 926 99170 Arabellastr. 17, 81925 Munich, Germany => E-Mail: wer@ecrc.de From RLFink@lbl.gov Fri Mar 7 18:33:54 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 7 Mar 1997 10:33:54 -0800 Subject: slow 6bone diagram update Message-ID: Sorry to be so slow on updating the 6bone diagrams. I am aggregating changes as I have been swamped. Will do a big update next week. Thanks for you patience. Bob From bound@zk3.dec.com Fri Mar 7 21:07:48 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Fri, 07 Mar 97 16:07:48 -0500 Subject: Using the 6bone in the public on the West Coast Message-ID: <9703072107.AA31533@wasted.zk3.dec.com> Next week we will be showing an IPv6 WWW page btw Internet World in L.A. and Uniforum at San Francisco using our port of Appache Server and Arena browser over the 6bone. This will debut our IPv6 Alphaserver for IPv6 Early Adopters to get on the 6bone and start using IPv6. www.digital.com/info/alphaserver/ ..... Its not toast yet but its baking.... /jim From hinden@ipsilon.com Fri Mar 7 21:48:30 1997 From: hinden@ipsilon.com (Bob Hinden) Date: Fri, 07 Mar 1997 13:48:30 -0800 Subject: Using the 6bone in the public on the West Coast In-Reply-To: <9703072107.AA31533@wasted.zk3.dec.com> Message-ID: <3.0.1.32.19970307134830.006df9b4@mailhost.ipsilon.com> Jim, >Next week we will be showing an IPv6 WWW page btw Internet World in L.A. >and Uniforum at San Francisco using our port of Appache Server and Arena Cool! Very nice work! Bob From froboy@jedi.transient.net Sun Mar 9 00:30:34 1997 From: froboy@jedi.transient.net (froboy) Date: Sat, 8 Mar 1997 19:30:34 -0500 (EST) Subject: Connectivity Message-ID: Hello there, I am part of a small northeastern U.S. freenet called Transient Systems. Transient Systems is interested in putting a site on the 6bone. The link that we would like to do this through is a 56K Circuit Switched Voice Line that we do dedicated dial-up with. I am curious if anyone can refer us to someone in Massachusetts, in the Boston/Arlington area so we may get a tunnel. Any help would be much appreciated. thank you, andrew d. tannenbaum System Administrator -- Transient Systems froboy@transient.net From bound@zk3.dec.com Sat Mar 8 05:26:18 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Sat, 08 Mar 97 00:26:18 -0500 Subject: Connectivity In-Reply-To: Your message of "Sat, 08 Mar 97 19:30:34 EST." Message-ID: <9703080526.AA27424@wasted.zk3.dec.com> Andrew... I suggest going thru UNH or Bay Networks in New England depending on which provider you have. You can get contact via the Ripe NCC. /jim From JOIN Project Team Mon Mar 10 12:47:10 1997 From: JOIN Project Team (JOIN Project Team) Date: Mon, 10 Mar 1997 11:47:10 -0100 (GMT) Subject: changed ping-statistic Message-ID: Hi, we moved our 6bone ping statistic page to http://www.join.uni-muenster.de/JOIN/ipv6/texte-englisch/ping-list.html The major change is that the list is generated automatically once a night based on the information in the RIPE registry now. Additionaly we included flags to check the DNS and reverse DNS service for each site. Like before all listed sites are pinged hourly. If somebody doesn't like to be pinged please drop us a short note... Hope it's a useful information for you, all the best - 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 31639, fax: +49 251 83 31653, email: wessend@uni-muenster.de ------------------------------------------------------------------------------ From tdyas@xenophanes.rutgers.edu Tue Mar 11 03:03:31 1997 From: tdyas@xenophanes.rutgers.edu (Tom Dyas) Date: Mon, 10 Mar 97 22:03:31 EST Subject: reverse delegation Message-ID: Who would I have to talk with to get a delegation for ip6.int.? Tom Tom Dyas tdyas@noc.rutgers.edu Network Operations Group http://www-no.rutgers.edu/~tdyas/ Rutgers University Computing Services 908-445-5683 From johnc@cac.washington.edu Tue Mar 11 18:49:16 1997 From: johnc@cac.washington.edu (John Carlson) Date: Tue, 11 Mar 1997 10:49:16 -0800 (PST) Subject: New Tunnel Message-ID: A tunnel has been established between the University of Washington and NWNet: site: UW location: University of Washington, Seattle, WA USA loc-string: 49 39 42n 122 18 45w prefix: 5F02:AD00:8C8E/48 ping: chickadee.ipv6.washington.edu 5F02:AD00:8C8E::60:A0:2470:63EC tunnel: 140.142.96.1 192.220.249.249 NWNET contact: johnc@cac.washington.edu status: operational 970306 remark: chickadee.ipv6.washington.edu is a pentium/133 linux 2.1.27 changed: johnc@cac.washington.edu 970311 source: RIPE johnc ------------------------------------------------------------------------------- John D. Carlson Networks and Distributed Computing EMAIL: johnc@cac.washington.edu University of Washington BELL: (206) 685-6204 4545 15th Ave NE FAX: (206) 685-4044 Seattle, WA 98105 From bmanning@ISI.EDU Tue Mar 11 19:21:38 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Tue, 11 Mar 1997 11:21:38 -0800 (PST) Subject: While Waiting... Message-ID: <199703111921.AA19977@zed.isi.edu> Trying to follow in the grand tradition, and while waiting for the majic strings to pop up from my mailing list search (anyone care to pass on the group id/password so I can update these objects on the RIPE ftp service?) I offer up these two new objects. The one is at ISI and the other is one hop off the LA exchange point, sometimes called MAE-LA. site: ISI-6BONE location: Los Angeles prefix: 5FBC:1100/32 ping: 5FBC:1100::8009:A01A tunnel: 128.9.160.26 192.31.7.104 CISCO/US RIPng operational tunnel: 128.9.160.26 198.32.146.11 LAP/US RIPng operational tunnel: 128.9.160.26 131.103.1.54 CICNET/US RIPng operational contact: bill manning status: operational since Mar-97 remark: DNS operational for reverse zones changed: bmanning@isi.edu 970311 source: RIPE site: LAP-EXCHANGE location: Los Angeles prefix: 5FBC:1000/32 ping: 5FBC:1000::C620:920B tunnel: 198.32.146.11 128.9.160.26 LAP/US RIPng operational contact: bill manning status: operational since Mar-97 remark: DNS operational for reverse zones remark: Willing to add tunnels on request remark: One hop from Genuity/Cerfnet/LosNettos/InterNex & others changed: bmanning@isi.edu 970311 source: RIPE Anyone wishing to setup a tunnel to either should email me and I'll get back in touch. Note that I'd prefer to host the tunnels off the LAP point, with the exception of the CARIN/DARTNET/SCAN links that terminate inside ISI, if they would like to move. --bill From RLFink@lbl.gov Wed Mar 12 05:12:16 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 11 Mar 1997 21:12:16 -0800 Subject: www.6bone.net In-Reply-To: Message-ID: At 2:08 AM -0800 3/8/97, Lars Fenneberg wrote: >Hi Bob! > > A few days ago I suggested registering 6bone.net to use it > for www.6bone.net. I only got one (positive) response in > private mail but no further feedback. > > So, what do you think as the one hosting the 6bone homepage? That I will probably do this (i.e., register www.6bone.net or ,org or both). Stay tuned. Thanks, Bob From stuart.prevost@bt-sys.bt.co.uk Wed Mar 12 12:55:50 1997 From: stuart.prevost@bt-sys.bt.co.uk (Stuart Prevost) Date: Wed, 12 Mar 1997 12:55:50 -0000 Subject: New tunnel Message-ID: Added new tunnel to IFB to tie in with 6bone overview diagram site: BT Labs, Martlesham Heath location: Suffolk, UK loc-string: 52 03 52n 01 17 16e prefix: 5f06:d800/32 ping: 5f06:d800:c171:3a00::1 tunnel: 193.113.58.75 194.105.166.254 IFB tunnel: 193.113.58.75 132.250.90.5 NRL tunnel: 193.113.58.75 148.88.153.38 ULANC contact: Stuart Prevost status: operational remark: IPv6 for Solaris 2.5.1 changed: stuart.prevost@bt-sys.bt.co.uk 970312 source: RIPE Regards Stuart From guyd@uunet.pipex.com Fri Mar 14 15:20:40 1997 From: guyd@uunet.pipex.com (Guy Davies) Date: Fri, 14 Mar 1997 15:20:40 +0000 (GMT) Subject: UUNET/UK update Message-ID: Hi All, UUNET/UK now has a second ipv6 router at our PoP in Telehouse, London. We are happy to setup tunnels when asked, particularly to organisations with connectivity to LINX in Telehouse, DGIX in Stockholm, AMS-IX in Amsterdam and the UUNET global infrastructure. We can currently support RIPng and static routing. A public thankyou to all the folks to whom we already have tunnels for their patience and help while I chased problems round the net during the installation of the second router. It's amazing the problems one little typo can cause . Our current ip6rr record is as follows.... site: UUNET-UK location: Cambridge, UK prefix: 5f07:3900/32 ping: 5f07:3900:9e2b:8500:0000:1111:1111:1111 6bone-gw.lon.ip6.pipex.net ping: 5f07:3900:9e2b:c000:0000:0060:3e59:4d90 eth0.6bone-gw.lon.ip6.pipex.net ping: 5f07:3900:9e2b:8500:0000:2222:2222:2222 6bone-gw.cam.ip6.pipex.net ping: 5f07:3900:9e2b:8900:0098:0000:0c92:145c eth0.6bone-gw.cam.ip6.pipex.net ping: 5f07:3900:00c2:8200:0000:0000:c00d:03c4 swannee.ip6.pipex.net tunnel: 158.43.133.254 192.31.7.104 CISCO/US RIPng operational tunnel: 158.43.133.254 192.32.29.62 BAY/US RIPng operational tunnel: 158.43.133.254 192.220.249.249 NWNET/US RIPng operational tunnel: 158.43.133.254 194.182.135.253 TELEBIT/DK RIPng operational tunnel: 158.43.133.254 194.105.166.254 IFB/UK RIPng operational tunnel: 158.43.133.254 130.225.231.5 UNI-C/DK RIPng operational tunnel: 158.43.133.254 193.10.66.50 SICS/SE RIPng operational tunnel: 158.43.133.254 204.123.2.236 DIGITAL-CA/US RIPng operational tunnel: 158.43.133.254 192.87.110.60 SURFNET/NL RIPng operational tunnel: 158.43.133.254 194.226.128.99 KIT/KZ static operational tunnel: 158.43.133.254 152.78.65.209 USOT-ECS/UK static operational tunnel: 158.43.133.254 194.80.33.20 ULANC/UK RIPng operational contact: IPv6 operations status: operational since 20-Feb-97 remark: DNS operational for forward (ip6.pipex.net) and reverse remark: zones remark: http://swannee.ip6.pipex.net:81/index.html remark: Willing to add tunnels on request changed: Guy.Davies@uunet.pipex.com 970313 source: RIPE Finally, plans are afoot with various UK organisations (incl. IFB and USOT-ECS) to finally get the UK connectivity into shape. We're kind of waiting for the murmurings from UKERNA/JANET to get a bit louder ;-) Regards, Guy From RLFink@lbl.gov Fri Mar 14 19:34:52 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 14 Mar 1997 11:34:52 -0800 Subject: new 6bone backbone drawing Message-ID: New 6bone backbone links drawing is now up (Version 6). Lot's of changes! I'll try to get the new site diagram up later today. Bob From RLFink@lbl.gov Sat Mar 15 01:29:05 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 14 Mar 1997 17:29:05 -0800 Subject: new 6bone diagram version 55 Message-ID: I've just put up a new 6bone diagram (version 55) with lots of changes. As I was pushed to finish it today, I haven't made the site names hot links and won't until Monday. The b/b links button is still hot though. As usual, I've made some value judgements on what b/b to connect to some sites. If you object to anything, please let me know. The old picture is still available as: http://www-6bone.lbl.gov/6bone/6bone-drawingv54.html Thanks, Bob From jang@sps.nl Mon Mar 17 08:28:10 1997 From: jang@sps.nl (Gils van, Jan) Date: Mon, 17 Mar 1997 09:28:10 +0100 Subject: IPv6 reservations ? Message-ID: Hi, Thanks for reading, I am wondering the following : In the IPv4 reservations is number 44.x.x.x reserved for radio amateurs so they can experiment with wireless data communication. Are there also reservations or agreements for IPv6 numbers for radio amateurs. By asking this question I am also wondering if there are any developers out there who are already building IPv6 stacks in NOS versions. I hope to hear from someone.... Jan H. van Gils e-Mail janvg@knoware.nl / pe1mhp@amsat.org ___________________________________________________________________ Jan H. van Gils | Software Productivity Solutions jang@sps.nl | P.O. box 92 2810 AB Reeuwijk +31 (0)182-396866 | Fokkerstraat 16 2811 ER Reeuwijk ------------------------------------------------------------------- From carlos.picoto@di.fc.ul.pt Mon Mar 17 11:35:07 1997 From: carlos.picoto@di.fc.ul.pt (Carlos Picoto) Date: Mon, 17 Mar 1997 11:35:07 -0000 Subject: IPv6 reservations ? Message-ID: <01BC32C7.447A55C0@eagle.di.fc.ul.pt> Jan, Jan>In the IPv4 reservations is number 44.x.x.x reserved for radio amateurs Jan>so they can Jan>experiment with wireless data communication. Jan> Jan>Are there also reservations or agreements for IPv6 numbers for radio Jan>amateurs. I would use ::44.x.x.x IPv6 addresses for that purpose. Jan> Jan>By asking this question I am also wondering if there are any developers Jan>out there Jan>who are already building IPv6 stacks in NOS versions. A Linux box would do the same. ./Carlos Picoto University of Lisbon CT1DYE / ::44.158.13.1 From jcday@jpd.ch.man.ac.uk Mon Mar 17 15:44:42 1997 From: jcday@jpd.ch.man.ac.uk (Jonathan Day) Date: Mon, 17 Mar 1997 09:44:42 -0600 (CST) Subject: Updated entry for UMAN Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1484945164-1553613669-858613482=:464 Content-Type: TEXT/PLAIN; charset=US-ASCII --1484945164-1553613669-858613482=:464 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=UMAN Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: c2l0ZToJCVVuaXZlcnNpdHkgb2YgTWFuY2hlc3Rlcg0KbG9jYXRpb246CVVu aXZlcnNpdHkgb2YgTWFuY2hlc3RlciwgTWFuY2hlc3RlciwgRW5nbGFuZA0K bG9jLXN0cmluZzoJNTMgNDQgMG4gMDIgMzIgMDB3DQpwcmVmaXg6CQk1ZjAz OjEyMDA6ODI1ODowYzAwLzY0DQpwaW5nOgkJNWYwMzoxMjAwOjgyNTg6MGMw MDo6MQlqcGQuaXA2LmNoLm1hbi5hYy51aw0KdHVubmVsOgkJMTMwLjg4LjEy LjExOQkxOTQuMTA1LjE2Ni4yNTQJSUZCCQlzdGF0aWMNCnR1bm5lbDoJCTEz MC44OC4xMi4xMTkJMTQ4Ljg4LjE1My4zOAlVTEFOQwkJUklQbmcNCnR1bm5l bDoJCTEzMC44OC4xMi4xMTkJMTMxLjExMS4xOTMuMTA0CVVDQU0tVAkJc3Rh dGljDQp0dW5uZWw6CQkxMzAuODguMTIuMTE5CTE5Mi42Ny43Ni4xOQlVTAkJ c3RhdGljDQp0dW5uZWw6CQkxMzAuODguMTIuMTE5CTE1Mi43OC42NS4yMDcJ VVNPVC1FQ1MJc3RhdGljDQp0dW5uZWw6CQkxMzAuODguMTIuMTE5CTE5My4z Mi4xLjY2CVRJQ0wJCXN0YXRpYw0KdHVubmVsOgkJMTMwLjg4LjEyLjExOQkx NTguNDMuMTMzLjI1NAlVVU5FVAkJUklQbmcNCmNvbnRhY3Q6CUpvbmF0aGFu IERheQk8amNkYXlAanBkLmNoLm1hbi5hYy51az4NCnN0YXR1czoJCW9wZXJh dGlvbmFsDQpyZW1hcms6CQlUaGlzIG5vZGUgbWF5IGJlIHN1YmplY3QgdG8g cmVvcmdhbmlzaW5nLg0KcmVtYXJrOgkJUnVubmluZyBJUHY2LWF3YXJlIG5h bWVzZXJ2ZXIsIEZUUCBzZXJ2ZXIgYW5kIFNlbmRtYWlsLg0KY2hhbmdlZDoJ amNkYXlAanBkLmNoLm1hbi5hYy51ayA5NzAzMTcNCnNvdXJjZToJCVJJUEUN Cg== --1484945164-1553613669-858613482=:464-- From RLFink@lbl.gov Mon Mar 17 19:04:02 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 17 Mar 1997 11:04:02 -0800 Subject: new 6bone b/b links diagram (version 7) Message-ID: New 6bone b/b links diagram (version 7) showing a few more RIPng links for UUNET/UK. Bob From RLFink@lbl.gov Mon Mar 17 21:26:06 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 17 Mar 1997 13:26:06 -0800 Subject: list of IPv6 applications? Message-ID: Is there any list of applications converted to IPv6 to date? If not, we should think of generating one and keeping it available thru the 6bone pages. If anyone wants to forward me info I'll attempt one. Thanks, Bob From crawdad@fnal.gov Mon Mar 17 23:31:22 1997 From: crawdad@fnal.gov (Matt Crawford) Date: Mon, 17 Mar 1997 17:31:22 -0600 Subject: list of IPv6 applications? In-Reply-To: "17 Mar 1997 13:26:06 PST." <"v0300780baf53670bc818"@[128.3.9.22]> Message-ID: <199703172331.RAA27730@gungnir.fnal.gov> > Is there any list of applications converted to IPv6 to date? Do you want to list what each implementor is shipping with their early test code? Or are you only asking what's been done outside of IPv6 stack development? > If anyone wants to forward me info I'll attempt one. Mostly I'm using Solaris, and it includes IPv6 versions of telnet, ftp, tftp, finger (client and server) Berkeley r-commands (client and server) inetd, sendmail mosaic, httpd nslookup, named From jimmy.kyriannis@nyu.edu Tue Mar 18 00:30:46 1997 From: jimmy.kyriannis@nyu.edu (Jimmy Kyriannis) Date: Mon, 17 Mar 1997 19:30:46 -0500 Subject: list of IPv6 applications? In-Reply-To: Message-ID: Perhaps, in addition to that, a list of services available on the 6bone. From the user perspective, once on the 6bone, there's not all that much "to do". Jimmy At 4:26 PM -0500 3/17/97, Bob Fink LBNL wrote: >Is there any list of applications converted to IPv6 to date? > >If not, we should think of generating one and keeping it available thru the >6bone pages. > >If anyone wants to forward me info I'll attempt one. > > >Thanks, > >Bob From kann@CS.UCLA.EDU Tue Mar 18 01:26:16 1997 From: kann@CS.UCLA.EDU (Jong Kann) Date: Mon, 17 Mar 1997 17:26:16 -0800 (PST) Subject: list of IPv6 applications? Message-ID: <199703180126.RAA03762@dew> Just for your information, we have ported SDR and VAT to IPv6 in the UCLA Internet Research Lab. Now they run on Solaris IPv6 and FreeBSD with INRIA IPv6. Jong Kann > > Is there any list of applications converted to IPv6 to date? > > Do you want to list what each implementor is shipping with their > early test code? Or are you only asking what's been done outside of > IPv6 stack development? > > > If anyone wants to forward me info I'll attempt one. > > Mostly I'm using Solaris, and it includes IPv6 versions of > > telnet, ftp, tftp, finger (client and server) > Berkeley r-commands (client and server) > inetd, sendmail > mosaic, httpd > nslookup, named > From RLFink@lbl.gov Tue Mar 18 01:57:28 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 17 Mar 1997 17:57:28 -0800 Subject: new 6bone diagram - version 56 Message-ID: New diagram has hot buttons active again, and some rehoming and a few new sites. Bob From RLFink@lbl.gov Tue Mar 18 03:02:09 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 17 Mar 1997 19:02:09 -0800 Subject: new JOIN and POLITO stats pages via 6bone web page Message-ID: Have added the new POLITO and JOIN stats page pointers to the 6bone stats page: http://www.join.uni-muenster.de/JOIN/ipv6/texte-englisch/ping-list.html http://www.ipv6.polito.it/test/history.html Bob From Francis.Dupont@inria.fr Tue Mar 18 10:53:36 1997 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Tue, 18 Mar 1997 11:53:36 +0100 Subject: list of IPv6 applications? In-Reply-To: Your message of Mon, 17 Mar 1997 13:26:06 PST. Message-ID: <199703181053.LAA27591@givry.inria.fr> In your previous mail you wrote: Is there any list of applications converted to IPv6 to date? If not, we should think of generating one and keeping it available thru the 6bone pages. If anyone wants to forward me info I'll attempt one. => there is no such list but there is a list per implementations... Francis.Dupont@inria.fr PS: for myself : basic API : resolver library, named, named-xfer, nslookup, addr, host, ... rcmd/rresvport system applications : ifconfig, route, arp, netstat, lsof, sysctl, ping, traceroute, network tools : libpcap/tcpdump, ttcp, pppd network clients : finger, ftp, telnet, tftp, rcp, rlogin, rsh, rdate network servers : inetd, fingerd, ftpd, telnetd, tftpd, sendmail, rexecd, rlogind, rshd web : apache, mmm, v6 (browser and proxy written in Object CAML) TODO : MH, NTP, Netperf, Sun RPC (including NFS), X11, GateD, vat/vic/sdr, .... From alex@ifb.net Tue Mar 18 11:27:45 1997 From: alex@ifb.net (Alex Clark) Date: Tue, 18 Mar 1997 11:27:45 -0000 Subject: list of IPv6 applications? Message-ID: <01BC338F.672EEE00@centaur.ifb.net> Is there any list of applications converted to IPv6 to date? If not, we should think of generating one and keeping it available thru = the 6bone pages. Thats a mighty fine idea, we have spent an age looking for an IPv6 web = server and are about to embark upon the search for an IPv6 aware = browser. Any idea if FTP's software supports IPv6 in anything except the = stack? All the bundled applications (browser, e-mail, etc) do not = support IPv6 as far as I know. Is this true? Alex Clark --------------------------------------- alex@ifb.net Business Development http://www.ifb.net Internet For Business Tel: +44 (0) 1224 333300 387 Union Street, DDI: +44 (0) 1224 333333 Aberdeen, UK. AB11 6BX --------------- Fax: +44 (0) 1224 333331 From goode@nc3a.nato.int Tue Mar 18 14:22:52 1997 From: goode@nc3a.nato.int (Rob Goode) Date: Tue, 18 Mar 1997 14:22:52 +0000 Subject: 6bone attachment point Message-ID: <332EA53C.31A7@nc3a.nato.int> Dear Sirs, please could you tell me which would be the most appropriate attachement point to the 6bone for us. Our provider is NL-NET in the Netherlands (Holland). Yours sincerely, Rob Goode Communications Techniques Branch Communications Systems Division NATO C3 Agency PO Box 174 2501 CD Den Haag The Netherlands Email: goode@nc3a.nato.int Tel: +31 70-314-2442 Fax: +31 70-314-2176 From dlee@visc.vt.edu Tue Mar 18 19:58:01 1997 From: dlee@visc.vt.edu (David Lee) Date: Tue, 18 Mar 1997 14:58:01 -0500 (EST) Subject: 6bone Routing Registry Message-ID: <199703181958.OAA09634@ocarina.visc.vt.edu> Bob and I were discussion how to list internal sites, or internal nodes within a site. For example, VT-EE, VT-BEV, etc. are considered nodes within the VT IPv6 AS. They are all under the same prefix and same regulatory policies. We were in the general agreement that the registry should only list sites as opposed to internal sites/nodes. Thus, VT-EE would not get a separate registry entry but can show up on the VT registry entry. However, there's some merit to having separate entries, so I'm putting this out for comments. Bob, feel free to step in anytime you want. :) Additionally, I'm expecting to get some native IPv6 routed subnets up for testing and there appears to be no way to designate this in the current RIPE registry format. First off, there is some question of whether or not to even designate this. Assuming that we want to designate it, which I would think that we would, then, I would think that the format needs to be the same as the tunnel designation. Thus, I would proposed the following. native: [iif addr] [oif addr] [other site] [rp type] [status] {type} where: iif ipv4 - Address of the routed subnet for the router's input interface address oif ipv4 - Address of the routed subnet for the outgoing interface site - Outgoing interface site name rp type - Routing protocol type. RIPng, static, etc. status - One of the following: oper/u "operational" status and link up oper/d "operational" status (or was ;) and link down expr/u "experimental" status and link up expr/d "experimental" status and link down type - Optional field of the format XY, where X is one of: u - feed to a upstream site d - feed to a downstream site (which may or may not be a leaf) t - feed to a "lateral" transit site (e.g., other backbone) l - feed to a downstream leaf site And Y is a number from 1 to 9, where 1 designates a primary feed, 2 designates a secondary feed, and so forth. An example of a machine with two interfaces would be: native: 128.173.88.118 128.173.89.100 VT-EE-NETLAB RIPng expr/u l1 I was also thinking of including the routed subnet's IPv6 prefix but I think that's unnecessary information. The going assumption is that the routed subnet's prefix is some portion of the destination site's prefix. I would also advocate that internal sites/nodes be listing according to the format [registry entry]-[internal name] I would note that if we start to match the production IPv4 network, then we'll have many of these native entries. When (and not if ;) we get to that point, I would propose that we only list the border router(s) for the native routed site. One of the justifications for having native routed nodes listed now is for people to see how many of these we actually have. This gives us an idea of penetration and can also be used on a marketing side. When we have a significant amount of sites that are native routed, the technical information need is reduced and we also have a much different and stronger selling point on IPv6 rollout. The only thing that differs from standard practice is the feed type. I believe that the feed type information will help people get a better understanding of how a site is connected. I would, naturally, advocate that the tunnel registry information (http://www-cnr.lbl.gov/6bone/6bone-register.html) be changed to 1) reflect standard convention and 2) include the proposed feed type information. Thus, the format should be: tunnel: [source addr] [dest iaddr] [site] [rp type] [status] {type} Regards, DCL -- David C. Lee, EE PhD student - http://www.visc.vt.edu/~dlee - dlee@vt.edu PHONE: 1-540-231-8398 | FAX: 1-540-231-3362 | LOCATION: 475 Whittemore Hall Virginia Tech Information Systems Center, Blacksburg, Virginia 24061-0111 From bmanning@ISI.EDU Tue Mar 18 21:52:15 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Tue, 18 Mar 1997 13:52:15 -0800 (PST) Subject: 6bone Routing Registry In-Reply-To: <199703181958.OAA09634@ocarina.visc.vt.edu> from "David Lee" at Mar 18, 97 02:58:01 pm Message-ID: <199703182152.AA09030@zed.isi.edu> Interesting... I've been batting around an alternative method and have David Kessens interest. The trick is to encode the keywords in the DNS and then walk the ip6.int tree to collect the required data. This scheme has the advantage that the delegation and SOA can be signed to authenticate legitimate heirarchy. The other big win is that the data is kept locally, hence improving its accuracy. I hope to have more to say on this in Memphis. --bill From guyd@uunet.pipex.com Wed Mar 19 00:22:18 1997 From: guyd@uunet.pipex.com (Guy Davies) Date: Wed, 19 Mar 1997 00:22:18 +0000 (GMT) Subject: 6bone Routing Registry In-Reply-To: <199703181958.OAA09634@ocarina.visc.vt.edu> Message-ID: On Tue, 18 Mar 1997, David Lee wrote: > Additionally, I'm expecting to get some native IPv6 routed subnets up for > testing and there appears to be no way to designate this in the current RIPE > registry format. First off, there is some question of whether or not to even > designate this. Assuming that we want to designate it, which I would think > that we would, then, I would think that the format needs to be the same as the > tunnel designation. Thus, I would proposed the following. > > native: [iif addr] [oif addr] [other site] [rp type] [status] {type} > > where: > > iif ipv4 - Address of the routed subnet for the router's input interface address > oif ipv4 - Address of the routed subnet for the outgoing interface > site - Outgoing interface site name > rp type - Routing protocol type. RIPng, static, etc. > status - One of the following: > oper/u "operational" status and link up > oper/d "operational" status (or was ;) and link down > expr/u "experimental" status and link up > expr/d "experimental" status and link down > type - Optional field of the format XY, where X is one of: > u - feed to a upstream site > d - feed to a downstream site (which may or may not be a leaf) > t - feed to a "lateral" transit site (e.g., other backbone) > l - feed to a downstream leaf site > > And Y is a number from 1 to 9, where 1 designates a primary > feed, 2 designates a secondary feed, and so forth. > > An example of a machine with two interfaces would be: > > native: 128.173.88.118 128.173.89.100 VT-EE-NETLAB RIPng expr/u l1 Hi David, Err, Looking at your proposal, I don't understand how this gives any information about a native IPv6 subnet. It seems to be more appropriate for a host/router rather than a subnet. This may be a useful attribute in it's own right but I'm not sure it does what you said you wanted. Surely, something along the following lines would prove more useful... native: [prefix] [rtr-id] [sn-name] [net-type] [rp-type] [status] {type} ...where... [prefix] is the routed IPv6 subnet (which may be covered in the global routing tables by a larger announcement) [rtr-id] is the id (ipv6|ipv4|hostname?) of the inbound i/f of the router via which this subnet can be reached. I think given that this is native IPv6, my choice would be the IPv6 address of the i/f. [sn-name] is the subnet name formed as described below by David [net-type] is the underlying network type (eth|ppp|tr|atm|....) [rp-type] is the routing protocol (ripng|idrpv6|static|....) [status] is the link status as described by David {type} is the link type as described by David. On multicast type media, this may need to be extensible to cover several 'peering' types (e.g. you may run IPv6 across an ethernet on which you have peerings to transit sites, leaf nodes, to upstream nodes and to downstream nodes - I'm thinking of something like a NAP here) This would give a better idea of the propagation of native IPv6 subnets and far more info about the subnet (possible number of connected hosts, use of particular network types, routing protocol used, etc) This, IMHO, maps more closely onto the tunnel attribute already defined in the ip6rr object and represents the subnet. > I was also thinking of including the routed subnet's IPv6 prefix but I think > that's unnecessary information. The going assumption is that the routed > subnet's prefix is some portion of the destination site's prefix. This is most likely true but (in the case of an organisation with multiple ASes) is not guaranteed. There is, as stated above, some useful info in the prefix. > I would > also advocate that internal sites/nodes be listing according to the format > > [registry entry]-[internal name] Definitely. This is a very good idea and kind of maps onto the concept of OSPFs areas around area0. > I would note that if we start to match the production IPv4 network, then > we'll have many of these native entries. When (and not if ;) we get to that > point, I would propose that we only list the border router(s) for the native > routed site. One of the justifications for having native routed nodes listed > now is for people to see how many of these we actually have. This gives us an > idea of penetration and can also be used on a marketing side. When we > have a significant amount of sites that are native routed, the technical > information need is reduced and we also have a much different and stronger > selling point on IPv6 rollout. > > The only thing that differs from standard practice is the feed type. > I believe that the feed type information will help people get a better > understanding of how a site is connected. > > I would, naturally, advocate that the tunnel registry information > (http://www-cnr.lbl.gov/6bone/6bone-register.html) be changed to > 1) reflect standard convention and 2) include the proposed feed type > information. Thus, the format should be: > > tunnel: [source addr] [dest iaddr] [site] [rp type] [status] {type} > > Regards, > DCL > > -- > David C. Lee, EE PhD student - http://www.visc.vt.edu/~dlee - dlee@vt.edu > PHONE: 1-540-231-8398 | FAX: 1-540-231-3362 | LOCATION: 475 Whittemore Hall > Virginia Tech Information Systems Center, Blacksburg, Virginia 24061-0111 > From RLFink@lbl.gov Wed Mar 19 00:36:10 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 18 Mar 1997 16:36:10 -0800 Subject: 6bone diagram change - version 57 Message-ID: Only minor changes (no new sites) to change incorrect CN to CA coutry codes for RISQ and ESYS. My apologies for moving Canada half way (or so) around the world! Bob From bound@zk3.dec.com Wed Mar 19 02:32:35 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Tue, 18 Mar 97 21:32:35 -0500 Subject: list of IPv6 applications? In-Reply-To: Your message of "Mon, 17 Mar 97 17:26:16 PST." <199703180126.RAA03762@dew> Message-ID: <9703190232.AA29549@wasted.zk3.dec.com> Jong, Also we are interested in any collaboration working with you and others around IPv6. What faculty department is this under? thanks /jim From jang@sps.nl Wed Mar 19 09:14:05 1997 From: jang@sps.nl (Gils van, Jan) Date: Wed, 19 Mar 1997 10:14:05 +0100 Subject: 6bone attachment point Message-ID: Hi Rob, After talking to NL.net they told me that 6Bone tunnels are not yet supported by there network. On this moment they are experimenting with tunneling and encapsulation. Talk to them for more information. When you want to make a tunnel, contact Martin D. Peck (mdp@tbit.dk) With regards Jan H. van Gils ___________________________________________________________________ Jan H. van Gils | Software Productivity Solutions jang@sps.nl | P.O. box 92 2810 AB Reeuwijk +31 (0)182-396866 | Fokkerstraat 16 2811 ER Reeuwijk ------------------------------------------------------------------- >---------- >From: Rob Goode[SMTP:goode@nc3a.nato.int] >Sent: Tuesday, March 18, 1997 3:22 PM >To: 6bone@isi.edu >Cc: ipv6@nc3a.nato.int >Subject: 6bone attachment point > >Dear Sirs, > >please could you tell me which would be the most >appropriate attachement point to the 6bone for us. >Our provider is NL-NET in the Netherlands (Holland). > >Yours sincerely, > >Rob Goode >Communications Techniques Branch >Communications Systems Division >NATO C3 Agency >PO Box 174 >2501 CD Den Haag >The Netherlands > >Email: goode@nc3a.nato.int Tel: +31 70-314-2442 Fax: +31 70-314-2176 > From RLFink@lbl.gov Wed Mar 19 16:09:20 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 19 Mar 1997 08:09:20 -0800 Subject: new 6bone diagram - version 58 Message-ID: new 6bone diagram: add UNI-KOELN/DE to JOIN/DE Bob From fang@snad.ncsl.nist.gov Wed Mar 19 16:56:50 1997 From: fang@snad.ncsl.nist.gov (Hsin Fang) Date: Wed, 19 Mar 1997 11:56:50 -0500 (EST) Subject: list of IPv6 applications? Message-ID: <199703191656.LAA05783@emu.ncsl.nist.gov> Hi Bob: From the quick analysis of the various implementations used in our testbed, Status: RO we have come up the following list (it may not be the most updated version but is up to the current version which we are running): INRIA : (source code available) OS: NetBSD/FreeBSD Platform : SUN workstation. Major Functions Icmpv6 IPv6 address manual/auto configuration IPv6 security implementation DES, MD5 and SHA (need special permission to get the code) IPv6 support for FDDI IPv6 support for MULTICAST IPv6 path MTU discovery IPv6 address mapping IPv6 dynamic/static routing IPv6/V4 tunneling point-to-point SIT interfaces with multicast (for RIPv6) ndp6 IPv6 libpcap IPv6 key management RIPv6 Apps: IPv6 ttcp IPv6 multicast neighbor discovery utilities route support for IPv6 IPv6 ifconfig IPv6 autoconfig IPv6 netstat IPv6 sendmail IPv6 Telenet/telnetd inetd support for IPv6 IPv6 tcpdump IPv6 ping/traceroute IPv6 rlogin IPv6 finger/fingerd IPv6 arp IPv6 http server/client IPv6 ftp/ftpd IPv6 tftp/tftpd IPv6 gated IPv6 nslookup NRL : (source code available) OS: BSDi Platform : PC 486+ Major Functions: IPv6 security implementations Key management API basic IPv6 functions Apps: IPv6 ttcp IPv6 multicast neighbor discovery utilities route support for IPv6 IPv6 ifconfig IPv6 netstat IPv6 Telenet/telnetd inetd support for IPv6 IPv6 tcpdump IPv6 ping/traceroute IPv6 rlogin IPv6 finger/fingerd IPv6 ftp/ftpd IPv6 tftp/tftpd SUN : (binary code only) OS: Solaris Platform : SUN workstation. Major Functions: IPv6 unicast and multicast IPv6 packet forwarding IPv6 path MTU discovery ICMP6 error processing and generation IPv6 Address resolution Router discovery IPv6 Neighbor Unreachability Detection Prefix discovery with invalid lifetimes IPv6 Stateless address autoconf Duplicate address detection RIPng in in.routed6 Apps: (for IPv6) finger and in.fingerd getent inetd support for IPv6 telnet server and client ftp/ftpd tftp/tftpd sendmail NCSA httpd server NCSA Mosaic browser rlogin rsh netstat support for IPv6 snoop ping IPv6 ifconfig nslookup NDS support for AAAA record LINUX : (source code available) OS: LINUX Platform : PC 486+ Functions: (for IPv6) forwarding address manual/auto configuration neighbor discovery static routing RIPng - MERIT Router Advertisement multicast Icmpv6 IPv6/V4 tunneling Apps: (for IPv6) arp ifconfig netstat route rarp finger+fingerd ftp+ftpd inetd tcpdump tftp+tftpd traceroute sendmail qpopper ping FTP : (binary code only) OS: Window95 Platform : PC 486+ Major Functions: Support IPv6 client functions DEC : (binary code only) Platform : DEC hub ONE router Major Functions: ICMPV6 Neighbor Discovery IPv6 packets forwarding IPv6/v4 static and automatic tunnels IPv6 router advertisement RIPv6 PPP for IPv6 Support IPv4 tunnel discovery between RIPv6 IPv6 address manual/auto configuration IPv6 ping traceroute IPv6 Dump routes BAYNetworks : (binary code only) Platform : BayNetworks ASN router Major Functions: IPv6 forwarding including forwarding of source routed packets IPv6 Neighbor Discovery IPv6 ICMP IPv6 Stateless Autoconfiguration Full Support of IPv4-to-IPv6 transition Mechanisms Configured Static IPv6-in-IPv4 Tunnels Automatic IPv6-in-IPv4 Tunnels IPv6-in-IPv6 Tunnels Path MTU Discovery RIPng: Dynamic IPv6 routing using RIP IPv6 Static Routes IPv6 over PPP IPv6 traffic filtering IPv6 MIB IPv6 Address manual/auto configuration IPv6 route RIP6 IPv6 ping IPv6 router advertisement Status: Telebit : (binary code only) Platform : Telebit router Major Functions: IPv6 ICMP IPv6 Stateless address configuration IPv6/IPv4 packet filtering and accounting IPv6 ping IPv6 traceroute ND IDRPv6 IPv6/V4 static tunneling SNMP support for IPv6 Regards, Hsin From RLFink@lbl.gov Wed Mar 19 17:05:28 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 19 Mar 1997 09:05:28 -0800 Subject: list of IPv6 applications? In-Reply-To: <199703191656.LAA05783@emu.ncsl.nist.gov> Message-ID: Hsin, Thanks for the list. Robbie Honerkamp is putting together a first draft web page to handle this info and it will be great to have a start with some real data. We will post it to the mailer as soon as we are ready, then everyone can comment and add to it. Thanks, Bob ========================================== At 8:56 AM -0800 3/19/97, Hsin Fang wrote: >Hi Bob: > >From the quick analysis of the various implementations used in our testbed, >we have come up the following list (it may not be the most updated version >but is up to the current version which we are running): > > > INRIA : (source code available) > OS: NetBSD/FreeBSD > Platform : SUN workstation. > Major Functions > Icmpv6 > IPv6 address manual/auto configuration > IPv6 security implementation DES, MD5 and SHA > (need special permission to get the code) > IPv6 support for FDDI > IPv6 support for MULTICAST > IPv6 path MTU discovery > IPv6 address mapping > IPv6 dynamic/static routing > IPv6/V4 tunneling > point-to-point SIT interfaces with multicast (for RIPv6) > ndp6 > IPv6 libpcap > IPv6 key management > RIPv6 > Apps: > IPv6 ttcp > IPv6 multicast > neighbor discovery utilities > route support for IPv6 > IPv6 ifconfig > IPv6 autoconfig > IPv6 netstat > IPv6 sendmail > IPv6 Telenet/telnetd > inetd support for IPv6 > IPv6 tcpdump > IPv6 ping/traceroute > IPv6 rlogin > IPv6 finger/fingerd > IPv6 arp > IPv6 http server/client > IPv6 ftp/ftpd > IPv6 tftp/tftpd > IPv6 gated > IPv6 nslookup > > NRL : (source code available) > OS: BSDi > Platform : PC 486+ > Major Functions: > IPv6 security implementations > Key management API > basic IPv6 functions > Apps: > IPv6 ttcp > IPv6 multicast > neighbor discovery utilities > route support for IPv6 > IPv6 ifconfig > IPv6 netstat > IPv6 Telenet/telnetd > inetd support for IPv6 > IPv6 tcpdump > IPv6 ping/traceroute > IPv6 rlogin > IPv6 finger/fingerd > IPv6 ftp/ftpd > IPv6 tftp/tftpd > > SUN : (binary code only) > OS: Solaris > Platform : SUN workstation. > Major Functions: > IPv6 unicast and multicast > IPv6 packet forwarding > IPv6 path MTU discovery > ICMP6 error processing and generation > IPv6 Address resolution > Router discovery > IPv6 Neighbor Unreachability Detection > Prefix discovery with invalid lifetimes > IPv6 Stateless address autoconf > Duplicate address detection > RIPng in in.routed6 > Apps: (for IPv6) > finger and in.fingerd > getent > inetd support for IPv6 > telnet server and client > ftp/ftpd > tftp/tftpd > sendmail > NCSA httpd server > NCSA Mosaic browser > rlogin > rsh > netstat support for IPv6 > snoop > ping > IPv6 ifconfig > nslookup > NDS support for AAAA record > > LINUX : (source code available) > OS: LINUX > Platform : PC 486+ > Functions: (for IPv6) > forwarding > address manual/auto configuration > neighbor discovery > static routing > RIPng - MERIT > Router Advertisement > multicast > Icmpv6 > IPv6/V4 tunneling > Apps: (for IPv6) > arp > ifconfig > netstat > route > rarp > finger+fingerd > ftp+ftpd > inetd > tcpdump > tftp+tftpd > traceroute > sendmail > qpopper > ping > > > FTP : (binary code only) > OS: Window95 > Platform : PC 486+ > Major Functions: > Support IPv6 client functions > > > DEC : (binary code only) > Platform : DEC hub ONE router > Major Functions: > ICMPV6 > Neighbor Discovery > IPv6 packets forwarding > IPv6/v4 static and automatic tunnels > IPv6 router advertisement > RIPv6 > PPP for IPv6 > Support IPv4 tunnel discovery between RIPv6 > IPv6 address manual/auto configuration > IPv6 ping > traceroute > IPv6 Dump routes > > BAYNetworks : (binary code only) > Platform : BayNetworks ASN router > Major Functions: > IPv6 forwarding including forwarding of source routed packets > IPv6 Neighbor Discovery > IPv6 ICMP > IPv6 Stateless Autoconfiguration > Full Support of IPv4-to-IPv6 transition Mechanisms > Configured Static IPv6-in-IPv4 Tunnels > Automatic IPv6-in-IPv4 Tunnels > IPv6-in-IPv6 Tunnels > Path MTU Discovery > RIPng: Dynamic IPv6 routing using RIP > IPv6 Static Routes > IPv6 over PPP > IPv6 traffic filtering > IPv6 MIB > IPv6 Address manual/auto configuration > IPv6 route > RIP6 > IPv6 ping > IPv6 router advertisement > Status: > > Telebit : (binary code only) > Platform : Telebit router > Major Functions: > IPv6 ICMP > IPv6 Stateless address configuration > IPv6/IPv4 packet filtering and accounting > IPv6 ping > IPv6 traceroute > ND > IDRPv6 > IPv6/V4 static tunneling > SNMP support for IPv6 > > >Regards, >Hsin From RLFink@lbl.gov Wed Mar 19 17:56:30 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 19 Mar 1997 09:56:30 -0800 Subject: list of IPv6 applications? In-Reply-To: <199703191748.AA11574@zed.isi.edu> References: from "Bob Fink LBNL" at Mar 19, 97 09:05:28 am Message-ID: At 9:48 AM -0800 3/19/97, bmanning@ISI.EDU wrote: >I think that there is a notable exception to this list.. I understand that >cisco has working binary code for their routing platforms. You sure are right...many of us run it! Thanks, Bob From bmanning@ISI.EDU Wed Mar 19 17:48:26 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Wed, 19 Mar 1997 09:48:26 -0800 (PST) Subject: list of IPv6 applications? In-Reply-To: from "Bob Fink LBNL" at Mar 19, 97 09:05:28 am Message-ID: <199703191748.AA11574@zed.isi.edu> I think that there is a notable exception to this list.. I understand that cisco has working binary code for their routing platforms. -- --bill From lpz@nautique.epm.ornl.gov Wed Mar 19 18:37:50 1997 From: lpz@nautique.epm.ornl.gov (Lawrence MacIntyre) Date: Wed, 19 Mar 1997 13:37:50 -0500 Subject: list of IPv6 applications? References: Message-ID: <3330327E.15FB@nautique.epm.ornl.gov> Bob Fink LBNL wrote: > > Hsin, > > Thanks for the list. Robbie Honerkamp is putting together a first draft > web page to handle this info and it will be great to have a start with some > real data. > > We will post it to the mailer as soon as we are ready, then everyone can > comment and add to it. > > Thanks, > > > > > DEC : (binary code only) > > Platform : DEC hub ONE router > > Major Functions: > > ICMPV6 > > Neighbor Discovery > > IPv6 packets forwarding > > IPv6/v4 static and automatic tunnels > > IPv6 router advertisement > > RIPv6 > > PPP for IPv6 > > Support IPv4 tunnel discovery between RIPv6 > > IPv6 address manual/auto configuration > > IPv6 ping > > traceroute > > IPv6 Dump routes > > DEC also has code for the Alpha running Digital Unix. The list of features is on the web page: http://www.digital.com/info/ipv6/host-implementation-18FEB97.html -- Lawrence ~ ------------------------------------------------------------------------ Lawrence MacIntyre Oak Ridge National Laboratory 423.574.8696 lpz@ornl.gov http://www.epm.ornl.gov/~lpz lpz@nautique.epm.ornl.gov From robbie@mindspring.com Wed Mar 19 18:44:37 1997 From: robbie@mindspring.com (robbie@mindspring.com) Date: Wed, 19 Mar 1997 13:44:37 -0500 (EST) Subject: Rough draft: IPv6 applications list Message-ID: <19970319184437.5276.qmail@tomservo.mindspring.com> I've started outlining a site that would contain a list of IPv6 applications. I'm looking for suggestions and comments for how the site might be laid out. I've got an outline at: http://web.shorty.com/ipv6/apps/ Please give it a look, and let me know (robbie@mindspring.com) if you have any comments. Thanks! Robbie -- Robbie Honerkamp robbie@mindspring.com From stuart@pa.dec.com Wed Mar 19 18:52:34 1997 From: stuart@pa.dec.com (Stephen Stuart) Date: Wed, 19 Mar 97 10:52:34 -0800 Subject: list of IPv6 applications? In-Reply-To: Your message of Wed, 19 Mar 97 09:56:30 -0800. Message-ID: <9703191852.AA25095@nsl-too.pa.dec.com> > At 9:48 AM -0800 3/19/97, bmanning@ISI.EDU wrote: > >I think that there is a notable exception to this list.. I understand that > >cisco has working binary code for their routing platforms. > > You sure are right...many of us run it! Digital has host software, as well. Hsin Fang did qualify his remark by saying that he was listing, "various implementations used in [their] testbed." Stephen From dlee@visc.vt.edu Wed Mar 19 19:30:06 1997 From: dlee@visc.vt.edu (David Lee) Date: Wed, 19 Mar 1997 14:30:06 -0500 (EST) Subject: 6bone Routing Registry In-Reply-To: from "Guy Davies" at Mar 19, 97 00:22:18 am Message-ID: <199703191930.OAA10898@ocarina.visc.vt.edu> > Err, Looking at your proposal, I don't understand how this gives any > information about a native IPv6 subnet. It seems to be more appropriate > for a host/router rather than a subnet. This may be a useful attribute in > it's own right but I'm not sure it does what you said you wanted. Surely, > something along the following lines would prove more useful... Right now I almost pretty much don't care as long as there's something workable. I got this damned qualifing exam looming overhead... :) > native: [prefix] [rtr-id] [sn-name] [net-type] [rp-type] [status] {type} > > ...where... > > [prefix] is the routed IPv6 subnet (which may be covered in the > global routing tables by a larger announcement) > [rtr-id] is the id (ipv6|ipv4|hostname?) of the inbound i/f of > the router via which this subnet can be reached. I think > given that this is native IPv6, my choice would be the > IPv6 address of the i/f. The question is that in order to diagnose problems, is the IPv6 address sufficient (at this stage in the game)? On another note, I would guess that most routed subnets would also have also have a tunnel connection. Mapping the native object to the tunnel object/end-point would be easier if we used the IPv4 address. My line of thought was to map the IPv6 network ontop of the IPv4 network. Thus, the IPv4 source/destination network ID's (I was originally trying to figure out how to specify the subnet without supplying a subnet mask... perhaps something like 128.173.88.118/58 would be better). True, an IPv6 routed subnet doesn't (shouldn't? :) imply a one-to-one mapping to an IPv4 network, but 1) I find that easier to keep track of if we look at things in terms of the IPv4 network and 2) I would also expect that all networks (for the forseeable future) would be dual IPv4/IPv6 networks. One could modify the ping line to provide a mapping between IPv4 and IPv6 addresses -- ping: 128.173.88.118 5f05:2000:80ad:5800::1 If the machine only has a IPv6 address, then that's the only thing that shows up. And add the requirement that all router nodes on the record must have a ping entry (of the above format), that would solve both problems. Given that, it would seem that we have a workable solution. > [sn-name] is the subnet name formed as described below by David > [net-type] is the underlying network type (eth|ppp|tr|atm|....) Good idea -- this would be useful to know. > [rp-type] is the routing protocol (ripng|idrpv6|static|....) > [status] is the link status as described by David > {type} is the link type as described by David. On multicast > type media, this may need to be extensible to cover > several 'peering' types (e.g. you may run IPv6 across > an ethernet on which you have peerings to transit > sites, leaf nodes, to upstream nodes and to downstream > nodes - I'm thinking of something like a NAP here) > > > I was also thinking of including the routed subnet's IPv6 prefix but I think > > that's unnecessary information. The going assumption is that the routed > > subnet's prefix is some portion of the destination site's prefix. > > This is most likely true but (in the case of an organisation with multiple > ASes) is not guaranteed. There is, as stated above, some useful info in > the prefix. One could envision that multiple ASes mean that they would have multiple ip6rr entries. In which the site name rule still would work. On another thought, I would assume that each on-link prefix then receives its own entry. DCL -- David C. Lee, EE PhD student - http://www.visc.vt.edu/~dlee - dlee@vt.edu PHONE: 1-540-231-8398 | FAX: 1-540-231-3362 | LOCATION: 475 Whittemore Hall Virginia Tech Information Systems Center, Blacksburg, Virginia 24061-0111 From jimmy.kyriannis@nyu.edu Wed Mar 19 23:13:50 1997 From: jimmy.kyriannis@nyu.edu (Jimmy Kyriannis) Date: Wed, 19 Mar 1997 18:13:50 -0500 Subject: list of IPv6 applications? In-Reply-To: <199703191748.AA11574@zed.isi.edu> References: from "Bob Fink LBNL" at Mar 19, 97 09:05:28 am Message-ID: At 12:48 PM -0500 3/19/97, bmanning@ISI.EDU wrote: >I think that there is a notable exception to this list.. I understand that >cisco has working binary code for their routing platforms. > > >-- >--bill I've been in touch with the Cisco contact for IPv6 IOS. It's currently only available on a highly limited basis - I was asked to wait until formal betas were released. :( Jimmy --------------- Jimmy Kyriannis Assistant Network Manager, New York University Academic Computing Facility Phone: 212-998-3431 FAX: 212-995-4120 Internet Mail: jimmy.kyriannis@nyu.edu From solensky@ftp.com Wed Mar 19 23:46:23 1997 From: solensky@ftp.com (Frank T Solensky) Date: Wed, 19 Mar 1997 18:46:23 -0500 Subject: list of IPv6 applications? Message-ID: <199703192343.SAA02994@MAILSERV-2HIGH.FTP.COM> >>Reply to your message of 3/18/97 9:21 AM >Any idea if FTP's software supports IPv6 in anything except the stack? >All the bundled applications (browser, e-mail, etc) do not support IPv6 >as far as I know. Is this true? TNVTPlus (telnet), FTP client and server, and ping currently work over IPv6; IPtrace parses some but not all IPv6 headers and a statistics program displays the IPv6 addresses assigned to an interface. We should have most of our other apps IPv6-capable very soon. -- Frank From guyd@uunet.pipex.com Thu Mar 20 13:24:36 1997 From: guyd@uunet.pipex.com (Guy Davies) Date: Thu, 20 Mar 1997 13:24:36 +0000 (GMT) Subject: 6bone Routing Registry In-Reply-To: <199703191930.OAA10898@ocarina.visc.vt.edu> Message-ID: On Wed, 19 Mar 1997, David Lee wrote: [snip] > The question is that in order to diagnose problems, is the IPv6 address > sufficient (at this stage in the game)? On another note, I would guess > that most routed subnets would also have also have a tunnel connection. > Mapping the native object to the tunnel object/end-point would be easier if > we used the IPv4 address. Hmm, we're starting to get to the point where it's not more attributes we need but more objects. I can see a good justification for an inetnum6 object (which would probably be almost directly copied from the inetnum object), an ipv6-site object (which is basically the current site object in ip6rr), an ipv6-host or ipv6-rtr object which can give details of mappings between ipv6 and ipv4 on a single interface _and_ and ipv6-subnet (equivalent to my native proposal). There's far too much useful info to realistically fit onto a single attribute line. Somebody tell me if you all think I'm running ahead of myself! > My line of thought was to map the IPv6 network ontop of the IPv4 network. > Thus, the IPv4 source/destination network ID's (I was originally trying > to figure out how to specify the subnet without supplying a subnet mask... > perhaps something like 128.173.88.118/58 would be better). True, an IPv6 > routed subnet doesn't (shouldn't? :) imply a one-to-one mapping to an > IPv4 network, but 1) I find that easier to keep track of if we look at > things in terms of the IPv4 network and 2) I would also expect that all > networks (for the forseeable future) would be dual IPv4/IPv6 networks. Sure, it's likely that most will be ipv4/ipv6 capable, but we need to take into account the possibility of single protocol networks reachable only via tunnels. I'd far rather think about the most flexible way to record these details now than in a years time when people are used to the other system. > One could modify the ping line to provide a mapping between IPv4 and IPv6 > addresses -- > > ping: 128.173.88.118 5f05:2000:80ad:5800::1 This could form part of an ipv6-host object. Obviously, these are host/interface addresses which have no direct association with a particular net. > If the machine only has a IPv6 address, then that's the only thing that > shows up. And add the requirement that all router nodes on the record must > have a ping entry (of the above format), that would solve both problems. Given > that, it would seem that we have a workable solution. > > > [sn-name] is the subnet name formed as described below by David > > [net-type] is the underlying network type (eth|ppp|tr|atm|....) > > Good idea -- this would be useful to know. Heh! We agree on something ;-) [snip] > > > I was also thinking of including the routed subnet's IPv6 prefix but I think > > > that's unnecessary information. The going assumption is that the routed > > > subnet's prefix is some portion of the destination site's prefix. > > > > This is most likely true but (in the case of an organisation with multiple > > ASes) is not guaranteed. There is, as stated above, some useful info in > > the prefix. > > One could envision that multiple ASes mean that they would have multiple > ip6rr entries. In which the site name rule still would work. Hmm, possibly but I know that several ISPs (particularly in the US) have _lots_ of ASes. Would they want to represent themselves as a single entity or lots of different ones? > On another > thought, I would assume that each on-link prefix then receives its > own entry. Well, either that or prefix becomes mandatory/multiple. > > DCL > > -- > David C. Lee, EE PhD student - http://www.visc.vt.edu/~dlee - dlee@vt.edu > PHONE: 1-540-231-8398 | FAX: 1-540-231-3362 | LOCATION: 475 Whittemore Hall > Virginia Tech Information Systems Center, Blacksburg, Virginia 24061-0111 > From chong@mail52.mitretek.org Fri Mar 21 18:37:10 1997 From: chong@mail52.mitretek.org (Chongeun Lee) Date: Fri, 21 Mar 97 13:37:10 -0500 Subject: RIPE-NCC registration Message-ID: <970321133710.28651@mail52.mitretek.org.0> Hi, I would like to register to RIPE for my company and need group id and password. Can anyone tell me what they are? Thanks, Chongeun From RLFink@lbl.gov Fri Mar 21 21:39:34 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 21 Mar 1997 13:39:34 -0800 Subject: RIPE-NCC registration In-Reply-To: <970321133710.28651@mail52.mitretek.org.0> Message-ID: At 10:37 AM -0800 3/21/97, Chongeun Lee wrote: >Hi, > >I would like to register to RIPE for my company and need group id and >password. >Can anyone tell me what they are? quote site group ip6rr quote site gpass 6bone From ipv6@dcn.soongsil.ac.kr Sat Mar 22 01:27:00 1997 From: ipv6@dcn.soongsil.ac.kr (IPv6 Project DCN) Date: Sat, 22 Mar 1997 10:27:00 +0900 Subject: New IPv6 site : SSU from Soongsil Univ., Korea Message-ID: <3.0.1.32.19970322102700.00695210@dcn.soongsil.ac.kr> Hello. This is Data Communication & Network(DCN) Lab., Soongsil Univ., Seoul, the Republic of Korea. We have developed the IPv6 system on the FreeBSD 2.1 OS and our developed IPv6 system is operational. And we brought up the tunnel to Cisco/US, then registered with RIPE-NCC. Here is the RIPE-NCC data: site: SSU(DCN, SoongSil University, Seoul, Korea) location: Seoul, The Republic of Korea prefix: 5f0d:e700:cbfd:0300/64 ping: 5f0d:e700:cbfd:0300::20:afa5:d5bf tunnel: 203.253.3.204 192.31.7.41 CISCO/US contact: Younghan Kim status: operational changed: ipv6@dcn.soongsil.ac.kr 970201 source: RIPE Please let me know if you see any problems with the our site. Thanks to ISI, and Cisco for their help in getting things set up. - IPv6 Project in DCN From seidmann@dcs.elf.stuba.sk Mon Mar 24 10:20:18 1997 From: seidmann@dcs.elf.stuba.sk (Thomas Seidmann) Date: Mon, 24 Mar 1997 11:20:18 +0100 (MET) Subject: RIPng over tunnels? Message-ID: Hi, I apologize in advance if this question sounds silly: which of the current IPv6 protocol implementations include RIPng over tunnels? I mean in source code, of course. TIA. Thomas From RLFink@lbl.gov Mon Mar 24 16:23:07 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 24 Mar 1997 08:23:07 -0800 Subject: new 6bone diagram, version 59 Message-ID: new 6bone diagram, version 59 moved NETGOD/US to WWU/US for transit add IXA/US and SSU/KR to CISCO/US as leaves Thanks, Bob From dlee@visc.vt.edu Tue Mar 25 05:18:27 1997 From: dlee@visc.vt.edu (David Lee) Date: Tue, 25 Mar 1997 00:18:27 -0500 (EST) Subject: 6bone Routing Registry In-Reply-To: from "Guy Davies" at Mar 20, 97 01:24:36 pm Message-ID: <199703250518.AAA01489@ocarina.visc.vt.edu> > Hmm, we're starting to get to the point where it's not more attributes we > need but more objects. I can see a good justification for an inetnum6 > object (which would probably be almost directly copied from the inetnum > object), an ipv6-site object (which is basically the current site object > in ip6rr), an ipv6-host or ipv6-rtr object which can give details of > mappings between ipv6 and ipv4 on a single interface _and_ and ipv6-subnet > (equivalent to my native proposal). There's far too much useful info to > realistically fit onto a single attribute line. > > Somebody tell me if you all think I'm running ahead of myself! To some extent, these items could be and/or are handled by DNS... no need to build a new system. The question, IMHO, is what useful information should be contained in the ip6rr for initial testing, deployment, and marketing phase (e.g., now). For the future, Bill (Manning's) comment on rolling this into DNS makes sense... > Sure, it's likely that most will be ipv4/ipv6 capable, but we need to take > into account the possibility of single protocol networks reachable only > via tunnels. I'd far rather think about the most flexible way to record > these details now than in a years time when people are used to the other > system. Again, I guess we're differing on how long we expect this to be used. To some extend, the long-range approach may be better (since there are people in this world who still use DOS V1.0 ... :) However, when we go to real IPv6 addresses, I would suspect that the routing databases will be redone with what we know to be true at that point. Or, if it doesn't work, we'll change it in the future ;) -- David C. Lee, EE PhD student - http://www.visc.vt.edu/~dlee - dlee@vt.edu PHONE: 1-540-231-8398 | FAX: 1-540-231-3362 | LOCATION: 475 Whittemore Hall Virginia Tech Information Systems Center, Blacksburg, Virginia 24061-0111 From guyd@uunet.pipex.com Tue Mar 25 11:09:21 1997 From: guyd@uunet.pipex.com (Guy Davies) Date: Tue, 25 Mar 1997 11:09:21 +0000 (GMT) Subject: 6bone Routing Registry In-Reply-To: <199703250518.AAA01489@ocarina.visc.vt.edu> Message-ID: On Tue, 25 Mar 1997, David Lee wrote: > > Hmm, we're starting to get to the point where it's not more attributes we > > need but more objects. I can see a good justification for an inetnum6 > > object (which would probably be almost directly copied from the inetnum > > object), an ipv6-site object (which is basically the current site object > > in ip6rr), an ipv6-host or ipv6-rtr object which can give details of > > mappings between ipv6 and ipv4 on a single interface _and_ and ipv6-subnet > > (equivalent to my native proposal). There's far too much useful info to > > realistically fit onto a single attribute line. > > > > Somebody tell me if you all think I'm running ahead of myself! > > To some extent, these items could be and/or are handled by DNS... no > need to build a new system. The question, IMHO, is what useful information > should be contained in the ip6rr for initial testing, deployment, and > marketing phase (e.g., now). For the future, Bill (Manning's) comment > on rolling this into DNS makes sense... Hi David, OK, to simplify all my ideas, the information I'd like to see (whatever the source) is... IPv6 Site (we know the details available here) IPv6 native net - IPv6 prefix in use on this net - IPv6 router via which the net can be reached - Codified subnet name - Network type (eth|atm|tr|fr|ppp|....) - Routing Protocols running on this subnet (ripng|static|idrpv6|....) - Operational Status (operational|experimental) - Peer relationships on this net (see David's previous emails) IPv6 router - Router name - Each IPv6 interface (shows which nets are connected by this rtr) - Each IPv4 interface (shows how IPv6 overlays IPv4) This kind of detail would allow me to decide which route I would expect to take and which routers I would expect to traverse in order to reach another site. If my traceroute failed, I would be able to see where either unexpected routing was happening or the packets stopped. That's what I need to know when doing problem solving on a network at the level we'll be able to do ourselves before contacting the site in question for assistance. I don't intend that this information should be used as a means by which to apportion blame when things break, more that it would allow me to more accurately direct my requests for help when I need it rather than using the current scattergun approach ;-) Clearly, the provision of this info, like the involvement in 6bone itself, is optional. Some of the details can be discovered from the dns and the current ip6rr but there are certainly details which cannot easily be obtained from either. > > Sure, it's likely that most will be ipv4/ipv6 capable, but we need to take > > into account the possibility of single protocol networks reachable only > > via tunnels. I'd far rather think about the most flexible way to record > > these details now than in a years time when people are used to the other > > system. > > Again, I guess we're differing on how long we expect this to be used. To > some extend, the long-range approach may be better (since there are people > in this world who still use DOS V1.0 ... :) However, when we go to real > IPv6 addresses, I would suspect that the routing databases will be redone > with what we know to be true at that point. Or, if it doesn't work, we'll > change it in the future ;) Agreed, and this would be the realm of the various working groups at RIPE and the other Regional IP Registries to decide. Regards, Guy > > -- > David C. Lee, EE PhD student - http://www.visc.vt.edu/~dlee - dlee@vt.edu > PHONE: 1-540-231-8398 | FAX: 1-540-231-3362 | LOCATION: 475 Whittemore Hall > Virginia Tech Information Systems Center, Blacksburg, Virginia 24061-0111 > From yoda@heidelbg.ibm.com Tue Mar 25 14:10:58 1997 From: yoda@heidelbg.ibm.com (Helmut Cossmann) Date: Tue, 25 Mar 1997 15:10:58 +0100 (MEZ) Subject: new site Message-ID: <9703251410.AA22219@kiwi.heidelbg.ibm.com> site: IBM ENC location: Heidelberg, Germany loc-string: 49 24n 8 24e 120m prefix: 5f04:fb00:e065:c500::/80 ping: 5f04:fb00:e065:c500:0:800:5a8 tunnel: 192.101.197.242 129.13.169.3 DIGITAL-EARC contact: status: operational remark: since March 21, 1997 remark: AIX 4.2 IPv6 remark: please report any problems to contact above. changed: Helmut Cossmann source: RIPE From davidk@isi.edu Tue Mar 25 18:50:02 1997 From: davidk@isi.edu (davidk@isi.edu) Date: Tue, 25 Mar 1997 10:50:02 -0800 (PST) Subject: 6bone Routing Registry In-Reply-To: <199703250518.AAA01489@ocarina.visc.vt.edu> from "David Lee" at Mar 25, 97 00:18:27 am Message-ID: <9703251850.AA19904@brind.isi.edu> David, David Lee writes: > > To some extent, these items could be and/or are handled by DNS... no > need to build a new system. The question, IMHO, is what useful information > should be contained in the ip6rr for initial testing, deployment, and > marketing phase (e.g., now). For the future, Bill (Manning's) comment > on rolling this into DNS makes sense... We don't really need to build a new system in any case. We could use DNS or we could use an existing registry database for this. Obviously, the ftp solution is not entirely satisfactory. However, it was only intended as a temporary solution to let the formats iron out in a natural way. I kept quiet recently during this discussion since I found that it was time to actually do something instead of discussing. Therefore, I have been busy to implement my 6bone site object proposal into the RIPE database instead of participating in this discussion. Stay tuned to this list for an announcement when it's ready. At the same time I have adapted my draft (included below) for Bill Mannings ideas on DNS so that the data stored in both solutions is at least stored in a compatible way. I personnally feel that the RIPE database model has some advantages over DNS. A RIPE database based database will force more consistency in the data and the search capabilities are more flexible. On the other hand, the DNS implementation is perhaps a bit easier to implement, allows for more rapid adaptation of new ideas and has better scalebility properties (not that this is a problem now...). Just wait a bit and we can try both systems. > > Sure, it's likely that most will be ipv4/ipv6 capable, but we need to take > > into account the possibility of single protocol networks reachable only > > via tunnels. I'd far rather think about the most flexible way to record > > these details now than in a years time when people are used to the other > > system. > > Again, I guess we're differing on how long we expect this to be used. To > some extend, the long-range approach may be better (since there are people > in this world who still use DOS V1.0 ... :) However, when we go to real > IPv6 addresses, I would suspect that the routing databases will be redone > with what we know to be true at that point. Or, if it doesn't work, we'll > change it in the future ;) I would certainly prefer an approach that looks a bit farther in the future since we all know that 'temporary' systems tend to stay a lot longer then expected. That was one the reasons my draft was very carefull about version numbers and extensibility. My priorities are now in the following order: - I will get the implementation as specified in the current draft working - I am listening carefully for any new proposals for extensions such as discussed recently and will look for ways to accomodate them. However, I also feel that we shouldn't go to far with adding bells & whistles. I don't think it is a good idea to store all details of your *internal* network in a global database. Furthermore, it doesn't make sense to design a new 'routing policy' language. That is already being done in the 'rps' IETF working group and I don't see any reason why that language could not support IPv6 in the future since it is very extensible, knows about tunnels and doesn't make any assumptions about IP versions and routing protocols used. However, this language is not entirely specified yet and so is (my) implementation of RPSL. David K. PS Does anybody want me to publish this draft as an Internet draft? --- Title: A proposal for an IPv6 site database object Date: 970325 Authors: Geert Jan de Groot David Kessens Introduction This proposal describes the proposed syntax of a new RIPE database object that describes the several IPv6 sites in the world. The proposal has been extended for experimental use inside DNS. The object will be used to facilitate the introduction of IPv6 in the Internet. It is expected that the object will be superceded later (when the IPv6 routing protocols and the like are better standarized) by a new structure that is more genericly designed and less IPv6 dependant (see RPS working group, the RPSL language draft, RPS tunnel attribute extensions for the 'inet-rtr' object draft by Dave Meyer if you are interested in the topic). The RIPE database can get experimental support for this pretty quick after the RIPE database working group gives approval for such an experimental object. Syntax checking will initially be a bit sloppy to allow for easy changes to the format in our rapidly changing environment and to cut implementation time ;-). The syntax is based on the experience with the 'ftp' object depository at the RIPE NCC created by Geert Jan de Groot and discussions on the 6bone mailing list. Any comments for changes and/or better wording are welcome. Several attribute name changes are made to the existing 'ftp' object to faciliate a better integration (and reuse of already existing attributes) in the RIPE database scheme. The now existing nearly-real time mirroring mechanism of the data allows for a fast distribution mechanism to other (mirror) databases in a topologically closer position to the database users. It is therefore proposed that this object can only be updated at the RIPE NCC database depository (for now). This avoids conflicting data in different databases problems as we have now with the IPv4 route and AS number objects. The proposed RIDE working group is currently defining an exchange format for communication between different Internet registries. This will facilitate other types of databases such as DNS that could be used instead for storing this data. Formal RIPE database template: ipv6-site: [mandatory] [single] descr: [mandatory] [multiple] location: [optional] [multiple] country: [optional] [multiple] prefix: [mandatory] [multiple] application: [optional] [multiple] tunnel: [optional] [multiple] contact: [mandatory] [multiple] url: [optional] [multiple] remarks: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] The object could be stored in DNS TXT records using the following syntax: TXT "[optional white space]tag:[optional white space]" Description and purpose of the attributes: - ipv6-site: SiteTag is a short unique tag for the IPv6 site to be used for lookups and referrals of the object. Syntax: /^[A-Z][A-Z\-]*[A-Z]$/ Example: ipv6-site: ISI - descr: Multiple line attribute that describes the site. This attribute usually contains information about the location of the IPv6 site and a full name of the site. Syntax: /^.*$/ Example: descr: ISI/USC, descr: Los Angeles - location: LocationString contains the coordinates of the IPv6 sites location. Multiple location strings can be provided on different lines for sites that have multiple locations in the area. One can use a domainname instead of LocationString if an RFC1876 LOC record is present in DNS. Note that this attribute is unnecessary for DNS based databases since DNS already has support for special location (LOC) records (see RFC1876). Syntax: Full syntax is described in RFC1876. A summary follows below: 3. Master File Format The LOC record is expressed in a master file in the following format: LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]] {"E"|"W"} alt["m"] [siz["m"] [hp["m"] [vp["m"]]]] ) (The parentheses are used for multi-line data as specified in [RFC 1035] section 5.1.) where: d1: [0 .. 90] (degrees latitude) d2: [0 .. 180] (degrees longitude) m1, m2: [0 .. 59] (minutes latitude/longitude) s1, s2: [0 .. 59.999] (seconds latitude/longitude) alt: [-100000.00 .. 42849672.95] BY .01 (altitude in meters) siz, hp, vp: [0 .. 90000000.00] (size/precision in meters) If omitted, minutes and seconds default to zero, size defaults to 1m, horizontal precision defaults to 10000m, and vertical precision defaults to 10m. These defaults are chosen to represent typical ZIP/postal code area sizes, since it is often easy to find approximate geographical location by ZIP/postal code. 4. Example Data ;;; ;;; note that these data would not all appear in one zone file ;;; ;; network LOC RR derived from ZIP data. note use of precision defaults cambridge-net.kei.com. LOC 42 21 54 N 71 06 18 W -24m 30m ;; higher-precision host LOC RR. note use of vertical precision default loiosh.kei.com. LOC 42 21 43.952 N 71 5 6.344 W -24m 1m 200m pipex.net. LOC 52 14 05 N 00 08 50 E 10m curtin.edu.au. LOC 32 7 19 S 116 2 25 E 10m rwy04L.logan-airport.boston. LOC 42 21 28.764 N 71 00 51.617 W -44m 2000m - country: ... Specify here the country codes of the countries where your site is located. Example: country: US or country: DK SE - prefix: IPv6Prefix is a prefix that is used within the the IPv6 site. Syntax: Example: prefix: 5f0d:0500:c100::/64 - application: [port[/protocol]] This attribute describes the different services available on the site. The services are the same as described in the '/etc/services' plus 'ping' More services might be added later on. Hostname is the DNS hostname of the host that provides the service and a port number and protocol type may be specified for services that don't run on the standard port. Syntax: /^\S+\s+[a-zA-Z\-]+(\.[a-zA-Z\-])*\s+\d+(\/udp|\/tcp))?$/ Examples: application: ping pinghost.ISI.EDU application: ftp ftp.ISI.EDU - tunnel: in -> [FreeText] This attribute defines a tunnel of Protocol1 in Protocol2 from address src to address dst. You only need to define your side of the tunnel. The other end should be present in the object of the other party's site object. Note that tunnels should in general be configured symmetrically along both end-points and only be present in the object if they are actually configured and working at both ends. Currently (only) the following type of tunnels are accepted: tunnel: IPv6 in IPv4 -> [FreeText] It is expected that more possibilities will be added later. Currently defined protocols are: IDRPv6, BGP5, RIPv6, STATIC Syntax checking will not be done on this field to allow for newer and fast implementations of other protocols. Domainnames are used for greater flexibility. It makes it for example trivial to obtain the IPv6 or IPv4 address from DNS if needed. Example: tunnel: IPv6 in IPv4 tbc5000-18.tbit.dk -> unvea.denet.dk TELEBIT IDRPv6 - contact: This is the contact information of the site. Use a valid NIC handle that you received when creating an entry for your personal data in one of the registry databases (do 'whois -h whois.ripe.net HELP' for help on creating such an object). Example: contact: DK13-RIPE Note for DNS databases: References for DNS style databases can be defined as follows: - use a valid NIC-handle that points to an entry in a whois Internet registry database - use the following syntax: contact: YourName (DomainNameOfTextRecordWithYourContactObject) - the ipv6-site object has a personal data entry attached in DNS (separated by an empty record with a line number only) and the contact entry has the same value as the name of the person. person: [mandatory] [single] address: [mandatory] [multiple] phone: [mandatory] [multiple] fax-no: [optional] [multiple] e-mail: [optional] [multiple] remarks: [optional] [multiple] changed: [mandatory] [multiple] - url: Put here any useful URLs that are of interest for your site Example: url: - remarks: Put here any information that might be interesting for the other people at the 6bone to know about or use it for site specific information. Also 'not yet accepted new functionality' to the objects can be put here (temporarely). Many people use this to report about the status of their site; is it in implementation phase, is it up and running or are there still techincal problems. Syntax: /^.*$/ Example: remarks: operational since July 5, 1996 remarks: happy to add new tunnels upon request. remarks: 6bone-router.cisco.com carries all ipv6 routes. - changed: Use this attribute to show who was resposible for a change/addition of the object and the date on which it took effect. You may use more changed attribute to reflect the change history of the object. The date field has the following format: YYMMDD (in the RIPE database) Other databases that don't have a format defined yet are recommended to use an YYYYMMDD format. It is expected that the RIPE database will support this format in the future. Note that more changes attributes can be specified to show a history of changes. Example: changed: davidk@ISI.EDU 960923 - source: RIPE This field is always the same for now. It describes the place where the object can be updated and is stored. Example: source: RIPE Note that a 'source:' field is not relevant for non-RIPE databases. Whois query tools are recommended to use a 'source: DNS' to identify data that is extracted from DNS or another clear identifier for other databases. From RLFink@lbl.gov Wed Mar 26 00:35:22 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 25 Mar 1997 16:35:22 -0800 Subject: 6bone Routing Registry In-Reply-To: <9703251850.AA19904@brind.isi.edu> References: <199703250518.AAA01489@ocarina.visc.vt.edu> from "David Lee" at Mar 25, 97 00:18:27 am Message-ID: David, At 10:50 AM -0800 3/25/97, davidk@isi.edu wrote: ... >PS Does anybody want me to publish this draft as an Internet draft? I think it would be a good idea. If you do this, please submit it through me (and I will forward it on) as we are a new WG and I need to deal with making sure the ID editor gets the naming for it right from the start. And don't forget to look at the current ID guidelines: ftp://ftp.ietf.org/ietf/1id-guidelines.txt Thanks for the work! Bob >--- > >Title: A proposal for an IPv6 site database object > >Date: 970325 >Authors: Geert Jan de Groot > David Kessens > >Introduction > >This proposal describes the proposed syntax of a new RIPE database object >that describes the several IPv6 sites in the world. The proposal has been >extended for experimental use inside DNS. The object will be used to >facilitate the introduction of IPv6 in the Internet. It is expected that >the object will be superceded later (when the IPv6 routing protocols and >the like are better standarized) by a new structure that is more >genericly designed and less IPv6 dependant (see RPS working group, the >RPSL language draft, RPS tunnel attribute extensions for the 'inet-rtr' >object draft by Dave Meyer if you are interested in the topic). The RIPE >database can get experimental support for this pretty quick after the >RIPE database working group gives approval for such an experimental >object. Syntax checking will initially be a bit sloppy to allow for easy >changes to the format in our rapidly changing environment and to cut >implementation time ;-). > >The syntax is based on the experience with the 'ftp' object depository at >the RIPE NCC created by Geert Jan de Groot and discussions on the 6bone >mailing list. Any comments for changes and/or better wording are welcome. > >Several attribute name changes are made to the existing 'ftp' object to >faciliate a better integration (and reuse of already existing attributes) >in the RIPE database scheme. > >The now existing nearly-real time mirroring mechanism of the data allows >for a fast distribution mechanism to other (mirror) databases in a >topologically closer position to the database users. It is therefore >proposed that this object can only be updated at the RIPE NCC database >depository (for now). This avoids conflicting data in different databases >problems as we have now with the IPv4 route and AS number objects. > >The proposed RIDE working group is currently defining an exchange format >for communication between different Internet registries. This will >facilitate other types of databases such as DNS that could be used >instead for storing this data. > > >Formal RIPE database template: > >ipv6-site: [mandatory] [single] >descr: [mandatory] [multiple] >location: [optional] [multiple] >country: [optional] [multiple] >prefix: [mandatory] [multiple] >application: [optional] [multiple] >tunnel: [optional] [multiple] >contact: [mandatory] [multiple] >url: [optional] [multiple] >remarks: [optional] [multiple] >changed: [mandatory] [multiple] >source: [mandatory] [single] > > >The object could be stored in DNS TXT records using the following syntax: > >TXT "[optional white space]tag:[optional white > space]" > > >Description and purpose of the attributes: > > >- ipv6-site: > > SiteTag is a short unique tag for the IPv6 site to be used for lookups > and referrals of the object. > > Syntax: > > /^[A-Z][A-Z\-]*[A-Z]$/ > > Example: > > ipv6-site: ISI > > >- descr: > > Multiple line attribute that describes the site. This attribute usually > contains information about the location of the IPv6 site and a full > name of the site. > > Syntax: > > /^.*$/ > > Example: > > descr: ISI/USC, > descr: Los Angeles > > >- location: > > LocationString contains the coordinates of the IPv6 sites location. > Multiple location strings can be provided on different lines for sites > that have multiple locations in the area. One can use a domainname > instead of LocationString if an RFC1876 LOC record is present in DNS. > > Note that this attribute is unnecessary for DNS based databases since > DNS already has support for special location (LOC) records (see RFC1876). > > Syntax: > > Full syntax is described in RFC1876. A summary follows below: > > 3. Master File Format > > The LOC record is expressed in a master file in the following format: > > LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]] > {"E"|"W"} alt["m"] [siz["m"] [hp["m"] > [vp["m"]]]] ) > > (The parentheses are used for multi-line data as specified in [RFC > 1035] section 5.1.) > > where: > > d1: [0 .. 90] (degrees latitude) > d2: [0 .. 180] (degrees longitude) > m1, m2: [0 .. 59] (minutes latitude/longitude) > s1, s2: [0 .. 59.999] (seconds latitude/longitude) > alt: [-100000.00 .. 42849672.95] BY .01 (altitude in meters) > siz, hp, vp: [0 .. 90000000.00] (size/precision in meters) > > If omitted, minutes and seconds default to zero, size defaults to 1m, > horizontal precision defaults to 10000m, and vertical precision > defaults to 10m. These defaults are chosen to represent typical > ZIP/postal code area sizes, since it is often easy to find > approximate geographical location by ZIP/postal code. > > 4. Example Data > > ;;; > ;;; note that these data would not all appear in one zone file > ;;; > > ;; network LOC RR derived from ZIP data. note use of precision defaults > cambridge-net.kei.com. LOC 42 21 54 N 71 06 18 W -24m 30m > > ;; higher-precision host LOC RR. note use of vertical precision default > loiosh.kei.com. LOC 42 21 43.952 N 71 5 6.344 W > -24m 1m 200m > > pipex.net. LOC 52 14 05 N 00 08 50 E 10m > > curtin.edu.au. LOC 32 7 19 S 116 2 25 E 10m > > rwy04L.logan-airport.boston. LOC 42 21 28.764 N 71 00 51.617 W > -44m 2000m > > >- country: ... > > Specify here the country codes of the countries where your site is > located. > > Example: > > country: US > > or > > country: DK SE > > >- prefix: > > IPv6Prefix is a prefix that is used within the the IPv6 site. > > Syntax: > > > > Example: > > prefix: 5f0d:0500:c100::/64 > > >- application: [port[/protocol]] > > This attribute describes the different services available on the site. > The services are the same as described in the '/etc/services' plus 'ping' > More services might be added later on. > > Hostname is the DNS hostname of the host that provides the service and > a port number and protocol type may be specified for services that > don't run on the standard port. > > Syntax: > > /^\S+\s+[a-zA-Z\-]+(\.[a-zA-Z\-])*\s+\d+(\/udp|\/tcp))?$/ > > Examples: > > application: ping pinghost.ISI.EDU > application: ftp ftp.ISI.EDU > > >- tunnel: in -> > [FreeText] > > This attribute defines a tunnel of Protocol1 in Protocol2 from address > src to address dst. You only need to define your side of the tunnel. > The other end should be present in the object of the other party's site > object. Note that tunnels should in general be configured symmetrically > along both end-points and only be present in the object if they are > actually configured and working at both ends. > > Currently (only) the following type of tunnels are accepted: > > tunnel: IPv6 in IPv4 -> > [FreeText] > > It is expected that more possibilities will be added later. > > Currently defined protocols are: IDRPv6, BGP5, RIPv6, STATIC > Syntax checking will not be done on this field to allow for newer and > fast implementations of other protocols. > > Domainnames are used for greater flexibility. It makes it for example > trivial to obtain the IPv6 or IPv4 address from DNS if needed. > > Example: > > tunnel: IPv6 in IPv4 tbc5000-18.tbit.dk -> unvea.denet.dk TELEBIT IDRPv6 > > >- contact: > > This is the contact information of the site. Use a valid NIC handle > that you received when creating an entry for your personal data in one > of the registry databases (do 'whois -h whois.ripe.net HELP' for help > on creating such an object). > > Example: > > contact: DK13-RIPE > > Note for DNS databases: > > References for DNS style databases can be defined as follows: > > - use a valid NIC-handle that points to an entry in a whois Internet > registry database > > - use the following syntax: > > contact: YourName (DomainNameOfTextRecordWithYourContactObject) > > - the ipv6-site object has a personal data entry attached in DNS > (separated by an empty record with a line number only) and the > contact entry has the same value as the name of the person. > > person: [mandatory] [single] > address: [mandatory] [multiple] > phone: [mandatory] [multiple] > fax-no: [optional] [multiple] > e-mail: [optional] [multiple] > remarks: [optional] [multiple] > changed: [mandatory] [multiple] > > >- url: > > Put here any useful URLs that are of interest for your site > > Example: > > url: > > >- remarks: > > Put here any information that might be interesting for the other people > at the 6bone to know about or use it for site specific information. > Also 'not yet accepted new functionality' to the objects can be put here > (temporarely). > > Many people use this to report about the status of their site; is it in > implementation phase, is it up and running or are there still techincal > problems. > > Syntax: > > /^.*$/ > > Example: > > remarks: operational since July 5, 1996 > remarks: happy to add new tunnels upon request. > remarks: 6bone-router.cisco.com carries all ipv6 routes. > > >- changed: > > Use this attribute to show who was resposible for a change/addition of > the object and the date on which it took effect. You may use more > changed attribute to reflect the change history of the object. > > The date field has the following format: YYMMDD (in the RIPE database) > Other databases that don't have a format defined yet are recommended to > use an YYYYMMDD format. It is expected that the RIPE database will > support this format in the future. Note that more changes attributes > can be specified to show a history of changes. > > Example: > > changed: davidk@ISI.EDU 960923 > > >- source: RIPE > > This field is always the same for now. It describes the place where the > object can be updated and is stored. > > Example: > > source: RIPE > > Note that a 'source:' field is not relevant for non-RIPE databases. > Whois query tools are recommended to use a 'source: DNS' to identify > data that is extracted from DNS or another clear identifier for other > databases. > > From RLFink@lbl.gov Wed Mar 26 01:25:44 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 25 Mar 1997 17:25:44 -0800 Subject: 6bone WG planning for Memphis Message-ID: The Memphis IETF 6bone WG session has been scheduled for a Wed. afternoon (9 April) one hour time slot. I had decided on a one hour time slot as meeting slots are hard to come by and we should not go any longer than practical with a large group (if San Jose was any example). If this meeting proves we need and can use a longer time slot, we can get one in Munich. I've shown all the IPng sessions below for your convenience. Note that the times have been carefully chosen to keep you in Memphis all week, whether you can find a hotel or not :-) However, the real reason that the IPng meetings are so late in the week is that Steve Deering will be in Japan until Wed. afternoon. The 6bone has been included under the NGTrans WG with me as a co-chair, along with Tony Hain and Bob Gilligan. However, Scott Bradner (one of the current OPS area directors) said that we should, for now, operate as a separate part of NGTrans, much in the same way that IPPM operates under BMWG. I have no problem with this and agree it is sensible that the 6bone be considered part of the IPv6 transition effort. So...for the agenda I have the following to date. Please send email to the list for changes/deletions/additions. My current 6bone agenda is: 1. Topology, addressing and routing issues CAIRN backbone - Mankin routing in the backbone - status from IDR WG addressing beyond RFC 1987 - Fink 2. 6bone routing registry issues RIPE-NCC based - David Kessens DNS based - Bill Manning David Meyer's Internet-Draft on extensions for "Representing Tunnels in RPSL" 3. Decide how to proceed with an Internet-Draft outlining requirements for the new 6bone infrastructure Thanks, Bob ================================================================================ MONDAY, April 7, 1997 1930-2200 Evening Sessions (2 1/2 hours) APP http HyperText Transfer Protocol WG INT frnetmib Frame Relay Service MIB WG INT svrloc Service Location Protocol WG OPS bmwg Benchmarking Methodology WG OPS mboned MBONED Deployment WG >>>>> OPS ngtrans New Generation Transition WG SEC secsh Secure Shell Protocol WG USV isnII Internet School Networking-Educators BOF WEDNESDAY, April 9, 1997 1415-1515 Afternoon Sessions II (1 hour) APP ircup IRC Update BOF APP schema Schema Registration BOF INT dnsind DNS IXFR, Notification, and Dynamic Update WG INT ipcdn IP Over Cable Data Network WG >>>>> OPS 6bone IPv6 Backbone BOF OPS ptopomib Physical Topology MIB WG RTG ospf Open Shortest Path First IGP WG TSV issll Integrated Services over Specific Link Layers WG THURSDAY, April 10, 1997 1300-1500 Afternoon Sessions I (2 hours) APP fax Internet Fax WG APP lsma Large Scale Multicast Applications WG >>>>> INT ipngwg IPNG WG OPS snmpv3 Simple Network Management Protocol Version 3 WG RTG mpls Multiprotocol Label Switching WG SEC ipsec IP Security Protocol WG TSV nfsv4 Network File System Version 4 BOF FRIDAY, April 11, 1997 0830-0900 Continental Breakfast 0900-1130 Morning Sessions (2 1/2 hours) APP drums Detailed Revision/Update of Message Standards WG INT frnetmib Frame Relay Service MIB WG >>>>> INT ipngwg IPNG WG OPS bmwg Benchmarking Methodology WG OPS snmpv3 Simple Network Mangaement Protocol Version 3 WG ================================================================================ From RLFink@lbl.gov Wed Mar 26 18:12:31 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 26 Mar 1997 10:12:31 -0800 Subject: new 6bone diagram - version 60 Message-ID: new 6bone diagram - version 60 DIGITAL-EARC/DE becomes a transit with IBM-ENC/DE stubbed from it Thanks, Bob From Doug Junkins Wed Mar 26 22:20:02 1997 From: Doug Junkins (Doug Junkins) Date: Wed, 26 Mar 1997 14:20:02 -0800 (PST) Subject: New Tunnel NWNet/US <-> IXA/US Message-ID: A new 6Bone tunnel between NorthWestNet, Inc. (NWNET/US) and Interconnected Associates, Inc. (IXA/US) has been configured running RIPng. Our new RIPE entry is: location: Bellevue, Washington, USA loc-string: 47 35 2n 122 8 2w 5m prefix: 5F02:AD00:C050:0D00/64 ping: mahogany.ipv6.nwnet.net (5f02:ad00:c050:d00:1:800:207F:049D) ping: nwnet-6bone-gw.ipv6.nwnet.net (5f02:ad00:c050:d00:1::c1a:c8a8) tunnel: 192.220.249.249 204.123.2.236 DIGITAL-CA/US - RIPng operational tunnel: 192.220.249.249 128.223.222.11 UOREGON/US - RIPng operational tunnel: 192.220.249.249 131.103.1.54 CICNET/US - RIPng operational tunnel: 192.220.249.249 137.229.12.248 ALASKA/US - RIPng operational tunnel: 192.220.249.249 158.43.137.157 UUNET/UK - RIPng experimental tunnel: 192.220.249.249 198.128.2.27 ESNET/US - RIPng operational tunnel: 192.220.249.249 140.142.96.1 UW/US - Static operational tunnel: 192.220.249.249 199.242.16.23 IXA/US - RIPng operational contact: Doug Junkins status: operational since 12/6/96 remarks: nwnet-6bone-gw.nwnet.net is a Cisco 4000M remarks: will add tunnels to people with ipv4 connectivity to remarks: NorthWestNet, MCI, Sprint's Seattle POP, and UUNet's remarks: Seattle and Portland POPs. remarks: Please send connectivity problems and requests to the remarks: above contact changed: junkins@nwnet.net 970326 source: RIPE - Doug / Douglas A. Junkins | Network Engineering \ / Network Engineer | NorthWestNet \ \ junkins@nwnet.net | Bellevue, Washington, USA / \ +1-206-649-7419 | / From guyd@uunet.pipex.com Thu Mar 27 09:55:58 1997 From: guyd@uunet.pipex.com (Guy Davies) Date: Thu, 27 Mar 1997 09:55:58 +0000 (GMT) Subject: New Tunnels to UUNET-UK Message-ID: Hi, New tunnels from JANET/UK, ESNET/US, UCAM-T/UK and NC3A/NL have been configured to UUNET-UK. Also, please note that our tunnel-v4 address is now 158.43.133.254 and _all_ our existing tunnels have been moved to the new address. Thanks to all who helped. Our current ip6rr object is.... site: UUNET-UK location: London, UK & Cambridge, UK prefix: 5f07:3900/32 ping: 5f07:3900:9e2b:8500:0000:1111:1111:1111 6bone-gw.lon.ip6.pipex.net ping: 5f07:3900:9e2b:c000:0000:0060:3e59:4d90 eth0.6bone-gw.lon.ip6.pipex.net ping: 5f07:3900:9e2b:8500:0000:2222:2222:2222 6bone-gw.cam.ip6.pipex.net ping: 5f07:3900:9e2b:8000:0000:0000:0c92:145c eth0.6bone-gw.cam.ip6.pipex.net ping: 5f07:3900:00c2:8200:0000:0000:c00d:03c4 swannee.ip6.pipex.net tunnel: 158.43.133.254 192.31.7.104 CISCO/US RIPng operational tunnel: 158.43.133.254 192.32.29.62 BAY/US RIPng operational tunnel: 158.43.133.254 192.220.249.249 NWNET/US RIPng operational tunnel: 158.43.133.254 194.182.135.253 TELEBIT/DK RIPng operational tunnel: 158.43.133.254 194.105.166.254 IFB/UK RIPng operational tunnel: 158.43.133.254 130.225.231.5 UNI-C/DK RIPng operational tunnel: 158.43.133.254 193.10.66.50 SICS/SE RIPng operational tunnel: 158.43.133.254 204.123.2.236 DIGITAL-CA/US RIPng operational tunnel: 158.43.133.254 198.32.146.11 ISI-LAP/US RIPng operational tunnel: 158.43.133.254 192.87.110.60 SURFNET/NL RIPng operational tunnel: 158.43.133.254 198.128.2.27 ESNET/US RIPng experimental tunnel: 158.43.133.254 129.88.26.2 G6/FR RIPng operational tunnel: 158.43.133.254 194.226.128.99 KIT/KZ static operational tunnel: 158.43.133.254 152.78.65.209 USOT-ECS/UK RIPng operational tunnel: 158.43.133.254 194.80.33.20 ULANC/UK RIPng operational tunnel: 158.43.133.254 130.88.12.119 UMAN/UK RIPng operational tunnel: 158.43.133.254 193.63.94.6 JANET/UK RIPng experimental tunnel: 158.43.133.254 131.111.193.104 UCAM-T/UK static operational tunnel: 158.43.133.254 192.150.94.61 NC3A/NL static operational tunnel-v4: 158.43.133.254 tunnel-v6: 5f07:3900:9e2b:8500:0000:1111:1111:1111 contact: IPv6 operations status: operational since 20-Feb-97 remark: DNS operational for forward (ip6.pipex.net) and reverse remark: (0.0.9.3.7.0.f.5.ip6.int) zones remark: http://swannee.ip6.pipex.net:81/index.html (currently dead)-: remark: Willing to add tunnels on request, particularly to customers remark: of UUNET or MFS/WorldCom worldwide or organisations connected remark: to LINX, D-GIX or AMS-IX. remark: Currently support RIPng or static routing changed: Guy.Davies@uunet.pipex.com 970326 source: RIPE Regards, Guy From RLFink@lbl.gov Thu Mar 27 16:13:19 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 27 Mar 1997 08:13:19 -0800 Subject: 6bone Agenda (v2) for Memphis Message-ID: 6bone Agenda (v2) for Memphis below. Please email me changes, deletions, and additions. Thanks, Bob 6bone Agenda (v2) for Memphis ____________________________ 1. Topology, addressing and routing issues CAIRN backbone - Mankin routing in the backbone - status from IDR WG addressing beyond RFC 1987 - Fink Prefix aggregation problems - Durand <<<<<<<<<<< added 2. 6bone routing registry issues RIPE-NCC based - David Kessens DNS based - Bill Manning David Meyer's Internet-Draft on extensions for "Representing Tunnels in RPSL" 3. Decide how to proceed with an Internet-Draft outlining requirements for the new 6bone infrastructure =============================================================================== Reposted for your information =============================================================================== The Memphis IETF 6bone WG session has been scheduled for a Wed. afternoon (9 April) one hour time slot. I had decided on a one hour time slot as meeting slots are hard to come by and we should not go any longer than practical with a large group (if San Jose was any example). If this meeting proves we need, and can use, a longer time slot, we can get one in Munich. I've shown all the IPng sessions below for your convenience. Note that the times have been carefully chosen to keep you in Memphis all week, whether you can find a hotel or not :-) However, the real reason that the IPng meetings are so late in the week is that Steve Deering will be in Japan until Wed. afternoon. The 6bone has been included under the NGTrans WG with me as a co-chair, along with Tony Hain and Bob Gilligan. However, Scott Bradner (one of the current OPS area directors) said that we should, for now, operate as a separate part of NGTrans, much in the same way that IPPM operates under BMWG. I have no problem with this and agree it is sensible that the 6bone be considered part of the IPv6 transition effort. ================================================================================ MONDAY, April 7, 1997 1930-2200 Evening Sessions (2 1/2 hours) APP http HyperText Transfer Protocol WG INT frnetmib Frame Relay Service MIB WG INT svrloc Service Location Protocol WG OPS bmwg Benchmarking Methodology WG OPS mboned MBONED Deployment WG >>>>> OPS ngtrans New Generation Transition WG SEC secsh Secure Shell Protocol WG USV isnII Internet School Networking-Educators BOF WEDNESDAY, April 9, 1997 1415-1515 Afternoon Sessions II (1 hour) APP ircup IRC Update BOF APP schema Schema Registration BOF INT dnsind DNS IXFR, Notification, and Dynamic Update WG INT ipcdn IP Over Cable Data Network WG >>>>> OPS 6bone IPv6 Backbone BOF OPS ptopomib Physical Topology MIB WG RTG ospf Open Shortest Path First IGP WG TSV issll Integrated Services over Specific Link Layers WG THURSDAY, April 10, 1997 1300-1500 Afternoon Sessions I (2 hours) APP fax Internet Fax WG APP lsma Large Scale Multicast Applications WG >>>>> INT ipngwg IPNG WG OPS snmpv3 Simple Network Management Protocol Version 3 WG RTG mpls Multiprotocol Label Switching WG SEC ipsec IP Security Protocol WG TSV nfsv4 Network File System Version 4 BOF FRIDAY, April 11, 1997 0830-0900 Continental Breakfast 0900-1130 Morning Sessions (2 1/2 hours) APP drums Detailed Revision/Update of Message Standards WG INT frnetmib Frame Relay Service MIB WG >>>>> INT ipngwg IPNG WG OPS bmwg Benchmarking Methodology WG OPS snmpv3 Simple Network Mangaement Protocol Version 3 WG ================================================================================ From dhaskin@baynetworks.com Thu Mar 27 19:02:07 1997 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Thu, 27 Mar 1997 14:02:07 -0500 Subject: 6bone Agenda (v2) for Memphis Message-ID: <3.0.32.19970327140206.0069dbf4@pobox.engeast.baynetworks.com> Bob, I'd like to discuss a possibility of getting a real block of IPv6 addresses for 6bone. I.e., 6bone would become a registry, a big structure, an exchange point, a provider collaboration.. - whatever you want to call it. We would attempt to set up an address administration/delegation services where 6bone clients would be able to get their site prefixes. The idea is to make it as real possible. This would provide as with a infrastructure for testing out the address assignment concepts as well as re-numbering and aggregation schemes. In the end, who know, 6bone may even grow into a real IPv6 network as ARPANET once did. Too much to ask? Dimitry At 08:13 AM 3/27/97 -0800, Bob Fink LBNL wrote: >6bone Agenda (v2) for Memphis below. Please email me changes, deletions, >and additions. > > >Thanks, > >Bob > > >6bone Agenda (v2) for Memphis >____________________________ > >1. Topology, addressing and routing issues > > CAIRN backbone - Mankin > > routing in the backbone - status from IDR WG > > addressing beyond RFC 1987 - Fink > > Prefix aggregation problems - Durand <<<<<<<<<<< added > > >2. 6bone routing registry issues > > RIPE-NCC based - David Kessens > > DNS based - Bill Manning > > David Meyer's Internet-Draft on extensions for > "Representing Tunnels in RPSL" > > >3. Decide how to proceed with an Internet-Draft outlining requirements for the >new 6bone infrastructure > > >=========================================================================== ==== >Reposted for your information >=========================================================================== ==== > >The Memphis IETF 6bone WG session has been scheduled for a Wed. afternoon >(9 April) one hour time slot. I had decided on a one hour time slot as >meeting slots are hard to come by and we should not go any longer than >practical with a large group (if San Jose was any example). If this >meeting proves we need, and can use, a longer time slot, we can get one in >Munich. > >I've shown all the IPng sessions below for your convenience. Note that the >times have been carefully chosen to keep you in Memphis all week, whether >you can find a hotel or not :-) > >However, the real reason that the IPng meetings are so late in the week is >that Steve Deering will be in Japan until Wed. afternoon. > > >The 6bone has been included under the NGTrans WG with me as a co-chair, >along with Tony Hain and Bob Gilligan. However, Scott Bradner (one of the >current OPS area directors) said that we should, for now, operate as a >separate part of NGTrans, much in the same way that IPPM operates under >BMWG. > >I have no problem with this and agree it is sensible that the 6bone be >considered part of the IPv6 transition effort. >=========================================================================== ===== > >MONDAY, April 7, 1997 > >1930-2200 Evening Sessions (2 1/2 hours) > > APP http HyperText Transfer Protocol WG > INT frnetmib Frame Relay Service MIB WG > INT svrloc Service Location Protocol WG > OPS bmwg Benchmarking Methodology WG > OPS mboned MBONED Deployment WG >>>>>> OPS ngtrans New Generation Transition WG > SEC secsh Secure Shell Protocol WG > USV isnII Internet School Networking-Educators BOF > > >WEDNESDAY, April 9, 1997 > >1415-1515 Afternoon Sessions II (1 hour) > > APP ircup IRC Update BOF > APP schema Schema Registration BOF > INT dnsind DNS IXFR, Notification, and Dynamic Update WG > INT ipcdn IP Over Cable Data Network WG >>>>>> OPS 6bone IPv6 Backbone BOF > OPS ptopomib Physical Topology MIB WG > RTG ospf Open Shortest Path First IGP WG > TSV issll Integrated Services over Specific Link Layers WG > > >THURSDAY, April 10, 1997 > >1300-1500 Afternoon Sessions I (2 hours) > > APP fax Internet Fax WG > APP lsma Large Scale Multicast Applications WG >>>>>> INT ipngwg IPNG WG > OPS snmpv3 Simple Network Management Protocol Version 3 WG > RTG mpls Multiprotocol Label Switching WG > SEC ipsec IP Security Protocol WG > TSV nfsv4 Network File System Version 4 BOF > >FRIDAY, April 11, 1997 > >0830-0900 Continental Breakfast >0900-1130 Morning Sessions (2 1/2 hours) > > APP drums Detailed Revision/Update of Message Standards WG > INT frnetmib Frame Relay Service MIB WG >>>>>> INT ipngwg IPNG WG > OPS bmwg Benchmarking Methodology WG > OPS snmpv3 Simple Network Mangaement Protocol Version 3 WG > >=========================================================================== ===== > > > > From RLFink@lbl.gov Thu Mar 27 19:01:30 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 27 Mar 1997 11:01:30 -0800 Subject: 6bone operational discussion luncheon - Tuesday the 8th Message-ID: I would like to invite 6bone folk from RIPE-NCC registered 6bone sites to a no-host lunch (that means you pay for your own lunch :-) on Tuesday the 8th of April in Memphis. The topic would be whatever is of interest relating to 6bone operational issues. The attendance is limited in this way so we don't have a swarm of those just interested in listening in, else we won't get any useful discussion. If there is something of interest from the lunch to report, I will do so at the 6bone meeting on Wed. Others not having attended the lunch can comment and interact if relevant at that time. I propose we meet Tuesday at 1130 at the IETF reg desk area, and go to lunch from there. Please let me know by private email if you intend to participate. Thanks, Bob From RLFink@lbl.gov Thu Mar 27 21:13:43 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 27 Mar 1997 13:13:43 -0800 Subject: 6bone Agenda (v2) for Memphis In-Reply-To: <3.0.32.19970327140206.0069dbf4@pobox.engeast.baynetworks.com> Message-ID: Dimitry, At 11:02 AM -0800 3/27/97, Dimitry Haskin wrote: ... >I'd like to discuss a possibility of getting a real block of IPv6 addresses >for 6bone. I.e., >6bone would become a registry, a big structure, an exchange point, a >provider collaboration.. - whatever you want to call it. We would attempt >to set up an address administration/delegation services where 6bone clients >would be able to get their site prefixes. The idea is to make it as real >possible. This would provide as with a infrastructure for testing out the >address assignment concepts as well as re-numbering and aggregation >schemes. In the end, who know, 6bone may even grow into a real IPv6 >network as ARPANET once did. > >Too much to ask? Not really. The agenda item "addressing beyond RFC 1987" was intended to give some voice to this topic in general. So I'll put you on before that item. Obviously there are bound to be numerous points of view on this, so we might as well start the dialog on it in Memphis (unless some brave souls wish to venture out on the list before then :-). Thanks, Bob From RLFink@lbl.gov Thu Mar 27 21:13:57 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 27 Mar 1997 13:13:57 -0800 Subject: 6bone Agenda (v3) for Memphis Message-ID: 6bone Agenda (v3) for Memphis below. Please email me changes, deletions, and additions. Thanks, Bob 6bone Agenda (v3) for Memphis ____________________________ 1. Topology, addressing and routing issues CAIRN backbone - Mankin routing in the backbone - status from IDR WG a 6bone IPv6 address block and registry - Haskin <<<<<<<<<<< added addressing beyond RFC 1987 - Fink Prefix aggregation problems - Durand 2. 6bone routing registry issues RIPE-NCC based - David Kessens DNS based - Bill Manning David Meyer's Internet-Draft on extensions for "Representing Tunnels in RPSL" 3. Decide how to proceed with an Internet-Draft outlining requirements for the new 6bone infrastructure =============================================================================== Reposted for your information =============================================================================== The Memphis IETF 6bone WG session has been scheduled for a Wed. afternoon (9 April) one hour time slot. I had decided on a one hour time slot as meeting slots are hard to come by and we should not go any longer than practical with a large group (if San Jose was any example). If this meeting proves we need, and can use, a longer time slot, we can get one in Munich. I've shown all the IPng sessions below for your convenience. Note that the times have been carefully chosen to keep you in Memphis all week, whether you can find a hotel or not :-) However, the real reason that the IPng meetings are so late in the week is that Steve Deering will be in Japan until Wed. afternoon. The 6bone has been included under the NGTrans WG with me as a co-chair, along with Tony Hain and Bob Gilligan. However, Scott Bradner (one of the current OPS area directors) said that we should, for now, operate as a separate part of NGTrans, much in the same way that IPPM operates under BMWG. I have no problem with this and agree it is sensible that the 6bone be considered part of the IPv6 transition effort. ================================================================================ MONDAY, April 7, 1997 1930-2200 Evening Sessions (2 1/2 hours) APP http HyperText Transfer Protocol WG INT frnetmib Frame Relay Service MIB WG INT svrloc Service Location Protocol WG OPS bmwg Benchmarking Methodology WG OPS mboned MBONED Deployment WG >>>>> OPS ngtrans New Generation Transition WG SEC secsh Secure Shell Protocol WG USV isnII Internet School Networking-Educators BOF WEDNESDAY, April 9, 1997 1415-1515 Afternoon Sessions II (1 hour) APP ircup IRC Update BOF APP schema Schema Registration BOF INT dnsind DNS IXFR, Notification, and Dynamic Update WG INT ipcdn IP Over Cable Data Network WG >>>>> OPS 6bone IPv6 Backbone BOF OPS ptopomib Physical Topology MIB WG RTG ospf Open Shortest Path First IGP WG TSV issll Integrated Services over Specific Link Layers WG THURSDAY, April 10, 1997 1300-1500 Afternoon Sessions I (2 hours) APP fax Internet Fax WG APP lsma Large Scale Multicast Applications WG >>>>> INT ipngwg IPNG WG OPS snmpv3 Simple Network Management Protocol Version 3 WG RTG mpls Multiprotocol Label Switching WG SEC ipsec IP Security Protocol WG TSV nfsv4 Network File System Version 4 BOF FRIDAY, April 11, 1997 0830-0900 Continental Breakfast 0900-1130 Morning Sessions (2 1/2 hours) APP drums Detailed Revision/Update of Message Standards WG INT frnetmib Frame Relay Service MIB WG >>>>> INT ipngwg IPNG WG OPS bmwg Benchmarking Methodology WG OPS snmpv3 Simple Network Mangaement Protocol Version 3 WG ================================================================================ From bmanning@ISI.EDU Fri Mar 28 00:10:16 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Thu, 27 Mar 1997 16:10:16 -0800 (PST) Subject: 6bone Agenda (v2) for Memphis In-Reply-To: from "Bob Fink LBNL" at Mar 27, 97 01:13:43 pm Message-ID: <199703280010.AA18737@zed.isi.edu> > might as well start the dialog on it in Memphis (unless some brave souls > wish to venture out on the list before then :-). > Humm, Well, there do seem to be the existing practive/experimental allocation methods (these may never go away). The registries have some guidance on hwo to parcel up IPv6 blocks based on the existant addressing guidelines. Then there is the MO 6+2+8 proposal for address "meaning" which might not be quite in line with the other "lead dog" in delegation practice. I suspect that what Dimetry has proposed is a varient of the secodn point. -- --bill From bound@zk3.dec.com Fri Mar 28 05:28:50 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Fri, 28 Mar 97 00:28:50 -0500 Subject: 6bone Agenda (v2) for Memphis In-Reply-To: Your message of "Thu, 27 Mar 97 14:02:07 EST." <3.0.32.19970327140206.0069dbf4@pobox.engeast.baynetworks.com> Message-ID: <9703280528.AA16819@wasted.zk3.dec.com> I really really really really really really think Dimitry's idea is wonderful. /jim From RLFink@lbl.gov Fri Mar 28 14:48:42 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 28 Mar 1997 06:48:42 -0800 Subject: new 6bone drawing - version 61 Message-ID: new 6bone drawing - version 61 move IXA/US to NWNET/US and make it transit add LAB/US to IXA/US move UICAM-T/UK to UUNET/UK Anyone know if JANET/UK and NC3A/NL are going into the 6bone registry? Thanks, Bob From RLFink@lbl.gov Fri Mar 28 14:59:38 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 28 Mar 1997 06:59:38 -0800 Subject: another new site for 6bone drawing version 61 Message-ID: Forgot to mention adding STUBA/SK to UUNET/UK in version 61 of the diagram. Welcome to STUBA (Slovak University of Technology, FEI, Department of Computer Science and Engineering) location: Bratislava, Slovak Republic Neat! Bob From bmanning@ISI.EDU Fri Mar 28 19:20:47 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Fri, 28 Mar 1997 11:20:47 -0800 (PST) Subject: 6bone Agenda (v2) for Memphis In-Reply-To: <9703280528.AA16819@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Mar 28, 97 00:28:50 am Message-ID: <199703281920.AA27934@zed.isi.edu> > > I really really really really really really think Dimitry's idea is > wonderful. > > /jim And you really really really really really really really think that creation of YAR is a good thing? Why not "encourage" ARIN to get off the pot and start delegation per their draft guidelines? --bill From kaos@ocs.com.au Sun Mar 30 05:22:28 1997 From: kaos@ocs.com.au (Keith Owens) Date: Sun, 30 Mar 1997 15:22:28 +1000 Subject: New 6bone leaf node, OCS-AU Message-ID: <19970330051837.31633.qmail@mail.ocs.com.au> site: O. C. Software P/L location: Greensborough, Victoria, Australia prefix: 5F04:C500:CB22:6100/64 ping: 5F04:C500:CB22:6100::6 router-6.ocs.com.au tunnel: 203.34.97.6 131.103.1.54 CICNET - static - operational contact: Keith Owens status: operational since March 20, 1997 remark: Linux 2.1.29, test machine, not always booted. remark: CICNET tunnel is temporary, will convert to Australian 6bone remark: transit node when it becomes available. remark: Forward DNS in place, waiting for delegation of ip6.int from remark: Australian backbone. changed: kaos@ocs.com.au 970330 source: RIPE From andy@thomas.ge.com Mon Mar 31 14:52:00 1997 From: andy@thomas.ge.com (Andrew L Hazeltine) Date: Mon, 31 Mar 1997 09:52:00 -0500 Subject: New site - ASCI Message-ID: <199703311452.JAA11851@thomas.ge.com> Hi, Advanced Systems Consulting, Inc. (ASCI) is now connected to the 6bone. Our tunnel became fully operational on March 7 when I finally got RIPng working. Our updated RIPE entry is: site: Advanced Systems Consulting, Inc. location: Marlton, NJ, USA loc-string: 39 55 00n 74 56 15w prefix: 5f01:600:c631:da00::/64 ping: 5f01:600:c631:da00:4701:20:af0a:ed6a penne.ipv6.advsys.com tunnel: 198.49.218.71 192.31.7.104 CISCO RIPng contact: Andrew Hazeltine status: operational since December 1996 remark: End systems: x86/Linux, Sparc/Solaris changed: andy@advsys.com 970328 source: RIPE - Andy From RLFink@lbl.gov Mon Mar 31 16:12:46 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 31 Mar 1997 08:12:46 -0800 Subject: new 6bone b/b links diagram - version 9 Message-ID: new 6bone b/b links diagram - version 9 G6/FR link to SICS/SE now RIPng Thanks, Bob From RLFink@lbl.gov Mon Mar 31 16:08:39 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 31 Mar 1997 08:08:39 -0800 Subject: new 6bone diagram - version 62 Message-ID: new 6bone diagram - version 62 change G6 Universities to G6 French IPv6 Group (it is broader than just French Univ.) add OCS/AU as a leaf off CICNET/US Thanks, Bob From RLFink@lbl.gov Mon Mar 31 18:40:23 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 31 Mar 1997 10:40:23 -0800 Subject: 6bone Agenda (v4) for Memphis Message-ID: 6bone Agenda (v4) for Memphis below. Please email me changes, deletions, and additions. Thanks, Bob 6bone Agenda (v3) for Memphis ____________________________ 1. Topology, addressing and routing issues CAIRN backbone - Mankin routing in the backbone - status from IDR WG a 6bone IPv6 address block and registry - Haskin addressing beyond RFC 1987 - Fink Prefix aggregation problems - Durand 2. 6bone routing registry issues David Meyer's Internet-Draft on extensions for <<< order changed "Representing Tunnels in RPSL" - Meyer RIPE-NCC based - David Kessens <<< order changed DNS based - Bill Manning <<< order changed 3. Decide how to proceed with an Internet-Draft outlining requirements for the new 6bone infrastructure =============================================================================== Reposted for your information =============================================================================== The Memphis IETF 6bone WG session has been scheduled for a Wed. afternoon (9 April) one hour time slot. I had decided on a one hour time slot as meeting slots are hard to come by and we should not go any longer than practical with a large group (if San Jose was any example). If this meeting proves we need, and can use, a longer time slot, we can get one in Munich. I've shown all the IPng sessions below for your convenience. Note that the times have been carefully chosen to keep you in Memphis all week, whether you can find a hotel or not :-) However, the real reason that the IPng meetings are so late in the week is that Steve Deering will be in Japan until Wed. afternoon. The 6bone has been included under the NGTrans WG with me as a co-chair, along with Tony Hain and Bob Gilligan. However, Scott Bradner (one of the current OPS area directors) said that we should, for now, operate as a separate part of NGTrans, much in the same way that IPPM operates under BMWG. I have no problem with this and agree it is sensible that the 6bone be considered part of the IPv6 transition effort. ================================================================================ MONDAY, April 7, 1997 1930-2200 Evening Sessions (2 1/2 hours) APP http HyperText Transfer Protocol WG INT frnetmib Frame Relay Service MIB WG INT svrloc Service Location Protocol WG OPS bmwg Benchmarking Methodology WG OPS mboned MBONED Deployment WG >>>>> OPS ngtrans New Generation Transition WG SEC secsh Secure Shell Protocol WG USV isnII Internet School Networking-Educators BOF WEDNESDAY, April 9, 1997 1415-1515 Afternoon Sessions II (1 hour) APP ircup IRC Update BOF APP schema Schema Registration BOF INT dnsind DNS IXFR, Notification, and Dynamic Update WG INT ipcdn IP Over Cable Data Network WG >>>>> OPS 6bone IPv6 Backbone BOF OPS ptopomib Physical Topology MIB WG RTG ospf Open Shortest Path First IGP WG TSV issll Integrated Services over Specific Link Layers WG THURSDAY, April 10, 1997 1300-1500 Afternoon Sessions I (2 hours) APP fax Internet Fax WG APP lsma Large Scale Multicast Applications WG >>>>> INT ipngwg IPNG WG OPS snmpv3 Simple Network Management Protocol Version 3 WG RTG mpls Multiprotocol Label Switching WG SEC ipsec IP Security Protocol WG TSV nfsv4 Network File System Version 4 BOF FRIDAY, April 11, 1997 0830-0900 Continental Breakfast 0900-1130 Morning Sessions (2 1/2 hours) APP drums Detailed Revision/Update of Message Standards WG INT frnetmib Frame Relay Service MIB WG >>>>> INT ipngwg IPNG WG OPS bmwg Benchmarking Methodology WG OPS snmpv3 Simple Network Mangaement Protocol Version 3 WG ================================================================================ From bmanning@ISI.EDU Mon Mar 3 21:53:50 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Mon, 3 Mar 1997 13:53:50 -0800 (PST) Subject: Getting attached... > > Note that an RFC1897 format address includes the ASN (Autonomous System > > Number) of one's provider, not an ASN that belongs to one's own site. > > (Though a provider uses its own ASN.) > > This is would make my address > > 5F: (01011111 == first 8 bits) > 0D: T > E9: +- 3561 (for MCI's ASN) > 00: (RES == reserved...?) > CE: 206. \ > 9C: 156. > our IPv4 class C subnet > 94: 148. / > 00: (RES == reserved...) Hi, It looks like the 0.0.9.e.d.0.f.5.ip6.int. entry is registered to Jim Bound of DEC. It might be prudent to have MCI clarify is delegation procedures for these test address blocks. Jim? -- --bill