From bound@zk3.dec.com Sat Jan 4 18:28:10 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Sat, 04 Jan 97 13:28:10 -0500 Subject: IPv6/DHCPv6 Public Domain on Alpha Netbsd 4.4 (64 bits!!!) Message-ID: <9701041828.AA15398@wasted.zk3.dec.com> DO NOT RESPOND TO THIS MAIL see below for implementation lists and contacts. Over the past 6 months Yunzhou Li from the University of Singapore working in conjunction with the University of New Hampshire, and Quaizar Vohra from the University of New Hampshire (UNH) developed a public domain version of DHCPv6 and IPv6 to run on the Carnegie Mellon port of Netbsd 4.4 on Digital Equipments Alpha 64 bit processor. Support to Yunzhou, Quaizar, and UNH for this effort was provided by the Digital IPv6 Alpha UNIX team to assist where we were able. This software is a 64bit version of IPv6 that is available to the public domain without any copyrights or other obligations other than the hope of sharing enhancements and ideas into the Internet Software Community. The DHCPv6 code is available now and the IPv6 stack will be available soon this month (January 1997). Though the DHCPv6 code is mean't for Quaizar's IPv6 stack he did at UNH, I believe that Yunzhou's code can be ported to other IPv6 stacks, using the IPv6 the Basic and Advanced API drafts as Yunzhou took the time to develop the code base in a most portable manner (e.g. using the database described in the book "Advanced Programming in the UNIX Environment" by Dr. Richard Stevens). You can access the DHCPv6 code base at: ftp://sun4.iol.unh.edu/pub/dhcpv6 There are two types of compressed packages inclusive: dhcpv6-1.0.tar.gz (for gunzip) dhcpv6-1.0.tar.Z (for uncompress) A documentation file exists based on the DHCPv6 draft but needs to be updated to reflect the next version of the draft Charlie Perkins (IBM Watson Labs) and I will submit for last call in January 1997 to reach Proposed Standard status. But the code base should not be affected in any significant manner. One objective we should have as a community is to add Dynamic Updates to DNS to the DHCPv6 Server code base Yunzhou has provided us using the latest release from Paul Vixie et al BIND T8.1A and the necessary security enhancements from the DNSSEC work and other implementation ideas being worked on in the community. If you want to contact Yunzhou you can reach him for now at yunzhou@ee.nus.sg or scip4166@leonis.nus.org. Yunzhou will be moving to the U.S. in late January 1997. You can reach Quaizar at qv@iol.unh.edu. Implementation discussion for DHCPv6 will be discussed on a mail list created for us by Ralph Droms Chair of the IETF DHC Working Group. The list will be dhc-v6impl@bucknell.edu and you can subscribe to that list as follows: Mail to listserv@bucknell.edu with body "help" or subscribe dhcp-v6impl Your Name Once Quaizar releases his code base we can use our IPv6 implementors list to discuss that software code base and report bugs etc... That list is ipv6imp@munnari.oz.au. This list has existed for some time for IPv6 implementors, and you can subscribe to it as follows: Mail to ipv6imp-request@munnari.oz.au. Quaizar's implementation is also documented very well as part of his Masters of Computer Science Thesis at UNH. Also a recent Digial Technical Journal (DTJ) is out and if you can get a copy it describes well what and how we built IPv6 on Alpha DUNIX (written by Dan Harrington [now at Lucent Technologies] Matt Thomas, Jack McCann, and Jim Bound). Its Volume 8 Number 3 1996. It is sent outside of Digital so what we wrote about is now public knowledge. It also discusses some of the paradigm and architectural trade-offs we made from an implementation perspective, like taking advantage of a 64bit architecture. I will announce a WWW page pointer and add a hotlink to our www.digital.com/info/ipv6/ page sometime in January 1997, where you will also be able to determine how to get hard copies if you want them, or view it online. As a community we need to give a big thanks to the University of New Hampshire (UNH), the UNH Interoperability Lab, University of Singapore, Yunzhou Li, Quaizar Vohra, Digital Equipement Corporation, and the Digital Alpha DUNIX IPv6 Team. This work will provide us a working IPv6 64 bit platform on Alpha to further develop the growing public domain of IPv6 software. A special thanks to Carnegie Mellon for the vision and on going work to port Netbsd 4.4 to the Alpha Platform, and Charlie Perkins and the IETF DHC Working Group for taking on DHCPv6 as the first IETF WG outside of the classic IPng Working group to produce an IPv6 spec that we think has rough consensus and "running code". Sincerely, /jim Jim Bound Consulting Software Engineer IPv6 Technical Director Digital Equipment Corporation bound@zk3.dec.com 603-881-0400 From rja@cisco.com Sat Jan 4 20:06:56 1997 From: rja@cisco.com (Ran Atkinson) Date: Sat, 4 Jan 1997 12:06:56 PST Subject: [IPv6Imp] IPv6/DHCPv6 Public Domain on Alpha Netbsd 4.4 (64 bits!!!) In-Reply-To: bound@zk3.dec.com "[IPv6Imp] IPv6/DHCPv6 Public Domain on Alpha Netbsd 4.4 (64 bits!!!)" (Jan 4, 1:28pm) Message-ID: <199701042006.MAA23550@cornpuffs.cisco.com> I'm glad to see this DHCPv6 port appear. As a matter of record, I'll note that the NRL IPv6 code has been running fine for some time now on DEC Alpha/NetBSD systems at NASA/Moffett Field, so this gives the DEC Alpha two different ports to work with (a good thing, IMHO). :-) Ran rja@cisco.com -- From templin@nas.nasa.gov Sun Jan 5 01:49:16 1997 From: templin@nas.nasa.gov (Fred L. Templin) Date: Sat, 4 Jan 1997 17:49:16 -0800 (PST) Subject: [IPv6Imp] IPv6/DHCPv6 Public Domain on Alpha Netbsd 4.4 (64 bits!!!) Message-ID: <199701050149.RAA29916@osprey.nas.nasa.gov> > As a matter of record, I'll note that the NRL IPv6 code has been > running fine for some time now on DEC Alpha/NetBSD systems at > NASA/Moffett Field, so this gives the DEC Alpha two different > ports to work with (a good thing, IMHO). Yes, as Ran points out we've been running the NRL IPv6 and IPSEC implementations on DEC Alpha/NetBSD-1.2 (including my changes which make the NRL code 64-bit clean) for a couple of months now here at NASA Ames. See: http://www.ipv6.nas.nasa.gov/nrl64.html for a writeup of the porting project. Since our current research objectives require an IPv6 implementation which offeres both high performance and extensibility, however, we're very much interested in taking a look at the new public-domain release Jim Bound referred to in his announcement as well. It's still a bit early for us to run a "bakeoff" against the various implementations, so Jim's annoucement certainly gives us a new data point to consider. Regards, Fred templin@nas.nasa.gov From bound@zk3.dec.com Mon Jan 6 16:09:35 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 06 Jan 97 11:09:35 -0500 Subject: [IPv6Imp] IPv6/DHCPv6 Public Domain on Alpha Netbsd 4.4 (64 bits!!!) In-Reply-To: Your message of "Sat, 04 Jan 97 17:49:16 PST." <199701050149.RAA29916@osprey.nas.nasa.gov> Message-ID: <9701061609.AA28270@wasted.zk3.dec.com> Fred, >Yes, as Ran points out we've been running the NRL IPv6 and IPSEC >implementations on DEC Alpha/NetBSD-1.2 (including my changes which >make the NRL code 64-bit clean) for a couple of months now here at >NASA Ames. See: > http://www.ipv6.nas.nasa.gov/nrl64.html I knew about this from you as you know for sometime. Was not clear until now you and NRL were updating the sources. More 64 bit code bases on Alpha is always a good thing. Also my mistake its release Netbsd 1.2 (not 4.4 but is based on 4.4). >for a writeup of the porting project. Since our current research >objectives require an IPv6 implementation which offeres both high >performance and extensibility, however, we're very much interested >in taking a look at the new public-domain release Jim Bound referred >to in his announcement as well. It's still a bit early for us to run >a "bakeoff" against the various implementations, so Jim's annoucement >certainly gives us a new data point to consider. I think you should check out the UNH code at NASA once its out. Connectathon is the first week in March and the next IPv6 interoperability testing will take place there in the Bay Area. I do feel unless an implementation goes to an IPv6 interoperability event it is not tempered to the test of fire and if I were a user I would ask if an implementation has been at these events. These events really test an implementation which cannot be done or verified by just being on the 6bone (e.g. address configuration, Neighbor Discovery, API) and really helps with development. Also IPsec still has yet to be tested at these IPv6 interoperability events and Multicast Routing so we still have a ways to go. Right now the only public domain that has been tested with the UNH test suites is INRIA's version. /jim From RLFink@lbl.gov Mon Jan 6 17:42:02 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 6 Jan 1997 09:42:02 -0800 Subject: San Jose IETF 6bone BOF minutes Message-ID: IETF Secretariat, I've enclosed the minutes of the San Jose IETF 6bone BOF. Though I handed in some slides at the reg desk in San Jose to be included in the printed proceedings, I would like to cancel them. The material I handed in, as well as other relevant info, is provided within these minutes. Thanks, Bob _______________________cut here_______________________________________ 6bone BOF Meeting December 10, 1996 San Jose, CA Bob Fink / LBNL, Chair Reported by Alain Durand, Pedro Roque, and Bob Fink. -------------------------------------------------------------------- Agenda -------------------------------------------------------------------- 1. Introduction and Agenda Bashing / Bob Fink (5 mins) 2. Formation of a 6bone WG - do we? / Bob Fink (10 mins) 3. If so, what might we set as an initial WG goal? / Bob Fink (5 mins) 4. Topology / Alain Durand (30 mins) 5. Addressing / (30 mins) 6. Routing / Pedro Roque (15 mins) 7. RIPE Registry cleanup & changes / David Kessens (15 mins) 8. Maps / Bob Fink (5 mins) -------------------------------------------------------------------- 1. Introduction and Agenda Bashing / Bob Fink -------------------------------------------------------------------- Bob Fink convened the meeting, and reviewed the agenda and its order, asking for changes. Rough time estimates were allocated for each item to keep the meeting on track. The agenda was acceptable to the group and the meeting continued. Fink noted that there was a 6bone web page at: http://www-6bone.lbl.gov/6bone/ and a mail list that one can subscribe to: majordomo@isi.edu subscribe 6bone -------------------------------------------------------------------- 2. Formation of a 6bone WG - do we? / Bob Fink -------------------------------------------------------------------- Bob Fink presented his view of the pros and cons of forming a working group. Advantages: - getting a meeting place at IETF meetings - formalization of process of feedback to other IETF ipv6 efforts Disadvantage: - need a goal and some work products - need to incur administrative overhead Fink contended that we've already succumbed to the admin. overhead and have most processes in place because of the existing 6bone testbed effort, and that 6bone participants are already producing useful products. Thus we (the 6bone participants) may just need to document some of them . Thus Bob concluded that it was worth forming a working group. Fink also presented a possible draft charter: The 6bone Working Group is a forum for information concerning the deployment, engineering, and operation of ipv6 protocols and procedures in the global Internet. This activity will include, but not be limited to: - Deployment of ipv6 transport and routing in the global Internet via a "6bone" testbed to assist in the following. - Creation of "practice and experience" informational RFC documents that capture the experiences of those who have deployed, and are deploying, various ipv6 technologies. - Feedback to various IETF ipv6-related activities, based on testbed experience, where appropriate. - Development of mechanisms and procedures to aid in the transition to native ipv6, where appropriate. - Development of mechanisms and procedures for sharing operational information to aid in operation of global ipv6 routing. Fink noted that the 6bone, though originally formed from the model of the mbone, was not like the current Mboned WG effort as the early 6bone is not a real start at deployment, rather a testbed for developers and users to try out implemenations and operational experiences to feed back into IPng IETF efforts and also provide advocacy for IPv6 deployment. There was broad consensus that Fink should proceed with forming a working group. There were also comments that supported Bob Fink acting as the chair, which he agreed to do at least initially for the formation effort. -------------------------------------------------------------------- 3. If so, what might we set as an initial WG goal? / Bob Fink -------------------------------------------------------------------- Bob Fink then presented several possible work products of a working group that were basicallyt generating a series of informational RFCs: - documentation of the RIPE registry - documentation of 6bone testbed participation procedures - documentation of relevant experiences with the testbed It was noted that currently the 6bone effort would be under the Operations area (Bradner/O'Dell are directors). Bob Fink agreed to proceed with filing the necessary charter and plan with the area directors as well as generating a discussion of the charter on the mailer. -------------------------------------------------------------------- 4. Topology / Alain Durand -------------------------------------------------------------------- Alain Durain proposed converting the 6bone testbed topology to a three level system of core backbone routers, second tier transit routers and leaf routers (for node sites not doing transit). He proposed this to better structure the 6bone for effective routing and to simplify its topology. Tunnels could then be built for either production or experimental uses. Durand noted his main point is that tunnels are per nature layer 2 items, and that if one wants the 6-bone to grow, it needs to do some kind of routing. From hiss experience, it's not such an easy task and probably not all nodes are willing to do it completely. Thus the reason for his proposed reorganized routing/topology into a three level system. It was agreed to continue this discussion on the mailer. -------------------------------------------------------------------- 6. Routing / Pedro Roque -------------------------------------------------------------------- Pedro Roque led off a discussion of routing in the 6bone with his concern that RIPng was slow to converge and caused him much trouble on the less reliable trans-Atlantic links. Others expressed their opinion that RIPng was able to converge and work in the 6bone. It was clear that there was a need for lively debate on the relative merits of routing approaches for the 6bone. The chair suggested that it was best to pursue this on the mailer. -------------------------------------------------------------------- 5. Addressing -------------------------------------------------------------------- Alain Durand presented his request for a change in the prefix notation for IPv6 addressing (draft-durand-ipv6prefix-00.txt). It was agreed that this was an oversight in RFC 1844 specifying address notation, and that this topic should be brought up at the IPng meetings this IETF week (it was and there was agreement there to incorporate Alain's suggested prefix format). Durand noted that this is not a "change" per se, just something that is not standardized yet. Someone pointed out that this notation could conflict with another notation that was used by the RPS group. Durand checked this with them later after the meeting, and thinks that in fact there is no problem at all. Pedro Roque presented his suggested address allocation policy for use in the 6bone. This was an elaboration of RFC 1897 that basically suggests that for leaf nodes (in the 6bone) that the prefix should be constructed using the first 32 bits of the prefix used by the transit site they are connected to. Some thought this was a reasonable idea. Geert Jan de Groot said that this was maybe not necessary because a dynamic routing algorithm would solve most problems. The discussion went back to RIPng, with some saying that RIPng is maybe not enough, and that what is needed are better protocols like BGP or IDRP. The question was raised about sites connecting to "big" nodes, and which prefix they should use. The answer was both, as it's a case of multihoming. Matt Crawford proposed using the 6bone testbed to experiment with Mike O'Dell's 8+8 addressing proposal. He identified various issues relating to this effort: - Host issues - modified pseudo header checksum for 8+8 addresses - Router isssues - insertion of RG - DNS issues - DNS lookup in 2 different parts AA & RG - Discover bootstrap troubles - Security issue - should we mandate IPsec? It was noted that IPsec is not currently in the tested. Jim Bound noted that a new draft was needed to explain what the differences are with the present addressing implementation. Jim also noted that he was interested in attempting an implementation of 8+8 that co-existed with the existing addressing as he believes that can be done. Bob Hinden expressed his concern that until the IPng working group decided if 8+8 was possible that it was premature for the 6bone efforts to deal with it. The chair agreed with this concern but also noted that the 6bone effort might assist the IPng 8+8 design effor in giving feedback as it moved along. It was agreed to continue discussion of possible 6bone 8+8 efforts on the mailer. -------------------------------------------------------------------- 7. RIPE Registry cleanup & changes / David Kessens -------------------------------------------------------------------- David Kessens presented the RPSL work in relation to a modified format for the RIPE-NCC 6bone routing registry. He contended that a well defined (and new) syntax was necessary before cleaning up the current RIPE-NCC 6bone registry. There were some comments on various fields. It was noted that an IPv6 end point address should be added. It was agreed to continue the discussion on RIPE-NCC 6bone registry restructuring on the mailer. David's presentation is available at: http://www-6bone.lbl.gov/6bone/ripev6object-kessens.ps -------------------------------------------------------------------- 8. Maps / Bob Fink -------------------------------------------------------------------- Bob Fink noted that he was at the useful limits of the current 6bone diagram, but that he intended to experiment with other forms of drawing it as the topology discussions and restructuring proceeded. The preferred solution would be to have the maps drawn automatically from registry data. Until such mechanisms are in use for the 6bone, Fink noted that he was willing to try to keep a 6bone map up to date manually. -------------------------------------------------------------------- -------------------------------------------------------------------- - end From pan@aster.spct.net Mon Jan 6 20:02:48 1997 From: pan@aster.spct.net (Plamen Nikolaev) Date: Mon, 6 Jan 1997 22:02:48 +0200 Subject: tunnel request Message-ID: <199701062002.WAA07700@a2.aster.spct.net> Hi folks, I am the admin of a small ISP in Sofia, Bulgaria and would like to get familiar with IPv6. Could someone please offer a tunnel? I intend to use one host currenlty (linux 2.1.18+, IP: 207.86.226.33) Our provider is Digex: [root@a2 /root]# traceroute rs.internic.net traceroute to rs.internic.net (198.41.0.5), 30 hops max, 40 byte packets 1 router (207.86.226.1) 222.988 ms 206.035 ms 209.178 ms 2 206.181.51.73 (206.181.51.73) 1087.04 ms 865.937 ms 2339.02 ms 3 dca1-core2-f0-0.atlas.digex.net (206.205.242.10) 1135.43 ms 1145 ms 888.814 ms 4 iad1-core1-h1-0.atlas.digex.net (165.117.50.89) 765.144 ms 785.801 ms * 5 maeeast-1.bbnplanet.net (192.41.177.1) 806.948 ms 874.9 ms * 6 collegepk-br2.bbnplanet.net (4.0.1.17) 1016.47 ms 1046.06 ms * 7 * collegepk-cr3.bbnplanet.net (128.167.252.1) 1111.44 ms 925.304 ms 8 netsol.bbnplanet.net (192.221.77.130) 1115.99 ms 1295.38 ms 888.868 ms 9 * rs0.internic.net (198.41.0.5) 799.857 ms 784.699 ms I've tried to come up with na IPv6 address: 5f00:f400:cf56:e200:21:40:3324:eb6c using one of Digex ASNs (2548). Not sure whether this is correct though. Thanks in advance, Plamen Nikolaev From jeffb@hsnp.com Mon Jan 6 22:15:14 1997 From: jeffb@hsnp.com (Jeff Barrow) Date: Mon, 6 Jan 1997 16:15:14 -0600 (CST) Subject: tunnel request In-Reply-To: <199701062002.WAA07700@a2.aster.spct.net> Message-ID: > 5 maeeast-1.bbnplanet.net (192.41.177.1) 806.948 ms 874.9 ms * > 6 collegepk-br2.bbnplanet.net (4.0.1.17) 1016.47 ms 1046.06 ms * > 7 * collegepk-cr3.bbnplanet.net (128.167.252.1) 1111.44 ms 925.304 ms > 8 netsol.bbnplanet.net (192.221.77.130) 1115.99 ms 1295.38 ms 888.868 ms > 9 * rs0.internic.net (198.41.0.5) 799.857 ms 784.699 ms Looks like you need to find someone near bbnplanet.net for a route. > > I've tried to come up with na IPv6 address: > 5f00:f400:cf56:e200:21:40:3324:eb6c > using one of Digex ASNs (2548). Not sure whether this is correct > though. This reminds me... there's still a bug in that web page for creating the IPv6 address... if the ASN is >255 then the upper 8 bits are lost. The IPv6 address in this case should be 5f09:f400:cf56:e200:: (actually, it'd help a LOT if in the web page script, it did the ASN lookup itself... some people still don't know how to look it up.) Jeff Barrow, Internet Connections, Inc. (NETC-DOM) From ben@ibs-us.net Tue Jan 7 01:11:24 1997 From: ben@ibs-us.net (ben) Date: Mon, 6 Jan 1997 17:11:24 -0800 (PST) Subject: tunnel request In-Reply-To: Message-ID: > This reminds me... there's still a bug in that web page for creating the > IPv6 address... if the ASN is >255 then the upper 8 bits are lost. > The IPv6 address in this case should be 5f09:f400:cf56:e200:: > (actually, it'd help a LOT if in the web page script, it did the ASN > lookup itself... some people still don't know how to look it up.) This should be fixed now... sorry for the inconvenience. And thanks to those who identified the problem. This next question came up once or twice before, but I don't know that it was answered clearly enough for me to understand... What is the 'ASN' field? Is it my ASN, my IPv4 provider's ASN, my IPv6 provider's ASN, etc... If I could figure that out then I could probably figure out something to do auto-ASN lookups. Until then, just hit "ASN list" at the bottom of the form. Oh, and it's tablized now; http://www.ibs-us.net/ipv6 Sideways to the Sun, www.ibs-us.net/~ben 45.5183754N/-122.6750031W --Ben Kirkpatrick IBS 503.227.7010 fax 503.227.5778 page 503.229.3199 From dhaskin@baynetworks.com Tue Jan 7 03:26:08 1997 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Mon, 06 Jan 1997 22:26:08 -0500 Subject: a different proposal for ipv6 in bgp Message-ID: <2.2c.32.19970107032608.00ad1d80@pobox.corpeast.baynetworks.com> At 04:53 PM 1/6/97 -0800, Dave Katz wrote: >It remains unclear to me why it is desirable to couple multiprotocol >support and the AS number space increase. The two functions are >completely orthogonal and as far as I can tell there is no benefit for >*mandating* that the two changes be made at the same time. > >Clearly the multiprotocol stuff could be deployed and become useful >more quickly than the AS number extension, due to the fact that it >can be done in a backward compatible, pairwise fashion. > I don't believe that this assessment is accurate. The BGP5 proposal is as backward compatible (if not more) with BGP4 as the proposed multiprotocol extension to BGP4. I.e., v4 routing information exchanged between BGP5 peers can be fully re-advertised via BGP4 and vise versa. As you might notice we even didn't require to immediately extend AS number space for v4 to keep the v4 related changes to a bare minimum. To support v6, bgp data structures need to change any way and v6 has no backward compatibility issue at this point. Thus it only makes sense to get a larger AS space for v6 now to avoid another transition later. >The deployment considerations for multiprotocol support are far less >onerous than the AS number stuff. > Care elaborate (in light of the BGP5 proposal)? >Operators who are concerned about deploying new software twice could >always wait until BGP5 deployment and turn on both features at the >same time. However, I think that the deployment timing for each >feature is difficult to predict in advance (will IPv6 take off? Are >we really under pressure for AS numbers?) so keeping them decoupled >keeps things more flexible. > >So, what is it that makes it preferable to entwine the changes? > Once again, the way the BGP5 proposal written I don't believe this larger AS space for v6 introduces more implementation and/or deployment burdens than yours multiprotocol stuff does... unless I miss some vital points. My point is that there is no additional penalty for the introducing a larger AS number space for v6 now and, to boot, BGP5 provides an optional mechanism to gradually introduce a larger AS number space for v4 too. So why not? >--Dave Dimitry > > X-Phone: +1 703 812 3704 > Date: Mon, 30 Dec 1996 14:05:41 EST > From: "John W. Stewart III" > Sender: owner-idr@merit.edu > Precedence: bulk > > > attached below is a proposal for a multi-protocol (including > ipv6) bgp > > while there are a number of differences between this one and > the bates/chandra/katz/rekhter one, one of the main motivating > factors for this one is to support longer-than-two-byte ASs. > it is our view that making bgp multi-protocol significantly > extends its life. so, although in a narrow sense the length > of the AS is orthogonal to being multi-protocol, the logistics > of transitions and the need to adequeately engineer the > protocol up-front, to us, suggests the need for longer-than- > two-byte ASs > > /jws > > From Alain.Durand@imag.fr Tue Jan 7 10:23:32 1997 From: Alain.Durand@imag.fr (Alain Durand) Date: Tue, 7 Jan 1997 11:23:32 +0100 Subject: tunnel request In-Reply-To: ben "Re: tunnel request" (Jan 6, 5:11pm) References: Message-ID: <970107112332.ZM484@rama.imag.fr> On Jan 6, 5:11pm, ben wrote: > Subject: Re: tunnel request > This next question came up once or twice before, but I don't know that > it was answered clearly enough for me to understand... What is the 'ASN' > field? Is it my ASN, my IPv4 provider's ASN, my IPv6 provider's ASN, etc... This is something we discussed in San Jose meeting. RFC1897 says: This is the current autonomous system number assigned to the provider providing internet service to the an IPv6 testers organization. It is currently undestood as your IPv4 provider AS, but we'd like to change that to allow you to use your IPv6 provider AS number (i.e. your 6bone contact) if you like to. This might be very usefull if/when we'll try to reshape the 6-bone. - Alain. From jimmy.kyriannis@nyu.edu Tue Jan 7 22:49:01 1997 From: jimmy.kyriannis@nyu.edu (Jimmy Kyriannis) Date: Tue, 7 Jan 1997 17:49:01 -0500 Subject: tunnel request In-Reply-To: <970107112332.ZM484@rama.imag.fr> References: ben "Re: tunnel request" (Jan 6, 5:11pm) Message-ID: At 5:23 AM -0500 1/7/97, Alain Durand wrote: >This is something we discussed in San Jose meeting. >RFC1897 says: > This is the current autonomous system number assigned to the > provider providing internet service to the an IPv6 testers > organization. > > >It is currently undestood as your IPv4 provider AS, but we'd like to change >that >to allow you to use your IPv6 provider AS number (i.e. your 6bone contact) >if you like to. This might be very usefull if/when we'll try to reshape >the 6-bone. > > - Alain. If reshaping the 6bone is emminent, to be more in line with the provider-based addressing hierarchy of IPv6, then it would seem that it's best to recommend that new connections use the AS numbers of their 6bone providers. As the 6bone grows, propagation of IPv4-based provider numbers now will mean more renumbering in the future - but, renumbering's not supposed to be a big deal under IPv6. :) Jimmy From RLFink@lbl.gov Tue Jan 7 23:29:52 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 7 Jan 1997 15:29:52 -0800 Subject: tshirt info Message-ID: Sorry to bother everyone about this, but I've been sent so much email asking about it I figured it best to send this to the whole list. My secretary is only getting to the Tshirt mailing this week as our Lab was closed for over two weeks over the holidays. Sorry for this delay. Don't feel obliged to send any checks until you receive your Tshirts, then send a US $ check made out to "Robert Fink", and mail it to: Robert Fink 3085 Buena Vista Way Berkeley CA 94708 USA And of course the amount was $10 US per Tshirt regardless of size, mailing included. Thanks, Bob From RLFink@lbl.gov Wed Jan 8 02:45:07 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 7 Jan 1997 18:45:07 -0800 Subject: tshirt info In-Reply-To: <9701071547.ZM2498@rennsport.nas.nasa.gov> References: Bob Fink LBNL "tshirt info" (Jan 7, 3:29pm) Message-ID: At 3:47 PM -0800 1/7/97, Andrew J. Hoag wrote: ... >Bob -- there was talk about doing a second order... Is this still an option? >I'm just looking for one more XXL ... Patience :-) Soon!! >I sent this just to you, but feel free to reply to the whole list. ;-) Bob From dhaskin@baynetworks.com Wed Jan 8 17:27:05 1997 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Wed, 8 Jan 1997 12:27:05 -0500 Subject: a different proposal for ipv6 in bgp Message-ID: <199701081727.MAA05844@pobox.engeast.BayNetworks.COM> Tony, > > Dimitry Haskin writes: > * At 04:53 PM 1/6/97 -0800, Dave Katz wrote: > * >It remains unclear to me why it is desirable to couple multiprotocol > * >support and the AS number space increase. The two functions are > * >completely orthogonal and as far as I can tell there is no benefit for > * >*mandating* that the two changes be made at the same time. > * > > * >Clearly the multiprotocol stuff could be deployed and become useful > * >more quickly than the AS number extension, due to the fact that it > * >can be done in a backward compatible, pairwise fashion. > * > > * I don't believe that this assessment is accurate. The BGP5 proposal > * is as backward compatible (if not more) with BGP4 as the proposed multiprot > * ocol > * extension to BGP4. I.e., v4 routing information exchanged between BGP5 > * peers can be fully re-advertised via BGP4 and vise versa. As you might not > * ice > * we even didn't require to immediately extend AS number space for v4 > * to keep the v4 related changes to a bare minimum. To support v6, bgp data > * structures need to change any way and v6 has no backward compatibility > * issue at this point. Thus it only makes sense to get a larger AS space for > * v6 now > * to avoid another transition later. > * > > Let's perhaps look at this a little differently. Since widespread > deployment of BGP4 and the hassle of transition from BGP3 (for those > of us who went through this, it was certainly not something to do more > than say a couple of times in your lifetime and in that case we were > driven by an immediate need) we have actually been able to add several > new attributes (communities, reflection, etc) to keep enhancing > inter-domain routing capabilities (all in use today) with very little > pain. We definitely not proposing a transition of the grand-scale of moving from the classfull to classless routing paradigm. I can assure you that what we're proposing is of a much smaller scale, practically no scale at all. And our intention was to make it even more extensible than BGP4. >The reason we've been able to do this is becuase we essentially > haven't messed with the underpinnings of the protocol itself. Neither did we. > The operational factors in doing this are much greater than perhaps many > folks realize (ISPs tell me different if you think I'm > overstating). In your proposal, before I can get benefit of the pain I > need to move I have the entrie Internet moved over to BGP5. This is definitely an overstatement. > I understand I can use it for multiprotocol on a pairwise basis > providing I dont touch the AS space but this doesn't seem like too > much of a win when I can add attributes to the exisiting BGP4 protocol > and start using BGP for multi-protocol interdomain support in an > understood and well-practiced operational way. This is a win because we don't have to drag 2-byte ASN into IPv6. There is enough discomfort with the 2-byte ASN to make me belive that dragging 2-byte ASN into v6 as a bad idea. And the most important it is _not_ necessary. Is it v6 that all this multiprotocol support is really about? And, if you want, you can use the option of gradually extending ASN for v4 too. For some, probably long, period simple mapping of zero-extended 4-byte ASN into 2-byte ASN used by BGP4 will ensure backward compatibility with BGP4. > > * >The deployment considerations for multiprotocol support are far less > * >onerous than the AS number stuff. > * > > * Care elaborate (in light of the BGP5 proposal)? > * > See above. See above. > > If you buy into my ease of deployment point above [and of course you > might not] let's look at where we are in terms of AS space as this is > other factor driving the current discussuion. Since I've started the > CIDR report I produce I've also been tracking the activity of ASes in the > global routing system as seen in BGP by a well connected router. The > interesting trend you see is the growth of ASes in the global routing > system is essentially linear. Whilst my data source is quite small (see > http://www.remplyees.org/~tbates/cidr.as.plot.html) this seems to be > growing at an average rate of 3 ASes per day. The linear growth if > further backed in "An analysis of Internet Inter-Domain Topology and > Route Stability" by Ramesh Govindan and Anoop Reddy from USC/ISI. > > If we use this growth rate and look at a couple of scenarios: > > Best Case > --------- > Assuming we have 65000 (not including Private ASes) ASes and > accounting for the 1937 ASes already in the system (this also assumes > we could re-use ones pre-allocated and not currently being used which > is probably over optimistic) we have 63063 ASes to play with resulting > in : > > 63063/3 = 21021 Days > 21021/365 = 57 Years before we run out. > > Worst Case > ---------- > > If we assume 15535 ASes will in fact be wasted (private space, > early/bad allocations before RFC1930, some ISPs getting as AS > for the wrong reason) we still end up with. > > (50000-1937)/3/365 = 43.8 years > > Now you could argue that this doesn't take into account the increasing > trend towards mutlihoming (not currently shown in the AS growth either > but anyway ;-)). However, there are a number of things to help with > this approach. > > 1. Improving use of private AS space. ISP router should be able to > override customer's AS with a preconfigured number. ISP router > shouldn't propagate a route to a customer router if the route includes > AS of the customer (this AS is preconfigured on the ISP router). > > 2. Use RIPv2 (instead of BGP) - doesn't require AS number at all. > > 3. Use single globally unique AS number (draft-stewart-bgp-without-as-00.txt) > None of that will be necessary for v6 if we use a larger ASN space there. > So with this in mind do we really want to tackle the AS number issue > right now at the risk of the operational impact ? You still didn't convince me that there is a significant operational impact with the BGP5 proposal. If you afraid to extend ASN for v4, we don't force you to do so. But we want a larger ASN space for v6. Would you agree that there is a zero operational impact for v6 at this point? If it not for v6 we, most probable, would be looking in extending BGP-4, don't we? > If the answer is yes > (which I must abmit seems hard to see from my viewpoint) then we > better make sure we look at all aspects before spinning the protocol > again wouldn't you agree ? > Sure. > --Tony Dimitry From jcday@jpd.ch.man.ac.uk Thu Jan 9 17:02:30 1997 From: jcday@jpd.ch.man.ac.uk (Jonathan Day) Date: Thu, 9 Jan 1997 17:02:30 +0000 (GMT) Subject: Sun IPv6 Message-ID: <199701091702.RAA05086@jpd.ch.man.ac.uk> Hi Sorry for mailing this here, but I was wondering if there was anyone using the Sun Solaris implementation of IPv6 for the Sparc who could help me - I am getting some rather bizare & invariably fatal boot errors (the IP module dies the moment it's loaded and takes the rest of the system with it). I'm wondering if there's something staggeringly obvious I'm overlooking. Jonathan From RLFink@lbl.gov Tue Jan 14 17:02:27 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 14 Jan 1997 09:02:27 -0800 Subject: last chance at the 6bone WG charter, goals and milestones Message-ID: 6bone Folk: I will need to submit the 6bone charter, goals and milestones to the area director(s) real soon now. I have not had a single comment from the mailer on the tentative one I submitted on 17 December. So...I would like to give you one more chance to modify it before I submit it. I have included my own rework of the goals and milestones I sent last month, mostly to clean it up for consistency in dates and work flow. I really need to know this isn't just my own pipe dream! Silence doesn't do it. Comments to the mailer please (unless you are beating me up that is :-) Thanks, Bob ===================== Goals and Milestones: Jan 97 / Establish and submit initial charter, goals, and first year Goals and Milestones (this list). Jan-Mar 97 / Discussion on topology, addressing and routing for a new 6bone infrastructure better suited to IPv6 testbed goals. Jan-Mar 97 / Discussion on the future of the RIPE-NCC 6bone routing registry and how it relates to the RPSL work. Jan-Dec 97 / Continuing interaction with, and feedback to, the IPng working groups at the IETF based on 6bone experience. Mar-Apr 97 / Begin work on an Internet-Draft outlining requirements for the new 6bone infrastructure. Apr 97 / Begin to restructure the 6bone testbed based on discussions. Jan-Feb 97 / Interact with RPS WG on extensions for "Representing Tunnels in RPSL" based on David Meyer's Internet-Draft. Apr 97 / Decide what direction to take with the RIPE-NCC 6bone routing registry. Aug 97 / Finish work on Internet-Draft outlining requirements for the new 6bone infrastructure. Sep 97 / Interact with MBONED on their work for co-existence strategies for IPv4 multicast and IPv6 multicast. (This based on the MBONED milestones.) Dec 97 / Begin work on a document describing operational practices and experiences for the 6bone. ========================================================================== Draft 6bone Charter as presented at the BOF The 6bone Working Group is a forum for information concerning the deployment, engineering, and operation of ipv6 protocols and procedures in the global Internet. This activity will include, but not be limited to: - Deployment of ipv6 transport and routing in the global Internet via a "6bone" testbed to assist in the following. - Creation of "practice and experience" informational RFC documents that capture the experiences of those who have deployed, and are deploying, various ipv6 technologies. - Feedback to various IETF ipv6-related activities, based on testbed experience, where appropriate. - Development of mechanisms and procedures to aid in the transition to native ipv6, where appropriate. - Development of mechanisms and procedures for sharing operational information to aid in operation of global ipv6 routing. - end From Alain.Durand@imag.fr Tue Jan 14 18:52:44 1997 From: Alain.Durand@imag.fr (Alain Durand) Date: Tue, 14 Jan 1997 19:52:44 +0100 (MET) Subject: last chance at the 6bone WG charter, goals and milestones Message-ID: <199701141852.TAA11722@rama.imag.fr> I'm OK with our goals. Just one question: do the milestones have to be so precisely timed? Shouldn't we focus on having some results for each IETF meeting? - Alain. From RLFink@lbl.gov Tue Jan 14 18:54:19 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 14 Jan 1997 10:54:19 -0800 Subject: last chance at the 6bone WG charter, goals and milestones In-Reply-To: <199701141852.TAA11722@rama.imag.fr> Message-ID: At 10:52 AM -0800 1/14/97, Alain Durand wrote: >I'm OK with our goals. Just one question: do the milestones have to be so >precisely timed? Shouldn't we focus on having some results for each IETF >meeting? Yes, I agree with you. We need to arrange to have useful things to focus on at the IETF. That's why I set the range of dates the way I did. However, any suggestions to make it better are appreciated. Thanks, Bob From crawdad@fnal.gov Tue Jan 14 19:57:51 1997 From: crawdad@fnal.gov (Matt Crawford) Date: Tue, 14 Jan 1997 13:57:51 -0600 Subject: last chance at the 6bone WG charter, goals and milestones In-Reply-To: "14 Jan 1997 09:02:27 PST." <"v03007805af015d94d515"@[128.3.9.22]> Message-ID: <199701141957.NAA24465@gungnir.fnal.gov> Looks fine, Bob. Matt From Ivano.Guardini@cselt.stet.it Wed Jan 15 08:12:00 1997 From: Ivano.Guardini@cselt.stet.it (Guardini Ivano) Date: Wed, 15 Jan 1997 09:12:00 +0100 Subject: New tunnel from CSELT Message-ID: Hi, there is one new tunnel between CSELT and SICS. CSELT <-----> SICS I have updated CSELT RIPE database entry: site: CSELT (Centro Studi E Laboratori Telecomunicazioni) location: Torino, ITALY loc-string: 45 03 52.2n 07 39 43.2e 250m prefix: 5f16:4d00::/32 ping: 5f16:4d00:a3a2:1100:11:800:2071:d812 tunnel: 163.162.17.77 129.88.26.1 G6 tunnel: 163.162.17.77 193.10.66.50 SICS tunnel: 163.162.17.77 130.192.26.254 POLITO tunnel: 163.162.252.4 131.175.5.37 CEFRIEL contact: Ivano Guardini status: operational since December 4, 1996 remark: Sun SPARC STATION 20, IPv6 for Solaris 2.5 changed: ivano.guardini@cselt.stet.it 19970114 source: RIPE Here is ping from CSELT to SICS: root@carmen_atm:/usr/ipv6/sbin#>./ping -s sics-v6 100 8 PING sics-v6: 100 data bytes 148 bytes from 5f0b:1700:c10a:4200:0:800:978:196d: icmp_seq=0. time=231 ms 148 bytes from 5f0b:1700:c10a:4200:0:800:978:196d: icmp_seq=1. time=251 ms 148 bytes from 5f0b:1700:c10a:4200:0:800:978:196d: icmp_seq=2. time=259 ms 148 bytes from 5f0b:1700:c10a:4200:0:800:978:196d: icmp_seq=3. time=168 ms 148 bytes from 5f0b:1700:c10a:4200:0:800:978:196d: icmp_seq=4. time=204 ms 148 bytes from 5f0b:1700:c10a:4200:0:800:978:196d: icmp_seq=5. time=307 ms 148 bytes from 5f0b:1700:c10a:4200:0:800:978:196d: icmp_seq=6. time=176 ms 148 bytes from 5f0b:1700:c10a:4200:0:800:978:196d: icmp_seq=7. time=279 ms ----sics-v6 PING Statistics---- 8 packets transmitted, 8 packets received, 0% packet loss round-trip (ms) min/avg/max = 168/234/307 Bye Ivano --------------------------------------------------- Ivano Guardini CSELT SpA via G. Reiss Romoli 274 Torino (Italy) Tel. +39 11 228 5424 Fax. +39 11 228 5069 --------------------------------------------------- From Bertrand.Buclin@att.ch Wed Jan 15 09:14:53 1997 From: Bertrand.Buclin@att.ch (Bertrand Buclin) Date: Wed, 15 Jan 1997 10:14:53 +0100 Subject: New site joining: AT&T Labs Europe Message-ID: <01BC02CC.F46E8940@nb-bbuclin.ch.att.com> Hi, AT&T Labs Europe is now connected to 6-bone. We've set up our tunnel to = Digital in Sophia-Antipolis (thanks Bob). We still have some routing = issues due to incompatibilities between the tunnel software at the = tunnel ends. This should get solved in a couple of weeks from now, when = we'll use a Digital RouteAbout to connect, instead of the Sun IPv6 = stack. I can't give yet a ping result because of the above routing issues (we = have only erratic connectivity...). Cheers, Bertrand site: AT&T Labs Europe location: AT&T Labs Europe, Geneva, Switzerland loc-string: 46 13 30n 6 6 0e 365m prefix: 5F15:F700::/32 ping: 5f15:f700:c2f2:4400:100:800:2076:5215 server-2.labs.att.ch tunnel: 194.242.68.68 193.56.15.54 DIGITAL-ETC contact: bertrand.buclin@att.ch=20 contact: BB13-RIPE status: operational since 23-Dec-1996 remark: Sun Solaris IPv6 V5 changed: bertrand.buclin@att.ch 961223 source: RIPE From bound@zk3.dec.com Wed Jan 15 14:02:16 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 15 Jan 97 09:02:16 -0500 Subject: last chance at the 6bone WG charter, goals and milestones In-Reply-To: Your message of "Tue, 14 Jan 97 09:02:27 PST." Message-ID: <9701151402.AA26750@wasted.zk3.dec.com> Bob, Silence on my part anyway was I think you got it right. Should have acked you. p.s. we do need a way a.s.a.p. to add all the nodes added since the last update of the map...It shows the IETF and market how fast this is growing. Which I think is important.....to IPv6 momentum. thanks /jim From RLFink@lbl.gov Thu Jan 16 14:57:38 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 16 Jan 1997 06:57:38 -0800 Subject: last chance at the 6bone WG charter, goals and milestones In-Reply-To: <9701151402.AA26750@wasted.zk3.dec.com> References: Your message of "Tue, 14 Jan 97 09:02:27 PST." Message-ID: Jim, At 6:02 AM -0800 1/15/97, bound@ZK3.DEC.COM wrote: ... >Silence on my part anyway was I think you got it right. Thanks. >p.s. we do need a way a.s.a.p. to add all the nodes added since the last >update of the map...It shows the IETF and market how fast this is >growing. Which I think is important.....to IPv6 momentum. I'm close to done with a redraw which I think does the stuff you want, but will be controversial given the way I'm choosing to draw the info and decisions I'm making. But I'll post it to the web site and send email to the list today or tomorrow so you can see it and comment. Thanks, Bob From RLFink@lbl.gov Thu Jan 16 17:43:27 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 16 Jan 1997 09:43:27 -0800 Subject: a new 6bone diagram Message-ID: I've finished my draft attempt at a new 6bone diagram. But before you rush off to look, let me tell you what the rationale for it is. I've recognized that this is a "sales" diagram as much as it is useful info. But there is a limit on what I can and should represent with it. So I have chosen to show only a primary connection from a site to the 6bone. Thus in some (many) cases I've had to guess what a sites primary path is, and you will need to help me get it right. At least this way the site gets to appear on a diagram and I can rationally draw it! Also, I've attempted to start the topology discussion by using Alain Durand's three level hierarchy to express the topology: core backbone routers, second tier transit routers and leaf routers (for node sites not doing transit). Last, I've specifically NOT shown interconnectivity of the "core backbone routers" as it changes, is too messy to draw, and doesn't tell people what they need to know. So for what it's worth, here it is. http://www-6bone.lbl.gov/6bone/6bone-newdrawing.GIF After a few days of comments, and we decide to use it, I'll add in the hot buttons to the RIPE-NCC entries on the names, and replace the current (now out of date) diagram on the 6bone web pages. So...please look and comment. Thanks, Bob From watson@ulysse.enet.dec.com Fri Jan 17 17:20:01 1997 From: watson@ulysse.enet.dec.com (Robert Watson) Date: Fri, 17 Jan 97 17:20:01 MET Subject: a new 6bone diagram Message-ID: <199701171608.RAA06379@vbormc.vbo.dec.com> Hi Bob > I've recognized that this is a "sales" diagram as much as it is useful > info. But there is a limit on what I can and should represent with it. As a "sales diagram" for IPv6 this map down plays the size of the 6bone, but I don't see how it could continue to grow as it was. So maybe it's time to split it into regions (e.g. Americas, Europe/Afria, Asia Pacific etc) which will give new-comers a better impression of the world-wide interest in IPV6 (not just a US concern) and will help joining-sites to locate a suitable second tier transit router to connect to. This might also allow more detail to be added to the core <-> Second level connectivity (which will help with problem solving) and support the three-tier structure Alain was proposing. Bob Robert (Bob) Watson Robert.Watson@vbe.mts.dec.com DIGITAL Equipment Corporation +33 (0)4.9295.9542 Centre Technique Europe, Sophia Antipolis France From RLFink@lbl.gov Fri Jan 17 17:19:50 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 17 Jan 1997 09:19:50 -0800 Subject: a new 6bone diagram In-Reply-To: <199701171608.RAA06379@vbormc.vbo.dec.com> Message-ID: Robert, At 8:20 AM -0800 1/17/97, Robert Watson wrote: .. >> I've recognized that this is a "sales" diagram as much as it is useful >> info. But there is a limit on what I can and should represent with it. > > As a "sales diagram" for IPv6 this map down plays the size > of the 6bone, but I don't see how it could continue to grow as it was. > > So maybe it's time to split it into regions (e.g. Americas, > Europe/Afria, Asia Pacific etc) which will give new-comers a better > impression of the world-wide interest in IPV6 (not just a US concern) > and will help joining-sites to locate a suitable second tier transit > router to connect to. > > This might also allow more detail to be added to the > core <-> Second level connectivity (which will help with problem > solving) and support the three-tier structure Alain was proposing. Thanks for the comments. I believe that we need to have much discussion on the topology/routing/addressing of the 6bone and that the map will follow this discussion. In the interim, I want to keep to a single page diagram as long as possible for simplicity sake. Unfortunately, at this time, there are many out of region 6bone connections that would be hard to diagram in a regionally based picture. For example, Korea, Taiwan, Singapore and other non-US locations are source out of NRL and Cisco. Though maybe I can be creative with some map background pointer stuff - will think about it. It may be we should also have some other mechanism to show folk about hooking up and how international we are, i.e., other pages than this. Oh, almost forgot, the NASA VRML-based pics already show the international flavor by way of their regional and world globe pictures. At any rate, I do need to get a picture up soon that reflects current state of the 6bone. I've received various positive comments about this form of diagram, so will put it up in replacement of the out of date one early next week. Thanks, Bob From RLFink@lbl.gov Fri Jan 17 17:48:55 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 17 Jan 1997 09:48:55 -0800 Subject: (IPng 2899) multiple 6bones - 6bone preference routing.... In-Reply-To: <1207.853492817@cs.ucl.ac.uk> Message-ID: Jon, At 1:20 AM -0800 1/17/97, Jon Crowcroft wrote: >we just have started discussing a 6bone pilot in the UK academic >network, and we had a nice presentation from some guys from Denmark >(Martin Peck i think from telebit....) on their trial and >implementation work, and the following question came up > >if we run multiple 6bone pilots with global connectivity, with >multiple ipv4 legacy paths between them, can we _choose_ ingress and >efgress to ipv4 and ipv6 clouds (i.e. is anyone doing BGP+ or BGP5 or >whatever, path preference paramaters that allow an IPv4 net to export >route choices that reflect IPv6 source and sink cloud >requirements....? Don't think we have other than static routes, RIPng and IDRPv6 between various sites at this time. I believe we are waiting on the outcome of the Katz/Haskin et al BGP4 v6 extensions versus IDRPv6 discussions before BGP comes into real use. As far as ingress/egress to the existing 6bone, my opinion is that you should connect as a "core backbone" site and establish connectivity and peering with other backbone sites as you think it makes sense (it is all still v6 over v4 tunnels). That is, at the moment, choice of interconnect is pretty wide open. I have included my newest diagram of the 6bone which may be of use to you: http://www-6bone.lbl.gov/6bone/6bone-newdrawing.GIF >sorry if that isn't a clear expression of the requirement, but >i'm not up to speed on SIP stuff.... Hope you guys hook up - it will be a great addition to the 6bone testbed! Thanks, Bob From dewell@woods.net Mon Jan 20 01:01:50 1997 From: dewell@woods.net (Aaron Dewell) Date: Sun, 19 Jan 1997 16:01:50 -0900 (AKST) Subject: tunnel request Message-ID: [sent before from dewell@shirley.alaska.net - but dissapeared.] I'd like to get a tunnel from someone nearby.. Internet Alaska is multi-homed through UUnet (seattle), AT&T Alascom (->sprint - chicago), and AGIS/net99 (seattle). IP address of this end: middle.ip6.alaska.net 5f16:8b00:ce95:4e00:3:0:100:5855 206.149.78.19 I presume the route to me would be 5f16:8b00::/32. Thank you to whomever. P.S. I'd prolly need the group password thingy too, to update the RIPE db when it happens. ---------------------------------------------------------------------- Aaron Dewell Sysadmin at Large dewell@alaska.net dewell@woods.net dewell@eng.utah.edu From qv@sparky.iol.unh.edu Tue Jan 21 16:08:05 1997 From: qv@sparky.iol.unh.edu (Quaizar Vohra) Date: Tue, 21 Jan 1997 11:08:05 -0500 Subject: Another IPv6 Implementation. Message-ID: <199701211608.LAA02984@sparky.IOL.UNH.EDU> Hi, We at the University of New Hampshire would like to announce another Public Domain Implementation for IPv6. It was started with an aim to develop a 64 bit implementation for the public domain. It has several significant differences from existing IPv6 implementations. It has been developed on NetBSD 1.2 running on Digital Alpha 64 bit processor. It might also run over 32 bit architectures (though I have not tested this, but it should not be a big problem). I have tested the implementation using the UNH InterOperabilty Labs. test suite and it interoperates with other implementations. The code base is accessible at : ftp://sun4.iol.unh.edu/pub/ipv6 The packages can be accesses in gzipped or compressed form. unh-ipv6-kit-0.0.tar.gz (for gunzip) unh-ipv6-kit-0.0.tar.Z (for uncompress) Some documentation is provided in the README and NOTES file about the installation procedure and about features supported by this implementation. Public Domain DHCPv6 code has also been written for this code base by Yunzhou Li. This was announced a couple of weeks back. If you have questions, suggestions etc., contact me at : qv@sun4.iol.unh.edu For discussion of this implementation and associated problems, use the IPv6 implementors list at : ipv6imp@munnari.oz.au You can subscribe to it by sending a mail to : ipv6imp-request@munnari.oz.au The release has a postscript file which has discusses this implementation. It is unh-ipv6-proj.ps I am very grateful to a bunch of people for this, who are : Bill Lenharth at InterOperability Lab. (UNH) Jim Bound (Digital Equipment Corp.) Prof. Robert D. Russell (UNH) Yunzhou Li (NUS) Digital Alpha DUNIX IPv6 Team A special thanks goes to the NetBSD community and IETF. Sincerely, Quaizar ------------------------------------------------------------------------ Quaizar Vohra InterOperabilty Lab. (UNH) (603)-862-0090 qv@sun4.iol.unh.edu From Dorian R. Kim" CICNet has connected to 6bone. We've set up tunnels to CISCO, NRL and UOregon today. Many thanks to Ran, Ron and Dave. Routing is being done with RIPng to all three sites, and we are using a cisco. site: CICNet primary AS location: Downers Grove, Illinois , USA prefix: 5F04:C900::/32 ping: 5F04:C900:8367:0100:0001::0C8E:50C2 6bone.chicago.cic.net tunnel: 131.103.1.54 192.31.7.104 CISCO - RIPng - operational tunnel: 131.103.1.54 132.250.90.3 NRL - RIPng - operational tunnel: 131.103.1.54 128.223.222.11 UOregon - RIPng - operational contact: Dorian Kim contact: CICNet Network Systems status: operational since 1/21/97 remark: 6bone.chicago.cic.net is a transit only tunnel fanout box ermark: 6bone.chicago.cic.net is a cisco 2501 remark: happy to add new tunnels upon request. remark: please report any problems to contact above. changed: dorian@cic.net 970121 source: RIPE Here's ping results from 6bone.chicago.cic.net to 6bone-router.cisco.com 6bone#ping ipv6 5f00:6d00:c01f:0700:0001:0060:3e11:6770 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5F00:6D00:C01F:0700:0001:0060:3E11:6770, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 112/116/120 ms Here's one to NRL 6bone#ping ipv6 5F00:3000:84FA:5A00::0003 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5F00:3000:84FA:5A00::0003, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/43/44 ms -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Street Senior Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From RLFink@lbl.gov Wed Jan 22 02:55:20 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 21 Jan 1997 18:55:20 -0800 Subject: new 6bone web page stuff Message-ID: various changes: 1. new 6bone diagram is up - PLEASE TELL ME WHERE THE ERRORS ARE! 2. a tool page with the G6 route tool and Ben Kirkpatrick's v6 address generation tool. 3. San Jose 6bone minutes now accessible on minutes web page. 4. 6bone WG charter now accessiable on the "What is the 6bone" page. Thanks, Bob From Ivano.Guardini@cselt.stet.it Wed Jan 22 10:53:26 1997 From: Ivano.Guardini@cselt.stet.it (Guardini Ivano) Date: Wed, 22 Jan 1997 11:53:26 +0100 Subject: New tunnel from CSELT Message-ID: Hi, there is one new tunnel between CSELT and ESNET. CSELT <-----> ESNET I have updated CSELT RIPE database entry: site: CSELT (Centro Studi E Laboratori Telecomunicazioni) location: Torino, ITALY loc-string: 45 03 52.2n 07 39 43.2e 250m prefix: 5f16:4d00::/32 ping: 5f16:4d00:a3a2:1100:11:800:2071:d812 tunnel: 163.162.17.77 129.88.26.1 G6 tunnel: 163.162.17.77 193.10.66.50 SICS tunnel: 163.162.17.77 198.128.2.27 ESNET tunnel: 163.162.17.77 130.192.26.254 POLITO tunnel: 163.162.252.4 131.175.5.37 CEFRIEL contact: Ivano Guardini status: operational since December 4, 1996 remark: Sun SPARC STATION 20, IPv6 for Solaris 2.5 changed: ivano.guardini@cselt.stet.it 19970122 source: RIPE Here is ping from CSELT to ESNET: root@carmen:/usr/ipv6/sbin#>./ping -s esnet-v6 PING esnet-v6: 56 data bytes 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=0. time=489 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=1. time=448 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=2. time=446 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=3. time=469 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=4. time=483 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=5. time=425 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=6. time=448 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=7. time=420 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=8. time=424 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=9. time=442 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=10. time=495 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=11. time=465 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=12. time=483 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=13. time=505 ms 104 bytes from 5f01:2500:c680:200:0:800:2bbc:f1ec: icmp_seq=14. time=407 ms ----esnet-v6 PING Statistics---- 15 packets transmitted, 15 packets received, 0% packet loss round-trip (ms) min/avg/max = 407/456/505 Bye Ivano --------------------------------------------------- Ivano Guardini CSELT SpA via G. Reiss Romoli 274 Torino (Italy) Tel. +39 11 228 5424 Fax. +39 11 228 5069 e-mail: ivano.guardini@cselt.stet.it --------------------------------------------------- From Ivano.Guardini@cselt.stet.it Wed Jan 22 13:49:45 1997 From: Ivano.Guardini@cselt.stet.it (Guardini Ivano) Date: Wed, 22 Jan 1997 14:49:45 +0100 Subject: Routing toward CSELT/IT Message-ID: Hi, I'm Ivano Guardini from CSELT/IT. Now CSELT has three tunnels with three 6Bone backbone sites: CSELT <----------------> G6 <----------------> SICS <----------------> ESNET We use these tunnels (and not the tunnel with POLITO) for the routing of the 6Bone traffic. We also have other tunnels with other italian 6Bone sites (POLITO/IT and CEFRIEL/IT) but we route through these tunnels only the italian 6Bone traffic (I mean that we route through the tunnel between CSELT and POLITO only the 6Bone traffic with a destination inside POLITO and through the tunnel between CSELT and CEFRIEL only the 6Bone traffic with a destination inside CEFRIEL). I observed that I receive the reply to most of my ICMP Echo Requests from the tunnel with POLITO. This is not the best path! Please route all the traffic toward CSELT through G6, ESNET or SICS!!!! Bye Ivano --------------------------------------------------- Ivano Guardini CSELT SpA via G. Reiss Romoli 274 Torino (Italy) Tel. +39 11 228 5424 Fax. +39 11 228 5069 e-mail: ivano.guardini@cselt.stet.it --------------------------------------------------- From Wei.Li@mars.process.com Wed Jan 22 16:21:26 1997 From: Wei.Li@mars.process.com (Li, Wei) Date: Wed, 22 Jan 1997 11:21:26 -0500 Subject: new tunnel from Process Software Corpora Message-ID: <1997Jan22.104700.1063.642901@mars.process.com> Process Software has connected to 6bone via Digital-CA. Many thanks to Stephan Stuart at Network Systems Laboratory, Digital Equipment Corporation. I have updated PSC RIPE database entry: site: Process Software Corporation location: 959 Concord Street, Framingham, MA 01701 loc-string: 42 18 20n 71 25 0w 30m prefix: 5F02:3000:C673:8E00::/80 ping: 5F02:3000:C673:8E00::800:2BE2:844F tunnel: 198.115.142.134 204.123.2.236 DIGITAL-CA/US tunnel-v4: friar.process.com (198.115.142.134) contact: David Low status: operational remark: please report any problems to contact above changed: Wei Li 19970120 source: RIPE Here is ping from PSC to Digital/CA borachio# ./ping 5f00:2100:cc7b:0:12:800:2be4:b5cc PING 5f00:2100:cc7b:0:12:800:2be4:b5cc (5f00:2100:cc7b:0:12:800:2be4:b5cc): 56 d ata bytes 64 bytes from 5f00:2100:cc7b:0:12:800:2be4:b5cc: icmp_seq=0 ttl=63 time=154.821 ms 64 bytes from 5f00:2100:cc7b:0:12:800:2be4:b5cc: icmp_seq=1 ttl=63 time=148.313 ms 64 bytes from 5f00:2100:cc7b:0:12:800:2be4:b5cc: icmp_seq=2 ttl=63 time=227.099 ms 64 bytes from 5f00:2100:cc7b:0:12:800:2be4:b5cc: icmp_seq=3 ttl=63 time=104.503 ms 64 bytes from 5f00:2100:cc7b:0:12:800:2be4:b5cc: icmp_seq=4 ttl=63 time=123.221 ms ^C --- 5f00:2100:cc7b:0:12:800:2be4:b5cc ping statistics --- 6 packets transmitted, 5 packets received, 16% packet loss round-trip min/avg/max = 104.503/151.591/227.099 ms ping from PSC to UNH: borachio# ./ping 5f02:3000:84b1:7600::800:912:241a PING 5f02:3000:84b1:7600::800:912:241a (5f02:3000:84b1:7600:0:800:912:241a): 56 data bytes 64 bytes from 5f02:3000:84b1:7600:0:800:912:241a: icmp_seq=0 ttl=252 time=282.70 2 ms 64 bytes from 5f02:3000:84b1:7600:0:800:912:241a: icmp_seq=1 ttl=252 time=240.72 1 ms 64 bytes from 5f02:3000:84b1:7600:0:800:912:241a: icmp_seq=3 ttl=252 time=153.77 ms 64 bytes from 5f02:3000:84b1:7600:0:800:912:241a: icmp_seq=4 ttl=252 time=115.24 3 ms 64 bytes from 5f02:3000:84b1:7600:0:800:912:241a: icmp_seq=5 ttl=252 time=109.07 3 ms ^C --- 5f02:3000:84b1:7600::800:912:241a ping statistics --- 6 packets transmitted, 5 packets received, 16% packet loss round-trip min/avg/max = 109.073/180.301/282.702 ms /wei From dhaskin@baynetworks.com Wed Jan 22 21:09:48 1997 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Wed, 22 Jan 1997 16:09:48 -0500 Subject: new tunnel Message-ID: <199701222109.QAA26428@pobox.engeast.BayNetworks.COM> Hi, There is a new 6bone tunnel between a Bay Networks' router in Massachusetts and a Bay's router in Santa Clara, California: Site: Bay Networks - CA, USA location: Santa Clara, California, USA prefix: 5F02:3000:C020:AE00:B180::/80 ping: 5F02:3000:C020:AE00:B180::0001 ping: 5F02:3000:C020:AE00:B180:0000:86B1:804B tunnel: 134.177.128.75 192.32.29.62 BAY-MA, USA, RIPng contact: Demetrios Coulis status: operational since January 1997 remark: platform: ASN 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 970120 source: RIPE ------------------------------------------ ping -ip6 5F02:3000:C020:AE00:B180::0001 -v -r5 16 bytes from (5F02:3000:C020:AE00:B180::0001) via If 4: icmp_seq=0, time= 101 ms 16 bytes from (5F02:3000:C020:AE00:B180::0001) via If 4: icmp_seq=1, time= 93 ms 16 bytes from (5F02:3000:C020:AE00:B180::0001) via If 4: icmp_seq=2, time= 1 ms 16 bytes from (5F02:3000:C020:AE00:B180::0001) via If 4: icmp_seq=3, time= 93 ms 16 bytes from (5F02:3000:C020:AE00:B180::0001) via If 4: icmp_seq=4, time= 93 ms ---- IPV6 PING Statistics---- IPV6 ping: [5F02:3000:C020:AE00:B180::0001] responded to 5 out of 5: 100% success. round-trip (ms) min/avg/max = 1/76/101 Dimitry From Dorian R. Kim" Merit In-Reply-To: Message-ID: There is now a tunnel between CICNet and Merit. Updated RR entry: site: CICNet primary AS location: Downers Grove, Illinois , USA prefix: 5F04:C900::/32 ping: 5F04:C900:8367:0100:0001::0C8E:50C2 6bone.chicago.cic.net tunnel: 131.103.1.54 192.31.7.104 CISCO - RIPng - operational tunnel: 131.103.1.54 132.250.90.3 NRL - RIPng - operational tunnel: 131.103.1.54 128.223.222.11 UOregon - RIPng - operational tunnel: 131.103.1.54 198.108.60.153 MERIT - RIPng - operational contact: Dorian Kim contact: CICNet Network Systems status: operational since 1/21/97 remark: 6bone.chicago.cic.net is a transit only tunnel fanout box ermark: 6bone.chicago.cic.net is a cisco 2501 remark: happy to add new tunnels upon request. remark: please report any problems to contact above. changed: dorian@cic.net 970122 source: RIPE ping results: 6bone#ping ipv6 merit Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5F00:ED00:C66C:3C00::0153, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/99/164 ms 6bone#traceroute ipv6 merit Type escape sequence to abort. Tracing the route to merit (5F00:ED00:C66C:3C00::0153) 1 merit (5F00:ED00:C66C:3C00::0153) 40 msec 40 msec 36 msec -dorian From CHIUP@itg.viacom.com Thu Jan 23 01:27:00 1997 From: CHIUP@itg.viacom.com (Chiu, Phil) Date: Wed, 22 Jan 97 17:27:00 PST Subject: 6bone attachment Message-ID: <32E6C42F@SMTPGATE3.VIACOM.COM> I am from Viacom International and we use UUNET as the ISP. Currently they do not have any plans for 6bone. Is there someone who uses UUNET but also has 6bone connectivity? Who's tunnel are you using and how are you getting there? Also, I reside in NYC. Thanks. From rja@cisco.com Wed Jan 22 23:28:25 1997 From: rja@cisco.com (Ran Atkinson) Date: Wed, 22 Jan 1997 15:28:25 PST Subject: Changes at CISCO's 6bone-router Message-ID: <199701222328.PAA28562@cornpuffs.cisco.com> There have been various changes at cisco's 6bone-router recently. This note summarises these to the list. Cisco's RIPE database entry was just updated accordingly. MERIT has moved their IPv6 tunnel from CISCO to CICnet in order to cleanup the 6bone topology a bit now that CICnet is up and running. Both MERIT and CICnet are located in Ann Arbor and their internal connectivity is much shorter than the prior MERIT--CISCO path. Similarly, SUMITOMO-US will be relocating their tunnel from CISCO to DIGITAL-CA in the near future because DIGITAL-CA is fewer hops and because DIGITAL-CA is already the upstream node from SUMITOMO-JP. This also will tend to clean up the 6bone topology a bit. The tunnel between G6 and CISCO has never worked well and has always had very high rates of packet loss (possibly related to congestion on the US--France IP links). Hence that tunnel's prior designation as "experimental". The CISCO-G6 tunnel has now been taken down and no longer exists. The preferred path between CISCO and G6 is to transit NRL, based on experimental measurements indicating that path works very reliably and with a fine RTT. Over the past couple of months I have observed that some of the RIPng updates received by CISCO have contained advertisements that were incorrect and tended to cause routing loops. While there are many ways that routing loops might occur, one common issue might be related to redistributing local static routes into RIPng for sites that are more than one hop away. I would like to encourage each site running RIPng or IDRP or any other routing protocol to double-check their configuration to make sure that they aren't initiating (as different from the usual retransmission of received advertisements) advertisements for nodes that they can't actually reach or that are more than one hop away. One could postulate that some of the connectivity issues shown on the various 6bone statistics web pages might be due to routing loops of one sort or another. I would also like to encourage folks to give thought to how the 6bone topology might be cleaned up in their neck of the woods. Dorian has observed that it would be nice if the 6bone topology reflected the underlying IPv4 topology. I concur with this assessment. Ran rja@cisco.com -- From Alain.Durand@imag.fr Thu Jan 23 18:44:07 1997 From: Alain.Durand@imag.fr (Alain Durand) Date: Thu, 23 Jan 1997 19:44:07 +0100 Subject: G6, new topology & routing policy Message-ID: <970123194407.ZM3216@rama.imag.fr> Hi. I have change the topology of my IPv6 testbed and or routing policy. I hope this might help the discussion on the restructuration of the 6-bone. We are now using two routers as tunnel entry points One is our regular sun (6bone-gw.ipv6.imag.fr/129.88.26.1) with netbsd/inria code. The other one is a digital router (6bone-core.ipv6.imag.fr/129.88.26.2). The goal is to somehow split core routing from leaf access. In the migration process, 6bone-gw will be use for regular, non-RIPng tunnels and 6bone-core will be used for RIPng ones. 6bone-core will advertize routes for sites I have direct non-RIPng tunnels to via 6bone-gw. I hope this 2 routers scheme will help me to select the routes I want to advertize with RIPng. Just to fuel the discussion, here are some details about G6 tunnels. Non rip-ng tunnels readvertized through RIPng via 6bone-core: WIDE/jp, UNI-C/dk, UL/pt, UNH/us, JOGUNET/de, SICS/se, COSY/at , ERA/se, NRL/us, SUMITOM/jp and CSELT/it RIPng tunnels: BAY/us, DIGITAL-ETC/fr, DIGITAL-CA/us & DIGITAL-BE/be Some non RIPng tunnels will be replaced shortly by core RIPng ones. If we reorganize the 6-bone in a geographical approach, I realize I should not annouce some sites and maybe I should dig some new tunnels with other european sites. I would like to get some comments: is a geographical approach a good thing? will it (or should it) map the underlaying IPv4 networks? I think this is an important point in this discussion. - Alain. From dorian@cic.net Thu Jan 23 20:03:17 1997 From: dorian@cic.net (Dorian R. Kim) Date: Thu, 23 Jan 1997 15:03:17 -0500 (EST) Subject: request Message-ID: It looks like some sites around 6bone hasn't discovered our existance yet. Could folks that this apply to add a route to 5F04:C900::/32? Here's topology info. tunnel: 131.103.1.54 192.31.7.104 CISCO - RIPng - operational tunnel: 131.103.1.54 132.250.90.3 NRL - RIPng - operational tunnel: 131.103.1.54 128.223.222.11 UOregon - RIPng - operational tunnel: 131.103.1.54 198.108.60.153 MERIT - RIPng - operational -dorian From dorian@cic.net Thu Jan 23 20:06:16 1997 From: dorian@cic.net (Dorian R. Kim) Date: Thu, 23 Jan 1997 15:06:16 -0500 (EST) Subject: G6, new topology & routing policy In-Reply-To: <970123194407.ZM3216@rama.imag.fr> Message-ID: On Thu, 23 Jan 1997, Alain Durand wrote: > I would like to get some comments: is a geographical approach a good thing? > will it (or should it) map the underlaying IPv4 networks? I personally think we should map it as closely as possible to underlaying IPv4 networks, modulo non-participants. Doing this probably heads off alot of headaches down the road. -dorian From Alain.Durand@imag.fr Fri Jan 24 18:33:46 1997 From: Alain.Durand@imag.fr (Alain Durand) Date: Fri, 24 Jan 1997 19:33:46 +0100 Subject: weird RIP prefix: 5f00::/16 Message-ID: <970124193347.ZM4686@rama.imag.fr> Hi I'm getting the prefix 5f00::/16 in a RIP announce. I do not understand this preffix. Is it a bug somewhere or do I miss something? Another question is: should a default route or a 5f00::/8 route be advertised by someone? If yes by who? I personnaly tend to think that such routes should not be advertised. opinions? - Alain. From junkins@nwnet.net Fri Jan 24 18:18:54 1997 From: junkins@nwnet.net (Doug Junkins) Date: Fri, 24 Jan 1997 10:18:54 -0800 (PST) Subject: G6, new topology & routing policy In-Reply-To: Message-ID: Dorian, I brought up our 6Bone site in December with just such a goal -- two of our customers are 6Bone participants with more interested in the 6Bone. We hope to provide a 6Bone infrastructure on top of our IPv4 network for our customers (and any others interested participants that are topologically close). Now if I could just get time to do it ;-). - Doug / Douglas A. Junkins | Network Engineering \ / Network Engineer | NorthWestNet \ \ junkins@nwnet.net | Bellevue, Washington, USA / \ (206)649-7419 | / On Thu, 23 Jan 1997, Dorian R. Kim wrote: > On Thu, 23 Jan 1997, Alain Durand wrote: > > > I would like to get some comments: is a geographical approach a good thing? > > will it (or should it) map the underlaying IPv4 networks? > > I personally think we should map it as closely as possible to underlaying IPv4 > networks, modulo non-participants. > > Doing this probably heads off alot of headaches down the road. > > -dorian > From dhaskin@baynetworks.com Fri Jan 24 19:31:21 1997 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Fri, 24 Jan 1997 14:31:21 -0500 Subject: weird RIP prefix: 5f00::/16 Message-ID: <199701241931.OAA22518@pobox.engeast.BayNetworks.COM> Alain, > > > I'm getting the prefix 5f00::/16 in a RIP announce. > I do not understand this preffix. Is it a bug somewhere > or do I miss something? > > Another question is: should a default route or a 5f00::/8 route > be advertised by someone? If yes by who? > I believe both prefixes, 5f00::/16 and 5f00::/8, were injected over an experimental tunnel to a bay router and propagated to other routers. They are not propagated any more. > I personnaly tend to think that such routes should not be advertised. > > opinions? > Agreed. > - Alain. > Dimitry From arlie@thepoint.net Fri Jan 24 19:59:18 1997 From: arlie@thepoint.net (Arlie Davis) Date: Fri, 24 Jan 1997 14:59:18 -0500 Subject: weird RIP prefix: 5f00::/16 Message-ID: I'm new to the 6BONE and to real-world deployment of IP6, so please take my question with a grain of salt. I've noticed in a lot of the traffic discussing routes on this list, that the length of the prefixes mentioned is quite small. Is this normal? Is this a good thing? If people are issued a /24 prefix under IPv6, it allocates proportionally as much as allocating /24 in IP4 address space. Is there something I don't understand, or are huge chunks of IP6 address space being thrown about? -- arlie >-----Original Message----- >From: Alain Durand [SMTP:Alain.Durand@imag.fr] >Sent: Friday, January 24, 1997 1:34 PM >To: 6bone@ISI.EDU >Subject: weird RIP prefix: 5f00::/16 > >Hi > >I'm getting the prefix 5f00::/16 in a RIP announce. >I do not understand this preffix. Is it a bug somewhere >or do I miss something? > >Another question is: should a default route or a 5f00::/8 route >be advertised by someone? If yes by who? > >I personnaly tend to think that such routes should not be advertised. > >opinions? > > - Alain. From dhaskin@baynetworks.com Fri Jan 24 20:00:38 1997 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Fri, 24 Jan 1997 15:00:38 -0500 Subject: loops Message-ID: <199701242000.PAA24786@pobox.engeast.BayNetworks.COM> qadams[1]>ping -ip6 5F02:AD00:C050:0D00:0001:0800:207F:049D -p 1 (If 1): [5F02:3000:84B1:7600:0000:0800:2B23:729E], time = 222 ms. 2 (If 1): [::129.88.26.1], time = 410 ms. 3 (If 12): [5F06:B500:8158:1A00:0000:0800:2BB9:F33D], time = 320 ms. 4 (If 1): [5F06:B500:8158:1A00:0000:0800:2075:24EA], time = 648 ms. 5 (If 12): [5F06:B500:8158:1A00:0000:0800:2BB9:F33D], time = 355 ms. 6 (If 1): [5F06:B500:8158:1A00:0000:0800:2075:24EA], time = 398 ms. 7 (If 12): [5F06:B500:8158:1A00:0000:0800:2BB9:F33D], time = 359 ms. 8 (If 1): [5F06:B500:8158:1A00:0000:0800:2075:24EA], time = 566 ms. 9 (If 12): [5F06:B500:8158:1A00:0000:0800:2BB9:F33D], time = 328 ms. qadams[1]>ping -ip6 5f00:3400:83b3:6000:3:800:207b:fbfb -p 1 (If 1): [5F02:3000:84B1:7600:0000:0800:2B23:729E], time = 164 ms. 2 (If 1): [::129.88.26.1], time = 613 ms. 3 (If 12): [5F06:B500:8158:1A00:0000:0800:2BB9:F33D], time = 374 ms. 4 (If 1): [5F06:B500:8158:1A00:0000:0800:2075:24EA], time = 433 ms. 5 (If 12): [5F06:B500:8158:1A00:0000:0800:2BB9:F33D], time = 324 ms. 6 (If 1): [5F06:B500:8158:1A00:0000:0800:2075:24EA], time = 507 ms. 7 (If 12): [5F06:B500:8158:1A00:0000:0800:2BB9:F33D], time = 332 ms. 8: * qadams[1]>ping -ip6 5F02:3000:C673:8E00::800:2BE2:844F -p 1: * 2 (If 1): [5F06:B500:8158:1A00:0000:0800:2075:24EA], time = 339 ms. 3: * 4 (If 1): [::129.88.26.1], time = 519 ms. 5 (If 1): [5F02:3000:84B1:7600:0000:0800:2B23:729E], time = 492 ms. 6 (If 1): [::129.88.26.1], time = 855 ms. 7 (If 1): [5F02:3000:84B1:7600:0000:0800:2B23:729E], time = 746 ms. 8: * 9 (If 1): [5F02:3000:84B1:7600:0000:0800:2B23:729E], time = 1117 ms. 10: * 11: * 12 (If 1): [::129.88.26.1], time = 2003 ms. From Marc.Blanchet@viagenie.qc.ca Fri Jan 24 20:21:14 1997 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Fri, 24 Jan 1997 15:21:14 -0500 Subject: G6, new topology & routing policy In-Reply-To: <970123194407.ZM3216@rama.imag.fr> Message-ID: At 19:44 +0100 23/01/97, Alain Durand wrote: > >If we reorganize the 6-bone in a geographical approach, I realize >I should not annouce some sites and maybe I should dig some new tunnels >with other european sites. > >I would like to get some comments: is a geographical approach a good thing? >will it (or should it) map the underlaying IPv4 networks? > >I think this is an important point in this discussion. > I'm new on this list. will be on the 6bone in the next few days. I've been involved in the mbone since a long time (as probably many of this list). I think that we should map to the underlaying ipv4 network. The best way, least headaches. Regards, Marc. ------------------------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca ViaGenie inc. | NIC: MB841 3107 ave. des hotels | radio: VA2-JAZ Ste-Foy, Quebec, Canada | G1W 4W5 | tel.: 418-656-9254 http://www.viagenie.qc.ca | fax.: 418-656-0183 ------------------------------------------------------------------------- Auteur du livre "TCP/IP simplifii", Editions Logiques,1997 ------------------------------------------------------------------------- From ganis@VNET.IBM.COM Fri Jan 24 20:08:30 1997 From: ganis@VNET.IBM.COM (Matthew R. Ganis (914) 684-4575) Date: Fri, 24 Jan 97 15:08:30 EST Subject: weird RIP prefix: 5f00::/16 Message-ID: <199701242155.AA16567@venera.isi.edu> "Alain Durand" writes: > >Another question is: should a default route or a 5f00::/8 route >be advertised by someone? If yes by who? > >I personnaly tend to think that such routes should not be advertised. > Well, I think a default route or a route of 5f00::/8 is perfectly valid from a backbone router to a leaf node (or whatever the final terminology is). I think it should be considered illegal for a leaf node to advertise a default (or 5f00::/8) back to the backbone. maybe i'm just stating the obvious, but I thought I'd put it out there. Matt Ganis. *********************************************************************** "The best way to get praise | Return Address: is to die" | IBM VNET: GANIS at RHQVM19 Italian Proverb | Internet: ganis@vnet.ibm.com | IPNET: ganis@bacchus.ims.advantis.com From mikenel@netcom.com Mon Jan 27 00:29:23 1997 From: mikenel@netcom.com (Michael Nelson) Date: Sun, 26 Jan 1997 19:29:23 -0500 Subject: 6BONE connection at MAE-EAST Message-ID: <01BC0BBF.3C2F8EA0@dreamland> I am looking to setup a 6BONE connection with someone who has good = connectivity to MAE-EAST (my provider is CAIS).=20 Also, I need to get access to the RIPE-NCC FTP directory so that I can = add an entry for my connection, how do I obtain the userid/password? Thanks, Mike. From RLFink@lbl.gov Mon Jan 27 01:52:08 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Sun, 26 Jan 1997 17:52:08 -0800 Subject: 6BONE connection at MAE-EAST In-Reply-To: <01BC0BBF.3C2F8EA0@dreamland> Message-ID: At 4:29 PM -0800 1/26/97, Michael Nelson wrote: >I am looking to setup a 6BONE connection with someone who has good >connectivity to MAE-EAST (my provider is CAIS). I'll wait for someone else on the list respond to this one. >Also, I need to get access to the RIPE-NCC FTP directory so that I can add >an entry for my connection, how do I obtain the userid/password? quote site group ip6rr quote site gpass 6bone Bob From mikenel@netcom.com Mon Jan 27 01:57:59 1997 From: mikenel@netcom.com (Michael Nelson) Date: Sun, 26 Jan 1997 17:57:59 -0800 (PST) Subject: 6BONE connection at MAE-EAST In-Reply-To: Message-ID: On Sun, 26 Jan 1997, Bob Fink LBNL wrote: > At 4:29 PM -0800 1/26/97, Michael Nelson wrote: > >I am looking to setup a 6BONE connection with someone who has good > >connectivity to MAE-EAST (my provider is CAIS). > > I'll wait for someone else on the list respond to this one. Someone responded privately. Thanks. > quote site group ip6rr > quote site gpass 6bone Thanks, Mike. From RLFink@lbl.gov Mon Jan 27 02:18:06 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Sun, 26 Jan 1997 18:18:06 -0800 Subject: changes to 6bone diagram Message-ID: 6bone diagram version 46: 1. BAY-CA/US tunneled from BAY/US 2. CICNET/US now a backbone site and primary for MERIT/US 3. CSELT/IT now a backbone site and primary for POLITO/IT 4. DIGITAL-CA/US now primary for SUMITOMO US and JP 5. Sites with partial or no tunnels built in RIPE-NCC registry shown under NOT COMPLETE list on diagram PSC/US INTERNET-ALASKA/US ESYS/CN EPFL/CH VIAGENIE/FR Sorry if I screwed anything up...just let me know. Remember I'm still trying to adapt this style of diagram to 6bone reality, so let me know when it makes no sense. Thanks, Bob From RLFink@lbl.gov Mon Jan 27 02:18:42 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Sun, 26 Jan 1997 18:18:42 -0800 Subject: a 6bone topology discussion In-Reply-To: Message-ID: The recent spurt of new tunnels and various email traffic about it make me want to comment on what I think we should be doing about the 6bone's topology and routing. Alain Durand has raised the question of whether we organize the 6bone's tunnels on a geographical basis or based on the underlaying IPv4 networks. Ran has also voiced concern for how routing information is passed on up the chain, thus propagating bad routes/loops...and has also expressed advocacy for a 6bone topology based on IPv4's. At this time everyone is simply deciding to connect to the 6bone via tunnels in what appears to me to be on a random basis. If we are to accomplish something of value as a testbed we should be organized and methodical about our goals, what we are testing, and how we go about it. Although I would like to say that we should adapt our topology entirely to IPv4's, at least for now, that is hard to do everywhere as we have many places where it is not possible. For example, it is clearly useful for some sites that are not ISPs (say Bay, Cisco, Digital, NRL) to provide a place to tunnel to for their own testing purposes, for their early customers and/or simply out of being a good Internet "neighbor"). I don't think we should discourage this for the sake of artificial IPv4 topology mapping. Yet we do want to avoid gratuitous topology that moves packets inefficiently. We also want sensible routing, and even useful testing of routing. Thus I would propose that we adopt the following: 1. Agree among us who the "core" backbone sites are, based on them either being an ISP (e.g., WIDE, JOIN, G6, ESnet, CICNet) or someone seriously committed to simulating one, at least for this phase of the 6bone (e.g., Bay, Cisco, Digital, NRL). 2. These core sites would then decide how to interconnect among themselves, i.e., tunnels and routing, based on what makes sense for performance and reliability, and maybe even for the sake of testing routing protocols as appropriate. 3. Identify intermediate backbone (transit) sites that can also serve to interconnect leaf/stub sites, but who may not wish the full responsibility or load of being a "core" backbone site. (This extra work may be heavier duty routing or policy enforcement.) 4. These transit sites would then decide how to connect with one, or two at the most, backbone sites based on agreement with those sites. 5. Leaf/stub sites would then request a tunnel of a transit or backbone site based on the IPv4 topology as much as possible. The goal would be to not traverse the world just to get across town (so to speak) if there is a practical choice just across town. 6. These leaf/stub sites would have only one, or two tunnels at most, to minimize complexity. The backbone/transit site(s) providing the tunnel support would enforce routing policy down to the leaf/stub, i.e., make sure the leaf/stub site understands the rules and disconnect the tunnel when there is a problem or violation of policy. 7. Leaf/stub sites don't set up tunnels among themselves, at least not without real announcement and discussion to the list of intent and purpose, and hopefully agreement from the list. I appreciate that the above might be a lot to swallow, but at least we should discuss what this might mean and decide to use it or develop a different model. If we don't, my concern is that we will have a poorly structured mess that won't be of any use as we move ahead to the next more difficult test phases of IPv6. We have come so far with the 6bone to not want to preserve and enhance it! Comments please - I just want to move ahead :-) Thanks, Bob From dth@lucent.com Mon Jan 27 16:37:56 1997 From: dth@lucent.com (Harrington, Dan) Date: Mon, 27 Jan 1997 11:37:56 -0500 Subject: weird RIP prefix: 5f00::/16 Message-ID: Arlie asked: > I've noticed in a lot of the traffic discussing routes on this list, > that the length of the prefixes mentioned is quite small. Is this > normal? Is this a good thing? In general, yes, short prefixes are good, in that they allow a large number of potential systems to be represented in a succinct manner. This is the basis of the CIDR model, which aims to reduce the number of routing table entries by aggregating a number of contiguous network addresses behind a prefix shorter than any of the individual entries would be. > If people are issued a /24 prefix under > IPv6, it allocates proportionally as much as allocating /24 in IP4 > address space. No, not really. If you've got a 24 bit prefix in IPv4, then you are 75% (24/32) of the way through the address, and you've only got 8 bits to number the systems within that /24 network prefix. In IPv6, a 24 bit prefix is less than 20% of the way through the address, and thus can "hide" a much larger number of networks and systems behind that single entry, as you've still got 104 bits to play with. > Is there something I don't understand, or are huge chunks of IP6 address > space being thrown about? I think you've got it...note that all of the prefixes in use on the 6bone are as defined in RFC 1897, and represent a fraction of the total address space defined in RFC 1884. Dan From bound@zk3.dec.com Mon Jan 27 16:57:35 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 27 Jan 97 11:57:35 -0500 Subject: a 6bone topology discussion In-Reply-To: Your message of "Sun, 26 Jan 97 18:18:42 PST." Message-ID: <9701271657.AA21114@wasted.zk3.dec.com> Bob, >1. Agree among us who the "core" backbone sites are, based on them either >being an ISP (e.g., WIDE, JOIN, G6, ESnet, CICNet) or someone seriously >committed to simulating one, at least for this phase of the 6bone (e.g., >Bay, Cisco, Digital, NRL). Digital Palo Alto Internet Exchange (PAIX) Digital-CA 6bone connection is seriously committed to simulating for now and possibly into the future IPv6 on the 6bone. We would be glad to be a core backbone router. So add us to that list. I think the topology you laid out is good and the idea of going next door instead of cross country to get next door. But there is one problem and it may just be a Digital problem right now. Let me explain. In a few short weeks we will be defining a public strategy for IPv6 so our customers can begin to use/deploy IPv6. These will be the early adopters. These customers will want to connect to the 6bone and other services as they are deployed for IPv6. We intend to gurantee them a level of service and support during this process. So if we tell them we will "take-care-of-and-support-you" at Digital-CA entry point it gives them relief from some problems while connecting and real support. So the customer may want to access the 6bone via Digital-CA even if they are in Naples, Florida U.S. to obtain the support, etc. we provide via Digital-CA. As opposed to another core-backbone-router that is just up and running and does not really have the resources to manage, support, or assist users with the 6bone connection. As you stated this should permitted, but must be controlled by the core-backbone routers (e.g. Digital-CA, ESnet, CICnet). I think it very important that our map of the 6bone permit viewing of these leaf nodes in some manner as the customer will want to see themselves on the 6bone drawing. It also assists us to track the number and range of users using IPv6 on the 6bone via the WWW. If those that are going to ***really really*** take on being core-backbone routers for the 6bone, and provide support, and would like to discuss this with us to work something out geographically please contact privately myself (bound@zk3.dec.com) and Stephen Stuart (stuart@pa.dec.com) for that discussion. /jim From dhaskin@baynetworks.com Mon Jan 27 18:44:36 1997 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Mon, 27 Jan 1997 13:44:36 -0500 Subject: a 6bone topology discussion Message-ID: <199701271844.NAA01229@pobox.engeast.BayNetworks.COM> > > Thus I would propose that we adopt the following: > > 1. Agree among us who the "core" backbone sites are, based on them either > being an ISP (e.g., WIDE, JOIN, G6, ESnet, CICNet) or someone seriously > committed to simulating one, at least for this phase of the 6bone (e.g., > Bay, Cisco, Digital, NRL). > Yes we need to define the core backbone sites but they can not be limited to ISPs on 6bone. Of cause ISPs are welcome to offer commercial grade IPv6 services independently. As it stands now some non-ISP sites are more IPv6-commited than ISP ones and may provide better services to their clients. > > 5. Leaf/stub sites would then request a tunnel of a transit or backbone > site based on the IPv4 topology as much as possible. The goal would be to > not traverse the world just to get across town (so to speak) if there is a > practical choice just across town. > This can be recommended but cannot be required. There are other than topology considerations that can't be ignored. Dimitry From iuso@net.telecomitalia.it Mon Jan 27 19:29:59 1997 From: iuso@net.telecomitalia.it (Francesco Iuso) Date: Mon, 27 Jan 1997 20:29:59 +0100 Subject: New 6Bone site SIRIUS-LAB1 Message-ID: <32ED0237.CF1@net.telecomitalia.it> Hi, SIRIUS-LAB1/IT has connected to 6bone. We've set up a tunnel to CSELT/IT and our entry in the RIPE database is as follows: site: Telecom Italia Divisione Rete location: Roma, ITALY loc-string: 45 03 52.2n 07 39 43.2e 250m prefix: 5f15:8100::/32 ping: 5f15:8100:c2f2::20:afc7:0 tunnel: 194.242.0.68 163.162.252.4 CSELT contact: Francesco Iuso Ivano Guardini status: operational since January 27, 1997 remark: PC 486, IPv6 NRL working on NetBSD 1.2 changed: iuso@net.telecomitalia.it 19970127 source: RIPE Bye Franceso -- Francesco Iuso TELECOM Italia DRE/TA-SP2 tel. + 39 6 3688 6273 Via della Vignaccia 45 fax. + 39 6 32 22 637 I-00163 Roma E-Mail iuso@net.telecomitalia.it Italy From dlee@visc.vt.edu Mon Jan 27 20:47:42 1997 From: dlee@visc.vt.edu (David Lee) Date: Mon, 27 Jan 1997 15:47:42 -0500 (EST) Subject: Connection request Message-ID: <199701272047.PAA07245@ocarina.visc.vt.edu> Hello -- I'm trying to get several test nodes up on the 6bone and have a number of questions. First, my understanding is that we should be using our provider's ASN and not our site ASN -- fine, except we have three different providers... see next question. Second, my best guess for the tunnel connection (from ocarina.ee.vt.edu) would be to NRL (going back to the first question, do I pick Sprint's ASN since that's the particular provider that we'd be using in this case?). Thanks, DCL -- David C. Lee, EE PhD student/GRA - http://www.visc.vt.edu/~dlee - dlee@vt.edu PHONE: 1-540-231-8398 | FAX: 1-540-231-3362 | LOCATION: 475 Whittemore Hall Virginia Tech Information Systems Center, Blacksburg, Virginia 24061-0111 From Marc.Blanchet@viagenie.qc.ca Tue Jan 28 18:51:23 1997 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Tue, 28 Jan 1997 13:51:23 -0500 Subject: new 6bone site Message-ID: Hi, our site (VIAGENIE/CA in Canada) is connected to the 6bone since last friday(19970124), through DIGITAL-CA. We will be down for this week for an upgrade and then back next week on the 6bone. Here is our entry in the RIPE db: site: Viagenie inc. location: Ste-Foy, Quebec, Canada prefix: 5F16:8900:CE7B:1F00::/64 ping: 5F16:8900:CE7B:1F00::800:2080:9A38 tunnel: 206.123.31.101 204.123.2.236 DIGITAL-CA/US contact: Marc Blanchet status: operational since 19970124 changed: Marc Blanchet 19970124 source: RIPE Regards, Marc. ------------------------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca ViaGenie inc. | NIC: MB841 3107 ave. des hotels | radio: VA2-JAZ Ste-Foy, Quebec, Canada | G1W 4W5 | tel.: 418-656-9254 http://www.viagenie.qc.ca | fax.: 418-656-0183 ------------------------------------------------------------------------- Auteur du livre "TCP/IP simplifii", Editions Logiques,1997 ------------------------------------------------------------------------- From lf@elemental.net Wed Jan 29 22:41:27 1997 From: lf@elemental.net (Lars Fenneberg) Date: Wed, 29 Jan 1997 23:41:27 +0100 (MET) Subject: New 6bone site MCS/DE Message-ID: Hi! MCS joined the 6bone yesterday. Our RIPE registry entry: site: Moorbeck Computer Systeme GmbH / Cityline location: Hamburg, Germany prefix: 5f15:9100::0/32 tunnel: 194.221.20.129 132.250.90.5 NRL tunnel: 194.221.20.129 129.88.26.1 G6 contact: Lars Fenneberg status: operational since about October, 1996 remark: running on Linux/IPv6 2.1.x remark: please don't install automatic pings to the IPv4 tunnel endpoint remark: if possible because it's currently reached via a dial-on-demand remark: line changed: lf@elemental.net 970129 source: RIPE Regards, Lars. -- Lars Fenneberg, lf@elemental.net, phone: +49 40 529 833 10 fingerprint D1 28 F1 FF 3C 6B C0 27 CC 9C 6C 09 34 0A 55 18 From stuart.prevost@bt-sys.bt.co.uk Thu Jan 30 15:51:36 1997 From: stuart.prevost@bt-sys.bt.co.uk (Stuart Prevost) Date: Thu, 30 Jan 1997 15:51:36 -0000 Subject: New 6bone site BT-Labs Message-ID: Hello, BT Labs has connected to the 6bone. We have two tunnels, one to NRL and the other to the University of Lancaster. I have added an entry in the RIPE database as follows site: BT Labs, Martlesham Heath location: Suffolk, UK loc-string: 52 04 00n 1 17 00e prefix: 5f06:d800/32 ping: 5f06:d800:c171:3a00::1 tunnel: 193.113.58.75 132.250.90.5 NRL tunnel: 193.113.58.75 148.88.153.38 ULANC contact: Stuart Prevost status: operational remark: IPv6 for Solaris 2.5.1 changed: stuart.prevost@bt-sys.bt.co.uk 970130 source: RIPE Stuart Stuart Prevost Advanced Applications & Technology, BTLabs stuart.prevost@bt-sys.bt.co.uk Tel:01473 646891 (int +44 1473 646891) From kazu@is.aist-nara.ac.jp Fri Jan 31 08:21:30 1997 From: kazu@is.aist-nara.ac.jp (Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) Date: Fri, 31 Jan 1997 17:21:30 +0900 Subject: weird RIP prefix: 5f00::/16 In-Reply-To: Your message of "Fri, 24 Jan 1997 19:33:46 +0100" References: <970124193347.ZM4686@rama.imag.fr> Message-ID: <7127.854698890@mine.aist-nara.ac.jp> Hi, From: "Alain Durand" Subject: weird RIP prefix: 5f00::/16 Date: Fri, 24 Jan 1997 19:33:46 +0100 > I'm getting the prefix 5f00::/16 in a RIP announce. > I do not understand this preffix. Is it a bug somewhere > or do I miss something? I'm receiving ::/0 as well as 5f00::/8 from Cisco. I wonder that ::/0 is necesary with the current address assignment. P.S. I'm also receiving packets with link-local source addresses from off-link. Please check out your IPv6 code in case. Thanks, --Kazu From capitani@sun1.spfo.unibo.it Fri Jan 31 10:56:57 1997 From: capitani@sun1.spfo.unibo.it (Gianluca Capitani) Date: Fri, 31 Jan 1997 11:56:57 +0100 Subject: New 6bone site UNIBO Message-ID: <199701311056.LAA02148@sun1.spfo.unibo.it> Hello, University of Bologna (ITALY) has connected to the 6bone. We have 1 tunnel to POLITO. I have added an entry in the RIPE database as follow: site: University of Bologna location: Bologna, site of Forli' - ITALY loc-string: 44 20 10n 12 00 10e 200m prefix: 5f15:4100:89cc::/48 ping: 5f15:4100:89cc:c600:c6:800:2074:ce95 tunnel: 137.204.198.2 130.192.26.254 POLITO contact: Gianluca Capitani status: operational since Jan.1997 remark: IPv6(rel.5) for Solaris 2.5.1 remark: Running a IPv6-capable Bind 4.9.3 on sun1.spfo.unibo.it changed: capitani@spfo.unibo.it 970131 source: RIPE Below is the ping result to POLITO tunnel: sun1%[54]:./ping -s 5f15:5000:82c0:e00:bd:800:2bb5:a7a8 PING 5f15:5000:82c0:e00:bd:800:2bb5:a7a8: 56 data bytes 64 bytes from 5f15:5000:82c0:e00:bd:800:2bb5:a7a8: icmp_seq=0. time=182 ms 64 bytes from 5f15:5000:82c0:e00:bd:800:2bb5:a7a8: icmp_seq=1. time=130 ms 64 bytes from 5f15:5000:82c0:e00:bd:800:2bb5:a7a8: icmp_seq=2. time=123 ms 64 bytes from 5f15:5000:82c0:e00:bd:800:2bb5:a7a8: icmp_seq=3. time=130 ms 64 bytes from 5f15:5000:82c0:e00:bd:800:2bb5:a7a8: icmp_seq=4. time=127 ms 64 bytes from 5f15:5000:82c0:e00:bd:800:2bb5:a7a8: icmp_seq=5. time=149 ms 64 bytes from 5f15:5000:82c0:e00:bd:800:2bb5:a7a8: icmp_seq=6. time=173 ms 64 bytes from 5f15:5000:82c0:e00:bd:800:2bb5:a7a8: icmp_seq=7. time=165 ms 64 bytes from 5f15:5000:82c0:e00:bd:800:2bb5:a7a8: icmp_seq=8. time=218 ms 64 bytes from 5f15:5000:82c0:e00:bd:800:2bb5:a7a8: icmp_seq=9. time=208 ms 64 bytes from 5f15:5000:82c0:e00:bd:800:2bb5:a7a8: icmp_seq=10. time=177 ms  ----5f15:5000:82c0:e00:bd:800:2bb5:a7a8 PING Statistics---- 11 packets transmitted, 11 packets received, 0% packet loss round-trip (ms) min/avg/max = 123/162/218 Please update the full routing table. Thanks. Gianluca C.. Gianluca Capitani University of Bologna (site of Forli') Tel: +39-543-450280 From RLFink@lbl.gov Fri Jan 31 15:27:37 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 31 Jan 1997 07:27:37 -0800 Subject: New 6bone site BT-Labs In-Reply-To: Message-ID: Stuart, Before I can put you on the 6bone diagram I need to know which route (tunnel) is your primary one, NRL or ULANC? Also, there is no corresponding RIPE-NCC entry for you in NRL's entry. Before I add folk to the diagram I need all RIPE-NCC entries complete and the tunnel pingable (and of course which is the primary if there are multiple tunnels). Thanks, Bob =============================================== At 7:51 AM -0800 1/30/97, Stuart Prevost wrote: >Hello, > >BT Labs has connected to the 6bone. We have two tunnels, one to NRL and >the other to the University of Lancaster. > >I have added an entry in the RIPE database as follows > >site: BT Labs, Martlesham Heath >location: Suffolk, UK >loc-string: 52 04 00n 1 17 00e >prefix: 5f06:d800/32 >ping: 5f06:d800:c171:3a00::1 >tunnel: 193.113.58.75 132.250.90.5 NRL >tunnel: 193.113.58.75 148.88.153.38 ULANC >contact: Stuart Prevost >status: operational >remark: IPv6 for Solaris 2.5.1 >changed: stuart.prevost@bt-sys.bt.co.uk 970130 >source: RIPE > >Stuart > > >Stuart Prevost >Advanced Applications & Technology, >BTLabs > >stuart.prevost@bt-sys.bt.co.uk >Tel:01473 646891 (int +44 1473 646891) From RLFink@lbl.gov Fri Jan 31 15:40:31 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 31 Jan 1997 07:40:31 -0800 Subject: new 6bone diagram (47) Message-ID: 6bone diagram 47 EPFL/CH tunnelled to SWITCH/CH PSC/US tunnelled to DIGITAL-CA/US VIAGENIE/CA tunnelled to DIGITAL-CA/US UNIBO/IT tunnelled to POLITO/IT SIRIUS-LAB1/IT tunnelled to CSELT/IT MCS/DE tunnelled to G6/FR Welcome to all!! Remember that I need sanity checks on the diagram, especially as to what is the primary path for a site. My rule is to pick the one that looks most likely to be closest if I'm not told otherwise. Thanks, Bob From RLFink@lbl.gov Fri Jan 31 15:53:28 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 31 Jan 1997 07:53:28 -0800 Subject: 6bone stats page added for CSELT/IT Message-ID: Added CSELT/IT ping reachability data page: http://www-6bone.lbl.gov/6bone/6bone_stats.html Thanks to Ivan Guardin1. Bob From erik-jan.bos@surfnet.nl Fri Jan 31 17:19:29 1997 From: erik-jan.bos@surfnet.nl (Erik-Jan Bos) Date: Fri, 31 Jan 1997 18:19:29 +0100 Subject: Looking for 6bone tunnel Message-ID: <15293.854731169@surfnet.nl> 6boners, we currently have our v6 box up-and-running and we are looking for a tunnel. We are located in The Netherlands, Europe. Knowning something about the IPv4 unicast topology, a tunnel to a v6 node inside NORDUnet might be a good idea. But any other offers are welcome as well. Thanks in advance. __ Erik-Jan Bos SURFnet The Netherlands From dlee@visc.vt.edu Fri Jan 31 18:04:39 1997 From: dlee@visc.vt.edu (David Lee) Date: Fri, 31 Jan 1997 13:04:39 -0500 (EST) Subject: New Site Message-ID: <199701311804.NAA04960@ocarina.visc.vt.edu> RIPE record: site: Virginia Polytechnic Institute and State University (VT) location: Blacksburg, Virginia, US loc-string: N 37-12.5 W080-24.4 prefix: 5F05:2000:80AD:5800::0/64 ping: 5F05:2000:80AD:5800:0058:0800:2023:1D71 tunnel: 128.173.88.82 198.82.204.73 Inner contact: David Lee status: operational since January 29, 1997 remark: Routes will be added on request to dlee@vt.edu remark: Other information at http://www.visc.vt.edu/ipv6 remark: and at http://www.ee.ipv6.vt.edu/ipv6 changed: dlee@vt.edu 970131 source: RIPE Note that DNS delegation has not occurred yet and should relatively soon. Currently, send your resolution requests to ocarina.ee.vt.edu. Tunnel ping information: ocarina:/home/dlee > ping anger.ipv6.inner.net Using IPv6. PING anger.ipv6.inner.net: 56 data bytes sending 64 bytes to 5f05:2000:c733:2100::5 Packet length= 64, header length= 40, priority= 0, flow label= 0 Echo reply: 64 bytes from 5f05:2000:c733:2100::5: icmp_seq=0. time=53 ms sending 64 bytes to 5f05:2000:c733:2100::5 Packet length= 64, header length= 40, priority= 0, flow label= 0 Echo reply: 64 bytes from 5f05:2000:c733:2100::5: icmp_seq=1. time=26 ms sending 64 bytes to 5f05:2000:c733:2100::5 Packet length= 64, header length= 40, priority= 0, flow label= 0 Echo reply: 64 bytes from 5f05:2000:c733:2100::5: icmp_seq=2. time=25 ms sending 64 bytes to 5f05:2000:c733:2100::5 Packet length= 64, header length= 40, priority= 0, flow label= 0 Echo reply: 64 bytes from 5f05:2000:c733:2100::5: icmp_seq=3. time=9 ms sending 64 bytes to 5f05:2000:c733:2100::5 Packet length= 64, header length= 40, priority= 0, flow label= 0 Echo reply: 64 bytes from 5f05:2000:c733:2100::5: icmp_seq=4. time=10 ms ^C ----anger.ipv6.inner.net PING Statistics---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 9/24/53 -- David C. Lee, EE PhD student/GRA - http://www.visc.vt.edu/~dlee - dlee@vt.edu PHONE: 1-540-231-8398 | FAX: 1-540-231-3362 | LOCATION: 475 Whittemore Hall Virginia Tech Information Systems Center, Blacksburg, Virginia 24061-0111 From 6bone@snad.ncsl.nist.gov Fri Jan 31 21:22:53 1997 From: 6bone@snad.ncsl.nist.gov (6bone@snad.ncsl.nist.gov) Date: Fri, 31 Jan 1997 16:22:53 -0500 (EST) Subject: Changes to NIST 6Bone Reachability WWW Page Message-ID: <199701312122.QAA00451@sloth.ncsl.nist.gov> Both v4 and v6 traceroute dumps have been added to the NIST 6Bone reachability page (http://www.antd.nist.gov/~ipng/NIST-6bone-status.html) This should help in tracking down and debugging some routing problems. Just click on a particular address to get to the traceroute information. Other changes include: 1. Statistics are gathered concurrently. This was done in an effort to keep up with the growing size of the 6bone. The timestamp of when a site is actually pinged can be found at the bottom of the traceroute dump. 2. The computed RTT information is no longer on the page. 3. No longer print RTT when there is a 100% loss. 4. The traceroute dump will report a bad address if detected.