From bmanning@ISI.EDU Mon Sep 1 16:22:34 1997 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 1 Sep 1997 08:22:34 -0700 (PDT) Subject: Release 5.2 is now available In-Reply-To: <034543B7FDC5D011BAC10000C06F25BE394899@gvamsx1.ch.att.com> from "Bertrand.Buclin@ch.att.com" at Sep 1, 97 01:30:27 pm Message-ID: <199709011522.AA24966@zephyr.isi.edu> > The 6Bone is planning to > cut over to the new addressing scheme on October 1st, Is there any reason why people think that there will be only a single address format running on the 6bone? -- --bill From roque@cisco.com Mon Sep 1 18:35:11 1997 From: roque@cisco.com (Pedro Marques) Date: Mon, 1 Sep 1997 10:35:11 -0700 (PDT) Subject: Release 5.2 is now available In-Reply-To: <034543B7FDC5D011BAC10000C06F25BE394899@gvamsx1.ch.att.com> References: <034543B7FDC5D011BAC10000C06F25BE394899@gvamsx1.ch.att.com> Message-ID: <199709011735.KAA09513@pedrom-ultra.cisco.com> >>>>> "Bertrand" == Bertrand Buclin writes: Bertrand> Mike, This is a very unfortunate position... During the Bertrand> last IETF meeting in Munich, we've been told that all Bertrand> the implementations that participated in the July UNH Bertrand> Interop testing did support the new addressing scheme Bertrand> and EUI-64 (I don't know though if Sun participated in Bertrand> that testing). Based among other things on that Bertrand> statement, it was decided to migrate the 6Bone to the Bertrand> new addressing scheme The new addressing scheme has no relation at all with the low 64bits of the address. So regardless of the changes in addressing you can still use 48-bit 802.3 link tokens. Bertrand> so that it could be tested in a Bertrand> sort of real deployment. Also, as Bill Manning has pointed out the two addressing formats will co-exist in the 6bone for a while. Pedro. From roque@cisco.com Tue Sep 2 08:38:43 1997 From: roque@cisco.com (Pedro Marques) Date: Tue, 2 Sep 1997 00:38:43 -0700 (PDT) Subject: Release 5.2 is now available In-Reply-To: References: Message-ID: <199709020738.AAA09625@pedrom-ultra.cisco.com> >>>>> "Bertrand" == Bertrand Buclin writes: >> Pedro: The new addressing scheme has no relation at all with >> the low 64bits of the Pedro: address. Bertrand> [BB ] Sort of... The IPv6-over-Ethernet (draft-ietf-ipngwg- Bertrand> trans-ethernet-02.txt) is pretty clear: stateless Bertrand> autoconfiguration is based on the EUI-64 ID of the interface Bertrand> (built from the 48 bits ID). How do you exchange packets on Bertrand> the link when two implementations are not using the same Bertrand> conventions to build link-local addresses ? Bertrand, IPv6 communication is still possible if different hosts are using different autoconfiguration schemes. Autoconfiguration just creates address, packets can flow between hosts regardsless of the mechanism used for creating the address (manual conf, DHCP, 802.3 based statless or 802.3 + some bits) >> >> Pedro: So regardless of the changes in addressing you can still >> use 48-bit 802.3 Pedro: link tokens. Bertrand> As long as you are ready to manually configure your boxes... Those are different issues: configuration and communication. Yes if you only have new format routers old format hosts you have to manually configure the global addresses (and vice-versa). But you may find that some vendors are quite cooperative on this issues :-) >> Pedro: Also, as Bill Manning has pointed out the two >> addressing formats will Pedro: co-exist in the 6bone for a >> while. Bertrand> On my site, I want to move to the 3FFE... addresses as soon Bertrand> as I can, and as of October 1st, get rid of the previous Bertrand> addresses. That is even a separate issue. You can configure 3ffe address and still use the previous autoconfiguration format. At the moment cisco is annoucing both it's 3ffe prefix and it's 5f00::.../32 prefix and we are still using the previous autoconf format. Bertrand> This is my choice. I agree that the two kinds of addresses will Bertrand> coexist on the 6Bone for a while, but as far as I am concerned, Bertrand> I plan to not anymore use and advertise my current 5F... Bertrand> prefix in a few weeks from now. Then don't. BGP which is what actually gets the job done doesn't attribute any special meaning to the prefix. Things will still work. Bertrand> So if other sites are still using their 5F... addresses, Bertrand> this is their choice, and indeed I can expect to still be able Bertrand> to communicate with those sites. And you will. Bertrand> Bottom line, I still find Sun's decision very unfortunate... With all due respect, some of the arguments you first presented are not really acurate and you will probably find your vendor more responsive if you bring the issue with them privatly instead of in a public forum. Pedro. From RLFink@lbl.gov Tue Sep 2 14:57:51 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 2 Sep 1997 06:57:51 -0700 Subject: Finland added to the country list Message-ID: I have added Finland to the 6bone country list. making 29 countries that I know of. Apparently I missed any notice of Finland coming online. Can someone tell me what Finish sites there are, and how they are connected, so I can add them to the diagram? Thanks, Bob From RLFink@lbl.gov Tue Sep 2 15:04:37 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 2 Sep 1997 07:04:37 -0700 Subject: current pTLA list - 28Aug97 In-Reply-To: <199708291834.LAA08399@pedrom-ultra.cisco.com> References: Message-ID: Pedro, At 11:34 AM -0700 8/29/97, Pedro Marques wrote: ... >I'd like to carve addresses from a separate TLA for interconnects (i.e. a >TLA not associated with any site). It would be nice if somebody will step >in and administer such a thing... if not i guess i'll have to volunteer. I believe you mean exchanges? We have several 6bone sites that will act as exchanges, one of which is Digital-CA. If a site becomes an exchange, then the tunnel must be going from the leaf site to this site. From the way you ask your question above I get the impression that you want to hand out NLAs below the pTLA even if they aren't directly connected. Am I missing your intent, or are you trying to do a style of addressing beyond the aggregatable address ID? Thanks, Bob From RLFink@lbl.gov Tue Sep 2 17:30:29 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 2 Sep 1997 09:30:29 -0700 Subject: Release 5.2 is now available In-Reply-To: <199709011735.KAA09513@pedrom-ultra.cisco.com> References: <034543B7FDC5D011BAC10000C06F25BE394899@gvamsx1.ch.att.com> <034543B7FDC5D011BAC10000C06F25BE394899@gvamsx1.ch.att.com> Message-ID: Pedro, At 10:35 AM -0700 9/1/97, Pedro Marques wrote: ... >The new addressing scheme has no relation at all with the low 64bits of the >address. > >So regardless of the changes in addressing you can still use 48-bit 802.3 >link tokens. As I read the Aggregatable Global Unicast Address Format I-D ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-unicast-aggr-02.txt the new Interface ID is part of the new addressing scheme. Thus we should be testing the new prefix format AND the new EUI-64 at the same time. ==== from the draft 3.5 Interface ID Interface identifiers are used to identify interfaces on a link. They are required to be unique on that link. They may also be unique over a broader scope. In many cases an interface's identifier will be the same or be based on the interface's link-layer address. Interface IDs used in the aggregatable global unicast address format are required to be 64 bits long and to be constructed in IEEE EUI-64 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ format [EUI-64]. These identifiers may have global scope when a global token (e.g., IEEE 48bit MAC) is available or may have local scope where a global token is not available (e.g., serial links, tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE EUI-64 terminology) in the EUI-64 identifier must be set correctly, as defined in [ARCH], to indicate global or local scope. The procedures for creating EUI-64 based Interface Identifiers is defined in [ARCH]. The details on forming interface identifiers is defined in the appropriate "IPv6 over " specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. ==== >Also, as Bill Manning has pointed out the two addressing formats will >co-exist in the 6bone for a while. The goal is to move away from the old address format as quickly as possible. In reality it should be what the 6bone community agrees on, and I haven't heard much yet on this from the mailer. Thanks, Bob From roque@cisco.com Tue Sep 2 17:40:02 1997 From: roque@cisco.com (Pedro Marques) Date: Tue, 2 Sep 1997 09:40:02 -0700 (PDT) Subject: Release 5.2 is now available In-Reply-To: References: <034543B7FDC5D011BAC10000C06F25BE394899@gvamsx1.ch.att.com> <199709011735.KAA09513@pedrom-ultra.cisco.com> Message-ID: <199709021640.JAA09777@pedrom-ultra.cisco.com> >>>>> "Bob" == Bob Fink writes: Bob> Pedro, At 10:35 AM -0700 9/1/97, Pedro Marques wrote: ... >> The new addressing scheme has no relation at all with the low >> 64bits of the address. >> >> So regardless of the changes in addressing you can still use >> 48-bit 802.3 link tokens. Bob> As I read the Aggregatable Global Unicast Address Format I-D Bob> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-unicast-aggr-02.txt Bob> the new Interface ID is part of the new addressing scheme. Bob> Thus we should be testing the new prefix format AND the new Bob> EUI-64 at the same time. Why ? Do you have any reason at all to tight the two things together ? They are two completely separate mechanisms for completly distinct problems. Further, operationally it makes no sense to me to try to connect the two issues... the 6bone is an interconection of ipv6 sites, it should not concern itself at all with autoconfiguration of hosts in a LAN. Pedro. From crawdad@fnal.gov Tue Sep 2 17:37:18 1997 From: crawdad@fnal.gov (Matt Crawford) Date: Tue, 02 Sep 1997 11:37:18 -0500 Subject: Release 5.2 is now available In-Reply-To: Your message of Tue, 02 Sep 1997 00:38:43 PDT. <199709020738.AAA09625@pedrom-ultra.cisco.com> Message-ID: <199709021637.LAA17975@gungnir.fnal.gov> Pedro diz: > IPv6 communication is still possible if different hosts are using different > autoconfiguration schemes. [...] > > Those are different issues: configuration and communication. Yes if you > only have new format routers old format hosts you have to manually configure > the global addresses (and vice-versa). But you may find that some vendors > are quite cooperative on this issues :-) So, for a transitional period, will you let your routers include both xxxx:xxxx:xxxx:xxxx::/64 and xxxx:xxxx:xxxx:xxxx:0::/80 in router advertisements on a single link? This would exercise the requirement that An IPv6 address prefix used for stateless autoconfiguration of an Ethernet interface must (have a length of 64 bits | be 80 bits in length). depending on which generation of the spec is implemented. From RLFink@lbl.gov Tue Sep 2 18:11:17 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 2 Sep 1997 10:11:17 -0700 Subject: Release 5.2 is now available In-Reply-To: <199709021640.JAA09777@pedrom-ultra.cisco.com> References: <034543B7FDC5D011BAC10000C06F25BE394899@gvamsx1.ch.att.com> <199709011735.KAA09513@pedrom-ultra.cisco.com> Message-ID: Pedro, At 9:40 AM -0700 9/2/97, Pedro Marques wrote: >>>>>> "Bob" == Bob Fink writes: > > Bob> Pedro, At 10:35 AM -0700 9/1/97, Pedro Marques wrote: ... > >> The new addressing scheme has no relation at all with the low > >> 64bits of the address. > >> > >> So regardless of the changes in addressing you can still use > >> 48-bit 802.3 link tokens. > > Bob> As I read the Aggregatable Global Unicast Address Format I-D > > Bob> >ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-unicast-aggr-02.txt > > Bob> the new Interface ID is part of the new addressing scheme. > > Bob> Thus we should be testing the new prefix format AND the new > Bob> EUI-64 at the same time. > >Why ? Do you have any reason at all to tight the two things together ? >They are two completely separate mechanisms for completly distinct problems. > >Further, operationally it makes no sense to me to try to connect the two >issues... the 6bone is an interconection of ipv6 sites, it should not concern >itself at all with autoconfiguration of hosts in a LAN. Because we are testing the real implementations on both LAN and WAN. And, of course, because that is the standard (i.e., I-D) that we agreed to implement and test. You had said that the new addressing scheme has no relation to the low 64 bits, but it does in the spec. Now I must admit I don't know what will break (if anything) if we don't implement EUI-64 at the same time as the aggregatable prefix, but we should try to test the real spec as much as possible. Thanks, Bob From roque@cisco.com Tue Sep 2 18:28:32 1997 From: roque@cisco.com (Pedro Marques) Date: Tue, 2 Sep 1997 10:28:32 -0700 (PDT) Subject: Release 5.2 is now available In-Reply-To: References: Message-ID: <199709021728.KAA09790@pedrom-ultra.cisco.com> >>>>> "Bertrand" == Bertrand Buclin writes: Bertrand> Pedro, It sounds to me like we are not on the same Bertrand> wavelength... Bertrand> What I see TODAY on my Sun systems (running 5.2) tells Bertrand> me that Sun's current implementation does not Bertrand> interoperate with other systems implementing the new Bertrand> addressing scheme. Bertrand> The router on my LAN used to have FFE8::800:2bb7:87f8 as ^^^^ fe80, ff is the prefix for multicast addresses. Make sure your host has a route for fe80::0/10 (i.e. some implementations como with a default config of /80 incorrectly) and things should work. Bertrand> I upgraded to router to a new code version implementing Bertrand> the EUI-64 stuff. It now has FFE8::A00:2bFF:FeB7:87f8 as ^^^^ that is multicast again. Bertrand> link local address. The Sun cannot talk to it anymore Bertrand> now. Since SUN did implement the earlier link-id draft that prepended bits to the link token i would expect it to work. Have you tryed with the proper link local address ? Pedro. From RLFink@lbl.gov Tue Sep 2 18:37:21 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 2 Sep 1997 10:37:21 -0700 Subject: current pTLA list - 28Aug97 In-Reply-To: <199708300149.BAA03501@inner.net> References: Your message of "Fri, 29 Aug 1997 14:17:15 PDT." <199708292117.AA07153@zed.isi.edu> Message-ID: At 6:49 PM -0700 8/29/97, Craig Metz wrote: >In message <199708292117.AA07153@zed.isi.edu>, you write: >>> I'd like to carve addresses from a separate TLA for interconnects (i.e. a >>> TLA not associated with any site). It would be nice if somebody will step >>> in and administer such a thing... if not i guess i'll have to volunteer. >> >>I was sort of hoping to use the 0000 range for this but craig beat us >>to it. > > If we decide that it's the right thing to do, I have no problem >slicing addresses off that block for this purpose. I'm not sure that it's the >right thing to do, though. Are these needed for every site (ISP) peering with another? How does this scale in the real world, i.e., how does one handle the assignment of these in the real world beyond a 6bone? Bob From bmanning@ISI.EDU Tue Sep 2 19:16:11 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Tue, 2 Sep 1997 11:16:11 -0700 (PDT) Subject: Finland added to the country list In-Reply-To: from "Bob Fink" at Sep 2, 97 06:57:51 am Message-ID: <199709021816.AA18825@zed.isi.edu> > > I have added Finland to the 6bone country list. making 29 countries that I > know of. > > Apparently I missed any notice of Finland coming online. Can someone tell > me what Finish sites there are, and how they are connected, so I can add > them to the diagram? > > > Thanks, > > Bob ; Petri Helenius pete@silver.sms.fi 04aug97 0.0.a.c.c.0.f.5.ip6.int. in ns ns.sms.fi. ; Matti Aarnio 26aug97 0.0.0.f.0.2.f.5.ip6.int. in ns mea.tmt.tele.fi. --bill From bmanning@ISI.EDU Tue Sep 2 19:11:44 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Tue, 2 Sep 1997 11:11:44 -0700 (PDT) Subject: Release 5.2 is now available In-Reply-To: from "Bob Fink" at Sep 2, 97 09:30:29 am Message-ID: <199709021811.AA18746@zed.isi.edu> > >Also, as Bill Manning has pointed out the two addressing formats will > >co-exist in the 6bone for a while. > > The goal is to move away from the old address format as quickly as > possible. In reality it should be what the 6bone community agrees on, and I > haven't heard much yet on this from the mailer. > > Thanks, > > Bob Hum. A goal for some will be to move from one address format to another. As I understand, both types remain valid and ought to be accepted. The IPv4 analogy I might use here is: "People must renumber all the hosts in the 1-126 range and go to the 192 range since the 192 range has CIDR support and the 1-126 does not." Or is there something else going on here? --bill From bound@zk3.dec.com Tue Sep 2 22:11:12 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Tue, 02 Sep 1997 17:11:12 -0400 Subject: Release 5.2 is now available In-Reply-To: Your message of "Tue, 02 Sep 1997 11:11:44 MST." <199709021811.AA18746@zed.isi.edu> Message-ID: <9709022111.AA13880@wasted.zk3.dec.com> Bill, >Hum. A goal for some will be to move from one address format to another. >As I understand, both types remain valid and ought to be accepted. >The IPv4 analogy I might use here is: > > "People must renumber all the hosts in the 1-126 range > and go to the 192 range since the 192 range has CIDR > support and the 1-126 does not." > >Or is there something else going on here? The 6bone is a test vehicle and we now have new agreed to specs for the low order 64bits per IPv6 over foo (choose your flavor). Bob Fink is correct we should be testing the new specs. If vendors have not implemented them that is a problem. It was my impression all had done so at UNH but some may not have offered new kits out to users. I know we just updated our kit and it will also support a backwards compatibility mode if there are nodes on the net that do not yet support the new interface ID spec. I personally believe we should select a drop dead date when the old form of IPv6 over Foo is no longer supported on the 6bone. All nodes must do the new specs and we can get rid of carrying around the backwards compatibility mode in all implementations. Bob I suggest you pick a date that we shoot for that is reasonable to all ??? /jim From jthompso@cs.utk.edu Wed Sep 3 15:56:19 1997 From: jthompso@cs.utk.edu (J Scott Thompson) Date: Wed, 3 Sep 1997 10:56:19 -0400 (EDT) Subject: Performance Measurement In-Reply-To: <9709022111.AA13880@wasted.zk3.dec.com> Message-ID: I am interested in focussing my Master's Thesis work in measurement of network performance. Specifically, I would like to develop a means by which historical data can be collected and made public looking at various metrics (bandwidth, latency, etc.), on various networks (6bone, ESNet, VBNS, etc.). Additionally, I would like to develop a means by which researchers can get real-time data for connections of interest (through CGI scripts or Java Applets executed from web pages). I am especially interested in trying to identify changes in network performance as the industry continues in its conversion to IPv6 and ATM over the coming years. I would appreciate feedback regarding this project. Specifically: 1) What metrics are the research community most interested in? 2) What metrics are measurable now using current tools? 3) What metric data are desired but which are currently not measurable using any known tools? 4) Is there anyone (or any group) currently interested in and working on similar measurements. 5) Any suggestions regarding a "good place to start" with a project of this nature. Jay Thompson University of Tennessee Computer Science Department jthompso@cs.utk.edu From RLFink@lbl.gov Thu Sep 4 00:46:47 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 3 Sep 1997 16:46:47 -0700 Subject: Munich IETF ngtrans-tools & -6bone WG minutes Message-ID: 6bone folk, Enclosed are the minutes of the Munich IETF ngtrans-tools and ngtrans-6bone WG meetings. Thanks, Bob _____________cut here___________________________________________________________ Ngtrans-tools WG meeting August 12, 1997 Munich IETF Tony Hain Microsoft chair (co-chair of ngtrans) Reported by ALain Durand and Tony Hain Discussion: ngtrans@sunroof.eng.sun.com Subscribe: majordomo@sunroof.eng.sun.com Archive: ftp://playground.sun.com/pub/ngtrans Chairs: Bob Fink rlfink@lbl.gov Robert Gilligan gilligan@freegate.net Tony Hain tonyhain@microsoft.com Notes for the minutes courtesy of Alain Durand durand@imag.fr Tools session: Various reports and plans were presented. Brian Carpenter (IBM, UK) reported that the "6 over 4" draft will be refreshed with no changes. Tony Hain (Microsoft, US) noted that the charter wording would be cleaned up to address concerns about the appearance we are mandating a scenario, and sent back to the list. Jim Bound (Digital, US) presented the NNAT concept as a means of dynamically assigning v4 addresses as needed for primarily v6 nodes. Goal is to allow primarily v6 work groups to be deployed soon, without requiring a permanent address in the v4 Internet. Attaining that requires core applications be available over the v6 stack sooner. Also requires a tie between the DNS and some form of DHCP service with a pool of v4 addresses. Some applications may not need or want connections with the v4 Internet, and should not be required to implement the extra code. Erik Nordmark (Sun, US) noted that the time to start thinking about translators to allow v4 only to v6 only has arrived. Some systems may arrive in the market as v6 only. Erik presented an overview of his ID (draft-ietf-ngtrans-header-trans-00.txt) and the rules for both directions. Tunneling v4 in v6 may be required for v4 compatible node within a v6 only routing system. Another option is a set of stateless translators that would convert the headers on the fly, but would not attempt v4 options. Pedro Marques (Cisco, US) discussed ideas about transparent translation where hosts were unaware of the translator. Does not require tie to DNS & DHCP, and Cisco has a prototype running. He will submit an ID to the list for comment. Dan Harrington (Lucent, US) reported that the update to the ID (draft-harrington-ngtrans-dhcp-option-00.txt) would reflect the assigned number from IANA. _____________cut here___________________________________________________________ ngtrans-6bone WG meeting August 12, 1997 Munich IETF Bob Fink ESnet/LBNL chair (co-chair of ngtrans) Reported by ALain Durand and Bob Fink Discussion: 6bone@isi.edu (6BONE Mailer) Subscribe: majordomo@isi.edu "subscribe 6bone" Archive: http://www.ipv6.nas.nasa.gov/6bone/ Chairs: Bob Fink rlfink@lbl.gov Robert Gilligan gilligan@freegate.net Tony Hain tonyhain@microsoft.com -------------------------------------------------------- Agenda -------------------------------------------------------- 1. Introduction and agenda / Fink 2. Status of action items from Memphis / Fink 3. New 6bone registry, oveview and issues / Kessens 4. Backbone planning / Fink, Durand, Davies 5. Test plan for aggregation-based addressing / Fink 6. Operational issues on the 6bone / various 7. Implementations in use on the 6bone / Fink -------------------------------------------------------- 1. Introduction and agenda / Fink -------------------------------------------------------- Bob Fink convened the meeting, giving a status report on the 6bone. There are now over 150 sites in 28 countries participating in the 6bone. BGP4+ has been successfully deployed in the 6bone backbon, with 3 interoperable implementations (Cisco, Digital and Telebit), and is rapidly replacing RIPng, IDRPv6 and static routes in the backbone. The 6bone now has its own domain, 6bone.net, through which the 6bone web pages and registry database is available. The primary DNS for 6bone.net is located at LBNL, and the secondary name servers are at RIPE an APNIC. The 6bone web pages are now available at: http://www.6bone.net The mail list is available by sending email to majordomo@isi.edu with subscribe 6bone in the body of the message. The agenda was accepted without comment. -------------------------------------------------------- 2. Status of action items from Memphis / Fink -------------------------------------------------------- Bob Fink reviewed the status of 6bone action items from the Memphis IETF. 2.1 CAIRN Backbone Proposal - Allison Mankin Allison Mankin will readdress this issue at the December meeting. 2.2 RFC1987 changes to use virtual IPv6 provide ID - Hsin Fang Hsin Fang removed this item from further consideration as the new Test Aggregation-based addressing plan supercedes it. 2.3 Aggregation-based Addressing structure for the 6bone - Bob Fink Bob Fink will present his plan, as issued previously to the 6bone mail list, under agenda item 5. below. 2.4 I-D "Representing IPv6 Tunnels in RPSL" - David Meyer This item is now closed as it has been implemented in the new 6bone registry. 2.5 New 6bone Registry - David Kessens David Kessens will present the status of the registry under agenda item 3. below. 2.6 DNS for localized 6bone routing registry information - Bill Manning Bill Manning would like to continue pursuing this idea. He earlier told the chair that he would come forward with a plan in the near future as to how he would like to proceed. The chair will close this item and await further submission from Bill before reactivating it. 2.7 Volunteer for I-D on requirements for new 6bone infrastructure - Bob Fink Bob Fink reported that he has previously had several offers to help on such a draft. He noted that when the address conversion and backbone restructuring of the 6bone is done, he will reopen this action as appropriate. 2.8 Survey of host and router implementations on the 6bone - Bob FInk Bob Fink will report on this survey under agenda item 7 below. -------------------------------------------------------- 3. New 6bone registry, oveview and issues / Kessens -------------------------------------------------------- David Kessens reported that the conversion away from the old ftp-style 6bone registry to the new RIPE-style 6bone registry was completed in early June. He autmatically mapped over all entries. The status of the new database is that there are 172 site objects and 130 persons registered. The query level is at ~200 per day. There are two mirror sites: whois.nic.fr and whois.ra.net, David noted that his draft on the registry specification, draft-ietf-ngtrans-6bone-registry-01.txt has been updated and it would be processed as an Informatinal RFC. David also noted that his registry was ready and capable of becoming an address registry for Aggregation-based Unicast addresses, if it was desirable. -------------------------------------------------------- 4. Backbone planning / Fink, Durand, Davies -------------------------------------------------------- Bob Fink spoke about the need to restructure the backbone to minimize peering, as opposed to full mesh peering, and that the renumbering for aggregation-based addressing might be a good time to accomplish this. He also noted the importance of moving to BGP4+ peering. Alain Durand, of the G6 project in France, spoke on plans to restructure the G6 collaborators for the coming readdressing required for the move to Aggregation-based addressing. Guy Davies, of UUNET/UK, spoke on plans to restructure the UK academic 6bone backbone, both to cleanup the topology and ready for the readdressing required for the move to Aggregation-based addressing. He also noted the problems in the current 6bone backbone with sloppy peering arrangements and poor aggregation. A major problem for the UK academic networks is that the 6bone backbone topology is too complex, there is not optimal aggregation, and there are bad RIPng problems. proposal: get accademic sites to single homed OR use BGP4+ map of Uk sites: The graphs from Guy's presentation are available at: http://www.pipex.net/~guyd/6bone/IETF-presentation/ -------------------------------------------------------- 5. Test plan for aggregation-based addressing / Fink -------------------------------------------------------- Bob Fink noted that the most important work ahead of the 6bone is conversion to the new Test address format for Aggregation-based Global Unicast addressing that is about to move to experimental RFC status. At a meeting later in the IETF week (Thursday at 11:30), those interested in the 6bone backbone planning met to discuss issues for the restructuring/cleanup of the backbone, as well as the address conversion. This meeting was reported in an email to the 6bone mail list that evening, and is reproduced as an addendum to these minutes. Then Bob presented the plan for 6bone use of the Test address format, which is the material presented on the 6bone mail list in late May. This material is reproduced as an addendum to these minutes. -------------------------------------------------------- 6. Operational issues on the 6bone / various -------------------------------------------------------- Matt Crawford spoke on multihoming on the 6bone. He noted that a site multihome to the same provider needs only one prefix if that provider knows how to handle the extra route. When connected to two or more providers it will (most likely) be necessary to have multiple prefixes. How much interconnection for backbone sites? There is too much as of today. This is recognized as one topic for discussion as the backbone is restructured for the new addressing format. -------------------------------------------------------- 7. Implementations in use on the 6bone / Fink -------------------------------------------------------- Bob Fink reported ion his survey of IPv6 implemenations. This survey may not be completely accurate, however, it is fairly close having been circulated for comment on the 6bone mail list. Host implementations in use on the 6bone are: Digital OpenVMS Digital Unix FTP Software Win95 Hitachi NR60 IBM AIX Inria BSD Linux SICS HP-UX Sun Solaris UNH for BSD NRL for BSD WIDE Hydrangea for BSD WIDE ZETA for BSD WIDE v6d Host implementations in use on the 6bone are: Bay Cisco Digital Fujitsu LR550 Hitachi NR60 Inria BSD Linux Merit MRT NRL for BSD Telebit WIDE Hydrangea for BSD WIDE ZETA for BSD WIDE v6d -------------------------------------------------------- Addendum - Report of ad hoc 6bne Backbone planning meeting -------------------------------------------------------- 6bone backbone planning meeting - 14 August 1997, Munich, DE. Alain Durand held a BOF for those interested in 6bone backbone planning under the new test aggregation address format. There were 27 people in attendance. Alain Durand (G6, FR) spoke on the need to minimize backone tunnels to clean up routing. There were comments for this, explaing the reasons why it is needed at this time, and comments as to why we shouldn't worry about this. Stephen Stuart (Digital-ca, US) spoke on reasons to cleanup peering, and to have multiple interconnect points for ISP TLA's. Matt Crawford showed various multi-prefix scenarios. There was a general consensus that there was a need to simplify the 6bone bacbone topology. Bob Fink (ESnet/LBNL, US) then led a discussion to generate a plan for readdressing and backbone restructuring. This discussion led to the following general agreements: 1. that we assign Testing pTLAs (i.e., pseudo TLAs assigned from the NLA1 field of the 6bone Test address allocation) from the Test Aggregation addressing I-D as follows: TELEBIT/DK 3FFE:0100::/24 SICS/SE 3FFE:0200::/24 G6/FR 3FFE:0300::/24 JOIN/DE 3FFE:0400::/24 WIDE/JP 3FFE:0500::/24 SURFNET/NL 3FFE:0600::/24 ESNET/US 3FFE:0700::/24 CICNET/US 3FFE:0800::/24 ISI-LAP/US 3FFE:0800::/24 NWNET/US 3FFE:0A00::/24 VIAGENIE/CA 3FFE:0B00::/24 CISCO/US 3FFE:0C00::/24 ANS/US 3FFE:0D00::/24 IFB/UK 3FFE:0E00::/24 NRL/US 3FFE:0F00::/24 CSELT/IT 3FFE:1000::/24 UUNET/UK 3FFE:1100::/24 DIGITAL-CA/US 3FFE:1200::/24 BAY/US 3FFE:1300::/24 UNI-C/DK 3FFE:1400::/24 Note: we started at 1 because Bob is nervous about using 0 :-) 2. that we establish October 1 as the start date for renumbering the backbone to testing aggregation addresses, with the goal of November 1 for coming online. 3. that all backbone sites will peer with BGP4+, and only BGP4+. 4. that the old testing addresses (RFC 1897) be discontinued on the backbone as early as October 1 (by sites already renumbered) and not later than November 1 when the newly addressed backbone is scheduled to be fully online. 5. that a call for new pTLA candidates be issued immediately, for inclusion in the October 1 renumbering/restructuring, where the criteria to be applied for inclusion is willingness and ability to actively participate in this timeframe, and demonstrated experience with IPv6 and the 6bone. 6. that a call for existing backbone sites (given a pTLA above) be made to decide themselves if they are able to participate in this renumbering/ resructuring effort, and be encouraged to give back their pTLA assignment for now if they aren't able to participate. (Note: any site doing this can easily reapply at a later time.) -------------------------------------------------------- Addendum - Call for 6bone Backbone participants email to 6bone list -------------------------------------------------------- Per the 6bone backbone ad hoc meeting in Munich, I am calling for those interested in being an early 6bone test pTLA (i.e., pseudo TLAs assigned from the NLA1 field of the 6bone Test address allocation) when the renumbering to the new Aggregation-based unicast address format is started on 1 October. Requirements are willingness and ability to actively participate in this timeframe, and demonstrated experience with IPv6 and the 6bone. Please send your requests to become a 6bone pTLA to the 6bone mail list with text sufficient to describe your interest and qualifications. I will assign test pTLAs to all reasonable request at this time. Thanks, Bob -end From RLFink@lbl.gov Thu Sep 4 01:22:51 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 3 Sep 1997 17:22:51 -0700 Subject: Release 5.2 is now available In-Reply-To: <9709022111.AA13880@wasted.zk3.dec.com> References: Your message of "Tue, 02 Sep 1997 11:11:44 MST." <199709021811.AA18746@zed.isi.edu> Message-ID: Jim, At 2:11 PM -0700 9/2/97, bound@zk3.dec.com wrote: >Bill, > >>Hum. A goal for some will be to move from one address format to another. >>As I understand, both types remain valid and ought to be accepted. >>The IPv4 analogy I might use here is: >> >> "People must renumber all the hosts in the 1-126 range >> and go to the 192 range since the 192 range has CIDR >> support and the 1-126 does not." >> >>Or is there something else going on here? > >The 6bone is a test vehicle and we now have new agreed to specs for the >low order 64bits per IPv6 over foo (choose your flavor). Bob Fink is >correct we should be testing the new specs. If vendors have not >implemented them that is a problem. It was my impression all had done >so at UNH but some may not have offered new kits out to users. I know >we just updated our kit and it will also support a backwards >compatibility mode if there are nodes on the net that do not yet support >the new interface ID spec. > >I personally believe we should select a drop dead date when the old form >of IPv6 over Foo is no longer supported on the 6bone. All nodes must do >the new specs and we can get rid of carrying around the backwards >compatibility mode in all implementations. > >Bob I suggest you pick a date that we shoot for that is reasonable to >all ??? I agree we need a date, but I'm concerned that we can't yet agree on one. For one, there are lots of Suns on the 6bone, and I doubt we can agree on a date until the Sun issue is resolved. Bob From bound@zk3.dec.com Thu Sep 4 03:30:09 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 03 Sep 1997 22:30:09 -0400 Subject: Release 5.2 is now available In-Reply-To: Your message of "Wed, 03 Sep 1997 17:22:51 MST." Message-ID: <9709040230.AA03454@wasted.zk3.dec.com> Bob, I understand that and agree with you. I did not say the date had to be anytime? But I think sometime should be selected. I suggest you or someone (I will help you if you like) contact all implementations and ask them when they can support the new stuff??? Then we pick a date? The hidden agenda I am working is as follows: We have new addr arch and we got to transition. We are also maybe going to change the DNS AAAA records via IPng WG. What I don't think we should do is have to "deploy" IPv6 in a production manner with backward compatible thingees from a test bed ..........I think this is not wise as a strategy. Transitioning v4 to v6 will be difficult enough without doing v6 to v6 too. What do you think? thanks /jim From RLFink@lbl.gov Thu Sep 4 16:10:12 1997 From: RLFink@lbl.gov (Bob Fink) Date: Thu, 4 Sep 1997 08:10:12 -0700 Subject: survey on expected transition dates for the 6bone Message-ID: 6bone Folk, As you have seen on this list, we have had much discussion on what might be intended for a conversion (on the 6bone) to the new aggregatable address format. Based on the IPng meetings, and what it says in the new I-D for IPv6 Addressing Architecture, the intention of the new Aggregatable Global Unicast Address format is to replace the previous Provider-Based Unicast Address format. It is even the case that, in the new address architecture I-D, that the reservation for Geographic-Based Unicast Addresses goes away as well. We need to make the conversion to the new format (on the 6bone) as cleanly and as soon as reasonable to facilitate testing of all parts of the new address format. At the Munich 6bone meetings we also set an initial timeline of: ===from the 6bone backbone meeting minutes "4. that the old testing addresses (RFC 1897) be discontinued on the backbone as early as October 1 (by sites already renumbered) and not later than November 1 when the newly addressed backbone is scheduled to be fully online." === So...my question is, is this reasonable? I would like to ask 6bone participants (all sites, not just backbone sites) to send to this list their estimate of ability to convert to the new address format, and when they believe it could be done. I'll compile and broadcst the list as it accumulates so we can all see what the problems are with implementations and timelines. Thanks, Bob ================================================================================ FROM THE OLD AND NEW ADDRESS ARCHITECTURE DOCS ================================================================================ draft-ietf-ipngwg-addr-arch-v2-02.txt [Page 6] INTERNET-DRAFT IPv6 Addressing Architecture July 1997 Allocation Prefix Fraction of (binary) Address Space ----------------------------------- -------- ------------- Reserved 0000 0000 1/256 Unassigned 0000 0001 1/256 Reserved for NSAP Allocation 0000 001 1/128 Reserved for IPX Allocation 0000 010 1/128 Unassigned 0000 011 1/128 Unassigned 0000 1 1/32 Unassigned 0001 1/16 Aggregatable Global Unicast Addresses 001 1/8 Unassigned 010 1/8 Unassigned 011 1/8 Unassigned 100 1/8 Unassigned 101 1/8 Unassigned 110 1/8 Unassigned 1110 1/16 Unassigned 1111 0 1/32 Unassigned 1111 10 1/64 Unassigned 1111 110 1/128 Unassigned 1111 1110 0 1/512 Link-Local Unicast Addresses 1111 1110 10 1/1024 Site-Local Unicast Addresses 1111 1110 11 1/1024 Multicast Addresses 1111 1111 1/256 -- Hinden & Deering Standards Track [Page 5] RFC 1884 IPv6 Addressing Architecture December 1995 Allocation Prefix Fraction of (binary) Address Space ------------------------------- -------- ------------- Reserved 0000 0000 1/256 Unassigned 0000 0001 1/256 Reserved for NSAP Allocation 0000 001 1/128 Reserved for IPX Allocation 0000 010 1/128 Unassigned 0000 011 1/128 Unassigned 0000 1 1/32 Unassigned 0001 1/16 Unassigned 001 1/8 Provider-Based Unicast Address 010 1/8 Unassigned 011 1/8 Reserved for Geographic- Based Unicast Addresses 100 1/8 Unassigned 101 1/8 Unassigned 110 1/8 Unassigned 1110 1/16 Unassigned 1111 0 1/32 Unassigned 1111 10 1/64 Unassigned 1111 110 1/128 Unassigned 1111 1110 0 1/512 Link Local Use Addresses 1111 1110 10 1/1024 Site Local Use Addresses 1111 1110 11 1/1024 Multicast Addresses 1111 1111 1/256 ================================================================================ -end From rirving@onecall.net Thu Sep 4 18:38:22 1997 From: rirving@onecall.net (Richard Irving) Date: Thu, 04 Sep 1997 12:38:22 -0500 Subject: Interested in joining 6 Bone Message-ID: <340EF20E.7229@onecall.net> One Call Communications, and Indiana based company is interested in joining the 6Bone. I would be interested in building a tunnel to someone.... Our ATM currently has its most open Circuits in Chicago. (The CHI NAP). If your company is interested, (or University) let me know. Richard Irving One Call Communications, Inc. 1-317-580-7217 rirving@onecall.net P.S. Where do I go to get the pre-fix assigned again ? I know of the Test Pre-fixes, but I was hoping for a more long term solution. All links to the RIPE-NCC 6bone are blocked ,( that I have found ...). PS. Latest IP 6 router code, and "Heavy Metal" to run it..... From RLFink@lbl.gov Thu Sep 4 19:03:15 1997 From: RLFink@lbl.gov (Bob Fink) Date: Thu, 4 Sep 1997 11:03:15 -0700 Subject: Release 5.2 is now available In-Reply-To: <9709040230.AA03454@wasted.zk3.dec.com> References: Your message of "Wed, 03 Sep 1997 17:22:51 MST." Message-ID: At 7:30 PM -0700 9/3/97, bound@zk3.dec.com wrote: >Bob, > >I understand that and agree with you. I did not say the date had to be >anytime? But I think sometime should be selected. > >I suggest you or someone (I will help you if you like) contact all >implementations and ask them when they can support the new stuff??? > >Then we pick a date? > >The hidden agenda I am working is as follows: > >We have new addr arch and we got to transition. We are also maybe going >to change the DNS AAAA records via IPng WG. What I don't think we >should do is have to "deploy" IPv6 in a production manner with backward >compatible thingees from a test bed ..........I think this is not wise >as a strategy. Transitioning v4 to v6 will be difficult enough without >doing v6 to v6 too. > >What do you think? I couldn't agree more. As for contacting all implementations, I'll start with a call to the 6bone list for any and all to comment on if they can make the conversion in the originally agreed timeframe of 1 Oct to 1 Nov, and if not, when it might be expected. Thanks, Bob From Marc.Blanchet@viagenie.qc.ca Thu Sep 4 19:33:38 1997 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Thu, 04 Sep 1997 14:33:38 -0400 Subject: survey on expected transition dates for the 6bone In-Reply-To: Message-ID: <3.0.1.32.19970904143338.0292c148@mail.viagenie.qc.ca> > >So...my question is, is this reasonable? > Yes for me. I have two sites that want to be leafs from me. I've asked them to wait (anyway they are not totally ready) until the new addressing structure to be in place. Less efforts for them and me. > >I would like to ask 6bone participants (all sites, not just backbone sit= es) >to send to this list their estimate of ability to convert to the new >address format, and when they believe it could be done. > I finally got (yesterday) the code from cisco. (side note: when you don't have the good name, you can spend a lot of time in searching into a large organisation to get the little thing you need... Thanks Dalen and Pedro..= . =20 So, I intend to make tests on the next two weeks with the cisco, complete DNS config and delegation, and then convert to the new addressing structu= re for 1st october. After, I will connect to the other bb sites with bgp4 wi= th the new addressing structure and then after my leaf sites.=20 This is my plan, if it works with the schedule of other bb sites. Regards, Marc. ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagenie inc. | http://www.viagenie.qc.ca 3107 des hotels | tel.: 418-656-9254=20 Ste-Foy, Quebec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp: 57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifi=E9, Editions Logiques, 1997 ------------------------------------------------------------ From dlee@visc.vt.edu Thu Sep 4 20:16:06 1997 From: dlee@visc.vt.edu (David Lee) Date: Thu, 4 Sep 1997 15:16:06 -0400 (EDT) Subject: survey on expected transition dates for the 6bone In-Reply-To: from "Bob Fink" at Sep 4, 97 08:10:12 am Message-ID: <199709041916.PAA20082@ocarina.visc.vt.edu> > "4. that the old testing addresses (RFC 1897) be discontinued on the > backbone as early as October 1 (by sites already renumbered) and not later > than November 1 when the newly addressed backbone is scheduled to be fully > online." > === > > So...my question is, is this reasonable? > > I would like to ask 6bone participants (all sites, not just backbone sites) > to send to this list their estimate of ability to convert to the new > address format, and when they believe it could be done. It'll probably take us no later than a week to renumber the Virginia Tech site, from the time I get a SLA, and verify that everything from DNS and connectivity to our providers works. -- David C. Lee - Ph.D. Candidate - ECE Instructor - Email dlee@vt.edu URL http://www.visc.vt.edu/~dlee - Phone 1-540-231-8398 - Fax 1-540-231-3362 Bradley Department of Electrical and Computer Engineering, Virginia Tech 475 Whittemore Hall, Blacksburg, Virginia 24061-0111 From RLFink@lbl.gov Thu Sep 4 22:55:37 1997 From: RLFink@lbl.gov (Bob Fink) Date: Thu, 4 Sep 1997 14:55:37 -0700 Subject: Interested in joining 6 Bone In-Reply-To: <340EF20E.7229@onecall.net> Message-ID: Richard, At 10:38 AM -0700 9/4/97, Richard Irving wrote: >One Call Communications, and Indiana based company is interested in >joining the 6Bone. I would be interested in building a tunnel to >someone.... Our ATM currently has its most open Circuits in Chicago. >(The CHI NAP). If your company is interested, (or University) let me >know. As we are in a transition stage on the 6bone for now (converting to the new aggregatable address format), I would suggest waiting until November (when it might be done) and ask again. > P.S. Where do I go to get the pre-fix assigned again ? I know of the >Test Pre-fixes, but I was hoping for a more long term solution. All >links to the RIPE-NCC 6bone are blocked ,( that I have found ...). Only test addess allocations are available at this time. The old 6bone registry at RIPE-NCC is gone, and is replaced by teh RIPE-style registry at ISI.EDU. Look at the 6bone home page for relevant pointers. http://www.6bone.net Thanks, Bob From RLFink@lbl.gov Fri Sep 5 15:31:09 1997 From: RLFink@lbl.gov (Bob Fink) Date: Fri, 5 Sep 1997 07:31:09 -0700 Subject: survey on expected transition dates for the 6bone - more Message-ID: When you respond to my question on conversion to the new address format, please let me know what implementation you are referring to. Some of the responses have left me guessing. Also, will the implementation support EUI-64? Thanks, Bob From RLFink@lbl.gov Fri Sep 5 15:28:35 1997 From: RLFink@lbl.gov (Bob Fink) Date: Fri, 5 Sep 1997 07:28:35 -0700 Subject: keeping Aggregatable registry In-Reply-To: <199709051317.PAA00575@titan.urec.fr> Message-ID: Bernard, At 6:17 AM -0700 9/5/97, Bernard TUY wrote: ... > The question I have is about delegation of parts of the prefix I >could get. > If I correctly understood what has been discussed before, as soon >as one > gets a prefix he has to maintain an Internet Registry to let everybody > knows the sub delegations he has performed. > So what format do we have to use (RIPE, ...) ? Are they tools already > available to facilitate these registration processes ? Each entity getting a piece of the aggregatable number space must maintain a registry for that below them. So that means a TLA (pTLA in our case) keeps track of its assignments, and if an NLA under it allocates below itself, then that NLA must also keep a registry. Your question on format is a good one. David Kessens might suggest one as he has said he can help provide the service using his 6bone registry. Myself, I'm doing the dumb and simple 'keep a text list' approach, see: http://www.6bone.net/6bone_pTLA_list.html I would be happy to have someone suggest a better format than mine, and I'll chnage to it. My guess is that not everyone will want to use either the 6bone registry (in a RIPE-style format) or a simple text list, so maybe having both is a good idea. Comments? Thanks, Bob From davidk@ISI.EDU Fri Sep 5 21:15:49 1997 From: davidk@ISI.EDU (davidk@ISI.EDU) Date: Fri, 5 Sep 1997 13:15:49 -0700 (PDT) Subject: keeping Aggregatable registry In-Reply-To: from "Bob Fink" at Sep 5, 97 07:28:35 am Message-ID: <9709052015.AA06079@brind.isi.edu> Bob, Bob Fink writes: > > Your question on format is a good one. David Kessens might suggest one as > he has said he can help provide the service using his 6bone registry. There are a couple of ways to do this: - The DNS reverse zone might be a good place to put this data - The 6bone registry can be used The 6bone registries already has most (if not all) of the support needed. There are two possibilities for doing this: We use the ipv6-site object which contains the 'prefix:' attribute which can be used to document the used prefixes. Currently everybody can just choose there own prefixes, but I can build in support that one needs approval first of the address space manager (SLA level n-1) to *create* such a prefix: attribute. It would be needed that the SLA manager at level n would also need an 'ipv6-site:' object. However, a cleaner solution is separating the notion of objects that describe which addresses *may* be used by somebody and keep the site objects for describing which address space is actually being routed and how. This is in fact how it is currently being done for IPv4 address space. IPv4 registries have information who can use what (InterNIC, RIPE, APNIC) and routing registries (RA, MCI, RIPE, CANET, ANS) have information on what is actually using what, where and how. This solution would reflect reality better, but might be viewed too complicated. The current software already has support for both type of objects, the 'ipv6-site:' objects are the routing registry type of objects and the 'inet6num:' objects for describing allocations/assignments of address space. I haven't made the 'inet6num:' public yet since we never had a need for it. Below follows a formal description: inet6num: [mandatory] [single] IPv6 prefix netname: [mandatory] [single] name of the TLA/SLA descr: [mandatory] [multiple] description of TLA/SLA country: [mandatory] [multiple] space separated list of ISO country codes admin-c: [mandatory] [multiple] NIC handle for administrative contact tech-c: [mandatory] [multiple] NIC handle for technical contact rev-srv: [optional] [multiple] nameserver for reverse domain, could be used by Bill or others to build the reverse zone! remarks: [optional] [multiple] same as in ipv6-site objects notify: [optional] [multiple] E-mail address gets notification message when somebody changes the object mnt-by: [optional] [multiple] pointer to maintainer object which describes who can update the object, everybody can do updates if you don't use this, however you can use the 'notify:' attribute to make sure you know about the fact. mnt-lower: [optional] [multiple] pointer to maintainer object which describes who is allowed to *create* objects for SLAs part of the 'inet6num:' object changed: [mandatory] [multiple] same as in ipv6-site objects source: [mandatory] [single] equal to 6BONE We could start with creating the following objects: inet6num: 0::/0 netname: The Mother of All Address Space ... mnt-by: IANA mnt-lower: IANA inet6num: 3FFE:0::/16 netname: TestAddressSpace ... mnt-by: BobFink-MNT mnt-lower: BobFink-MNT inet6num: 3FFE:0::/24 netname: INNER-TLA0 ... mnt-by: INNER-TLA0-MNT mnt-lower: INNER-TLA0-MNT inet6num: 3FFE:0::/32 netname: CustomerINNER-TLA0-SLA0 ... mnt-by: CustomerINNER-TLA0-SLA0-MNT mnt-lower: CustomerINNER-TLA0-SLA0-MNT and so on ... > Myself, I'm doing the dumb and simple 'keep a text list' approach, see: > > http://www.6bone.net/6bone_pTLA_list.html > > My guess is that not everyone will want to use either the 6bone registry > (in a RIPE-style format) or a simple text list, so maybe having both is a > good idea. It always make sense to keep such a short simple and authoritative list to check who is right in case of conflicts that might but should not happen. Please let me know what your view is, as the best thing to do, David K. --- From Luca.dellAgnello@cnaf.infn.it Tue Sep 9 14:34:51 1997 From: Luca.dellAgnello@cnaf.infn.it (Luca dell'Agnello) Date: Tue, 9 Sep 1997 15:34:51 +0200 (MET DST) Subject: request for pTLA Message-ID: Request for a pTLA ID --------------------- Our organization, INFN-CNAF, acts as Local Internet Registry (LIR) for GARR network, the Italian research and academic network (we distribute ipv4 network addresses). Moreover international circuits of the GARR network are located at=A0INFN-C= NAF: - 34 Mb/s link to TEN-34 network (European research and academic network);= =20 - 4 Mb/s links to US (T1 to ESnet and E1 to Internet MCI/WIN). Our experience in 6BONE started last February; we have 2 international tunnels:=20 - ESNET-US; - JOIN-DE, with a very good performance (40 ms avg.). Due to GARR international circuits, we are going to add new tunnels with international sites and become a 6BONE backbone site; so we will provide 6BONE connectivity to any other GARR site (we planned to move our 6BONE router to get a more stable and managed configuration). Our main interest is gaining experience in transition mechanism, IPv6 routing protocols and implementations, and applications over 6BONE; moreover, since we act as IPv4 address delegation and registry for all GARR sites, we need to learn how to plan IPv6 GARR addressing. Please feel free to send us any questions and comments. Thanks Cristina Vistoli Luca dell'Agnello From jane@iaeste.no Tue Sep 9 15:08:19 1997 From: jane@iaeste.no (Jan Marius Evang) Date: 09 Sep 1997 16:08:19 +0200 Subject: Cisco IPv6 setup Message-ID: Hi! We are thinking about purchasing a couple of Cisco 7206 routers, and wonder wether they will reliably run IPv6. Which IOS versions are needer? beta? will they give us betas? Wich other nettcomponents are neccessary? Nameservers? IPv6/IPv4 agents? More specifically, we are interrested in what we need for IPv6, RSVP and ATM in these routers (plus of course 100mbps Ethernet) yours Jan Marius Evang -- -O Rxyskatt From RLFink@lbl.gov Tue Sep 9 16:28:42 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 9 Sep 1997 09:28:42 -0600 Subject: pTLA list as of 9Sep97 Message-ID: Below is the current pseudo TLA (pTLA) List as of 9 September 1997,with two new sites added: STUBA and INFN-CNAF. http://www.6bone.net/6bone_pTLA_list.html I still see no 6bone registry entries for MREN, 3COM and VERIO. I would suggest these three sites register very soon as participation in the 6bone backbone will require registration. Thanks, Bob ========================================== INNER 3FFE:0000::/24 TELEBIT 3FFE:0100::/24 SICS 3FFE:0200::/24 G6 3FFE:0300::/24 JOIN 3FFE:0400::/24 WIDE 3FFE:0500::/24 SURFNET 3FFE:0600::/24 ESNET 3FFE:0700::/24 CICNET 3FFE:0800::/24 ISI-LAP 3FFE:0900::/24 NWNET 3FFE:0A00::/24 VIAGENIE 3FFE:0B00::/24 CISCO 3FFE:0C00::/24 ANS 3FFE:0D00::/24 IFB 3FFE:0E00::/24 NRL/US 3FFE:0F00::/24 CSELT 3FFE:1000::/24 UUNET 3FFE:1100::/24 DIGITAL-CA 3FFE:1200::/24 BAY 3FFE:1300::/24 UNI-C 3FFE:1400::/24 UO 3FFE:1500::/24 NUS-IRDU 3FFE:1600::/24 MREN 3FFE:1700::/24 (no 6bone registry entry) INTEROP 3FFE:1800::/24 3COM 3FFE:1900::/24 (no 6bone registry entry) CAIRN 3FFE:1A00::/24 VERIO 3FFE:1B00::/24 (no 6bone registry entry) MERIT 3FFE:1C00::/24 ATT-LABS-EUROPE 3FFE:1D00::/24 SWISS-TELECOM 3FFE:1E00::/24 NETCOM-UK 3FFE:1F00::/24 SWITCH 3FFE:2000::/24 JANET 3FFE:2100::/24 STUBA 3FFE:2200::/24 INFN-CNAF 3FFE:2300::/24 -end From RLFink@lbl.gov Tue Sep 9 22:28:24 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 9 Sep 1997 15:28:24 -0600 Subject: corrected pTLA list - 9Sep97 #2 Message-ID: Guy Davies pointed out I was not using correct 6bone registry site object names. So I've corrected a handfull on the list below and posted it to the web as well. http://www.6bone.net/6bone_pTLA_list.html Thanks, Bob =================================== INNER 3FFE:0000::/24 TELEBIT 3FFE:0100::/24 SICS 3FFE:0200::/24 G6 3FFE:0300::/24 JOIN 3FFE:0400::/24 WIDE 3FFE:0500::/24 SURFNET 3FFE:0600::/24 ESNET 3FFE:0700::/24 CICNET 3FFE:0800::/24 ISI-LAP 3FFE:0900::/24 NWNET 3FFE:0A00::/24 VIAGENIE 3FFE:0B00::/24 CISCO 3FFE:0C00::/24 ANSNET 3FFE:0D00::/24 IFB 3FFE:0E00::/24 NRL 3FFE:0F00::/24 CSELT 3FFE:1000::/24 UUNET-UK 3FFE:1100::/24 DIGITAL-CA 3FFE:1200::/24 BAY 3FFE:1300::/24 UNI-C 3FFE:1400::/24 UO 3FFE:1500::/24 NUS-IRDU 3FFE:1600::/24 MREN 3FFE:1700::/24 (no 6bone registry entry) INTEROP 3FFE:1800::/24 3COM 3FFE:1900::/24 (no 6bone registry entry) CAIRN 3FFE:1A00::/24 VERIO 3FFE:1B00::/24 (no 6bone registry entry) MERIT 3FFE:1C00::/24 ATT-LABS-EUROPE 3FFE:1D00::/24 SWISS-TELECOM 3FFE:1E00::/24 NETCOM-UK 3FFE:1F00::/24 SWITCH 3FFE:2000::/24 JANET 3FFE:2100::/24 STUBA 3FFE:2200::/24 INFN-CNAF 3FFE:2300::/24 -end From RLFink@lbl.gov Tue Sep 9 23:03:39 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 9 Sep 1997 16:03:39 -0600 Subject: Cisco IPv6 setup In-Reply-To: Message-ID: At 8:08 AM -0600 9/9/97, Jan Marius Evang wrote: >Hi! >We are thinking about purchasing a couple of Cisco 7206 routers, and >wonder wether they will reliably run IPv6. > >Which IOS versions are needer? beta? will they give us betas? Wich >other nettcomponents are neccessary? Nameservers? IPv6/IPv4 agents? > >More specifically, we are interrested in what we need for IPv6, RSVP >and ATM in these routers (plus of course 100mbps Ethernet) Please try asking: mmcneali@cisco.com (Martin Mcnealis Cisco) He is the Cisco IPv6 product manager. Bob From mmcnealis@cisco.com Wed Sep 10 03:52:18 1997 From: mmcnealis@cisco.com (Martin McNealis) Date: Tue, 09 Sep 1997 19:52:18 -0700 Subject: Cisco IPv6 setup Message-ID: <2.2.32.19970910025218.01bce100@puli.cisco.com> Hi Jan, Comments inline:- >At 8:08 AM -0600 9/9/97, Jan Marius Evang wrote: >> >>Hi! >> >>We are thinking about purchasing a couple of Cisco 7206 routers, and >>wonder wether they will reliably run IPv6. Of course :-) >>Which IOS versions are needer? beta? will they give us betas? Wich >>other nettcomponents are neccessary? Nameservers? IPv6/IPv4 agents? Currently our IOS IPv6 Beta version, which now incorpates IPv6 <---> IPv4 NAT functionality. >>More specifically, we are interrested in what we need for IPv6, RSVP >>and ATM in these routers (plus of course 100mbps Ethernet) Please let me know your specific configuration, however RSVP support is not integrated with our current IOS IPv6 implementation. Cheers, -Martin- From jane@iaeste.no Wed Sep 10 08:44:22 1997 From: jane@iaeste.no (Jan Marius Evang) Date: 10 Sep 1997 09:44:22 +0200 Subject: Cisco IPv6 setup In-Reply-To: Martin McNealis's message of Tue, 09 Sep 1997 19:52:18 -0700 References: <2.2.32.19970910025218.01bce100@puli.cisco.com> Message-ID: >> Martin McNealis writes: MM> Hi Jan, MM> Comments inline:- >>> We are thinking about purchasing a couple of Cisco 7206 routers, >>> and wonder wether they will reliably run IPv6. MM> Of course :-) good :-) >>> Which IOS versions are needer? beta? will they give us betas? >>> Wich other nettcomponents are neccessary? Nameservers? IPv6/IPv4 >>> agents? MM> Currently our IOS IPv6 Beta version, which now incorpates IPv6 MM> <---> IPv4 NAT functionality. >>> More specifically, we are interrested in what we need for IPv6, >>> RSVP and ATM in these routers (plus of course 100mbps Ethernet) MM> Please let me know your specific configuration, however RSVP MM> support is not integrated with our current IOS IPv6 MM> implementation. We are currently in the "funding" phase, and wonder wether this is the right choise to ask for money for :-) Current plans: Cisco 7206 NPE 150 16MB (CPU card) IO card (with 100Mbit ethernet) Cisco 100 Mbit ethernet module Cisco 1 port ATM module OC-3 (two routers of this configuration) Marius -- -O Rxyskatt From dragon@dcn.soongsil.ac.kr Wed Sep 10 13:55:45 1997 From: dragon@dcn.soongsil.ac.kr (kim yong sin) Date: Wed, 10 Sep 1997 21:55:45 +0900 Subject: Q:DNS server implement Message-ID: <3.0.1.32.19970910215545.00699c54@dcn.soongsil.ac.kr> I'm tring config DNS server for ipv6. 1. BIND version 8.1.1 is support AAAA type. ---> download 2. make (compile) 3. make 'zone file' for domain (q1: Can I involve ipv4 and ipv6 hosts information into same zone file?) anyway, i write ipv4 and ipv6 hosts into same zone file. For 'nslookup', it operates well. 4. for client, first it searchs 'hosts' file, and if don't exist that host name then it sends 'query' message to DNS server. (q2: Does client sends 'query' message using ipv6 packet?) (q3: This case, Which 'resolv.conf' file contains DNS server address ipv6 or ipv4 addr?) 5. If DNS server can't find that host name, it send to other DNS server (q4: Which DNS server for ipv6 avilable?) If i can't config DNS server, i hope using resolver-only client and query to avilable server Thanks From RLFink@lbl.gov Wed Sep 10 15:56:04 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 10 Sep 1997 08:56:04 -0600 Subject: corrected pTLA list - 9Sep97 #2 In-Reply-To: <199709100426.AA29081@zephyr.isi.edu> References: from "Bob Fink" at Sep 9, 97 03:28:24 pm Message-ID: Bill, At 10:26 PM -0600 9/9/97, Bill Manning wrote: >Bob, > While you were out, it was determined that you had made a typo > in the first list and I had gon ahead and turned on ISI-LAP at > 0800 and got CIC agreement to run at 0900. Please make the changes. Thanks for letting me know. I have changed the list, and have also corrected the 6bone registry's new inet6num objects to reflect this (I'll announce all that stuff later today). > Also, less than half the ptla assignments have turned in delegation > requests. When they do, there are a couple of things which I am > asking for and there will be a few more that I will begin to insist > on. > > - I will ask for the delegates PGP key > - I will ask for 6bone registry entries > - I will ask for sites that agree to sign their delegations. This sounds reasonable to me. The registry entries are essential and I will insist on this specifically. Not having MREN, 3COM and VERIO registry entries has already meant that we can't delegate their pTLA to them using the new inet6num registry object. Thanks, Bob ==== INNER 3FFE:0000::/24 TELEBIT 3FFE:0100::/24 SICS 3FFE:0200::/24 G6 3FFE:0300::/24 JOIN 3FFE:0400::/24 WIDE 3FFE:0500::/24 SURFNET 3FFE:0600::/24 ESNET 3FFE:0700::/24 ISI-LAP 3FFE:0800::/24 CICNET 3FFE:0900::/24 NWNET 3FFE:0A00::/24 VIAGENIE 3FFE:0B00::/24 CISCO 3FFE:0C00::/24 ANSNET 3FFE:0D00::/24 IFB 3FFE:0E00::/24 NRL 3FFE:0F00::/24 CSELT 3FFE:1000::/24 UUNET-UK 3FFE:1100::/24 DIGITAL-CA 3FFE:1200::/24 BAY 3FFE:1300::/24 UNI-C 3FFE:1400::/24 UO 3FFE:1500::/24 NUS-IRDU 3FFE:1600::/24 MREN 3FFE:1700::/24 (no 6bone registry entry) INTEROP 3FFE:1800::/24 3COM 3FFE:1900::/24 (no 6bone registry entry) CAIRN 3FFE:1A00::/24 VERIO 3FFE:1B00::/24 (no 6bone registry entry) MERIT 3FFE:1C00::/24 ATT-LABS-EUROPE 3FFE:1D00::/24 SWISS-TELECOM 3FFE:1E00::/24 NETCOM-UK 3FFE:1F00::/24 SWITCH 3FFE:2000::/24 JANET 3FFE:2100::/24 STUBA 3FFE:2200::/24 INFN-CNAF 3FFE:2300::/24 ==== inet6num: 3FFE:800::/24 netname: ISI-LAP descr: pTLA delegation for the 6bone country: US admin-c: BM2-6BONE tech-c: BM2-6BONE remarks: changed from 0900 on 10Sep97 mnt-by: MNT-ISI-LAP mnt-lower: MNT-ISI-LAP changed: RLFink@lbl.gov 19970910 source: 6BONE ==== inet6num: 3FFE:900::/24 netname: CICNET descr: pTLA delegation for the 6bone country: US admin-c: DK1-6BONE tech-c: IT1-6BONE remarks: changed from 0800 on 10Sep97 mnt-by: MNT-CICNET mnt-lower: MNT-CICNET changed: RLFink@lbl.gov 19970910 source: 6BONE -end From RLFink@lbl.gov Wed Sep 10 18:15:30 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 10 Sep 1997 11:15:30 -0600 Subject: new 6bone test address registry facility started up Message-ID: 6bone folk, David Kessens has setup his new inet6num object in the 6bone registry to allow us to assign, with delegation, the new IPv6 test addresses. To this end, a top level object has been assigned to me for the new test TLA with a netname of TEST-TLA-6BONE, with an inet6num value of 3FFE::/16 (see below). You can reference this object, as well as other new inet6num objects, by using the 6bone whois query: http://www.6bone.net/whois.html This object is the owner, if you will, of all objects below it. However, it is my intention to assign pTLAs as delegated objects and then let them sub-delegate. Thus I have created (with some automatic help from David Kessens) the pTLA objects below the test TLA. I have shown a sample object below (the one for TELEBIT). All pTLAs have been assigned using their existing 6bone registry ipv6-name as their netname within the inet6num object. The exceptions to this are MREN, 3COM and VERIO which have not made their 6bone registry entries yet. They must create their 6bone registry entries if they wish to use their pTLA assignment (I will create their inet6num objects as soon as their entries are created). You should note that the "mnt-by" and "mnt-lower" fields are set to a new maintainer object created for your site that has the name "MNT-netname" with the value set to the "notify" value for your site. You can change this as you will, but the important thing to note is that the "mnt-lower" assignment is the person that gets to delegate other inet6num objects below your site's pTLA assignment. I think this is enough for now to get you thinking. Please address questions to the list, copied to David and me, so we can all learn. Thanks, Bob ============================================= inet6num: 3FFE::/16 netname: TEST-TLA-6BONE descr: Test Address Space for the 6bone country: AT AU BE CA CH DE DK ES FI FR GB country: HU IE IT JP KR KZ NL NO PL PT RO RU country: SE SG SK TW US admin-c: RLF1-6BONE tech-c: BM2-6BONE tech-c: DK13-RIPE rev-srv: ns.isi.edu rev-srv: imag.imag.fr remarks: contact RLF1-6BONE for allocation of a pTLA remarks: contact BM2-6BONE for reverse delegations remarks: contact DK13-RIPE for issues regarding the 6bone registry remarks: version 3 mnt-by: RLF1-6BONE mnt-lower: RLF1-6BONE changed: davidk@ISI.EDU 19970908 changed: rlfink@lbl.gov 19970909 source: 6BONE ========================== inet6num: 3FFE:100::/24 netname: TELEBIT descr: pTLA delegation for the 6bone country: DK admin-c: HHA1-6BONE tech-c: HHA1-6BONE mnt-by: MNT-TELEBIT mnt-lower: MNT-TELEBIT changed: RLFink@lbl.gov 19970909 source: 6BONE -end From bortzmeyer@pasteur.fr Thu Sep 11 08:47:03 1997 From: bortzmeyer@pasteur.fr (Stephane Bortzmeyer) Date: Thu, 11 Sep 97 09:47:03 +0200 Subject: Q:DNS server implement In-Reply-To: <3.0.1.32.19970910215545.00699c54@dcn.soongsil.ac.kr> (kim yong sin 's message of Wed, 10 Sep 97 21:55:45 +0900) Message-ID: <199709110747.JAA10545@josephine.sis.pasteur.fr> On Wednesday 10 September 97, at 21 h 55, the keyboard of kim yong sin wrote: > 3. make 'zone file' for domain > (q1: Can I involve ipv4 and ipv6 hosts information into same zone file?) Yes. Example: josephine IN A 157.99.60.23 IN AAAA 5f06:b500:9d63:3c00:1:800:2b38:703b josephine-v6 IN AAAA 5f06:b500:9d63:3c00:1:800:2b38:703b > For 'nslookup', it operates well. I prefer dig. > (q2: Does client sends 'query' message using ipv6 packet?) No (unless you have an IPv6 resolver). You can serve IPv6 data with a IPv4 BIND (and vice-versa, but I dont' think there is an IPv6 DNS server yet). > (q3: This case, Which 'resolv.conf' file contains DNS server address ipv6 > or ipv4 addr?) IPv4 (see above). From jinsuh@dcn.soongsil.ac.kr Thu Sep 11 10:09:20 1997 From: jinsuh@dcn.soongsil.ac.kr (Jinsuh shin) Date: Thu, 11 Sep 1997 18:09:20 +0900 Subject: Q : How can I use Security & Authentication Header?? Message-ID: <3.0.1.32.19970911180920.006b5498@dcn.soongsil.ac.kr> As you know, there are several extension header include security & authentication in IPv6.. so, If these extension headers are implemented, how can I use Security & Authentication header in application level?? I think that users must be able to use these extension header in application level..For example, telnet or ftp... But I don't know how?? please, tell me when and how?? thank you.. phone : 02 -573 - 9077 From martynas@vingis.sc-uni.ktu.lt Thu Sep 11 13:42:12 1997 From: martynas@vingis.sc-uni.ktu.lt (Martynas Buozis) Date: Thu, 11 Sep 1997 15:42:12 +0300 Subject: No subject Message-ID: <3417E724.2E52C963@vingis.sc-uni.ktu.lt> From RLFink@lbl.gov Thu Sep 11 22:55:48 1997 From: RLFink@lbl.gov (Bob Fink) Date: Thu, 11 Sep 1997 15:55:48 -0600 Subject: status of conversion for 6bone backbone sites Message-ID: I have used the manual text pTLA assignment list to tally the status of conversion for 6bone pTLA sites (see below). Only a few sites have sent me their status, and what hasn't been said (generally) is if the conversion includes EUI-64. So...6bone pTLA sites, please send me your status of conversion. I would also appreciate it if you state your disposition re EUI-64, and what vendor or system is preventing your being ready by October for conversion. Thanks, Bob ==== from http://www.6bone.net/6bone_pTLA_list.html ipv6-site name test prefix status for conversion -------------- -------------- ------------------------ INNER 3FFE:0000::/24 converted TELEBIT 3FFE:0100::/24 SICS 3FFE:0200::/24 G6 3FFE:0300::/24 JOIN 3FFE:0400::/24 WIDE 3FFE:0500::/24 SURFNET 3FFE:0600::/24 ESNET 3FFE:0700::/24 ISI-LAP 3FFE:0800::/24 CICNET 3FFE:0900::/24 NWNET 3FFE:0A00::/24 VIAGENIE 3FFE:0B00::/24 ready by Oct 1 CISCO 3FFE:0C00::/24 ANSNET 3FFE:0D00::/24 IFB 3FFE:0E00::/24 ready by Oct 1 NRL 3FFE:0F00::/24 converted CSELT 3FFE:1000::/24 UUNET-UK 3FFE:1100::/24 DIGITAL-CA 3FFE:1200::/24 BAY 3FFE:1300::/24 ready by mid-Oct UNI-C 3FFE:1400::/24 UO 3FFE:1500::/24 NUS-IRDU 3FFE:1600::/24 MREN 3FFE:1700::/24 INTEROP 3FFE:1800::/24 3COM 3FFE:1900::/24 CAIRN 3FFE:1A00::/24 VERIO 3FFE:1B00::/24 (no 6bone registry entry) MERIT 3FFE:1C00::/24 ATT-LABS-EUROPE 3FFE:1D00::/24 ready by Oct 1 ?? SWISS-TELECOM 3FFE:1E00::/24 NETCOM-UK 3FFE:1F00::/24 SWITCH 3FFE:2000::/24 JANET 3FFE:2100::/24 STUBA 3FFE:2200::/24 ready by Oct 1 INFN-CNAF 3FFE:2300::/24 -end From tom@mail.zentrum.ml.org Fri Sep 12 01:50:06 1997 From: tom@mail.zentrum.ml.org (Tom Hardy) Date: Fri, 12 Sep 1997 10:20:06 +0930 Subject: Request for connection Message-ID: <341891BE.17FE@zentrum.ml.org> Hi, Writing to find a point of connection to 6bone. Location: Adelaide, Australia Ipv4 : 203.31.34.160 Ipv6 : 5F0A:CC00:CB1F:2200::80:AD16:AD79 Kind Regards, Tom Hardy From Ivano.Guardini@CSELT.IT Fri Sep 12 09:26:45 1997 From: Ivano.Guardini@CSELT.IT (Guardini Ivano) Date: Fri, 12 Sep 1997 10:26:45 +0200 Subject: status of conversion for 6bone backbone sites Message-ID: Hi Bob, here in CSELT we have started moving to the new addressing scheme. I think that we will be ready by the end of this month but probably our conversion will not include EUI-64. At this time we have five different IPv6 implementations in our lab: Inria, NRL, Linux, Sun and Telebit (router TBC2000). We would like to move to EUI-64 when at least the Inria, Sun and Telebit implementations will be able to support it. This is because due to the new solicited node multicast addresses a machine supporting EUI-64 will not be able to interoperate with an old one. 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.it --------------------------------------------------- From Ivano.Guardini@CSELT.IT Fri Sep 12 10:05:25 1997 From: Ivano.Guardini@CSELT.IT (Guardini Ivano) Date: Fri, 12 Sep 1997 11:05:25 +0200 Subject: Some changes in CSELT tunnel configuration Message-ID: Hi all, there is a new BGP4+ capable tunnel between CSELT and UUNET-UK and we have moved to BGP4+ also over our tunnels with NRL and TELEBIT. We are advertising through these tunnels both the old (5f16:4d00::/32) and the new (3ffe:1000::/24) CSELT prefix. The last interesting change is that POLITO/IT is now a CSELT transit site and it isn't connected to DIGITAL-CA/US anymore. The connection between CSELT and POLITO is achieved by menas of a new RIPng capable high performance tunnel established over the SIRIUS italian IP over ATM network. This should help to improve the italian portion of the 6Bone network. 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.it --------------------------------------------------- From Alain.Durand@imag.fr Tue Sep 16 22:09:20 1997 From: Alain.Durand@imag.fr (Alain Durand) Date: Tue, 16 Sep 1997 23:09:20 +0200 Subject: On the peering of pTLAs... Message-ID: <970916230920.ZM1283@rama.imag.fr> Networking is so fun !!! Especially in europe ;-) I'm trying to figure out who I should peer with in the new addressing plan. I know the connection from Renater/france to the US is &*^*&^*&^*&%^^%^&, so I'm looking mostly for european peers. It's late (11pm local time), networks should be quiet, time for some pings & traceroutes on the underlaying IPv4 topology. For each site, I'm giving the average RTT from G6, % of packet loss and the approximate route. IPv4 connectivity of 6bone core sites in Europe to G6: Site RTT packet route loss ---------------------------------------------------------------------------- TELEBIT/DK 244ms 0% Ten34UK-stockholm-dk SICS/SE 50ms 0% Ten34UK-stockholm-se G6/FR LOCAL JOIN/DE 45ms 0% Ten34DE-frankfort-muenster SURFNET/NL 85ms 40% Ten34UK-stockholm-amsterdam IFB/GB 605ms 20% washington-sprint-insnet-ifb CSELT/IT 300ms 20% Ten34UK-stockholm-ParisEbone-interbusinessIT UUNET-UK/GB 200ms 0% washington-pipex-UK UNI-C/dk 80ms 0% Ten34UK-stockholm-dk ATT-LABS-EUROPE/CH 460ms 0% ten34Londre-stockholm-amsterdam-unisrc-att SWISS-TELECOM/CH no valid record in database NETCOM-UK/GB 270ms 10% washington-netcom-netcomUK SWITCH/CH 40ms 0% ten34DE-ten34CH-switch JANET/GB 230ms 20% ten34UK-janet STUBA/SK 180ms 0% ten34DE-amsterdam-stockholm-munichEbone-bratislava INFN-CNAF/IT 50ms 0% ten34DE-ten34IT-infn INR/RU 2500ms 60% washington-sprint-dtag.de-moscow-inr If other sites had similar informations on their connectivity, I would be happy to get them to help me decide on the peering. - Alain. From RLFink@lbl.gov Wed Sep 17 02:39:33 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 16 Sep 1997 18:39:33 -0700 Subject: On the peering of pTLAs... In-Reply-To: <970916230920.ZM1283@rama.imag.fr> Message-ID: Alain's mail below on using RTT info for helping to determine optimal backbone peering is a good one. Has anyone thought of good ways/metrics to decide how pTLA sites can determine what other pTLA sites to peer with to avoid the old backbone mode of everyone just trying to peer with everyone? My hope in all this conversion/backbone-cleanup is that we gain the necessary reliability to have a reliable backbone. pTLA sites need to be ready to provide reliable service! (sorry to preach :-) Anyway, ideas and suggestions needed (to the list please), and appreciated. Thanks, Bob ============================================= At 2:09 PM -0700 9/16/97, Alain Durand wrote: >Networking is so fun !!! Especially in europe ;-) > >I'm trying to figure out who I should peer with in the new addressing plan. >I know the connection from Renater/france to the US is &*^*&^*&^*&%^^%^&, >so I'm looking mostly for european peers. > >It's late (11pm local time), networks should be quiet, time for some pings & >traceroutes on the underlaying IPv4 topology. > >For each site, I'm giving the average RTT from G6, % of packet loss >and the approximate route. > >IPv4 connectivity of 6bone core sites in Europe to G6: > >Site RTT packet route > loss >---------------------------------------------------------------------------- >TELEBIT/DK 244ms 0% Ten34UK-stockholm-dk >SICS/SE 50ms 0% Ten34UK-stockholm-se >G6/FR LOCAL >JOIN/DE 45ms 0% Ten34DE-frankfort-muenster >SURFNET/NL 85ms 40% Ten34UK-stockholm-amsterdam >IFB/GB 605ms 20% washington-sprint-insnet-ifb >CSELT/IT 300ms 20% Ten34UK-stockholm-ParisEbone-interbusinessIT >UUNET-UK/GB 200ms 0% washington-pipex-UK >UNI-C/dk 80ms 0% Ten34UK-stockholm-dk >ATT-LABS-EUROPE/CH 460ms 0% ten34Londre-stockholm-amsterdam-unisrc-att >SWISS-TELECOM/CH no valid record in database >NETCOM-UK/GB 270ms 10% washington-netcom-netcomUK >SWITCH/CH 40ms 0% ten34DE-ten34CH-switch >JANET/GB 230ms 20% ten34UK-janet >STUBA/SK 180ms 0% >ten34DE-amsterdam-stockholm-munichEbone-bratislava >INFN-CNAF/IT 50ms 0% ten34DE-ten34IT-infn >INR/RU 2500ms 60% washington-sprint-dtag.de-moscow-inr > >If other sites had similar informations on their connectivity, >I would be happy to get them to help me decide on the peering. > > - Alain. From Alain.Durand@imag.fr Wed Sep 17 12:51:07 1997 From: Alain.Durand@imag.fr (Alain Durand) Date: Wed, 17 Sep 1997 13:51:07 +0200 Subject: On the peering of pTLAs... In-Reply-To: Guy Davies "Re: On the peering of pTLAs..." (Sep 17, 12:06pm) References: <970916230920.ZM1283@rama.imag.fr> <341FB9C3.C4055DEC@uk.uu.net> Message-ID: <970917135107.ZM2518@rama.imag.fr> On Sep 17, 12:06pm, Guy Davies wrote: > Here's a similar list for UUNET-UK. I've also added the total number of > hops as this could have some bearing on choice of route. My preferred > routes would, I guess be those which don't cross the Atlantic twice to > reach the destination (sorry, Alain ;-) > > Based on that, my preferred EU peers would be telebit, sics, surfnet, > ifb, cselt, uni-c, netcom-uk, janet and stuba. However, some of the > RTTs in that list are pretty poor (although loss is generally fairly > low) > > Based purely on RTT, the favourites are telebit, sics, surfnet, ifb, > uni-c, netcom-uk and janet (all sub 200ms). I think, given that most of > the first list appear in the second list and that I already peer with > all the first list, I'll stick with that for now.... In fact, the only > one I peer with who's not in the list is G6 who had better connectivity > to us when we started the peering (not sure why out traffic now goes via > the states rather than straight across Ebone) Guy, Duncan, As it seems G6 has a poor connectivity with UUNET-UK and both G6 & UUNET-UK have good connectivity to JANET, It will make sense to remove the G6 <-> UUNET-UK tunnel and that guy & I directly peer with you. So Duncan, could you announce me all the GPG4+ 3ffe... routes? - Alain. From Ivano.Guardini@CSELT.IT Thu Sep 18 15:07:04 1997 From: Ivano.Guardini@CSELT.IT (Guardini Ivano) Date: Thu, 18 Sep 1997 16:07:04 +0200 Subject: On the peering of pTLAs... Message-ID: Hi all, here in CSELT we have been collecting IPv6 and IP4 reachability statistics towards all the 6Bone backbone sites since the beginning of this year. I think that in order to understand the quality of a connection a single measurement is not enough but the average over a significative period of time should be considered. Therefore I present here the average pkt. loss and RTT over the last 2 weeks for most of the core sites. Thinking that a single figure describing the quality of the connection may be helpful I tryed to define a single quality factor taking into account both loss and RTT. The quality factor I have figured out is an estimate of the probability Q(RTTmax) to get the answer to an ECHO Request within RTTmax ms. The factor depends on the value chosen for RTTmax. Clearly if we raise RTTmax the weigth given to the RTT value decreases and if RTTmax -> infinity then Q(RTTmax) -> 1-Loss = Availability. On the contrary if we decrease RTTmax the weight of the RTT value increases. You can see in the following table the values I obtained with RTTmax=300 ms and RTTmax=400 ms. Site av. Loss av. RTT Q(300) Q(400) -------------------------------------------- VIAGENIE 1,68% 303,75 0,762 0,866 CISCO 5,32% 352,08 0,454 0,765 NRL 6,26% 372,06 0,388 0,715 CICNET 6,76% 332,75 0,575 0,766 ESNET 7,38% 348,19 0,449 0,788 DIGITAL-CA 7,59% 389,68 0,341 0,685 ISI-LAP 8,01% 371,01 0,170 0,755 ANSNET 8,16% 377,74 0,620 0,758 BAY 8,78% 535,40 0,095 0,292 NWNET 11,26% 462,08 0,126 0,633 WIDE 13,94% 491,97 0,000 0,026 UNI-C 15,90% 324,81 0,535 0,708 SURFNET 24,84% 320,49 0,474 0,653 UUNET-UK 25,16% 383,51 0,183 0,576 SWITCH 26,53% 393,26 0,330 0,583 SICS 27,38% 293,76 0,524 0,651 JOIN 27,97% 381,09 0,139 0,528 G6 28,80% 379,04 0,240 0,533 IFB 29,61% 865,95 0,010 0,124 TELEBIT 34,46% 548,18 0,004 0,160 I hope that this information will help to decide on peerings. 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.it --------------------------------------------------- From ipng@sunroof.Eng.Sun.COM Thu Sep 18 18:40:05 1997 From: ipng@sunroof.Eng.Sun.COM (Matt Crawford) Date: Thu, 18 Sep 1997 12:40:05 -0500 Subject: /126 or /127 -- neither! Message-ID: <199709181740.MAA02589@gungnir.fnal.gov> At the PAL1 meeting, when we were considering the 64 bit identifier which is now part of the addressing architecture, the question arose of teensy little subnets (such as /126's) for point-to-point links. I argued at the time that we have no place, and need no place, for any prefix with length in the range 65 to 127 bits, inclusive. That is, every entry in a (unicast) IPv6 routing table ought to be either a 128 bit "host route" or a prefix of 64 bits or less. I'd like to elaborate a bit on this argument. To be specific, I'm discussing the case of a point-to-point link between two routers under different organizational control. This may be a link between two sites, two ISPs, or a site and an ISP from which the site does not derive address space. Possibly what I have to say will be applicable to p-p links within an organization. Not being an enormous ISP or a seller of boxes to enormous ISPs, I enjoy a vast ignorance about operational customs. The fundamental reason that IPv4 needs a /30 for a point-to-point link is that one address is reserved to be the broadcast address on that subnet. IPv6 has no broadcast. A secondary reason is that another address is reserved as an ill-defined numeric name for the subnet itself. (I say ill-defined because so many implementations treat it as a synonym the above broadcast address.) IPv6 uses a similar bit-pattern as an anycast address for "any router on this subnet." What I've seen requested here for IPv6 is a slice of the address space to be used for non-routable /126 (or /127) prefixes to number point-to-point links. This space would carry, besides scaling problems, a weighty bureaucracy to administer assignments. It should have, therefore, an equally weighty justification. I think there is none. The alternative is for each end of a p-p link to be assigned an address out of its respective site's prefix. I believe routing protocols can perfectly well handle links whose endpoints have unrelated global-scope addresses. RIPng, for example, uses link-local next-hop addresses, and the last section of draft-bates-bgp4-multiprotocol-03.txt seems to take care of this situation quite nicely. In summary, the only capability that's lost by having no subnet allocated to a p-p link is the ability to address "either end of this link." The cost of providing that ability is to either use one of our very large /64 subnets per link, or to do great violence to the interface identifier concept in the new addressing architecture. Matt From roque@cisco.com Thu Sep 18 20:02:15 1997 From: roque@cisco.com (Pedro Marques) Date: Thu, 18 Sep 1997 12:02:15 -0700 (PDT) Subject: (IPng 4426) /126 or /127 -- neither! In-Reply-To: <199709181740.MAA02589@gungnir.fnal.gov> References: <199709181740.MAA02589@gungnir.fnal.gov> Message-ID: <199709181902.MAA04758@pedrom-ultra.cisco.com> >>>>> "Matt" == Matt Crawford writes: Matt> At the PAL1 meeting, when we were considering the 64 bit Matt> identifier which is now part of the addressing architecture, Matt> the question arose of teensy little subnets (such as /126's) Matt> for point-to-point links. I argued at the time that we have Matt> no place, and need no place, for any prefix with length in Matt> the range 65 to 127 bits, inclusive. That is because the address space should be 64 bits in length in the first place or is there any other reason that escapes me ? Matt> I'd like to elaborate a bit on this argument. To be Matt> specific, I'm discussing the case of a point-to-point link Matt> between two routers under different organizational control. I don't think p-to-p links within an organization are different. Matt> A secondary reason is that another address is reserved as an Matt> ill-defined numeric name for the subnet itself. (I say Matt> ill-defined because so many implementations treat it as a Matt> synonym the above broadcast address.) IPv6 uses a similar Matt> bit-pattern as an anycast address for "any router on this Matt> subnet." Matt> What I've seen requested here for IPv6 is a slice of the Matt> address space to be used for non-routable /126 (or /127) Matt> prefixes to number point-to-point links. The two issues aren't really related... one issue is the use of non-routable addresses for peering, another issue is the question of /127 being valid subnet lengths. The issue with /127 is as you pointed out if anycast addresses are mandatory. Matt> This space would Matt> carry, besides scaling problems, a weighty bureaucracy to Matt> administer assignments. It should have, therefore, an Matt> equally weighty justification. I think there is none. This is an argument against non-routable addresses, which i consider quite reasonable. The motivation for non-routable addresses btw is to ease "automatic" renumbering of ASes (which is something of a very unproven concept). Matt> The alternative is for each end of a p-p link to be assigned Matt> an address out of its respective site's prefix. You mean unnumbered links ? but there are good reasons to have numbered p-to-p links. I don't understand why you are mixing the p-to-p issue with the peering address issue. What if instead of a serial the peer uses an ethernet ? Do you proprose to use unnumbered ethernets too ? Matt> I believe routing protocols can perfectly well handle links whose Matt> endpoints have unrelated global-scope addresses. In the context of BGP peering you have: i A ----- B if link is numbered (global scope address): A and B will announce routes to each other using as nexthop the global addresses Ia and Ib (respectivly). Those addresses are the ones annouced in to the IBGP mesh. I's global prefix will be injected into the IGP. if the link is unnumbered: A and B will need to make those annoucements with Ag and Bg. That means site B needs to manually configure a route to A's prefix and inject it in it's own IGP a vice-versa. So, taking the address out of the link only adds complexity and creates two possible reasons for manual reconfiguration: the renumbering of site A and the renumbering of site B. While you only had one with a numbered link: the renumbering of link i. I'm not claiming that using non-routable addresses on link i is the right thing to do. I'm just trying to clarify what the potential problem might be (i'm very tempted to say there is none)... Matt> RIPng, for example, uses link-local next-hop addresses Which is a real pain in the neck... because of all the nice effects you get when you try to redistribute RIP into/from other routing protocols. But then you need to have link locals anyway in your table (because of the potential need to send redirects)... Matt> In summary, the only capability that's lost by having no Matt> subnet allocated to a p-p link is the ability to address Matt> "either end of this link." No. What you loose by not having a subnet in a p-to-p link is the ability to address the link's end-points knowing only how to route to the link. That is why numbered links are very useful. Matt> The cost of providing that Matt> ability is to either use one of our very large /64 subnets Matt> per link, Not really. Matt> or to do great violence to the interface Matt> identifier concept in the new addressing architecture. Since i've absolutely no idea what interface identifiers are useful for i cannot comment on that. Pedro. From qv@3com.com Fri Sep 19 00:26:57 1997 From: qv@3com.com (Quaizar Vohra) Date: Thu, 18 Sep 1997 16:26:57 -0700 (PDT) Subject: (IPng 4426) /126 or /127 -- neither! In-Reply-To: <199709181902.MAA04758@pedrom-ultra.cisco.com> References: <199709181740.MAA02589@gungnir.fnal.gov> <199709181902.MAA04758@pedrom-ultra.cisco.com> Message-ID: <199709182326.QAA08133@lookout.nsd.3com.com> Hi Pedro, Well if you mean by ununumbered ethernets assigning nodes on the ethernet (which are peering in some arbitrary fashion) in different ASs, addresses out of their respective AS's prefix then the case is no different then the p-to-p link case. In the ethernet case, as per Matt's suggestion you will configure nodes from AS A on that etherenet with addresses from a global prefix assigned to A and let nodes on the same subnet from AS B know that this prefix is on-link though they are not configured with addresses from the prefix and vice-versa. Yes the question still remains which method is better. 1) Do we use global prefixes assigned to the link which are not part of the prefixes assigned to either AS as you suggested or somebody did ? 2) Or configure nodes on the link with prefixes belonging to their respective ASs as Matt suggest. 3) Or use a global prefix which is part of a prefix assigned to one of the ASs and configure all nodes on the link with that prefix. As you said in the cases 2) and 3) you have to reconfigure the nodes with addresses out of new prefixes if renumbering occurs and introducing them in the IGPs of the involved ASs. But BGP anyway will require some reconfiguration on renumbering, atleast in policies. While in case of using 1) you will need to setup an administrative body. Quaizar > > I don't understand why you are mixing the p-to-p issue with the peering > address issue. What if instead of a serial the peer uses an ethernet ? > Do you proprose to use unnumbered ethernets too ? > > Matt> I believe routing protocols can perfectly well handle links whose > Matt> endpoints have unrelated global-scope addresses. > > In the context of BGP peering you have: > > i > A ----- B > > if link is numbered (global scope address): > > A and B will announce routes to each other using as nexthop the global > addresses Ia and Ib (respectivly). Those addresses are the ones annouced > in to the IBGP mesh. I's global prefix will be injected into the IGP. > > if the link is unnumbered: > > A and B will need to make those annoucements with Ag and Bg. That means > site B needs to manually configure a route to A's prefix and inject it > in it's own IGP a vice-versa. > > So, taking the address out of the link only adds complexity and creates > two possible reasons for manual reconfiguration: the renumbering of > site A and the renumbering of site B. While you only had one with > a numbered link: the renumbering of link i. > > I'm not claiming that using non-routable addresses on link i is the right > thing to do. I'm just trying to clarify what the potential problem might > be (i'm very tempted to say there is none)... > > Matt> RIPng, for example, uses link-local next-hop addresses > > Which is a real pain in the neck... because of all the nice effects you > get when you try to redistribute RIP into/from other routing protocols. > > But then you need to have link locals anyway in your table (because of > the potential need to send redirects)... > > Matt> In summary, the only capability that's lost by having no > Matt> subnet allocated to a p-p link is the ability to address > Matt> "either end of this link." > > No. What you loose by not having a subnet in a p-to-p link is the > ability to address the link's end-points knowing only how to route > to the link. That is why numbered links are very useful. > > Matt> The cost of providing that > Matt> ability is to either use one of our very large /64 subnets > Matt> per link, > Not really. > > Matt> or to do great violence to the interface > Matt> identifier concept in the new addressing architecture. > > Since i've absolutely no idea what interface identifiers are useful for i > cannot comment on that. > > Pedro. From jpressman@earthlink.net Fri Sep 19 01:04:08 1997 From: jpressman@earthlink.net (Jeff Pressman) Date: Thu, 18 Sep 1997 17:04:08 -0700 Subject: Please take me off this list Message-ID: <3421C177.2210E5A6@earthlink.net> Please take me off this list this is the fifth message I have sent to this effect thank you Jeff Pressman jpressman@earthlink.net From Alain.Durand@imag.fr Fri Sep 19 17:50:06 1997 From: Alain.Durand@imag.fr (Alain Durand) Date: Fri, 19 Sep 1997 18:50:06 +0200 Subject: /64 or /124,/126,/127,/128 addresses? In-Reply-To: Dimitry Haskin "(IPng 4447) Re: /126 or /127 -- neither!" (Sep 19, 9:47am) References: <3.0.32.19970919094707.006865b8@pobox> Message-ID: <970919185006.ZM3725@rama.imag.fr> I would like to make some comments on this issue from my 6bone experience with tunnels. 1) There is an interroperability issue now on the way people are doing tunnels (which are by essence Point ot Point links). Some implementations can use /128 addresses, end-point addresses may be taken from any address spaces. Some implementations do not allow anything longer that /127, thus there is a technical need to number the tunnel with a /124, /126 or /127 network. 2) If the tunnel need a network number, the question is now in which address space this network is taken from? If it's a tunnel between an ISP and a site,it's not a serious matter, if it's a tunnel between two ISPs, then it's an issue: will this network be taken from address space A, B or from a neutral "DMZ". Taking addresses from the DMZ simplify renumbering (I buy Pedro's arguments) but it's a real burden to delegate small chunk of this DMZ. Using networks from address space A or B doens't help for renumbering anymore than using /128 addresses. 3) In designing the G6 networks on the 6bone with pTLA & pNLAs, I have dedicated a /64 network for all my ppp links, serial or tunnels. This prooved very easy to extend to any number of links If I had to use a /64 prefix for each tunnel, I will first waste a huge lot of address space (maybe it's not an issue?) and, worse, to maintain a good design in my addressing architecture, I will have to reserve a large part of my site /48 prefix for the tunnels, a /52 or /56 prefix. That's the reason why I like long prefixes, like /124 (easier to read in hex. digits), and I even like /128 more! 4) Routers must be configured manually. We can not use stateless autoconf. I found easier to number my routers starting from 1 than to build manually an EUI64 for them. If ever one wants to reserve well known addresses, I'd rather like to have 0x000 to 0xFFF reserved for manually configured hosts and then from 0x1000 to, let's say 0x1FFF for well known addresses 5) If there a need of well known addresses for a point to point link? Couldn't we say "well known addresses are reserved for non PtP links. So my personal take is that /128 addresses for tunnels are the simplest thing to use. - Alain. From deering@cisco.com Fri Sep 19 18:07:17 1997 From: deering@cisco.com (Steve Deering) Date: Fri, 19 Sep 1997 10:07:17 -0700 Subject: seeking someone Message-ID: [I apologize for using this mailing list for this purpose, but I have exhausted other avenues of enquiry, and at least this shouldn't bother as many people as posting to the main ipng list...] I'm trying to find the name and email address of the fellow who talked to me outside the terminal room at the IETF in Munich, who pointed out a previously-unconsidered issue/problem with increasing the IPv6 minimum MTU. He had (and presumably still has) a British accent and he told me that he teaches IPv6 training classes. Unfortunately and embarassingly, I have forgotten both his name and the specific issue he raised. If you are that person, or if you know the name and address of the person I am talking about, please let me know. Thanks, Steve From spera@alp.net Tue Sep 23 10:18:32 1997 From: spera@alp.net (Andrea Spera) Date: Tue, 23 Sep 1997 11:18:32 +0200 Subject: Change POLITO's topology Message-ID: <34278967.268D1858@csp.it> Hello, We announce that POLITO is not under DIGITAL-CA anymore. At present we join 6bone through CSELT, exchanging route via RIPng. Thanks Andrea Spera Roberto Canna From cwhite@ua1ix.ua.edu Tue Sep 23 23:02:03 1997 From: cwhite@ua1ix.ua.edu (Craig White) Date: Tue, 23 Sep 1997 17:02:03 -0500 (CDT) Subject: your mail In-Reply-To: <199709232140.AA26221@zed.isi.edu> Message-ID: My face is so red! 1,000,000 pardons requested... On Tue, 23 Sep 1997 bmanning@ISI.EDU wrote: > > > > subscribe 6bone > > > > > > Sending this request to the mailing list will not get you your hearts desire. > Sending this request to the mailing list maint account will greatly improve > your chances of joy. What is the list maint account you ask??? > > 6bone-request@isi.edu > > -- > --bill > From cwhite@ua1ix.ua.edu Wed Sep 24 14:49:27 1997 From: cwhite@ua1ix.ua.edu (Craig White) Date: Wed, 24 Sep 1997 08:49:27 -0500 (CDT) Subject: Where to attach Message-ID: We're connected to BBN planet in Atlanta. Who would be my best tunnel partner? Thanks in advance, -craig From Marc.Blanchet@viagenie.qc.ca Mon Sep 29 00:44:24 1997 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Sun, 28 Sep 1997 19:44:24 -0400 Subject: traceroute,ipv6,solaris Message-ID: <3.0.3.32.19970928194424.0395dcc0@mail.viagenie.qc.ca> Hi, anyone have converted traceroute (or any related tool) to ipv6 on solari= s? Looking for one. Regards, Marc. ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagenie inc. | http://www.viagenie.qc.ca 3107 des hotels | tel.: 418-656-9254=20 Ste-Foy, Quebec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp: 57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifi=E9, Editions Logiques, 1997 ------------------------------------------------------------ From RLFink@lbl.gov Mon Sep 29 17:05:41 1997 From: RLFink@lbl.gov (Bob Fink) Date: Mon, 29 Sep 1997 09:05:41 -0700 Subject: new 6bone hookup web page Message-ID: I've just fixed the hookup page http://www.6bone.net/6bone_hookup.html to reflect the new address changes (thanks to Marc Blanchet for reminding me of this :-). Please take a look and recommend corrections. It would be nice to get better info on setting up the DNS as well. Thanks, Bob From yskim@dcn.soongsil.ac.kr Tue Sep 30 03:16:12 1997 From: yskim@dcn.soongsil.ac.kr (Kim,younsik) Date: Tue, 30 Sep 1997 11:16:12 +0900 Subject: Question for IPv6 DNS Message-ID: <3.0.1.32.19970930111612.006e13c0@dcn.soongsil.ac.kr> Hi. This is soongsil university in korea. I'm a gradurated student researching computer network. We implemented IPv6 over FreeBSD, and it is running. our IPv6 router is attached to 6bone. And we implemented DNS server/client for IPv6 resently. our DNS server support AAAA type. But 6bone nodes don't know our IPv6 domain name. How to this? Please answer me solution. From chenxz@ict.ac.cn Wed Sep 24 07:09:53 1997 From: chenxz@ict.ac.cn (Chen xiuzhong) Date: Wed, 24 Sep 1997 14:09:53 +0800 Subject: No subject Message-ID: <005201bcc8b0$7a255ec0$5a27e29f@L3.ict.ac.cn> This is a multi-part message in MIME format. ------=_NextPart_000_004F_01BCC8F3.878FFD20 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi,everyone, I am installing a Redhat6.0 with supporting IPv6.But after I finish = the system upgrading(including to upgrade the kenel version to 2.2.10 = and to config the network) and reboot the system,I find the device = "eth0" cannot be brought up.Using the command "ifconfig",I find a device = "dummy".In the logfile "/var/boot.log",there is a error "SIGIFINDEX:No = such device". =20 Who know why it is so?What can i do to resolve it? =20 Thx. *********************************************** Chen Xiuzhong Network Test Lab Institute of Computing Technology Tel: 62565533-9218 *********************************************** ------=_NextPart_000_004F_01BCC8F3.878FFD20 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,everyone,
    I am installing a = Redhat6.0=20 with supporting IPv6.But after I finish the system upgrading(including = to=20 upgrade the kenel version to 2.2.10 and to config the network) and = reboot the=20 system,I find the device "eth0" cannot be brought up.Using the = command=20 "ifconfig",I find a device "dummy".In the logfile=20 "/var/boot.log",there is a error "SIGIFINDEX:No such=20 device".
 
Who know why = it is so?What=20 can i do to resolve it?
 
Thx.
***********************************************
Chen=20 Xiuzhong
Network Test Lab
Institute of Computing = Technology
Tel:=20 62565533-9218
*********************************************** ------=_NextPart_000_004F_01BCC8F3.878FFD20-- From chenxz@ict.ac.cn Mon Sep 29 06:55:21 1997 From: chenxz@ict.ac.cn (Chen xiuzhong) Date: Mon, 29 Sep 1997 13:55:21 +0800 Subject: »Ø¸´: Message-ID: <004101bccc9c$46c96720$5a27e29f@L3.ict.ac.cn> Thanks. But now, I have another trouble.When I use "ping", I alway get error " name or server is not known".Futhermore,I find the IPv6 address of the interface "eth0" is not the one which I set up. Please help me setup the correct IPv6 and DNS.