From davidk@isi.edu Tue Apr 1 05:31:39 1997 From: davidk@isi.edu (davidk@isi.edu) Date: Mon, 31 Mar 1997 21:31:39 -0800 (PST) Subject: Full 6BONE database now available in RIPE style database Message-ID: <9704010531.AA15454@brind.isi.edu> Hi, This is to inform you that I have installed a RIPE style database for the 6BONE registry. I have also converted *all* RIPE ftp registry data (from this morning) to the new format as described by the draft that I posted recently. This will make it possible to use this registry as the main 6BONE repository from now on, if desired so. Note that there are some incompatibilities between the old and new format which will only show up when updating the data in the registry. Just check the draft if you find a problem when you try to update the data. You might also see some funny entries that couldn't be fixed by my conversion scripts. Just fix them manually. I would have liked to have done a better job in that regard but I am simply lacking the time to convert 125 objects manually... There are some changes with the draft: - I use the value '6BONE' in the source: attribute - I have required the addition of the origin: AS (please let me know if this is a bad idea). I thought that this gives nice possibilities for lookups and some better idea how people derived their Ipv6 address space. Biggest change from the ftp directory approach: - contact information is stored in different objects (role or person objects). You will be required to use a NIC handle (RIPE, InterNIC or from another registry) in the contact: field. You can create your own person/role object with 6BONE NIC handle if you don't have a NIC handle of one of the registries yet. I already tried to create some person/role objects automatically. Just do a search for your object and you will find if this is the case for you. - domain names are used instead of IP numbers. This makes it very easy to find out about the IPv6 and/or IPv4 number which is needed for some of the apllications that people are using on the 6BONE. Note that some of the old objects still contain IP numbers. They will not be accepted anymore when updating the data. It might be nice if somebody knows about a tool like 'host' that could support both an IPv4 & IPv6 lookup at the same time. - syntax checking will make the quality of the data better and will allow people to write tools to handle the data (for example 6BONE maps ;-)). Please inform me of any bugs in the syntax checking code since it is very new. You can always use the remarks: attribute if you need to document features that are not available in the current format. Known problems/missing features: - The server can not resolve non-6BONE NIC handles yet. I plan to do something about this, time allowing. Just use a second query to the appropriate registry to find the data: no suffix/-ORG whois.internic.net -RIPE whois.ripe.net -APNIC whois.apnic.net - No 24/7 helpdesk is available. The database doesn't have a dedicated machine right now. - I plan to make the full dump of the database available on a daily basis as soon as possible. I will put a copyright message with my name, USC & ISI in the data set to protect against abuse (spamming). Please let me know if you know a better organization for the copyright if such thing exists ... - No nice web site with helpfull documents - No web forms based interface (I might be doing this if I can find some time) How to query the database: use: $ whois -h brind.isi.edu SearchKey (or as an alternative: 'telnet brind.isi.edu whois' and type the SearchKey when you are connected) $ whois -h brind.isi.edu HELP will send you the help/howto file on howto find and update objects. Please check out the document for howto create, update or delete your objects in a RIPE style database. It is not difficult but it helps a lot if you have read the document (particurlarly the NIC handle section if you need to create a person/role object). Note that the actual formats are described in the internet draft. Send your updates by E-mail to: auto-dbm@ISI.EDU Your update will be done and you will usually receive an acknowledgement message in just a few seconds. The following whois tools are available for those of you who don't have a version of whois OR want to use the full capabilities of the RIPE whois server. ftp://ftp.ripe.net/tools/ripe-whois*.tar.gz Some interesting examples: The objects have the same name as the RIPE filename. Just do a search for your object by doing for example: $ whois -h brind.isi.edu CSELT $ whois -h brind.isi.edu 5F16:4D00::/32 Search first level more specifics (be carefull to specify a correct IPv6 prefix/address or the server will only do a 'string' based search): $ whois -h brind.isi.edu -M 5F16:4D00::/32 Search all more specifics: $ whois -h brind.isi.edu -M 5F16:4D00::/32 Search all less specifics: $ whois -h brind.isi.edu -L 5F16:4D00::/33 Find all objects with origin AS=Your(Providers)AS (note: there are curently no objects with this attribute specified since it is a new feature. Just add the attribute to your ipv6 object and try this feature) $ whois -h brind.isi.edu -i origin Your(Providers)AS Don't hesitate to experiment a bit by adding an object or doing some query trials but please remove any experimental objects after use. Don't hesitate to contact me if you have any questions. I might react a bit delayed though, since I am very busy with some other IETF related work ... I hope this helps, David K. --- From Andrew Romanenko Tue Apr 1 11:32:01 1997 From: Andrew Romanenko (Andrew Romanenko) Date: Tue, 1 Apr 1997 17:32:01 +0600 (ESD) Subject: New site Message-ID: The Ural State Academy of railway transport has become a new 6bone site in Russia. It has a tunnel to UUNET-UK (Thanks to Guy Davies). The following is our ip6rr object. site: USART location: Yekaterinburg, RU prefix: 5F15:5C00:C2E2:E600:00E6/80 ping: 5F15:5C00:C2E2:E600:00E6:0000:0100:5386 linux.ipv6.cca.usart.ru tunnel: 194.226.230.161 158.43.133.254 UUNET/UK static operational contact: Andrew Romanenko status: operational changed: andrew@cca.usart.ru 970401 source: RIPE Andrew Romanenko, USART Network administrator From goode@nc3a.nato.int Tue Apr 1 15:35:05 1997 From: goode@nc3a.nato.int (Rob Goode) Date: Tue, 1 Apr 1997 16:35:05 +0100 Subject: New site: NC3A-NL Message-ID: <199704011535.QAA05970@comsun21.nc3a.nato.int> Dear 6bones, NATO C3 Agency in the Netherlands (NC3A-NL) is now connected to the 6bone. We have been connected via a static route to UUNET/UK since March 20th. Our RIP entry is: ipv6-site: NC3A-NL origin: NLnet (ASN 1890) location: 52 06 39n 04 19 29w 12m descr: NATO C3 Agency, The Hague, The Netherlands country: NL prefix: 5F07:6200:C096:5E00::/64 application: ping 5F07:6200:C096:5E00:5E:800:207C:691 comsun9.nc3a.nato.int application: ping 5F07:6200:C096:5E00:5E:A0:2487:451F rgpc1-nu.nc3a.nato.int application: ping 5F07:6200:C096:5E00:5E:800:201c:6c97 comsun21.nc3a.nato.int tunnel: IPv6 in IPv4 -> NC3A-NL STATIC 6bone-gw.london.pipex.net contact: IO7-6BONE remarks: DNS currently not operational for forward or reverse #:-( remarks: Currently STATIC routing #:-( remarks: ipv6-site is operational since 20-Mar-97 remark: Solaris 2.5.1 IPv6 & x86/Linux 2.1.29 remark: please report any problems to contact above. changed: Rob Goode 970401 source: 6BONE Cheers, Rob Goode goode@nc3a.nato.int From RLFink@lbl.gov Tue Apr 1 19:00:21 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 1 Apr 1997 11:00:21 -0800 Subject: new 6bone diagram - version 63 Message-ID: new 6bone diagram - version 63 add ASCI/US to CISCO/US add USART/RU to UUNET/UK add NC3A/NL to UUNET/UK NC3L/NL is the NATO C3 Agency, The Hague, The Netherlands USART/RU is the Ural State Academy of railway transport in Russia ASCI/US is Advanced Systems Consulting, Inc., Marlton, NJ, USA Welcome to Russia and NATO - lots of opportunities here :-) Sounds like a new Tom Clancy novel in the making! Thanks, Bob From maray@fsz.bme.hu Thu Apr 3 12:22:18 1997 From: maray@fsz.bme.hu (MARAY Tamas) Date: Thu, 3 Apr 1997 14:22:18 +0200 (MET DST) Subject: Budapest, Hungary Message-ID: <199704031222.AA13686@bagira.fsz.bme.hu> Hi all, We have set up an experimental IPv6 site at the Technical University of Budapest. Since we would like to join to the 6bone, we are now searching a partner to cooperate with in setting up our first international IPv6 tunel. Probably the best partner would be the SURFnet IPv6 router, because of the direct and fast Budapest-Amsterdam link. If people from SURFnet read the message would they please reply? I have got some SURFnet e-mail addresses but I am not sure if they are correct because I have not received any reply for my messages I sent there. Does somebody know whom I should look for? We are also thinking about setting up a tunel with a US site. Following the network topology, we could use the Budapest-Pompano Beach (MCI) link. Any suggestion? Cheers, Tamas From RLFink@lbl.gov Thu Apr 3 14:56:23 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 3 Apr 1997 06:56:23 -0800 Subject: Budapest, Hungary In-Reply-To: <199704031222.AA13686@bagira.fsz.bme.hu> Message-ID: At 4:22 AM -0800 4/3/97, MARAY Tamas wrote: >Hi all, > >We have set up an experimental IPv6 site at the Technical University >of Budapest. Since we would like to join to the 6bone, we are now >searching a partner to cooperate with in setting up our first >international IPv6 tunel. Probably the best partner would be the >SURFnet IPv6 router, because of the direct and fast Budapest-Amsterdam >link. >If people from SURFnet read the message would they please reply? >I have got some SURFnet e-mail addresses but I am not sure if they >are correct because I have not received any reply for my messages >I sent there. Does somebody know whom I should look for? > >We are also thinking about setting up a tunel with a US site. >Following the network topology, we could use the Budapest-Pompano >Beach (MCI) link. >Any suggestion? If you use this link, maybe CICNET is a good choice...just gussing. Bob From bmanning@ISI.EDU Thu Apr 3 16:38:05 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Thu, 3 Apr 1997 08:38:05 -0800 (PST) Subject: f.5.ip6.int delegations Message-ID: <199704031638.AA02794@zed.isi.edu> ;; QUESTIONS: ;; 0.0.f.2.a.0.f.5.ip6.int, type = NS, class = IN ;; ANSWERS: 0.0.f.2.a.0.f.5.ip6.int. 129600 NS ns.isi.edu. 0.0.f.2.a.0.f.5.ip6.int. 129600 NS sun1.dcs.elf.stuba.sk. ... ;; QUESTIONS: ;; 0.0.6.0.1.0.f.5.ip6.int, type = NS, class = IN ;; ANSWERS: 0.0.6.0.1.0.f.5.ip6.int. 129600 NS ns.ge.com. 0.0.6.0.1.0.f.5.ip6.int. 129600 NS gabriel.advsys.com. ... ;; QUESTIONS: ;; 0.0.2.6.7.0.f.5.ip6.int, type = NS, class = IN ;; ANSWERS: 0.0.2.6.7.0.f.5.ip6.int. 129600 NS freeman.NL.net. 0.0.2.6.7.0.f.5.ip6.int. 129600 NS ns.NL.net. ... ;; QUESTIONS: ;; 0.0.4.1.5.1.f.5.IP6.INT, type = NS, class = IN ;; ANSWERS: 0.0.4.1.5.1.f.5.IP6.INT. 129600 NS ns.isi.edu. 0.0.4.1.5.1.f.5.IP6.INT. 129600 NS gandalf.cnaf.infn.it. -- --bill From RLFink@lbl.gov Thu Apr 3 18:04:04 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 3 Apr 1997 10:04:04 -0800 Subject: Full 6BONE database now available in RIPE style database In-Reply-To: <9704010531.AA15454@brind.isi.edu> Message-ID: I'm enthused that David has installed a RIPE style database for the 6BONE registry...but it raises a few operational issues that we should work out before we cause ourselves some problems. 1. we need to agree that we are officially switching to it and a time to turn OFF the RIPE ftp-based database. This is necessary to avoid duplicate entries as the next RIPE-style preload won't be easy if we have to sort out which is the correct entry to carry over. 2. we need to decide where it will reside (ISI is ok by me, but I haven't heard from the RIPE folk on their intent yet). 3. we need some web documentation (I've agreed to do this for David). 4. we need a web-based mechanism to query the database with so we don't have to just rely on whois commands. This is necessary for two reasons...one is to make it easier for users to simply use a 6bone web page to query site data, and the other is to allow hot buttons to work on my diagrams. 5. other issues I'm too uninformed about to mention?? I contend we should discuss this on the mailer a bit, and at the meetings next week, to see where we are before anyone starts putting their data in this new database. Comments to the mailer please! Thanks, Bob ================================================ At 9:31 PM -0800 3/31/97, davidk@isi.edu wrote: >Hi, > >This is to inform you that I have installed a RIPE style database for the >6BONE registry. I have also converted *all* RIPE ftp registry data (from >this morning) to the new format as described by the draft that I posted >recently. This will make it possible to use this registry as the main >6BONE repository from now on, if desired so. > >Note that there are some incompatibilities between the old and new format >which will only show up when updating the data in the registry. Just >check the draft if you find a problem when you try to update the data. >You might also see some funny entries that couldn't be fixed by my >conversion scripts. Just fix them manually. I would have liked to have >done a better job in that regard but I am simply lacking the time to >convert 125 objects manually... > >There are some changes with the draft: > >- I use the value '6BONE' in the source: attribute > >- I have required the addition of the origin: AS (please let me know > if this is a bad idea). I thought that this gives nice possibilities for > lookups and some better idea how people derived their Ipv6 address space. > >Biggest change from the ftp directory approach: > >- contact information is stored in different objects (role or person > objects). You will be required to use a NIC handle (RIPE, InterNIC or > from another registry) in the contact: field. You can create your own > person/role object with 6BONE NIC handle if you don't have a NIC handle > of one of the registries yet. I already tried to create some > person/role objects automatically. Just do a search for your object and > you will find if this is the case for you. > >- domain names are used instead of IP numbers. This makes it very easy to > find out about the IPv6 and/or IPv4 number which is needed for some of > the apllications that people are using on the 6BONE. Note that some of > the old objects still contain IP numbers. They will not be accepted > anymore when updating the data. It might be nice if somebody knows > about a tool like 'host' that could support both an IPv4 & IPv6 lookup > at the same time. > >- syntax checking will make the quality of the data better and will allow > people to write tools to handle the data (for example 6BONE maps ;-)). > Please inform me of any bugs in the syntax checking code since it is > very new. You can always use the remarks: attribute if you need to > document features that are not available in the current format. > >Known problems/missing features: > >- The server can not resolve non-6BONE NIC handles yet. I plan to do > something about this, time allowing. Just use a second query to the > appropriate registry to find the data: > > no suffix/-ORG whois.internic.net > -RIPE whois.ripe.net > -APNIC whois.apnic.net > >- No 24/7 helpdesk is available. The database doesn't have a dedicated > machine right now. > >- I plan to make the full dump of the database available on a daily basis > as soon as possible. I will put a copyright message with my name, USC & > ISI in the data set to protect against abuse (spamming). Please let me > know if you know a better organization for the copyright if such thing > exists ... > >- No nice web site with helpfull documents > >- No web forms based interface (I might be doing this if I can find some > time) > > >How to query the database: > >use: > >$ whois -h brind.isi.edu SearchKey > >(or as an alternative: 'telnet brind.isi.edu whois' > and type the SearchKey when you are connected) > >$ whois -h brind.isi.edu HELP > >will send you the help/howto file on howto find and update objects. > >Please check out the document for howto create, update or delete your >objects in a RIPE style database. It is not difficult but it helps a lot >if you have read the document (particurlarly the NIC handle section if >you need to create a person/role object). Note that the actual formats >are described in the internet draft. Send your updates by E-mail to: > >auto-dbm@ISI.EDU > >Your update will be done and you will usually receive an acknowledgement >message in just a few seconds. > >The following whois tools are available for those of you who don't have a >version of whois OR want to use the full capabilities of the RIPE whois >server. > >ftp://ftp.ripe.net/tools/ripe-whois*.tar.gz > > >Some interesting examples: > >The objects have the same name as the RIPE filename. Just do a search for >your object by doing for example: > >$ whois -h brind.isi.edu CSELT > >$ whois -h brind.isi.edu 5F16:4D00::/32 > >Search first level more specifics (be carefull to specify a correct IPv6 >prefix/address or the server will only do a 'string' based search): > >$ whois -h brind.isi.edu -M 5F16:4D00::/32 > >Search all more specifics: > >$ whois -h brind.isi.edu -M 5F16:4D00::/32 > >Search all less specifics: > >$ whois -h brind.isi.edu -L 5F16:4D00::/33 > >Find all objects with origin AS=Your(Providers)AS >(note: there are curently no objects with this attribute specified > since it is a new feature. Just add the attribute to your ipv6 > object and try this feature) > >$ whois -h brind.isi.edu -i origin Your(Providers)AS > > >Don't hesitate to experiment a bit by adding an object or doing some >query trials but please remove any experimental objects after use. > >Don't hesitate to contact me if you have any questions. I might react a >bit delayed though, since I am very busy with some other IETF related work ... > >I hope this helps, > >David K. >--- From dorian@cic.net Thu Apr 3 18:19:31 1997 From: dorian@cic.net (Dorian R. Kim) Date: Thu, 3 Apr 1997 13:19:31 -0500 (EST) Subject: Budapest, Hungary In-Reply-To: Message-ID: On Thu, 3 Apr 1997, Bob Fink LBNL wrote: > If you use this link, maybe CICNET is a good choice...just gussing. We responded off list. -dorian From guyd@uunet.pipex.com Thu Apr 3 19:36:08 1997 From: guyd@uunet.pipex.com (Guy Davies) Date: Thu, 3 Apr 1997 20:36:08 +0100 (BST) Subject: More tunnels to UUNET-UK Message-ID: Hi All, Today, UUNET-UK has, with help from Dorian Kim, David Meyer and Alexis Yushin setup tunnels to CICNET/US, UO/US and NLNET/NL. Our current ISI 6bone RR object is.... ipv6-site: UUNET-UK origin: AS1849 descr: London, UK & Cambridge, UK country: GB prefix: 5F07:3900::/32 application: ping 6bone-gw.lon.ip6.pipex.net application: ping eth0.6bone-gw.lon.ip6.pipex.net application: ping 6bone-gw.cam.ip6.pipex.net application: ping eth0.6bone-gw.cam.ip6.pipex.net application: ping swannee.ip6.pipex.net tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> eng-ios-dirtylab-gw.cisco.com CISCO RIPng tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> quincy-adams.corpeast.baynetworks.com BAY RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> nwnet-6bone-gw.nwnet.net NWNET RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> tdegwipv6.tbit.dk TELEBIT RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> router.ifb.net IFB RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> unvea.denet.dk UNI-C RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> sauce.sics.se SICS RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> pax-6bone.pa-x.dec.com DIGITAL-CA RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> sandbox.ep.net ISI-LAP RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> zesbot.ipv6.surfnet.nl SURFNET RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> esnet-v6r1.es.net ESNET RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> 6bone.chicago.cic.net CICNET RIPng tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> 6bone-gw.uoregon.edu UO RIPng tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> 6bone-core.ipv6.imag.fr G6 RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> newbie.hq.kit.kz KIT STATIC tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> scorpio.ecs.soton.ac.uk USOT-ECS RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> gate6.lancs.ac.uk ULANC RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> jpd.ch.man.ac.uk UMAN RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> phoenix.ja.net JANET RIPv6 tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> twizzle.trin.cam.ac.uk UCAM-T STATIC tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> comsun9.nc3a.nato.int NC3A-NL STATIC tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> sc02.dcs.elf.stuba.sk STUBA STATIC tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> linux.cca.usart.ru USART STATIC tunnel: IPv6 in IPv4 6bone-gw.london.pipex.net -> freeman.nl.net NLNET STATIC contact: IO6-6BONE remarks: DNS operational for forward (ip6.pipex.net) and reverse remarks: (0.0.9.3.7.0.f.5.ip6.int) zones remarks: Willing to add tunnels on request, particularly to customers remarks: of UUNET or MFS/WorldCom worldwide or organisations connected remarks: to LINX, D-GIX or AMS-IX. remarks: Currently support RIPng or STATIC routing remarks: ipv6-site is operational since 20-Feb-97 remarks: first url below is currently dead )-: url: http://swannee.ip6.pipex.net:81/index.html url: http://swannee.uunet.pipex.com:81/index.html notify: ipv6@uunet.pipex.com changed: Guy.Davies@uunet.pipex.com 970403 source: 6BONE The RIPE ip6rr object is also up to date :-) BTW, Can we please have some autoupdate mechanism? Guy From RLFink@lbl.gov Fri Apr 4 01:14:31 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 3 Apr 1997 17:14:31 -0800 Subject: a reference document for the new RIPE-based 6bone registry Message-ID: David Kessens and I have done up a web page for the new RIPE-based 6bone registry: http://www-6bone.lbl.gov/6bone/RIPE-registry.html We offer it to help you in trying it out, learning about it and evaluating it to help with discussions we have on the mailer and in Memphis...we are NOT saying we have converted to this operationally yet. So please take a look and send comments to either David or me, and we will talk more about this as anyone wants. Thanks, Bob From RLFink@lbl.gov Fri Apr 4 01:46:52 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 3 Apr 1997 17:46:52 -0800 Subject: new 6bone bb links diagram - version 10 Message-ID: new 6bone bb links diagram - version 10 new RIPng tunnel from UUNET/UK to CICNET/US Bob From RLFink@lbl.gov Fri Apr 4 21:04:41 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 4 Apr 1997 13:04:41 -0800 Subject: ISI 6bone registry doc and web-based whois query Message-ID: I've placed a pointer to the ISI 6bone document on the 6bone home page. In addition, David Kessens has provided a simple web-based whois query, and I have placed the pointer for this on the homepage as well. I have placed the following note in the ISI registry doc to minimize confusion: =========== EDITOR's NOTE: This DRAFT documentation is for a RIPE-style routing registry database, currently located at ISI, that is being discussed and evaluated for adoption by the IETF ngtrans 6bone Working Group. Readers are cautioned to NOT take this as a completed work, or the registry it describes as the operational 6bone routing registry. The still "official" 6bone routing registry is an ftp-based registry located at the RIPE-NCC. Please see "How to register your site with RIPE-NCC" for information on this and "RIPE-NCC 6bone Registry" for access to it. =========== My thanks to David for all his good work! Thanks, Bob From RLFink@lbl.gov Fri Apr 4 23:00:24 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 4 Apr 1997 15:00:24 -0800 Subject: 6bone Agenda (v5) for Memphis Message-ID: 6bone Agenda (v5) for Memphis below. Please email me changes, deletions, and additions. Thanks, Bob 6bone Agenda (v5) for Memphis ____________________________ 1. Topology, addressing and routing issues CAIRN backbone - Allison Mankin routing in the backbone - status from IDR WG a 6bone IPv6 address block and registry - Dimitry Haskin Toward Establishing a real virtual IPv6 network - Hsin Fang <<<< NEW addressing beyond RFC 1987 - Bob Fink Prefix aggregation problems - Alain Durand 2. 6bone routing registry issues David Meyer's Internet-Draft on extensions for "Representing Tunnels in RPSL" - David Meyer RIPE-NCC based - David Kessens DNS based - Bill Manning 3. Decide how to proceed with an Internet-Draft outlining requirements for the new 6bone infrastructure =============================================================================== Reposted for your information =============================================================================== The Memphis IETF 6bone WG session has been scheduled for a Wed. afternoon (9 April) one hour time slot. I had decided on a one hour time slot as meeting slots are hard to come by and we should not go any longer than practical with a large group (if San Jose was any example). If this meeting proves we need, and can use, a longer time slot, we can get one in Munich. I've shown all the IPng sessions below for your convenience. Note that the times have been carefully chosen to keep you in Memphis all week, whether you can find a hotel or not :-) However, the real reason that the IPng meetings are so late in the week is that Steve Deering will be in Japan until Wed. afternoon. The 6bone has been included under the NGTrans WG with me as a co-chair, along with Tony Hain and Bob Gilligan. However, Scott Bradner (one of the current OPS area directors) said that we should, for now, operate as a separate part of NGTrans, much in the same way that IPPM operates under BMWG. I have no problem with this and agree it is sensible that the 6bone be considered part of the IPv6 transition effort. ================================================================================ MONDAY, April 7, 1997 1930-2200 Evening Sessions (2 1/2 hours) APP http HyperText Transfer Protocol WG INT frnetmib Frame Relay Service MIB WG INT svrloc Service Location Protocol WG OPS bmwg Benchmarking Methodology WG OPS mboned MBONED Deployment WG >>>>> OPS ngtrans New Generation Transition WG SEC secsh Secure Shell Protocol WG USV isnII Internet School Networking-Educators BOF WEDNESDAY, April 9, 1997 1415-1515 Afternoon Sessions II (1 hour) APP ircup IRC Update BOF APP schema Schema Registration BOF INT dnsind DNS IXFR, Notification, and Dynamic Update WG INT ipcdn IP Over Cable Data Network WG >>>>> OPS 6bone IPv6 Backbone BOF OPS ptopomib Physical Topology MIB WG RTG ospf Open Shortest Path First IGP WG TSV issll Integrated Services over Specific Link Layers WG THURSDAY, April 10, 1997 1300-1500 Afternoon Sessions I (2 hours) APP fax Internet Fax WG APP lsma Large Scale Multicast Applications WG >>>>> INT ipngwg IPNG WG OPS snmpv3 Simple Network Management Protocol Version 3 WG RTG mpls Multiprotocol Label Switching WG SEC ipsec IP Security Protocol WG TSV nfsv4 Network File System Version 4 BOF FRIDAY, April 11, 1997 0830-0900 Continental Breakfast 0900-1130 Morning Sessions (2 1/2 hours) APP drums Detailed Revision/Update of Message Standards WG INT frnetmib Frame Relay Service MIB WG >>>>> INT ipngwg IPNG WG OPS bmwg Benchmarking Methodology WG OPS snmpv3 Simple Network Mangaement Protocol Version 3 WG ================================================================================ From rzm@torun.pdi.net Sat Apr 5 13:44:51 1997 From: rzm@torun.pdi.net (Rafal Maszkowski) Date: Sat, 5 Apr 1997 15:44:51 +0200 (MET DST) Subject: Tunnel do Poland Message-ID: <199704051344.PAA21332@rymunda.torun.pdi.net> Thanks to Peter Sjoedin from SICS we have a tunnel Poland-Sweden now. I hope that the following entry is correct - I have uploaded it to RIPE ftp database. site: PDi Torun (Public Internet Access, Torun) location: Torun, Poland loc-string: 53 01 00N 18 35 00E 100m prefix: 5f07:5f00/32 ping: len6.torun.pdi.net 5f07:5f00:9e4b:0:1::1 tunnel: 158.75.28.22 193.10.66.50 SICS/SE static operational tunnel: 158.75.28.22 158.75.2.50 UMK/PL static operational tunnel: 158.75.28.22 194.181.184.77 ZSE/PL static down tunnel: 158.75.28.22 156.17.29.1 PWr/PL static planned tunnel-v4: 158.75.28.22 tunnel-v6: 5f07:5f00:9e4b:0:1::1 contact: Rafal Maszkowski status: operational since 03-Apr-97 remark: System: i486 Linux 2.1.x; temporary IPv6 router for *.pl remark: may be down in the afternoon MET; loc-string is unprecise changed: rzm@pdi.net 970403 source: RIPE Whom should I ask for delegating rDNS? I would like to have it for 0.0.0.0.b.4.e.9.0.0.f.5.7.0.f.5.ip6.int . The primary could be 5f07:5f00:9e4b:0:1::1 . I will try to setup some other bind but just now I have only one v6 machine with named. I hope to run some other one in Poland but I would like to have one secondary outside pl too. R. -- Rafal Maszkowski rzm@torun.pdi.net http://www.torun.pdi.net/~rzm Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - St. J. Lec From RLFink@lbl.gov Sat Apr 5 19:28:08 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Sat, 5 Apr 1997 11:28:08 -0800 Subject: Tunnel do Poland In-Reply-To: <199704051344.PAA21332@rymunda.torun.pdi.net> Message-ID: Rafal, At 5:44 AM -0800 4/5/97, Rafal Maszkowski wrote: >Thanks to Peter Sjoedin from SICS we have a tunnel Poland-Sweden now. I'm adding PDiT/PL to the diagram today. >Whom should I ask for delegating rDNS? ... From http://www-6bone.lbl.gov/6bone/6bone_hookup.html Status: RO - Don't forget the ip6.int delegation for reverse mapping. Bill Manning (bmanning@isi.edu) is doing these and he allocates them with a /32, so you need to coordinate this with whoever in your organization is responsible for your ASN. Welcome to the 6bone! Thanks, Bob From RLFink@lbl.gov Sat Apr 5 19:36:17 1997 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Sat, 5 Apr 1997 11:36:17 -0800 Subject: new 6bone diagram - version 64 Message-ID: new 6bone diagram - version 64 add PDIT/PL to SICS/SE Welcome to PDiT and our newest country, Poland: PDi Torun (Public Internet Access, Torun, Poland) This will be the last update until after the Memphis IETF. Thanks, Bob From bruno@tk.uni-linz.ac.at Tue Apr 8 12:36:39 1997 From: bruno@tk.uni-linz.ac.at (Bruno Achauer) Date: Tue, 8 Apr 1997 13:36:39 +0200 Subject: tunnel request Message-ID: <199704081136.NAA18963@pelican.tk.uni-linz.ac.at> Hi, we have a small experimental ipv6 network and would like to connect to the 6bone. Anybody interested in setting up a tunnel to us? --Bruno. ----------------------------------------------------------------------- | Bruno Achauer, Uni Linz, Institut f. Informatik/Telekooperation | | Altenbergerstrasse 69, A-4040 Linz, Austria | | bruno@tk.uni-linz.ac.at, Phone +43-732-24689264, Fax +43-732-246810 | ----------------------------------------------------------------------- From davidk@ISI.EDU Tue Apr 8 16:27:30 1997 From: davidk@ISI.EDU (David Kessens) Date: Tue, 8 Apr 1997 08:27:30 -0700 (PDT) Subject: 6BONE RIPE style database dump now available Message-ID: <199704081527.AA00793@zephyr.isi.edu> Hi, A full dump of the 6BONE RIPE style database is now available from: http://www.ISI.EDU/~davidk/6bone/ The dump is updated every night. David K. --- From bruno@tk.uni-linz.ac.at Tue Apr 8 20:13:09 1997 From: bruno@tk.uni-linz.ac.at (Bruno Achauer) Date: Tue, 8 Apr 1997 21:13:09 +0200 Subject: New tunnel: SWITCH - TK-LINZ Message-ID: <199704081913.VAA21136@pelican.tk.uni-linz.ac.at> Hi, a tunnel has been established between the Univerity of Linz and SWITCH: site: TK-LINZ, Telecooperation Group, University of Linz location: Linz, Austria prefix: 5F04:B500:8C4E:5C00::/80 ping: 5F04:B500:8C4E:5C00::0800:2BE4:FA35 poista.ipv6.tk.uni-linz.ac.at ping: 5F04:B500:8C4E:5C00::0800:2BE4:FB35 bobbele.ipv6.tk.uni-linz.ac.at tunnel: 140.78.92.35 130.59.1.5 SWITCH - static - operational contact: bruno@tk.uni-linz.ac.at status: operational changed: bruno@tk.uni-linz.ac.at 970308 source: RIPE Special thanks to Simon Leinen at SWITCH and all the other folks who responded even before I saw my own mail coming back from the list :-) --Bruno. ----------------------------------------------------------------------- | Bruno Achauer, Uni Linz, Institut f. Informatik/Telekooperation | | Altenbergerstrasse 69, A-4040 Linz, Austria | | bruno@tk.uni-linz.ac.at, Phone +43-732-24689264, Fax +43-732-246810 | ----------------------------------------------------------------------- From andrea.chierici@cnaf.infn.it Wed Apr 9 09:03:47 1997 From: andrea.chierici@cnaf.infn.it (Andrea Chierici) Date: Wed, 9 Apr 1997 10:03:47 +0200 (MET DST) Subject: IPv6 QOS Message-ID: Hi, I am writing my master thesis on IPV6 here at INFN-CNAF, and I'm interested particularly in quality of service and granted bandwith. Can anybody tell me if there are some application that can be tested now? I see that the 6bone is up just for pings and traceroutes, can not we do something more? Thanks, Andrea ----------------------------------------- Andrea Chierici, Computer Science Student INFN-CNAF Bologna ITALY ----------------------------------------- From mdp@tbit.dk Wed Apr 9 14:26:55 1997 From: mdp@tbit.dk (Martin D. Peck) Date: Wed, 09 Apr 1997 15:26:55 +0200 Subject: IPv6 QOS References: Message-ID: <334B991F.14AF@tbit.dk> Hi Andrea, Andrea Chierici wrote: > > Hi, > I am writing my master thesis on IPV6 here at INFN-CNAF, > and I'm interested particularly in quality of service and granted > bandwith. > Can anybody tell me if there are some application that can be tested now? > I see that the 6bone is up just for pings and traceroutes, can not we do > something more? We're doing a router based implementation of RSVP for IPv6 and establishing a way of exchanging the specified traffic parameters with ATM SVCs (it's up and running for IPv4) . In a 6Bone environment build on static IPv4 tunnels this is not meaningful, so we are pushing for some end-to-end IPv6 connectivity to run tests. Any ideas ? /Martin Telebit Communications From rute.sofia@forum.pt Wed Apr 9 19:30:24 1997 From: rute.sofia@forum.pt (Rute Sofia) Date: Wed, 09 Apr 1997 20:30:24 +0200 Subject: Fw: IPv6 QOS Message-ID: Hi, I am writing my master thesis on IPSEC - mainly ISAKMP at the University of Lisbon, Portugal and I'd like to know where can I obtain some implementation (and documentation) that I could use for some testing. Thanks, Rute Sofia ------------------------------------------------------------------- Helena Rute Esteves Carvalho Sofia rute.sofia@forum.pt mi1002@caravela.di.fc.ul.pt University of Lisbon ----------------------------------------------------------- From maray@fsz.bme.hu Wed Apr 9 20:54:29 1997 From: maray@fsz.bme.hu (MARAY Tamas) Date: Wed, 9 Apr 1997 21:54:29 +0200 (MET DST) Subject: New tunnel: CICnet - BME-FSZ Message-ID: <199704091954.AA19393@bagira.fsz.bme.hu> Hi all, A new tunnel has been set up between CICnet (Chicago) and the Technical University of Budapest, Hungary. The RIPE entry: site: Technical Univ. of Budapest (BME-FSZ) location: Budapest, Hungary loc-string: 47 30 00n 19 00 00e 10m prefix: 5f09:f300:9842:4c00/64 ping: tracy.ipv6.fsz.bme.hu ping: 5f09:f300:9842:4c00:4c:0:c067:7b99 tunnel: 152.66.76.4 131.103.1.54 CICnet contact: maray@fsz.bme.hu status: operational since 09-04-1997 changed: maray@fsz.bme.hu 970409 source: RIPE Tamas From unigrd@unidhp1.uni-c.dk Thu Apr 10 07:47:18 1997 From: unigrd@unidhp1.uni-c.dk (Gudrun R. Dalgeir) Date: Thu, 10 Apr 1997 08:47:18 +0200 (METDST) Subject: New tunnel, BME-FSZ and UNI-C In-Reply-To: <199704091954.AA19393@bagira.fsz.bme.hu> Message-ID: Hi, there's a new static tunnel between the Technical Univ. of Budapest (BME-FSZ) and UNI-C. regards, ---------------- oo000oo ---------------------------------- Gudrun Dalgeir phone : (+) 45 35878532 UNI-C fax : (+) 45 35878890 Vermundsgade 5 e-mail : Gudrun.Dalgeir@uni-c.dk DK-2100 Kbh. O ----------------------------------------------------------- From bmanning@ISI.EDU Fri Apr 11 15:34:49 1997 From: bmanning@ISI.EDU (Bill Manning) Date: Fri, 11 Apr 1997 07:34:49 -0700 (PDT) Subject: proposed changes Message-ID: <199704111434.AA12888@zephyr.isi.edu> Hi, Would people object to a more structured approch to registering inverse delegations, e.g. an online form? Would there be significant grief if the proposed online form asked for authentication keys? The default is a null key if none is supplied. (I'd like to start using DNS Security) -- "When in doubt, Twirl..." -anon From RLFink@lbl.gov Sat Apr 12 21:23:30 1997 From: RLFink@lbl.gov (Bob Fink) Date: Sat, 12 Apr 1997 12:23:30 -0800 Subject: proposed changes In-Reply-To: <199704111434.AA12888@zephyr.isi.edu> Message-ID: Bill, At 6:34 AM -0800 4/11/97, Bill Manning wrote: ... > Would people object to a more structured approch to registering > inverse delegations, e.g. an online form? I think an online web-based form would be great! > Would there be significant grief if the proposed online form > asked for authentication keys? The default is a null key if > none is supplied. > (I'd like to start using DNS Security) Can you start with the web form, them give us an outline of what adding "DNS security" means in practice before we agree to going to it? I think it's a good idea in general, but most of us are probably not really clear on all the implications. Thanks, Bob From RLFink@lbl.gov Sun Apr 13 23:00:22 1997 From: RLFink@lbl.gov (Bob Fink) Date: Sun, 13 Apr 1997 15:00:22 -0700 Subject: Memphis IETF ngtrans-6bone WG minutes Message-ID: IETF Secretariat, Enclosed are the minutes of the Memphis IETF 6bone WG meeting. Note that the 6bone WG is a part of the NGTRANS WG, which currently holds separate meetings and will submit its own minutes. Thanks, Bob _______________________cut here_____________________________________ 6bone WG Meeting April 9, 1997 Memphis, TN Bob Fink / LBNL, Chair (co-chair of ngtrans WG) Reported by Dan Harrington and Bob Fink. -------------------------------------------------------------------- Agenda -------------------------------------------------------------------- 1. Introduction and Agenda Bashing / Bob Fink 2. CAIRN Backbone / Allison Mankin 3. Status from the IDR WG / Bob Fink 4. Prefix aggregation problems / Alain Durand 5. A 6BONE address block and registry / Dimitry Haskin 6. Toward establishing a real virtual IPv6 network / Hsin Fang 7. Addressing beyond RFC1987 / Bob Fink 8. Representing IPv6 Tunnels in RPSL / David Meyer 9. New 6BONE registry / David Kessens 10. DNS is your friend / Bill Manning 11. Internet Draft on requirements for new 6bone infrastructure / Bob Fink 12. Survey of implementations / Bob Fink -------------------------------------------------------------------- 1. Introduction and Agenda Bashing / Bob Fink -------------------------------------------------------------------- Bob Fink convened the meeting, giving a status report of the formation of the 6bone WG as part of the ngtrans WG. He noted that 6bone efforts would be kept distinct from ngtrans transition tools current efforts, but that how the two subgroups would interact in the future would be evaluated and modified as appropriate. Fink noted that there was a 6bone web page at: http://www-6bone.lbl.gov/6bone/ and a mail list that one can subscribe to: majordomo@isi.edu subscribe 6bone He then asked for additions and changes to the agenda. Due to the large attendance expected at this meting (based on experience at San Jose) it had been decided to use only a one hour time slot, with strict time control on the agenda topics with most discussion and decisions being done via the mail list. The agenda was modified by Kevin Lahey's request for a quick survey of implementations used on the 6bone. The agenda was accepted and the meeting continued. -------------------------------------------------------------------- 2. CAIRN Backbone / Allison Mankin -------------------------------------------------------------------- Allison Mankin presented her ideas for a native IPv6 backbone using the CAIRN research backbone network. - High bandwidth backbone for research, etc. (U.S. federal funding) - A diagram of the CAIRN topology was shown: + connectivity ranges from DS-3 to full OC-3. + several current v6 sites are CAIRN sites (ISI, LBL...) + each site has a PC/FreeBSD router and/or an Ascend GRL w/v6 support - Proposed possibilities for the backbone included: + Transit bandwidth service with native IPv6 unicast + Native IPv6 multicast path + V6 peering/exchange points + Experimental clearinghouse + Software distribution center Jim Bound commented that it was important for CAIRN's IPv6 implementation to use UNH interop lab/events to make sure there is proper interoperability before direct connectivity is attempted. Allison expressed her desire to join in the UNH testing. Further discussion was deferred to the mail list. -------------------------------------------------------------------- 3. Status from the IDR WG / Bob Fink -------------------------------------------------------------------- Bob Fink reported on the IDR WG meeting earlier in the week, noting that there were two competing BGP proposals. One from Cisco for a BGP4+ that mostly just added IPv6 support to BGP4, while a Bay/ISI proposal for a BGP5 added other features, such as a larger AS, in addition to IPv6 support. He also noted that Cisco had released an early field test version of their BGP4+ that was in the hands of several 6bone sites for experimentation. Fink stated his desire that the 6bone soon start testing BGP among some 6bone backbone sites for early experience with BGP. Further discussion was deferred to the mail list. -------------------------------------------------------------------- 4. Prefix aggregation problems / Alain Durand -------------------------------------------------------------------- Alain Durand spoke on routing anomolies that he has observed in the running 6bone. - Inconsistency in method of aggregation. Too many routes. - Backdoor routes...leads to looping, requires additional routes to supress. - Unaggregated advertisements (might have been one-time blip) - "Wierd" prefixes...typos, incorrect scope. Alain noted that site-local prefix could use a tighter definition. His conclusion...160 routes today, could easily be cut to 95 through better aggregation. With a better addressing scheme (e.g. GSE's large structure) this could be cut to ~20 (in Default Free Zone). -------------------------------------------------------------------- 5. A 6BONE address block and registry / Dimitry Haskin -------------------------------------------------------------------- Dimitry Haskin spoke on the need for a new 6bone address structure and registry. He acknowledged the first steps taken with the 6bone, noting that it now must evolve into a "real" network using a real address structure. Commercial interest in connectivity must be met, and this required moving to a real addressing architecture and registry. He agreed with plans he was hearing for the 6bone to move to whatever the IPng WG decided as the outcome of its GSE deliberations. -------------------------------------------------------------------- 6. Toward establishing a real virtual IPv6 network / Hsin Fang -------------------------------------------------------------------- Hsin Fang spoke on problems with the current 6bone RFC1987 address strcuture, how it was being used and how a "real virtual IPv6v network" might be formed based on changes to RFC1987. 6BONE Address Problems: - No organized hierarchical addressing structure. - No correlation between DNS structure and addressing structure. - No correlation between 6bone topology and addressing structure. - ISPs are not ready to operate as IPv6 service providers. - 6bone rate of growth indicates that scaling will become an issue before ISPs are ready. - 6bone "service providers" are typically not ISPs. - No guarantee that the currently used "subscriber assumed" address prefix will be the actual ISP assigned prefix. - Real provider based addresses are guaranteed to be different (RFC1897). - Renumbering WILL happen - why not have a structured hierarchy now? Suggestions: Establish the IPv6 address based on 6bone structure. - Use 6bone virtual provider's ID instead of physical network provider's ASN. - Use meaningful representation in the subscriber field, e.g. it could be one's own ASN or one's network address. Provider Based Address Format | 3 | 5 bits | 16 bits | 8 | 24 bits | 8 | 64 bits | +---+----------+----------+---+------------+---+----------------+ |010|RegistryID|ProviderID|RES|SubscriberID|RES|Intra-Subscriber| +---+----------+----------+---+------------+---+----------------+ Testing Address Format | 3 | 5 bits | 16 bits | 8 | 24 bits | 8 | 16 bits|48 bits| +---+----------+----------+---+------------+---+--------+-------+ | | |Autonomous| | IPv4 | | Subnet | Intf. | |010| 11111 | System |RES| Network |RES| | | | | | Number | | Address | | Address| ID | +---+----------+----------+---+------------+---+--------+-------+ Suggested New 6bone Address Format | 3 | 5 bits | 16 bits | 8 | 24 bits | 8 | 16 bits|48 bits| +---+----------+----------+---+------------+---+--------+-------+ | | | IPv6 | | ASN* or | | Subnet | Intf. | |010| 11111 | VPID |RES|IPv4 prefix |RES| | | | | | | | | | Address| ID | +---+----------+----------+---+------------+---+--------+-------+ IPv6 VPID : Virtual Provider Identifier ASN* : Your own ASN IPv4 Prefix : Your ISP provided network address Benefits: - More accurate delegation of 6bone. - Provide reasonable address/DNS aggregation. - More efficient routing table aggregation. - Provides valuable experience on IPv6 renumbering on a relatively large scale. Matt Crawford commented that he welcomed Hsin Fang's ideas, suggesting that implementation of it be done ASAP. There was general agreement from the crowd. Further discussion was deferred to the mail list. -------------------------------------------------------------------- 7. Addressing beyond RFC1987 / Bob Fink -------------------------------------------------------------------- Bob Fink briefly outlined his desire for the 6bone to follow the new IPv6 addressing plan that he expected to result from the IPng WG meeting later in the week. He postulated that, if real operational experience and feedback to developers and the IPng WG was a primary goal of the 6bone, that the 6bone should move quickly to adopt a new addressing plan and to test network renumbering. Jim Bound expressed his concern that users might not accept the concept of renumbering in the marketplace. Bob Fink then asked Bob Hinden to comment as IPng WG co-chair. Bob Hinden commented that he would be presenting a preliminary new unicast addressing plan at the IPng WG meeting later in the week, and that this would result in an Internet-Draft shortly therafter. He also supported experimentation with renumbering as a goal for the 6bone. Further discussion was deferred to the mail list. -------------------------------------------------------------------- 8. Representing IPv6 Tunnels in RPSL / David Meyer -------------------------------------------------------------------- David Meyer presented his ideas on representing IPv6 tunnels in RPSL that were published in the Internet Draft library as draft-ietf-rps-rpsl-00.txt. - inet-rtr object in RPSL is extended - tunnels modeled as an interface - new inet-tunnel object defined - follows RIPE-181/RPSL paradigm of specifying "your" side of the policy Please refer to the I-D for details. David then outlined outstanding issues: - Formal syntax for IPv6 Route Object? + Tunnel object would like to use general RPSL syntax to describe policy + Finessed in the examples (ANY) - Generally, should RPSL be used for IPv6? - Transition from RIPE registry to ? - Tools - Others (such as David Kessen's comments) David described David Kessens offline comments on the draft, which he will continue to pursue offline. There was a question on filtering/policy that was unanswered due to time constraints on the schedule. Bob Fink requested feedback to David on his draft via the mail list. -------------------------------------------------------------------- 9. New 6BONE registry / David Kessens -------------------------------------------------------------------- David Kessens spoke on the new RIPE-191 style 6bone routing registry that he had just made operational prior to this IETF meeting. He gave a brief overview of the information he has already sent to the 6bone mail list, noting that there was a web page describing how to use the new registry available through the 6bone web pages. There is also a whois web-based query tool for the registry that is available through the 6bone web pages. He noted that the registry and the whois server is at brind.isi.edu and that the registry will be mirrored at several 6bone sites around the world. David noted Bob Fink's intention to register the domain 6bone.net, and that the registry and whois server could then be renamed under this domain. Information on the IPv6 site object extension to the RIPE database structure are available from the Internet Draft library as draft-ietf-ngtrans-6bone- registry-00.txt. Discussion of if and when to convert the 6bone from the existing RIPE-NCC ftp-based routing registry was deferred to the mail list. -------------------------------------------------------------------- 10. DNS is your friend / Bill Manning -------------------------------------------------------------------- Bill Manning spoke on his idea for putting 6bone routing information into the DNS using TXT and/or Kitchen Sink SINK resource records. He noted that this would allow the site to locally maintain their own routing registry information using the well established DNS hierarchy, thereby encouraging a more up-to-date registry due to its locally controlled nature. Due to limited time (the one hour time slot was up and cookies were availabe so people were drifting out), this was deferred to the mail list. For those interested in Don Eastlake's Kitchen Sink Resource Record mechanism to extend DNS, please refer to draft-eastlake-kitchen-sink-01.txt. -------------------------------------------------------------------- 11. Internet Draft on requirements for new 6bone infrastructure / Bob Fink -------------------------------------------------------------------- Bob Fink asked for help on an Internet Draft on Requirements for the New 6bone Infrastructure. A goal would be to have a first draft by the Munich IETF in August. Those interested were asked to contact Bob offline. -------------------------------------------------------------------- 12. Survey of implementations / Bob Fink -------------------------------------------------------------------- The survey of IPv6 implementations in use on the 6bone was postponed due to lack of time. Bob Fink volunteered to do this survey via the mail list. -------------------------------------------------------------------- -------------------------------------------------------------------- - end From ad@vosko.nl Mon Apr 14 09:05:24 1997 From: ad@vosko.nl (Ad Olsthoorn) Date: Mon, 14 Apr 1997 10:05:24 +0200 Subject: AW: IPv6 QOS Message-ID: <01BC48BB.5FABA560@ad> Hi Helena Rute Esteves Carvalho Sofia, Try FTP Software Inc Onnet32 v2.0 or Secure Client v3.0 TCP/IP suite, = this is a full IPv6/IPv4 kernel with IPSEC implemenation. Search the web = (www.ftp.com) and you'll find all you need !! You can download demo's or order 30 day full action copies on CD (Only = the US versions supports the security features due to exportlimitations = in the US) Regards, Ad Olsthoorn ---------- Van: Rute Sofia[SMTP:rute.sofia@forum.pt] Verzonden: woensdag 9 april 1997 20:30 Aan: 6bone@isi.edu Onderwerp: Fw: IPv6 QOS=20 Hi, I am writing my master thesis on IPSEC - mainly ISAKMP at the University of Lisbon, Portugal and I'd like to know where can I obtain some implementation (and documentation) that I could use for some testing. Thanks, Rute Sofia =09 ------------------------------------------------------------------- Helena Rute Esteves Carvalho Sofia rute.sofia@forum.pt mi1002@caravela.di.fc.ul.pt University of Lisbon ----------------------------------------------------------- From RLFink@lbl.gov Mon Apr 14 14:37:08 1997 From: RLFink@lbl.gov (Bob Fink) Date: Mon, 14 Apr 1997 06:37:08 -0700 Subject: Cairn and future v6 backbone In-Reply-To: <199704141302.NAA01631@grail.tri.sbc.com> Message-ID: Eric, At 6:02 AM -0700 4/14/97, Eric Yang wrote: ... > I understand CAIRN is part of DARPA. If the plan is to create a IPv6 >backbone based on the CAIRN , is it possible for a private company to >participate? If this is possible, I like to hear more about it. Of course. You aren't becoming a member of CAIRN's testbed itself, rather participating in a research project that one of their members is proposing to use it for. For details of the proposal I will defer to Allison Mankin. Thanks, Bob From RLFink@lbl.gov Mon Apr 14 16:41:44 1997 From: RLFink@lbl.gov (Bob Fink) Date: Mon, 14 Apr 1997 08:41:44 -0700 Subject: new 6bone diagram - version 65 Message-ID: new 6bone diagram - version 65 BME-FSZ/HU to UNI-C/DK NURI/KR to ISI-LAP/US TK-LINZ/AT to SWITCH/CH Welcome to BME-FSZ/HU in Budapest, Hungary, our 22nd country! Technical Univ. of Budapest (BME-FSZ) Budapest, Hungary Also welcome to NURI/KR, our 2nd Korean site I believe. NURI ( Inet, Inc. ) Seoul, KOREA Also welcome to another Austrian site, TK-LINZ/AT Telecooperation Group, University of Linz Linz, Austria We are getting VERY international!! Bob PS: I'm guessing on which tunnels to use for BME-FSZ and NURI to use. Can someone from these sites (or anyone) tell me if these are close to the IPv4 routing for these sites? (Just a reminder, I only show one tunnel per site, hopefully the tunnel closest to the site's IPv4 route to the Internet, and also hopefully the one it considers primary.) From RLFink@lbl.gov Mon Apr 14 16:51:57 1997 From: RLFink@lbl.gov (Bob Fink) Date: Mon, 14 Apr 1997 08:51:57 -0700 Subject: new 6bone home page Message-ID: I have added David Kessen's pointer to his registry homepage to the 6bone home page, which includes full registry dumps and his whois source code. We do need discussion on the list as to if/when to convert to this new registry as it is now stale and new sites are being added to the old one (as they should be until we agree to use the new one and cutover to it). Thanks, Bob From bmanning@ISI.EDU Mon Apr 14 16:52:59 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Mon, 14 Apr 1997 08:52:59 -0700 (PDT) Subject: f.5.ip6.int delegations Message-ID: <199704141552.AA07258@zed.isi.edu> ;; QUESTIONS: ;; 0.0.0.5.c.4.f.5.ip6.int, type = NS, class = IN ;; ANSWERS: 0.0.0.5.c.4.f.5.ip6.int. 129600 NS jatz.aarnet.edu.au. 0.0.0.5.c.4.f.5.ip6.int. 129600 NS munnari.oz.au. 0.0.0.5.c.4.f.5.ip6.int. 129600 NS ns1.telstra.net. ... ;; QUESTIONS: ;; 0.0.f.5.7.0.f.5.ip6.int, type = NS, class = IN ;; ANSWERS: 0.0.f.5.7.0.f.5.ip6.int. 129600 NS len.torun.pdi.net. 0.0.f.5.7.0.f.5.ip6.int. 129600 NS ns.isi.edu. 0.0.f.5.7.0.f.5.ip6.int. 129600 NS len.ipv6.pdi.net. ... ;; QUESTIONS: ;; 0.0.5.b.4.0.f.5.ip6.int, type = NS, class = IN ;; ANSWERS: 0.0.5.b.4.0.f.5.ip6.int. 129600 NS poista.tk.uni-linz.ac.at. 0.0.5.b.4.0.f.5.ip6.int. 129600 NS ns.isi.edu. ... ;; QUESTIONS: ;; 0.0.e.2.0.0.f.5.ip6.int, type = NS, class = IN ;; ANSWERS: 0.0.e.2.0.0.f.5.ip6.int. 129600 NS fezzik.rutgers.edu. 0.0.e.2.0.0.f.5.ip6.int. 129600 NS hardees.rutgers.edu. -- --bill From bmanning@ISI.EDU Mon Apr 14 19:28:00 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Mon, 14 Apr 1997 11:28:00 -0700 (PDT) Subject: proposed changes In-Reply-To: from "Nikos Mouat" at Apr 11, 97 10:26:06 am Message-ID: <199704141828.AA07660@zed.isi.edu> > > > Isn't this the way that all your other dns delegations are done bill? > (ie the stuff for the exchanges) - you already have the whole thing in > place don't you? Well... mostly. There are some changes that are coming down the pipe that should better reflect new activities. ... like RFC 2065 support. -- --bill From crawdad@fnal.gov Mon Apr 14 22:05:49 1997 From: crawdad@fnal.gov (Matt Crawford) Date: Mon, 14 Apr 1997 16:05:49 -0500 Subject: 6bone action items per Memphis IETF meeting In-Reply-To: "13 Apr 1997 15:00:32 PDT." <"v03007800af76ffdc3ddf"@[128.3.9.22]> Message-ID: <199704142105.QAA07306@gungnir.fnal.gov> > I have outlined below what I think are the > primary action items resulting from the meeting. > > Please comment on them to the mailer. ... > > A8. Performa a survey of host and router implementations in use on the > 6bone, so the information may be made available through the 6bone web pages. Bob, Actually, I don't think we got to A8 due to a time shortage. I think people mostly agreed that would be best done by email anyway. Matt From RLFink@lbl.gov Tue Apr 15 01:06:11 1997 From: RLFink@lbl.gov (Bob Fink) Date: Mon, 14 Apr 1997 17:06:11 -0700 Subject: 6bone action items per Memphis IETF meeting In-Reply-To: <199704142105.QAA07306@gungnir.fnal.gov> References: "13 Apr 1997 15:00:32 PDT." <"v03007800af76ffdc3ddf"@[128.3.9.22]> Message-ID: Matt, At 2:05 PM -0700 4/14/97, Matt Crawford wrote: ... >> A8. Performa a survey of host and router implementations in use on the >> 6bone, so the information may be made available through the 6bone web pages. ... >Actually, I don't think we got to A8 due to a time shortage. I think >people mostly agreed that would be best done by email anyway. Yeah, we got to saying just that much as I closed the meeting for cookies (see the minutes below), so I'm just saying it's an action item to attend to. Thanks, Bob -------------------------------------------------------------------- 12. Survey of implementations / Bob Fink -------------------------------------------------------------------- The survey of IPv6 implementations in use on the 6bone was postponed due to lack of time. Bob Fink volunteered to do this survey via the mail list. -------------------------------------------------------------------- From jang@sps.nl Tue Apr 15 14:00:32 1997 From: jang@sps.nl (Gils van, Jan) Date: Tue, 15 Apr 1997 15:00:32 +0200 Subject: IPv6, Users in the Netherlands Message-ID: Hi, Thanks for reading this message. I am looking for IPv6(IPng) users/developers in the Netherlands, maybe it would be an idea to exchange information about your experince's so far. I am will try to install a Linux system with IPv6 and when I can find some info about the Alpha AXP version I will also try to install it on a Alpha Multia. With regards Jan H. van Gils ___________________________________________________________________ Jan H. van Gils | Software Productivity Solutions jang@sps.nl | P.O. box 92 2810 AB Reeuwijk +31 (0)182-396866 | Fokkerstraat 16 2811 ER Reeuwijk ------------------------------------------------------------------- From bmanning@ISI.EDU Tue Apr 15 16:21:31 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Tue, 15 Apr 1997 08:21:31 -0700 (PDT) Subject: pesky AAAA records :) Message-ID: <199704151521.AA09033@zed.isi.edu> ;; QUERY SECTION: ;; f.5.ip6.int, type = NS, class = IN ;; ANSWER SECTION: f.5.ip6.int. 1d12h IN NS munnari.oz.au. f.5.ip6.int. 1d12h IN NS zesbot.ipv6.surfnet.nl. f.5.ip6.int. 1d12h IN NS NS.ISI.EDU. ;; ADDITIONAL SECTION: munnari.oz.au. 14h44m45s IN A 128.250.22.2 munnari.oz.au. 14h44m45s IN A 128.250.1.21 zesbot.ipv6.surfnet.nl. 6h46m53s IN AAAA 5f04:4f00:c057:6e00:3c:c0:4fc6:9cc7 zesbot.ipv6.surfnet.nl. 6h46m53s IN A 192.87.110.60 NS.ISI.EDU. 1D IN A 128.9.128.127 Humm... :) -- bill From bound@zk3.dec.com Tue Apr 15 17:31:35 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Tue, 15 Apr 97 12:31:35 -0400 Subject: IPv6, Users in the Netherlands In-Reply-To: Your message of "Tue, 15 Apr 97 15:00:32 +0200." Message-ID: <9704151631.AA29843@wasted.zk3.dec.com> Hi, very timely.. I am doing a presentation to the New Hampshire U.S. Linux users/developers group Wednesday night at UNH on IPv6. I have had some interaction with the Linux implementation, but does anyone know what/who has the stack running on Alpha Linux...I am checking the IPng www pages too and see two entries for Linux work.. thanks /jim From bill@wizard.gsfc.nasa.gov Wed Apr 16 02:52:44 1997 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Date: Tue, 15 Apr 1997 21:52:44 -0400 (EDT) Subject: Memphis IETF ngtrans-6bone WG minutes In-Reply-To: from "Bob Fink" at Apr 13, 97 03:00:22 pm Message-ID: <9704160152.AA28554@wizard.gsfc.nasa.gov> > -------------------------------------------------------------------- > 7. Addressing beyond RFC1987 / Bob Fink > -------------------------------------------------------------------- > > Bob Fink briefly outlined his desire for the 6bone to follow the new IPv6 addressing plan that he expected to result from the IPng WG meeting later in the week. He postulated that, if real operational experience and feedback to developers and the IPng WG was a primary goal of the 6bone, that the 6bone should move quickly to adopt a new addressing plan and to test network renumbering. > > Jim Bound expressed his concern that users might not accept the concept of renumbering in the marketplace. > > Bob Fink then asked Bob Hinden to comment as IPng WG co-chair. > > Bob Hinden commented that he would be presenting a preliminary new unicast addressing plan at the IPng WG meeting later in the week, and that this would result in an Internet-Draft shortly therafter. He also supported experimentation with renumbering as a goal for the 6bone. > > Further discussion was deferred to the mail list. From one B. Fink to another... :-) Any idea when this aggregate-based unicast addressing plan I-D will be available? Is this supposed to be a replacement for the geographic based addressing option (format 100) or yet another option? I'm working on a Federal networks ATM addressing plan, and I'm proposing to use IPv6 addresses embedded in ATM NSAP addresses. I was originally planning to use a geographic based scheme, but perhaps I should check out this new addressing I-D to see what options it provides. The bottom line is I need real IPv6 addresses from some registration authority. Is a registry for the US / North America defined at this point for any of the addressing options? -Bill From RLFink@lbl.gov Wed Apr 16 05:18:58 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 15 Apr 1997 21:18:58 -0700 Subject: Memphis IETF ngtrans-6bone WG minutes In-Reply-To: <9704160152.AA28554@wizard.gsfc.nasa.gov> References: from "Bob Fink" at Apr 13, 97 03:00:22 pm Message-ID: Bill, At 6:52 PM -0700 4/15/97, Bill Fink wrote: ... >Any idea when this aggregate-based unicast addressing plan I-D will be >available? Is this supposed to be a replacement for the geographic based >addressing option (format 100) or yet another option? Bob Hinden promised it in a week or two from the meeting. He has (as we all do) a great interest in getting it out quickly, so I would expect it soon. As for what it is, it is provider-like addressing in that the owner of a block assigns sub parts of it, delegating downwards, but there are several very important differences: 1. an exchange (like a NAP with extra functionality) can be registered as well as a provider at the top-level. This makes it quasi geo/metro-like. People getting their delegation from an exchange (as opposed to a provider) will then arrange who will be their transit provider beyond the exchange point of connection, and won't have to renumber as long as the exchange operator stays in business. Maybe transit arrangements are also another business opportunity for the exchange operator. 2. the TLA (Top Level Aggregator) is limited to 13 bits to limit the high-level routing complexity. no words yet on who gets to be one of these...stay tuned. 3. no registry bits are wasted, small blocks of TLAs will be handed out to various registries as appropriate. 4. the IEEE EUI-64 was accepted, thus fixing the node id to 64 bits and reducing the "routing goop" site prefix size to just 48-bits. With the site partition (subnet) field being 16 bits it means that the routing is now able to be done on 64 bits. 5. the EUI-64 "global/local" bit will have significance in that if it is set to "global" it may be treated as globally unique, while setting it "local" will mean that it can then be formatted in a non-globally unique fashion. | 3 | 13 bits | 32 bits | 16 | 64 bits | +---+---------+----------------+---------+---------------------------------+ |010| TLA | NLA* | subnet | EUI-64 node id | +---+---------+----------------+---------+---------------------------------+ TLA = Top Level Aggregator NLA* = Next Level Aggregator EUI-64 = http://standards.ieee.org/db/oui/tutorials/EUI64.html >I'm working on a Federal networks ATM addressing plan, and I'm proposing >to use IPv6 addresses embedded in ATM NSAP addresses. I was originally >planning to use a geographic based scheme, but perhaps I should check >out this new addressing I-D to see what options it provides. The bottom >line is I need real IPv6 addresses from some registration authority. >Is a registry for the US / North America defined at this point for any >of the addressing options? No registry exists at this time. We anticipate starting with a test TLA for the 6bone so we can start testing this whole thing, including delegation and renumbering, as soon as possible. Comments now appropriate from "all" on usability of EUI-64 for your purpose. There is a registry for it. Apologies if I've misrepresented any of Bob's ideas here, but it is probably useful to have some interpretation of this plan while we are waiting on Bob :-) Bob From brian@hursley.ibm.com Wed Apr 16 11:44:35 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Wed, 16 Apr 1997 11:44:35 +0100 Subject: Memphis IETF ngtrans-6bone WG minutes In-Reply-To: from "Bob Fink" at Apr 15, 97 09:18:58 pm Message-ID: <9704161044.AA80676@hursley.ibm.com> Bill, > > >I'm working on a Federal networks ATM addressing plan, and I'm proposing > >to use IPv6 addresses embedded in ATM NSAP addresses. I have to say I don't see the advantage in this; they are orthogonal addressing spaces. But if you do it, I hope you'll use the mapping in RFC 1888, section 6. > >I was originally > >planning to use a geographic based scheme, There is no defined IPv6 geographic scheme. Brian Carpenter From bortzmeyer@pasteur.fr Wed Apr 16 16:58:26 1997 From: bortzmeyer@pasteur.fr (Stephane Bortzmeyer) Date: Wed, 16 Apr 97 17:58:26 +0200 Subject: traceroute with IPv6 from a Web server Message-ID: <199704161558.RAA12421@josephine.sis.pasteur.fr> In order to let people on the 6bone try it from various points of view, it would be a good idea to have a network of "traceroute servers" allowing people to see the 6bone on various sides. As fas as I know, there is currently no such server. So, I've set up one. I hope it will be the first of a large family: http://www.ipv6.internatif.org/cgi-bin/traceroute Feel free to use it and to report any problem, suggestion, etc. From bortzmeyer@pasteur.fr Thu Apr 17 13:02:54 1997 From: bortzmeyer@pasteur.fr (Stephane Bortzmeyer) Date: Thu, 17 Apr 97 14:02:54 +0200 Subject: traceroute with IPv6 from a Web server In-Reply-To: <199704161558.RAA12421@josephine.sis.pasteur.fr> (Stephane Bortzmeyer 's message of Wed, 16 Apr 97 17:58:26 +0200) Message-ID: <199704171202.OAA22149@josephine.sis.pasteur.fr> On Wednesday 16 April 97, at 17 h 58, the keyboard of Stephane Bortzmeyer wrote: > As fas as I know, there is currently no such server. So, I've set up one. > I hope it will be the first of a large family: Here is the second one :-) http://www.ipv6.pasteur.fr/IPv6/traceroute.html Unfortunately. it is too close (network-wise) from the first. At least it's a different operating system. And a new script. From lf@elemental.net Thu Apr 17 14:31:09 1997 From: lf@elemental.net (Lars Fenneberg) Date: Thu, 17 Apr 1997 15:31:09 +0200 (MEST) Subject: IPv6, Users in the Netherlands In-Reply-To: <9704151631.AA29843@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Apr 15, 97 12:31:35 pm Message-ID: Hi all! You, bound@zk3.dec.com, said: > users/developers group Wednesday night at UNH on IPv6. I have had some > interaction with the Linux implementation, but does anyone know what/who > has the stack running on Alpha Linux... I think Philip Blundell has IPv6 running on Alpha Linux. Regards, Lars. -- Lars Fenneberg, lf@elemental.net (private), lf@cityline.net (work) pgp fingerprint D1 28 F1 FF 3C 6B C0 27 CC 9C 6C 09 34 0A 55 18 From bill@wizard.gsfc.nasa.gov Fri Apr 18 02:31:48 1997 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Date: Thu, 17 Apr 1997 21:31:48 -0400 (EDT) Subject: Memphis IETF ngtrans-6bone WG minutes In-Reply-To: from "Bob Fink" at Apr 15, 97 09:18:58 pm Message-ID: <9704180131.AA00758@wizard.gsfc.nasa.gov> > Date: Tue, 15 Apr 1997 21:18:58 -0700 > From: Bob Fink > > 1. an exchange (like a NAP with extra functionality) can be registered as > well as a provider at the top-level. This makes it quasi geo/metro-like. > People getting their delegation from an exchange (as opposed to a provider) > will then arrange who will be their transit provider beyond the exchange > point of connection, and won't have to renumber as long as the exchange > operator stays in business. Maybe transit arrangements are also another > business opportunity for the exchange operator. I like this. > 2. the TLA (Top Level Aggregator) is limited to 13 bits to limit the > high-level routing complexity. no words yet on who gets to be one of > these...stay tuned. > > 3. no registry bits are wasted, small blocks of TLAs will be handed out to > various registries as appropriate. This is kind of critical. For the Federal networking addressing I'm working on, I'd like to have the IANA allocate a small block of TLAs to for example NIST, as the standards body for the US, who could then suballocate portions of this space to various federal organizations. The general consensus among the federal groups I am working with favors some type of geographic based addressing scheme. > 4. the IEEE EUI-64 was accepted, thus fixing the node id to 64 bits and > reducing the "routing goop" site prefix size to just 48-bits. With the > site partition (subnet) field being 16 bits it means that the routing is > now able to be done on 64 bits. I really don't like this at first glance. 64 bits of basically flat space for a given subnet seems like major overkill. I thought that 48 bits of flat space was overkill, but I could see the significant advantage to that. I don't see any advantage to increasing this to 64 bits and I do see a major disadvantage. The disadvantage is that it only leaves 32 bits for the NLA, which seriously reduces the flexibility of the RG. If you broke this down for example into 3 fields for provider, sub-provider, and site, each field would only be about 10 bits or about 1000 possibilities, and you might want to have more fields. For the geographic based scheme I was proposing as a strawman, I had 5 fields, namely region (10 bits), metro (10), locality (10), organization(10), and site (8), which adds up to 48 bits. Trying to squeeze something like this down into 32 bits would be quite difficult. > 5. the EUI-64 "global/local" bit will have significance in that if it is > set to "global" it may be treated as globally unique, while setting it > "local" will mean that it can then be formatted in a non-globally unique > fashion. Maybe I missed it in the web page reference, but I didn't notice any reference to the "global/local" bit, although I know they have this for EUI-48. Once again, I don't see any utility/advantage to using EUI-64. EUI-48 makes sense since it's used quite universally in Ethernet, FDDI, ATM, etc MAC layer addresses, but I've yet to see anything that uses EUI-64, and it just seems a monumental waste of valuable address space. > | 3 | 13 bits | 32 bits | 16 | 64 bits | > +---+---------+----------------+---------+---------------------------------+ > |010| TLA | NLA* | subnet | EUI-64 node id | > +---+---------+----------------+---------+---------------------------------+ > > TLA = Top Level Aggregator > NLA* = Next Level Aggregator > EUI-64 = http://standards.ieee.org/db/oui/tutorials/EUI64.html > > >I'm working on a Federal networks ATM addressing plan, and I'm proposing > >to use IPv6 addresses embedded in ATM NSAP addresses. I was originally > >planning to use a geographic based scheme, but perhaps I should check > >out this new addressing I-D to see what options it provides. The bottom > >line is I need real IPv6 addresses from some registration authority. > >Is a registry for the US / North America defined at this point for any > >of the addressing options? > > No registry exists at this time. We anticipate starting with a test TLA > for the 6bone so we can start testing this whole thing, including > delegation and renumbering, as soon as possible. As indicated earlier, I would like to see IANA allocate a small block of TLAs to someone like NIST, who could then suballocate addresses to US federal organizations. > Comments now appropriate from "all" on usability of EUI-64 for your > purpose. There is a registry for it. EUI-64 would make what I'm trying to achieve more difficult, since there's no longer a natural match with existing 48-bit MAC addresses, which the ATM addressing currently uses as the ESI. However, I'm not saying it's impossible, only that it's no longer as natural a fit. Also, for handling IPv4 addresses in ATM NSAP addresses, I was looking to embed the IPv4 address in the low order 32 bits of the ATM NSAP address (not counting the SEL field), with an appropriate IPv6 route prefix (RG) in the upper bits of the ATM NSAP address (not counting the AFI/ICD fields). I'll have to see how this can fit into the new aggregator based IPv6 addressing format. > Apologies if I've misrepresented any of Bob's ideas here, but it is > probably useful to have some interpretation of this plan while we are > waiting on Bob :-) I think it's quite useful. Thanks for sketching it out. I look forward to reading all the gory details when the I-D comes out. > Bob -Bill From bill@wizard.gsfc.nasa.gov Fri Apr 18 03:40:04 1997 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Date: Thu, 17 Apr 1997 22:40:04 -0400 (EDT) Subject: Memphis IETF ngtrans-6bone WG minutes In-Reply-To: <9704161044.AA80676@hursley.ibm.com> from "majordom@ISI.EDU" at Apr 16, 97 11:44:35 am Message-ID: <9704180240.AA00881@wizard.gsfc.nasa.gov> > Bill, > > > > >I'm working on a Federal networks ATM addressing plan, and I'm proposing > > >to use IPv6 addresses embedded in ATM NSAP addresses. > > I have to say I don't see the advantage in this; they are > orthogonal addressing spaces. But if you do it, I hope you'll > use the mapping in RFC 1888, section 6. Brian, Well, IEEE 48-bit MAC addresses are orthogonal to IPv6 or ATM NSAP addresses but there was apparently an advantage to embedding MAC addresses in IPv6 and ATM NSAP addresses. I happen to think there are major advantages to be obtained from recognizing that both IPv6 and ATM NSAP addresses are 128 bits long (not counting the AFI/ICD and SEL fields in the ATM NSAP addresses), hierarchical, and globally unique, which allows a very natural equivalence to be formed between the two addressing spaces. Some of the major advantages of this approach include: * Simplicity and ease of understanding * Facilitates and simplifies network management and troubleshooting of ATM networks * Works with both IPv4 and IPv6 * Eliminates the need for the complexity of NHRP (and possibly also ATMARP at a later stage) * Provides for direct shortcut routing across an ATM infrastructure across LIS boundaries * Provides for distributed ATMARP service * Very easy to implement * Only one name and address space to devise, administer, and manage * Scalable * Minimizes latency on connection setup * DNS would also be a directory for ATM addresses which would facilitate native ATM operation if desired * Uniform user interface and maximum user benefit * Can leverage existing IP capabilities to provide the same capabilities at the ATM layer, and IP can take full advantage of the ATM layer - basically avoids unnecessary duplication of effort which would otherwise be required in solving the same basic problem (such as security considerations) at multiple layers My early ideas on all of the above I wrote up in a long since expired Internet Draft entitled "IP/ATM Integrated Routing & Addressing (IRA) Model". If anyone is interested in checking it out, it is still available at: http://www.nasa.atd.net/draft-fink-ipatm-ira-00.html I am considering writing up a new version of the IRA Model I-D (if I can ever find a few free days), based on comments I received on the original and additional ideas that have occurred to me after additional thought on the subject. The one thing that has held me back is that the IP switching model is probably an even better way of integrating the IP and ATM layers. It's a matter of how quickly that model can be standardized and generally accepted. Regarding your comment about RFC 1888, yes I was following the format described in it for embedding IPv6 addresses in ATM NSAP addresses. However, I do have a question/concern regarding the proposed encapsulation. It uses a new AFI (35) and I don't think that is currently one of the approved ATM NSAP formats by the ATM Forum, so there is some concern that this could potentially lead to some operational problems. The original Internet Draft version of this subject used the normal AFI of 47 with an ICD of 0090, which definitely would not be a problem for ATM use. What was the rationale for changing this to use a new AFI? > > >I was originally > > >planning to use a geographic based scheme, > > There is no defined IPv6 geographic scheme. I know. :-( That's definitely a major stumbling block. If it came down to that, I was even considering submitting a proposal for an IPv6 geographic scheme. However, this may not be necessary, as the basic goal may be readily achievable via the new aggregator based addressing format. > Brian Carpenter -Bill From brian@hursley.ibm.com Fri Apr 18 11:14:32 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Fri, 18 Apr 1997 11:14:32 +0100 Subject: Memphis IETF ngtrans-6bone WG minutes In-Reply-To: <9704180131.AA00758@wizard.gsfc.nasa.gov> from "Bill Fink" at Apr 17, 97 09:31:48 pm Message-ID: <9704181014.AA94286@hursley.ibm.com> >- Bill Fink said: .... > you might want to have more fields. For the geographic based scheme > I was proposing as a strawman, I had 5 fields, namely region (10 bits), > metro (10), locality (10), organization(10), and site (8), which adds > up to 48 bits. So you are ready to assert that the networks concerned will have a physical topology that matches this geographical topology precisely, for the next few decades? Bill, the reason there is no defined geographical addressing scheme for IPv6 is that nobody has yet described one that has met consensus that it is scaleable and routable. Brian Carpenter From brianw@unidec.co.uk Fri Apr 18 14:04:22 1997 From: brianw@unidec.co.uk (Brian Williams) Date: Fri, 18 Apr 1997 14:04:22 +0100 Subject: New Site on Bone Message-ID: Hi, Unidec Systems Ltd (USL-UK) is now connected upto the 6Bone. The IPv4 Tunnel is connected to DIGITAL-ETC (Digital in Sophia), thanks to Robert Watson. At the moment we have two nodes running with IPv6. A) Digital Routabout (RIPng) 5F1A:5900:C3A6:1300:0001:0800:2BB9:EE57 B) Digital Unix (Auto configured) IPv6 test code 5F1A:5900:C3A6:1300:0001:0800:2BBB:B706 Everything should Ping Ok and should be up all the time I hope that I have done everything in the correct order and manner, if not please forgive my mistakes. Best Regards Brian Williams PS. I have entered the following information on the FTP site site: Unidec Systems Ltd location: Manor Chambers, Marygate, York, Engand loc-string: 53 57 40N 1 5 12W prefix: 5F1A:5900:C3A6:1300:0001::/80 ping: 5F1A:5900:C3A6:1300:0001:0800:2BB9:EE57 ping: 5F1A:5900:C3A6:1300:0001:0800:2BBB:B706 tunnel: 195.166.19.5 193.56.15.54 DIGITAL-ETC contact: brianw@unidec.co.uk, ianb@unidec.co.uk status: operational since 16-Apr-1997 remark: Tel :: +44 (0)1904 670670 remark: Fax :: +44 (0)1904 670570 remark: Tunnel Suppled By Digital Equipment Co. remark: Digital RouteAbout Access EW /IPv6 remark: New tunnels added, RIP only, send mail to contact remark: 5F1A:5900:C3A6:1300:0001:0800:2BBB:B706 is DECunix/IPv6 changed: brianw@unidec.co.uk source: RIPE From RLFink@lbl.gov Fri Apr 18 15:50:17 1997 From: RLFink@lbl.gov (Bob Fink) Date: Fri, 18 Apr 1997 07:50:17 -0700 Subject: new 6bone diagram - version 66 Message-ID: new 6bone diagram - version 66 FTP-SOFTWARE/US to UNH/US BME-FSZ/HU moved to JOIN/DE (closer path) Welcome to FTP-SOFTWARE, developers of IPv6 for Windows platforms! Bob From dth@lucent.com Fri Apr 18 18:04:17 1997 From: dth@lucent.com (Harrington, Dan) Date: Fri, 18 Apr 1997 13:04:17 -0400 Subject: Memphis IETF ngtrans-6bone WG minutes Message-ID: Hi Bill, You had asked: > [...] However, I do have a question/concern regarding the > proposed encapsulation. It uses a new AFI (35) and I don't think > that is currently one of the approved ATM NSAP formats by the > ATM Forum, so there is some concern that this could potentially > lead to some operational problems. The original Internet Draft > version of this subject used the normal AFI of 47 with an ICD > of 0090, which definitely would not be a problem for ATM use. > What was the rationale for changing this to use a new AFI? My recollection (and I was not involved in the actual discussions taking place) was that the use of IANA's ICD value for this purpose left no possibility of any other potential use, and was thus considered too restrictive. The new AFI value was a way to avoid this limitation (although it clearly was not the only possible solution). Dan From solensky@ftp.com Fri Apr 18 18:07:22 1997 From: solensky@ftp.com (Frank T Solensky) Date: Fri, 18 Apr 1997 13:07:22 -0400 Subject: New 6bone site Message-ID: <199704181703.NAA08676@MAILSERV-2HIGH.FTP.COM> FTP Software is now hooked up to the 6bone via a tunnel to UNH. The RIPE db info follows and is already in the registry; I'm looking to find out our elevation now. The first IPv6 address should be pingable, the second should be set up later today. site: FTP-SOFTWARE location: North Andover, MA loc-string: 42 42 10.33n 71 07 31.44w prefix: 5f00:0100:807f::/48 ping: 5f00:0100:807f:0000:0400:0800:201f:4eaa ping: 5f00:0100:807f:0000:f100:0020:afa2:f408 tunnel: 128.127.4.5 132.177.118.22 UNH contact: Bill Lambroukas status: operational remark: Happily echoing your pings since April 1997 changed: solensky@ftp.com 970417 source: RIPE From ben@tellus.co.uk Sat Apr 19 18:13:51 1997 From: ben@tellus.co.uk (Ben Crosby) Date: Sat, 19 Apr 1997 18:13:51 +0100 Subject: Update on USOT-ECS/UK In-Reply-To: <199704081913.VAA21136@pelican.tk.uni-linz.ac.at> Message-ID: <3.0.1.32.19970419181351.00901100@smtp.tellus.co.uk> Hi, A huge thanks to all of you who have been providing me with help.. I'm now fairly happy with USOT-ECS, and the following stuff has changed recently; We are now providing the Defence Research Agency (DRA/UK) with their 6bone connectivity, via UUNET and SICS. We've finally got our nameservers sorted, and so 6bone-gw.ipv6.ecs.soton.ac.uk should be pingable. The two mailing lists that are run from here, uk6bone and ip6ac are now accessible via IPv6, and can accept ipv6 email addresses for subscriptions. I'm very close to being able to supply and accept a newsfeed over IPv6, thanks to Craig Metz' hard work. Those interested in joining in, please email me. Thanks, Ben. From dchiu@cs.ubc.ca Tue Apr 22 00:54:42 1997 From: dchiu@cs.ubc.ca (Daniel Chiu) Date: Mon, 21 Apr 1997 16:54:42 -0700 (PDT) Subject: Attachment point to 6bone Message-ID: Hi, I would like to connect my user machine to the 6bone and would like to know if someone would be willing to tell me which would be the most appropriate attachment point? Thank you for your assistance. Daniel Chiu dchiu@cs.ubc.ca From jarius@iac.co.jp Tue Apr 22 04:45:14 1997 From: jarius@iac.co.jp (Jarius Jenkins) Date: Tue, 22 Apr 1997 12:45:14 +0900 (JST) Subject: Attachment point to 6bone In-Reply-To: Message-ID: Hello, I am looking to attach a couple of machines to the 6bone. Right now I have 1 Linux machine, 1 Sparc/Solaris, and 1 Windows95 Machine. I work for an Internet Service Provider in Japan, and have contacted WIDE about a connection. They informed me that theirs is for research only, and wanted to know what research I could provide them with. At this point, I have no specific "research" under which to connect to them... In the future we will be looking into integrating this with our customer base (obviously a while off now), but for now I am just trying to get things set up. I have the information for my systems now, but we will be swithing from our current connection of 1 64k lan connection, and 1 128k connection to two 128k connections (obtaining new IP addresses and probably with different ASN's from the current connections). As for the future, we are connected through two of Japan's giants in telecommunications, and have greater than 15Mbps bandwidth to our servers, but those are offsite, and will only obtain IPV6 connections after they have been tested inhouse, and have been proven to work. From brian@hursley.ibm.com Tue Apr 22 09:34:19 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Tue, 22 Apr 1997 09:34:19 +0100 Subject: Memphis IETF ngtrans-6bone WG minutes In-Reply-To: from "Harrington, Dan" at Apr 18, 97 01:04:17 pm Message-ID: <9704220834.AA54810@hursley.ibm.com> The reason for the new AFI was that using the ICD didn't leave any code point for future use by the IANA; the new AFI gives the IANA a 16 bit code point for future use. This was done at the insistence of the IANA; personally I'd have stayed with the ICD, but that's water under the bridge. Actually Juha Heinanen may want a second code point, to provide a pure IPv4-in-ATM address embedding. He certainly hasn't expressed concern about the new AFI value. He has found a minor error in the RFC though (it doesn't spell out the complete IDP correctly, as I recall without checking.) Brian Carpenter >- Harrington, Dan said: > > Hi Bill, > > You had asked: > > [...] However, I do have a question/concern regarding the > > proposed encapsulation. It uses a new AFI (35) and I don't think > > that is currently one of the approved ATM NSAP formats by the > > ATM Forum, so there is some concern that this could potentially > > lead to some operational problems. The original Internet Draft > > version of this subject used the normal AFI of 47 with an ICD > > of 0090, which definitely would not be a problem for ATM use. > > What was the rationale for changing this to use a new AFI? > > My recollection (and I was not involved in the actual > discussions taking place) was that the use of IANA's > ICD value for this purpose left no possibility of any > other potential use, and was thus considered too restrictive. > The new AFI value was a way to avoid this limitation (although > it clearly was not the only possible solution). > > Dan > From Philip Blundell Tue Apr 22 21:12:55 1997 From: Philip Blundell (Philip Blundell) Date: Tue, 22 Apr 1997 21:12:55 +0100 (BST) Subject: 6bone partitioned? Message-ID: Hi guys. Here's a message I just sent to the UK-6bone mailing list. Not wanting to point fingers of blame, but could NRL and JOIN have a look at their routing tables and see if all is well? On a more positive subject, now that things are by and large fairly reliable and we are starting to see a fair amount of IPv6-capable mail software at large in the world, would there be any interest in setting up an exploder for this list so that people can actually the mail over their 6bone connections? p. ---------- Forwarded message ---------- Date: Tue, 22 Apr 1997 21:06:33 +0100 (BST) From: Philip Blundell To: Peter Curran Cc: UK 6bone Subject: Re: Connectivity On Tue, 22 Apr 1997, Peter Curran wrote: > I went and checked the NIST page (my normal measure of 'whats working') > and all was well. Looking at the traceroute info there I think that > there is some partitioning going on for sites that are not directly or > indirectly connected to NRL (or maybe its the other way round) - our > primary path is via a direct tunnel to NRL. It certainly looks now as if there is a partitioning effect. I suspect that some routes are getting lost where the backbone nodes peer with each other. This is what I get if I try to traceroute to BT-LABS (who get their connectivity from NRL). kings-cross:~$ traceroute 5f06:d800:c171:3a00::1 traceroute to 5f06:d800:c171:3a00::1 (5f06:d800:c171:3a00::1), 30 hops max, 60 byte packets 1 6bone-gw.lon.ip6.pipex.net (5f07:3900:9e2b:8500:0:1111:1111:1111) 14.777 ms !N 16.376 ms !N * kings-cross:~$ They apparently are up, because NIST can see them (and I imagine TICL can too). I checked Bob Fink's 6bone map. With the exception of NIST (who I _can_ see) all the other nodes off NRL are unreachable from here. I get a similar picture in Germany; all nodes fed from JOIN are unreachable aside from BME-FSZ. A traceroute to BME gives me this: kings-cross:~$ traceroute 5f09:f300:9842:4c00:4c:0:c067:7b99 traceroute to 5f09:f300:9842:4c00:4c:0:c067:7b99 (5f09:f300:9842:4c00:4c:0:c067:7b99), 30 hops max, 60 byte packets 1 6bone-gw.lon.ip6.pipex.net (5f07:3900:9e2b:8500:0:1111:1111:1111) 21.024 ms * 12.603 ms 2 5f07:2b00:82e1:e700:5:3333:3333:3333 (5f07:2b00:82e1:e700:5:3333:3333:3333) 79.197 ms * 98.866 ms 3 tracy.ipv6.fsz.bme.hu (5f09:f300:9842:4c00:4c:0:c067:7b99) 1007.476 ms * 630.767 ms kings-cross:~$ and a traceroute to NIST gives me this: kings-cross:~$ traceroute 5f00:3100:8106:3300:0:c0:3302:5a traceroute to 5f00:3100:8106:3300:0:c0:3302:5a (5f00:3100:8106:3300:0:c0:3302:5a), 30 hops max, 60 byte packets 1 6bone-gw.lon.ip6.pipex.net (5f07:3900:9e2b:8500:0:1111:1111:1111) 15.904 ms * 12.136 ms 2 6bone-core.ipv6.imag.fr (5f06:b500:8158:1a00:0:800:2bb9:f33d) 74.400 ms 66.592 ms 100.538 ms 3 luna-v6.ipv6.imag.fr (5f06:b500:8158:1a00:0:800:2075:24ea) 70.568 ms 329.833 ms 64.592 ms 4 ipng9.ipng.nist.gov (5f00:3100:8106:3300:0:c0:3302:5a) 245.904 ms * 482.212 ms kings-cross:~$ - in both cases it seems that either the 6bone map is wrong about the connectivity, or there are backup routes in place. I'll forward this to the main 6bone mailing list and see what people there have to say. p. From JOIN Project Team Wed Apr 23 11:57:24 1997 From: JOIN Project Team (JOIN Project Team) Date: Wed, 23 Apr 1997 12:57:24 +0200 (MEZ) Subject: 6bone partitioned? In-Reply-To: Message-ID: Hi Philip, On Tue, 22 Apr 1997, Philip Blundell wrote: > Hi guys. >=20 > Here's a message I just sent to the UK-6bone mailing list. Not wanting= to > point fingers of blame, but could NRL and JOIN have a look at their > routing tables and see if all is well?=20 >=20 > On a more positive subject, now that things are by and large fairly > reliable and we are starting to see a fair amount of IPv6-capable mail > software at large in the world, would there be any interest in setting = up > an exploder for this list so that people can actually the mail over the= ir > 6bone connections?=20 >=20 > p. >=20 > ---------- Forwarded message ---------- > Date: Tue, 22 Apr 1997 21:06:33 +0100 (BST) > From: Philip Blundell > To: Peter Curran > Cc: UK 6bone > Subject: Re: Connectivity >=20 > On Tue, 22 Apr 1997, Peter Curran wrote: >=20 > > I went and checked the NIST page (my normal measure of 'whats working= ') > > and all was well. Looking at the traceroute info there I think that > > there is some partitioning going on for sites that are not directly o= r > > indirectly connected to NRL (or maybe its the other way round) - our > > primary path is via a direct tunnel to NRL.=20 >=20 > It certainly looks now as if there is a partitioning effect. I suspect > that some routes are getting lost where the backbone nodes peer with ea= ch > other.=20 >=20 > This is what I get if I try to traceroute to BT-LABS (who get their > connectivity from NRL). >=20 > kings-cross:~$ traceroute 5f06:d800:c171:3a00::1 > traceroute to 5f06:d800:c171:3a00::1 (5f06:d800:c171:3a00::1), 30 hops > max, 60 byte packets > 1 6bone-gw.lon.ip6.pipex.net (5f07:3900:9e2b:8500:0:1111:1111:1111) > 14.777 ms !N 16.376 ms !N * > kings-cross:~$=20 >=20 > They apparently are up, because NIST can see them (and I imagine TICL c= an > too).=20 our router don=B4t get any route for 5f06:d800::/32. Normally we should g= et the prefix at least via RIPng from CICNET.=20 >=20 > I checked Bob Fink's 6bone map. With the exception of NIST (who I _can= _ > see) all the other nodes off NRL are unreachable from here. I get a > similar picture in Germany; all nodes fed from JOIN are unreachable asi= de > from BME-FSZ. >=20 > A traceroute to BME gives me this: >=20 > kings-cross:~$ traceroute 5f09:f300:9842:4c00:4c:0:c067:7b99 > traceroute to 5f09:f300:9842:4c00:4c:0:c067:7b99 > (5f09:f300:9842:4c00:4c:0:c067:7b99), 30 hops max, 60 byte packets > 1 6bone-gw.lon.ip6.pipex.net (5f07:3900:9e2b:8500:0:1111:1111:1111) > 21.024 ms * 12.603 ms > 2 5f07:2b00:82e1:e700:5:3333:3333:3333 > (5f07:2b00:82e1:e700:5:3333:3333:3333) 79.197 ms * 98.866 ms > 3 tracy.ipv6.fsz.bme.hu (5f09:f300:9842:4c00:4c:0:c067:7b99) 1007.47= 6 > ms * 630.767 ms > kings-cross:~$ >=20 > and a traceroute to NIST gives me this: >=20 > kings-cross:~$ traceroute 5f00:3100:8106:3300:0:c0:3302:5a > traceroute to 5f00:3100:8106:3300:0:c0:3302:5a > (5f00:3100:8106:3300:0:c0:3302:5a), 30 hops max, 60 byte packets > 1 6bone-gw.lon.ip6.pipex.net (5f07:3900:9e2b:8500:0:1111:1111:1111) > 15.904 ms * 12.136 ms > 2 6bone-core.ipv6.imag.fr (5f06:b500:8158:1a00:0:800:2bb9:f33d) 74.4= 00 > ms 66.592 ms 100.538 ms > 3 luna-v6.ipv6.imag.fr (5f06:b500:8158:1a00:0:800:2075:24ea) 70.568 = ms > 329.833 ms 64.592 ms > 4 ipng9.ipng.nist.gov (5f00:3100:8106:3300:0:c0:3302:5a) 245.904 ms = * > 482.212 ms > kings-cross:~$=20 >=20 > - in both cases it seems that either the 6bone map is wrong about the > connectivity, or there are backup routes in place. the 6bone map does not show all tunnels of transit and leaf sites. If you refer to the ripe registry you see that NIST has also a tunnel to G6 = - that explains your traceroute. Your traceroute to BME goes via UNI-C because we don=B4t have a direct tunnel to UUNET... - Guido -------------------------------------------------------------------------= ----- JOIN -- IP Version 6 in the WiN Guido Wessendorf A project of DFN Westfaelische Wilhelms-Universitaet Mue= nster Project Team email: Universitaetsrechenzentrum join@uni-muenster.de Einsteinstrasse 60 http://www.join.uni-muenster.de D-48149 Muenster / Germany phone: +49 251 83 31639, fax: +49 251 83 31653, email: wessend@uni-muenst= er.de -------------------------------------------------------------------------= ----- > I'll forward this to the main 6bone mailing list and see what people th= ere > have to say. >=20 > p. >=20 >=20 From guyd@uunet.pipex.com Wed Apr 23 16:30:08 1997 From: guyd@uunet.pipex.com (Guy Davies) Date: Wed, 23 Apr 1997 16:30:08 +0100 (BST) Subject: 6bone partitioned? In-Reply-To: Message-ID: On Wed, 23 Apr 1997, JOIN Project Team wrote: > > This is what I get if I try to traceroute to BT-LABS (who get their > > connectivity from NRL). > >=20 > > kings-cross:~$ traceroute 5f06:d800:c171:3a00::1 > > traceroute to 5f06:d800:c171:3a00::1 (5f06:d800:c171:3a00::1), 30 hops > > max, 60 byte packets > > 1 6bone-gw.lon.ip6.pipex.net (5f07:3900:9e2b:8500:0:1111:1111:1111) > > 14.777 ms !N 16.376 ms !N * > > kings-cross:~$=20 > >=20 > > They apparently are up, because NIST can see them (and I imagine TICL c= an > > too).=20 >=20 > our router don=B4t get any route for 5f06:d800::/32. Normally we should g= et > the prefix at least via RIPng from CICNET.=20 Hi Philip & Guido, We also have no connectivity to the address you show. 6bone-lon-gw#sho ipv6 route 5f06:d800:c171:3a00::1/128 Route not found BT-LABS also have connections to IFB and ULANC. I am getting RIPng from IFB so clearly there's either broken RIPng from BT-LABS or the static from IFB to BT-LABS isn't being redistributed or BT-LABS don't really have a tunnel to IFB. I think ULANC are either down or not running a RIPng routing daemon because their RIPng session to us is not running. This certainly explains your lack of connectivity to BT-LABS but not necessarily to anywhere else. Guy From davidk@isi.edu Thu Apr 24 02:28:38 1997 From: davidk@isi.edu (davidk@isi.edu) Date: Wed, 23 Apr 1997 18:28:38 -0700 (PDT) Subject: power outage for the experimental 6bone registry Message-ID: <9704240128.AA22823@brind.isi.edu> Hi, The experimental 6BONE registry at ISI will unfortunately be down this night due to scheduled maintenance work to the electrical power systems which will result in a power outage. E-mail updates can be send but will be deferred until the system is up again, queries will not work. However, at least in theory, and if you really need the data, a full dump of the database can be obtained from my webpage (http://www.isi.edu/~davidk/6bone/) since the web server runs from another power source. Bob Fink and me have already agreed that we will have in the future at least one real time mirror server running at another location to make sure that we will always have at least one server up and running and ready to answer your queries. My apologies for the inconvenience, David K. --- From stuart@pa.dec.com Fri Apr 25 06:47:14 1997 From: stuart@pa.dec.com (Stephen Stuart) Date: Thu, 24 Apr 97 22:47:14 -0700 Subject: Updates to DIGITAL-CA Message-ID: <9704250547.AA07042@nsl-too.pa.dec.com> Tunnels added to SURFNET and TANET-TW. We're testing new proxy aggregation code to address the problem with more specific routes within the SOFTBANK prefix that Alain pointed out at the Memphis 6bone meeting. If anyone sees a more specific route within the prefix 5F01:2200:2D00::/48, could you please let me know (along with whether you receive it directly from me or through a third party). Thanks, Stephen From RLFink@lbl.gov Fri Apr 25 16:25:37 1997 From: RLFink@lbl.gov (Bob Fink) Date: Fri, 25 Apr 1997 08:25:37 -0700 Subject: Attachment point to 6bone In-Reply-To: Message-ID: Daniel, At 4:54 PM -0700 4/21/97, Daniel Chiu wrote: >Hi, > >I would like to connect my user machine to the 6bone and would like to >know if someone would be willing to tell me which would be the most >appropriate attachment point? > >Thank you for your assistance. > >Daniel Chiu >dchiu@cs.ubc.ca Did anyone respond you yet? If not...my recommendations for UBC (given its connectivity from my perspective) is to come in thru NWNET in the Seattle area. This would give you good connectivity until we have a Canadian-based transit or backbone site. Contact: Doug Junkins Thanks, Bob ============= Find route to: www.ubc.ca. (137.82.194.43), Max 30 hops, 40 byte packets Host Names truncated to 32 bytes 1 ir30gw.lbl.gov. (128.3.9.1 ): 2ms 1ms 2ms 2 er1gw.lbl.gov. (131.243.128.11 ): 1ms 2ms 1ms 3 lbl-lc1-1.es.net. (198.128.16.11 ): 2ms 2ms 1ms 4 ames-lbl-atms.es.net. (134.55.28.1 ): 8ms 7ms 7ms 5 fix-west-cpe.sanfrancisco.mci.ne (192.203.230.18 ): 7ms 7ms 7ms 6 * 6 core1-hssi3-0.sanfrancisco.mci.n (204.70.1.205 ): 11ms 14ms 7 core1.seattle.mci.net. (204.70.4.165 ): 24ms 24ms 24ms 8 border2-fddi-0.seattle.mci.net. (204.70.3.146 ): 24ms 28ms 27ms 9 canet.seattle.mci.net. (204.70.53.6 ): 31ms 27ms 26ms 10 205.207.238.133 (205.207.238.133): 33ms 109ms 97ms 11 psp.bc.canet.ca. (205.207.238.173): 29ms 31ms 29ms 12 * 12 regiona12.bc.canet.ca. (192.68.61.102 ): 34ms 31ms 13 ubc-ubiquity.ubc.bc.net. (142.231.2.1 ): 35ms 33ms 32ms 14 anguhub14.net.ubc.ca. (137.82.207.1 ): 33ms 38ms 35ms 15 cscihub1.net.ubc.ca. (137.82.202.2 ): 36ms 31ms 33ms 16 web.ucs.ubc.ca. (137.82.194.10 ): 40ms * 35ms *Trace completed* ===== site: NorthWestNet location: Bellevue, Washington, USA loc-string: 47 35 2n 122 8 2w 5m prefix: 5F02:AD00:C050:0D00/64 ping: mahogany.ipv6.nwnet.net (5f02:ad00:c050:d00:1:800:207F:049D) ping: nwnet-6bone-gw.ipv6.nwnet.net (5f02:ad00:c050:d00:1::c1a:c8a8) tunnel: 192.220.249.249 204.123.2.236 DIGITAL-CA/US - RIPng operational tunnel: 192.220.249.249 128.223.222.11 UOREGON/US - RIPng operational tunnel: 192.220.249.249 131.103.1.54 CICNET/US - RIPng operational tunnel: 192.220.249.249 137.229.12.248 ALASKA/US - RIPng operational tunnel: 192.220.249.249 158.43.137.157 UUNET/UK - RIPng experimental tunnel: 192.220.249.249 198.128.2.27 ESNET/US - RIPng operational tunnel: 192.220.249.249 140.142.96.1 UW/US - Static operational tunnel: 192.220.249.249 199.242.16.23 IXA/US - RIPng operational contact: Doug Junkins status: operational since 12/6/96 remarks: nwnet-6bone-gw.nwnet.net is a Cisco 4000M remarks: will add tunnels to people with ipv4 connectivity to remarks: NorthWestNet, MCI, Sprint's Seattle POP, and UUNet's remarks: Seattle and Portland POPs. remarks: Please send connectivity problems and requests to the remarks: above contact changed: junkins@nwnet.net 970326 source: RIPE -end From RLFink@lbl.gov Fri Apr 25 18:55:59 1997 From: RLFink@lbl.gov (Bob Fink) Date: Fri, 25 Apr 1997 10:55:59 -0700 Subject: new 6bone diagram - version 67 Message-ID: new 6bone diagram - version 67 move SURFNET/NL to backbone site add SURFNET-HQ/NL to SURFNET/NL move USOT-ECS/UK to transit site add DRA/UK to USOT-ECS/UK add TANET/TW to DIGITAL-CA/US add USL/UK to DIGITAL-ETC/FR Welcome to the new sites: SURFnet-HQ Hoog Catharijne, Utrecht, The Netherlands DRA-UK: Defence Research Agency, DRA Malvern, Worcestershire, UK TANET-TW IPv6 project (Transit site) Shen-Kan, Taipei, Taiwan, Republic of China Unidec Systems Ltd, Manor Chambers, Marygate, York, England Thanks, Bob From RLFink@lbl.gov Fri Apr 25 18:56:49 1997 From: RLFink@lbl.gov (Bob Fink) Date: Fri, 25 Apr 1997 10:56:49 -0700 Subject: 6bone country list - now at 25 Message-ID: Here is my list of countries on the 6bone. PLease let me know if I've messed it up somehow. I'll soon add a page for this on the web site. Thanks, Bob ============= AT - Austria AU - Australia CA - Canada BE - Belgium CH - Switzerland CN - China DE - Germany DK - Denmark ES - Spain FR - France HU _ Hungary IT - Italy JP - Japan KR - Korea KZ - Kazakhstan NL - Netherlands PL - Poland PT - Portugal RU - Russian Federation SE - Sweden SG - Singapore SK - Slovakia TW - Taiwan UK - United Kingdom US - United States ------------------ 25 countries From vonbrand@inf.utfsm.cl Fri Apr 25 22:34:42 1997 From: vonbrand@inf.utfsm.cl (Horst von Brand) Date: Fri, 25 Apr 1997 17:34:42 -0400 Subject: I'd like to connect to the 6bone... Message-ID: <199704252134.RAA04434@pincoya.inf.utfsm.cl> And I need some kind of step-by-step instructions for doing this. Note that I'm far off any place, and there is no local expertise/help to be had. Any URLs or other pointers? Thanks! -- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From junkins@nwnet.net Sat Apr 26 18:32:48 1997 From: junkins@nwnet.net (Doug Junkins) Date: Sat, 26 Apr 1997 10:32:48 -0700 (PDT) Subject: Attachment point to 6bone In-Reply-To: Message-ID: We're working with Daniel and his network adminstrator to set up a tunnel. - Doug / Douglas A. Junkins | Network Engineering \ / Network Engineer | NorthWestNet \ \ junkins@nwnet.net | Bellevue, Washington, USA / \ +1-206-649-7419 | / On Fri, 25 Apr 1997, Bob Fink wrote: > Daniel, > > At 4:54 PM -0700 4/21/97, Daniel Chiu wrote: > >Hi, > > > >I would like to connect my user machine to the 6bone and would like to > >know if someone would be willing to tell me which would be the most > >appropriate attachment point? > > > >Thank you for your assistance. > > > >Daniel Chiu > >dchiu@cs.ubc.ca > > Did anyone respond you yet? > > If not...my recommendations for UBC (given its connectivity from my perspective) is to come in thru NWNET in the Seattle area. This would give you good connectivity until we have a Canadian-based transit or backbone site. > > Contact: > > Doug Junkins > > > Thanks, > > Bob > > ============= > Find route to: www.ubc.ca. (137.82.194.43), Max 30 hops, 40 byte packets > Host Names truncated to 32 bytes > 1 ir30gw.lbl.gov. (128.3.9.1 ): 2ms 1ms 2ms > 2 er1gw.lbl.gov. (131.243.128.11 ): 1ms 2ms 1ms > 3 lbl-lc1-1.es.net. (198.128.16.11 ): 2ms 2ms 1ms > 4 ames-lbl-atms.es.net. (134.55.28.1 ): 8ms 7ms 7ms > 5 fix-west-cpe.sanfrancisco.mci.ne (192.203.230.18 ): 7ms 7ms 7ms > 6 * > 6 core1-hssi3-0.sanfrancisco.mci.n (204.70.1.205 ): 11ms 14ms > 7 core1.seattle.mci.net. (204.70.4.165 ): 24ms 24ms 24ms > 8 border2-fddi-0.seattle.mci.net. (204.70.3.146 ): 24ms 28ms 27ms > 9 canet.seattle.mci.net. (204.70.53.6 ): 31ms 27ms 26ms > 10 205.207.238.133 (205.207.238.133): 33ms 109ms 97ms > 11 psp.bc.canet.ca. (205.207.238.173): 29ms 31ms 29ms > 12 * > 12 regiona12.bc.canet.ca. (192.68.61.102 ): 34ms 31ms > 13 ubc-ubiquity.ubc.bc.net. (142.231.2.1 ): 35ms 33ms 32ms > 14 anguhub14.net.ubc.ca. (137.82.207.1 ): 33ms 38ms 35ms > 15 cscihub1.net.ubc.ca. (137.82.202.2 ): 36ms 31ms 33ms > 16 web.ucs.ubc.ca. (137.82.194.10 ): 40ms * 35ms > *Trace completed* > > ===== > site: NorthWestNet > location: Bellevue, Washington, USA > loc-string: 47 35 2n 122 8 2w 5m > prefix: 5F02:AD00:C050:0D00/64 > ping: mahogany.ipv6.nwnet.net (5f02:ad00:c050:d00:1:800:207F:049D) > ping: nwnet-6bone-gw.ipv6.nwnet.net (5f02:ad00:c050:d00:1::c1a:c8a8) > tunnel: 192.220.249.249 204.123.2.236 DIGITAL-CA/US - RIPng operational > tunnel: 192.220.249.249 128.223.222.11 UOREGON/US - RIPng operational > tunnel: 192.220.249.249 131.103.1.54 CICNET/US - RIPng operational > tunnel: 192.220.249.249 137.229.12.248 ALASKA/US - RIPng operational > tunnel: 192.220.249.249 158.43.137.157 UUNET/UK - RIPng experimental > tunnel: 192.220.249.249 198.128.2.27 ESNET/US - RIPng operational > tunnel: 192.220.249.249 140.142.96.1 UW/US - Static operational > tunnel: 192.220.249.249 199.242.16.23 IXA/US - RIPng operational > contact: Doug Junkins > status: operational since 12/6/96 > remarks: nwnet-6bone-gw.nwnet.net is a Cisco 4000M > remarks: will add tunnels to people with ipv4 connectivity to > remarks: NorthWestNet, MCI, Sprint's Seattle POP, and UUNet's > remarks: Seattle and Portland POPs. > remarks: Please send connectivity problems and requests to the > remarks: above contact > changed: junkins@nwnet.net 970326 > source: RIPE > > -end > > From warlock@csuchico.edu Sun Apr 27 09:14:34 1997 From: warlock@csuchico.edu (John Kennedy) Date: Sun, 27 Apr 1997 01:14:34 -0700 Subject: join request Message-ID: <199704270814.BAA07946@hircine.net.chico.ca.us> 04/27/97 @ 01:12:52 AM (Sunday) Seems like a chicken & egg situation, so I'll punt. (: I've got a linux-2.1.36 box set up and I think the 6bone tunnel is the next step. My boxes address is 132.241.60.98 if you want to test to it, and I've done a few traceroutes to likely destinations. Any steps I'm missing at this point? --- john =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= IPv6 calculations using the Subnet Address : 0 PREFIX 01011111 ASN 0000111100111011 RESERVED 00000000 IP 100001001111000100111100 RESERVED 00000000 SUBNET ADDR 0000000000000000 MAC ADDRESS 000000000010000010101111011100110010111111000110 Converting to hex: 5F0F3B0084F13C0000000020AF732FC6 Reforming to flat IPv6: 5F0F:3B00:84F1:3C00:0000:0020:AF73:2FC6 Shortens/Reduces to: 5F0F:3B00:84F1:3C00::20:AF73:2FC6 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [bmanning@isi.edu] 1 cuitlahac.net.CSUChico.EDU (132.241.60.97) 3.082 ms 3.405 ms 2.72 ms 2 john-parker-e31.net.CSUChico.EDU (132.241.66.1) 3.96 ms 1.949 ms 1.909 ms 3 john-bigboote.net.CSUChico.EDU (132.241.60.81) 2.651 ms 2.008 ms 1.924 ms 4 Chico.CSU.net (132.241.65.1) 2.826 ms 2.249 ms 2.148 ms 5 137.145.124.2 (137.145.124.2) 12.94 ms 14.81 ms 13.259 ms 6 sl-stk-17-H11/0-T3.sprintlink.net (144.228.147.13) 15.82 ms 15.644 ms 14.479 ms 7 144.228.40.22 (144.228.40.22) 32.203 ms 15.925 ms 15.574 ms 8 sl-stk-2-P4/0/0-155M.sprintlink.net (144.232.1.6) 17.313 ms 16.556 ms 16.75 ms 9 sl-mae-w-H1/0-T3.sprintlink.net (144.228.10.46) 21.608 ms 18.555 ms 18.395 ms 10 f6.peer1.sjc1.genuity.net (198.32.136.56) 38.311 ms 34.529 ms 29.908 ms 11 f6.core1.sjc1.genuity.net (207.240.1.33) 40.163 ms 33.817 ms 29.588 ms 12 core1.lax1.genuity.net (207.240.0.5) 40.959 ms 45.292 ms 39.107 ms 13 f6.peer1.lax1.genuity.net (207.240.1.30) 41.889 ms 38.588 ms 39.016 ms 14 sandbox.ep.net (198.32.146.11) 26.12 ms * 172.918 ms =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [gw-6bone@pa.dec.com] 1 cuitlahac.net.CSUChico.EDU (132.241.60.97) 5.411 ms 2.832 ms 2.613 ms 2 john-oconnor.net.CSUChico.EDU (132.241.66.33) 4.834 ms 4.006 ms 2.874 ms 3 john-bigboote.net.CSUChico.EDU (132.241.60.70) 2.157 ms 1.97 ms 2.022 ms 4 Chico.CSU.net (132.241.65.1) 2.311 ms 3.583 ms 2.456 ms 5 San-Francisco.CSU.net (137.145.120.2) 10.677 ms 13.903 ms 20.675 ms 6 sl-stk-17-H11/0-T3.sprintlink.net (144.228.147.13) 219.4 ms 214.151 ms 236.951 ms 7 144.228.40.19 (144.228.40.19) 14.103 ms 13.611 ms 23.941 ms 8 Hssi2-0.GW1.SFO1.ALTER.NET (137.39.166.121) 54.278 ms 42.731 ms 69.956 ms 9 421.atm3-0.cr2.sfo1.alter.net (137.39.13.46) 173.83 ms * 32.215 ms 10 133.Hssi12-0.CR2.PAO1.Alter.Net (137.39.71.229) 31.157 ms 35.89 ms 31.344 ms 11 312.atm2-0.br1.pao1.alter.net (137.39.13.145) 34.083 ms 48.62 ms 32.437 ms 12 digital-gw1.pa-x.dec.com (198.32.176.241) 28.716 ms 30.297 ms 30.595 ms 13 pax-6bone.pa-x.dec.com (204.123.2.236) 30.927 ms 1942.93 ms 34.644 ms =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [ipv6-support@cisco.com] 1 cuitlahac.net.CSUChico.EDU (132.241.60.97) 6.742 ms 84.784 ms 7.815 ms 2 john-oconnor.net.CSUChico.EDU (132.241.66.33) 82.782 ms 3.162 ms 3.212 ms 3 john-bigboote.net.CSUChico.EDU (132.241.60.70) 3.436 ms 2.005 ms 2.042 ms 4 Chico.CSU.net (132.241.65.1) 2.302 ms 2.327 ms 2.209 ms 5 San-Francisco.CSU.net (137.145.120.2) 11.47 ms 11.817 ms 10.561 ms 6 sl-stk-17-H11/0-T3.sprintlink.net (144.228.147.13) 15.92 ms 15.984 ms 15.741 ms 7 144.228.40.22 (144.228.40.22) 13.708 ms 15.106 ms 13.877 ms 8 sl-stk-2-P4/0/0-155M.sprintlink.net (144.232.1.6) 15.045 ms 13.995 ms 26.657 ms 9 sl-mae-w-H1/0-T3.sprintlink.net (144.228.10.46) 69.164 ms 329.786 ms 23.449 ms 10 sanjose1-br1.bbnplanet.net (198.32.136.19) 27.441 ms 31.025 ms 28.341 ms 11 paloalto-br2.bbnplanet.net (4.0.1.10) 28.755 ms 27.888 ms 38.954 ms 12 su-pr2.bbnplanet.net (131.119.0.218) 26.655 ms 28.152 ms 28.231 ms 13 cisco.bbnplanet.net (131.119.26.10) 28.429 ms 41.227 ms 31.145 ms 14 dirtylab-gw-2.cisco.com (192.31.7.47) 27.944 ms 32.346 ms 29.553 ms 15 eng-ios-dirtylab-gw.cisco.com (192.31.7.104) 28.048 ms * 32.204 ms =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [dorian@cic.net] 1 cuitlahac.net.CSUChico.EDU (132.241.60.97) 5.723 ms 4.997 ms 2.899 ms 2 john-parker-e31.net.CSUChico.EDU (132.241.66.1) 4.206 ms 1.956 ms 2.059 ms 3 john-bigboote.net.CSUChico.EDU (132.241.60.81) 2.569 ms 1.993 ms 1.9 ms 4 Chico.CSU.net (132.241.65.1) 2.587 ms 5.087 ms 2.187 ms 5 San-Francisco.CSU.net (137.145.120.2) 17.848 ms 14.405 ms 15.47 ms 6 sl-stk-17-H11/0-T3.sprintlink.net (144.228.147.13) 15.677 ms 17.037 ms 21.309 ms 7 144.228.40.22 (144.228.40.22) 19.63 ms 15.622 ms 22.585 ms 8 sl-stk-1-P10/0/0-155M.sprintlink.net (144.232.1.1) 17.372 ms 18.462 ms 25.546 ms 9 core4-hssi1-0.SanFrancisco.mci.net (206.157.77.65) 41.164 ms 191.319 ms 32.587 ms 10 bordercore3-loopback.WillowSprings.mci.net (166.48.32.1) 329.666 ms 111.526 ms 69.329 ms 11 cicnet.WillowSprings.mci.net (166.48.33.250) 81.222 ms 67.228 ms 70.832 ms 12 6bone.chicago.cic.net (131.103.1.54) 71.736 ms 71.525 ms * From mccann@zk3.dec.com Mon Apr 28 22:12:15 1997 From: mccann@zk3.dec.com (Jack McCann) Date: Mon, 28 Apr 1997 17:12:15 -0400 Subject: Getting attached... Message-ID: <9704282112.AA19293@wasted.zk3.dec.com> Jason, Digital is currently running the primary for 0.0.9.e.d.0.f.5.ip6.int. As Bill pointed out, this should probably be in MCI's hands, but due to the way things evolved, we're it for now. We'll contact MCI to see if we can fix this. In the mean time, I can simply delegate 0.0.4.9.c.9.e.c.0.0.9.e.d.0.f.5.ip6.int to you. Send me your server names/addresses and I'll put in the necessary glue. - Jack ---------------------------------------------- From macedo@ravel.ufrj.br Tue Apr 29 01:19:24 1997 From: macedo@ravel.ufrj.br (Sergio Ricardo Ferreira Macedo) Date: Mon, 28 Apr 1997 21:19:24 -0300 (EST) Subject: 6bone mailing list on Brasil Message-ID: <199704290019.VAA26721@protheus.ravel.ufrj.br> ANNOUNCING 6BONE-BR MAILING LIST. We're begining to build a IPv6 backbone on Brazil and setting it up for future connection with the 6bone. For discussing this matters we started up a mailing list at the High Speed Networks Laboratory at UFRJ. The brazilian subscribers of the 6bone mailing list are invited to subscribe the 6bone-br mailing list by sending mail to: majordomo@ravel.ufrj.br without subject and with the following content (I know it's well known information, but...) : subscribe 6bone-br yourusername@your.address Thanks for you attention. Sergio Macedo From RLFink@lbl.gov Tue Apr 29 02:47:53 1997 From: RLFink@lbl.gov (Bob Fink) Date: Mon, 28 Apr 1997 18:47:53 -0700 Subject: 6Bone meeting follow up In-Reply-To: <199704282143.RAA01351@emu.ncsl.nist.gov> Message-ID: Hsin, At 2:43 PM -0700 4/28/97, Hsin Fang wrote: >Hi Bob: > >Several people approached me after 6Bone meeting to show their interest >in "virtual provider based address" scheme. I would like to hear your opinion >for whether should I write a quick draft. Thanks. > >Regards, >Hsin As you probably saw in my 6bone action items list from Memphis, I had hoped to elicit comments over the mail list on your proposal (aee A2 below). I am basically enthusiastic about your proposal. My only hesitition was that we should be moving to a new "aggregation-based" test address format based on the Memphis IPng WG meeting (as soon as Bob Hinden writes up the draft). This does exactly what you propose, just in the new format under the 6bone test allocation. Thus my question is, is it worth trying to go through renumbering under the current format (reworked per your proposal) and then go through it again with the new test address? However, there may be issues (e.g., conversion to EUI-64 for host id) that may slow down the move to the new format, thus making it more reasonable to do your change for the interim. I'll copy this to the list in the hopes of getting some broader-based conversation on it. Thanks for bringing it up...and thanks for the ideas and presentation in Memphis. Bob ==== Date: Sun, 13 Apr 1997 15:00:32 -0700 To: 6bone@isi.edu (6BONE Mailer) From: Bob Fink Subject: 6bone action items per Memphis IETF meeting Sender: owner-6bone@ISI.EDU Precedence: bulk 6bone folk, The Memphis IETF was a very productive one for IPv6 and the 6bone. We will soon have a new Aggregation-Based Unicast Addressing Structure from the IPng WG, using the 64-bit EUI-64, which will certainly have direct implications for all developers and the 6bone. We also had a very successful conclusion to the Mike O'Dell 8+8/GSE proposals leaving us with definite directions on many issues. On the latter score (analysis of the GSE proposal) I strongly recommend that everyone read the Internet Draft by Crawford/Mankin/Narten/Stewart/Zhang that is available as draft-ipngwg-esd-analysis-00.txt. As for details of the above mentioned IPng WG actions, you will have to wait for their minutes. As for the 6bone WG meeting, we had many presentations on numerous items of great importance for us. I have outlined below what I think are the primary action items resulting from the meeting. Please comment on them to the mailer. If I have left something out, or misrepresented an issue, please let me know so I may correct the list as soon as possible. Thanks, Bob ================================================================= A1. Discussion of Allison Mankin's proposal to use the CAIRN Backbone as a native IPv6 transport backbone (among other things) for the 6bone. A2. Discussion of Hsin Fang's proposal to modify RFC1987 to use a virtual IPv6 provider ID instead of ASN for addressing in the 6bone. A3. Discussion of Bob Fink's proposal to follow the new Aggregation-Based Unicast Addressing Structure (when it is published as an Internet Draft) as the basis for a new addressing architecture for the 6bone, and the basis to start renumbering experiments. A4. Discussion of David Meyer's Internet Draft on "Representing IPv6 Tunnels in RPSL" so it may be included in the RPSL design at the RPS WG. A5. Discussion of David Kessens' new 6BONE registry, whether to switch to it, and if so, when. A6. Discussion of Bill Manning's ideas on using DNS for localized 6bone routing registry information. A7. Volunteers to help Bob Fink with an Internet Draft on requirements for new 6bone infrastructure. A8. Performa a survey of host and router implementations in use on the 6bone, so the information may be made available through the 6bone web pages. - end From RLFink@lbl.gov Tue Apr 29 02:53:54 1997 From: RLFink@lbl.gov (Bob Fink) Date: Mon, 28 Apr 1997 18:53:54 -0700 Subject: CAIRN & IPv6 In-Reply-To: <2.2.32.19970428202159.0098f410@cxr.research.att.com> Message-ID: Anders, At 1:21 PM -0700 4/28/97, Anders Fernstedt wrote: >Bob, > >Could you give me a quick brief of CAIRNs commitment/involvement in the >6bone. I missed the Memphis meeting, where I think Allison gave some form of >briefing... No more than was in the minutes (see below). I would like Allison to provide more information so we can all see what the real plans might/could be. I'll copy here on this to let her have the chance to put out something out to the mailer. >PS Are there any real-time trials planned to your knowledge? How do you mean this: real-time systems or testing in real-time? Thanks, Bob ----------------from the 6bone WG minutes: -------------------------------------------------------------------- 2. CAIRN Backbone / Allison Mankin -------------------------------------------------------------------- Allison Mankin presented her ideas for a native IPv6 backbone using the CAIRN research backbone network. - High bandwidth backbone for research, etc. (U.S. federal funding) - A diagram of the CAIRN topology was shown: + connectivity ranges from DS-3 to full OC-3. + several current v6 sites are CAIRN sites (ISI, LBL...) + each site has a PC/FreeBSD router and/or an Ascend GRL w/v6 support - Proposed possibilities for the backbone included: + Transit bandwidth service with native IPv6 unicast + Native IPv6 multicast path + V6 peering/exchange points + Experimental clearinghouse + Software distribution center Jim Bound commented that it was important for CAIRN's IPv6 implementation to use UNH interop lab/events to make sure there is proper interoperability before direct connectivity is attempted. Allison expressed her desire to join in the UNH testing. Further discussion was deferred to the mail list. -end From W. Richard Stevens" I have been having intermittent email problems for the past months that I have finally tracked down. Most hosts could send email to my kohala.com domain without a problem, but a few had continual problems. I have finally tracked the problem down to an MX record that points to a host with a AAAA record. The MX record was the one with a higher preference, and it was never used, but just the presence of a AAAA record for that host causes some mailers/nameservers to gag (and say the domain is unresolvable). The AAAA record was being returned by my nameserver as additional records for either an ANY query or an MX query. mcimail.com and mail12.digital.com are two of the servers that could not send me email. This is just a warning to others on the 6bone to avoid this problem. I know many sites are placing all the AAAA records into a separate .ipv6 subdomain, which solves the problem (or at least makes it a local problem), but at some point more of these AAAA records that older servers cannot grok are going to filter up. Rich Stevens I have been having intermittent email problems for the past months that I have finally tracked down. Most hosts could send email to my kohala.com domain without a problem, but a few had continual problems. I have finally tracked the problem down to an MX record that points to a host with a AAAA record. The MX record was the one with a higher preference, and it was never used, but just the presence of a AAAA record for that host causes some mailers/nameservers to gag (and say the domain is unresolvable). The AAAA record was being returned by my nameserver as additional records for either an ANY query or an MX query. mcimail.com and mail12.digital.com are two of the servers that could not send me email. This is just a warning to others on the 6bone to avoid this problem. I know many sites are placing all the AAAA records into a separate .ipv6 subdomain, which solves the problem (or at least makes it a local problem), but at some point more of these AAAA records that older servers cannot grok are going to filter up. Rich Stevens From RLFink@lbl.gov Tue Apr 29 15:19:05 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 29 Apr 1997 07:19:05 -0700 Subject: Attachment point to 6bone In-Reply-To: References: Message-ID: Jarius, At 8:45 PM -0700 4/21/97, Jarius Jenkins wrote: >Hello, > I am looking to attach a couple of machines to the 6bone. Right >now I have 1 Linux machine, 1 Sparc/Solaris, and 1 Windows95 Machine. I >work for an Internet Service Provider in Japan, and have contacted WIDE >about a connection. They informed me that theirs is for research only, and >wanted to know what research I could provide them with. At this point, I >have no specific "research" under which to connect to them... In the >future we will be looking into integrating this with our customer base >(obviously a while off now), but for now I am just trying to get things >set up. > I have the information for my systems now, but we will be swithing >from our current connection of 1 64k lan connection, and 1 128k connection >to two 128k connections (obtaining new IP addresses and probably with >different ASN's from the current connections). As for the future, we are >connected through two of Japan's giants in telecommunications, and have >greater than 15Mbps bandwidth to our servers, but those are offsite, and >will only obtain IPV6 connections after they have been tested inhouse, and >have been proven to work. Sorry to be so slow in getting a response to you. At the current time the 6bone isn't a production network, it is a testing network (see below). We certainly hope there will be a time when it turns into a real production network, but that is still in the future. Until that point in time the only thing you could do was try it out, learn from it and feedback into the product development and IETF community what you learn. In that context any 6bone backbone site should be willing to let you have a tunnel to them as it should be in line with their mission on the 6bone as well. Having said that, I appreciate that any given site might choose to try some real production application use (i.e. not testing in the 6bone definition) that could give a 6bone backbone or transit site difficulty with appropriate use. This is a hard situation to actually define (i.e., where it cannot be construed as IPv6 testing in some fashion), but I think we need to admit that it will happen. Thus I believe that in this (real production) case it is incumbent on the user to: (1) find a way to tunnel so that their IPv4 connectivity would route their traffic in a way compatible with their existing appropriate use agreements for production use; (2) let the 6bone participants know so there can be an agreement as to how to characterize the use, and what to do (use the 6bone as is or (1) above). Reading what you say above, I suspect you would characterize your 6bone usage as testing of IPv6, not production. Then you should have no trouble convincing any 6bone backbone or transit site, including WIDE for example, to give you a "connection". Though I'm sure my response to you here will generate some comment, I am very glad you inadvertently brought it up as you are certainly not the only site that will find yourself in the situation of wanting to move from testing over the 6bone to finding real IPv6 Internet connectivity. We all hope that the 6bone will turn from one to the other as appropriate. Thanks, Bob ========================================================================== Draft 6bone Charter as presented at the BOF The 6bone Working Group is a forum for information concerning the deployment, engineering, and operation of ipv6 protocols and procedures in the global Internet. This activity will include, but not be limited to: - Deployment of ipv6 transport and routing in the global Internet via a "6bone" testbed to assist in the following. - Creation of "practice and experience" informational RFC documents that capture the experiences of those who have deployed, and are deploying, various ipv6 technologies. - Feedback to various IETF ipv6-related activities, based on testbed experience, where appropriate. - Development of mechanisms and procedures to aid in the transition to native ipv6, where appropriate. - Development of mechanisms and procedures for sharing operational information to aid in operation of global ipv6 routing. -end From RLFink@lbl.gov Tue Apr 29 15:31:50 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 29 Apr 1997 07:31:50 -0700 Subject: I'd like to connect to the 6bone... In-Reply-To: <199704252134.RAA04434@pincoya.inf.utfsm.cl> Message-ID: At 2:34 PM -0700 4/25/97, Horst von Brand wrote: >And I need some kind of step-by-step instructions for doing this. Note >that I'm far off any place, and there is no local expertise/help to be >had. Any URLs or other pointers? Not for the faint of heart without some technical help. What is your machine environment (type of unix, or Windows or...). It may be that I can use you as a test case for getting a better writeup online. Thanks, Bob From RLFink@lbl.gov Tue Apr 29 16:12:00 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 29 Apr 1997 08:12:00 -0700 Subject: new 6bone diagram - version 68 Message-ID: new 6bone diagram - version 68 add NETHER/US to CICNET/US Welcome to the Nether Network in Ann Arbor, Michigan USA Bob From RLFink@lbl.gov Tue Apr 29 16:36:56 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 29 Apr 1997 08:36:56 -0700 Subject: MX/AAAA problems In-Reply-To: <199704291225.FAA01523@kohala.kohala.com> Message-ID: Rich, At 5:25 AM -0700 4/29/97, W. Richard Stevens wrote: >I have been having intermittent email problems for the past months >that I have finally tracked down. Most hosts could send email to my >kohala.com domain without a problem, but a few had continual problems. > >I have finally tracked the problem down to an MX record that points to >a host with a AAAA record. The MX record was the one with a higher >preference, and it was never used, but just the presence of a AAAA >record for that host causes some mailers/nameservers to gag (and say >the domain is unresolvable). The AAAA record was being returned by >my nameserver as additional records for either an ANY query or an MX >query. mcimail.com and mail12.digital.com are two of the servers >that could not send me email. > >This is just a warning to others on the 6bone to avoid this problem. >I know many sites are placing all the AAAA records into a separate >.ipv6 subdomain, which solves the problem (or at least makes it a >local problem), but at some point more of these AAAA records that >older servers cannot grok are going to filter up. Thanks for the explanation. Does anyone have a clue as to the pathology of the failure in dns code (or wherever) so we can blow a whistle on this quick? Bob From RLFink@lbl.gov Tue Apr 29 17:07:55 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 29 Apr 1997 09:07:55 -0700 Subject: new 6bone backbone links diagram - version 11 Message-ID: new 6bone backbone links diagram - version 11 added in SURNET/NL links added ESNET/US to NWNET/US link changed IDRPv6 color to green (couldn't use my red pen on the map :-) added BGP4+ legend Any BGP4+ links yet?? Anyone notice any missing links I should fix? Thanks, Bob From Alain.Durand@imag.fr Tue Apr 29 17:53:05 1997 From: Alain.Durand@imag.fr (Alain Durand) Date: Tue, 29 Apr 1997 18:53:05 +0200 Subject: MX/AAAA problems In-Reply-To: Bob Fink "Re: MX/AAAA problems" (Apr 29, 8:36am) References: Message-ID: <970429185305.ZM15384@rama.imag.fr> On Apr 29, 8:36am, Bob Fink wrote: > Subject: Re: MX/AAAA problems > Thanks for the explanation. Does anyone have a clue as to the pathology of > the failure in dns code (or wherever) so we can blow a whistle on this > quick? >From what we have seen, some DNS server are really picky. When they see unusual RR, they think the entry is either tainted or invalid. Some old secondary servers seeing AAAA records think the whole zone is invalid and refuse to tranfer it. That's the main reason why we choose to use a separate subdomain ipv6.foo.tld to store AAAA records. But then, there is another problem. How do you choose the outgoing E-mail address if you use the ipv6.foo.tld subdomain ? Should it be user@host.foo.tld or user@host.ipv6.foo.tld ? If you choose user@host.foo.tld, relpies will not use IPv6 but IPv4 instead. If you use user@host.ipv6.foo.tl and the mail is relayed later to an IPv4 MTA then, you end up with the same problem, this host may crash when it sees a AAAA record. :-( The ipv6 subdomain trick is only a short term patch. Hopefully people will upgrade to more recent releases of bind soon enough. - Alain. From enry@wayga.ratatosk.org Tue Apr 29 19:04:02 1997 From: enry@wayga.ratatosk.org (Mark Komarinski) Date: Tue, 29 Apr 1997 14:04:02 -0400 Subject: Want to find ASN Message-ID: <199704291804.OAA06990@wayga.ratatosk.org> Okay. I'm about ready to punt. How can I find an ASN around me? We're in the boston area going thru Alter.Net, but I can't seen to find anything relating to either Alternet or UUnet. Anyone have some hints? -Mark From stuart@pa.dec.com Tue Apr 29 20:18:51 1997 From: stuart@pa.dec.com (Stephen Stuart) Date: Tue, 29 Apr 97 12:18:51 -0700 Subject: Want to find ASN In-Reply-To: Your message of Tue, 29 Apr 97 14:04:02 -0400. <199704291804.OAA06990@wayga.ratatosk.org> Message-ID: <9704291918.AA12052@nsl-too.pa.dec.com> > Okay. I'm about ready to punt. How can I find an ASN around me? We're > in the boston area going thru Alter.Net, but I can't seen to find anything > relating to either Alternet or UUnet. Anyone have some hints? Assuming that the address whose origin ASN you want is in 208.197.0.0/12 (I looked up wayga.ratatosk.org and used 208.197.103.125 for this example): % whois -h whois.ra.net 208.197.103.125 route: 208.192.0.0/12 descr: UUNET Technologies descr: 3060 Williams Drive descr: Fairfax descr: VA 22031, USA origin: AS701 comm-list: COMM_NSFNET advisory: AS690 1:701 mnt-by: MAINT-AS701 changed: knight@uu.net 961004 source: RADB The origin ASN for your address is 701. Stephen From crawdad@fnal.gov Tue Apr 29 22:19:26 1997 From: crawdad@fnal.gov (Matt Crawford) Date: Tue, 29 Apr 1997 16:19:26 -0500 Subject: MX/AAAA problems In-Reply-To: "29 Apr 1997 18:53:05 +0200." <"970429185305.ZM15384"@rama.imag.fr> Message-ID: <199704292119.QAA05931@gungnir.fnal.gov> > On Apr 29, 8:36am, Bob Fink wrote: > > Thanks for the explanation. Does anyone have a clue as to the pathology of > > the failure in dns code (or wherever) so we can blow a whistle on this > > quick? I didn't find anything wrong in a current sendmail source. And my desktop has had a AAAA RR for quite some time now, without a special sub-zone to hold it. > Some old secondary servers seeing AAAA records think the whole zone > is invalid and refuse to tranfer it. And the last time I delved into bind, the named-xfer program that did a zone transfer for a secondary server created a text-format file, so it couldn't accept any new RR type it didn't know about. Ugh. I hope that's been fixed. > The ipv6 subdomain trick is only a short term patch. Hopefully people > will upgrade to more recent releases of bind soon enough. And running into these problems is success for the 6bone, not failure. Matt From RLFink@lbl.gov Tue Apr 29 23:35:05 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 29 Apr 1997 15:35:05 -0700 Subject: Want to find ASN In-Reply-To: <199704291804.OAA06990@wayga.ratatosk.org> Message-ID: At 11:04 AM -0700 4/29/97, Mark Komarinski wrote: >Okay. I'm about ready to punt. How can I find an ASN around me? We're >in the boston area going thru Alter.Net, but I can't seen to find anything >relating to either Alternet or UUnet. Anyone have some hints? The ASN you need to use is the ASN of the place in the backbone providing you with 6bone service so we can simulate at least reasonable route aggregation. So first you should pick a point for 6bone tunnelling as close to your v4 connectivity as "reasonably" possible. At the moment, UUNET in the US doesn't have a 6bone setup yet (tho Mike O'Dell says they may soon be able to become a 6bone backbone site). Thus I would suggest BAY/US (in Billerica, Msss.) until UUNET is up: contact: Wenken Ling contact: Dimitry Haskin Once you get them to agree to home you, then you would use their ASN. Thanks, Bob From guyd@uunet.pipex.com Wed Apr 30 01:22:04 1997 From: guyd@uunet.pipex.com (Guy Davies) Date: Wed, 30 Apr 1997 01:22:04 +0100 (BST) Subject: Want to find ASN In-Reply-To: <199704291804.OAA06990@wayga.ratatosk.org> Message-ID: Hi Mark, UUNET/UK have a 6bone router to which you can connect. However, this may not be the best option as all your US to US traffic would traverse the Atlantic twice :-( I would suggest you look at the 6bone backbone sites (http://www-cnr.lbl.gov/6bone/6bone-drawing.html is a good point from which to check the details of the sites) and traceroute to each. The one with the best IPv4 connectivity should be your first choice. Regards, Guy On Tue, 29 Apr 1997, Mark Komarinski wrote: > Okay. I'm about ready to punt. How can I find an ASN around me? We're > in the boston area going thru Alter.Net, but I can't seen to find anything > relating to either Alternet or UUnet. Anyone have some hints? > > -Mark > From RLFink@lbl.gov Wed Apr 30 15:32:19 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 30 Apr 1997 07:32:19 -0700 Subject: 6bone Tshirt 2nd order mailings started Message-ID: Sorry to be so slow on mailing the Tshirts. This morning the first batch of 6bone Tshirts for the 2nd (and final) order went out. PLEASE DON'T EMAIL ME ASKING ABOUT YOUR ORDER...IT WILL BE MAILED DURING THE NEXT 5 DAYS (PROVIDING YOU WERE ON MY LIST OF COURSE :-) To date the following have been mailed: ================================================================================ Ames, Kurt 1 XL address on file Asayesh, Hamid 1 XXL address on file Banerjee, Partha 2 L address on file Bassham, Larry 1 L address on file, prepaid Batie, Alan 1 XL address on file Behrle, Jeremy 1 XXL address on file Blanchet, Marc 4 L address on file Boggs, Adam 1 XL address on file Boneparth, David 1 XL aaddress on file Bortzmeyer, Stephane 1 XL address on file Bourgeois, Judd 1 XL address on file Burson, Jeff 1 XL address on file Chavez, Paul 1 XL address on file Cully, Brian 1 XL address on file Desrosiers, Luc 1 XL address on file Dewell, Aaron 1 L, 1 XL address on file Fenwick, Wynn 1 XL, 1 XXL address on file Hankins, Greg 1 M address on file Harrison, Jeff 1 XL address on file Hoag, Andrew 1 XXL address on file Homelien, Oystein 1 L, 1 XL address on file Jin, Bih-Huang 1 L address on file King, Paul 2 XXL address on file Kyriannis, Jimmy 1 L, 1 XL address on file Lee, Chongeun 1 M address on file Lekashman, John 2 S, 1 XL, 1 XXL address on file Lerperger, Michael 1 XL address on file Levenberg, Richard 2 L address on file Lewis, David 1 XXL address on file Markov, Igor 1 M address on file Marlowe, Matthew 2 XL address on file Martin, David 1 L address on file Metz, Craig 1 L address on file, prepaid Narayan, Vishy 1 M, 1 L address on file Peachey, Alex 2 L, 1 XL address on file Shah, Sameer 1 XL address on file ******addon Stewart, John 1 XL address on file Sullivan, Don 1 M address on file Tannenbaum, Andrew 1 XL address on file Tate, Mike 1 XL address on file Thompson, Jim 1 M, 1 L address on file Virgilio, Vincenzo 2 XL, 1 L address on file Whalen, Matthew 1 L address on file Yang, Eric 1 M address on file ================================================================================ Please send NO checks/money until after you have received your Tshirt(s) in the mail. The cost is still $10 per Tshirt including mailing anywhere. When you do send a check (only upon receipt of Thsirts) please make it out to Robert L. Fink and mail to: Robert L. Fink 3085 Buena Vista Way Berkeley, CA 94708 USA ================================================================================ From RLFink@lbl.gov Wed Apr 30 16:37:16 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 30 Apr 1997 08:37:16 -0700 Subject: new 6bone backbone links diagram - version 12 Message-ID: new 6bone backbone links diagram - version 12 change peering to BGP4+ for: UUNET/UK to CICNET/US UUNET/UK to CISCO/US CISCO/US to CICNET/US Congratulations on the first BGP IPv6 peerings! Please keep me informed as these BGP peering occur so I can get them on the diagram...we need the impetus on this one! Thanks, Bob http://www-6bone.lbl.gov/6bone/6bone-bblinks.html From RLFink@lbl.gov Wed Apr 30 16:34:01 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 30 Apr 1997 08:34:01 -0700 Subject: new 6bone diagram - version 69 Message-ID: new 6bone diagram - version 69 add WUSTL/US to CICNET/US http://www-6bone.lbl.gov/6bone/6bone-drawing.html Welcome to Washington University in St. Louis, Missouri, USA. Thanks, Bob From jyy@ans.net Wed Apr 30 19:50:00 1997 From: jyy@ans.net (Jessica Yu) Date: Wed, 30 Apr 1997 14:50:00 -0400 Subject: Loop ... Message-ID: <199704301850.OAA15895@cannes.aa.ans.net> 6bone.wtn.ans.net#traceroute ipv6 5F0D:E900:80DF:DE00:0001:0060:3E0B:3008 Type escape sequence to abort. Tracing the route to 5F0D:E900:80DF:DE00:1:60:3E0B:3008 1 5F02:3000:C020:AE00:201D::1 68 msec 64 msec 76 msec 2 5F07:2B00:82E1:E700:5:3333:3333:3333 224 msec * * 3 5F04:FB00:80B0::BF42:C0:3302:14 444 msec * 232 msec 4 5F06:B500:8158:1A00::800:2BB9:F33D 356 msec 356 msec 352 msec 5 5F07:2B00:82E1:E700:5:3333:3333:3333 340 msec * 296 msec 6 5F04:FB00:80B0::BF42:C0:3302:14 348 msec * 368 msec 7 5F06:B500:8158:1A00::800:2BB9:F33D 372 msec 408 msec 392 msec 8 5F07:2B00:82E1:E700:5:3333:3333:3333 392 msec * 588 msec 9 5F04:FB00:80B0::BF42:C0:3302:14 416 msec * 400 msec 10 5F06:B500:8158:1A00::800:2BB9:F33D 500 msec 496 msec 432 msec 11 5F07:2B00:82E1:E700:5:3333:3333:3333 500 msec 568 msec * 12 5F04:FB00:80B0::BF42:C0:3302:14 524 msec 524 msec 508 msec 13 5F06:B500:8158:1A00::800:2BB9:F33D 604 msec 688 msec 788 msec 14 5F07:2B00:82E1:E700:5:3333:3333:3333 716 msec 616 msec 576 msec .............. --Jessica From dhaskin@baynetworks.com Wed Apr 30 22:54:29 1997 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Wed, 30 Apr 1997 17:54:29 -0400 Subject: dhaskin Message-ID: <199704302154.RAA26414@pobox.engeast.BayNetworks.COM> Hi, I've updated the Bay's registry record with new tunnels: tunnel: 192.32.29.62 130.88.12.119 UMAN, UK, RIPng tunnel: 192.32.29.62 192.87.106.15 SURFnet, Netherlands, RIPng tunnel: 192.32.29.62 204.148.62.66 ANS, USA, RIPng We've also started route filtering. In the most cases when a number of more specific routes are advertised to us along with an aggregate, more specific routes are ignored. Let's know if there is any problem. Example before filtering: Prefix Protocol Intf. Metric ------------------------------------------- ---------- ------- ---------- 5F00:3100::0000/32 RIPv6 20 2 5F00:3100::0000/32 RIPv6 12 2 5F00:3100::0000/32 RIPv6 4 3 5F00:3100:8106:3300::0000/80 RIPv6 12 2 5F00:3100:8106:3E00::0000/80 RIPv6 4 4 5F00:3100:8106:E000::0000/80 RIPv6 4 4 5F00:3100:8106:E100::0000/80 RIPv6 4 4 After filtering Prefix Protocol Intf. Metric ------------------------------------------- ---------- ------- ---------- 5F00:3100::0000/32 RIPv6 20 2 5F00:3100::0000/32 RIPv6 12 2 5F00:3100::0000/32 RIPv6 4 3 Thanks, Dimitry From dhaskin@baynetworks.com Wed Apr 30 22:48:45 1997 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Wed, 30 Apr 1997 17:48:45 -0400 Subject: updated BAY record Message-ID: <199704302148.RAA26066@pobox.engeast.BayNetworks.COM> Hi, I've updated the Bay's registry record with new tunnels: tunnel: 192.32.29.62 130.88.12.119 UMAN, UK, RIPng tunnel: 192.32.29.62 192.87.106.15 SURFnet, Netherlands, RIPng tunnel: 192.32.29.62 204.148.62.66 ANS, USA, RIPng We've also started route filtering. In the most cases when a number of more specific routes are advertised to us along with an aggregate, more specific routes are ignored. Let's know if there is any problem. Example before filtering: Prefix Protocol Intf. Metric ------------------------------------------- ---------- ------- ---------- 5F00:3100::0000/32 RIPv6 20 2 5F00:3100::0000/32 RIPv6 12 2 5F00:3100::0000/32 RIPv6 4 3 5F00:3100:8106:3300::0000/80 RIPv6 12 2 5F00:3100:8106:3E00::0000/80 RIPv6 4 4 5F00:3100:8106:E000::0000/80 RIPv6 4 4 5F00:3100:8106:E100::0000/80 RIPv6 4 4 After filtering Prefix Protocol Intf. Metric ------------------------------------------- ---------- ------- ---------- 5F00:3100::0000/32 RIPv6 20 2 5F00:3100::0000/32 RIPv6 12 2 5F00:3100::0000/32 RIPv6 4 3 Thanks, Dimitry