From thomas.eklund@era-t.ericsson.se Fri Nov 1 09:16:50 1996 From: thomas.eklund@era-t.ericsson.se (Thomas Eklund) Date: Fri, 01 Nov 1996 10:16:50 +0100 Subject: ERA connected to the 6bone Message-ID: <3279C002.5BDE@era-t.ericsson.se> Hi, I just want to announce that a new site (ERA - ERicsson Radio Systems) is up and running on the 6bone. And I'm happy to set up a tunnel to anyone who wants it. Currently there are 5 tunnels up and running in both directions. They are to SICS, UNI-C, Telebit, G6 and NRL. The RIPE database entry look like: ----------------------------------- site: ERA - Ericsson Radio Systems location: Kista (Stockholm), SWEDEN prefix: 5f0b:1700:c047:1400::/64 ping: 5f0b:1700:c047:1400::800:200d:1cfe tunnel: 192.71.20.139 193.10.66.50 SICS tunnel: 192.71.20.139 129.88.26.1 G6 tunnel: 192.71.20.139 194.182.135.253 Telebit tunnel: 192.71.20.139 132.250.90.5 NRL tunnel: 192.71.20.139 130.225.231.5 UNI-C contact: Thomas Eklund status: operational since 29 oct 1996 remark: Sun workstation running NetBSD remark: with INRIAS implementation of IPv6 changed: thomas.eklund@era-t.ericsson.se 961029 source: RIPE ------------------------------------ Regards /Thomas Eklund thomas.eklund@era-t.ericsson.se :-) From mdp@tbit.dk Fri Nov 1 16:49:19 1996 From: mdp@tbit.dk (Martin D. Peck) Date: Fri, 01 Nov 1996 17:49:19 +0100 Subject: New Tunnels Message-ID: <327A2A0F.490B@tbit.dk> Hi Bob, Three operational tunnels have been added. ifb (Internet For Business, Aberdeen) to Telebit (Viby): Dynamic Route G6 (Grenoble) to Telebit (Viby): Static Route ERA (Ericsson Radio Systems, Kista) to Telebit (Viby): Static Route Our RIPE database entry is now as follows. site: telebit communications a/s location: Viby J. , Denmark prefix: 5f0c:bf00/32 ping: 5f0c:bf00:C2b6:8700:00fd:1111:1111:1111 ping: 5f0c:bf00:C2b6:8700:00fd:2222:2222:2222 tunnel: 194.182.135.253 130.225.231.5 UNI-C IDRPv6 tunnel: 194.182.135.253 128.176.191.66 JOIN IDRPv6 tunnel: 194.182.135.253 194.105.166.254 ifb IDRPv6 tunnel: 194.182.135.253 193.55.240.18 G6 Static tunnel: 194.182.135.253 192.71.20.139 ERA Static contact: supp@tbit.dk status: operational remark: http://www.tbit.dk changed: hha@tbit.dk 961101 source: RIPE Many Thanks, Martin em: info@tbit.dk From RLFink@lbl.gov Fri Nov 1 15:53:37 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 1 Nov 1996 07:53:37 -0800 Subject: 6bone map change, new sites and tunnels Message-ID: 6bone Diagram version 31: New site NETGOD/US, tunneled to CISCO/US New site IFB/UK, tunneled to UMAN/UK and TELEBIT/DK New site IBM/US, tunneled to NRL/US New site SUMITOMO-JP, tunneled to NUS-IRDU/SG & SUMITOMO-USA/JP New site ERS/SE, tunneled to TELEBIT/DK, UNI-C/DK, SICS/SE, G6/FR & NRL/US Welcome to all the new sites! Please sanity check your sites connectivity in the drawing, and double check all the multi-homed links are in their corresponding RIPE-NCC entries. This may "cook" this form of map (tho I can stress it a while longer) and may soon need to change to a transit map for the top level with submaps below. Thanks, Bob From dhaskin@baynetworks.com Fri Nov 1 18:32:25 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Fri, 1 Nov 1996 13:32:25 -0500 Subject: RIP on 6bone Message-ID: <199611011832.NAA28369@pobox.BayNetworks.com> Folks, Does any one have a RIPng implementation that they would like to try with a Bay router via a tunnel link? Thanks, Dimitry From ben@ibs-us.net Fri Nov 1 18:50:57 1996 From: ben@ibs-us.net (Ben Kirkpatrick) Date: Fri, 01 Nov 1996 10:50:57 -0800 Subject: No subject Message-ID: <327A4691.7D0@telenova.com> list From RLFink@lbl.gov Fri Nov 1 19:38:21 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 1 Nov 1996 11:38:21 -0800 Subject: T-shirts In-Reply-To: <9610301721.AA07170@wasted.zk3.dec.com> Message-ID: Jim, At 9:21 AM -0800 10/30/96, wrote: >Spoke with Matt Crawford off line and he pointed out the errors of my >thinking. You asked for input not consensus. I apologize I missed this >point. The only defense I have is I am very paranoid of the >good-ole-boy network that has joined this list. Its your call and I >think the key point is for people to see that the 6bone is working and >growing exponentially. Thanks for your nice note. To be honest, I'm often not even aware when someone emails me and doesn't cc: the list...nor do I generally care. It is still my inclination to keep the Tshirt with just the globe and the country/site listing as, IMHO, it will be the most visual impact to those seeing us wearing it. And, of course, Bay, Cisco, Digital, Telebit and other implementation companies will clearly show on it and I doubt anyone will miss the significance of that. Thanks, Bob From ahoag@nas.nasa.gov Fri Nov 1 19:51:18 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Fri, 1 Nov 1996 11:51:18 -0800 Subject: 3D Map updates Message-ID: <9611011151.ZM12128@rennsport.nas.nasa.gov> I have added ERA, NETGOD, IBM and verified that the map is current with the RIPE database (as of 0800 PST). Sometime this weekend I'll try and produce the seperations for the T-shirt for Bob. If there are any last minute tunnel changes, let me know before Sunday. I'm going to start publishing the tunnels that I've found to be asymmetric. In munging the data I can produce some stats... This most current run is shown below: 121 (63 / 58 dups) tunnels processed for 43 sites. Asymmetric tunnel: ERA (192.71.20.139) --> SICS (193.10.66.50) Asymmetric tunnel: ERA (192.71.20.139) --> G6 (129.88.26.1) Asymmetric tunnel: NETGOD (206.129.65.250) --> WWU (140.160.166.22) Asymmetric tunnel: NRL (132.250.90.5) --> IFB (194.105.166.254) Asymmetric tunnel: TELEBIT (194.182.135.253) --> G6 (193.55.240.18) Meaning my program found 43 RIPE-NCC files (I removed NUS since it duplicated NUS-IRDU) with 121 tunnels. Of those, 63 were original and 58 were the reverse-direction. Five tunnels (listed above) do not have both directions defined in both files. -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From masaki@merit.edu Fri Nov 1 19:54:04 1996 From: masaki@merit.edu (Masaki Hirabaru) Date: Fri, 01 Nov 1996 14:54:04 -0500 Subject: RIP on 6bone In-Reply-To: Your message of "Fri, 01 Nov 1996 13:32:25 EST." <199611011832.NAA28369@pobox.BayNetworks.com> Message-ID: <199611011954.OAA26394@merit.edu> Dimitry, We've developed RIPng implementation which works on Solaris, INRIA and Linux ipv6. If we have a chance to try with another RIPng implementation, it's greatly appriciated. Masaki Merit Network > Date: Fri, 1 Nov 1996 13:32:25 -0500 > From: dhaskin@baynetworks.com (Dimitry Haskin) > Message-Id: <199611011832.NAA28369@pobox.BayNetworks.com> > To: 6bone@ISI.EDU > Subject: RIP on 6bone > Sender: owner-6bone@ISI.EDU > Precedence: bulk > > Folks, > > Does any one have a RIPng implementation that they would like > to try with a Bay router via a tunnel link? > > Thanks, > Dimitry From bound@zk3.dec.com Sat Nov 2 16:31:15 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Sat, 02 Nov 96 11:31:15 -0500 Subject: T-shirts In-Reply-To: Your message of "Fri, 01 Nov 96 11:38:21 PST." Message-ID: <9611021631.AA05390@wasted.zk3.dec.com> I am in synch now and look forward to wearing the TShirt. p.s. the requests I am seeing for 6bone access and Digital kits is getting to the point that its going to require us to have someone on it full time with the way things are going. Its moving much faster than I expected. I am also now hearing of private Intranets that want to run IPv6 and not wait on "whoever" which is also moving faster than I projected in my mind and to my superiors. thanks for the hard work, /jim From jcday@jpd.ch.man.ac.uk Sat Nov 2 17:24:41 1996 From: jcday@jpd.ch.man.ac.uk (Jonathan Day) Date: Sat, 2 Nov 1996 17:24:41 +0000 (GMT) Subject: T-shirts In-Reply-To: <9611021631.AA05390@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Nov 2, 96 11:31:15 am Message-ID: <199611021724.RAA01217@jpd.ch.man.ac.uk> > I am in synch now and look forward to wearing the TShirt. Same here. When's the T-Shirt shipping & how much will it cost to those of us in Merrie Englande? > p.s. the requests I am seeing for 6bone access and Digital kits is > getting to the point that its going to require us to have someone on it > full time with the way things are going. Its moving much faster than I > expected. I am also now hearing of private Intranets that want to run > IPv6 and not wait on "whoever" which is also moving faster than I > projected in my mind and to my superiors. It doesn't surprise me that much. These sorts of technological changes are bound to attract a lot of attention which, in turn, will lead to further developments, which in turn will generate yet more attention. It's much more surprising that anyone would be surprised by it. To be honest, I can't think of many developments in computing in the past 16 years that haven't followed the same pattern. IMHO, it's vitally important that the pace of change is sustained and that more 'user-side' software is developed to feed that pace. Jonathan From pcurran@ticl.co.uk Sun Nov 3 11:07:58 1996 From: pcurran@ticl.co.uk (Peter Curran) Date: Sun, 3 Nov 1996 11:07:58 -0000 Subject: T-shirts Message-ID: <199611031102.LAA05457@gate.ticl.co.uk> > > I am in synch now and look forward to wearing the TShirt. > > Same here. When's the T-Shirt shipping & how much will it cost to > those of us in Merrie Englande? > To make things easier: It would probably be easier (cheaper) if a person collected orders for the T-Shirt from UK boners and a single batch was shipped across the pond. If nobody else wants to volunteer then I will be happy to do it. Peter ======================================================================= Peter Curran | Internet & Security Consultancy The Internet Connection Ltd | Name Registration Service pcurran@ticl.co.uk | Training & Seminars phone: +44-1306-881944 | http://www.ticl.co.uk ======================================================================= From patel@marvin.enet.dec.com Mon Nov 4 08:01:30 1996 From: patel@marvin.enet.dec.com (Jitu Patel (IP (V6/V4) and OSI Routing), REO2-F/D8 DTN 830 3520) Date: Mon, 4 Nov 96 00:01:30 PST Subject: RIP on 6bone Message-ID: <9611040801.AA24111@nsl.pa.dec.com> Dimitry, I have RIPNg on our Digital routers. I will set it up tomorrow. You could try connecting to pax-6bone.pa-x.dec.com from you end. What is the tunnel address at your end ? Jitu From RLFink@lbl.gov Mon Nov 4 16:11:59 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 4 Nov 1996 08:11:59 -0800 Subject: 6bone map change Message-ID: 6bone diagram version 32: Add new tunnel from TELEBIT/DK to G6/FR minor other corrections (or...Bob may eventually get it right :-) Thanks, Bob ==== Date: Fri, 01 Nov 1996 17:49:19 +0100 From: "Martin D. Peck" MIME-Version: 1.0 To: RLFink@lbl.gov CC: 6bone@ISI.EDU Subject: New Tunnels Hi Bob, Three operational tunnels have been added. ifb (Internet For Business, Aberdeen) to Telebit (Viby): Dynamic Route G6 (Grenoble) to Telebit (Viby): Static Route ERA (Ericsson Radio Systems, Kista) to Telebit (Viby): Static Route Our RIPE database entry is now as follows. site: telebit communications a/s location: Viby J. , Denmark prefix: 5f0c:bf00/32 ping: 5f0c:bf00:C2b6:8700:00fd:1111:1111:1111 ping: 5f0c:bf00:C2b6:8700:00fd:2222:2222:2222 tunnel: 194.182.135.253 130.225.231.5 UNI-C IDRPv6 tunnel: 194.182.135.253 128.176.191.66 JOIN IDRPv6 tunnel: 194.182.135.253 194.105.166.254 ifb IDRPv6 tunnel: 194.182.135.253 193.55.240.18 G6 Static tunnel: 194.182.135.253 192.71.20.139 ERA Static contact: supp@tbit.dk status: operational remark: http://www.tbit.dk changed: hha@tbit.dk 961101 source: RIPE Many Thanks, Martin em: info@tbit.dk - From patel@marvin.enet.dec.com Sun Nov 3 13:37:33 1996 From: patel@marvin.enet.dec.com (Jitu Patel (IP (V6/V4) and OSI Routing), REO2-F/D8 DTN 830 3520) Date: Sun, 3 Nov 96 13:37:33 MET Subject: RIP on 6bone Message-ID: <199611031237.NAA13114@vbormc.vbo.dec.com> ---------------------Reply to mail dated 1-NOV-1996 19:21--------------------- Dimitry, I have RIPNg on our Digital routers. I will set it up tomorrow. You could try connecting to pax-6bone.pa-x.dec.com from you end. From Alain.Durand@imag.fr Mon Nov 4 18:09:39 1996 From: Alain.Durand@imag.fr (Alain Durand) Date: Mon, 4 Nov 1996 19:09:39 +0100 Subject: 2 new tunnels In-Reply-To: Bob Fink LBNL "6bone map change" (Nov 4, 8:11am) References: Message-ID: <961104190939.ZM16140@rama.imag.fr> There are 2 new tunnels: G6 <-> BAY and G6 <-> NRL My ripe database entry is updated. Here is the ping trace: BAY: ganesha# ping6 -c 5 5F02:3000:C020:AE00:201D:0000:C020:1D3E trying to get source for 5F02:3000:C020:AE00:201D:0000:C020:1D3E source should be 5f06:b500:8158:1a00:1:0:8158:1a01 PING 5F02:3000:C020:AE00:201D:0000:C020:1D3E (5f02:3000:c020:ae00:201d:0:c020:1d3e): 56 data bytes 64 bytes from 5f02:3000:c020:ae00:201d:0:c020:1d3e: icmp6_seq=0 ttl=60 time=499.989 ms 64 bytes from 5f02:3000:c020:ae00:201d:0:c020:1d3e: icmp6_seq=2 ttl=60 time=435.784 ms 64 bytes from 5f02:3000:c020:ae00:201d:0:c020:1d3e: icmp6_seq=3 ttl=60 time=479.540 ms 64 bytes from 5f02:3000:c020:ae00:201d:0:c020:1d3e: icmp6_seq=4 ttl=60 time=459.113 ms --- 5F02:3000:C020:AE00:201D:0000:C020:1D3E ping statistics --- 5 packets transmitted, 4 packets received, 20% packet loss round-trip min/avg/max = 435.784/468.606/499.989 ms NRL: ganesha# ping6 -c 5 5f00:3000:84fa:5a00:0000:0000:0000:0005 trying to get source for 5f00:3000:84fa:5a00:0000:0000:0000:0005 source should be 5f06:b500:8158:1a00:1:0:8158:1a01 PING 5f00:3000:84fa:5a00:0000:0000:0000:0005 (5f00:3000:84fa:5a00::5): 56 data bytes 64 bytes from 5f00:3000:84fa:5a00::5: icmp6_seq=0 ttl=255 time=284.635 ms 64 bytes from 5f00:3000:84fa:5a00::5: icmp6_seq=1 ttl=255 time=345.466 ms 64 bytes from 5f00:3000:84fa:5a00::5: icmp6_seq=2 ttl=255 time=321.975 ms 64 bytes from 5f00:3000:84fa:5a00::5: icmp6_seq=3 ttl=255 time=334.663 ms 64 bytes from 5f00:3000:84fa:5a00::5: icmp6_seq=4 ttl=255 time=345.428 ms --- 5f00:3000:84fa:5a00:0000:0000:0000:0005 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 284.635/326.433/345.466 ms - Alain. From Alain.Durand@imag.fr Mon Nov 4 18:59:02 1996 From: Alain.Durand@imag.fr (Alain Durand) Date: Mon, 4 Nov 1996 19:59:02 +0100 Subject: full routing table Message-ID: <961104195902.ZM17007@rama.imag.fr> 6bone-gw.ipv6.imag.fr is now carrying a full routing table. - Alain. From dhaskin@baynetworks.com Mon Nov 4 21:40:06 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Mon, 4 Nov 1996 16:40:06 -0500 Subject: new tunnels Message-ID: <199611042140.QAA24124@pobox.BayNetworks.com> Hi, I've update Bay's ripe database entry with new tunnels: 1) BAY <-> UNI-C ping -ip6 5f07:2b00:82e1:e700:5:c0:3302:31 -v 16 bytes from (5F07:2B00:82E1:E700:0005:00C0:3302:0031): icmp_seq=0, time= 410 ms ---- IPV6 PING Statistics---- IPV6 ping: [5F07:2B00:82E1:E700:0005:00C0:3302:0031] responded to 1 out of 1: 100% success. round-trip (ms) min/avg/max = 410/410/410 2) BAY <-> JOIN project ping -ip6 5f04:fb00:80b0::bf42:00c0:3302:0014 -v 16 bytes from (5F04:FB00:80B0:0000:BF42:00C0:3302:0014): icmp_seq=0, time= 273 ms --- IPV6 PING Statistics---- IPV6 ping: [5F04:FB00:80B0:0000:BF42:00C0:3302:0014] responded to 1 out of 1: 100% success. round-trip (ms) min/avg/max = 273/273/273 3) BAY <-> G6 ping -ip6 5f06:b500:8158:1a00:1:0:8158:1a01 -r5 -v 16 bytes from (5F06:B500:8158:1A00:0001:0000:8158:1A01): icmp_seq=0, time= 183 ms 16 bytes from (5F06:B500:8158:1A00:0001:0000:8158:1A01): icmp_seq=1, time= 175 ms 16 bytes from (5F06:B500:8158:1A00:0001:0000:8158:1A01): icmp_seq=2, time= 171 ms 16 bytes from (5F06:B500:8158:1A00:0001:0000:8158:1A01): icmp_seq=3, time= 1 ms 16 bytes from (5F06:B500:8158:1A00:0001:0000:8158:1A01): icmp_seq=4, time= 203 ms ---- IPV6 PING Statistics---- IPV6 ping: [5F06:B500:8158:1A00:0001:0000:8158:1A01] responded to 5 out of 5: 100% success. round-trip (ms) min/avg/max = 1/146/203 Dimitry From tonyhain@microsoft.com Mon Nov 4 22:56:56 1996 From: tonyhain@microsoft.com (Tony Hain) Date: Mon, 4 Nov 1996 14:56:56 -0800 Subject: Internet Draft Submission Message-ID: Quaizar, While I will be glad to make time for discussing this on the agenda in San Jose, I would like to warn you now that I think you are headed off course with this paper. It appears you are retracing some old ground and are trying to minimize the work to implement the software rather than the work to implement the network. A few specific issues: I don't see any place in draft-ietf-ipngwg-ipv6-tunnel-04.txt that talks about V6 over V4 tunnels. What it is defining are encapsulations over V6 tunnels. In fact you should be looking at RFC1701 for use of V4 as a tunnel media. Trying to prohibit a V4 compatible address from communicating with a V6 only address increases the complexity since the node with the V4 compatible address will have to have another V6 only address to talk to the desired destination. I don't see the distinction between your Class 1 & 2 end systems in terms of address usage. Any isolated node will need a V4 address to get across that media. If it does not build an RFC1701 tunnel to its next hop it will need a V4 compatible V6 address, otherwise any V6 address should work. Also, use of automatic tunnels does not imply that the entire Internet has to use V4 compatible addresses. Only the systems which wish to communicate with each other directly need this. What the automatic tunneling systems need is a configured default V6 router which will get them to non-V4 addressable destinations. Finally, manually configured tunnels will be an administrative reality for network management and diagnostics. Trying to push automatic tunneling into these environments will only delay the roll out of V6. Tony PS: I guess I have been disconnected from the NGTRANS mailer since I moved to Microsoft. I just assumed the list had gone dormant. If there are issues in the deployment that are restricting progress we should make sure they are talked about in San Jose. >---------- >From: qv@iol.unh.edu[SMTP:qv@iol.unh.edu] >Sent: Monday, November 04, 1996 12:57 PM >To: internet-drafts@ietf.org >Cc: Tony Hain; gilligan@free-gate.com; dan@lkg.dec.com; qv@sun4.iol.unh.edu >Subject: Internet Draft Submission > >Dear Editor, > We wish to submit an internet draft to the ngtrans working >group. Please forward all the correspondance to my e-mail address as >my co-author would be temporarily off the net. > >Thanks, >Quaizar > >Quaizar Vohra >Inter-Operatibility Lab. (IOL), Univ. of New Hampshire >E-mail : qv@sun4.iol.unh.edu >Phone : (603)-862-0090 > >---------------------------------------------------------------- >IPng Transition Dan Harrington >Internet Draft Digital Equipment Corp. > Quaizar Vohra > University of New Hampshire > November 1996 > > Limiting the role of IPv4-compatible Addresses in IPv6 > > draft-harrington-ngtrans-v4comp-00.txt > >Abstract > > This draft presents a proposal to limit IPv4-compatible IPv6 > addresses to tunnelling interfaces in the transition from IPv4 to > IPv6. The reasons and context for restricting the usage in this > manner will be presented. > >Status of This Memo > > This document is a submission to the NGtrans Working Group of the > Internet Engineering Task Force (IETF). Comments should be > submitted to the ngtrans@sunroof.end.sun.com mailing list. The > authors invite discussion and feedback on this topic. > > This document is an Internet-Draft. Internet-Drafts are working > documents of the Internet Engineering Task Force (IETF), its areas, > and its working groups. Note that other groups may also distribute > working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other documents > at any time. It is inappropriate to use Internet-Drafts as > reference material or to cite them other than as ``work in > progress.'' > > To learn the current status of any Internet-Draft, please check the > ``1id-abstracts.txt'' listing contained in the Internet-Drafts > Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), > munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or > ftp.isi.edu (US West Coast). > > Distribution of this document is unlimited. > > >Table Of Contents > > 1. Introduction 3 > 2. Architectural and Philosophical Issues 3 > 3. Isolated Hosts 4 > 3.1. Class 1 Isolated Nodes 4 > 3.2. Class 2 Isolated Nodes 4 > 4. Other Issues 5 > 4.1. Host Issues 5 > >Expires May 1997 [Page 1] > >Internet Draft IPv4-compatible Addresses November 1996 > > 4.2. Router Issues 5 > 5. Acknowledgements 6 > 6. References 6 > 7. Author's Addresses 6 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires May 1997 [Page 2] > >Internet Draft IPv4-compatible Addresses November 1996 > >1. Introduction > > IPv4-compatible addresses are designed to ease the transition of > IPv4 to IPv6, by utilizing the readily available IPv4 address space > and protocols to provide IPv6 connectivity. They currently serve > two roles, both related to tunnelling: > > - To allow isolated IPv6 nodes to come up on the Internet > and communicate with other IPv6 nodes via automatic tunneling, > which requires a minimal amount of configuration. > > - Identifying an IPv6 router's next-hop interface address over > a manually configured tunnel. > > These tasks both require implementations to treat an IPv4 tunnel as > a pseudo-NBMA link, where ::/96 is treated as an on-link IPv6 prefix > for the tunnel interface. In this model, all IPv4-compatible > addresses are on-link to the tunnel interface and the IPv4 Internet > forms one large link layer, in which address resolution is a trivial > function. Manually configured tunnels are used with static routes to > IPv6 prefixes, where the next-hop is an IPv4-compatible address on > the link. While this link type does not use the standard link-local > prefix of FE80:: or Neighbor Discovery protocols, it does have its > own characteristics and rules [V6TUNNELS]. Conceptually, then, it > can be seen that IPv6 packets using IPv4-compatible addresses could > be treated as using a special type of link-local address, and the > Hop Limit could be set to a value of 1 with no dire consequences. > > The current Transition Mechanisms specification [RFC1933], however, > also include a provision to allow an IPv4-compatible address to be > assigned to an interface for native IPv6 communications, with all > the requirements of Neighbor Discovery. It is this usage which we > wish to prohibit, for the sake of reduced complexity and increased > interoperability. > >2. Architectural and Philosophical Issues > > Although IPv4 and IPv6 represent different network protocols, IPv4 > addresses can be represented as IPv6 addresses. However, they still > define an IPv4 endpoint, that is, an interface on a link connected > to an IPv4 network, using IPv4 protocols. Using them in multiple > fashions, for both IPv4 and IPv6 packets on a given interface as > well as for tunnelling, can and will lead to interoperability > problems, as has been reported on the NGTRANS mailing list [NGLIST]. > This dual usage also leads to unnecessary implementation complexity; > for example, the source address selection algorithm should not > permit the use of an IPv4-compatible address (as source or > destination) with a global IPv6 address (as destination or source). > > As mentioned above, the encapsulation of IPv6 packets in IPv4 > packets essentially uses the IPv4 network as a specialized media > type. The "Generic Packet Tunneling in IPv6" [V6TUNNELS] > specification gives the mechanism by which one protocol may be run > over another. In keeping with the general IP philosophy of an > > >Expires May 1997 [Page 3] > >Internet Draft IPv4-compatible Addresses November 1996 > > address being associated with a particular interface [RFC1122], it > should be held that a tunnel interface is not merely an abstraction, > but a "real" interface to a specific media type, with its own rules > and behaviours. > > Finally, restricting the usage of IPv4-compatible addresses will > simplify the definition, implementation, and usage of this address > form, and smooth the IPv4 to IPv6 transition. Simple, clear > definitions are easy to explain; special cases and asterisks are > not. If IPv6 is to be widely accepted and deployed, the training > and educational aspects of the architecture must not be ignored. > >3. Isolated Hosts > > Two interpretations of the term "Isolated Host" have been proposed > in the course of discussing IPv4-compatible address usage. Both are > presented below, and hopefully these definitions can be clarified, > and consensus reached, through further discussion. > >3.1. Class 1 Isolated Nodes > > The first interpretation of an isolated host is a host which does > not have an on-link IPv6 router, and which thus must encapsulate all > packets to off-link destinations. But this node is connected to an > IPv6-capable Internet Service Provider (ISP) and thus has a provider > based IPv6 address [RFC1897][V6PROVIDER], which we will refer to as > PBA. This PBA is assigned to the tunnel interface and is used as > source address in outgoing packets. The node has a manually > configured tunnel to an ISP router. This PBA is based upon the ISP's > prefix and the IPV4 address of the IPv4 interface through which the > encapsulated packets get forwarded to the ISP. Note that the > IPv4-compatible might be usable as the link-local address in a > routing protocol, but this is yet to be determined. > > So this isolated node has global IPv6 connectivity via the ISP. This > isolated node has a default IPv6 route (::/0) with the ISP router as > next-hop, which may be identifed by an IPv4-compatible address. > Examples of this class of isolated node can be found on the current > 6-bone. [6BONE] > >3.2. Class 2 Isolated Nodes > > The second form of isolated nodes are those nodes which are not > connected to an IPv6-capable ISP, i.e. they don't have a PBA. All > they have is an IPv4-compatible address and they communicate with > other IPv6 nodes which have IPv4-compatible addresses using > end-to-end automatic tunneling. This requires that the destination > node also has an IPv4-compatible address, and implies that the > packet will make a single hop (i.e. the IPv6 packet will not be > forwarded). > > In the evolution of the 6bone, the second class of host is not > represented. It remains to be seen how common this type of host > will be as IPv6 is deployed commercially. For these nodes to > > >Expires May 1997 [Page 4] > >Internet Draft IPv4-compatible Addresses November 1996 > > communicate with other IPv6 nodes on the Internet, the remote IPv6 > system must have automatic tunneling enabled on every IPv6 node on > the Internet. At some point in transition, when the IPv4 address > space is exhausted, new IPv6 nodes will not be able to get > IPv4-compatible addresses to do automatic tunneling. These nodes > will only have PBAs and would not be able to communicate with class > 2 isolated nodes. So while this class of system represents a simple > configuration, it can be seen that from the beginning these nodes > may only be able to communicate with a subset of the IPv6 network, > and the percentage of unreachable hosts will likely increase over > time. Also, the extensive use of IPv4-compatible addresses for > communications between IPv6 systems will exercise the IPv4 routing > infrastructure, without promoting the use of IPv6 hierarchical > routing, thereby taxing an overburdened service without any gain in > operational experience in the new technology. > >4. Other Issues > > One important issue is whether IPv4-compatible addresses should be > assigned to all physical interfaces having IPv4 addresses. We > believe that this is not a good idea as it creates several problems > without being a solution for any existing problem. There are other > issues to consider as well. > > Another disadvantage is that IPv4-compatible addresses will have to > be treated specially in name services like DNS and DHCP, with > duplication of data and potential operational confusion resulting. > >4.1. Host Issues > > Hosts may have to deal with multiple mechanisms for obtaining > addresses, and support dual address lifetime (or lease) constructs. > While DHCP is commonly used to obtain IPv4 addresses, DHCPv6 does > not support the assignment of IPv4-compatible addresses, and thus > the server will not recognize such addresses as belonging to any > given client. [DHCPv6] > > Also, assigning an IPv4-compatible address to the interface on which > IPv4 is running may not be generally possible. For example, an IPv4 > host using SLIP could support an IPv6 implementation using > tunnelling, but not a native interface. There may be other examples > of media types which support one protocol but not the other. > >4.2. Router Issues > > In addition to the issues presented above, which focus largely on > the impact to IPv6 hosts, there are various concerns related to dual > IPv6/IPv4 routers. In the current RFC 1933 model, dual protocol > routers at the borders of IPv6 islands may be called upon to perform > routing of packets using IPv4-compatible source and destination > addresses. There are several reasons why this is not a good idea: > > - While encapsulation of IPv6 packets in IPv4 tunnels will be a > necessary function of dual IPv4/IPv6 routers, it would be best > > >Expires May 1997 [Page 5] > >Internet Draft IPv4-compatible Addresses November 1996 > > to reduce the need for this function by having the originating > host use automatic tunnelling. > > - The routers may have greater memory requirements than otherwise. > See the draft "IPv6 Routing Table Issues" [RJA] for details. > >5. Acknowledgements > > The authors wish to thank Pedro Roque, Jim Bound, Ran Atkinson, Bill > Lenharth and Matt Thomas for their input and consideration, as well > as the growing community of IPv6 developers. > >6. References > > [RFC1933] R. Gilligan, E. Nordmark, "Transition Mechanisms for > IPv6 Hosts and Routers", RFC 1933, April 1996. > > [V6TUNNELS] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6", > , Work in Progress, > October 1996. > > [RFC1122] R. Braden, "Requirements for Internet Hosts - Communication > Layers", RFC 1122, October 1989. > > [NGLIST] Interoperability problem described on ngtrans mailing > list, Wednesday March 13, 1996. > > [RFC1897] R. Hinden, "IPv6 Testing Address Allocation", RFC 1897, > January 1996. > > [V6PROVIDER] Y. Rekhter et al, "An IPv6 Provider-Based Unicast Address > Format", , > Work in Progress, March 1996. > > [6BONE] http://www-cnr.lbl.gov/6bone > > [DHCPv6] J. Bound, C. Perkins, "Dynamic Host Configuration Protocol > for IPv6 (DHCPv6)", , > Work in Progress, August 1996. > > [RJA] R. Atkinson, "IPv6 Routing Table Size Issues", > , Work in > Progress, October 1996. > >7. Author's Addresses > > > Dan Harrington > P.O. Box 81W > W. Townsend, MA > > Quaizar Vohra > Interoperability Lab > 7 Leavitt Lane > > >Expires May 1997 [Page 6] > >Internet Draft IPv4-compatible Addresses November 1996 > > University of New Hampshire > Durham, NH 03824 > qv@iol.unh.edu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Expires May 1997 [Page 7] > From RLFink@lbl.gov Tue Nov 5 17:54:29 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 5 Nov 1996 09:54:29 -0800 Subject: 6bone map change Message-ID: 6bone diagram version 33: New tunnel from BAY/US to JOIN/DE New tunnel from BAY/US to UNI-C/DK New tunnel from BAY/US to G6/FR New tunnel from NRL/US to G6/FR New site UCAM-T/UK with tunnels to UMAN/UK and IFB/UK Added existing tunnel from NRL/US to IFB/UK Welcome to Univ. of Cambridge, Trinity College! Thanks, Bob From stuart@pa.dec.com Tue Nov 5 19:19:28 1996 From: stuart@pa.dec.com (Stephen Stuart) Date: Tue, 05 Nov 96 11:19:28 -0800 Subject: IPV6 web servers Message-ID: <9611051919.AA28314@nsl-too.pa.dec.com> Three of Digital's Palo Alto web servers are now IPV6-capable. Point your IPV6-capable web browser at any of the following URLs for the IPV6 versions of: http://altavista.ipv6.digital.com/ AltaVista http://www.ipv6.digital.com/ Digital's corporate WWW server http://ftp.ipv6.digital.com/ Search gatekeeper.dec.com's archive If you have IPV6-specific problems with any of these services, please contact me rather than the official support folks. Stephen - ----- Stephen Stuart stuart@pa.dec.com Network Systems Laboratory Digital Equipment Corporation From RLFink@lbl.gov Wed Nov 6 02:06:44 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 5 Nov 1996 18:06:44 -0800 Subject: Tshirt site list as of 5 Nov 96 - NEED SANITY CHECK Message-ID: 6bone folk, The list below has the sites I know of to date for the back of the 6bone Tshirt. I've listed the G6 collaboration sites and would like to add other collaboration sites as well (JOIN, UNI-C, WIDE, others?) if someone can supply them. Also, I thought we were soon to get a site in Spain (ES) - anyone know? So please speak up now as I will turn the list over to my illustrator on =46riday the 8th. And get those new countries signed up and online now!! :-) Thanks, Bob PS: I will soon publish the list of orders to date so you can check and modify as needed...it's just not in the critical path yet and I've been busy :-) =3D=3D=3D=3D=3D=3D=3D=3D=3D AT COSY DE FAUERN JOGUNET JOIN TU-BS DK TELEBIT UNI-C ES XXX =46R EUDIL ENSTb G6 INRIA IMAG SB-ROSCOFF UPOITIER UREC USTRASBOURG JP KEK SUMITOMO WIDE KZ KIT NL RIPE-NCC PT UL SE ERA SICS SG NUS-IRDU UK IFB UCAM-T UCL UMAN US ATT BAY CAIRN CISCO DIGITAL ESNET FNAL FTP-SW INNER KOHALA LBNL MERIT NASA-GSFC NASA-NAS NETLAG NIST NRL PARC RUTGERS SUMITOMO SUN UCLA UNH UO USC-ISI WWU - From martin@mrrl.lut.ac.uk Wed Nov 6 17:01:36 1996 From: martin@mrrl.lut.ac.uk (Martin Hamilton) Date: Wed, 06 Nov 1996 17:01:36 +0000 Subject: Tshirt site list as of 5 Nov 96 - NEED SANITY CHECK In-Reply-To: Your message of "Tue, 05 Nov 1996 18:06:44 PST." Message-ID: <199611061701.RAA00466@gizmo.lut.ac.uk> Bob Fink LBNL writes: | So please speak up now as I will turn the list over to my illustrator on | Friday the 8th. Put us down for a couple of T-shirts if it's not too late! We've just started routing to the 6bone via IFB, and our prefix is (thinks...) 5f03:1200:9e7d:6000/64 | UK | IFB LUT :-) | UCAM-T | UCL | UMAN Cheerio, Martin From bound@zk3.dec.com Thu Nov 7 00:38:42 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 06 Nov 96 19:38:42 -0500 Subject: Internet Draft Submission In-Reply-To: Your message of "Mon, 04 Nov 96 14:56:56 PST." Message-ID: <9611070038.AA23319@wasted.zk3.dec.com> Hi Tony, I pretty much agree with your response. One part I do agree with in the draft is I don't see v4-compat addrs being used on the link but only with tunnels. Is NGTRANS the place to discuss taht or IPng WG? I think we should review Dimitry's draft for sure. Its looking much stronger. I would like to see more in the draft how the routes are actually discovered as this may be the place to discover tunnels and we could test it on the 6bone. We are meeting right? thanks /jim From RLFink@lbl.gov Thu Nov 7 02:14:31 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 6 Nov 1996 18:14:31 -0800 Subject: Tshirt site list as of 6 Nov 96 Message-ID: Current list of sites for the Tshirt follows. Think I've caught up with the requests for being on the Tshirt. Corrections/additions accepted as usual. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D AT COSY CH ETHZ DE DETEBERKOM FAUERN JOGUNET JOIN TU-BS DK TELEBIT UAALBORG UAARHUS UCOPENHAGEN ULYNGBY UNI-C UODENSE =46R EUDIL ENSTb G6 INRIA IMAG SB-ROSCOFF UPOITIER UREC USTRASBOURG JP IWANAMI KEK NARA SUMITOMO UTOKYO WIDE KZ KIT NL RIPE-NCC PT UL SE ERA KTH SICS SG NUS-IRDU UK IFB LUT TICL UCAM-T UCL UMAN US ATT BAY CAIRN CISCO DIGITAL ESNET FNAL FTP-SW IBM INNER KOHALA LBNL MERIT NASA-GSFC NASA-NAS NETGOD NETLAG NIST NRL PARC RUTGERS SUMITOMO SUN UCLA UNH UO USC-ISI WWU - From bound@zk3.dec.com Thu Nov 7 02:49:49 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 06 Nov 96 21:49:49 -0500 Subject: Internet Draft Submission In-Reply-To: Your message of "Wed, 06 Nov 96 18:25:16 PST." <3281488C.6854@freegate.net> Message-ID: <9611070249.AA09818@wasted.zk3.dec.com> Bob/Tony, Why don't you start a thread on ngtrans and we can all stop responding to this mail on IPng WG... /jim From bohm@it.kth.se Thu Nov 7 09:32:49 1996 From: bohm@it.kth.se (Christer Bohm) Date: Thu, 07 Nov 1996 10:32:49 +0100 Subject: IPv6 on ATM Message-ID: <199611070932.KAA03964@piraya.electrum.kth.se> Hi, I don't know if this is the right forum for this type of question. I wonder if anyone have expirience of IPv6 on top on ATM? We have MAN network (a part of the Stockhom Gigabit Network) manily consisting of Fore ATM switches and we would like to run IPv6 on it and connect it to the 6bone. Are there any implementations that could fit our purpose? Thanks in advance! /Christer - - Christer Bohm url: http://www.it.kth.se/~bohm e-mail: bohm@it.kth.se Royal Institute of Technology Dept. of Teleinformatics KTH-Electrum/204 phone: +46+8+752 1486 S-164 40 Stockholm,SWEDEN fax: +46+8+751 1793 From brandner@kar.dec.com Thu Nov 7 11:57:52 1996 From: brandner@kar.dec.com (Rudolf Brandner CEC Karlsruhe (+49-721-690231)) Date: Thu, 07 Nov 96 12:57:52 +0100 Subject: IPv6 on ATM In-Reply-To: Your message of Thu, 07 Nov 96 10:32:49 +0100. <199611070932.KAA03964@piraya.electrum.kth.se> Message-ID: <9611071157.AA17223@kaputt.kar.dec.com> Christer, there isn't any standard for IPv6/ATM yet and there are still problems to be solved (i.e. how to autoconfigure a node, how ND should work, etc). Nevertheless, you can tunnel IPv6 traffic using IPv4/ATM (what's probably not what you want to do). We did this already here in Germany between Berlin and Karlsruhe using the B-ISDN of the Deutsche Telekom. Worked very well. Rudolf Brandner CEC Karlsruhe, European Applied Research Center Digital Equipment Corporation email: brandner@kar.dec.com ---------- > > Hi, I don't know if this is the right forum for this type of question. I > wonder if anyone have expirience of IPv6 on top on ATM? We have MAN network (a > part of the Stockhom Gigabit Network) manily consisting of Fore ATM switches > and we would like to run IPv6 on it and connect it to the 6bone. Are there any > implementations that could fit our purpose? > > Thanks in advance! > > /Christer > - - > Christer Bohm url: http://www.it.kth.se/~bohm > e-mail: bohm@it.kth.se > Royal Institute of Technology Dept. of Teleinformatics > KTH-Electrum/204 phone: +46+8+752 1486 > S-164 40 Stockholm,SWEDEN fax: +46+8+751 1793 > From whchoi@cosmos.kaist.ac.kr Thu Nov 7 13:06:35 1996 From: whchoi@cosmos.kaist.ac.kr (Woohyong Choi) Date: Thu, 7 Nov 1996 22:06:35 +0900 (KST) Subject: Tunnel Request from KAIST to NRL Message-ID: <199611071306.WAA20896@cosmos> We're setting up an IPv6 cloud of two machines here in KAIST, Korea. One is a Sparc machine running NetBSD1.1(with INRIA IPv6 code), and the other is planned to run Solaris IPv6 soon. The IPv6 address for KAIST node is 6bone-gw.ipv6.kaist.ac.kr [TBD; DNS is not yet operational yet] 5f06:f500:8ff8:b900::0800:2007:4749 (5f06:f500:8ff8:b900::/64 prefix) 143.248.185.22 (AS1781) contact point - ipv6-ops@cosmos.kaist.ac.kr From the ping statistics from my local machine, I believe NRL will better serve as my parent for IPv6 tunnel. Ronald, could you please add a tunnel entry in your router and tell me RIPE IP6RR ftp group username/password? (132.250.90.5 143.248.185.22 KAIST) Thanks, -whchoi Cisco ----192.31.7.41 PING Statistics---- 137 packets transmitted, 109 packets received, 20% packet loss round-trip (ms) min/avg/max = 334/417/489 NRL ----132.250.90.5 PING Statistics---- 134 packets transmitted, 125 packets received, 6% packet loss round-trip (ms) min/avg/max = 458/549/725 From jcday@jpd.ch.man.ac.uk Thu Nov 7 14:33:57 1996 From: jcday@jpd.ch.man.ac.uk (Jonathan Day) Date: Thu, 7 Nov 1996 14:33:57 +0000 (GMT) Subject: UMAN entry change Message-ID: <199611071433.OAA18365@jpd.ch.man.ac.uk> Hi Just a quick note to say I've made a few corrections to the entry for UMAN - the tunnels to IFB and the University of Cambridge from my site are now correctly given. (ok, ok they're actually present now. :) Jonathan From rja@cisco.com Thu Nov 7 17:25:16 1996 From: rja@cisco.com (Ran Atkinson) Date: Thu, 7 Nov 1996 09:25:16 PST Subject: IPv6 on ATM In-Reply-To: Christer Bohm "IPv6 on ATM" (Nov 7, 10:32am) Message-ID: <199611071725.JAA22867@cornpuffs.cisco.com> There is not yet anything close to consensus within the IETF on how IPv6 should be used over ATM. There are at least two (possibly more) proposals on IPv6 over ATM (see draft-ion-* in the Internet Drafts archive near you for documents related to IPv4-IPv6/ATM). So, while it is possible that a prototype implementation exists, there is not yet any sort of interoperable standard for IPv6 over ATM. Best regards, Ran rja@cisco.com -- From Francis.Dupont@inria.fr Thu Nov 7 18:32:40 1996 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Thu, 07 Nov 1996 19:32:40 +0100 Subject: IPv6 on ATM In-Reply-To: Your message of Thu, 07 Nov 1996 10:32:49 +0100. <199611070932.KAA03964@piraya.electrum.kth.se> Message-ID: <199611071832.TAA29690@givry.inria.fr> In your previous mail you wrote: Hi, I don't know if this is the right forum for this type of question. I wonder if anyone have expirience of IPv6 on top on ATM? We have MAN network (a part of the Stockhom Gigabit Network) manily consisting of Fore ATM switches and we would like to run IPv6 on it and connect it to the 6bone. Are there any implementations that could fit our purpose? => if you need something today or tomorrow morning you can only use PVCs which solve all the resolution (ie address mapping) and QoS issues. It is less stupid than you can believe... But for other (:-) features you have to wait for a standard, for instance InARP is not yet defined for IPv6 (more an oversight than a real problem). Regards Francis.Dupont@inria.fr From bound@zk3.dec.com Thu Nov 7 20:19:06 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Thu, 07 Nov 96 15:19:06 -0500 Subject: IPv6 on ATM In-Reply-To: Your message of "Thu, 07 Nov 96 09:25:16 PST." <199611071725.JAA22867@cornpuffs.cisco.com> Message-ID: <9611072019.AA05795@wasted.zk3.dec.com> Christer, >There is not yet anything close to consensus within the IETF on how >IPv6 should be used over ATM. There are at least two (possibly >more) proposals on IPv6 over ATM (see draft-ion-* in the Internet >Drafts archive near you for documents related to IPv4-IPv6/ATM). This is not entirely the case. There was a debate and set of presentations on this at the June 1996 Montreal meeting. Three different proposals were on the table. One from Greenville Armitage, One from Schulter/Jork, and one from Atkinson, et al. The Atkinson et al proposed to use NHRP. Armitage wanted to use Multicast and a server strategy, and Schulter/Jork determined a scheme to treat ATM as any other link to IPv6. The consensus that was reached was that Armitage/Schulter/Jork will combine technologies and determine a course of action for ATM LANs and NHRP would only be used for cut-thu and over large clouds. This had consensus by the WG Chair and the ) community The details of these specs I assume will be presented at San Jose in the ION WG. The reason that the community did this is we do not want to have to rewrite our software for different links and many other reasons. Do a search on the ID Abstracts directory for "Schulter" "Amritage" "Atkinson" or "ION". You can use that as background. >So, while it is possible that a prototype implementation exists, there >is not yet any sort of interoperable standard for IPv6 over ATM. Its not just possible its in fact true. Rudi Brandner already responded to you and I think Francis Dupont may have one too. So Digital and INRIA do have prototypes. But I think until the specs get done doing more work is very sketchy. /jim From rja@cisco.com Thu Nov 7 21:32:44 1996 From: rja@cisco.com (Ran Atkinson) Date: Thu, 7 Nov 1996 13:32:44 PST Subject: IPv6 on ATM In-Reply-To: "Re: IPv6 on ATM" (Nov 7, 3:19pm) Message-ID: <199611072132.NAA27062@cornpuffs.cisco.com> Jim, I'll quote directly from the official online meeting minutes (see ftp://ftp.ietf.org/ietf/ion/ion-minutes-96jun.txt) : ---------------------------------------------------------------------- At this point, the chairs opened the floor for discussion of the three proposals presented. There were a number of clarification questions on the three presentations. Referring to draft-ietf-ion-ipv6atm-framework-00, Joel Halpern asked whether or not we really wanted two multicast mechanisms. Markus responded that a second mechanism wasn't necessary and that MARS could be used instead. After some discussion, the chairs asked each of the presenters what they believed the differences in the proposals were and what the best way forward would be. The general consensus was that the major difference was where to run NHRP (on the host or on the router). It was also urged that the solution to neighbor discovery should attempt to minimize the use of multicast/broadcast as the number of possible recipients could be quite large. There was agreement that a merged draft will be produced from the three proposals with a goal to have one server (MARS) instead of two. This draft is expected in advance of the next IETF meeting. ---------------------------------------------------------------------- Note that this does not indicate that ANY decision has been made on how to proceed and it explicitly notes that further discussion will occur at the San Jose IETF. Note also that co-locating the MARS server with the NHRP server ("...one server instead of two") has been the direction this working group has been moving in general (e.g. for IPv4 also) for sometime now. So my original comments to the 6bone list really are in fact correct and consistent with the official online WG minutes. :-) Best Regards, Ran rja@cisco.com -- From dhaskin@baynetworks.com Thu Nov 7 21:41:57 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Thu, 7 Nov 1996 16:41:57 -0500 Subject: IPv6 on ATM Message-ID: <199611072141.QAA03443@pobox.BayNetworks.com> Jim, > > This is not entirely the case. There was a debate and set of > presentations on this at the June 1996 Montreal meeting. Three > different proposals were on the table. One from Greenville Armitage, > One from Schulter/Jork, and one from Atkinson, et al. The Atkinson et > al proposed to use NHRP. Armitage wanted to use Multicast and a server > strategy, and Schulter/Jork determined a scheme to treat ATM as any > other link to IPv6. The consensus that was reached was that > Armitage/Schulter/Jork will combine technologies and determine a course > of action for ATM LANs and NHRP would only be used for cut-thu and over > large clouds. This had consensus by the WG Chair and the ) community > The details of these specs I assume will be presented at San Jose in the > ION WG. The reason that the community did this is we do not want to > have to rewrite our software for different links and many other reasons. > Do a search on the ID Abstracts directory for "Schulter" "Amritage" > "Atkinson" or "ION". You can use that as background. > This was not my reading of the "community consensus". As I remember it, the consensus was that Greenville and Peter should attempt to combine their proposal and then community will decide between remaining two. For one, both Greenville's and Peter's proposals are ATM centric and it would be a win if we define solution which works over all NBMA technologis as the Atkinson et al proposal does. Dimitry From bound@zk3.dec.com Thu Nov 7 22:08:09 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Thu, 07 Nov 96 17:08:09 -0500 Subject: IPv6 on ATM In-Reply-To: Your message of "Thu, 07 Nov 96 13:32:44 PST." <199611072132.NAA27062@cornpuffs.cisco.com> Message-ID: <9611072208.AA20790@wasted.zk3.dec.com> Ran, The minutes do not reflect the actual events that took place which I stated and are also correct. I will leave it that NHRP is not going to be used for the ATM LAN solution, but that the solution to be worked on will include the Schulter/Armitage work to be presented how they will coordinate their efforts. /jim From bound@zk3.dec.com Thu Nov 7 22:23:00 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Thu, 07 Nov 96 17:23:00 -0500 Subject: IPv6 on ATM In-Reply-To: Your message of "Thu, 07 Nov 96 16:41:57 EST." <199611072141.QAA03443@pobox.BayNetworks.com> Message-ID: <9611072223.AA22329@wasted.zk3.dec.com> Dimitry, >This was not my reading of the "community consensus". As I remember it, >the consensus was that Greenville and Peter should attempt to combine >their proposal and then community will decide between remaining two. >For one, both Greenville's and Peter's proposals are ATM centric and it >would be a win if we define solution which works over all NBMA technologis >as the Atkinson et al proposal does. No not quite what I heard and we can now go back and ask the chair and lots of people in the room at Montreal. The minutes were just a snapshot of about 1.25 hours and room full of consensus on the direction to be headed. The issue is that NHRP would cause ND and Autoconf to treat the ATM or NBMA link different than we treat Ethernet or FDDI as examples. This means that we all have to have extra or different code at the Internet Layer to do ND for NBMA. Peter has proposed a means that will not cause this result, and will work with Greenville to adapt his proposal to MARs and other parts in that draft. The bottom line is that the community did not want to tell grad students 10 years from now ND and Autoconf works this way on Ethernet and FDDI and this way on NBMA. And lots of us host vendors don't want to write the ) code two different ways either. NHRP lost a major battle at the Montreal meeting and in the community on the host (I am not speaking of the router). Denying that will only procrastinate a solution. The Atkinson proposal was deemed unacceptable was my reading and lots of other peoples for the link case. I heard the opposite from you that Schulter/Armitage will resolve that problem with a proposal to the ION group at San Jose. I know Peter and Greenville are working on this now no one from NHRP has attempted to work with them do determine where NHRP fits on the router. For the host we simply don't need it. /jim From dhaskin@baynetworks.com Thu Nov 7 22:49:59 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Thu, 7 Nov 1996 17:49:59 -0500 Subject: IPv6 on ATM Message-ID: <199611072249.RAA06740@pobox.BayNetworks.com> Jim > > I will leave it that NHRP is not going to > be used for the ATM LAN solution, but that the solution to be worked on > will include the Schulter/Armitage work to be presented how they will > coordinate their efforts. > > /jim > And what will we do for FR, X-25, etc.? Provide yet separate solutions?! :( Dimitry From stuart@pa.dec.com Thu Nov 7 23:58:00 1996 From: stuart@pa.dec.com (Stephen Stuart) Date: Thu, 07 Nov 96 15:58:00 -0800 Subject: New 6bone tunnel Message-ID: <9611072358.AA25986@nsl-too.pa.dec.com> Bob, I've updated the DIGITAL-CA entry at RIPE to show the new tunnel to Politecnico di Torino (POLITO). We exchange routing information with them via RIPng. Could you please update the map? % ping6 -c 10 ipv6gw-v4.polito.it PING ipv6gw-v4.polito.it (130.192.14.189): 56 data bytes 64 bytes from 130.192.14.189: icmp_seq=0 ttl=42 time=298 ms 64 bytes from 130.192.14.189: icmp_seq=1 ttl=42 time=275 ms 64 bytes from 130.192.14.189: icmp_seq=2 ttl=42 time=382 ms 64 bytes from 130.192.14.189: icmp_seq=3 ttl=42 time=412 ms 64 bytes from 130.192.14.189: icmp_seq=4 ttl=42 time=288 ms 64 bytes from 130.192.14.189: icmp_seq=5 ttl=42 time=303 ms 64 bytes from 130.192.14.189: icmp_seq=6 ttl=42 time=414 ms 64 bytes from 130.192.14.189: icmp_seq=7 ttl=42 time=450 ms 64 bytes from 130.192.14.189: icmp_seq=8 ttl=42 time=349 ms 64 bytes from 130.192.14.189: icmp_seq=9 ttl=42 time=323 ms ----ipv6gw-v4.polito.it PING Statistics---- 10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max = 275/349/450 ms Everyone, Will sites carrying full routing please add the appropriate routing table entries? Thanks to all, Stephen From rja@cisco.com Fri Nov 8 01:35:48 1996 From: rja@cisco.com (Ran Atkinson) Date: Thu, 7 Nov 1996 17:35:48 PST Subject: IPv6 on ATM In-Reply-To: "Re: IPv6 on ATM" (Nov 7, 5:23pm) Message-ID: <199611080135.RAA00966@cornpuffs.cisco.com> Jim, I'd suggest you have an issue for the ion mailing list and the ION WG chairs. However, the IETF works on the premise that the meeting minutes are both definitive and accurate. My understanding from the minutes and the chairs is the same as what Dimitry said. I'd also note that the 3rd proposal is largely the work of Dimitry Haskin and Jim Luciani, to give credit where due. I've not been contacted by Grenville or Peter at all, so its not the case that I'm ignoring anyone. Best Regards, Ran rja@cisco.com -- From jork@kar.dec.com Fri Nov 8 09:28:17 1996 From: jork@kar.dec.com (Markus Jork) Date: Fri, 08 Nov 96 10:28:17 +0100 Subject: IPv6 on ATM Message-ID: <9611080928.AA31822@sand2.kar.dec.com> Funny how everybody remembers the outcome of the last ION session in a different way. My memory corresponds with what Jim said. (And I attended the session until the end, unlike other participants in this discussion.) I must admit I am guilty of not having checked the meeting minutes so far. They necessarily can be only rough. But the sentence "There was agreement that a merged draft will be produced from the three proposals..." is not correct. The consensus was to merge the Armitage and Schulter/Jork/Harter proposals (which is also what Dimitry remembers). And my understanding is that that would be the basis for further work in the ION group. Markus From RLFink@lbl.gov Fri Nov 8 15:08:59 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 8 Nov 1996 07:08:59 -0800 Subject: Tshirt site list as of 8 Nov 96 0700 PDT Message-ID: Current list of sites for the Tshirt follows. Think I've caught up with all the requests for being on the Tshirt. I will close this list off as of 1700 PDT today. As an aside, this is now 16 countries, and over 75 sites. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D AT COSY CN ESYS CH ETHZ DE DETEBERKOM FAUERN JOGUNET JOIN TU-BS DK DENET UAALBORG UAARHUS UNI-C DTH UNI-C KBH UODENSE TELEBIT =46R G6 EUDIL ENSTB INRIA IMAG SB-ROSCOFF UPOITIER UREC USTRASBOURG IT POLITO JP KEK SUMITOMO WIDE HITACHI JAIST KEIOU NAIST NTT OSAKAU SONY SONY-CSL UTOKYO KR KAIST KZ KIT NL RIPE-NCC PT UL SE ERA KTH SICS SG NUS-IRDU UK IFB LUT TICL UCAM-T UCL UMAN US ATT BAY CAIRN CISCO DIGITAL ESNET FNAL FTP-SW IBM INNER KOHALA LBNL MERIT NASA-GSFC NASA-NAS NETGOD NETLAG NIST NRL PARC RUTGERS SCO SUMITOMO SUN UCLA UNH UO USC-ISI WWU - From RLFink@lbl.gov Fri Nov 8 15:42:15 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 8 Nov 1996 07:42:15 -0800 Subject: 6bone map change Message-ID: 6bone Diagram Version 34: New site KAIST/KR with tunnels to CISCO/US and NRL/US New site POLITO/IT with a tunnel to DIGITAL-CA/US Welcome to KAIST Korea and POLITO Italy! We are beoming very international :-) KAIST/KR needs a RIPE entry, but I chose not to wait for it as I will be out of town all next week. I will see email, but won't try any map updates till 18 Nov. Thanks, Bob ================== To: rlfink@lbl.gov Cc: Stephen Stuart , 6bone@isi.edu Subject: New 6bone tunnel Date: Thu, 07 Nov 96 15:58:00 -0800 From: Stephen Stuart X-Mts: smtp Bob, I've updated the DIGITAL-CA entry at RIPE to show the new tunnel to Politecnico di Torino (POLITO). We exchange routing information with them via RIPng. Could you please update the map? % ping6 -c 10 ipv6gw-v4.polito.it PING ipv6gw-v4.polito.it (130.192.14.189): 56 data bytes 64 bytes from 130.192.14.189: icmp_seq=0 ttl=42 time=298 ms 64 bytes from 130.192.14.189: icmp_seq=1 ttl=42 time=275 ms 64 bytes from 130.192.14.189: icmp_seq=2 ttl=42 time=382 ms 64 bytes from 130.192.14.189: icmp_seq=3 ttl=42 time=412 ms 64 bytes from 130.192.14.189: icmp_seq=4 ttl=42 time=288 ms 64 bytes from 130.192.14.189: icmp_seq=5 ttl=42 time=303 ms 64 bytes from 130.192.14.189: icmp_seq=6 ttl=42 time=414 ms 64 bytes from 130.192.14.189: icmp_seq=7 ttl=42 time=450 ms 64 bytes from 130.192.14.189: icmp_seq=8 ttl=42 time=349 ms 64 bytes from 130.192.14.189: icmp_seq=9 ttl=42 time=323 ms ----ipv6gw-v4.polito.it PING Statistics---- 10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max = 275/349/450 ms Everyone, Will sites carrying full routing please add the appropriate routing table entries? Thanks to all, Stephen =============================================== From: Woohyong Choi Subject: Tunnel Request from KAIST to NRL To: ronald.d.lee@nrl.navy.mil Date: Thu, 7 Nov 1996 22:06:35 +0900 (KST) Cc: 6bone@isi.edu Mime-Version: 1.0 Sender: owner-6bone@ISI.EDU Precedence: bulk We're setting up an IPv6 cloud of two machines here in KAIST, Korea. One is a Sparc machine running NetBSD1.1(with INRIA IPv6 code), and the other is planned to run Solaris IPv6 soon. The IPv6 address for KAIST node is 6bone-gw.ipv6.kaist.ac.kr [TBD; DNS is not yet operational yet] 5f06:f500:8ff8:b900::0800:2007:4749 (5f06:f500:8ff8:b900::/64 prefix) 143.248.185.22 (AS1781) contact point - ipv6-ops@cosmos.kaist.ac.kr From the ping statistics from my local machine, I believe NRL will Status: RO better serve as my parent for IPv6 tunnel. Ronald, could you please add a tunnel entry in your router and tell me RIPE IP6RR ftp group username/password? (132.250.90.5 143.248.185.22 KAIST) Thanks, -whchoi Cisco ----192.31.7.41 PING Statistics---- 137 packets transmitted, 109 packets received, 20% packet loss round-trip (ms) min/avg/max = 334/417/489 NRL ----132.250.90.5 PING Statistics---- 134 packets transmitted, 125 packets received, 6% packet loss round-trip (ms) min/avg/max = 458/549/725 === From RLFink@lbl.gov Fri Nov 8 20:01:32 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 8 Nov 1996 12:01:32 -0800 Subject: 6bone Tshirt ordering Message-ID: I have been asked several times about when to order, how to pay, etc. Many of you have already sent me size and qty (and sometimes mailing address) information. Early next week I will compile these orders into a list to play back so people know they have an order on record, and I will give a few days to adjust the orders. Meanwhile, those of you who have not sent an order yet should do so now. Just let me know qty and size and where to mail them if you won't be in San Jose to pick them up. I will only be able to take cash or checks (NO credit cards). I still expect the price to be $10 or less per Tshirt. Thanks, Bob From RLFink@lbl.gov Sat Nov 9 01:08:05 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 8 Nov 1996 17:08:05 -0800 Subject: Final 6bone Tshirt site/country list Message-ID: Final list of sites for the Tshirt follows. Thanks, Bob ========= AT COSY CA ESYS CH ETHZ DE DETEBERKOM FAUERN JOGUNET JOIN TU-BS DK DENET UAALBORG UAARHUS UNI-C DTH UNI-C KBH UODENSE TELEBIT FR G6 EUDIL ENSTB INRIA IMAG SB-ROSCOFF UPOITIER UREC USTRASBOURG IT POLITO JP KEK SUMITOMO WIDE HITACHI JAIST KEIOU NAIST NTT OSAKAU SONY SONY-CSL UTOKYO KR KAIST KZ KIT NL RIPE-NCC PT UL SE ERA KTH SICS SG NUS-IRDU UK IFB LUT TICL UCAM-T UCL UMAN US ATT BAY CAIRN CISCO DIGITAL ESNET FNAL FTP-SW IBM IBS-US INNER KOHALA LBNL MERIT NASA-GSFC NASA-NAS NETGOD NETLAG NIST NRL PARC RUTGERS SCO SUMITOMO SUN UCLA UNH UO USC-ISI WWU - From RLFink@lbl.gov Sat Nov 9 01:08:05 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 8 Nov 1996 17:08:05 -0800 Subject: Final 6bone Tshirt site/country list Message-ID: Final list of sites for the Tshirt follows. Thanks, Bob ========= AT COSY CA ESYS CH ETHZ DE DETEBERKOM FAUERN JOGUNET JOIN TU-BS DK DENET UAALBORG UAARHUS UNI-C DTH UNI-C KBH UODENSE TELEBIT FR G6 EUDIL ENSTB INRIA IMAG SB-ROSCOFF UPOITIER UREC USTRASBOURG IT POLITO JP KEK SUMITOMO WIDE HITACHI JAIST KEIOU NAIST NTT OSAKAU SONY SONY-CSL UTOKYO KR KAIST KZ KIT NL RIPE-NCC PT UL SE ERA KTH SICS SG NUS-IRDU UK IFB LUT TICL UCAM-T UCL UMAN US ATT BAY CAIRN CISCO DIGITAL ESNET FNAL FTP-SW IBM IBS-US INNER KOHALA LBNL MERIT NASA-GSFC NASA-NAS NETGOD NETLAG NIST NRL PARC RUTGERS SCO SUMITOMO SUN UCLA UNH UO USC-ISI WWU - From jim@interop.net Sat Nov 9 04:03:36 1996 From: jim@interop.net (Jim Martin) Date: Fri, 8 Nov 1996 20:03:36 -0800 (PST) Subject: Connection Request Message-ID: Folks, I'm looking for a 6Bone connection to Interop's testing and hotstaging facility in the San Francisco Bay area. We're currently hung off of Barrnet. The idea for us is to have a testbed to play with v6 interoperability before we try to do any real deployment in the InteropNet networks next year at the Interop shows. I'm running release 5 of the Solaris port on core.hstf.interop.net (199.45.11.20), and if I didn't blow any of my math, my RFC1897 testing address is 5f:00:fd:00:c7:2d:0b:00:2d:0b:08:00:20:19:d1:91. Anyone in a position to help me out? Thanks! Jim P.S. Any chance this will be in time to make the T-shirt? :) Jim Martin Internet: jim@interop.net Network Engineering Fax: (408) 541-4121 Softbank Expos Phone: (415) 372-6750 From itojun@csl.sony.co.jp Sat Nov 9 06:23:03 1996 From: itojun@csl.sony.co.jp (Jun-ichiro Itoh) Date: Sat, 09 Nov 1996 15:23:03 +0900 Subject: Tshirt site list as of 8 Nov 96 0700 PDT In-Reply-To: RLFink's message of Fri, 08 Nov 96 07:08:59 PST. Message-ID: <1831.847520583@itojun.csl.sony.co.jp> >Current list of sites for the Tshirt follows. Think I've caught up with all >the requests for being on the Tshirt. >I will close this list off as of 1700 PDT today. >As an aside, this is now 16 countries, and over 75 sites. >JP > WIDE > HITACHI > JAIST > KEIOU <- > NAIST > NTT > OSAKAU <- > SONY > SONY-CSL > UTOKYO <- I think they should be: KEIO OSAKA-U U-TOKYO Could you please change them for us? thanks, itojun, one of wide IPv6 team From stuart@pa.dec.com Sat Nov 9 08:25:38 1996 From: stuart@pa.dec.com (Stephen Stuart) Date: Sat, 09 Nov 96 00:25:38 -0800 Subject: Connection Request In-Reply-To: Your message of Fri, 08 Nov 96 20:03:36 -0800. Message-ID: <9611090825.AA03833@nsl-too.pa.dec.com> I added a static tunnel from Palo Alto to you (you didn't mention your prefix length, so I assumed 64; 5F00:FD00:C72D:0B00::0/64). If you'd prefer a RIPng tunnel, let me know. You should add a tunnel back to prefix 5f00:2100:cc7b:0000::/64 at IPv4 address 204.123.2.236 (feel free to point default at us as well). Ping altavista.ipv6.digital.com to test. Stephen - ----- Stephen Stuart stuart@pa.dec.com Network Systems Laboratory Digital Equipment Corporation From bound@zk3.dec.com Sat Nov 9 14:47:51 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Sat, 09 Nov 96 09:47:51 -0500 Subject: IPv6 on ATM In-Reply-To: Your message of "Thu, 07 Nov 96 17:49:59 EST." <199611072249.RAA06740@pobox.BayNetworks.com> Message-ID: <9611091447.AA10777@wasted.zk3.dec.com> Dimitry, >And what will we do for FR, X-25, etc.? Provide yet separate solutions?! :( I don't want that either. This will come up at ION but I don't have a problem with this discussion here it seems friendly and worthwhile. I just don't want: 1. NHRP for IPv6 address processing I want to use the mechanisms I have built for ND, Addrconf, DHCPv6. 2. The Internet Layer to change built for IPv6 as an abstraction. Now I believe that Armitage/Schulter/Harter/Jork can do the above and for all NBMA links. I also think they do not have an issue with cutthrough using NHRP off link. I am just speaking about a link OK. Not the cloud or communications between partitions. But I do think the folks above can build a link VPN with their approach and get multicast to work over NBMA too. /jim From RLFink@lbl.gov Sun Nov 10 05:20:46 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Sat, 9 Nov 1996 21:20:46 -0800 Subject: Final Final 6bone Tshirt site/country list :-) Message-ID: Made some WIDE/JP corrections and also added INTEROP as they just came up. Thanks, Bob ========= AT COSY CA ESYS CH ETHZ DE DETEBERKOM FAUERN JOGUNET JOIN TU-BS DK DENET UAALBORG UAARHUS UNI-C DTH UNI-C KBH UODENSE TELEBIT FR G6 EUDIL ENSTB INRIA IMAG SB-ROSCOFF UPOITIER UREC USTRASBOURG IT POLITO JP KEK SUMITOMO WIDE HITACHI JAIST KEIO NAIST NTT OSAKA-U SONY SONY-CSL U-TOKYO KR KAIST KZ KIT NL RIPE-NCC PT UL SE ERA KTH SICS SG NUS-IRDU UK IFB LUT TICL UCAM-T UCL UMAN US ATT BAY CAIRN CISCO DIGITAL ESNET FNAL FTP-SW IBM IBS-US INNER INTEROP KOHALA LBNL MERIT NASA-GSFC NASA-NAS NETGOD NETLAG NIST NRL PARC RUTGERS SCO SUMITOMO SUN UCLA UNH UO USC-ISI WWU - From ganis@VNET.IBM.COM Mon Nov 11 16:40:02 1996 From: ganis@VNET.IBM.COM (Matthew R. Ganis (914) 684-4575) Date: Mon, 11 Nov 96 11:40:02 EST Subject: multiple tunnels Message-ID: <199611111641.AA06595@venera.isi.edu> For those sites that have multiple tunnels up and running: how are you doing your routing ? For example, today I have a tunnel to NRL and I'm routing (by default) all of 5f00::/8 to them. But If I added another tunnel I'd need to change my routing (which is fine). Do I need to figure out my own static routes or can I run RIPng from the other end of my tunnels ? thanks, Matt. From wholscher@centuryinter.net Tue Nov 12 04:02:52 1996 From: wholscher@centuryinter.net (William J. Holscher) Date: Mon, 11 Nov 1996 20:02:52 -0800 Subject: becoming an island Message-ID: <3287F6EC.7635@centuryinter.net> I am currently managing a small ISP in Rockledge, Fl. The president of the company is interested in becoming an "island for ipv6". Could you send me the necessary info on how I might make this come about? Any help you could give me in this matter would be greatly appreciated. Thanks, Wm. Holscher Mngr. Computing & Communication Services, Inc. 640 Eyster Blvd. Rockledge, Fl. 32955 407-639-8100 voice 407-639-0224 fax wholsch@ccsmall.com From mdp@tbit.dk Tue Nov 12 12:47:29 1996 From: mdp@tbit.dk (Martin D. Peck) Date: Tue, 12 Nov 1996 13:47:29 +0100 Subject: multiple tunnels References: <199611111641.AA06595@venera.isi.edu> Message-ID: <328871E1.33B1@tbit.dk> Hi Matt, Matthew R. Ganis (914) 684-4575 wrote: > > For those sites that have multiple tunnels up and running: how are you > doing your routing ? For example, today I have a tunnel to NRL > and I'm routing (by default) all of 5f00::/8 to them. But If I added > another tunnel I'd need to change my routing (which is fine). > Do I need to figure out my own static routes or can I run RIPng from > the other end of my tunnels ? > thanks, > Matt. At present the 6Bone defaults to statically configured tunnels but the use of RIPv6 is beginning between those tunnels that support it. We are promoting the idea of using IDRP for IPv6 for exchanging routing information which has the advantage of offering more effective scaleability. The protocol is now running successfully on the 6Bone between UNI-C/JOIN/IFB/and TELEBIT (with NIST and others starting soon). The routing table snap-shot shown below, taken from UNI-C's operational IPv6 network shows some of the possible combinations for managing multiple tunnels. 5f00:3000::/32 cphUNH 10 Static path 5f02:3000::/32 cphUNH 10 Static path 5f04:fb00::/32 cpherla 5 IDRP 5f04:fb00:80b0:0:bf42:c0:3302:14/128 cpherla 1 Configured Peer 5f05:2000::/32 cphUNH 10 Static path 5f06:b500::/32 cphG6 10 Static path 5f06:b500:8158:1a00:1:0:8158:1a01/128 cphG6 1 Configured Peer 5f06:d500::/32 cphUNH 10 Static path 5f07:2b00:82e1:e700::/64 unveav6lan1 200 Configured Peer 5f09:c400::/32 cphWIDE 10 Static path 5f09:c400:a3dd:b00:0:0:c0e3:665f/128 cphWIDE 1 Configured Peer 5f0b:1700::/32 unicsics 10 Static path 5f0b:3700::/32 cpherla 55 IDRP-EXT 5f0c:bf00::/32 cphtelebit 5 IDRP 5f0c:bf00:c2b6:8700:fd:1111:1111:1111/12 cphtelebit 1 Configured Peer 5f0d:e900::/32 cphUNH 10 Static path Hope this helps, Martin TELEBIT COMMUNICATIONS A/S From RLFink@lbl.gov Tue Nov 12 15:51:19 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 12 Nov 1996 07:51:19 -0800 Subject: new tunnel JOIN<->TU-Berlin In-Reply-To: Message-ID: Guido, At 6:07 AM -0800 11/12/96, JOIN Project Team wrote: >Hello Bob, > >we have installed a new tunnel from JOIN-project to the Technical >University of Berlin (TU-Berlin). Will update the map next week when I'm back in town. As you probably know, you are already on the Tshirt. Thanks, Bob From mdp@tbit.dk Tue Nov 12 16:33:19 1996 From: mdp@tbit.dk (Martin D. Peck) Date: Tue, 12 Nov 1996 17:33:19 +0100 Subject: IPv6 on ATM References: <199611070932.KAA03964@piraya.electrum.kth.se> Message-ID: <3288A6CF.3485@tbit.dk> Christer, Telebit has been working on an IPv6 over ATM SVC implementation for UNI-C's IPv6 network following the Armitage style solution (draft_armitage_ion_tn_00.txt), which is now available as a Beta version. This implementation is aimed at gaining early development and testing experience in advance of a more formal consensus. Both Unicast and Multicast SVCs have been implemented. Multicast Neighbor Discovery over ATM has also been implemented using MARS according to the draft RFC. More generally, we have been running PVCs across the UNI-C network both transparently (ie native IPv6 without encapsulation) and using LLC+SNAP encapsulation as described in RFC 1483. I hope this helps, Martin TELEBIT COMMUNICATIONS A/S From jcday@jpd.ch.man.ac.uk Tue Nov 12 17:19:28 1996 From: jcday@jpd.ch.man.ac.uk (Jonathan Day) Date: Tue, 12 Nov 1996 17:19:28 +0000 (GMT) Subject: T-shirts, et al Message-ID: <199611121719.RAA11819@jpd.ch.man.ac.uk> Hi I'd like to put in a provisional order for a couple of the 6-bone T-Shirts. If there's someone in the UK who's going to be buying them, then I'll place the actual order through them. (The p&p is a little steep, otherwise, but that's not going to cause a problem if it proves necessary.) Jonathan From mdp@tbit.dk Tue Nov 12 16:33:19 1996 From: mdp@tbit.dk (Martin D. Peck) Date: Tue, 12 Nov 1996 17:33:19 +0100 Subject: IPv6 on ATM References: <199611070932.KAA03964@piraya.electrum.kth.se> Message-ID: <3288A6CF.3485@tbit.dk> Christer, Telebit has been working on an IPv6 over ATM SVC implementation for UNI-C's IPv6 network following the Armitage style solution (draft_armitage_ion_tn_00.txt), which is now available as a Beta version. This implementation is aimed at gaining early development and testing experience in advance of a more formal consensus. Both Unicast and Multicast SVCs have been implemented. Multicast Neighbor Discovery over ATM has also been implemented using MARS according to the draft RFC. More generally, we have been running PVCs across the UNI-C network both transparently (ie native IPv6 without encapsulation) and using LLC+SNAP encapsulation as described in RFC 1483. I hope this helps, Martin TELEBIT COMMUNICATIONS A/S From RLFink@lbl.gov Tue Nov 12 15:51:19 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 12 Nov 1996 07:51:19 -0800 Subject: new tunnel JOIN<->TU-Berlin In-Reply-To: Message-ID: Guido, At 6:07 AM -0800 11/12/96, JOIN Project Team wrote: >Hello Bob, > >we have installed a new tunnel from JOIN-project to the Technical >University of Berlin (TU-Berlin). Will update the map next week when I'm back in town. As you probably know, you are already on the Tshirt. Thanks, Bob From jcday@jpd.ch.man.ac.uk Tue Nov 12 17:19:28 1996 From: jcday@jpd.ch.man.ac.uk (Jonathan Day) Date: Tue, 12 Nov 1996 17:19:28 +0000 (GMT) Subject: T-shirts, et al Message-ID: <199611121719.RAA11819@jpd.ch.man.ac.uk> Hi I'd like to put in a provisional order for a couple of the 6-bone T-Shirts. If there's someone in the UK who's going to be buying them, then I'll place the actual order through them. (The p&p is a little steep, otherwise, but that's not going to cause a problem if it proves necessary.) Jonathan From Dransfield@mail.dec.com Wed Nov 13 00:53:20 1996 From: Dransfield@mail.dec.com (Mike Dransfield) Date: Wed, 13 Nov 1996 11:53:20 +1100 Subject: New site DIGITAL-AU Message-ID: Hi, I have a new site at Digital in Sydney, Australia with a tunnel to DIGITAL-CA operational. I have a nameserver running but am unsure how to get the reverse mapping delegated as I am connected via Telstra Internet (formerly AARNet) with a C-class ipv4 network. I have a web server running but not yet tested. details attached thanks, Mike Dransfield site: Digital Equipment Corporation Australia location: Sydney, Australia loc-string: 33 53 s 151 10 e 10m prefix: 5F04:C500:CB00:2C00::/80 ping: riogrande.ipv6.digital.com.au (5F04:C500:CB00:2C00::800:2B3A:5FE1:) tunnel: 203.0.44.12 204.123.2.236 DIGITAL-CA contact: mike@stl.dec.com status: operational remark: Digital UNIX IPv6 remark: IPV6 webserver http://www.ipv6.digital.com.au:81/ changed: mike@stl.dec.com 19961113 source: RIPE From martin@mrrl.lut.ac.uk Wed Nov 13 14:23:43 1996 From: martin@mrrl.lut.ac.uk (Martin Hamilton) Date: Wed, 13 Nov 1996 14:23:43 +0000 Subject: T-shirts, et al In-Reply-To: Your message of "Tue, 12 Nov 1996 17:19:28 GMT." <199611121719.RAA11819@jpd.ch.man.ac.uk> Message-ID: <199611131423.OAA16639@gizmo.lut.ac.uk> Jonathan Day writes: | I'd like to put in a provisional order for a couple of the 6-bone T-Shirts. | If there's someone in the UK who's going to be buying them, then I'll | place the actual order through them. (The p&p is a little steep, otherwise, | but that's not going to cause a problem if it proves necessary.) I'm going to be in San Jose, so I could pick a few up for UK people Cheerio, Martin From dhaskin@baynetworks.com Thu Nov 14 15:48:23 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Thu, 14 Nov 1996 10:48:23 -0500 Subject: new tunnels Message-ID: <199611141548.KAA28123@pobox.BayNetworks.com> Hi, I've update Bay's RIPE database entry with new tunnels: 1) BAY <-> WIDE, Static Routing qadams[1]>ping -ip6 5f09:c400:a3dd:0800::1 -v -r5 16 bytes from (5F09:C400:A3DD:0800::0001) via If 10: icmp_seq=0, time= 324 ms 16 bytes from (5F09:C400:A3DD:0800::0001) via If 10: icmp_seq=1, time= 324 ms 16 bytes from (5F09:C400:A3DD:0800::0001) via If 10: icmp_seq=2, time= 300 ms 16 bytes from (5F09:C400:A3DD:0800::0001) via If 10: icmp_seq=3, time= 328 ms 16 bytes from (5F09:C400:A3DD:0800::0001) via If 10: icmp_seq=4, time= 300 ms ---- IPV6 PING Statistics---- IPV6 ping: [5F09:C400:A3DD:0800::0001] responded to 5 out of 5: 100% success. round-trip (ms) min/avg/max = 300/315/328 2) BAY <-> SUMITOMO/JP, RIPng Routing qadams[1]>ping -ip6 5f09:c100:8599::5fec:44cc -r5 -v 16 bytes from (5F09:C100:8599::5FEC:44CC) via If 11: icmp_seq=0, time= 281 ms 16 bytes from (5F09:C100:8599::5FEC:44CC) via If 11: icmp_seq=1, time= 289 ms 16 bytes from (5F09:C100:8599::5FEC:44CC) via If 11: icmp_seq=2, time= 289 ms 16 bytes from (5F09:C100:8599::5FEC:44CC) via If 11: icmp_seq=3, time= 289 ms 16 bytes from (5F09:C100:8599::5FEC:44CC) via If 11: icmp_seq=4, time= 285 ms ---- IPV6 PING Statistics---- IPV6 ping: [5F09:C100:8599::5FEC:44CC] responded to 5 out of 5: 100% success. round-trip (ms) min/avg/max = 281/286/289 3) BAY <-> DIGITAL-CA, RIPng Routing qadams[1]>ping -ip6 5F00:2100:CC7B:0000:0012:0800:2BE4:B5CC -r5 -v 16 bytes from (5F00:2100:CC7B:0000:0012:0800:2BE4:B5CC) via If 7: icmp_seq=0, time= 171 ms 16 bytes from (5F00:2100:CC7B:0000:0012:0800:2BE4:B5CC) via If 7: icmp_seq=1, time= 144 ms 16 bytes from (5F00:2100:CC7B:0000:0012:0800:2BE4:B5CC) via If 7: icmp_seq=2, time= 464 ms 16 bytes from (5F00:2100:CC7B:0000:0012:0800:2BE4:B5CC) via If 7: icmp_seq=3, time= 160 ms 16 bytes from (5F00:2100:CC7B:0000:0012:0800:2BE4:B5CC) via If 7: icmp_seq=4, time= 144 ms ---- IPV6 PING Statistics---- IPV6 ping: [5F00:2100:CC7B:0000:0012:0800:2BE4:B5CC] responded to 5 out of 5: 100% success. round-trip (ms) min/avg/max = 144/216/464 Dimitry From ronlee@CS.NRL.NAVY.MIL Thu Nov 14 16:19:38 1996 From: ronlee@CS.NRL.NAVY.MIL (Ronald Lee) Date: Thu, 14 Nov 1996 11:19:38 -0500 (EST) Subject: New tunnel: NRL<->RADYN Message-ID: <9611141119.aa25412@CS.NRL.NAVY.MIL> A new tunnel was established with Radio Dynanics Corp (RADYN) in Silver Spring, Maryland (MD), USA and NRL. The site manager will be updating their RIPE entry, but here's the basics for full routing table sites and online status: ------------------------------------------------------------------------------- v4 tunnel endpoint: 128.8.126.86 Prefix: 5f00:1b00:8008:7e66::0/64 v6 tunnel endpoint: 5f00:1b00:8008:7e66::c090:25d5 ------------------------------------------------------------------------------- PING radyn-ping (5f00:1b00:8008:7e66::c090:25d5): 56 data bytes 64 bytes from 5f00:1b00:8008:7e66::c090:25d5: icmp_seq=0 ttl=255 time=64.138 ms 64 bytes from 5f00:1b00:8008:7e66::c090:25d5: icmp_seq=1 ttl=255 time=17.361 ms 64 bytes from 5f00:1b00:8008:7e66::c090:25d5: icmp_seq=2 ttl=255 time=16.516 ms --- radyn-ping ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 16.516/32.671/64.138 ms ------------------------------------------------------------------------------- Thanks, Ron Lee NRL From wmk@radyn.com Thu Nov 14 17:26:41 1996 From: wmk@radyn.com (William M. Kules) Date: Thu, 14 Nov 1996 12:26:41 -0500 Subject: New tunnel: NRL<->RADYN Message-ID: <199611141726.MAA16967@gauss.radyn.com> Ron Lee wrote: > A new tunnel was established with Radio Dynanics Corp (RADYN) in > Silver Spring, Maryland (MD), USA and NRL. > > > The site manager will be updating their RIPE entry, but here's the > basics for full routing table sites and online status: > > > ------------------------------------------------------------------------------- > v4 tunnel endpoint: 128.8.126.86 > Prefix: 5f00:1b00:8008:7e66::0/64 > v6 tunnel endpoint: 5f00:1b00:8008:7e66::c090:25d5 Sorry for the confusion. The tunnel goes to the University of Maryland, College Park, Computer Science Department. (I work for Radio Dynamics -- but I'll work on that one, too :-) ). Bill Kules From RLFink@lbl.gov Thu Nov 14 18:08:31 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 14 Nov 1996 10:08:31 -0800 Subject: 6bone Tshirt order list - must reply by cob 18 Nov 96 Message-ID: 6bone Folk: I have compiled the list of 6bone Tshirt orders below. The format is shown below, and I have inserted ? whenever in doubt of your intentions. My apologies if I have screwed up your name an previous info you have sent me. As there are now well over 250 Tshirts ordered, and I have to personally front this money, I really need exact verification of the quantities, sizes, how you will take delivery AND that you are really going to pay me. So please email me your info as formatted below to help me edit the list. Be clear if you are changing, deleting or adding a new line. Only send me your info...please don't repeat the whole list to me. I am now setting the price at $10 US as this will cover the multi-color setup and the variation in cost based on size. It will simply be easiest to charge all sizes the same. Mailing is free as you will receive your Tshirt(s) from my Lab with other educational material in the mailing. No choice here...you get printed material of my choice :-) If I'm to mail to you, please include your properly formatting mailing address (even if you think you have sent it before). Payment can be in cash or check made out to me (Robert L. Fink)...but PLEASE don't send it yet...I'll let you know when. I need to hear from you by 18th Nov (next Monday), close of business, to verify your orders. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D lname, fname tab qty size, more qty size tab "mail" to you or "ietf" pic= kup =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Asayesh, Hamid 10 XL, 35 L ietf Atkinson, Ran 2 L, 2 XL ietf Blundell, Phil 1 L mail Boroumand, Jarad 2 XL ietf Bound, Jim 3 ? ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L ? Clauberg, Axel 3 XL mail Clay, Mike 1 L, 1 XL mail Crawford, Matt 2 XL ietf Curran, Peter 2 L ietf Dalgeir, Gudrun 1 XL, 1 S, 5 XL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? Dupont, Francis 1 XXL ietf Durand, Alain 10 XL ietf Eklund, Peter 2 L ? =46ang, Hsin 1 XL ? =46ernstedt, Anders 25 L, 25 XL ? =46ield, Brian 1 XL mail =46ink, Bob 2 XL ietf Ganis, Matt 2 XL, 2 L ? Glenn, Robert 2 XL mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 2 XL, 2 M, 11 L ietf Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 3 XL ietf Hoag, Andrew ? ietf Juliano, Bryan 1 XL ? Kann, Jung 2 L ? King, Ray 2 ? mail Kirkpatrick, Ben 1 XL mail Labovitz, Craig 1 XL ? Lahey, Kevin 2 L ? Latzko Alex ? ietf Mankin, Allison ? ietf Martin, Jim 1 XL ietf Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail Meyer, David 1 XXL ? McCann, Jack 2 XL ? Michlmayr, Mike 2 XXL ? Nitzan, Becca 1 M ietf Narten, Tom 1 XL ietf Nerenberg Lyndon 6 XL ietf Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Quinch, Charlie 5 XXL ? Shand, Mike 1 XL mail Sjodin, Peter 2 XL ? Solensky, Frank 1 L ietf Spindler, Tom 2 XXL mail Steven, Rick 1 XL ? StPierre, Brad ? mail Stuart, Stephen 3 XL ? Templin, Fred 2 XXL ? Turner, Rob 1 XXL ? Vohra, Quaizar 3 XL, 1 L, 1 M ietf Weise, Bernd 5 XL, 2 XXL ietf Yamamoto, Kazuhiko 1 L ? Yoshida, Shin 1 L ietf -end From rja@cisco.com Thu Nov 14 18:30:33 1996 From: rja@cisco.com (Ran Atkinson) Date: Thu, 14 Nov 1996 10:30:33 PST Subject: cisco tunnel endpoint change Message-ID: <199611141830.KAA14188@cornpuffs.cisco.com> Because cisco's Engineering Computing Services group is rearranging the configuration of our experimental subnets, the tunnel endpoint for 6bone-router.cisco.com will be changing to 192.31.7.104 sometime this evening (US Pacific Standard Time; perhaps 8-10 hours from the time I write this). I apologise for the relatively short notice, but ECS did not give me lots of notice and I'm about to leave town on business travel. Folks with tunnels to 6bone-router.cisco.com should please rehome the cisco end of the tunnel accordingly at your convenience. I apologise to the rest of the 6bone for any temporary disruptions that this change might cause. Regards, Ran rja@cisco.com -- From stuart@pa.dec.com Thu Nov 14 19:21:41 1996 From: stuart@pa.dec.com (Stephen Stuart) Date: Thu, 14 Nov 96 11:21:41 -0800 Subject: New IPV6 tunnels from Palo Alto Message-ID: <9611141921.AA07521@nsl-too.pa.dec.com> The following tunnels have been added to DIGITAL-CA; Bob, could you please do that map thing [that you do so well :-)]? tunnel: 204.123.2.235 203.0.44.12 DIGITAL-AU DIGITAL-AU's prefix is 5F04:C500:CB00:2C00::/80, test address 5F04:C500:CB00:2C00::800:2B3A:5FE1. % ping6 -c 10 -q 5F04:C500:CB00:2C00::800:2B3A:5FE1 PING (5F04:C500:CB00:2C00::800:2B3A:5FE1): 56 data bytes ----5F04:C500:CB00:2C00::800:2B3A:5FE1 PING Statistics---- 10 packets transmitted, 9 packets received, 10% packet loss round-trip (ms) min/avg/max = 256/276/301 ms tunnel: 204.123.2.236 163.221.11.21 WIDE % ping6 -c 10 -q 5f09:c400:a3dd:b00::c0e3:665f PING (5f09:c400:a3dd:b00::c0e3:665f): 56 data bytes ----5f09:c400:a3dd:b00::c0e3:665f PING Statistics---- 10 packets transmitted, 9 packets received, 10% packet loss round-trip (ms) min/avg/max = 324/334/345 ms tunnel: 204.123.2.236 141.39.66.24 DETEBERKOM % ping6 -c 10 -q 5F04:FB00:8D27:4200:1:800:2B91:AF86 PING (5F04:FB00:8D27:4200:1:800:2B91:AF86): 56 data bytes ----5F04:FB00:8D27:4200:1:800:2B91:AF86 PING Statistics---- 10 packets transmitted, 9 packets received, 10% packet loss round-trip (ms) min/avg/max = 359/389/416 ms tunnel: 204.123.2.236 199.45.11.20 This one is Softbank Expositions, the people who do Interop trade shows. Their prefix is 5F00:FD00:C72D:0B00::0/64, test ping address is 5f00:fd00:c72d:0b00:2d0b:0800:2019:d191. % ping6 -c 10 -q 5f00:fd00:c72d:0b00:2d0b:0800:2019:d191 PING (5f00:fd00:c72d:0b00:2d0b:0800:2019:d191): 56 data bytes ----5f00:fd00:c72d:0b00:2d0b:0800:2019:d191 PING Statistics---- 10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max = 8/12/21 ms We also now exchange RIPng routing information with: BAY: % ping6 -c 10 -q 5F02:3000:C020:AE00::0001 PING (5F02:3000:C020:AE00::0001): 56 data bytes ----5F02:3000:C020:AE00::0001 PING Statistics---- 10 packets transmitted, 9 packets received, 10% packet loss round-trip (ms) min/avg/max = 249/305/436 ms CISCO: % ping6 -c 10 -q 5f00:6d00:c01f:0700:0001:0060:3e11:6770 PING (5f00:6d00:c01f:0700:0001:0060:3e11:6770): 56 data bytes ----5f00:6d00:c01f:0700:0001:0060:3e11:6770 PING Statistics---- 10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max = 5/6/12 ms We also supply RIPng routes to MERIT. Stephen From berndw@deteberkom.de Thu Nov 14 20:34:54 1996 From: berndw@deteberkom.de (Bernd Weise) Date: Thu, 14 Nov 96 20:34:54 MEZ Subject: New site DeTeBerkom-DE Message-ID: <199611141939.AA27336@venera.isi.edu> Hy, we connected our IPv6 test-site to the 6bone. Tunnels are operational to DIGITAL-CA, JOIN-DE and to TU-BERLIN-DE. Please be aware that this is a testbed, which can be rebooted sometimes. Following information has been stored on the RIPE server: site: DeTeBerkom GmbH location: Berlin, Germany loc-string: 52 28n 13 18e 50m prefix: 5F04:FB00:8D27:4200::/64 ping: 5F04:FB00:8D27:4200:1:800:2B91:AF86 (pioneer6.deteberkom.de) tunnel: 141.39.66.24 204.123.2.236 DIGITAL-CA/US tunnel: 141.39.66.24 128.176.191.66 JOIN/DE tunnel: 141.39.66.24 130.149.62.18 TU Berlin/DE tunnel-v4: pioneer4.deteberkom.de (141.39.66.24) contact: weise@deteberkom.de status: operational since 13-Nov-1996 remark: As this is an IPv6 testbed connectivity might be remark: lost rarely remark: The testbed consists of systems from remark: Digital remark: HP remark: IBM remark: SUN remark: Running implementations are from remark: SICS, Digital, IBM and SUN remark: New tunnels added, RIP or static; send mail to contact changed: Bernd Weise 19961114 source: RIPE Bernd i===========================================================================i i Bernd Weise, DeTeBerkom GmbH, Voltastrasse 5, D-13355 Berlin i i Tel. +49 - 30 - 46701-143, Fax. +49 - 30 - 46701-445 i i i i NEW ADDRESS from 1. December 1996: i i DeTeBerkom GmbH, Goslarer Ufer 35,10589 Berlin i i Tel: +49 - 30 - 3497-3112, Fax: -3113 i i i i Internet: weise@deteberkom.de i i===========================================================================i From ronlee@CS.NRL.NAVY.MIL Thu Nov 14 21:39:19 1996 From: ronlee@CS.NRL.NAVY.MIL (Ronald Lee) Date: Thu, 14 Nov 1996 16:39:19 -0500 (EST) Subject: New tunnel: NRL<->RADYN In-Reply-To: <199611141726.MAA16967@gauss.radyn.com> from "William M. Kules" at Nov 14, 96 12:26:41 pm Message-ID: <9611141639.aa25806@CS.NRL.NAVY.MIL> > > v4 tunnel endpoint: 128.8.126.86 > > Prefix: 5f00:1b00:8008:7e66::0/64 > > v6 tunnel endpoint: 5f00:1b00:8008:7e66::c090:25d5 > > Sorry for the confusion. The tunnel goes to the University of > Maryland, College Park, Computer Science Department. (I work > for Radio Dynamics -- but I'll work on that one, too :-) ). > > Bill Kules My bad, a bit of miscommunication. Please change references to RADYN to UMCP-CS Thus, NRL is supporting this tunnel: NRL <-> UMCP-CS Ron From jcallaha@willamette.edu Fri Nov 15 01:29:49 1996 From: jcallaha@willamette.edu (John Callahan) Date: Thu, 14 Nov 1996 17:29:49 -0800 (PST) Subject: Request for Tunnel -- Western Washington U? Message-ID: Hi 6bone folks! We would like to join the 6bone. My guess is the best tunnel would be Western Washington University (WWU), since we're 10 hops on the same ASN, but maybe someone else knows better? Its unclear to me at which stage in the game we register with RIPE, but the pertinent information is: site: willamette location: Willamette University, Salem, OR, USA loc-string: 44 56 35n 123 2 2w 1m prefix: 5f02:ad00:9e68::/64 ping: 5f02:ad00:9e68::e8a1:e17a tunnel: 158.104.3.35 140.160.166.22 wwu contact: John Callahan status: planned changed: jcallaha@willamette.edu 961114 source: RIPE Thanks! John -- John Callahan |Assistant Director, Network Services Willamette Integrated Technology Services|Willamette University, Salem, OR, USA Phone: (503) 375-5495 Fax: (503) 375-5456|http://www.willamette.edu/~jcallaha From scott-6bone@laird.com Fri Nov 15 05:44:15 1996 From: scott-6bone@laird.com (Scott Laird) Date: Thu, 14 Nov 1996 21:44:15 -0800 Subject: New IPv6 tunnels from WWU to WILLAMETTE and NETGOD Message-ID: <199611150544.AA23356@venera.isi.edu> I've just added a tunnel from 140.160.166.22 to 158.104.3.35 for WILLAMETTE. Their prefix is 5f02:ad00:9e68::/64. $ ping6 -c 5 5f02:ad00:9e68::e8a1:e17a PING 5f02:ad00:9e68::e8a1:e17a: 56 data bytes 64 bytes from 5f02:ad00:9e68::e8a1:e17a: icmp_seq=0 time=24.9 ms 64 bytes from 5f02:ad00:9e68::e8a1:e17a: icmp_seq=1 time=20.6 ms 64 bytes from 5f02:ad00:9e68::e8a1:e17a: icmp_seq=2 time=25.1 ms 64 bytes from 5f02:ad00:9e68::e8a1:e17a: icmp_seq=3 time=26.0 ms 64 bytes from 5f02:ad00:9e68::e8a1:e17a: icmp_seq=4 time=33.8 ms --- 5f02:ad00:9e68::e8a1:e17a ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 20.6/26.0/33.8 ms We also have a tunnel to netgod.org, from 140.160.166.23 to 206.129.65.250, prefix 5f11:b600:ce81:4100::/64: $ ping6 -c 5 5F11:B600:CE81:4100::0020:AF9E:4703 PING 5F11:B600:CE81:4100::0020:AF9E:4703: 56 data bytes 64 bytes from 5f11:b600:ce81:4100:0:20:af9e:4703: icmp_seq=0 time=53.3 ms 64 bytes from 5f11:b600:ce81:4100:0:20:af9e:4703: icmp_seq=1 time=21.5 ms 64 bytes from 5f11:b600:ce81:4100:0:20:af9e:4703: icmp_seq=2 time=59.7 ms 64 bytes from 5f11:b600:ce81:4100:0:20:af9e:4703: icmp_seq=3 time=36.4 ms 64 bytes from 5f11:b600:ce81:4100:0:20:af9e:4703: icmp_seq=4 time=31.9 ms --- 5F11:B600:CE81:4100::0020:AF9E:4703 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 21.5/40.5/59.7 ms Both tunnels are listed with RIPE. Scott Laird From simon@switch.ch Fri Nov 15 09:42:00 1996 From: simon@switch.ch (Simon Leinen) Date: Fri, 15 Nov 1996 10:42:00 +0100 (MET) Subject: request for connection information Message-ID: <199611150942.KAA01233@celeste.switch.ch> [resent with corrected IPv6 address prefix- sorry.] We would like to connect to the 6bone. SWITCH is a network provider for the educational and research community in Switzerland, and some of our members have expressed interest in an infrastructure for IPv6 experimentation. Our autonomous system is #559, so the prefix in question would be 5f02:2f00::/32 . Could you suggest a convenient 6bone "POP" in our region? Currently we have better connectivity to Scandinavia than to our neighbor countries, although next year the connections to most other European countries should improve with the deployment of TEN-34. Do you think it is realistic to use a Sun SPARCstation running Sun's IPv6 implementation as a router to connect other organizations to the 6bone? -- Simon. From simon@switch.ch Fri Nov 15 09:37:48 1996 From: simon@switch.ch (Simon Leinen) Date: Fri, 15 Nov 1996 10:37:48 +0100 (MET) Subject: request for connection information Message-ID: <199611150937.KAA01184@celeste.switch.ch> We would like to connect to the 6bone. SWITCH is a network provider for the educational and research community in Switzerland, and some of our members have expressed interest in an infrastructure for IPv6 experimentation. Our autonomous system is #559, so the prefix in question would be 5f02:b200::/32 . Could you suggest a convenient 6bone "POP" in our region? Currently we have better connectivity to Scandinavia than to our neighbor countries, although next year the connections to most other European countries should improve with the deployment of TEN-34. Do you think it is realistic to use a Sun SPARCstation running Sun's IPv6 implementation as a router to connect other organizations to the 6bone? -- Simon. From Ivano.Guardini@cselt.stet.it Fri Nov 15 14:29:37 1996 From: Ivano.Guardini@cselt.stet.it (Guardini Ivano) Date: Fri, 15 Nov 1996 15:29:37 +0100 Subject: CSELT would like to join the 6Bone Message-ID: Hello, my name is Ivano Guardini. I'm a researcher from CSELT (Centro Studi e Laboratori Telecomunicazioni). CSELT is located in Torino (Italy). It is the STET Group's Company for the study, research, experimentation and qualification for telecomunications and information technology. My working group is creating an IPv6 test-bed network within CSELT. Our hosts are workstations and PCs. On the workstations we installed Sun IPv6 code for Solaris 2.5. On the PCs we installed NRL IPv6 code for NetBSD 1.2, INRIA IPv6 code for FreeBSD 2.1.5 and IPv6 code for Linux. One of the workstation acts as router. We would like to join the 6bone. What is the most appropriate attachment point for us? I will be waiting a reply from you as soon as possible. Thank you. By Ivano --------------------------------------------------- Ivano Guardini CSELT SpA via G. Reiss Romoli 274 Torino (Italy) Tel. +39 11 228 5424 Fax. +39 11 228 5069 --------------------------------------------------- From pcurran@ticl.co.uk Sat Nov 16 00:31:57 1996 From: pcurran@ticl.co.uk (Peter Curran) Date: Sat, 16 Nov 1996 00:31:57 -0000 Subject: IPv6 for FreeBSD 2.1.5 Message-ID: <199611160025.AAA01091@gate.ticl.co.uk> Does anyone know if there is a port of the INRIA (or any other) IPv6 code for FreeBSD 2.1.5R. I can only seem to find a version for 2.1.0. Many thanks Peter Curran TICL From Francis.Dupont@inria.fr Sat Nov 16 14:41:06 1996 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Sat, 16 Nov 1996 15:41:06 +0100 Subject: IPv6 for FreeBSD 2.1.5 In-Reply-To: Your message of Sat, 16 Nov 1996 00:31:57 GMT. <199611160025.AAA01091@gate.ticl.co.uk> Message-ID: <199611161441.PAA06943@givry.inria.fr> In your previous mail you wrote: Does anyone know if there is a port of the INRIA (or any other) IPv6 code for FreeBSD 2.1.5R. I can only seem to find a version for 2.1.0. => I have ported my implementation to NetBSD 1.2 and FreeBSD 2.1.5 but the next release (based on these OSs) is scheduled only for the end of this month. Francis.Dupont@inria.fr From RLFink@lbl.gov Tue Nov 19 17:33:14 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 09:33:14 -0800 Subject: Tshirt order list 19Nov96 0930 Message-ID: This is my Tshirt list as of Tuesday morning. I'll continue to take orders up until I need to give them to the Tshirt printer (Wed. sometime I think). This is 293 Tshirts so far! Gee, is someone reselling these things :-) I will probably order a bunch extra XL as it is the largest group (170 of 293), and am sure there will be demand at the IETF. Also wouldn't be surprised if I need to order more after the IETF. Thanks, Bob =============================================== Acheson, Steve 1 XL mail Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Edmondson, Dave 9 XL ietf (Andrew Malcolm) Eklund, Thomas 10 XL ietf Fang, Hsin 1 XL ietf Fernstedt, Anders 25 L, 25 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail (need address) Jaeger, Kurt 5 XL, 1 XXL mail Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf King, Ray 4 L mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Meier, Erich 2 XL mail Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Nerenberg, Lyndon 6 XL ietf Onoe, Atsushi 1 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Templin, Fred 1 XL, 2 XXL ietf Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Zhang, Lixia 1 M ietf From davidk@isi.edu Tue Nov 19 19:43:30 1996 From: davidk@isi.edu (davidk@isi.edu) Date: Tue, 19 Nov 1996 11:43:30 -0800 (PST) Subject: RIPE object proposal Message-ID: <9611191943.AA10337@brind.isi.edu> Hi all, Here is the long awaited proposal for the RIPE IPv6 object. The proposal is not formatted in any form yet. Please take look. Any comments and better ideas are welcome! Note that I am very busy right now with some IETF related topics that might cause some delay in my E-mail responses. David K. --- Title: A proposal for a RIPE database IPv6 site object Date: 961119 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 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. Formal RIPE database template: ipv6-site: [mandatory] [single] descr: [mandatory] [multiple] loc-string: [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] 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 - loc-string: LocationString contains the coordinates of the IPv6 sites location. Multiple location strings can be proovided on different lines for sites that have multiple locations in the area. Syntax: Somebody can give me a pointer for the RFC standard Example (for now): loc-string: 33 40 10n 117 49 20w 10m - prefix: IPv6Prefix is a prefix that is used within the the IPv6 site. Syntax: Example: prefix: 5f0d:0500:c100::/6 - application: [port] This attribute describes the different services available on the site. The services are the same as described in the '/etc/services' plus the ping application. More services might be added later on. Hostname is the DNS hostname of the host that provides the service and a port number may be specified for services that don't run on the standard port. Syntax: /^[\w\-]\s+[a-bA-Z\-]+(\.[a-bA-B\-])*\s+\d+$/ 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. Currently (only) the following type of tunnels are accepted: tunnel: IPv6 in IPv4 IPv4SourceAddress -> IPv4DestinationAddress [FreeText] It is expected that more possibilities will be added later. Note for discussion: It is may be better to use DNS domain names here instead of the raw IP addresses. Example: tunnel: IPv6 in IPv4 128.176.191.66 -> 130.225.231.5 IDRPv6 - contact: This is the contact information of the site. You may decide to either use a valid RFC822 E-mail address or to put in a reference to a valid NIC handle. Examples: contact: David Kessens or contact: DK13-RIPE - 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 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 From RLFink@lbl.gov Tue Nov 19 23:04:00 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 15:04:00 -0800 Subject: Tshirt order list 19Nov96 1500 Message-ID: At this stage, to avoid further confusion, I've moved all those not confirmed from the first list to this one, and notated it. However, confirmed or not, I will honor them as there is such a high confirmed response. Way over 300 Tshirts! I'm still open for orders and will queue what comes in after my cutoff for a 2nd run later on. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL mail (need address) Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Boroumand, Jarad 2 XL ietf (not confirmed) Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L ? (not confirmed) Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Curran, Peter 2 L ietf Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? (not confirmed) de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf (not confirmed) Durand, Alain 10 XL ietf (not confirmed) Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf =46ang, Hsin 1 XL ietf =46ernstedt, Anders 25 L, 25 XL ietf =46ield, Brian 1 XL mail (not confirmed) =46ink, Bob 2 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail (need address) Jaeger, Kurt 5 XL, 1 XXL mail Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf (not confirmed) McCann, Jack 2 XL ? (not confirmed) Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail (not confirmed) Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf (not confirmed) Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Onoe, Atsushi 1 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf Solensky, Frank 1 L ietf (not confirmed) Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Turner, Rob 1 XXL ? (not confirmed) Vohra, Quaizar 3 XL, 1 L, 1 M ietf (not confirmed) Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf (not confirmed) Zhang, Lixia 1 M ietf -end From RLFink@lbl.gov Tue Nov 19 23:04:00 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 15:04:00 -0800 Subject: Tshirt order list 19Nov96 1500 Message-ID: At this stage, to avoid further confusion, I've moved all those not confirmed from the first list to this one, and notated it. However, confirmed or not, I will honor them as there is such a high confirmed response. Way over 300 Tshirts! I'm still open for orders and will queue what comes in after my cutoff for a 2nd run later on. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL mail (need address) Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Boroumand, Jarad 2 XL ietf (not confirmed) Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L ? (not confirmed) Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Curran, Peter 2 L ietf Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? (not confirmed) de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf (not confirmed) Durand, Alain 10 XL ietf (not confirmed) Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf =46ang, Hsin 1 XL ietf =46ernstedt, Anders 25 L, 25 XL ietf =46ield, Brian 1 XL mail (not confirmed) =46ink, Bob 2 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail (need address) Jaeger, Kurt 5 XL, 1 XXL mail Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf (not confirmed) McCann, Jack 2 XL ? (not confirmed) Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail (not confirmed) Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf (not confirmed) Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Onoe, Atsushi 1 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf Solensky, Frank 1 L ietf (not confirmed) Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Turner, Rob 1 XXL ? (not confirmed) Vohra, Quaizar 3 XL, 1 L, 1 M ietf (not confirmed) Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf (not confirmed) Zhang, Lixia 1 M ietf -end From RLFink@lbl.gov Tue Nov 19 23:04:00 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 15:04:00 -0800 Subject: Tshirt order list 19Nov96 1500 Message-ID: At this stage, to avoid further confusion, I've moved all those not confirmed from the first list to this one, and notated it. However, confirmed or not, I will honor them as there is such a high confirmed response. Way over 300 Tshirts! I'm still open for orders and will queue what comes in after my cutoff for a 2nd run later on. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL mail (need address) Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Boroumand, Jarad 2 XL ietf (not confirmed) Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L ? (not confirmed) Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Curran, Peter 2 L ietf Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? (not confirmed) de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf (not confirmed) Durand, Alain 10 XL ietf (not confirmed) Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf =46ang, Hsin 1 XL ietf =46ernstedt, Anders 25 L, 25 XL ietf =46ield, Brian 1 XL mail (not confirmed) =46ink, Bob 2 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail (need address) Jaeger, Kurt 5 XL, 1 XXL mail Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf (not confirmed) McCann, Jack 2 XL ? (not confirmed) Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail (not confirmed) Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf (not confirmed) Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Onoe, Atsushi 1 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf Solensky, Frank 1 L ietf (not confirmed) Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Turner, Rob 1 XXL ? (not confirmed) Vohra, Quaizar 3 XL, 1 L, 1 M ietf (not confirmed) Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf (not confirmed) Zhang, Lixia 1 M ietf -end From RLFink@lbl.gov Wed Nov 20 00:56:53 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 16:56:53 -0800 Subject: 6bone map change and COLORFUL ADDITIONS :-) Message-ID: 6bone diagram version 35: Many changes - may miss a few on the list below remove extraneous KAIST - CISCO link add TU-Berlin/DE and DETERBERKOM/DE and respective links add DIGITAL-AU/AU with a link to DIGITAL-CA/US add WILLAMETTE/US with a link to WWU/US add new link from SUMITOMO/JP to BAY/US add new links from DIGITAL-CA/US to DETERBERKOM/DE, WIDE/JP & BAY/US Apologies if I screwed something up...just let me know. ALSO - NOT TO START A WAR, A COLORFUL CHANGE I've colorized the nodes, and made a first attempt at identifying transit nodes to eventually help in routing, planning, redoing the map, etc. If I've offended your site, my apologies...just let me know. If I was wrong in doing this, I'll change/remove or whatever is appropriate. Comments to the mailer, please :-) Thanks, Bob From RLFink@lbl.gov Tue Nov 19 23:04:00 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 15:04:00 -0800 Subject: Tshirt order list 19Nov96 1500 Message-ID: At this stage, to avoid further confusion, I've moved all those not confirmed from the first list to this one, and notated it. However, confirmed or not, I will honor them as there is such a high confirmed response. Way over 300 Tshirts! I'm still open for orders and will queue what comes in after my cutoff for a 2nd run later on. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL mail (need address) Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Boroumand, Jarad 2 XL ietf (not confirmed) Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L ? (not confirmed) Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Curran, Peter 2 L ietf Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? (not confirmed) de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf (not confirmed) Durand, Alain 10 XL ietf (not confirmed) Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf =46ang, Hsin 1 XL ietf =46ernstedt, Anders 25 L, 25 XL ietf =46ield, Brian 1 XL mail (not confirmed) =46ink, Bob 2 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail (need address) Jaeger, Kurt 5 XL, 1 XXL mail Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf (not confirmed) McCann, Jack 2 XL ? (not confirmed) Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail (not confirmed) Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf (not confirmed) Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Onoe, Atsushi 1 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf Solensky, Frank 1 L ietf (not confirmed) Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Turner, Rob 1 XXL ? (not confirmed) Vohra, Quaizar 3 XL, 1 L, 1 M ietf (not confirmed) Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf (not confirmed) Zhang, Lixia 1 M ietf -end From RLFink@lbl.gov Tue Nov 19 23:04:00 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 15:04:00 -0800 Subject: Tshirt order list 19Nov96 1500 Message-ID: At this stage, to avoid further confusion, I've moved all those not confirmed from the first list to this one, and notated it. However, confirmed or not, I will honor them as there is such a high confirmed response. Way over 300 Tshirts! I'm still open for orders and will queue what comes in after my cutoff for a 2nd run later on. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL mail (need address) Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Boroumand, Jarad 2 XL ietf (not confirmed) Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L ? (not confirmed) Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Curran, Peter 2 L ietf Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? (not confirmed) de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf (not confirmed) Durand, Alain 10 XL ietf (not confirmed) Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf =46ang, Hsin 1 XL ietf =46ernstedt, Anders 25 L, 25 XL ietf =46ield, Brian 1 XL mail (not confirmed) =46ink, Bob 2 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail (need address) Jaeger, Kurt 5 XL, 1 XXL mail Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf (not confirmed) McCann, Jack 2 XL ? (not confirmed) Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail (not confirmed) Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf (not confirmed) Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Onoe, Atsushi 1 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf Solensky, Frank 1 L ietf (not confirmed) Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Turner, Rob 1 XXL ? (not confirmed) Vohra, Quaizar 3 XL, 1 L, 1 M ietf (not confirmed) Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf (not confirmed) Zhang, Lixia 1 M ietf -end From RLFink@lbl.gov Tue Nov 19 23:04:00 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 15:04:00 -0800 Subject: Tshirt order list 19Nov96 1500 Message-ID: At this stage, to avoid further confusion, I've moved all those not confirmed from the first list to this one, and notated it. However, confirmed or not, I will honor them as there is such a high confirmed response. Way over 300 Tshirts! I'm still open for orders and will queue what comes in after my cutoff for a 2nd run later on. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL mail (need address) Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Boroumand, Jarad 2 XL ietf (not confirmed) Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L ? (not confirmed) Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Curran, Peter 2 L ietf Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? (not confirmed) de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf (not confirmed) Durand, Alain 10 XL ietf (not confirmed) Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf =46ang, Hsin 1 XL ietf =46ernstedt, Anders 25 L, 25 XL ietf =46ield, Brian 1 XL mail (not confirmed) =46ink, Bob 2 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail (need address) Jaeger, Kurt 5 XL, 1 XXL mail Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf (not confirmed) McCann, Jack 2 XL ? (not confirmed) Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail (not confirmed) Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf (not confirmed) Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Onoe, Atsushi 1 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf Solensky, Frank 1 L ietf (not confirmed) Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Turner, Rob 1 XXL ? (not confirmed) Vohra, Quaizar 3 XL, 1 L, 1 M ietf (not confirmed) Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf (not confirmed) Zhang, Lixia 1 M ietf -end From RLFink@lbl.gov Tue Nov 19 23:04:00 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 15:04:00 -0800 Subject: Tshirt order list 19Nov96 1500 Message-ID: At this stage, to avoid further confusion, I've moved all those not confirmed from the first list to this one, and notated it. However, confirmed or not, I will honor them as there is such a high confirmed response. Way over 300 Tshirts! I'm still open for orders and will queue what comes in after my cutoff for a 2nd run later on. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL mail (need address) Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Boroumand, Jarad 2 XL ietf (not confirmed) Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L ? (not confirmed) Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Curran, Peter 2 L ietf Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? (not confirmed) de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf (not confirmed) Durand, Alain 10 XL ietf (not confirmed) Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf =46ang, Hsin 1 XL ietf =46ernstedt, Anders 25 L, 25 XL ietf =46ield, Brian 1 XL mail (not confirmed) =46ink, Bob 2 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail (need address) Jaeger, Kurt 5 XL, 1 XXL mail Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf (not confirmed) McCann, Jack 2 XL ? (not confirmed) Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail (not confirmed) Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf (not confirmed) Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Onoe, Atsushi 1 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf Solensky, Frank 1 L ietf (not confirmed) Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Turner, Rob 1 XXL ? (not confirmed) Vohra, Quaizar 3 XL, 1 L, 1 M ietf (not confirmed) Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf (not confirmed) Zhang, Lixia 1 M ietf -end From RLFink@lbl.gov Tue Nov 19 23:04:00 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 15:04:00 -0800 Subject: Tshirt order list 19Nov96 1500 Message-ID: At this stage, to avoid further confusion, I've moved all those not confirmed from the first list to this one, and notated it. However, confirmed or not, I will honor them as there is such a high confirmed response. Way over 300 Tshirts! I'm still open for orders and will queue what comes in after my cutoff for a 2nd run later on. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL mail (need address) Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Boroumand, Jarad 2 XL ietf (not confirmed) Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L ? (not confirmed) Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Curran, Peter 2 L ietf Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? (not confirmed) de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf (not confirmed) Durand, Alain 10 XL ietf (not confirmed) Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf =46ang, Hsin 1 XL ietf =46ernstedt, Anders 25 L, 25 XL ietf =46ield, Brian 1 XL mail (not confirmed) =46ink, Bob 2 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail (need address) Jaeger, Kurt 5 XL, 1 XXL mail Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf (not confirmed) McCann, Jack 2 XL ? (not confirmed) Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail (not confirmed) Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf (not confirmed) Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Onoe, Atsushi 1 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf Solensky, Frank 1 L ietf (not confirmed) Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Turner, Rob 1 XXL ? (not confirmed) Vohra, Quaizar 3 XL, 1 L, 1 M ietf (not confirmed) Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf (not confirmed) Zhang, Lixia 1 M ietf -end From RLFink@lbl.gov Tue Nov 19 23:04:00 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 15:04:00 -0800 Subject: Tshirt order list 19Nov96 1500 Message-ID: At this stage, to avoid further confusion, I've moved all those not confirmed from the first list to this one, and notated it. However, confirmed or not, I will honor them as there is such a high confirmed response. Way over 300 Tshirts! I'm still open for orders and will queue what comes in after my cutoff for a 2nd run later on. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL mail (need address) Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Boroumand, Jarad 2 XL ietf (not confirmed) Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L ? (not confirmed) Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Curran, Peter 2 L ietf Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? (not confirmed) de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf (not confirmed) Durand, Alain 10 XL ietf (not confirmed) Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf =46ang, Hsin 1 XL ietf =46ernstedt, Anders 25 L, 25 XL ietf =46ield, Brian 1 XL mail (not confirmed) =46ink, Bob 2 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail (need address) Jaeger, Kurt 5 XL, 1 XXL mail Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf (not confirmed) McCann, Jack 2 XL ? (not confirmed) Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail (not confirmed) Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf (not confirmed) Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Onoe, Atsushi 1 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf Solensky, Frank 1 L ietf (not confirmed) Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Turner, Rob 1 XXL ? (not confirmed) Vohra, Quaizar 3 XL, 1 L, 1 M ietf (not confirmed) Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf (not confirmed) Zhang, Lixia 1 M ietf -end From RLFink@lbl.gov Wed Nov 20 00:56:53 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 16:56:53 -0800 Subject: 6bone map change and COLORFUL ADDITIONS :-) Message-ID: 6bone diagram version 35: Many changes - may miss a few on the list below remove extraneous KAIST - CISCO link add TU-Berlin/DE and DETERBERKOM/DE and respective links add DIGITAL-AU/AU with a link to DIGITAL-CA/US add WILLAMETTE/US with a link to WWU/US add new link from SUMITOMO/JP to BAY/US add new links from DIGITAL-CA/US to DETERBERKOM/DE, WIDE/JP & BAY/US Apologies if I screwed something up...just let me know. ALSO - NOT TO START A WAR, A COLORFUL CHANGE I've colorized the nodes, and made a first attempt at identifying transit nodes to eventually help in routing, planning, redoing the map, etc. If I've offended your site, my apologies...just let me know. If I was wrong in doing this, I'll change/remove or whatever is appropriate. Comments to the mailer, please :-) Thanks, Bob From RLFink@lbl.gov Tue Nov 19 23:04:00 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 19 Nov 1996 15:04:00 -0800 Subject: Tshirt order list 19Nov96 1500 Message-ID: At this stage, to avoid further confusion, I've moved all those not confirmed from the first list to this one, and notated it. However, confirmed or not, I will honor them as there is such a high confirmed response. Way over 300 Tshirts! I'm still open for orders and will queue what comes in after my cutoff for a 2nd run later on. Thanks, Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL mail (need address) Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Boroumand, Jarad 2 XL ietf (not confirmed) Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L ? (not confirmed) Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Curran, Peter 2 L ietf Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? (not confirmed) de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf (not confirmed) Durand, Alain 10 XL ietf (not confirmed) Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf =46ang, Hsin 1 XL ietf =46ernstedt, Anders 25 L, 25 XL ietf =46ield, Brian 1 XL mail (not confirmed) =46ink, Bob 2 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail (need address) Jaeger, Kurt 5 XL, 1 XXL mail Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf (not confirmed) McCann, Jack 2 XL ? (not confirmed) Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail (not confirmed) Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf (not confirmed) Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Onoe, Atsushi 1 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf Solensky, Frank 1 L ietf (not confirmed) Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Turner, Rob 1 XXL ? (not confirmed) Vohra, Quaizar 3 XL, 1 L, 1 M ietf (not confirmed) Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf (not confirmed) Zhang, Lixia 1 M ietf -end From john@atcmp.nl Wed Nov 20 12:14:40 1996 From: john@atcmp.nl (John van Krieken) Date: Wed, 20 Nov 1996 13:14:40 +0100 Subject: 6bone map change and COLORFUL ADDITIONS :-) In-Reply-To: Your message of "Tue, 19 Nov 1996 16:56:53 PST." Message-ID: <199611201214.NAA02692@atcmpg.atcmp.nl> In message , Bob Fink LBNL writes: > 6bone diagram version 35: Legend for colors? --------------------------------- John van Krieken, AT Computing BV 024-3527242, john@atcmp.nl, http://www.nl.net/~atcmp/images/pasfotos/john.gif From RLFink@lbl.gov Wed Nov 20 16:35:36 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 20 Nov 1996 08:35:36 -0800 Subject: 6bone map change Message-ID: 6bone diagram version 36: correct routes for NETGOD/US to WWU/US add IBS/US and its tunnel to NETGOD/US Added a legend for the colors. Thanks, Bob From RLFink@lbl.gov Thu Nov 21 00:54:51 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 20 Nov 1996 16:54:51 -0800 Subject: Final country/site list for the 6bone Tshirt Message-ID: This is the final country/site list for the 6bone Tshirt. There are 17 countries and over 80 sites! Well done! Thanks, Bob ========= AT COSY AU DIGITAL CA ESYS CH ETHZ DE DETEBERKOM FAUERN JOGUNET JOIN TU-BERLIN TU-BS DK DENET UAALBORG UAARHUS UNI-C DTH UNI-C KBH UODENSE TELEBIT FR G6 EUDIL ENSTB INRIA IMAG SB-ROSCOFF UPOITIER UREC USTRASBOURG IT POLITO JP KEK SUMITOMO WIDE HITACHI JAIST KEIO NAIST NTT OSAKA-U SONY SONY-CSL U-TOKYO KR KAIST KZ KIT NL RIPE-NCC PT UL SE ERA KTH SICS SG NUS-IRDU UK IFB LUT SCO TICL UCAM-T UCL UMAN US ATT BAY CAIRN CISCO DIGITAL ESNET FNAL FTP-SW IBM IBS-US INNER INTEROP KOHALA LBNL MERIT NASA-GSFC NASA-NAS NETGOD NETLAG NIST NRL PARC RADYN RUTGERS SUMITOMO SUN UCLA UMCP-CS UNH UO USC-ISI WILLAMETTE WWU - From RLFink@lbl.gov Thu Nov 21 00:51:27 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 20 Nov 1996 16:51:27 -0800 Subject: Final 6bone Tshirt list for first order Message-ID: The following list is the final one for the first 6bone Tshirt order. I will now accumulate orders I receive for a later (after the IETF) second order. I will tell everyone as soon as possible about when/how to pay...stay tuned. Thanks, Bob =================================================== Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL ietf Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Boroumand, Jarad 2 XL ietf Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L mail (need postal address) Cianci, Frank 1 XL ietf Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Curran, Peter 2 L ietf Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? (not confirmed) de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf Durand, Alain 2L, 8 XL ietf Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf Fang, Hsin 1 XL ietf Fernstedt, Anders 25 L, 25 XL ietf Field, Brian 1 XL mail Fink, Bob 1 L, 25 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail Jaeger, Kurt 5 XL, 1 XXL mail Jinmei, Tatuya 5 L ietf Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf Kato, Akira 2 L ietf King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf (not confirmed) McCann, Jack 2 XL ? (not confirmed) Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail (not confirmed) Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf (not confirmed) Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Onoe, Atsushi 1 L mail Ouin, Edouard 3 XL ietf Page, John 2 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need postal address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf Solensky, Frank 1 L ietf (not confirmed) Souissi, Mohsen 1 L ietf (Dupont pickup) Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Turner, Rob 1 XXL ? (not confirmed) Vohra, Quaizar 3 XL, 1 L, 1 M ietf Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf Zhang, Lixia 1 M ietf -end From ahoag@nas.nasa.gov Thu Nov 21 16:22:38 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Thu, 21 Nov 1996 08:22:38 -0800 Subject: RIPE object proposal In-Reply-To: davidk@ISI.EDU "RIPE object proposal" (Nov 19, 11:43am) References: <9611191943.AA10337@brind.isi.edu> Message-ID: <9611210822.ZM25552@rennsport.nas.nasa.gov> Just a few comments David. The proposal looks good and thank you David & Geert Jan for all your effort on this! > On Nov 19, 11:43am, davidk@ISI.EDU wrote: > ... > > - loc-string: > > LocationString contains the coordinates of the IPv6 sites location. > Multiple location strings can be proovided on different lines for sites > that have multiple locations in the area. > > Syntax: > > Somebody can give me a pointer for the RFC standard RFC1712 specifies the "GPOS" RR for DNS. (excerpt below) > loc-string: 33 40 10n 117 49 20w 10m Proposed syntax: loc-string: (from RFC1712) LONGITUDE The real number describing the longitude encoded as a printable string. The precision is limited by 256 charcters within the range -90..90 degrees. Positive numbers indicate locations north of the equator. LATITUDE The real number describing the latitude encoded as a printable string. The precision is limited by 256 charcters within the range -180..180 degrees. Positive numbers indicate locations east of the prime meridian. ALTITUDE The real number describing the altitude (in meters) from mean sea-level encoded as a printable string. The precision is limited by 256 charcters. Positive numbers indicate locations above mean sea-level. It also would be helpful to require some sort of "Location:" string describing the above lat-long... Since many people don't know their lat-long, they could alternatively provide the location. > - application: [port] > > This attribute describes the different services available on the site. > The services are the same as described in the '/etc/services' plus the ping > application. More services might be added later on. > > Hostname is the DNS hostname of the host that provides the service and > a port number may be specified for services that don't run on the > standard port. Is it assumed that this is for IPv6 applications? Would a version/protocol field here be useful? > - 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. Currently a lot of people are appending an "ipv6-site" tag after the . This makes sense to me as a sanity check on where the tunnel is supposed to point. Especially with a lot of tunnels being "phased in" or out and changed, the IP address may end up being transient while the IPv6-Site tag would be somewhat more permanent. We discussed this earlier and you pointed out that the database can look up the IP address, however with some of these tunnels moving around, the IP addresses for all records don't get change when the tunnel endpoint changes, so we have some records pointed to the old and some to the new. Would you be able to automatically move all references to the old IP to the new? > Note for discussion: > > It is may be better to use DNS domain names here instead of the raw IP > addresses. If DNS is broken it may be hard to resolve hostname to addresses... I'd rather just do the reverse lookup (at my own risk) if I need the hostname. OTOH, we do use DNS for a reason and using host names may cure some of the problems I mention in the paragraph above. My vote would be for hostnames with the caveat that everyone would have to have DNS configured to tunnel (for the IPv4 endpoints at least). > >-- End of excerpt from davidk@ISI.EDU -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From yoshida@sumitomo.com Thu Nov 21 19:12:26 1996 From: yoshida@sumitomo.com (Shin Yoshida) Date: Thu, 21 Nov 1996 11:12:26 -0800 Subject: 6bone map change and COLORFUL ADDITIONS :-) References: Message-ID: <3294A998.5D06@sumitomo.com> > I've colorized the nodes, and made a first attempt at identifying transit > nodes to eventually help in routing, planning, redoing the map, etc. I'm just curious about how nodes are identified as transit or leaf. Some "leaf" nodes have up to five tunnels and other "leaf" nodes have tunnels to real leaf nodes. Some "transit" nodes have as less as three tunnels and have no tunnels to real leaf nodes. Shin From RLFink@lbl.gov Fri Nov 22 01:33:23 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 21 Nov 1996 17:33:23 -0800 Subject: 6bone map change and COLORFUL ADDITIONS :-) In-Reply-To: <3294A998.5D06@sumitomo.com> References: Message-ID: At 11:12 AM -0800 11/21/96, Shin Yoshida wrote: >> I've colorized the nodes, and made a first attempt at identifying transit >> nodes to eventually help in routing, planning, redoing the map, etc. > >I'm just curious about how nodes are identified as transit or leaf. > >Some "leaf" nodes have up to five tunnels and other "leaf" nodes have >tunnels to real leaf nodes. Some "transit" nodes have as less as three >tunnels and have no tunnels to real leaf nodes. It was just a guess on my part based on past events - nothing special about the designation. It is really an effort to open the discussion of just how we SHOULD structure our 6bone efforts... Thanks, Bob From RLFink@lbl.gov Fri Nov 22 15:23:54 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 22 Nov 1996 07:23:54 -0800 Subject: new 6bone map Message-ID: 6bone drawing version 38: new site ORNL/US with tunnel to ESNET/US Welcome to Oak Ridge National Lab! Thanks, Bob From crawdad@fnal.gov Fri Nov 22 15:33:19 1996 From: crawdad@fnal.gov (Matt Crawford) Date: Fri, 22 Nov 1996 09:33:19 -0600 Subject: 6bone map change and COLORFUL ADDITIONS :-) In-Reply-To: "21 Nov 1996 17:33:23 PST." <"v03007820aeba8e78bd56"@[128.3.9.22]> Message-ID: <199611221533.JAA06474@gungnir.fnal.gov> The map makes it clear that if we were to run RIP now, or any non-policy-based routing protocol, most sites would be carrying transit traffic. Perhaps we should put it on our agenda to clean up and simplify the connectivity to more closely model the sort of network we intend to build. Matt From ray@webwurx.com Fri Nov 22 16:33:33 1996 From: ray@webwurx.com (Webwurx - Ray King) Date: Fri, 22 Nov 1996 11:33:33 -0500 Subject: Well done! Message-ID: <2.2.32.19961122163333.0092b3e8@webwurx.com> Hi, We are the graphics designers who won the T-shirt logo contest. We work for a leading web-design company in Toronto, Canada called Webwurx Multimedia. I would like to congratulate Bob on the tremendous work effort he has put forth organizing this whole T-shirt thing the day to day accuracy and updating on the 6bone website and mailing list. You are doing a tremendous job. And good luck to all the IPv6 and 6bone members in all future developments. I have been following the mailing list for a couple months now and find what you are doing very fascinating - very cool. Keep up the good work. Sincerely, Ray King Webwurx Inc. http://www.webwurx.com From RLFink@lbl.gov Fri Nov 22 17:59:12 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 22 Nov 1996 09:59:12 -0800 Subject: setting a 6bone BOF agenda for San Jose Message-ID: 6bone folk: I'd like to get some consensus on an agenda for the 6bone BOF in San Jose. Below are Alain Durand's suggestions. Please send all ideas/suggestions to the mailer (not to me) so we can all see and discuss what is worth covering in San Jose. Thanks, Bob ============================================ From: "Alain Durand" Date: Thu, 7 Nov 1996 14:59:07 +0100 To: Bob Fink LBNL Subject: agenda of the 6-bone BOF Hi bob, I have a list of topics I would like to discuss during the 6-bone bof. I'm not sure if we'll have time to discuss each one as there might be some more important issues and our timeframe is limited. Some of those topics have already been discussed by mail without reaching a real consensus, I hope the large bandwith provided by the IETF meeting will help us to solve some issues. If it works it will be a good point for the the creation of a WG. - RIPE registry * database clean up * new syntax & new entries (some important infos are missing) - experimental tunnels - IPv6 endpoints - speed/reliability of tunnels - sub-tunnels (tunnels to a subset of a site) - existence of a routing protocol - site carrying full routing table * database sanity check - 6-bone topology * comments on the current topology * how to add new tunnels ? * should we go to a full mesh of core routers? - map of the 6-bone * usefullness of various maps * full maps, sub-maps... - dynamic routing * is it needed at the scale of the 6-bone? * is RIPng suitable? * experiences with other routing protocols? - Addresses * limitations of RFC1897 * could we try something else? * what about "real" IPv6 addresses ? - Alain. --- From jcday@jpd.ch.man.ac.uk Fri Nov 22 17:51:46 1996 From: jcday@jpd.ch.man.ac.uk (Jonathan Day) Date: Fri, 22 Nov 1996 17:51:46 +0000 (GMT) Subject: 6bone map change and COLORFUL ADDITIONS :-) In-Reply-To: <199611221533.JAA06474@gungnir.fnal.gov> from "Matt Crawford" at Nov 22, 96 09:33:19 am Message-ID: <199611221751.RAA06734@jpd.ch.man.ac.uk> > The map makes it clear that if we were to run RIP now, or any > non-policy-based routing protocol, most sites would be carrying > transit traffic. Perhaps we should put it on our agenda to clean up > and simplify the connectivity to more closely model the sort of > network we intend to build. Hmmmm. Is it a good idea to tidy up, at this stage? If people start using IPv6 (as opposed to developing) on a large scale, whilst the layout is still messy, you know that everything will still work (albeit better) when the connections are tidied. It's not always so predictable, if you start simple and increase the complexity. (I've heard that the loss of the transatlantic link between the UK and the US for 2, maybe 2.5 weeks, last year, was due in part to the network at either end becoming too complex.) I'd have thought that the 6bone, as it stands, is ideally suited to testing under unusual conditions, which, of course, are the sort of situations you most need reliability and good performance. Jonathan From RLFink@lbl.gov Fri Nov 22 17:59:04 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 22 Nov 1996 09:59:04 -0800 Subject: 6bone map change and COLORFUL ADDITIONS :-) In-Reply-To: <199611221533.JAA06474@gungnir.fnal.gov> References: "21 Nov 1996 17:33:23 PST." <"v03007820aeba8e78bd56"@[128.3.9.22]> Message-ID: At 7:33 AM -0800 11/22/96, Matt Crawford wrote: >The map makes it clear that if we were to run RIP now, or any >non-policy-based routing protocol, most sites would be carrying >transit traffic. Perhaps we should put it on our agenda to clean up >and simplify the connectivity to more closely model the sort of >network we intend to build. Totally agree. I want to circulate some agenda ideas/suggestions soon for San Jose (actually ones that Alain Durand sent to me) so we can have some better idea of what we should do there. Thanks, Bob From Alain.Durand@imag.fr Fri Nov 22 21:20:15 1996 From: Alain.Durand@imag.fr (Alain Durand) Date: Fri, 22 Nov 1996 22:20:15 +0100 Subject: evolution of the 6-bone In-Reply-To: Bob Fink LBNL "new 6bone map" (Nov 22, 7:23am) References: Message-ID: <961122222015.ZM22584@rama.imag.fr> At the last G6 meeting, we talked about some evolutions about the routing issues in the 6-bone. We came up with some propositions. I'd like to discuss them here. Few points first: ----------------- - we'd like to ease routing - statics routes are going to be used for quite a long time (we do not believe in RIPng at the scale of the growing 6-bone) - we should automaticaly derived them from a routing registry - some sites are willing to work hard to achive a good routing, some others jsut need a 6-bone access. - tunnel informations is of little use to compute routes. Tunnels are somehow point to point link, i.e. layer 2. Current informations in the ripe database about tunnels are only relevant to set up tunnels. We need layer 3 informations, i.e. reachable prefixes, not links, to build routes. Our proposal: ------------- we'd like to define 2 kinds of 6-bone nodes: - core nodes - leaf nodes Core node: ---------- - has a router that knows most (if not all) 6-bone routes - should not have a default route (not quite sure about that) - is willing to provide 6-bone access to any other node - cooperate with other core nodes Leaf node: ---------- - any other node with a default route to a core node Note: Core nodes might be fully inter-connected with tunnels. This is not mandatory, but might prove usefull. not sure, to be discussed RIPE database: -------------- To compute all the 6-bone routes, we only need the following informations for each core node: - IPv6 address of the tunneling router - Prefixes directly reachable from this node NB1: the IPv6 address is only used to build the string of routers NB2: somehow, this is the same kind of informations that a dynamic routing algorithm carries. Interesting points of this proposal: ------------------------------------ - easy to implement - simplify the computation of the routes - sites might use several prefixes. - sites might set up experimental tunnels with other sites and only route selected prefixes through this tunnel. The rest of the traffic will be routed through the regular routes. - only core nodes willing to cooperated should add few new entries in the ripe database. - only few core nodes are needed. Currently I use less than 10 different routers in my routing table. - nodes might become core at any time: they just need to add the extra informations about the prefixes they can reach. What I call core nodes are somehow what we see as transit nodes on the map... - Alain. From dhaskin@baynetworks.com Fri Nov 22 20:33:50 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Fri, 22 Nov 1996 15:33:50 -0500 Subject: route tracing Message-ID: <199611222033.PAA26504@pobox.BayNetworks.com> Falks, I've noticed that some 6bone routers use link-local source addresses when sending ICMP Time Exceeded messages to global scope addresses. Since such messages don't travel far, such routers don't show up in trace route records. Dimitry From RLFink@lbl.gov Fri Nov 22 21:00:05 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 22 Nov 1996 13:00:05 -0800 Subject: 6bone info display posters at the San Jose IETF Message-ID: 6bone folk, Some have mentioned that it might be a good idea to have 6bone information on display at the IETF in San Jose. To this end, I propose to make up two 30 X 40 inch foam core poster boards with 6bone info, and see if we can get the approval from the IETF meeting arrangers to put them out in the open lobby areas for all attendees to see. My proposed content for these is below under the headings Poster 1 and 2. I would like to get input on what is to be on them, and consensus that it is a good idea to do it. Comments, corrections, additions and deletions happily accepted, but please send then to the mailer for all to see. Thanks, Bob ================================================================================ Poster 1 6bone logo w/6bone url under it 6bone stick and ball diagram Text as follows: The 6bone is an independent outgrowth of the IETF IPng project that resulted in the creation of the IPv6 protocols intended to eventually replace the current Internet network layer protocol known as IPv4. The 6bone is currently an informal collaborative project spanning the entire world - currently 17 countries and over 80 sites are participating. One essential part in the IPv4 to IPv6 transition is the development of an Internet-wide IPv6 backbone infrastructure that can transport IPv6 packets. As with the existing IPv4 Internet backbone, the IPv6 backbone infrastructure will be composed of many Internet Service Providers (ISPs) and user networks linked together to provide the world-wide Internet. The 6bone is a virtual network layered on top of portions of the physical IPv4-based Internet to support routing of IPv6 packets, as that function has not yet been integrated into many production routers. The network is composed of islands that can directly support IPv6 packets, linked by virtual point-to-point links called "tunnels". The tunnel endpoints are typically workstation-class machines having operating system support for IPv6. ================================================================================ Poster 2 6bone logo w/6bone url under it Text blocks as follow: 6bone routing registry (bold heading) A 6bone routing registry is maintained at the RIPE-NCC project in Holland: ftp://ftp.ripe.net/ipv6/ip6rr/ This registry provides a way to register the tunnels used in the 6bone, and allows for automatic services such as: VRML mapping (e.g., http://www.ipv6.nas.nasa.gov/viz/) and route tracing (e.g., http://www.ipv6.imag.fr/route.html ) 6bone statistics (bold heading) 6bone statistics are available to indicate the status and quality of 6bone routes and tunnels as needed. Currently three places provide this information: JOIN/DE, NIST/US and TU-BS/DE http://www.join.uni-muenster.de/local/v6ping/v6answer.html http://snad.ncsl.nist.gov/~ipng/NIST-6bone-status.html http://www.cs.tu-bs.de/~strauss/ipng/stats.html IPv6 information (bold heading) IPv6 information resulting from the IETF's IPng project is available at: http://playground.sun.com/pub/ipng/html/ipng-main.html This includes IPng Overview writeups, IPv6 specifications, information on IPv6 implementations and relevant IETF IPng working group information IPv6 implementations (bold heading) IPv6 router and host implementations are now available for production or testing from many commercial and academic sources, including implemetations for both routers and host systems. Router implementations available include: Bay, Cisco, Digital and Telebit Router implementations under development include Ipsilon and Penril. Host implementations available include: 4.4 BSD Lite, AIX, BSD/OS, Digital Unix, HP/UX, MacOS, NetBSD, Solaris Host implementations under development include Linux, Novell, Pacific Softworks, Siemens Nixdorf BS2000, Streams, Windows. ================================================================================ - end From bound@zk3.dec.com Fri Nov 22 22:49:38 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Fri, 22 Nov 96 17:49:38 -0500 Subject: evolution of the 6-bone In-Reply-To: Your message of "Fri, 22 Nov 96 22:20:15 +0100." <961122222015.ZM22584@rama.imag.fr> Message-ID: <9611222249.AA23784@wasted.zk3.dec.com> I agree with your definitions and the core nodes. Seems like the core nodes you define are the transit nodes on the map today. So Bob has it right. thanks /jim From davidk@isi.edu Fri Nov 22 23:05:20 1996 From: davidk@isi.edu (davidk@isi.edu) Date: Fri, 22 Nov 1996 15:05:20 -0800 (PST) Subject: RIPE object proposal In-Reply-To: <9611210822.ZM25552@rennsport.nas.nasa.gov> from "Andrew J. Hoag" at Nov 21, 96 08:22:38 am Message-ID: <9611222305.AA17196@brind.isi.edu> Hi Andrew, > Andrew J. Hoag writes : > > Just a few comments David. The proposal looks good and thank you David & Geert > Jan for all your effort on this! Thanks! > > On Nov 19, 11:43am, davidk@ISI.EDU wrote: > > ... > > > > - loc-string: > > > > LocationString contains the coordinates of the IPv6 sites location. > > Multiple location strings can be proovided on different lines for sites > > that have multiple locations in the area. > > > > Syntax: > > > > Somebody can give me a pointer for the RFC standard > > RFC1712 specifies the "GPOS" RR for DNS. (excerpt below) > > > loc-string: 33 40 10n 117 49 20w 10m > > Proposed syntax: > > loc-string: > > (from RFC1712) > > LONGITUDE The real number describing the longitude encoded as a > printable string. The precision is limited by 256 charcters > within the range -90..90 degrees. Positive numbers > indicate locations north of the equator. > > LATITUDE The real number describing the latitude encoded as a > printable string. The precision is limited by 256 charcters > within the range -180..180 degrees. Positive numbers > indicate locations east of the prime meridian. > > ALTITUDE The real number describing the altitude (in meters) from > mean sea-level encoded as a printable string. The precision > is limited by 256 charcters. Positive numbers indicate > locations above mean sea-level. I will take this up in my proposal. > It also would be helpful to require some sort of "Location:" string describing > the above lat-long... Since many people don't know their lat-long, they could > alternatively provide the location. This is a good one. I would say that we could also add the (optional) 'country:' attribute (will not help much in the US/Russia though ...). We could also change the syntax of loc-string to: RFC1712|[Free text describing location] Software should be smart enough to make the distinction ;-). Or give the advise to describe your location in the 'descr:' field since this 'location description' will not be computer readable anyway. I am just not very sure if we should add another 'free text' attribute. > > - application: [port] > > > > This attribute describes the different services available on the site. > > The services are the same as described in the '/etc/services' plus the ping > > application. More services might be added later on. > > > > Hostname is the DNS hostname of the host that provides the service and > > a port number may be specified for services that don't run on the > > standard port. > > Is it assumed that this is for IPv6 applications? Would a version/protocol > field here be useful? Yes. I didn't add it since the whole object is IPv6 specific but if you think that it is useful ... > > - 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. > > Currently a lot of people are appending an "ipv6-site" tag after the . > This makes sense to me as a sanity check on where the tunnel is supposed to > point. Especially with a lot of tunnels being "phased in" or out and changed, > the IP address may end up being transient while the IPv6-Site tag would be > somewhat more permanent. > > We discussed this earlier and you pointed out that the database can look up the > IP address, however with some of these tunnels moving around, the IP addresses > for all records don't get change when the tunnel endpoint changes, so we have > some records pointed to the old and some to the new. Would you be able to > automatically move all references to the old IP to the new? This would be difficult since it would mean touching other people's objects. My idea was to do this referencing dynamically at lookup time. However, it might be better to start with user supplied site information in the object since this part of the implementation is a kind of trikey and would delay deployment. > > Note for discussion: > > > > It is may be better to use DNS domain names here instead of the raw IP > > addresses. > > If DNS is broken it may be hard to resolve hostname to addresses... I'd rather > just do the reverse lookup (at my own risk) if I need the hostname. OTOH, we do > use DNS for a reason and using host names may cure some of the problems I > mention in the paragraph above. My vote would be for hostnames with the caveat > that everyone would have to have DNS configured to tunnel (for the IPv4 > endpoints at least). Agreed. David K. --- From ahoag@nas.nasa.gov Sat Nov 23 00:15:26 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Fri, 22 Nov 1996 16:15:26 -0800 Subject: RIPE object proposal In-Reply-To: davidk@ISI.EDU "Re: RIPE object proposal" (Nov 22, 3:05pm) References: <9611222305.AA17196@brind.isi.edu> Message-ID: <9611221615.ZM29265@rennsport.nas.nasa.gov> > On Nov 22, 3:05pm, davidk@ISI.EDU wrote: > > Andrew J. Hoag writes : ... > > It also would be helpful to require some sort of "Location:" string describing > > the above lat-long... Since many people don't know their lat-long, they could > > alternatively provide the location. > > This is a good one. I would say that we could also add the (optional) > 'country:' attribute (will not help much in the US/Russia though ...). I can understand trying to limit free text attributes. I think as much "standardization" that we can achieve as possible would be helpful. Somebody feel free to chime in here, but what about specifying the Internet country-code for the location, as well as a one-line string describing the specific population center. (i.e. city, township, ...etc.) Sounds like it might be helpful for most countries if there is a State / Province code somewhere involved as well. > > Is it assumed that this is for IPv6 applications? Would a version/protocol > > field here be useful? > > Yes. I didn't add it since the whole object is IPv6 specific but if you > think that it is useful ... That's probably a good place to save information. I was looking at a more generic use rather than an IPv6 specific one. > > We discussed this earlier and you pointed out that the database can look up the > > IP address, however with some of these tunnels moving around, the IP addresses > > for all records don't get change when the tunnel endpoint changes, so we have > > some records pointed to the old and some to the new. Would you be able to > > automatically move all references to the old IP to the new? > > This would be difficult since it would mean touching other people's > objects. > > My idea was to do this referencing dynamically at lookup time. However, > it might be better to start with user supplied site information in the > object since this part of the implementation is a kind of trikey and > would delay deployment. > > > > Note for discussion: > > > > > > It is may be better to use DNS domain names here instead of the raw IP > > > addresses. > > > > If DNS is broken it may be hard to resolve hostname to addresses... I'd rather > > just do the reverse lookup (at my own risk) if I need the hostname. OTOH, we do > > use DNS for a reason and using host names may cure some of the problems I > > mention in the paragraph above. My vote would be for hostnames with the caveat > > that everyone would have to have DNS configured to tunnel (for the IPv4 > > endpoints at least). > > Agreed. So should hostnames be the norm? That should clear up our problem with moving tunnels noted above. I cross-referenced Alain's comments re: "evolution of the 6-bone" (http://www.ipv6.nas.nasa.gov/6bone/0506.html) and it looks like most of the issues are taken care of. Alain discusses the desire to have the prefix information (prefix: field) and the IPv6 address of the tunnelling router, which could be a AAAA lookup on the hostname above. -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From bound@zk3.dec.com Sat Nov 23 02:51:20 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Fri, 22 Nov 96 21:51:20 -0500 Subject: setting a 6bone BOF agenda for San Jose In-Reply-To: Your message of "Fri, 22 Nov 96 09:59:12 PST." Message-ID: <9611230251.AA06383@wasted.zk3.dec.com> if we can do alains suggestion that woudl be very successful on our part. looks good to me. /jim From jcday@jpd.ch.man.ac.uk Mon Nov 25 09:17:29 1996 From: jcday@jpd.ch.man.ac.uk (Jonathan Day) Date: Mon, 25 Nov 1996 09:17:29 +0000 (GMT) Subject: Videoconferencing Message-ID: <199611250917.JAA02857@jpd.ch.man.ac.uk> Hi One of the oft-made claims for IPv6 is that it's good when used for videoconferencing. Is there any videoconferencing software written to use it, as yet, though? Jonathan From ashleyb@sco.com Mon Nov 25 14:33:07 1996 From: ashleyb@sco.com (Ashley Baumann) Date: Mon, 25 Nov 1996 14:33:07 +0000 (GMT) Subject: UK: Looking for a tunnel Message-ID: <9611251433.aa03263@scowpat.sco.com> Hi, I'm looking for a v6 tunnel somewhere in the uk (we are BTnet customers located in watford). any/all offers gleefully received. Thanks Ashleyb ------------------------- Ashley Baumann TEL: +44 (0)1923 813519 SCO, Croxley Business Park, FAX: +44 (0)1923 813804 Hatters Lane, Watford EMAIL: ashleyb@sco.com WD1 8YN, UK From berndw@deteberkom.de Mon Nov 25 17:44:08 1996 From: berndw@deteberkom.de (Bernd Weise) Date: Mon, 25 Nov 96 17:44:08 MEZ Subject: DeTeBerkom off for few days Message-ID: <199611251645.AA26855@venera.isi.edu> Dear 6bone folks, due to a movement to a new location and new buildings, our site has to be diconnected for a few days. I'll do my best to reconnect the equipment as soon as possible. Please regard our new address from December 1st. Bernd i===========================================================================i i Bernd Weise, DeTeBerkom GmbH, Voltastrasse 5, D-13355 Berlin i i Tel. +49 - 30 - 46701-143, Fax. +49 - 30 - 46701-445 i i i i NEW ADDRESS from 1. December 1996: i i DeTeBerkom GmbH, Goslarer Ufer 35,10589 Berlin i i Tel: +49 - 30 - 3497-3112, Fax: -3113 i i i i Internet: weise@deteberkom.de i i===========================================================================i From crawdad@fnal.gov Mon Nov 25 16:38:54 1996 From: crawdad@fnal.gov (Matt Crawford) Date: Mon, 25 Nov 1996 10:38:54 -0600 Subject: evolution of the 6-bone In-Reply-To: "22 Nov 1996 22:20:15 +0100." <"961122222015.ZM22584"@rama.imag.fr> Message-ID: <199611251638.KAA11207@gungnir.fnal.gov> Alain, I can't quite accept your definition of Core Node, and I don't like the name Leaf Node as you use it. Specifically, I don't think a core node should be required to provide a tunnel to everyone who asks. Rather, the set of all Core Nodes should be defined so that at least one will provide a tunnel to anyone who asks, and possibly the connecting site occasionally will be required to re-home when the Core reorganizes. A Node which is not a Core Node may be an IPv6 provider to many other sites. I think the term "Leaf" isn't appropriate in this case. Also, you may want to require that any two Core Nodes are connected by an IPv6 path which includes only Core Nodes. From dhaskin@baynetworks.com Mon Nov 25 20:03:57 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Mon, 25 Nov 1996 15:03:57 -0500 Subject: new tunnel Message-ID: <199611252003.PAA21691@pobox.BayNetworks.com> Hi, I've registred a new 6bone site and a 6bone tunnel with RIPE: BAY-FRANCE: site: Bay Networks/France location: Valbonne, France, USA prefix: 5F02:3000:C020:AE00:FBDC::/80 ping: 5F02:3000:C020:AE00:FBDC::0001 ping: 5F02:3000:C020:AE00:FBDC::0002 tunnel: 141.251.220.2 192.32.29.62 BAY, USA, RIPng contact: Wenken Ling contact: Dimitry Haskin status: operational since November 25, 1996 remark: platform: BLN remark: will add new tunnels upon request remark: carries all 6-bone routes remark: please report any problems to contacts above changed: dhaskin@baynetworks.com 961125 source: RIPE Ping info: qadams[1]>ping -ip6 5F02:3000:C020:AE00:FBDC::0001 -v -r5 16 bytes from (5F02:3000:C020:AE00:FBDC::0001) via If 13: icmp_seq=0, time= 289 ms 16 bytes from (5F02:3000:C020:AE00:FBDC::0001) via If 13: icmp_seq=1, time= 316 ms 16 bytes from (5F02:3000:C020:AE00:FBDC::0001) via If 13: icmp_seq=2, time= 308 ms 16 bytes from (5F02:3000:C020:AE00:FBDC::0001) via If 13: icmp_seq=3, time= 300 ms 16 bytes from (5F02:3000:C020:AE00:FBDC::0001) via If 13: icmp_seq=4, time= 296 ms ---- IPV6 PING Statistics---- IPV6 ping: [5F02:3000:C020:AE00:FBDC::0001] responded to 5 out of 5: 100% success. round-trip (ms) min/avg/max = 289/301/316 Dimitry From Dransfield@mail.dec.com Tue Nov 26 07:45:54 1996 From: Dransfield@mail.dec.com (Mike Dransfield) Date: Tue, 26 Nov 1996 18:45:54 +1100 Subject: new temporary tunnel at Interop Sydney Message-ID: We have setup a new temporary connection to Network/Interop in Sydney mike site: Networld/Interop Sydney location: Sydney, Australia loc-string: 33 53 s 151 10 e 10m prefix: 5F04:C500:2D00:0::/64 ping: alpha.ipv6.au.interop.net (5F04:C500:2D00::800:2B3C:AFB8) tunnel: 45.16.8.114 204.123.2.236 DIGITAL-CA contact: mike@stl.dec.com status: operational temporarily remark: Digital UNIX IPv6/DECswitch 900EF remark: temporary connection at Sydney interop remark: rip tunnel to DIGITAL-CA remark: static tunnel to DIGITAL-AU changed: mike@stl.dec.com 19961126 source: RIPE From esposito@ercole.cefriel.it Tue Nov 26 13:02:02 1996 From: esposito@ercole.cefriel.it (Sergio Esposito) Date: Tue, 26 Nov 1996 14:02:02 +0100 Subject: new tunnel Message-ID: <2.2.32.19961126130202.006df914@mailer.cefriel.it> Hi, I've registered a new tunnel with RIPE: CEFRIEL site: CEFRIEL location: Milano, ITALY loc-string: 45 37 00n 9 17 00e prefix: 5f00:8900::/32 ping: 5f00:8900:83af:0500:cd:800:2074:7010 tunnel: 131.175.5.37 130.192.14.189 POLITO contact: esposito@mailer.cefriel.it status: operational since 11/96 remark: using ipv6 for Solaris 5.0 changed: esposito@mailer.cefriel.it 961118 source: RIPE Sergio Esposito ============================================================================ Organization : CEFRIEL Address : Via Emanueli, 15 - 20126 MILANO (Italy) Phone : +39-2-66161.211 / +39-2-66161.1 FAX : +39-2-66161.448 Interests : IPv6, IPSec, VPN e-mail : esposito@mailer.cefriel.it www : ============ From RLFink@lbl.gov Tue Nov 26 22:24:42 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 26 Nov 1996 14:24:42 -0800 Subject: 6bone map change Message-ID: 6bone drawing version 39: new site LIU/SE tunnelled to SICS/SE new site BAY-FRANCE/FR tunnelled to BAY/US new site CEFRIEL/IT tunnelled to POLITO/IT Welcome to the new sites! SICS and POLITO should note that they need to add the tunnel end points for these tunnels to their RIPE registry. Thanks, Bob From RLFink@lbl.gov Tue Nov 26 22:42:23 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 26 Nov 1996 14:42:23 -0800 Subject: 6bone attach locs page modified Message-ID: I have updated the attachment location 6bone web page to include Bay and Digital (Cisco and Netlag weere already listed). http://www-6bone.lbl.gov/6bone/6bone_attach_locs.html I suspect that many have missed my minimal pointer to this page on the 6bone hookup page. http://www-6bone.lbl.gov/6bone/6bone_hookup.html I would encourage anyone that wants equal billing to review this page and send me email with their intent/desire to be added to this page as well as an email contact point. Thanks, Bob From sakurai@rinfo.sumiden.co.jp Thu Nov 28 05:34:14 1996 From: sakurai@rinfo.sumiden.co.jp (Akihiro Sakurai) Date: Thu, 28 Nov 1996 14:34:14 +0900 Subject: New Tunnels Message-ID: <199611280533.OAA01876@rinfogw.rinfo.sei.co.jp> All, I've update SUMITOMO-JP's RIPE database entry with new tunnels: SUMITOMO-JP <-> DIGITAL-CA RIPng SUMITOMO-JP <-> KEK Static Routing Regards, ------------------------------------------------------------------------ Akihiro Sakurai E-mail:sakurai@rinfo.sumiden.co.jp Systems and Electronics R & D Center, Sumitomo Electric Industries, Ltd. Phone +81-6-466-5601 Fax +81-6-462-4586 From roque@di.fc.ul.pt Fri Nov 29 00:28:33 1996 From: roque@di.fc.ul.pt (Pedro Roque) Date: Fri, 29 Nov 1996 00:28:33 GMT Subject: BOF topic - address allocation Message-ID: <199611290028.AAA28569@oberon.di.fc.ul.pt> This is a proposal for a small modification of RFC 1897 which could be considered a complement to what Alain Durand was proposing in a previous mail. As 1897 is a formal document i thought i better write the "mail" in a similiar way. ./Pedro. ------------------------------------------------------------------------------ Submission to the 6bone BOF Roque, P. November 1996 roque@di.fc.ul.pt Address Allocation on the 6bone Abstract This document suggests an address allocation policy for use in the 6bone. Introduction Currently, the 6bone, although composed of a small number of nodes starts to show some characteristics that should be avoided in terms of address allocation. The current 6bone topology, appears as a mixture of a full mesh network and a geographic based network. This fact tends to increase the complexity of the management tasks and routing table determination. But as routing protocols start to be deployed, the topology moves to a more common model of a large group of leaf domains and a smaller group of transit domains, the current address allocation [RFC1897] will still force transit routers to carry an average of one entry per connected site. The goal of this document is to propose a way to reduce this ratio via changes to the address allocation procedure. Complementary, it is believed that it will reduce the management tasks of the network (specially until the point that every transit site speaks a common routing protocol). "Real" IPv6 addresses Using IPv6 addresses out of the "Test Address Allocation" space in the current 6bone is an alternative that the author considers to be a potential disservice to IPv6 deployment. Of the current 6bone sites that provide for transit traffic a very small percentage are transit domains for the IPv4 Internet. Since an address allocation should distribute small prefixes for transit domains for further allocation to leaf nodes that default through them, it would be necessary to allocate at the moment "top level provider" prefixes to the transit domains. Since the significative majority of those domains will not, under normal circumstances, be considered "top level" transit networks this policy will then to waste address space and reduce the aggregation capability of the future IPv6 Internet. The author believes that an address allocation policy should follow the wire topology, and not a virtual topology like the current 6bone. Modifications to the Test Address Allocation RFC 1897 specifies that a site should use a prefix composed of the test allocation prefix (5f::/8), it's network provider AS number and it's IPv4 network addresses. The author suggests that for leaf nodes, the prefix should be constructed using the 32 first bits of the prefix used by the transit site they connect to. The following 32 bits of the prefix should be constructed according to the rule set on the referred document. For transit domains, the AS number used should be an AS number registered in the InterNIC database for that domain, if available. Else the transit domain will use the AS number of it's network provider and a sequential number (starting from 1) on the first reserved field of RFC 1897 (from left to right). It is expected that users of the same AS can resolve the attribution of the sub-AS identifier as a local problem. As the 6bone grows it's topology is expected to converge to the current Internet topology and transit sites will normally own an AS identifier. Lifetime This policy is only intended to the short term, and if adopted, should be reviewed periodicly. From malara@crs4.it Fri Nov 29 18:50:29 1996 From: malara@crs4.it (Paolo Malara) Date: Fri, 29 Nov 96 19:50:29 +0100 Subject: CRS4 asking to join Message-ID: <199611291850.AA69085@bruckner.crs4.it> Hello, CRS4 is looking for a point of attachment to the 6bone. We are a non-profit research center located in Sardinia (more info at http://www.crs4.it). We are currently running IPv6 on a few Solaris-2.5 machines (sparc based). I guess the best choice for us is "Politecnico di Torino", isn't it? Any help would be really appreciated. Thanks. Paolo Malara -- * * * * *Centro di Ricerca, Sviluppo e Studi Superiori in Sardegna * * * * * * * * * * Paolo Malara * Phone: (+39) 70 2796 260 * * * * * CRS4 * Fax: (+39) 70 2796 245 * * via Nazario Sauro, 10 * * * 09123 Cagliari, Italy * E-mail: malara@crs4.it * * * * * * * Centre for Advanced Studies, Research, and Development in Sardinia * * * From RLFink@lbl.gov Fri Nov 29 21:09:34 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 29 Nov 1996 13:09:34 -0800 Subject: 6bone map change Message-ID: 6bone diagram version 40: SUMITOMO/JP tunnel to DIGITAL-CA/US SUMITOMO/JP tunnel to KEK/JP Note to KEK/JP to add SUMITOMO tunnel to their RIPE entry. Thanks, Bob From ahoag@nas.nasa.gov Sat Nov 30 03:12:14 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Fri, 29 Nov 1996 19:12:14 -0800 Subject: New VRML Map & snapshots Message-ID: <9611291912.ZM3797@rennsport.nas.nasa.gov> I ran another VRML map and GIF snapshots. Things seem to be growing quite rapidly. Here's the problems from the RIPE database: 182 (99 / 83 dups) tunnels processed for 59 sites. Asymmetric tunnel: DIGITAL-CA (204.123.2.236) --> NIST (129.6.51.154) Asymmetric tunnel: DIGITAL-CA (204.123.2.236) --> NRL (132.250.90.5) Asymmetric tunnel: DIGITAL-CA (204.123.2.236) --> SOFTBANK (199.45.11.20) Asymmetric tunnel: DIGITAL-CA (204.123.2.236) --> MERIT (198.108.60.153) Asymmetric tunnel: ERA (192.71.20.139) --> SICS (193.10.66.50) Asymmetric tunnel: ESNET (198.128.2.27) --> JOIN (128.176.191.66) Asymmetric tunnel: ESNET (198.128.2.27) --> FNAL (131.225.57.207) Asymmetric tunnel: FNAL (131.225.57.207) --> ESNET (198.128.4.72) Asymmetric tunnel: IBS-US (208.131.3.35) --> UO (128.223.222.11) Asymmetric tunnel: JOIN (128.176.191.66) --> ESNET (198.128.4.72) Asymmetric tunnel: LIU (130.236.79.169) --> SICS (193.10.66.50) Asymmetric tunnel: NETGOD (206.129.65.250) --> IBS-US (208.131.3.35) Asymmetric tunnel: NRL (132.250.90.5) --> UL (192.67.76.128) Asymmetric tunnel: SUMITOMO-JP (133.153.22.100) --> KEK (130.87.57.37) Asymmetric tunnel: TELEBIT (194.182.135.253) --> NIST (129.6.51.154) Asymmetric tunnel: TELEBIT (194.182.135.253) --> G6 (193.55.240.18) Asymmetric tunnel: UCAM-T (131.111.193.104) --> IFB (194.105.166.254) Asymmetric tunnel: UL (192.67.76.128) --> NRL (132.250.90.16) So there are still some tunnels in RIPE that don't have the corresponding return tunnel. DIGITAL-CA seems have a lot on its list, but is not in anyone's list. I _am_ aware of the positioning problems in the UK (I don't have new / better lat-longs yet) and the old political boundaries (non-unified Germany). I'm keeping my eyes peeled for a new globe that is more up to date. Enjoy! -- | Andrew Hoag | MS 258-6 | Voice: (415) 604-4972 | | Network Engineer | Moffett Field, CA 94035 | Fax: (415) 604-4377 | | High-Speed LAN +------------------------+---+--------------------+ | NAS Facility | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov | -- From stuart@pa.dec.com Sat Nov 30 05:54:33 1996 From: stuart@pa.dec.com (Stephen Stuart) Date: Fri, 29 Nov 96 21:54:33 -0800 Subject: New VRML Map & snapshots In-Reply-To: Your message of Fri, 29 Nov 96 19:12:14 -0800. <9611291912.ZM3797@rennsport.nas.nasa.gov> Message-ID: <9611300554.AA25080@nsl-too.pa.dec.com> > 182 (99 / 83 dups) tunnels processed for 59 sites. > Asymmetric tunnel: DIGITAL-CA (204.123.2.236) --> NIST (129.6.51.154) > Asymmetric tunnel: DIGITAL-CA (204.123.2.236) --> NRL (132.250.90.5) > Asymmetric tunnel: DIGITAL-CA (204.123.2.236) --> SOFTBANK (199.45.11.20) > Asymmetric tunnel: DIGITAL-CA (204.123.2.236) --> MERIT (198.108.60.153) NIST and NRL requested tunnels a while back but never followed up when I added them; I've taken them off our list. Merit requested a RIP tunnel, and I'm not sure what their intentions are regarding listing it in their registry. Softbank doesn't seem to have appeared in the registry yet. > So there are still some tunnels in RIPE that don't have the corresponding > return tunnel. DIGITAL-CA seems have a lot on its list, but is not > in anyone's list. I list what I've configured, and I configure what's been requested. Is there some other procedure that other people follow? Stephen From ahoag@nas.nasa.gov Sat Nov 30 07:31:23 1996 From: ahoag@nas.nasa.gov (Andrew J. Hoag) Date: Fri, 29 Nov 1996 23:31:23 -0800 (PST) Subject: New VRML Map & snapshots In-Reply-To: <9611300554.AA25080@nsl-too.pa.dec.com> from "Stephen Stuart" at Nov 29, 96 09:54:33 pm Message-ID: <199611300731.XAA04133@rennsport.nas.nasa.gov> > > So there are still some tunnels in RIPE that don't have the corresponding > > return tunnel. DIGITAL-CA seems have a lot on its list, but is not > > in anyone's list. > > I list what I've configured, and I configure what's been requested. Is > there some other procedure that other people follow? I'm sorry, I wasn't trying to single you out. It probably would have been better to list the other parties who hadn't updated their entries, rather than the person who did. :-) Unfortunately, there isn't really a "procedure" to any of this and frequently people don't remember to update the database entry as they add tunnels, and that's what I am trying to point out. As accurate information as we can get will be helpful in a couple of weeks when we try and figure out what, if any, actions are neccessary to grow the 6bone. Thanks for the update! From RLFink@lbl.gov Sat Nov 30 18:40:23 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Sat, 30 Nov 1996 10:40:23 -0800 Subject: additions to 6bone hookup locs page and change in format Message-ID: I've added G6 to the hoookup locs page and also minimized the gratuitious text. http://www-6bone.lbl.gov/6bone/6bone_attach_locs.html Thanks, Bob From pjb27@cam.ac.uk Sat Nov 30 19:31:43 1996 From: pjb27@cam.ac.uk (Philip Blundell) Date: Sat, 30 Nov 1996 19:31:43 +0000 (GMT) Subject: evolution of the 6-bone In-Reply-To: <199611251638.KAA11207@gungnir.fnal.gov> Message-ID: On Mon, 25 Nov 1996, Matt Crawford wrote: > I can't quite accept your definition of Core Node, and I don't like > the name Leaf Node as you use it. Specifically, I don't think a core > node should be required to provide a tunnel to everyone who asks. > Rather, the set of all Core Nodes should be defined so that at least > one will provide a tunnel to anyone who asks, and possibly the > connecting site occasionally will be required to re-home when the > Core reorganizes. > > A Node which is not a Core Node may be an IPv6 provider to many other > sites. I think the term "Leaf" isn't appropriate in this case. > > Also, you may want to require that any two Core Nodes are connected > by an IPv6 path which includes only Core Nodes. I agree with Matt. I don't think it's reasonable to require any particular Core Node to accept a tunnel from all comers. A "leaf" node would have to be a node which doesn't forward traffic for _any_ other node, but I'm not at all convinced that it would be a useful concept to come up with. In the UK, at least, things seem to be heading towards a loosely-organised but quite well-connected web, with many tunnels between sites, rather than one central 'backbone' node and many 'leaf' nodes hanging off it. I suggest that core nodes (as defined above) be designated as such on the map, and all other nodes just be left without any special annotation. phil From kuznet@ms2.inr.ac.ru Sat Nov 30 20:31:38 1996 From: kuznet@ms2.inr.ac.ru (A.N.Kuznetsov) Date: Sat, 30 Nov 1996 23:31:38 +0300 Subject: INR looking for tunnel Message-ID: <32A099AA.4796@ms2.inr.ac.ru> Hello! We are looking for a tunnel to 6bone. Location: Moscow, Russia Institute for Nuclear Research (http://www.inr.ac.ru) Supposed tunnel endpoint: dee.inr.ac.ru (193.233.7.82) IPv6 net: 5f0b:4f00:c1e9:700::/64 Any would be appreciated. Thanks. Alexey Kuznetsov. INR Network Administrator. kuznet@ms2.inr.ac.ru