From Alain.Durand@imag.fr Wed Oct 1 12:42:53 1997 From: Alain.Durand@imag.fr (Alain Durand) Date: Wed, 1 Oct 1997 13:42:53 +0200 Subject: New addressing plan Message-ID: <971001134253.ZM2706@rama.imag.fr> The G6 main node is now fully converted to the addressing plan in the pTLA 3ffe:0300::/24. The G6 leaf & transit sub-sites are converting starting now, this proccess should be finish by Nov. 1st. - Alain. From RLFink@lbl.gov Wed Oct 1 16:40:07 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 1 Oct 1997 08:40:07 -0700 Subject: status of 6bone addressing and backbone restructuring conversion Message-ID: Well, it is October 1, and the addressing and backbone restructuring conversion is well underway. I have enclosed the current status page from: (http://www.6bone.net/6bone_pTLA_list.html) Several sites have not provided me with their status yet. Please do so. Thanks, Bob ============================================================= ipv6-site name test prefix status for conversion -------------- -------------- ------------------------ INNER/US-VA 3FFE:0000::/24 converted TELEBIT/DK 3FFE:0100::/24 ready by Oct 1 w/EUI-64 SICS/SE 3FFE:0200::/24 ready by mid-Oct w/EUI-64 G6/FR 3FFE:0300::/24 ready by Oct 1 w/EUI-64 JOIN/DE 3FFE:0400::/24 ready by Oct 1 w/EUI-64 WIDE/JP 3FFE:0500::/24 ready by mid-Oct w/EUI-64 SURFNET/NL 3FFE:0600::/24 ESNET/US 3FFE:0700::/24 ready by Oct 1 W/EUI-64 ISI-LAP/US-CA 3FFE:0800::/24 CICNET/US-IL 3FFE:0900::/24 NWNET/US-WA 3FFE:0A00::/24 VIAGENIE/CA 3FFE:0B00::/24 ready by Oct 1 CISCO/US-CA 3FFE:0C00::/24 ready by Oct 1 w/EUI-64 ANSNET/US-DC 3FFE:0D00::/24 IFB/GB 3FFE:0E00::/24 ready by Oct 1 NRL/US-DC 3FFE:0F00::/24 converted CSELT/IT 3FFE:1000::/24 ready by Oct 1, wait on Inria, Sun and Telebit for EUI-64 UUNET-UK/GB 3FFE:1100::/24 ready by Oct 1 w/EUI-64 when Sun delivers DIGITAL-CA/US 3FFE:1200::/24 BAY/US 3FFE:1300::/24 ready by mid-Oct UNI-C/DK 3FFE:1400::/24 UO/US-OR 3FFE:1500::/24 NUS-IRDU/SG 3FFE:1600::/24 MREN/US-IL 3FFE:1700::/24 ready by Oct 1 w/EUI-64 when Sun delivers INTEROP/US 3FFE:1800::/24 3COM /US-CA 3FFE:1900::/24 ready by mid-OCt w/EUI-64 CAIRN/US 3FFE:1A00::/24 reserved 3FFE:1B00::/24 (for VERIO, but no 6bone registry entry yet) MERIT/US-MI 3FFE:1C00::/24 ready by Oct 1 w/EUI-64 when Sun delivers ATT-LABS-EUROPE/CH 3FFE:1D00::/24 ready by Oct 1 w/EUI-64 SWISS-TELECOM/CH 3FFE:1E00::/24 NETCOM-UK/GB 3FFE:1F00::/24 SWITCH/CH 3FFE:2000::/24 ready by Nov 2 w/ JANET/GB 3FFE:2100::/24 ready by Oct 1 w/EUI-64 STUBA/SK 3FFE:2200::/24 ready by Oct 1 INFN-CNAF/IT 3FFE:2300::/24 INR/RU 3FFE:2400::/24 NLNET/NL 3FFE:2500::/24 -end From RLFink@lbl.gov Wed Oct 1 16:39:28 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 1 Oct 1997 08:39:28 -0700 Subject: maps/diagrams for the 6bone Message-ID: It is time for the issue of updating the 6bone maps. The current maps are out of date, and certainly don't reflect the new backbone or recent sites added. Andrew Scott, of Lancaster University, has developed several automatically generated maps based on the new addressing structure. Take a look at: http://www.cs-ipv6.lancs.ac.uk/ftp-archive/6Bone/Maps and specifially look at: http://www.cs-ipv6.lancs.ac.uk/ftp-archive/6Bone/Maps/backbone.gif If it is possible these (or a variant) would suffice for our uses, it would have many advantages over the manually done ones. I see these advantages as accuracy, being up-to-date, and, my favorite, no work by me :-) Disadvantages would be the need to be more disciplined with our 6bone registry information used to build the maps, and the complexity of specifying and implementing the automated diagram. Thus I would like to hear from 6bone participants as to what use the diagrams are. Comments to the mailer please. Thanks, Bob From RLFink@lbl.gov Wed Oct 1 17:31:39 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 1 Oct 1997 09:31:39 -0700 Subject: DNS 6bone setup info Message-ID: I have updated the hookup page for DNS info using David Lee's DNS config information. Please see: http://www.6bone.net/6bone_hookup.html Please look at this and let me know if it seems ok. Comments to the mailer. Thanks, Bob From Marc.Blanchet@viagenie.qc.ca Wed Oct 1 21:44:20 1997 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Wed, 01 Oct 1997 16:44:20 -0400 Subject: bb routing Message-ID: <3.0.3.32.19971001164420.007302e8@mail.viagenie.qc.ca> Hi, In order to avoid multiple BGP peering among the bb sites, I'm thinking about putting a 6bone route server (like the current route server project of Merit in the current ipv4 world) so that every bb site can get routes from it. It can be fed by the registry db entries. Since it requires correct registries entry, then it has the same disadvantages as the Bob lancaster-maps proposal. I talked to the author of the route server software and the author of th= e ipv6 gated. It shouldn't be too difficult to convert it (route server software) for the 6bone. I can get someone here to do it (with me). Comments? Does it make any sense to have a 6bone route server?=20 Regards, Marc. ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagenie inc. | http://www.viagenie.qc.ca 3107 des hotels | tel.: 418-656-9254=20 Ste-Foy, Quebec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp: 57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifi=E9, Editions Logiques, 1997 ------------------------------------------------------------ From davidk@isi.edu Fri Oct 3 21:23:54 1997 From: davidk@isi.edu (davidk@isi.edu) Date: Fri, 3 Oct 1997 13:23:54 -0700 (PDT) Subject: hardware failure 6bone registry Message-ID: <9710032023.AA25706@brind.isi.edu> Hi, This morning, we experienced a disk crash on the 6bone registry machine. I have redirected the whois query interface to a mirror backup machine. The mirror site will show you information from last night. Updates are currently being queued until a replacement machine is up and running which is expected to happen by the end of the day. I expect that we will not experience any data loss, however updates that have been done *after* last evening will not be visible until the replacement machine is on-line, David K. --- From davidk@isi.edu Sat Oct 4 02:52:22 1997 From: davidk@isi.edu (davidk@isi.edu) Date: Fri, 3 Oct 1997 18:52:22 -0700 (PDT) Subject: 6bone registry information Message-ID: <9710040152.AA05851@brind.isi.edu> Hi, A temporary replacement machine has been setup and is up and running. As far as I can see, no information is lost. Queries and updates will work as normal, however since we had to update DNS, whois.6bone.net might point to the wrong machine for a while. Thus, if you cannot connect to whois.6bone.net, use brind.isi.edu instead. Also, the automatic lookup of person/role information, when doing an ipv6-site/inet6num query, is not supported. The ftp site with raw database files is not supported on the replacement machine but you can get the same information through the web site at: http://www.isi.edu/~davidk/6bone/. This service will be restored, when time allows, later next week. David K. --- From grime@dcn.soongsil.ac.kr Sat Oct 4 04:19:40 1997 From: grime@dcn.soongsil.ac.kr (Park, Ilkyun) Date: Sat, 04 Oct 1997 12:19:40 +0900 Subject: An IPv6 WWW client Message-ID: <3.0.1.32.19971004121940.0068bf6c@dcn.soongsil.ac.kr> I am a graduate student at Soongsil graduate school. I want to run WWW client program over IPv6. Can I get the status of IPv6 WWW client programs used in 6bone? I have the information about Inria's MMM Web client, but I want to know about the others, too. o_O............................................. mailto:grime@dcn.soongsil.ac.kr From Francis.Dupont@inria.fr Sat Oct 4 11:47:31 1997 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Sat, 04 Oct 1997 12:47:31 +0200 Subject: An IPv6 WWW client In-Reply-To: Your message of Sat, 04 Oct 1997 12:19:40 +0900. <3.0.1.32.19971004121940.0068bf6c@dcn.soongsil.ac.kr> Message-ID: <199710041047.MAA16941@givry.inria.fr> In your previous mail you wrote: I am a graduate student at Soongsil graduate school. I want to run WWW client program over IPv6. Can I get the status of IPv6 WWW client programs used in 6bone? I have the information about Inria's MMM Web client, but I want to know about the others, too. => I know there are some IPv6 versions of Mosaic but Mosaic is not the easiest program to recompile from the sources... I'd like to do an IPv6 version of Lynx (very nice browser with a text only interface, very useful for fast browsing (no stupid blinking images :-) or for testing a page for individual users (in Europe the bandwidth is incredibly expensive than when you have to pay for it you disable the load of image fist :-)). The problem is I don't know if I have the time to do it. Someone has suggested the Arena browser too... Regards Francis.Dupont@inria.fr PS: if you look at the "ports" collection of FreeBSD you can find: - arena-i18n-beta3b - chimera-1.65 - linemode-4.0D - lynx-2.7.1 - mmm-0.40 - mosaic-2.7b5 - netscape-2.02 - netscape-3.01 - netscape-4.0b3 - slang-lynx-2.7.1 - w3-2.2.26 This gives the way to patch and build them too... From Rajesh Kr. Semwal" Hi, I'm a student of Comp. Sci. and working on a project to implement IPv6 under Linux op. system. Since we do not have an IPv6 router, we wish to connect ourselves to the 6bone so as to check our implementation by interacting with other sites with IPv6. So, how can i get connected to 6bone. For that, what type of software shall i need? Pl. suggest any sites where I can get more info. regarding 6bone. Thanx. Bye. From dauphin@sig.enst.fr Mon Oct 6 10:03:27 1997 From: dauphin@sig.enst.fr (Gilles Dauphin) Date: Mon, 6 Oct 1997 11:03:27 +0200 Subject: An IPv6 WWW client Message-ID: <199710060903.LAA11292@tomcat.enst.fr> > From Francis.Dupont@inria.fr Sat Oct 4 17:27:47 1997 > > > PS: if you look at the "ports" collection of FreeBSD you can find: > - arena-i18n-beta3b > - chimera-1.65 > - linemode-4.0D > - lynx-2.7.1 > - mmm-0.40 > - mosaic-2.7b5 > - netscape-2.02 > - netscape-3.01 > - netscape-4.0b3 > - slang-lynx-2.7.1 > - w3-2.2.26 > This gives the way to patch and build them too... > mMosaic-3.2.0 have Ipv6 functionnality too. Gilles From chong@mail52.mitretek.org Tue Oct 7 23:26:14 1997 From: chong@mail52.mitretek.org (Chongeun Lee) Date: Tue, 7 Oct 97 18:26:14 -0400 Subject: Comment on 6bone map Message-ID: <971007182614.25331@mail52.mitretek.org.0> Bob, Following your input, I looked at http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Maps/ and http://www.cs-ipv6.lancs.ac.uk/ftp-archive/6Bone/Maps/6Bone.gif I can see how it would be more efficient to have machine generated maps/diagrams as more and more sites are being added to 6bone and frequent changes/updates are being made on the 6bone structure and 6bone database. But when you are talking about moving to this new automated map, were you also planning on changing the design of these maps? From the user's perspective, I felt quite dizzy trying to decipher what was written around the circle edge. Some words looked overlapped with other letters. And even if I could read all of them, it looked too messy for me to do any planning for my testing. At the moment, I just wish to be able to see all the pTLA's, NLA's etc. along with the leaf sites in a clearly legible, well-organized format, plus each site's information in the 6bone database. The current 6bone map has served me very well so far. Chongeun From Marc.Blanchet@viagenie.qc.ca Wed Oct 8 04:03:24 1997 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Tue, 07 Oct 1997 23:03:24 -0400 Subject: ipv6 panel at a canadian workshop Message-ID: <3.0.3.32.19971007230324.0399e638@mail.viagenie.qc.ca> Hi, I'm looking for people for making a panel on ipv6&6bone at the next CaNe= t II workshop, end of november, Montr=E9al, Qu=E9bec. (CaNet II =3D Interne= t II equivalent in Canada). Anyone interested in participating? (particularly canadian people). Regards, Marc. ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagenie inc. | http://www.viagenie.qc.ca 3107 des hotels | tel.: 418-656-9254=20 Ste-Foy, Quebec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp: 57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifi=E9, Editions Logiques, 1997 ------------------------------------------------------------ From jane@iaeste.no Wed Oct 8 11:40:01 1997 From: jane@iaeste.no (Jan Marius Evang) Date: 08 Oct 1997 12:40:01 +0200 Subject: reconnecting IPv6 site. Message-ID: Hi! After not being connected for a while, We would like to take up out IPv6 activities again. I understand the adressing scheeme has changed, and I get a message from whois to update the "object". Is teher something written about what I need to change, or should I just read through everything at www.6bone.net? Marius PS. Whois entry at http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois/UIO.html -- -O Rxyskatt From RLFink@lbl.gov Wed Oct 8 12:19:56 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 8 Oct 1997 04:19:56 -0700 Subject: Comment on 6bone map In-Reply-To: <971007182614.25331@mail52.mitretek.org.0> Message-ID: Chongeun , At 3:26 PM -0700 10/7/97, Chongeun Lee wrote: >Bob, > >Following your input, I looked at > > http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Maps/ > >and > > http://www.cs-ipv6.lancs.ac.uk/ftp-archive/6Bone/Maps/6Bone.gif > >I can see how it would be more efficient to have machine generated >maps/diagrams as more and more sites are being added to 6bone and frequent >changes/updates are being made on the 6bone structure and 6bone database. > >But when you are talking about moving to this new automated map, were you also >planning on changing the design of these maps? From the user's perspective, >I felt quite dizzy trying to decipher what was written around the circle edge. > Some words looked overlapped with other letters. And even if I could read >all of them, it looked too messy for me to do any planning for my testing. > >At the moment, I just wish to be able to see all the pTLA's, NLA's etc. along >with the leaf sites in a clearly legible, well-organized format, plus each >site's information in the 6bone database. The current 6bone map has served me >very well so far. These are important points and ones I want to address before I settle on this technique as the only map generation method. Thanks for your comments...and stay tuned as Andrew and I work on this. Thanks, Bob From RLFink@lbl.gov Fri Oct 10 00:21:03 1997 From: RLFink@lbl.gov (Bob Fink) Date: Thu, 9 Oct 1997 16:21:03 -0700 Subject: reconnecting IPv6 site. In-Reply-To: Message-ID: Marius, At 3:40 AM -0700 10/8/97, Jan Marius Evang wrote: >Hi! >After not being connected for a while, We would like to take up out >IPv6 activities again. I understand the adressing scheeme has >changed, and I get a message from whois to update the "object". Yes it has, and you need new implementations to use it - ones that support AGGR and EUI-64. The 6bone web pages for hookups has some info on this. Take a look: http://www.6bone.net/6bone_hookup.html >Is teher something written about what I need to change, or should I >just read through everything at www.6bone.net? There is also the info I've sent via the 6bone mail list. See below. Let me know if you need more info...and suggestions as to what should be added to the web pages to make this clearer. Thanks, Bob ==== To: 6bone@isi.edu (6BONE Mailer) From: Bob Fink Subject: new 6bone test address registry facility started up 6bone folk, David Kessens has setup his new inet6num object in the 6bone registry to allow us to assign, with delegation, the new IPv6 test addresses. To this end, a top level object has been assigned to me for the new test TLA with a netname of TEST-TLA-6BONE, with an inet6num value of 3FFE::/16 (see below). You can reference this object, as well as other new inet6num objects, by using the 6bone whois query: http://www.6bone.net/whois.html This object is the owner, if you will, of all objects below it. However, it is my intention to assign pTLAs as delegated objects and then let them sub-delegate. Thus I have created (with some automatic help from David Kessens) the pTLA objects below the test TLA. I have shown a sample object below (the one for TELEBIT). All pTLAs have been assigned using their existing 6bone registry ipv6-name as their netname within the inet6num object. The exceptions to this are MREN, 3COM and VERIO which have not made their 6bone registry entries yet. They must create their 6bone registry entries if they wish to use their pTLA assignment (I will create their inet6num objects as soon as their entries are created). You should note that the "mnt-by" and "mnt-lower" fields are set to a new maintainer object created for your site that has the name "MNT-netname" with the value set to the "notify" value for your site. You can change this as you will, but the important thing to note is that the "mnt-lower" assignment is the person that gets to delegate other inet6num objects below your site's pTLA assignment. I think this is enough for now to get you thinking. Please address questions to the list, copied to David and me, so we can all learn. Thanks, Bob ============================================= inet6num: 3FFE::/16 netname: TEST-TLA-6BONE descr: Test Address Space for the 6bone country: AT AU BE CA CH DE DK ES FI FR GB country: HU IE IT JP KR KZ NL NO PL PT RO RU country: SE SG SK TW US admin-c: RLF1-6BONE tech-c: BM2-6BONE tech-c: DK13-RIPE rev-srv: ns.isi.edu rev-srv: imag.imag.fr remarks: contact RLF1-6BONE for allocation of a pTLA remarks: contact BM2-6BONE for reverse delegations remarks: contact DK13-RIPE for issues regarding the 6bone registry remarks: version 3 mnt-by: RLF1-6BONE mnt-lower: RLF1-6BONE changed: davidk@ISI.EDU 19970908 changed: rlfink@lbl.gov 19970909 source: 6BONE ========================== inet6num: 3FFE:100::/24 netname: TELEBIT descr: pTLA delegation for the 6bone country: DK admin-c: HHA1-6BONE tech-c: HHA1-6BONE mnt-by: MNT-TELEBIT mnt-lower: MNT-TELEBIT changed: RLFink@lbl.gov 19970909 source: 6BONE -end From jane@iaeste.no Fri Oct 10 08:17:57 1997 From: jane@iaeste.no (Jan Marius Evang) Date: 10 Oct 1997 09:17:57 +0200 Subject: reconnecting IPv6 site. In-Reply-To: Bob Fink's message of Thu, 9 Oct 1997 16:21:03 -0700 References: Message-ID: >> Bob Fink writes: BF> Yes it has, and you need new implementations to use it - ones BF> that support AGGR and EUI-64. The 6bone web pages for hookups BF> has some info on this. Take a look: OK. I suppose the newest Linux kernels and Cisco IOS (IPv6) has this? Or is it just the tools? BF> http://www.6bone.net/6bone_hookup.html >> Is teher something written about what I need to change, or should >> I just read through everything at www.6bone.net? BF> There is also the info I've sent via the 6bone mail list. See BF> below. BF> Let me know if you need more info...and suggestions as to what BF> should be added to the web pages to make this clearer. When I make it work, I'll see if a mini-howto is needed :-) BF> This object is the owner, if you will, of all objects below it. BF> However, it is my intention to assign pTLAs as delegated objects BF> and then let them sub-delegate. This means that I need to have a pTLA delegated to for instance Norway? Or is this already done? BF> sample object below (the one for TELEBIT). All pTLAs have been BF> assigned using their existing 6bone registry ipv6-name as their BF> netname within the inet6num object. BF> TELEBIT descr: pTLA delegation for the 6bone country: DK BF> admin-c: HHA1-6BONE tech-c: HHA1-6BONE mnt-by: MNT-TELEBIT BF> mnt-lower: MNT-TELEBIT changed: RLFink@lbl.gov 19970909 source: BF> 6BONE So I shopuld update all these fields in the "whois database"? Thanks for you help, I'll have a look at that web page. Marius -- -O Rxyskatt From J. Paul Reed" To 6bone listers: Hi. I just subscribed the the 6bone mailing list (sorry for that null message; that was my fault). Allow me to introduce myself; my name's J. Paul Reed. I'm doing a project for an Extended Essay I'm doing on IPv4 vs. IPv6 (this is for the International Baccalaureate program, www.ibo.org.uk, if you've never heard of it). As part of this project, I wanted to hook Poudre School District (my home school district) up to the 6bone to get the experience of actually connecting an IPv6 host up to a network. I would then analyze the connection process as part of the essay. Unfortunately, the two 6bone nodes I've sent email to have completely ignored me, so I was wondering if there was someone out here who might be able to help me (us) by agreeing to give the first public K12 school district a tunneled connection! I was also wondering if someone could give me a time estimate of how long it would take to get an address block and get ourselves registered because (big surprise) I have procrastinated and there is a time element on this project. If anyone could help, that'd be great! Thanks for your time! Later, Paul ------------------------------------------------------------------- J. Paul Reed preed@psd.k12.co.us || paul@619pro.com Computer, you and I need to have a little talk... --Chief Miles O'Brien, "Emissary," Star Trek: DS9 Geek Code and various other frivolities at www.psd.k12.co.us/~preed From brian@hursley.ibm.com Mon Oct 13 15:38:45 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Mon, 13 Oct 1997 15:38:45 +0100 Subject: query re IPv6 URL format Message-ID: <9710131438.AA21266@hursley.ibm.com> Hi, Has anybody implemented a Web browser that accepts IPv6 numeric addresses as part of a URL, and if so what format did you use? (to be clear, I am after the IPv6 equivalent of the existing URL format such as http://194.196.110.160/~bc/ ) (also to be clear, the RFC 1884 syntax will break existing browsers) Thanks for any info Brian Carpenter From dauphin@sig.enst.fr Tue Oct 14 08:49:18 1997 From: dauphin@sig.enst.fr (Gilles Dauphin) Date: Tue, 14 Oct 1997 09:49:18 +0200 Subject: query re IPv6 URL format Message-ID: <199710140749.JAA20365@tomcat.enst.fr> > From brian@hursley.ibm.com Mon Oct 13 20:56:47 1997 > > Hi, > > Has anybody implemented a Web browser that accepts IPv6 numeric > addresses as part of a URL, and if so what format did you use? > > (to be clear, I am after the IPv6 equivalent of > the existing URL format such as http://194.196.110.160/~bc/ ) > > (also to be clear, the RFC 1884 syntax will break existing > browsers) Here is a comment I found in mMosaic . file libwww2/HTTCP.c : /* manage only non numeric adresses */ /* RFC 2133 */ Gilles From brian@hursley.ibm.com Tue Oct 14 09:20:43 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Tue, 14 Oct 1997 09:20:43 +0100 Subject: query re IPv6 URL format In-Reply-To: <199710140749.JAA20365@tomcat.enst.fr> from "Gilles Dauphin" at Oct 14, 97 09:49:18 am Message-ID: <9710140820.AA103720@hursley.ibm.com> In other words they punted. Thanks Brian >- Gilles Dauphin said: > > > > From brian@hursley.ibm.com Mon Oct 13 20:56:47 1997 > > > > Hi, > > > > Has anybody implemented a Web browser that accepts IPv6 numeric > > addresses as part of a URL, and if so what format did you use? > > > > (to be clear, I am after the IPv6 equivalent of > > the existing URL format such as http://194.196.110.160/~bc/ ) > > > > (also to be clear, the RFC 1884 syntax will break existing > > browsers) > > Here is a comment I found in mMosaic . file libwww2/HTTCP.c : > /* manage only non numeric adresses */ > /* RFC 2133 */ > > Gilles > From Francis.Dupont@inria.fr Tue Oct 14 10:07:06 1997 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Tue, 14 Oct 1997 11:07:06 +0200 Subject: query re IPv6 URL format In-Reply-To: Your message of Mon, 13 Oct 1997 15:38:45 BST. <9710131438.AA21266@hursley.ibm.com> Message-ID: <199710140907.LAA16460@givry.inria.fr> In your previous mail you wrote: Has anybody implemented a Web browser that accepts IPv6 numeric addresses as part of a URL, and if so what format did you use? (to be clear, I am after the IPv6 equivalent of the existing URL format such as http://194.196.110.160/~bc/ ) (also to be clear, the RFC 1884 syntax will break existing browsers) => I believe the agreement is to implement only the name format for URL and X11 displays (in both cases hexadecimal litteral addresses break the whole thing). I know there is something similar in IETF minutes for RFC 822 (ie bc@[194.196.110.160] has no equivalent for IPv6). It is not a problem because IPv6 litterals are not for humans, ie not very suitable for good user interfaces... Regards Francis.Dupont@inria.fr From deering@cisco.com Tue Oct 14 14:45:10 1997 From: deering@cisco.com (Steve Deering) Date: Tue, 14 Oct 1997 06:45:10 -0700 Subject: query re IPv6 URL format In-Reply-To: <199710140907.LAA16460@givry.inria.fr> References: Your message of Mon, 13 Oct 1997 15:38:45 BST. <9710131438.AA21266@hursley.ibm.com> Message-ID: At 2:07 AM -0700 10/14/97, Francis Dupont wrote: > => I believe the agreement is to implement only the name format > for URL and X11 displays (in both cases hexadecimal litteral addresses > break the whole thing). I know there is something similar in IETF minutes > for RFC 822 (ie bc@[194.196.110.160] has no equivalent for IPv6). > It is not a problem because IPv6 litterals are not for humans, ie > not very suitable for good user interfaces... I thought the decision was to express the IPv6 address in hexadecimal without the ":"s, i.e., just 32 contiguous hex digits, which is even less user-friendly than the standad represenatation, but at least usable by humans in a pinch and certainly usable by automatons. Steve From brian@hursley.ibm.com Tue Oct 14 15:23:27 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Tue, 14 Oct 1997 15:23:27 +0100 Subject: query re IPv6 URL format In-Reply-To: from "Steve Deering" at Oct 14, 97 06:45:10 am Message-ID: <9710141423.AA86521@hursley.ibm.com> If that was the decision then we need to codify it and tell the world. I could live with it, if the URL parsers can handle it. I'll check that with the URL guys. Brian >- Steve Deering said: > > At 2:07 AM -0700 10/14/97, Francis Dupont wrote: > > => I believe the agreement is to implement only the name format > > for URL and X11 displays (in both cases hexadecimal litteral addresses > > break the whole thing). I know there is something similar in IETF minutes > > for RFC 822 (ie bc@[194.196.110.160] has no equivalent for IPv6). > > It is not a problem because IPv6 litterals are not for humans, ie > > not very suitable for good user interfaces... > > I thought the decision was to express the IPv6 address in hexadecimal > without the ":"s, i.e., just 32 contiguous hex digits, which is even > less user-friendly than the standad represenatation, but at least > usable by humans in a pinch and certainly usable by automatons. > > Steve > > > From Francis.Dupont@inria.fr Tue Oct 14 17:40:25 1997 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Tue, 14 Oct 1997 18:40:25 +0200 Subject: query re IPv6 URL format In-Reply-To: Your message of Tue, 14 Oct 1997 06:45:10 PDT. Message-ID: <199710141640.SAA02394@givry.inria.fr> In your previous mail you wrote: I thought the decision was to express the IPv6 address in hexadecimal without the ":"s, i.e., just 32 contiguous hex digits, which is even less user-friendly than the standad represenatation, but at least usable by humans in a pinch and certainly usable by automatons. => I see two problems with this new proposal: - it doesn't work with standard cut and paste - it is still ambiguous because it has the same syntax than a name (ie a label of a DNS host name). Regards Francis.Dupont@inria.fr From deering@cisco.com Tue Oct 14 18:11:06 1997 From: deering@cisco.com (Steve Deering) Date: Tue, 14 Oct 1997 10:11:06 -0700 Subject: query re IPv6 URL format In-Reply-To: <199710141640.SAA02394@givry.inria.fr> References: Your message of Tue, 14 Oct 1997 06:45:10 PDT. Message-ID: At 9:40 AM -0700 10/14/97, Francis Dupont wrote: > In your previous mail you wrote: > > I thought the decision was to express the IPv6 address in hexadecimal > without the ":"s, i.e., just 32 contiguous hex digits, which is even > less user-friendly than the standad represenatation, but at least > usable by humans in a pinch and certainly usable by automatons. > > => I see two problems with this new proposal: Certainly. As far as I know, no one has come up with a problem-free proposal. > - it doesn't work with standard cut and paste Sure it does -- you just have to edit the string a little after you paste. :-) > - it is still ambiguous because it has the same syntax than > a name (ie a label of a DNS host name). So maybe the proposal included putting the hex string in quotes or something. I was just reporting what I thought was a decision by some community that had hashed this issue out. Treat it as a rumor until someone else substantiates it. Steve From deering@cisco.com Tue Oct 14 19:08:28 1997 From: deering@cisco.com (Steve Deering) Date: Tue, 14 Oct 1997 11:08:28 -0700 Subject: query re IPv6 URL format In-Reply-To: <199710141640.SAA02394@givry.inria.fr> References: Your message of Tue, 14 Oct 1997 06:45:10 PDT. Message-ID: At 9:40 AM -0700 10/14/97, Francis Dupont wrote: > - it is still ambiguous because it has the same syntax than > a name (ie a label of a DNS host name). What's the limit on the length of a DNS label (not the whole DNS name, but the thing that goes between the dots in a DNS name)? Is it less than 32, by any chance? Steve From hinden@Ipsilon.COM Tue Oct 14 19:47:01 1997 From: hinden@Ipsilon.COM (Bob Hinden) Date: Tue, 14 Oct 1997 11:47:01 -0700 Subject: query re IPv6 URL format In-Reply-To: <9710141423.AA86521@hursley.ibm.com> References: Message-ID: <3.0.3.32.19971014114701.008d0a60@mailhost.ipsilon.com> Brian, >If that was the decision then we need to codify it and tell >the world. I could live with it, if the URL parsers can handle >it. I'll check that with the URL guys. > Maybe I am missing something, but... The IPv4 syntax is: http://111.222.333.444/~bc It would seem to me that while http://aaaa:bbbb::cccc:dddd/~bc has multiple ":"'s in it, given left to right parsing, I don't see anything ambiguous. The first thing after the "//" is either a DNS name, IPv4 address, or an IPv6 address. If the current parsers can distinguish between "hursley.ibm.com" and "111.222.333.444", both of which use dots as separators, then could they also deal with IPv6 addresses with colons? Why can't the parsers learn how to do this? They need to be changed to handle IPv6 addresses anyway. Bob From Francis.Dupont@inria.fr Tue Oct 14 19:53:24 1997 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Tue, 14 Oct 1997 20:53:24 +0200 Subject: query re IPv6 URL format In-Reply-To: Your message of Tue, 14 Oct 1997 11:08:28 PDT. Message-ID: <199710141853.UAA04426@givry.inria.fr> In your previous mail you wrote: At 9:40 AM -0700 10/14/97, Francis Dupont wrote: > - it is still ambiguous because it has the same syntax than > a name (ie a label of a DNS host name). What's the limit on the length of a DNS label (not the whole DNS name, but the thing that goes between the dots in a DNS name)? Is it less than 32, by any chance? => the limit is less than 64: lost! Regards Francis.Dupont@inria.fr From crawdad@fnal.gov Tue Oct 14 19:53:26 1997 From: crawdad@fnal.gov (Matt Crawford) Date: Tue, 14 Oct 1997 13:53:26 -0500 Subject: query re IPv6 URL format Message-ID: <199710141853.NAA21340@gungnir.fnal.gov> Brian, I brought this up quite some time ago and there was a little discussion, in which you participated, but no "decision" as such that I recall. Here's my original message and a summary ... ------- Forwarded Messages To: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: clash between PS rfc1884 and PS rfc1783 Date: Tue, 16 Jan 96 14:19:31 -0600 The text representation of IPv6 addresses specified in item 2 of section 2.2 of RFC1884: For example the following addresses: 1080:0:0:0:8:800:200C:417A a unicast address [...] may be represented as: 1080::8:800:200C:417A a unicast address results in a possible ambiguity if such an IPv6 address appears in a URL constructed according to RFC1738 (section 3.1): While the syntax for the rest of the URL may vary depending on the particular scheme selected, URL schemes that involve the direct use of an IP-based protocol to a specified host on the Internet use a common syntax for the scheme-specific data: //:@:/ (While RFC1738 only mentions IPv4 addresses appearing as , it will be widely presumed that IPv6 addresses may also be used.) If the last 16-bit component of an IPv6 address used as in a URL contains only digits 0 through 9, it may look as if a port number is present. Conversely, if a port number is present and has no more than four digits, it will resemble a part of the IPv6 address. Solutions: 1. Change the textual representation of IPv6 addresses. 2. Forbid the "::" abbreviation of IPv6 addresses in URLs and other contexts in which a port number might be appended with a colon. (Then counting the fields will reveal whether a port number is present.) 3. Forbid the use of literal IPv6 addresses in URLs. 4. Change the syntax of URLs. All of these have drawbacks. I suggest that #1 is better than #2, and #3 and #4 are out of the question. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------- Message 2 To: iesg@CNRI.Reston.VA.US, ipng@sunroof.Eng.Sun.COM Cc: Robert Elz , huitema@pax.inria.fr (Christian Huitema), Brian Carpenter CERN-CN , Francis Dupont , Geert Jan de Groot , John Gardiner Myers From: "Matt Crawford" Subject: Re: (IPng 1170) Re: clash between PS rfc1884 and PS rfc1783 In-reply-to: Your message of Wed, 17 Jan 96 14:40:05 +0100. Date: Wed, 17 Jan 96 09:46:16 -0600 I like kre's idea of writing 32 unadorned hex digits, but it only works for email where there is some surrounding marker. Dropped into the URL format (or typed (ugh!) at a command line, you can't tell a 32 digits IPv6 address from a 32 character short-form hostname. I like even more Francis' idea of writing literal IPv6 address as names in ip6.int. However, the times you'd want literal addresses are exactly the times you suspect DNS may not be fully operational. (As is the case now: ns.isi.edu. can't find ip6.int.: Server failed.) So the magic would have to be wired into gethostbyname() or in the resolver. (Concoct a AAAA record on the spot in answer to a AAAA query on a name in ip6.int.) Does the gain justify the ugliness? Steve's suggestion of using the URL quoting mechanism (so that 1080::8:800:200C:417A becomes 1080%3A%3A8%3A800%3A200C%3A417A) works for URLs, but it starts us down a piecemeal-solution path. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------- End of Forwarded Messages From Francis.Dupont@inria.fr Tue Oct 14 20:08:33 1997 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Tue, 14 Oct 1997 21:08:33 +0200 Subject: query re IPv6 URL format In-Reply-To: Your message of Tue, 14 Oct 1997 11:47:01 PDT. <3.0.3.32.19971014114701.008d0a60@mailhost.ipsilon.com> Message-ID: <199710141908.VAA04143@givry.inria.fr> In your previous mail you wrote: Brian, >If that was the decision then we need to codify it and tell >the world. I could live with it, if the URL parsers can handle >it. I'll check that with the URL guys. > Maybe I am missing something, but... The IPv4 syntax is: http://111.222.333.444/~bc It would seem to me that while http://aaaa:bbbb::cccc:dddd/~bc has multiple ":"'s in it, given left to right parsing, I don't see anything ambiguous. The first thing after the "//" is either a DNS name, IPv4 address, or an IPv6 address. If the current parsers can distinguish between "hursley.ibm.com" and "111.222.333.444", both of which use dots as separators, then could they also deal with IPv6 addresses with colons? => it is not true (just look at the RFC 1738 or for instance lynx documentation). According to the last one, URLs can be: http://host:port/path?searchpart#fragment ^ telnet://user:password@host:port ^ ^ ftp://username:password@host:port/path;type=[D,I, or A] ^ ^ ... And dont' forget we need the same thing for RFC 821/822, X11, ... Why can't the parsers learn how to do this? They need to be changed to handle IPv6 addresses anyway. => it is very easy and as far as I know enough to support DNS names (and the terrible RES_USE_INET6 stuff). Personally I think the right thing to do is to kill literals (IPv4 literals too)! Regards Francis.Dupont@inria.fr PS: the URL format http://host:port/... is very common and perhaps will become more common if ISPs put a bad priority to the 80 TCP port (:-). From bound@zk3.dec.com Tue Oct 14 21:50:52 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Tue, 14 Oct 1997 16:50:52 -0400 Subject: query re IPv6 URL format In-Reply-To: Your message of "Tue, 14 Oct 1997 11:08:28 PDT." Message-ID: <9710142050.AA15633@wasted.zk3.dec.com> >What's the limit on the length of a DNS label (not the whole DNS name, >but the thing that goes between the dots in a DNS name)? Is it less than >32, by any chance? labels can be 63 octets But the entire name can only be 255 octets. /jim From lf@elemental.net Tue Oct 14 22:32:56 1997 From: lf@elemental.net (Lars Fenneberg) Date: Tue, 14 Oct 1997 23:32:56 +0200 Subject: reconnecting IPv6 site. In-Reply-To: ; from Jan Marius Evang on Fri, Oct 10, 1997 at 09:17:57AM +0200 References: Message-ID: <19971014233256.37745@gimli.elemental.net> Hi! Quoting Jan Marius Evang (jane@iaeste.no): > >> Bob Fink writes: > > BF> Yes it has, and you need new implementations to use it - ones > BF> that support AGGR and EUI-64. The 6bone web pages for hookups > BF> has some info on this. Take a look: > > OK. I suppose the newest Linux kernels and Cisco IOS (IPv6) has this? You'll need one of the recent CVS snapshots of David Miller. Alexey has added EUI-64 support to them. See ftp.kernel.org:/pub/linux/kernel/davem. > Or is it just the tools? If you run radvd on Linux you'll need a new version. I'm currently working on a new release which will allow 64bit prefixes but it's not public yet. If you need it please contact me via private email. 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 sp0005@aixrs1.hrz.uni-essen.de Wed Oct 15 00:38:03 1997 From: sp0005@aixrs1.hrz.uni-essen.de (Kai Schulte) Date: Wed, 15 Oct 1997 01:38:03 +0200 (MESZ) Subject: query re IPv6 URL format In-Reply-To: Message-ID: On Tue, 14 Oct 1997, Steve Deering wrote: > What's the limit on the length of a DNS label (not the whole DNS name, > but the thing that goes between the dots in a DNS name)? Is it less than > 32, by any chance? Why not use dots instead of colons and some prefix (e.g. another dot) or square brackets (like in the old ka9q nos days) to distinguish them from dns names? Kai From RLFink@lbl.gov Wed Oct 15 01:26:08 1997 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 14 Oct 1997 17:26:08 -0700 Subject: new DNS config info Message-ID: For those interested in how to setup an IPv6-capable DNS please look at the excellent new writeup on the hookups page: http://www.6bone.net/6bone_hookup.html Thanks to Bertrand Buclin of AT&T Labs Europe for the new writeup, as well as David Lee of Virginia Tech for the existing one. Both are given...take your choice. As always, comments to the mailer on these, or any, hookup information. Thanks, Bob From jang@sps.nl Wed Oct 15 08:36:41 1997 From: jang@sps.nl (Gils van, Jan) Date: Wed, 15 Oct 1997 08:36:41 +0100 Subject: IPv6 for NetBSD Message-ID: Hi, Thanks for reading, can someone tell me if there is a IPv6 source for NetBSD and what are is the experince so far. I am working with NetBSD 1.2.1 kernel on a i386 platform. Thanks in advance Jan H. van Gils e-Mail janvg@knoware.nl / pe1mhp@amsat.org From brian@hursley.ibm.com Wed Oct 15 11:32:09 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Wed, 15 Oct 1997 11:32:09 +0100 Subject: query re IPv6 URL format In-Reply-To: <3.0.3.32.19971014114701.008d0a60@mailhost.ipsilon.com> from "Bob Hinden" at Oct 14, 97 11:47:01 am Message-ID: <9710151032.AA19944@hursley.ibm.com> The colons break both most existing URL parsers and the BNF describing URLs. Eliminating the :: does not fix it. Believe me. I spent an hour on the BNF. Brian >- Bob Hinden said: > > Brian, > > >If that was the decision then we need to codify it and tell > >the world. I could live with it, if the URL parsers can handle > >it. I'll check that with the URL guys. > > > > Maybe I am missing something, but... > > The IPv4 syntax is: > > http://111.222.333.444/~bc > > It would seem to me that while > > http://aaaa:bbbb::cccc:dddd/~bc > > has multiple ":"'s in it, given left to right parsing, I don't see anything > ambiguous. The first thing after the "//" is either a DNS name, IPv4 > address, or an IPv6 address. If the current parsers can distinguish > between "hursley.ibm.com" and "111.222.333.444", both of which use dots as > separators, then could they also deal with IPv6 addresses with colons? > > Why can't the parsers learn how to do this? They need to be changed to > handle IPv6 addresses anyway. > > Bob > > From brian@hursley.ibm.com Wed Oct 15 11:37:34 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Wed, 15 Oct 1997 11:37:34 +0100 Subject: query re IPv6 URL format In-Reply-To: <199710141853.NAA21340@gungnir.fnal.gov> from "Matt Crawford" at Oct 14, 97 01:53:26 pm Message-ID: <9710151037.AA90992@hursley.ibm.com> Sadly I believe that only > 1. Change the textual representation of IPv6 addresses. will work. The colons kill us. Brian >- Matt Crawford said: > > Brian, > > I brought this up quite some time ago and there was a little > discussion, in which you participated, but no "decision" as such that > I recall. Here's my original message and a summary ... > > ------- Forwarded Messages > > To: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com > From: "Matt Crawford" > Subject: clash between PS rfc1884 and PS rfc1783 > Date: Tue, 16 Jan 96 14:19:31 -0600 > > The text representation of IPv6 addresses specified in item 2 of > section 2.2 of RFC1884: > > For example the following addresses: > > 1080:0:0:0:8:800:200C:417A a unicast address > [...] > may be represented as: > > 1080::8:800:200C:417A a unicast address > > results in a possible ambiguity if such an IPv6 address appears in a > URL constructed according to RFC1738 (section 3.1): > > While the syntax for the rest of the URL may vary depending on the > particular scheme selected, URL schemes that involve the direct use > of an IP-based protocol to a specified host on the Internet use a > common syntax for the scheme-specific data: > > //:@:/ > > (While RFC1738 only mentions IPv4 addresses appearing as , it > will be widely presumed that IPv6 addresses may also be used.) > > If the last 16-bit component of an IPv6 address used as in a > URL contains only digits 0 through 9, it may look as if a port number > is present. Conversely, if a port number is present and has no more > than four digits, it will resemble a part of the IPv6 address. > > > > Solutions: > > 1. Change the textual representation of IPv6 addresses. > > 2. Forbid the "::" abbreviation of IPv6 addresses in URLs and other > contexts in which a port number might be appended with a colon. > (Then counting the fields will reveal whether a port number is > present.) > > 3. Forbid the use of literal IPv6 addresses in URLs. > > 4. Change the syntax of URLs. > > > All of these have drawbacks. I suggest that #1 is better than #2, > and #3 and #4 are out of the question. > _________________________________________________________ > Matt Crawford crawdad@fnal.gov Fermilab > PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A > > ------- Message 2 > > To: iesg@CNRI.Reston.VA.US, ipng@sunroof.Eng.Sun.COM > Cc: Robert Elz , > huitema@pax.inria.fr (Christian Huitema), > Brian Carpenter CERN-CN , > Francis Dupont , > Geert Jan de Groot , > John Gardiner Myers > From: "Matt Crawford" > Subject: Re: (IPng 1170) Re: clash between PS rfc1884 and PS rfc1783 > In-reply-to: Your message of Wed, 17 Jan 96 14:40:05 +0100. > > Date: Wed, 17 Jan 96 09:46:16 -0600 > > I like kre's idea of writing 32 unadorned hex digits, but it only > works for email where there is some surrounding marker. Dropped into > the URL format (or typed (ugh!) at a command line, you can't tell a > 32 digits IPv6 address from a 32 character short-form hostname. > > I like even more Francis' idea of writing literal IPv6 address as > names in ip6.int. However, the times you'd want literal addresses > are exactly the times you suspect DNS may not be fully operational. > (As is the case now: ns.isi.edu. can't find ip6.int.: Server failed.) > So the magic would have to be wired into gethostbyname() or in the > resolver. (Concoct a AAAA record on the spot in answer to a AAAA > query on a name in ip6.int.) > > Does the gain justify the ugliness? > > Steve's suggestion of using the URL quoting mechanism (so that > 1080::8:800:200C:417A becomes 1080%3A%3A8%3A800%3A200C%3A417A) > works for URLs, but it starts us down a piecemeal-solution path. > _________________________________________________________ > Matt Crawford crawdad@fnal.gov Fermilab > PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A > > ------- End of Forwarded Messages > From brian@hursley.ibm.com Wed Oct 15 11:39:27 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Wed, 15 Oct 1997 11:39:27 +0100 Subject: query re IPv6 URL format In-Reply-To: <199710141908.VAA04143@givry.inria.fr> from "Francis Dupont" at Oct 14, 97 09:08:33 pm Message-ID: <9710151039.AA99181@hursley.ibm.com> I've had that discussion with the URL syntax authors. They are unanimous that the colons are not parseable in practice. Brian >- Francis Dupont said: > > In your previous mail you wrote: > > Brian, > > >If that was the decision then we need to codify it and tell > >the world. I could live with it, if the URL parsers can handle > >it. I'll check that with the URL guys. > > > > Maybe I am missing something, but... > > The IPv4 syntax is: > > http://111.222.333.444/~bc > > It would seem to me that while > > http://aaaa:bbbb::cccc:dddd/~bc > > has multiple ":"'s in it, given left to right parsing, I don't see anything > ambiguous. The first thing after the "//" is either a DNS name, IPv4 > address, or an IPv6 address. If the current parsers can distinguish > between "hursley.ibm.com" and "111.222.333.444", both of which use dots as > separators, then could they also deal with IPv6 addresses with colons? > > => it is not true (just look at the RFC 1738 or for instance lynx > documentation). According to the last one, URLs can be: > > http://host:port/path?searchpart#fragment > ^ > telnet://user:password@host:port > ^ ^ > > ftp://username:password@host:port/path;type=[D,I, or A] > ^ ^ > ... > And dont' forget we need the same thing for RFC 821/822, X11, ... > > Why can't the parsers learn how to do this? They need to be changed to > handle IPv6 addresses anyway. > > => it is very easy and as far as I know enough to support DNS names > (and the terrible RES_USE_INET6 stuff). Personally I think the right > thing to do is to kill literals (IPv4 literals too)! > > Regards > > Francis.Dupont@inria.fr > > PS: the URL format http://host:port/... is very common and perhaps > will become more common if ISPs put a bad priority to the 80 TCP port (:-). > From brian@hursley.ibm.com Wed Oct 15 11:36:07 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Wed, 15 Oct 1997 11:36:07 +0100 Subject: query re IPv6 URL format In-Reply-To: from "Steve Deering" at Oct 14, 97 11:08:28 am Message-ID: <9710151036.AA82643@hursley.ibm.com> >- Steve Deering said: > > What's the limit on the length of a DNS label (not the whole DNS name, > but the thing that goes between the dots in a DNS name)? Is it less than > 32, by any chance? 32 is not a problem, but a hex number looks like a name and gets sent off for DNS resolving. For example when I ask Netscape for http://abcdef1234567890abcdef1234567890 it attaches my default domain and says: Fatal Error 500 Can't Access Document: http://abcdef1234567890abcdef1234567890.hursley.ibm.com/. Reason: Can't locate remote host: abcdef1234567890abcdef1234567890.hursley.ibm.com. Brian From bmanning@ISI.EDU Wed Oct 15 15:27:38 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Wed, 15 Oct 1997 07:27:38 -0700 (PDT) Subject: mailing list check Message-ID: <199710151427.AA14069@zed.isi.edu> -- "When in doubt, Twirl..." -anon From deering@cisco.com Wed Oct 15 16:27:49 1997 From: deering@cisco.com (Steve Deering) Date: Wed, 15 Oct 1997 08:27:49 -0700 Subject: query re IPv6 URL format In-Reply-To: <9710151035.AA13218@hursley.ibm.com> References: from "Steve Deering" at Oct 14, 97 11:08:28 am Message-ID: At 3:35 AM -0700 10/15/97, (Brian E Carpenter) wrote: > >- Steve Deering said: > > What's the limit on the length of a DNS label (not the whole DNS name, > > but the thing that goes between the dots in a DNS name)? Is it less than > > 32, by any chance? > > 32 is not a problem, but a hex number looks like a name and gets > sent off for DNS resolving... I wasn't thinking of it as a problem, but rather as a possible solution. If DNS labels happened to have a length restriction of less than 32, then an IPv6 address represented as 32 hex digits would be distinguishable from a DNS label by the fact that it was longer than a legal DNS label. Unfortunately, the length limit on DNS labels turns out to be greater than 32. Steve From deering@cisco.com Wed Oct 15 16:51:53 1997 From: deering@cisco.com (Steve Deering) Date: Wed, 15 Oct 1997 08:51:53 -0700 Subject: query re IPv6 URL format In-Reply-To: <9710151037.AA90992@hursley.ibm.com> References: <199710141853.NAA21340@gungnir.fnal.gov> from "Matt Crawford" at Oct 14, 97 01:53:26 pm Message-ID: At 3:37 AM -0700 10/15/97, (Brian E Carpenter) wrote: > Sadly I believe that only > > > 1. Change the textual representation of IPv6 addresses. > > will work. The colons kill us. Changing to some other punctuation character would probably just kill us somewhere else. I think it's highly unlikely that we can come up with a representation that will be transparently compatible with all existing "grammars" that may encounter IP addresses (e.g., command-line parsers, configuration file languages, email parsers, ...). For the URL case in particular, is there not a character or pair of characters that could be defined as delimiting an IPv6 (or IPv4/6) address literal, e.g., [aaaa:bbbb::cc:d] or ^aaaa:bbbb::cc:d^ or something similar? An address plus port number would then look like [aaaa:bbbb::cc:d]:8080. Steve From jambi@oceana.nlanr.net Wed Oct 15 17:07:23 1997 From: jambi@oceana.nlanr.net (Iddo Jambi Ganbar) Date: Wed, 15 Oct 1997 09:07:23 -0700 (PDT) Subject: Request for tunnel In-Reply-To: <19971014224446.14354@nlanr.net> Message-ID: hi we're interested in connecting the vBNS (from SDSC to start with) to the 6bone. We're using FreeBSD2.2 with the CAIRN IPv6 code, a sparc (solaris2.5.1) and possibly a Linux box. I can't tell from the list who might be best located, do the ESnet connections come down to San Diego? If anyone knows a more topologicaly sensible place for us to tunnel to, please holler -- Thanx jambi and kc From hinden@Ipsilon.COM Wed Oct 15 18:46:44 1997 From: hinden@Ipsilon.COM (Bob Hinden) Date: Wed, 15 Oct 1997 10:46:44 -0700 Subject: query re IPv6 URL format In-Reply-To: References: <9710151035.AA13218@hursley.ibm.com> Message-ID: <3.0.3.32.19971015104644.0087ed80@mailhost.ipsilon.com> Brian, Let me see if I can continue to show how little I know about URL's..... Would some sort of escape or quoting work? Something like: http://[aaaa:bbbb:cccc::zzzz]/~bc http://[aaaa:bbbb:cccc::zzzz]:80/~bc http://[aaaabbbbccccddddeeeeffffgggghhhh]:80/~bc or http://"aaaa:bbbb:cccc::zzzz"/~bc http://"aaaa:bbbb:cccc::zzzz":80/~bc http://"aaaabbbbccccddddeeeeffffgggghhhh":80/~bc or (very ugly) http://aaaa&:bbbb&:cccc&:&:zzzz/~bc http://aaaa&:bbbb&:cccc&:&:zzzz:80/~bc or (very ugly) http://&aaaabbbbccccddddeeeeffffgggghhhh:80/~bc etc. Bob From Francis.Dupont@inria.fr Wed Oct 15 19:08:07 1997 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Wed, 15 Oct 1997 20:08:07 +0200 Subject: query re IPv6 URL format In-Reply-To: Your message of Wed, 15 Oct 1997 10:16:39 BST. Message-ID: <199710151808.UAA05883@givry.inria.fr> In your previous mail you wrote: > Personally I think the right thing to do is to kill literals > (IPv4 literals too)! Although user-friendliness calls for killing literals, as you suggest Francis, I believe it would be a serious mistake to do it: ... (some good arguments) Literals are an essential feature that we must preserve, else it will become impossible to operate the networks. => I have changed my mind. I'd still like to kill literals but without killing the functionality. The best proposal I saw is to use names in the ip6.int domain. They have strictly the same information than literals, but they are full standard DNS names and very easy to recognize, parse and use (ie reverse). I know only one drawback: one has to use a tool in order to get it (here I use "nslookup -debug -type=ptr" and cut & paste). For instance the address: 3ffe:306:1051:8300:220:feff:fe00:8781 becomes the name: 1.8.7.8.0.0.e.f.f.f.e.f.0.2.2.0.0.0.3.8.1.5.0.1.6.0.3.0.e.f.f.3.ip6.int Another advantage is this solution is general and can be used for all the cases (URL, X11, RFC 822, ...). Regards Francis.Dupont@inria.fr From masaki@merit.edu Wed Oct 15 20:15:47 1997 From: masaki@merit.edu (Masaki Hirabaru) Date: Wed, 15 Oct 1997 15:15:47 -0400 Subject: (IPng 4677) Re: query re IPv6 URL format In-Reply-To: Your message of "Wed, 15 Oct 1997 20:08:07 +0200." <199710151808.UAA05883@givry.inria.fr> Message-ID: <199710151915.PAA12054@merit.edu> > 3ffe:306:1051:8300:220:feff:fe00:8781 3ffe%3a306%3a1051%3a8300%3a220%3afeff%3afe00%3a8781 I think that this should work in url. -- Masaki From RLFink@lbl.gov Wed Oct 15 21:50:32 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 15 Oct 1997 13:50:32 -0700 Subject: Request for tunnel In-Reply-To: References: <19971014224446.14354@nlanr.net> Message-ID: At 9:07 AM -0700 10/15/97, Iddo Jambi Ganbar wrote: > > hi > > we're interested in connecting the vBNS (from SDSC to start with) > to the 6bone. We're using FreeBSD2.2 with the CAIRN IPv6 code, > a sparc (solaris2.5.1) and possibly a Linux box. > I can't tell from the list who might be best located, > do the ESnet connections come down to San Diego? > If anyone knows a more topologicaly sensible place for > us to tunnel to, please holler -- ESnet's 6bone router is in Berkeley. Barring that, it's not a bad place to connect for your purposes. ISI-LAP, 3COM, Cisco and Digital-CA are quite reasonable west coast points as well. Is the vBNS connecting, or NLANR? If vBNS would like to join, I can issue a pTLA. Else it might be best just to take a delegation from an existing pTLA (e.g., from the list I gave above). Thanks, Bob From qv@3com.com Wed Oct 15 22:07:34 1997 From: qv@3com.com (Quaizar Vohra) Date: Wed, 15 Oct 1997 14:07:34 -0700 (PDT) Subject: query re IPv6 URL format In-Reply-To: <9710151039.AA99181@hursley.ibm.com> References: <199710141908.VAA04143@givry.inria.fr> <9710151039.AA99181@hursley.ibm.com> Message-ID: <199710152107.OAA06010@lookout.nsd.3com.com> How about defining a DNS domain ipv6addr and allowing an IPv6 address x1:x2:x3:x4:x5:x6:x7:x8 to be typed as a dns name x1.x2.x3.x4.x5.x6.x7.x8.ipv6addr. Disclaimer : I am very ignorant about DNS. Quaizar From kaos@ocs.com.au Wed Oct 15 23:30:56 1997 From: kaos@ocs.com.au (Keith Owens) Date: Thu, 16 Oct 1997 08:30:56 +1000 Subject: query re IPv6 URL format In-Reply-To: Your message of "Wed, 15 Oct 1997 20:08:07 +0200." <199710151808.UAA05883@givry.inria.fr> Message-ID: <19971015223058.26405.qmail@mail.ocs.com.au> On Wed, 15 Oct 1997 20:08:07 +0200, Francis Dupont wrote: >I know only one drawback: one has to use a tool >in order to get it (here I use "nslookup -debug -type=ptr" and cut & paste). Try this, I got fed up with typing as well :) #!/usr/bin/perl -w # # ip6_int # # Convert valid IPv6 address to ip6.int PTR value. Convert valid # IPv4 address to in-addr.arpa PTR value. Anything not valid is # simply printed as is. Handles :: notation and embedded IPv4 # addresses. If the address is followed by /n, the PTR is # truncated to n bits. # # Examples: # nslookup -type=any `ip6_int 3ffe::203.34.97.6` looks up # 6.0.1.6.2.2.b.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.e.f.f.3.ip6.int # nslookup -type=any `ip6_int fe80::b432:e6ff/10` looks up # 2.e.f.ip6.int # nslookup -type=any `ip6_int ::127.0.0.1` looks up # 1.0.0.0.0.0.f.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int # nslookup -type=any `ip6_int 127.0.0.1` looks up # 1.0.0.127.in-addr.arpa # nslookup -type=any `ip6_int 127.0.0.1/8` looks up # 127.in-addr.arpa # # Copyright 1997 Keith Owens . GPL. # require 5; use strict; use integer; my $v6; if ($#ARGV >= 0 && ($v6 = ($ARGV[0] =~ m;^([0-9a-fA-f:]+)(?::(\d+\.\d+\.\d+\.\d+))?(?:/(\d+))?$;)) || $ARGV[0] =~ m;^(\d+\.\d+\.\d+\.\d+)(?:/(\d+))?$;) { my $valid = 1; if ($v6) { my (@chunk) = split(/:/, $1, 99); my $mask = $3; if ($2) { my (@v4) = split(/\./, $2); $valid = ($v4[0] <= 255 && $v4[1] <= 255 && $v4[2] <= 255 && $v4[3] <= 255); if ($valid) { push(@chunk, sprintf("%x%02x", $v4[0], $v4[1])); push(@chunk, sprintf("%x%02x", $v4[2], $v4[3])); } } my $pattern = ""; if ($valid) { foreach (@chunk) { $pattern .= /^$/ ? 'b' : 'c'; } if ($pattern =~ /^bbc+$/) { @chunk = (0, 0, @chunk[2..$#chunk]); @chunk = (0, @chunk) while ($#chunk < 7); } elsif ($pattern =~ /^c+bb$/) { @chunk = (@chunk[0..$#chunk-2], 0, 0); push(@chunk, 0) while ($#chunk < 7); } elsif ($pattern =~ /^c+bc+$/) { my @left; push(@left, shift(@chunk)) while ($chunk[0] ne ""); shift(@chunk); push(@left, 0); push(@left, 0) while (($#left + $#chunk) < 6); @chunk = (@left, @chunk); } $valid = $#chunk == 7; } my $ip6int = "ip6.int"; my $i; if ($valid) { foreach (@chunk) { $i = hex($_); if ($i > 65535) { $valid = 0; } else { $ip6int = sprintf("%x.%x.%x.%x.", ($i) & 0xf, ($i >> 4) & 0xf, ($i >> 8) & 0xf, ($i >> 12) & 0xf) . $ip6int; } } } if ($valid && defined($mask)) { $valid = ($mask =~ /^\d+$/ && $mask <= 128); if ($valid) { $ip6int = substr($ip6int, int((128-$mask)/4)*2); if ($mask &= 3) { $i = hex(substr($ip6int, 0, 1)); $i >>= (4-$mask); substr($ip6int, 0, 1) = sprintf("%x", $i); } } } $ARGV[0] = $ip6int if ($valid); } else { # v4 my (@v4) = split(/\./, $1); my $mask = $2; $valid = ($v4[0] <= 255 && $v4[1] <= 255 && $v4[2] <= 255 && $v4[3] <= 255); my $v4 = hex(sprintf("%02X%02X%02X%02X", @v4)); if ($valid && defined($mask)) { $valid = ($mask =~ /^\d+$/ && $mask <= 32); if ($valid) { $v4 = $v4 & ((~0) << (32-$mask)); $v4[0] = ($v4 >> 24) & 255; $v4[1] = ($v4 >> 16) & 255; $v4[2] = ($v4 >> 8) & 255; $v4[3] = $v4 & 255; } } else { $mask = 32; } if ($valid) { my $i = 4 - int(($mask+7) / 8); pop(@v4) while ($i--); $ARGV[0] = join('.', reverse(@v4)); $ARGV[0] .= '.' if ($ARGV[0] ne ""); $ARGV[0] .= 'in-addr.arpa'; } } } print "@ARGV\n"; From bmanning@ISI.EDU Thu Oct 16 00:29:41 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Wed, 15 Oct 1997 16:29:41 -0700 (PDT) Subject: query re IPv6 URL format In-Reply-To: <199710151808.UAA05883@givry.inria.fr> from "Francis Dupont" at Oct 15, 97 08:08:07 pm Message-ID: <199710152329.AA24317@zed.isi.edu> From another list (dns related no less!) with the names "scrubbed" to protect the innocent. >> I've now updated the patches for allowing named to chroot to also support >> setting the user and group id's with another option: 'runas "user[.group]";'. >> Also, they didn't apply cleanly against 8.1.1. The patches below cover >> both chroot and runas. > >Minor nit: '.' is a valid character for a user name. Perhaps ':' would be >a better delimiter? (It is not a valid user name character...) -- --bill From brian@hursley.ibm.com Thu Oct 16 09:46:04 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 16 Oct 1997 09:46:04 +0100 Subject: query re IPv6 URL format In-Reply-To: <3.0.3.32.19971015104644.0087ed80@mailhost.ipsilon.com> from "Bob Hinden" at Oct 15, 97 10:46:44 am Message-ID: <9710160846.AA03334@hursley.ibm.com> Belive me I tried this on the URL folks, even wrote the BNF for them, and they insist that the real-world parsers can't handle it and will barf on the first colon they see. They are wedged on the way their parsers work and we are wedged on the notation we picked. Somebody's code is going to have to change. As for 1.8.7.8.0.0.e.f.f.f.e.f.0.2.2.0.0.0.3.8.1.5.0.1.6.0.3.0.e.f.f.3.ip6.int that really doesn't meet the criterion of being cut and pastable from the canonical notation. Brian Carpenter >- Bob Hinden said: > > Brian, > > Let me see if I can continue to show how little I know about URL's..... > > Would some sort of escape or quoting work? Something like: > > http://[aaaa:bbbb:cccc::zzzz]/~bc > http://[aaaa:bbbb:cccc::zzzz]:80/~bc > http://[aaaabbbbccccddddeeeeffffgggghhhh]:80/~bc > > or > > http://"aaaa:bbbb:cccc::zzzz"/~bc > http://"aaaa:bbbb:cccc::zzzz":80/~bc > http://"aaaabbbbccccddddeeeeffffgggghhhh":80/~bc > > or (very ugly) > > http://aaaa&:bbbb&:cccc&:&:zzzz/~bc > http://aaaa&:bbbb&:cccc&:&:zzzz:80/~bc > > or (very ugly) > > http://&aaaabbbbccccddddeeeeffffgggghhhh:80/~bc > > etc. > > Bob > > > > > From brian@hursley.ibm.com Thu Oct 16 09:35:12 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 16 Oct 1997 09:35:12 +0100 Subject: (IPng 4677) Re: query re IPv6 URL format In-Reply-To: <199710151915.PAA12054@merit.edu> from "Masaki Hirabaru" at Oct 15, 97 03:15:47 pm Message-ID: <9710160835.AA127426@hursley.ibm.com> It doesn't in at least one well known browser - the "escaped" colons get turned into colons before being passed to the resolver. I tried it some time ago. Brian >- Masaki Hirabaru said: > > > 3ffe:306:1051:8300:220:feff:fe00:8781 > 3ffe%3a306%3a1051%3a8300%3a220%3afeff%3afe00%3a8781 > > I think that this should work in url. -- Masaki > From brian@hursley.ibm.com Thu Oct 16 09:48:45 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 16 Oct 1997 09:48:45 +0100 Subject: query re IPv6 URL format In-Reply-To: <199710152107.OAA06010@lookout.nsd.3com.com> from "Quaizar Vohra" at Oct 15, 97 02:07:34 pm Message-ID: <9710160848.AA43203@hursley.ibm.com> That may turn out to be the best way - Larry Masinter also suggested this. In fact ipv6addr doesn't need to be a real domain name - it's just a token for the URL parser. Brian >- Quaizar Vohra said: > > > How about defining a DNS domain ipv6addr and > allowing an IPv6 address x1:x2:x3:x4:x5:x6:x7:x8 to be typed as > a dns name x1.x2.x3.x4.x5.x6.x7.x8.ipv6addr. > > Disclaimer : I am very ignorant about DNS. > > Quaizar > From rcn@mci.net Thu Oct 16 11:50:50 1997 From: rcn@mci.net (Randolph C. Nicklas) Date: Thu, 16 Oct 1997 06:50:50 -0400 Subject: Request for tunnel Message-ID: <3.0.32.19971016065049.006e52d0@mci.net> Bob & Iddo, Please our (vBNS Engineerings) comments below. Thanks, Randy At 01:50 PM 10/15/97 -0700, Bob Fink wrote: >At 9:07 AM -0700 10/15/97, Iddo Jambi Ganbar wrote: >> >> hi >> >> we're interested in connecting the vBNS (from SDSC to start with) >> to the 6bone. We're using FreeBSD2.2 with the CAIRN IPv6 code, >> a sparc (solaris2.5.1) and possibly a Linux box. >> I can't tell from the list who might be best located, >> do the ESnet connections come down to San Diego? The vBNS is ATM-connected to ESnet at SDSC via General Atomics, over which we BGP4--peer. >> If anyone knows a more topologicaly sensible place for >> us to tunnel to, please holler -- Iddo--have you given any thought to using one of the supported ATM adaptors in your NLANR P6 host? Why?--see below. > >ESnet's 6bone router is in Berkeley. Barring that, it's not a bad place to >connect for your purposes. ISI-LAP, 3COM, Cisco and Digital-CA are quite >reasonable west coast points as well. > >Is the vBNS connecting, or NLANR? NLANR could use the vBNS to reach other 6bone routers--for example,the vBNS peers with ESnet at SDSC, as well as other locales. I would like to think of the NLANR/SDSC routers as the first vBNS IPv6 routers, and note that all five vBNS Supercomputer Centers (SCCs--SDSC, NCAR, NCSA, PSC & CTC) have IPv6 router h/w (FDDI-attached P6s). Iddo--it is important that we coordinate our efforts on deploying IPv6 in the vBNS. > >If vBNS would like to join, I can issue a pTLA. Yes, we would, and a pTLA for the vBNS would be welcome, as would advice on an IPv6 addressing plan for the vBNS. At ISI's recent IPv6 conference in Arlington, Greg Miller & I put forward our plans to deploy three native IPv6 routers (Bay Area, Chicago, and DC area) on the vBNS, connected together with dedicated ATM PVCs, and accepting 6bone traffic via ATM PVCs (from vBNS SCC and University sites as well as through the ATM NAPS) and tunnels (again, from vBNS sites and any of the NAPs). It will be 1Q98 before the routers are installed in the relevant MCI terminals. We are considering both TRAIL routers as well as Ciscos, but we want the WAN links to be IPv6 over ATM. > >Else it might be best just to take a delegation from an existing pTLA >(e.g., from the list I gave above). > > >Thanks, > >Bob > > > > ------------------------------------------ Randolph C. Nicklas vBNS Engineering/MCI 703.715.7099 1.800.SKY.PAGE 902418 From Francis.Dupont@inria.fr Thu Oct 16 13:04:19 1997 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Thu, 16 Oct 1997 14:04:19 +0200 Subject: query re IPv6 URL format In-Reply-To: Your message of Thu, 16 Oct 1997 09:46:04 BST. <9710160846.AA03334@hursley.ibm.com> Message-ID: <199710161204.OAA09399@givry.inria.fr> In your previous mail you wrote: Belive me I tried this on the URL folks, even wrote the BNF for them, and they insist that the real-world parsers can't handle it and will barf on the first colon they see. They are wedged on the way their parsers work and we are wedged on the notation we picked. Somebody's code is going to have to change. As for 1.8.7.8.0.0.e.f.f.f.e.f.0.2.2.0.0.0.3.8.1.5.0.1.6.0.3.0.e.f.f.3.ip6.int that really doesn't meet the criterion of being cut and pastable from the canonical notation. => I believe we are converging... I seems the solution is to get the IPv6 address, apply a transform which must replace colons by dots and append a trailer name which is not ambiguous. The "ip6.int" proposal enters in this category, the problem is cut & paste doesn't work but no suitable transform meets this criterion (because of colons). Then we need: - a transform from any to (literal) IPv6 address to a dot notation with the same information (ie we have to keep the hexa digits). - a not ambiguous trailing domain name Unessential criteria for the transform should be: - as little as possible result (keep URLs readable) - one to one transform (note: for this we need a good canonical format for IPv6 addresses, for instance full hexa without heading zeros) - easy to program Regards Francis.Dupont@inria.fr PS: use the "ip6.int" because we can get the real name with a search for a PTR RR is not a good idea (if one wants to use a literal is likely because the name is not available). From smurf@noris.de Thu Oct 16 13:04:38 1997 From: smurf@noris.de (Matthias Urlichs) Date: Thu, 16 Oct 1997 14:04:38 +0200 (Funky) Subject: query re IPv6 URL format In-Reply-To: from "Steve Deering" at Oct 15, 97 08:51:53 am Message-ID: <19971016120438.18346.qmail@nova.noris.de> Hi, Steve: >For the URL case in particular, is there not a character or pair of >characters that could be defined as delimiting an IPv6 (or IPv4/6) address >literal, e.g., [aaaa:bbbb::cc:d] or ^aaaa:bbbb::cc:d^ or something similar? >An address plus port number would then look like [aaaa:bbbb::cc:d]:8080. I _like_ the bracket idea. Let's apply it to IPV4, too, and deprecate the old syntax. 1/2 :-) -- Matthias Urlichs noris network GmbH From deering@cisco.com Thu Oct 16 16:04:12 1997 From: deering@cisco.com (Steve Deering) Date: Thu, 16 Oct 1997 08:04:12 -0700 Subject: query re IPv6 URL format In-Reply-To: <199710161204.OAA09399@givry.inria.fr> References: Your message of Thu, 16 Oct 1997 09:46:04 BST. <9710160846.AA03334@hursley.ibm.com> Message-ID: At 5:04 AM -0700 10/16/97, Francis Dupont wrote: > => I believe we are converging... I seems the solution is to get > the IPv6 address, apply a transform which must replace colons by dots > and append a trailer name which is not ambiguous. > The "ip6.int" proposal enters in this category, the problem is cut & paste > doesn't work but no suitable transform meets this criterion (because > of colons). There are degrees of "cut-and-paste friendly". In all cases, it seems that after pasting an IPv6 address into a URL, one will have to edit the resulting string. Adding "[" and "]" before and after the pasted address would be fairly painless. Replacing all the ":"s with "."s would be somewhat more annoying. Reversing the order of all the hex digits, putting dots between the digits, and adding ".ip6.int" to the end would be deadly. If we can't have perfect cut-and-paste, let's at least try to make it as little hassle as possible to use generic cut-and-paste. Steve From RLFink@lbl.gov Thu Oct 16 16:25:09 1997 From: RLFink@lbl.gov (Bob Fink) Date: Thu, 16 Oct 1997 08:25:09 -0700 Subject: Request for tunnel In-Reply-To: <3.0.32.19971016065049.006e52d0@mci.net> Message-ID: Randolph, At 3:50 AM -0700 10/16/97, Randolph C. Nicklas wrote: ... >>Is the vBNS connecting, or NLANR? > > NLANR could use the vBNS to reach other 6bone routers--for example,the > vBNS peers with ESnet at SDSC, as well as other locales. I would like > to think of the NLANR/SDSC routers as the first vBNS IPv6 routers, >and note > that all five vBNS Supercomputer Centers (SCCs--SDSC, NCAR, NCSA, PSC & > CTC) have IPv6 router h/w (FDDI-attached P6s). > > Iddo--it is important that we coordinate our efforts on deploying IPv6 > in the vBNS. I very much like the idea of having vBNS as a multi-site 6bone backbone site as it will provide better performance and connectivity AND help us gain experience with the new AGGR addressing. >>If vBNS would like to join, I can issue a pTLA. > > Yes, we would, and a pTLA for the vBNS would be welcome, as would >advice > on an IPv6 addressing plan for the vBNS. > > At ISI's recent IPv6 conference in Arlington, Greg Miller & I put >forward > our plans to deploy three native IPv6 routers (Bay Area, Chicago, >and DC > area) on the vBNS, connected together with dedicated ATM PVCs, and >accepting > 6bone traffic via ATM PVCs (from vBNS SCC and University sites as >well as > through the ATM NAPS) and tunnels (again, from vBNS sites and any >of the > NAPs). It will be 1Q98 before the routers are installed in the >relevant MCI > terminals. We are considering both TRAIL routers as well as Ciscos, >but we > want the WAN links to be IPv6 over ATM. I really like the prospect of vBNS moving native IPv6. Let's get going right away with the tunneled version so you can move your plans along. I will assign a pTLA for vBNS (let's call it vBNS) if you will register with the 6bone registry (a requirement for 6bone participation). You can read the documentation at: http://www.6bone.net/RIPE-registry.html and I have enclosed my 6bone registry entry registration email for convenience. Then you should create a MNTNR entry (MNT-VBNS) so I can delegate the inet6nun pTLA to you using it (also see example below). As for an addressing plan, let's try to get the mail list to comment. I'll also suggest something later on. But for now...get registered and I'll assign your pTLA. Welcome aboard! Bob =========== To: auto-dbm@ISI.EDU From: Bob Fink Subject: LONGACK - create ipv6-site entry for LBNL ipv6-site: LBNL origin: AS293 descr: LBNL - Lawrence Berkeley National Lab. descr: 1 Cyclotron Road descr: Berkeley, CA 94720 descr: location is that of LBNL's GPS receiver for ntp service location: 37 52 36.024 N 122 15 9.372 W 244.58m country: US prefix: 5F01:2500:8003::/48 application: ping lbnl-v6r1.lbl.gov tunnel: IPv6 in IPv4 lbnl-v6r1.lbl.gov -> esnet-v6r1.es.net ESNET STATIC contact: RLF1-6BONE remarks: version 3 - initial entry notify: RLFink@lbl.gov changed: RLFink@lbl.gov 19970725 source: 6BONE === To: auto-dbm@isi.edu From: Bob Fink Subject: longack - create mntnr entry for MREN mntner: MNT-MREN descr: maintainer of MREN 6bone registry objects admin-c: MC1-6BONE upd-to: mren-tech@anl.gov mnt-nfy: mren-tech@anl.gov auth: NONE mnt-by: MNT-MREN changed: RLFink@lbl.gov 19970916 source: 6BONE -end From jeff@ollie.clive.ia.us Thu Oct 16 17:51:13 1997 From: jeff@ollie.clive.ia.us (Jeffrey C. Ollie) Date: Thu, 16 Oct 1997 11:51:13 -0500 Subject: query re IPv6 URL format References: <19971016120438.18346.qmail@nova.noris.de> Message-ID: <34464601.A812A0B5@ollie.clive.ia.us> This is a cryptographically signed message in MIME format. --------------msCEBE3B7FC547EA65AC517C3E Content-Type: multipart/mixed; boundary="------------AB891C5AB936DA529A9974E3" This is a multi-part message in MIME format. --------------AB891C5AB936DA529A9974E3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matthias Urlichs wrote: > > >For the URL case in particular, is there not a character or pair of > >characters that could be defined as delimiting an IPv6 (or IPv4/6) address > >literal, e.g., [aaaa:bbbb::cc:d] or ^aaaa:bbbb::cc:d^ or something similar? > >An address plus port number would then look like [aaaa:bbbb::cc:d]:8080. > > I _like_ the bracket idea. Let's apply it to IPV4, too, and deprecate the > old syntax. 1/2 :-) This has some precedent in the form that is used by SMTP to send to a literal IP address. For example: To: jcollie@[161.210.218.100] From: whoever@nowhere.com Subject: test Will end up in my mailbox. Jeff --------------AB891C5AB936DA529A9974E3 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ollie, Jeffrey Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Jeffrey Ollie n: Ollie;Jeffrey email;internet: jeff@ollie.clive.ia.us tel;work: 515-965-7057 tel;fax: 515-965-7305 x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------AB891C5AB936DA529A9974E3-- --------------msCEBE3B7FC547EA65AC517C3E Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKqwYJKoZIhvcNAQcCoIIKnDCCCpgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CKMwggPtMIIDVqADAgECAhAeBhYhhWVpKqVfNDjc6L/iMA0GCSqGSIb3DQEBBAUAMGIxETAP BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVy aVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzEwMTYwMDAw MDBaFw05ODEwMTYyMzU5NTlaMIIBHjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVh bCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BT IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MTMwMQYDVQQLEypEaWdpdGFsIElEIENs YXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMTDUplZmZyZXkgT2xsaWUx JTAjBgkqhkiG9w0BCQEWFmplZmZAb2xsaWUuY2xpdmUuaWEudXMwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBAKs+gLAXdii4gsP6wDMyn+j/B++3Bp7uoQLXLDg9rxYvlM2I3ON7umcQ YUwaQ2IaH3RzHa9nergx6wPmwSJ1ENyNdPXBKJQXGfjk23k4rh9G00krxDMtxVz179L4ZpuE Rxpy31BZ+oBJ27pYmanXCB0kic+ugnk+vvRf66q/99T5AgMBAAGjgeUwgeIwCQYDVR0TBAIw ADCBrwYDVR0gBIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMBAGCmCGSAGG+EUBBgMEAhYA MA0GCSqGSIb3DQEBBAUAA4GBAK1nOUgFgZflh9pZMQuQ3VhAAKvPpl78ZzmYxhzCutht+pZ5 SKJi2Xec1zAwe4obMnKQGzm6of8OverSlzMMZ+QjJB2basgcwT1V6yBUBB81KndB8rSSLa8Y iIvVzOAdSXqzPulysGCOA47Jsf7wPunfp5DxnBWJ4dfg3/CLOx5UMIICeTCCAeKgAwIBAgIQ Uh81HfJwfgArvspZhwTVOTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwNjI3MDAwMDAwWhcNOTkwNjI3MjM1OTU5WjBi MREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsT K1ZlcmlTaWduIENsYXNzIDEgQ0EgLSBJbmRpdmlkdWFsIFN1YnNjcmliZXIwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBALYUps9N0AUN2Moj0G+qtCmSY44s+G+W1y6ddksRsTaNV8nD /RzGuv4eCLozypXqvuNbzQaot3kdRCrtc/KxUoNoEHBkkdc+a/n3XZ0UQ5tul0WYgUfRLcvd u3LXTD9xquJA8lQ5vBbuz3zsuts/bCqzFrGGEp2ukzTVuNXQ9z6pAgMBAAGjMzAxMA8GA1Ud EwQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0B AQIFAAOBgQDB+vcC51fKEXXGnAz6K3dPh0UXO+PSwdoPWDmOrpWZA6GooTj+eZqTFwuXhjnH ymg0ZrvHiEX2yAwF7r6XJe/g1G7kf512XM59uhSirguf+2dbSKVnJa8ZZIj2ctgpJ6o3Emqx KK8ngxhlbI3tQJ5NxHiohuzpLFC/pvkN27CmSjCCAjEwggGaAgUCpAAAATANBgkqhkiG9w0B AQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT LkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYw MTI5MDAwMDAwWhcNOTkxMjMxMjM1OTU5WjBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOUZv22jVmEtmUhx 9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiHmgabEKFz37RYOWtuwfYV 1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF4Ncth3uhtzKwezC6 Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAUnO6mlXc3D+CfbCQmGIqgkx2AG4l PdXCCXBXAQwPdx8YofscYA6gdTtJIUH+p1wtTEJJ0/8o2Izqnf7JB+J3glMj3lXzzkST+vpM vco281tmsp7I8gxeXtShtCEJM8o7WfySwjj8rdmWJOAt+qMp9TNoeE60vJ9pNeKomJRzO8Qx ggHQMIIBzAIBATB2MGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2Ny aWJlcgIQHgYWIYVlaSqlXzQ43Oi/4jAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk3MTAxNjE2NTExNFowIwYJKoZIhvcNAQkEMRYE FHd+naCchcSozH1P5j230A2ekAFyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAbrZsdNDX8JQGWbU4/rVwRckA74dEieDPDqEiqJRVoNAlmZB/EZnU Yb6MfN2ooQpOwwA+pae6CxqfPNJisabFZL/EH3+FndBjD9wM8/3WK/GiHlwJeU1Iy7qA4KCh w6uz5Ly/agxT1K+xU0mUyyMA8vbuOgVEEkBzHQlj/53Td5k= --------------msCEBE3B7FC547EA65AC517C3E-- From osborne@gateway.grumman.com Thu Oct 16 19:02:52 1997 From: osborne@gateway.grumman.com (Rick Osborne) Date: Thu, 16 Oct 1997 14:02:52 -0400 Subject: Literal addresses in URLs - 'splain to me Message-ID: <3.0.3.32.19971016140252.00a66330@gateway.northgrum.com> I would like someone to explain to me exactly why disallowing literal addresses in IPv6 URLs should not be allowed. (Kind of a double negative, sorry.) I mean, I'm advocating that we bar them from URLs and nothing else. Typing "ping aaaa:bbbb::cc:d" from a console or anything is just fine, but why work so hard to find a way to use them as URLs? I'm just not seeing it ... -- Rick Osborne Are you trying to tell us that you get up incredibly early, just to spend an hour reading news and not having any breakfast? [...] I'm aghast that any human being would ever leave the sweet arms of Morpheus, unless forced to by powers beyond his control. - Dan Sorenson From masaki@merit.edu Thu Oct 16 19:31:53 1997 From: masaki@merit.edu (Masaki Hirabaru) Date: Thu, 16 Oct 1997 14:31:53 -0400 Subject: which BGP4+ used Message-ID: <199710161831.OAA28867@merit.edu> Folks, I know a version of BGP4+ is running over 6bone, but it seems different from draft-ietf-idr-bgp4-multiprotocol-01.txt. I'm now testing our BGP4+ code with cisco at one of 6bone backbone sites, but its BGP4+ is apparently different from the draft. I'm afraid I might miss something new. Is there any updated spec? Thanks, Masaki From bound@zk3.dec.com Thu Oct 16 21:21:24 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Thu, 16 Oct 1997 16:21:24 -0400 Subject: Literal addresses in URLs - 'splain to me In-Reply-To: Your message of "Thu, 16 Oct 1997 14:02:52 EDT." <3.0.3.32.19971016140252.00a66330@gateway.northgrum.com> Message-ID: <9710162021.AA31573@wasted.zk3.dec.com> >I would like someone to explain to me exactly why disallowing literal >addresses in IPv6 URLs should not be allowed. (Kind of a double negative, >sorry.) I mean, I'm advocating that we bar them from URLs and nothing >else. Typing "ping aaaa:bbbb::cc:d" from a console or anything is just >fine, but why work so hard to find a way to use them as URLs? I'm just not >seeing it ... I agree outlaw them for IPv6. This is very intelligent input. /jim From roque@cisco.com Fri Oct 17 02:16:01 1997 From: roque@cisco.com (Pedro Marques) Date: Thu, 16 Oct 1997 18:16:01 -0700 (PDT) Subject: which BGP4+ used In-Reply-To: <199710161831.OAA28867@merit.edu> References: <199710161831.OAA28867@merit.edu> Message-ID: <199710170116.SAA01235@pedrom-ultra.cisco.com> >>>>> "Masaki" == Masaki Hirabaru writes: Masaki> Folks, I know a version of BGP4+ is running over 6bone, Masaki> but it seems different from Masaki> draft-ietf-idr-bgp4-multiprotocol-01.txt. I'm now testing Masaki> our BGP4+ code with cisco at one of 6bone backbone sites, Masaki> but its BGP4+ is apparently different from the draft. I'm Masaki> afraid I might miss something new. Is there any updated Masaki> spec? Masaki, The current cisco implementation does draft-ietf-idr-bgp4-multiprotocol-00.txt (a couple of length fields where taken out of MP attributes in the -01 version so they don't really interoperate). Pedro. From kunihiro@zebra.org Fri Oct 17 07:21:56 1997 From: kunihiro@zebra.org (kunihiro@zebra.org) Date: Fri, 17 Oct 1997 15:21:56 +0900 Subject: which BGP4+ used Message-ID: <199710170621.PAA18946@rs.digital-magic.co.jp> >I know a version of BGP4+ is running over 6bone, but it seems >different from draft-ietf-idr-bgp4-multiprotocol-01.txt. I'm now >testing our BGP4+ code with cisco at one of 6bone backbone sites, >but its BGP4+ is apparently different from the draft. I'm afraid >I might miss something new. Is there any updated spec? I'm thinking about a same problem. It seems that some current running code conforms draftr-ietf-idr-bgp4-multiprotocol-00.txt (include two octet NLRI length field). Many people are thinking that it is also important conforming current vendor's beta version implemetation. But I'm not sure vedor implementation. I have seen three types of BGP4+ packet. Below description assumes SNPA is zero. 1. o gated-bgp4+ default (without -DBATES_LAST_DRAFT) .. no SAFI +--------------------------------+ | AFI (2 octets) | +--------------------------------+ | Length of NextHop (1 octet) | +--------------------------------+ | Address of NextHop (variable) | +--------------------------------+ | Number of SNPAs (1 octet = 0) | +--------------------------------+ | NLRI Length (2 octets) | +--------------------------------+ | NLRI (variable) | +--------------------------------+ 2. draft-ietf-idr-bgp4-multiprotocol-00 o gated-bgp4+ (with -DBATES_LAST_DRAFT ) o MRT o zebra (with draft-00 option) .. with NLRI length +--------------------------------+ | AFI (2 octets) | +--------------------------------+ | SAFI (1 octet) | +--------------------------------+ | Length of NextHop (1 octet) | +--------------------------------+ | Address of NextHop (variable) | +--------------------------------+ | Number of SNPAs (1 octet = 0) | +--------------------------------+ | NLRI Length (2 octets) | +--------------------------------+ | NLRI (variable) | +--------------------------------+ 3. draft-ietf-idr-bgp4-multiprotocol-01 o zebra ... rid of NLRI length +--------------------------------+ | AFI (2 octets) | +--------------------------------+ | SAFI (1 octet) | +--------------------------------+ | Length of NextHop (1 octet) | +--------------------------------+ | Address of NextHop (variable) | +--------------------------------+ | Number of SNPAs (1 octet = 0) | +--------------------------------+ | NLRI (variable) | +--------------------------------+ IMHO, the best thing is moving toward to draft-ietf-idr-bgp4-multiprotocol-01 specification. -- Kunihiro Ishiguro From brian@hursley.ibm.com Fri Oct 17 10:30:14 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Fri, 17 Oct 1997 10:30:14 +0100 Subject: Literal addresses in URLs - 'splain to me In-Reply-To: <9710162021.AA31573@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Oct 16, 97 04:21:24 pm Message-ID: <9710170930.AA125978@hursley.ibm.com> That was certainly my view when drafting RFC 1900 and in the ideal world I would stick to it. However the fact is that when there is a catastrophic operational problem with DNS, there can be cases where the *only* way to repair the network is by using literal addresses, either to send mail to another site, or to access remote systems - and URLs are one of the ways we access remote systems these days. So while I stick to the deprecation of literal addresses that is in RFC 1900, I regretfully feel that we need them as emergency backup. That means the syntax doesn't have to be beautiful. Brian Carpenter >- bound@zk3.dec.com said: > > > >I would like someone to explain to me exactly why disallowing literal > >addresses in IPv6 URLs should not be allowed. (Kind of a double negative, > >sorry.) I mean, I'm advocating that we bar them from URLs and nothing > >else. Typing "ping aaaa:bbbb::cc:d" from a console or anything is just > >fine, but why work so hard to find a way to use them as URLs? I'm just not > >seeing it ... > > I agree outlaw them for IPv6. This is very intelligent input. > > /jim > From masaki@merit.edu Fri Oct 17 14:55:43 1997 From: masaki@merit.edu (Masaki Hirabaru) Date: Fri, 17 Oct 1997 09:55:43 -0400 Subject: which BGP4+ used In-Reply-To: Your message of "Fri, 17 Oct 1997 15:21:56 +0900." <199710170621.PAA18946@rs.digital-magic.co.jp> Message-ID: <199710171355.JAA11833@merit.edu> Kunihiro and Pedro, Thanks for letting me know. I haven't seen the -00 version, so I got confused. I'm still writing this by analyzing a BGP4+ packet I'm receiving rather than looking at the -00 version. So, the following differences may not cover all. 1) There is a length field, NLRI Length (2 octets) in Kunihiro's explanation, which doesn't exist in the -01 version. Both MP_REACH_NLRI (Type Code 14) and MP_UNREACH_NLRI (Type Code 15) have this 2 octets length field right before Network Layer Reachability Information (variable) or Withdrawn Routes (variable), respectively. 2) The Length of Next Hop Network Address (1 octet) in MP_REACH_NLRI (Type Code 14) has a value 32; A global-scope address (16 octets) and a link-local address (16 octets) follow. I think that in the -01 version, next hop address should be one. Kunirhiro, my BGP4+ code is based on the same one Gated has. I need to connect the 6bone with BGP4+, so I have no choice at the moment. So, probably I'd better put some configuration option to switch a version depending on a peer. Does 6bone has a plan to migrate to the -01 version? I don't think there is any version information to distinguish in BGP4+ OPEN message, so I think we may need to have a schedule if we want to update. Anyway, thanks. I'm clear now. Masaki > Return-Path: majordom@ISI.EDU > Message-Id: <199710170621.PAA18946@rs.digital-magic.co.jp> > From: kunihiro@zebra.org > To: 6bone@ISI.EDU > Subject: Re: which BGP4+ used > Content-Type: Text/Plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Date: Fri, 17 Oct 1997 15:21:56 +0900 > Sender: owner-6bone@ISI.EDU > Precedence: bulk > > >I know a version of BGP4+ is running over 6bone, but it seems > >different from draft-ietf-idr-bgp4-multiprotocol-01.txt. I'm now > >testing our BGP4+ code with cisco at one of 6bone backbone sites, > >but its BGP4+ is apparently different from the draft. I'm afraid > >I might miss something new. Is there any updated spec? > > I'm thinking about a same problem. It seems that some current running > code conforms draftr-ietf-idr-bgp4-multiprotocol-00.txt (include two > octet NLRI length field). Many people are thinking that it is also > important conforming current vendor's beta version implemetation. But > I'm not sure vedor implementation. > > I have seen three types of BGP4+ packet. Below description assumes > SNPA is zero. > > 1. o gated-bgp4+ default (without -DBATES_LAST_DRAFT) > .. no SAFI > +--------------------------------+ > | AFI (2 octets) | > +--------------------------------+ > | Length of NextHop (1 octet) | > +--------------------------------+ > | Address of NextHop (variable) | > +--------------------------------+ > | Number of SNPAs (1 octet = 0) | > +--------------------------------+ > | NLRI Length (2 octets) | > +--------------------------------+ > | NLRI (variable) | > +--------------------------------+ > > 2. draft-ietf-idr-bgp4-multiprotocol-00 > o gated-bgp4+ (with -DBATES_LAST_DRAFT ) > o MRT > o zebra (with draft-00 option) > .. with NLRI length > +--------------------------------+ > | AFI (2 octets) | > +--------------------------------+ > | SAFI (1 octet) | > +--------------------------------+ > | Length of NextHop (1 octet) | > +--------------------------------+ > | Address of NextHop (variable) | > +--------------------------------+ > | Number of SNPAs (1 octet = 0) | > +--------------------------------+ > | NLRI Length (2 octets) | > +--------------------------------+ > | NLRI (variable) | > +--------------------------------+ > > 3. draft-ietf-idr-bgp4-multiprotocol-01 > o zebra > ... rid of NLRI length > +--------------------------------+ > | AFI (2 octets) | > +--------------------------------+ > | SAFI (1 octet) | > +--------------------------------+ > | Length of NextHop (1 octet) | > +--------------------------------+ > | Address of NextHop (variable) | > +--------------------------------+ > | Number of SNPAs (1 octet = 0) | > +--------------------------------+ > | NLRI (variable) | > +--------------------------------+ > > IMHO, the best thing is moving toward to draft-ietf-idr-bgp4-multiprotocol-01 > specification. > -- > Kunihiro Ishiguro From kcn@digex.net Fri Oct 17 17:59:36 1997 From: kcn@digex.net (Kevin Nicholson) Date: Fri, 17 Oct 1997 12:59:36 -0400 (EDT) Subject: Cisco router configuration examples Message-ID: I have searched the 6bone mailing list archives looking for examples of IPv6 tunneling, and dynamic/static routing, and IPv4<>IPv6 NAT .. with no luck. Could someone please post a few cisco config examples, along with images and hardware recommendations ? Kevin Nicholson Principal Engineer - Access Postal: One DIGEX Plaza, Beltsville MD USA 20705 From roque@cisco.com Fri Oct 17 19:19:58 1997 From: roque@cisco.com (Pedro Marques) Date: Fri, 17 Oct 1997 11:19:58 -0700 (PDT) Subject: which BGP4+ used In-Reply-To: <199710171355.JAA11833@merit.edu> References: <199710170621.PAA18946@rs.digital-magic.co.jp> <199710171355.JAA11833@merit.edu> Message-ID: <199710171819.LAA01533@pedrom-ultra.cisco.com> >>>>> "Masaki" == Masaki Hirabaru writes: Masaki> Kunihiro and Pedro, Thanks for letting me know. I haven't Masaki> seen the -00 version, so I got confused. I'm still writing Masaki> this by analyzing a BGP4+ packet I'm receiving rather than Masaki> looking at the -00 version. So, the following differences Masaki> may not cover all. Masaki> 1) There is a length field, NLRI Length (2 octets) in Masaki> Kunihiro's explanation, which doesn't exist in the -01 Masaki> version. Yes. Those fields where removed in the -01 version. Masaki> 2) The Length of Next Hop Network Address (1 octet) in Masaki> MP_REACH_NLRI (Type Code 14) has a value 32; A Masaki> global-scope address (16 octets) and a link-local address Masaki> (16 octets) follow. This is not a question of what the bgp-multiprotocol draft defines but what a separate document, on IPv6 information over BGP will define. This document will be based on the section on IPv6 in draft-bates-bgp4-multiprotocol. If you look at that section you see when the nexthop should consist of one or two ipv6 addresses. The ipv6-bgp draft should be availiable soon. Masaki> Does 6bone has a plan to migrate to the -01 version? You might not be able to make a "plan" as it depends on the availability of code from vendors... Pedro. From masaki@merit.edu Fri Oct 17 20:01:19 1997 From: masaki@merit.edu (Masaki Hirabaru) Date: Fri, 17 Oct 1997 15:01:19 -0400 Subject: which BGP4+ used In-Reply-To: Your message of "Fri, 17 Oct 1997 11:19:58 PDT." <199710171819.LAA01533@pedrom-ultra.cisco.com> Message-ID: <199710171901.PAA17569@merit.edu> > Masaki> 2) The Length of Next Hop Network Address (1 octet) in > Masaki> MP_REACH_NLRI (Type Code 14) has a value 32; A > Masaki> global-scope address (16 octets) and a link-local address > Masaki> (16 octets) follow. > > This is not a question of what the bgp-multiprotocol draft defines but > what a separate document, on IPv6 information over BGP will define. > > This document will be based on the section on IPv6 in > draft-bates-bgp4-multiprotocol. If you look at that section you see when > the nexthop should consist of one or two ipv6 addresses. > > The ipv6-bgp draft should be availiable soon. Pedro, I saw the -00 version. I understand this is a current ambiguous point independently of the versions. I'm waiting for the ipv6-bgp draft. > Masaki> Does 6bone has a plan to migrate to the -01 version? > > You might not be able to make a "plan" as it depends on the availability > of code from vendors... We could push vendor(s) :-) I know the difference is trivial for users, but it might bring an operational confusion. We will need to ask our peers which bgp4+ is used, bgp4+00 or bgp4+01. Thanks, Masaki From bound@zk3.dec.com Sat Oct 18 16:37:26 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Sat, 18 Oct 1997 11:37:26 -0400 Subject: Literal addresses in URLs - 'splain to me In-Reply-To: Your message of "Fri, 17 Oct 1997 10:30:14 BST." <9710170930.AA125978@hursley.ibm.com> Message-ID: <9710181537.AA14668@wasted.zk3.dec.com> >However the fact is that when there is a catastrophic operational >problem with DNS, there can be cases where the *only* way to >repair the network is by using literal addresses, either to >send mail to another site, or to access remote systems - >and URLs are one of the ways we access remote systems these days. >So while I stick to the deprecation of literal addresses that is >in RFC 1900, I regretfully feel that we need them as emergency backup. A valid point. But I don't see repairing DNS using URLs. No one is saying you can't use IPv6 addresses in this input. Just we don't need them for URLs. They work fine now with FTP, Telnet, etc.. /jim From roque@cisco.com Sun Oct 19 10:49:56 1997 From: roque@cisco.com (Pedro Marques) Date: Sun, 19 Oct 1997 02:49:56 -0700 (PDT) Subject: as1275 Message-ID: <199710190949.CAA02415@pedrom-ultra.cisco.com> I've configured our router to reject all the BGP routes sourced by AS 1275 as they are injecting in tons of doubtable information, including a default route. Internic says that as1275 is registered as: c/o University of Dortmund (ASN-UNIDO) GERMANY Autonomous System Name: UNIDO-AS Autonomous System Block: 1270 - 1275 But there is absolutly no reference to the university of dortmund in the 6bone registry (which is one of the reasons this mail is not being sent privatly). Intead i find about ten sites (CCed in the message) all which claim to be in AS 1275. What i don't really understand is why, if all the sites share the same AS, aren't they all under the same prefix which can be cleanly annouced. And if there is a good reason why this can't be done then perhaps they shoulnd't be in the same AS... Can you folks please try to sort out this mess ... Please don't inject prefixes which you don't own or for which the owners have not explicitly asked you to originate them (there are plenty of prefixes bellow that belong to US sites). And *please* don't inject a default route into BGP. Thanks, Pedro. -------------------------------------------------------------------------- 6bone-router>sh ipv6 bgp reg 1275$ BGP IPv6 table version is 745545, local router id is 192.31.7.217 Status codes: * - valid, > - best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete 3FFE::0/24 * 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:200::0/24 * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i 3FFE:400::0/24 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:600:8000::4/126 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? 3FFE:700:20:1::14/126 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? 3FFE:7C0:40::0/48 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:800::0/32 * 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i 3FFE:A00::0/24 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 3FFE:F00::0/24 * 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1001:1:FFFF::0/126 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? 3FFE:1100:0:400::2C/126 * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? 3FFE:1100:0:C00::4/126 * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? 3FFE:1100:0:C0C::0/64 * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? 3FFE:1100:0:1420::0/64 * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i 3FFE:1108:800::0/40 * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i 3FFE:1300::0/24 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1500::FFFE:0:0:14/126 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i 3FFE:1500::FFFE:0:0:1C/126 * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i 3FFE:1500::FFFE:0:1EA1:0/126 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1C00:0:60::0/64 * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 3FFE:1C00::0/24 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 3FFE:1D04::0/124 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1D04:1::0/64 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1DEC::0/32 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1E00::0/24 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 3FFE:2500::0/25 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F00:100:807F::0/48 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F00:C00:807A:4000::0/64 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F00:1000:0:F:F::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? 5F00:6D00:0:E:8::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? 5F00:80DF:0:E:9::0/112 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? 5F00:E000:C19C:1300::0/64 * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? 5F00:ED00::0/40 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 5F00:ED00:C66C:3C00::0/64 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 5F01:F00:8E67:A00::0/64 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 5F02:2000:C1D1:ED00::0/64 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F02:2F00::0/32 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F02:3000:84B1:7900:1::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F02:3000:84B1::0/48 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F02:3000:C020:AE00:201D::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F02:3000:C020:AE00:B180::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F02:AD00::0/32 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 5F02:BD00:D0D0:D800::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F04:4F00::BBBB:1103:3274:0/112 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? 5F04:4F00::BBBB:1103:3582:0/112 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? 5F04:C900:8367:2::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? 5F04:F900::0/32 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 5F04:FB00::0/32 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F06:2800:967E:F300::0/64 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 5F06:8900::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F06:8900:0:1:3::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F06:D500::0/32 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F06:D800::0/32 * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? 5F06:F900:8DFE:100::0/64 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F07:2B00::0/32 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 5F09:F300:9842:4C00::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F09:F300:9842:4C00:4C::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F09:F400:CF57:2E00::0/64 * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i 5F0B:1700:C10A:4200::0/64 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F0B:2900::0/32 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 5F0B:3700::0/32 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 5F0B:4F00:C1E9:700::0/64 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 5F0D:500:C100::0/64 * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i 5F0D:E900:9EA5:800:8::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 5F00:6D00:0:E:8::2 FE80::C5A:CB51:A Tunnel7 3582 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F15:A300::4:0/126 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? 5F1A:6D00:C269:A600::0/64 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 5F1B:5000::1:0:0:0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F1B:5000::0/32 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F1D:800:D009:200::0/80 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 5F21:EA00:C20C:E000:0:60::0/96 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? 5F28:1D00:C171:3A00::0/64 * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? 5FFF:FF00:C0A8:C00::0/64 *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 0::0/0 * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1849 5539 4555 1225 1275 ? *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 5539 4555 1225 1275 ? 6bone-router> From Martynas Buozis Sun Oct 19 19:07:02 1997 From: Martynas Buozis (Martynas Buozis) Date: Sun, 19 Oct 1997 21:07:02 +0300 (EET DST) Subject: Some questions. In-Reply-To: Message-ID: Dear sirs, I have some questions and hope, that you will help me. 1. Some time ago, as I remember, on the ticl.co.uk IPv6 Web Page http://www.ipv6.ticl.co.uk/ I found a possibility to order The IPv6 Resource Kit on CDROM. But when I decided to subscribe it I found, that this page isn't reachable now. I was trying for one week to get on it. Maybe someone can give me another address of that company - I want order CD's about IPv6 and security. Maybe I am looking on wrong address or company ? 2. I wrote several times to Mr. Martin McNealis form CISCO (mail address mmcnealis@cisco.com) asking for help about implementing IPv6 on CISCO routers, but two months there are no answer from him. Maybe you can advice someone who can help me with IPv6 on CISCO routers ? With best regards - Martynas Buozis Litnet NOC From Aad.van.der.Zanden@nc3a.nato.int Mon Oct 20 08:49:13 1997 From: Aad.van.der.Zanden@nc3a.nato.int (Aad van der Zanden) Date: Mon, 20 Oct 1997 08:49:13 +0100 Subject: Some questions. Message-ID: <3.0.32.19971020084910.009d1250@mail.nc3a.nato.int> At 09:07 PM 10/19/97 +0300, Martynas Buozis wrote: >Dear sirs, > >I have some questions and hope, that you will help me. > >1. Some time ago, as I remember, on the ticl.co.uk IPv6 Web Page >http://www.ipv6.ticl.co.uk/ I found a possibility to order The IPv6 >Resource Kit on CDROM. But when I decided to subscribe it I found, that >this page isn't reachable now. I was trying for one week to get on it. >Maybe someone can give me another address of that company - I want order >CD's about IPv6 and security. Maybe I am looking on wrong address or >company ? > >2. I wrote several times to Mr. Martin McNealis form CISCO (mail address >mmcnealis@cisco.com) asking for help about implementing IPv6 on CISCO >routers, but two months there are no answer from him. Maybe you can advice >someone who can help me with IPv6 on CISCO routers ? > Join the crowd ... I have also tried triggering him several times. Although I have verbally been promised to get some Cisco ip6 images I have had no responses at all from three attempts to mmcnealis@cisco.com and a Cc: to the manager of Cisco IOS product Market also resulted in the sound of silence. It looks like Cisco has a selective market for ip6 ... :-( ( maybe this one triggers some attention...) Aad > > > > quote: "If a trainstation is where the train stops, a busstation is where the bus stops, then a workstation is where......." ================================================================== // Aad van der Zanden | POSTAL ADDRESS: // Communications Systems Division | // NATO C3 Agency | NATO C3 Agency // Email : Aad.van.der.Zanden@nc3a.nato.int | P.O. BOX 174 // Phone : +31 (0)70 3142440 | 2501 CD The Hague // Fax : +31 (0)70 3142176 |The Netherlands ============================================================================ NEW NEW H320 compliant video phone #31 070 3148107 NEW NEW NEW ============================================================================ From brian@hursley.ibm.com Mon Oct 20 09:25:51 1997 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Mon, 20 Oct 1997 09:25:51 +0100 Subject: Literal addresses in URLs - 'splain to me In-Reply-To: <9710181537.AA14668@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Oct 18, 97 11:37:26 am Message-ID: <9710200825.AA15774@hursley.ibm.com> Right, this is *exactly* what we have to decide about. Are there any operational situations where fixing DNS *requires* web access? Brian >- bound@zk3.dec.com said: > > > >However the fact is that when there is a catastrophic operational > >problem with DNS, there can be cases where the *only* way to > >repair the network is by using literal addresses, either to > >send mail to another site, or to access remote systems - > >and URLs are one of the ways we access remote systems these days. > >So while I stick to the deprecation of literal addresses that is > >in RFC 1900, I regretfully feel that we need them as emergency backup. > > A valid point. But I don't see repairing DNS using URLs. No one is > saying you can't use IPv6 addresses in this input. Just we don't need > them for URLs. They work fine now with FTP, Telnet, etc.. > > /jim > From smurf@noris.de Mon Oct 20 12:55:48 1997 From: smurf@noris.de (Matthias Urlichs) Date: Mon, 20 Oct 1997 13:55:48 +0200 (Funky) Subject: Literal addresses in URLs - 'splain to me In-Reply-To: <9710200825.AA15774@hursley.ibm.com> from "majordom@ISI.EDU" at Oct 20, 97 09:25:51 am Message-ID: <19971020115548.14852.qmail@nova.noris.de> Brian: >Right, this is *exactly* what we have to decide about. >Are there any operational situations where fixing DNS *requires* >web access? Some boxes (firewalls, for instance) are administered by a WWW interface. They may either not have a Telnet interface, or the administrator (or the manual...) is sufficiently clueless that it may not be possible for them to fix the DNS without a browser. On the other hand, if we include the ability to use URLs with IPv6 addresses, then the terminally clueless (including some search engines) will no doubt use them (instead of domain names) internally. We already see that with IPv4, and IMHO it's a problem. It's going to be more of a problem with IPv6. On balance ... I don't know yet. :-/ -- Matthias Urlichs noris network GmbH From JOIN Project Team Mon Oct 20 14:43:14 1997 From: JOIN Project Team (JOIN Project Team) Date: Mon, 20 Oct 1997 15:43:14 +0200 (MEZ) Subject: as1275 In-Reply-To: <199710190949.CAA02415@pedrom-ultra.cisco.com> Message-ID: Hi Pedro, On Sun, 19 Oct 1997, Pedro Marques wrote: > > I've configured our router to reject all the BGP routes sourced by AS 1275 > as they are injecting in tons of doubtable information, including a default > route. > > Internic says that as1275 is registered as: > > c/o University of Dortmund (ASN-UNIDO) > GERMANY > > Autonomous System Name: UNIDO-AS > Autonomous System Block: 1270 - 1275 > > But there is absolutly no reference to the university of dortmund in the > 6bone registry (which is one of the reasons this mail is not being sent > privatly). Intead i find about ten sites (CCed in the message) all which claim > to be in AS 1275. AS1275 is registered (in the RIPE db) as "DFN-IP service and DFN customer networks". We use it for our IPv6 JOIN project (it is an DFN project). > What i don't really understand is why, if all the sites > share the same AS, aren't they all under the same prefix which can be cleanly > annouced. And if there is a good reason why this can't be done then perhaps > they shoulnd't be in the same AS... All IPv6 sites using AS1275 should have the same prefixes 3ffe:400::/24 or 5f04:fb00::/32. In general these are German sites like Universities. For these two prefixes we do BGP route aggregation, so i wonder if you see more and/or longer prefixes *originated* at JOIN. > > Can you folks please try to sort out this mess ... > > Please don't inject prefixes which you don't own or for which the owners > have not explicitly asked you to originate them (there are plenty of prefixes > bellow that belong to US sites). And *please* don't inject a default route > into BGP. These days i discussed similar problems with Guy (UUNET-UK). He also received a lot of routes which should be originated by JOIN according to his routing table. Now this seems to be the case also at your site :-( When i examine our routing table i find for all the routes (which you claim as "tons of doubtable information"), a source from which our router gets them. I appended to this mail our complete routing table for all 3ffe-prefixes. I wonder why your routing table mentions AS1275 as originator of all these routes. What does "i" (IGP) as origin code mean in your routing table? Does it mean that these routes are learned via RIPng at our site? I believe there should be "e"'s (EGP), because we got these routes via BGP from other sites. Some of your routes specify "?" (incomplete) as source of (our?) information: when i check these routes i get "BGP-INCOMPLETE" in our routing table. That means, that this route is learned via BGP from our router, but has not a complete BGP path to the originator of the prefix - e.g. there is some RIPng or static routing inbetween. I can see no reason (or configuration line) why we should originate these routes - in general we get them via BGP from our BGP peers (see our routing table). I did not find a default route in our table. Maybe this route was visible at the time you examined your table - but i am quite sure that we are *not* the originator of a default route (hopefully i am right ;-) For your information we still have 6bone tunnels to core backbone sites running RIPng (BAY) and IDRPv6 (UNI-C and IFB) as routing protocols. But to all these sites i configured strong in- and out-filters, so normally there should be no problems with that. On our BGP4+ tunnels i configured no filters (except the aggregation of our two prefixes, of course). Hope this helps a little bit, all the best - Guido ------------------------------------------------------------------------------ JOIN -- IP Version 6 in the WiN Guido Wessendorf A project of DFN Westfaelische Wilhelms-Universitaet Muenster Project Team email: Universitaetsrechenzentrum join@uni-muenster.de Einsteinstrasse 60 http://www.join.uni-muenster.de D-48149 Muenster / Germany phone: +49 251 83 31639, fax: +49 251 83 31653, email: wessend@uni-muenster.de ------------------------------------------------------------------------------ >Thanks, > Pedro. > > -------------------------------------------------------------------------- > 6bone-router>sh ipv6 bgp reg 1275$ > BGP IPv6 table version is 745545, local router id is 192.31.7.217 > Status codes: * - valid, > - best, i - internal > Origin codes: i - IGP, e - EGP, ? - incomplete > > 3FFE::0/24 > * 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 3FFE:200::0/24 > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > 3FFE:400::0/24 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 3FFE:600:8000::4/126 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > 3FFE:700:20:1::14/126 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > 3FFE:7C0:40::0/48 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 3FFE:800::0/32 > * 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > 3FFE:A00::0/24 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 3FFE:F00::0/24 > * 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 3FFE:1001:1:FFFF::0/126 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > 3FFE:1100:0:400::2C/126 > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > 3FFE:1100:0:C00::4/126 > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > 3FFE:1100:0:C0C::0/64 > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > 3FFE:1100:0:1420::0/64 > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > 3FFE:1108:800::0/40 > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > 3FFE:1300::0/24 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 3FFE:1500::FFFE:0:0:14/126 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > 3FFE:1500::FFFE:0:0:1C/126 > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > 3FFE:1500::FFFE:0:1EA1:0/126 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 3FFE:1C00:0:60::0/64 > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 3FFE:1C00::0/24 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 3FFE:1D04::0/124 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 3FFE:1D04:1::0/64 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 3FFE:1DEC::0/32 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 3FFE:1E00::0/24 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 3FFE:2500::0/25 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F00:100:807F::0/48 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F00:C00:807A:4000::0/64 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F00:1000:0:F:F::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > 5F00:6D00:0:E:8::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > 5F00:80DF:0:E:9::0/112 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > 5F00:E000:C19C:1300::0/64 > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > 5F00:ED00::0/40 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 5F00:ED00:C66C:3C00::0/64 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 5F01:F00:8E67:A00::0/64 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 5F02:2000:C1D1:ED00::0/64 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F02:2F00::0/32 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F02:3000:84B1:7900:1::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F02:3000:84B1::0/48 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F02:3000:C020:AE00:201D::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F02:3000:C020:AE00:B180::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F02:AD00::0/32 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 5F02:BD00:D0D0:D800::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F04:4F00::BBBB:1103:3274:0/112 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > 5F04:4F00::BBBB:1103:3582:0/112 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > 5F04:C900:8367:2::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > 5F04:F900::0/32 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 5F04:FB00::0/32 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F06:2800:967E:F300::0/64 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 5F06:8900::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F06:8900:0:1:3::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F06:D500::0/32 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F06:D800::0/32 > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > 5F06:F900:8DFE:100::0/64 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F07:2B00::0/32 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 5F09:F300:9842:4C00::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F09:F300:9842:4C00:4C::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F09:F400:CF57:2E00::0/64 > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > 5F0B:1700:C10A:4200::0/64 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F0B:2900::0/32 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 5F0B:3700::0/32 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 5F0B:4F00:C1E9:700::0/64 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 5F0D:500:C100::0/64 > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > 5F0D:E900:9EA5:800:8::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 5F00:6D00:0:E:8::2 FE80::C5A:CB51:A Tunnel7 3582 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F15:A300::4:0/126 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > 5F1A:6D00:C269:A600::0/64 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 5F1B:5000::1:0:0:0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F1B:5000::0/32 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F1D:800:D009:200::0/80 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 i > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 i > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 i > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i > 5F21:EA00:C20C:E000:0:60::0/96 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > 5F28:1D00:C171:3A00::0/64 > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > 5FFF:FF00:C0A8:C00::0/64 > *> 5F00:6D00:0:E:D::2 FE80::C8E:50C2:6 Tunnel12 1225 1275 ? > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1225 1275 ? > * 5F00:6D00:0:E:F::2 FE80::60:2FA7:ED00:8 Tunnel14 4555 1225 1275 ? > * 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? > 0::0/0 > * 3FFE:DFE:1::9 FE80::E0:B0E2:3AB9:9 Tunnel26 1673 1849 5539 4555 1225 1275 ? > *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 5539 4555 1225 1275 ? > 6bone-router> =============================================================================== The complete JOIN routing table for the 3ffe prefixes: 3ffe::/24 CICNET 15 BGP ( AS Path: 1225 109 48 ) 3ffe::/24 G6 20 BGP ( AS Path: 1717 786 109 48 ) 3ffe::/24 SURFNET 20 BGP ( AS Path: 1103 1225 109 48 ) 3ffe::/24 SWITCH 25 BGP ( AS Path: 559 1717 786 109 48 ) 3ffe:100::/24 TELEBIT 5 BGP ( AS Path: 3263 ) 3ffe:100::/24 SURFNET 10 BGP ( AS Path: 1103 3263 ) 3ffe:200::/24 SWITCH 50 BGP 3ffe:300::/24 G6 5 BGP ( AS Path: 1717 ) 3ffe:300::/24 INFN-CNAF 10 BGP ( AS Path: 137 1717 ) 3ffe:300::/24 SURFNET 10 BGP ( AS Path: 1103 1717 ) 3ffe:301:dec1::/48 SWITCH 50 BGP 3ffe:302:11:2:0:2:0:50/124 INFN-CNAF 50 BGP-INCOMPLETE ( AS Path: 137 ) 3ffe:400::/24 NULL 0 Own Aggregation 3ffe:400::/24 SWITCH 50 BGP 3ffe:400:10:100::/64 lan5.v6 1 Configured broa 3ffe:400:10:100:200:a2ff:fec2:cbf2/128 paladin 1 Configured Peer 3ffe:400:10:100:2c0:33ff:fe00:11/128 lan5.v6 0 Configured path 3ffe:400:10:102::/64 lan5.v6 1 Static path ( NextHop: 3ffe:400:10:100:2c0:33ff:fe02:10 ) 3ffe:400:10:103::/64 lan5.v6 1 Static path ( NextHop: 3ffe:400:10:100:2c0:33ff:fe02:12 ) 3ffe:400:10:104::/64 lan5.v6 1 Static path ( NextHop: 3ffe:400:10:100:20c:14ff:fec9:90 ) 3ffe:400:40::/48 TU-BERLIN 1 Static path 3ffe:400:40:100:0:0:c0d4:4a6b/128 TU-BERLIN 1 Configured Peer 3ffe:400:50::/48 FAUERN 2 RIPv6 3ffe:400:50:1:0:0:0:1/128 FAUERN 1 Configured Peer 3ffe:400:60::/48 UNI-ULM 1 Static path 3ffe:400:60:1:a00:20ff:fe19:4a08/128 UNI-ULM 1 Configured Peer 3ffe:400:e0::/48 LRZ 1 Static path 3ffe:400:e0:902:0:0:0:1/128 LRZ 1 Configured Peer 3ffe:401::/64 lan1.v6 1 Configured broa 3ffe:401:0:0:2c0:33ff:fe02:14/128 UNI-ULM 0 Configured path 3ffe:401:0:0:2c0:33ff:fe02:14/128 TU-BERLIN 0 Configured path 3ffe:401:0:0:2c0:33ff:fe02:14/128 LRZ 0 Configured path 3ffe:401:0:0:2c0:33ff:fe02:14/128 INFN-CNAF 0 Configured path 3ffe:401:0:0:2c0:33ff:fe02:14/128 FAUERN 0 Configured path 3ffe:401:0:0:2c0:33ff:fe02:14/128 BAY 0 Configured path 3ffe:401:0:0:2c0:33ff:fe02:14/128 ATT-LABS-EUROPE 0 Configured path3ffe:401:0:0:2c0:33ff:fe02:14/128 paladin 0 Configured path 3ffe:401:0:0:2c0:33ff:fe02:14/128 lan1.v6 0 Configured path 3ffe:600::/24 SURFNET 5 BGP ( AS Path: 1103 ) 3ffe:600::/24 CICNET 10 BGP ( AS Path: 1225 1103 ) 3ffe:600::/24 G6 10 BGP ( AS Path: 1717 1103 ) 3ffe:600:8000:0:0:0:0:4/126 SWITCH 50 BGP-INCOMPLETE 3ffe:604:2::/48 SURFNET 10 BGP ( AS Path: 1103 1891 ) 3ffe:604:2::/48 G6 15 BGP ( AS Path: 1717 1103 1891 ) 3ffe:604:2::/48 CICNET 15 BGP ( AS Path: 1225 1103 1891 ) 3ffe:700::/24 ESNET 5 BGP ( AS Path: 293 ) 3ffe:700::/24 INFN-CNAF 10 BGP ( AS Path: 137 293 ) 3ffe:700:20:1:0:0:0:1/128 ESNET 1 Configured Peer 3ffe:700:20:1:0:0:0:2/128 ESNET 0 Configured path 3ffe:700:20:2:0:0:0:8/126 CICNET 50 BGP-INCOMPLETE ( AS Path: 1225 1103 1717 137 ) 3ffe:700:20:2:0:0:0:8/126 SWITCH 50 BGP-INCOMPLETE ( AS Path: 559 1717 137 ) 3ffe:700:20:2:0:0:0:8/126 SURFNET 50 BGP-INCOMPLETE ( AS Path: 1103 1717 137 ) 3ffe:700:20:2:0:0:0:8/126 G6 50 BGP-INCOMPLETE ( AS Path: 1717 137 ) 3ffe:700:20:2:0:0:0:8/126 INFN-CNAF 50 BGP-INCOMPLETE ( AS Path: 137 ) 3ffe:800::/32 CICNET 10 BGP ( AS Path: 1225 4555 ) 3ffe:800::/32 SURFNET 10 BGP ( AS Path: 1103 4555 ) 3ffe:800::/32 G6 15 BGP ( AS Path: 1717 1103 4555 ) 3ffe:900::/24 CICNET 5 BGP ( AS Path: 1225 ) 3ffe:900::/24 SURFNET 10 BGP ( AS Path: 1103 1225 ) 3ffe:a00::/24 SURFNET 10 BGP-INCOMPLETE 3ffe:a00::/24 SWITCH 50 BGP-INCOMPLETE 3ffe:c00::/24 CICNET 10 BGP ( AS Path: 1225 109 ) 3ffe:c00::/24 SURFNET 15 BGP ( AS Path: 1103 1225 109 ) 3ffe:c00::/24 G6 15 BGP ( AS Path: 1717 786 109 ) 3ffe:c00::/24 SWITCH 20 BGP ( AS Path: 559 1717 786 109 ) 3ffe:d01:0:0:0:0:0:4/126 CICNET 10 BGP ( AS Path: 1225 1673 ) 3ffe:d01:0:0:0:0:0:4/126 SURFNET 15 BGP ( AS Path: 1103 1225 1673 ) 3ffe:dfe:1:0:0:0:0:8/126 CICNET 10 BGP ( AS Path: 1225 1673 ) 3ffe:dfe:1:0:0:0:0:8/126 SURFNET 15 BGP ( AS Path: 1103 1225 1673 ) 3ffe:dfe:fffe:0:0:0:0:4/126 CICNET 10 BGP ( AS Path: 1225 1673 ) 3ffe:dfe:fffe:0:0:0:0:4/126 SURFNET 15 BGP ( AS Path: 1103 1225 1673 ) 3ffe:f00::/24 CICNET 15 BGP ( AS Path: 1225 109 48 ) 3ffe:f00::/24 SURFNET 20 BGP ( AS Path: 1103 1225 109 48 ) 3ffe:f00::/24 G6 20 BGP ( AS Path: 1717 786 109 48 ) 3ffe:f00::/24 SWITCH 25 BGP ( AS Path: 559 1717 786 109 48 ) 3ffe:1000::/24 SWITCH 212 BGP 3ffe:1100::/24 CICNET 10 BGP ( AS Path: 1225 1849 ) 3ffe:1100::/24 SURFNET 10 BGP ( AS Path: 1103 1849 ) 3ffe:1100::/24 G6 15 BGP ( AS Path: 1717 1103 1849 ) 3ffe:1100:0:1420::/64 SWITCH 50 BGP 3ffe:1108:800::/40 SWITCH 50 BGP 3ffe:1200::/24 CICNET 15 BGP ( AS Path: 1225 1849 33 ) 3ffe:1200::/24 SURFNET 15 BGP ( AS Path: 1103 1849 33 ) 3ffe:1200::/24 G6 20 BGP ( AS Path: 1717 1103 1849 33 ) 3ffe:1300::/24 BAY 2 RIPv6 3ffe:1300::/24 SWITCH 50 BGP 3ffe:1300:0:0:0:0:0:1/128 BAY 1 Configured Peer 3ffe:1400::/24 SWITCH 50 BGP 3ffe:1500:0:0:fffe:0:0:14/126 SWITCH 50 BGP 3ffe:1500:0:0:fffe:0:0:1c/126 SWITCH 50 BGP 3ffe:1500:0:0:fffe:0:1ea1::/126 SWITCH 50 BGP 3ffe:1600::/32 CICNET 15 BGP ( AS Path: 1225 109 7472 ) 3ffe:1600::/32 SURFNET 20 BGP ( AS Path: 1103 1225 109 7472 ) 3ffe:1600::/32 G6 20 BGP ( AS Path: 1717 786 109 7472 ) 3ffe:1600::/32 SWITCH 25 BGP ( AS Path: 559 1717 786 109 7472 ) 3ffe:1c00::/24 SWITCH 50 BGP-INCOMPLETE 3ffe:1c00:0:60::/64 SWITCH 50 BGP-INCOMPLETE 3ffe:1d00::/24 ATT-LABS-EUROPE 5 BGP ( AS Path: 5623 ) 3ffe:1d00::/24 G6 10 BGP ( AS Path: 1717 5623 ) 3ffe:1d00:1:100:a00:2bff:feb7:87f8/128 ATT-LABS-EUROPE 1 Configured Peer 3ffe:1d04::/32 SURFNET 10 BGP ( AS Path: 1103 6905 ) 3ffe:1d04::/32 CICNET 15 BGP ( AS Path: 1225 1103 6905 ) 3ffe:1d04::/32 SWITCH 15 BGP ( AS Path: 559 5623 6905 ) 3ffe:1d04::/32 G6 15 BGP ( AS Path: 1717 1103 6905 ) 3ffe:1d04::/124 SWITCH 50 BGP 3ffe:1d04:1::/64 SWITCH 50 BGP 3ffe:1d05::/32 SWITCH 50 BGP 3ffe:1dec::/32 SWITCH 50 BGP 3ffe:1e00::/24 SWITCH 50 BGP-INCOMPLETE 3ffe:1f00::/24 CICNET 15 BGP ( AS Path: 1225 1849 5571 ) 3ffe:1f00::/24 SURFNET 15 BGP ( AS Path: 1103 1849 5571 ) 3ffe:1f00::/24 G6 20 BGP ( AS Path: 1717 1103 1849 5571 ) 3ffe:2000::/24 SWITCH 5 BGP ( AS Path: 559 ) 3ffe:2000::/24 INFN-CNAF 10 BGP ( AS Path: 137 559 ) 3ffe:2000::/24 G6 10 BGP ( AS Path: 1717 559 ) 3ffe:2000:0:1::/128 SWITCH 1 Configured Peer 3ffe:2000:0:1:0:0:0:1/128 SWITCH 0 Configured path 3ffe:2000:0:1:0:0:0:60/124 CICNET 50 BGP-INCOMPLETE ( AS Path: 1225 1103 1717 137 ) 3ffe:2000:0:1:0:0:0:60/124 SWITCH 50 BGP-INCOMPLETE ( AS Path: 559 1717 137 ) 3ffe:2000:0:1:0:0:0:60/124 SURFNET 50 BGP-INCOMPLETE ( AS Path: 1103 1717 137 ) 3ffe:2000:0:1:0:0:0:60/124 G6 50 BGP-INCOMPLETE ( AS Path: 1717 137 ) 3ffe:2000:0:1:0:0:0:60/124 INFN-CNAF 50 BGP-INCOMPLETE ( AS Path: 137 ) 3ffe:2100::/24 SURFNET 10 BGP ( AS Path: 1103 786 ) 3ffe:2100::/24 G6 10 BGP ( AS Path: 1717 786 ) 3ffe:2100::/24 CICNET 15 BGP ( AS Path: 1225 1849 786 ) 3ffe:2100::/24 INFN-CNAF 15 BGP ( AS Path: 137 1717 786 ) 3ffe:2100::/24 SWITCH 15 BGP ( AS Path: 559 1717 786 ) 3ffe:2300::/24 INFN-CNAF 5 BGP ( AS Path: 137 ) 3ffe:2300::/24 G6 10 BGP ( AS Path: 1717 137 ) 3ffe:2300:0:ffff:0:0:0:9/128 INFN-CNAF 1 Configured Peer 3ffe:2400::/24 CICNET 10 BGP ( AS Path: 1225 109 ) 3ffe:2400::/24 SURFNET 15 BGP ( AS Path: 1103 1225 109 ) 3ffe:2400::/24 G6 15 BGP ( AS Path: 1717 786 109 ) 3ffe:2400::/24 SWITCH 20 BGP ( AS Path: 559 1717 786 109 ) 3ffe:2500::/24 SURFNET 10 BGP ( AS Path: 1103 1890 ) 3ffe:2500::/24 CICNET 15 BGP ( AS Path: 1225 1849 1890 ) 3ffe:2500::/24 G6 15 BGP ( AS Path: 1717 1103 1890 ) 3ffe:2500::/25 SWITCH 50 BGP 3ffe:2500::/32 SURFNET 10 BGP ( AS Path: 1103 1890 ) 3ffe:2500::/32 CICNET 15 BGP ( AS Path: 1225 1849 1890 ) 3ffe:2500::/32 G6 15 BGP ( AS Path: 1717 1103 1890 ) 3ffe:2600::/24 SURFNET 10 BGP ( AS Path: 1103 3274 ) 3ffe:2600::/24 CICNET 15 BGP ( AS Path: 1225 1103 3274 ) 3ffe:2600::/24 G6 15 BGP ( AS Path: 1717 1103 3274 ) From chong@mail52.mitretek.org Mon Oct 20 16:03:39 1997 From: chong@mail52.mitretek.org (Chongeun Lee) Date: Mon, 20 Oct 97 11:03:39 -0400 Subject: Some questions. Message-ID: <971020110339.9585@mail52.mitretek.org.0> My experience with cisco in that regard. The response to my request past these months for any information on their IPv6 status and product (even in alpha or beta version) has been that it would be available this fall. Yet, I see some people from this mailing list who have been using cisco's IPv6 version for quite some time. Interesting. Chongeun >At 09:07 PM 10/19/97 +0300, Martynas Buozis wrote: > >>Dear sirs, > >> > >>I have some questions and hope, that you will help me. > >> > >>1. Some time ago, as I remember, on the ticl.co.uk IPv6 Web Page > >>http://www.ipv6.ticl.co.uk/ I found a possibility to order The IPv6 > >>Resource Kit on CDROM. But when I decided to subscribe it I found, that > >>this page isn't reachable now. I was trying for one week to get on it. > >>Maybe someone can give me another address of that company - I want order > >>CD's about IPv6 and security. Maybe I am looking on wrong address or > >>company ? > >> > >>2. I wrote several times to Mr. Martin McNealis form CISCO (mail address > >>mmcnealis@cisco.com) asking for help about implementing IPv6 on CISCO > >>routers, but two months there are no answer from him. Maybe you can advice > >>someone who can help me with IPv6 on CISCO routers ? > >> > > >Join the crowd ... > >I have also tried triggering him several times. > >Although I have verbally been promised to get some Cisco ip6 images > >I have had no responses at all from three attempts to mmcnealis@cisco.com > >and a Cc: to the manager of Cisco IOS product Market also resulted in > >the sound of silence. > >It looks like Cisco has a selective market for ip6 ... :-( > >( maybe this one triggers some attention...) > > >Aad > > >> > >> > >> > >> > >quote: "If a trainstation is where the train stops, a > > busstation is where the bus stops, then a > > workstation is where......." > >================================================================== > >// Aad van der Zanden | POSTAL ADDRESS: > >// Communications Systems Division | > >// NATO C3 Agency | NATO C3 Agency > >// Email : Aad.van.der.Zanden@nc3a.nato.int | P.O. BOX 174 > >// Phone : +31 (0)70 3142440 | 2501 CD The >Hague > >// Fax : +31 (0)70 3142176 |The Netherlands > >============================================================================ > > NEW NEW H320 compliant video phone #31 070 3148107 NEW NEW NEW > >============================================================================ > > From roque@cisco.com Mon Oct 20 19:14:12 1997 From: roque@cisco.com (Pedro Marques) Date: Mon, 20 Oct 1997 11:14:12 -0700 (PDT) Subject: as1275 In-Reply-To: References: <199710190949.CAA02415@pedrom-ultra.cisco.com> Message-ID: <199710201814.LAA02685@pedrom-ultra.cisco.com> >>>>> "Guido" == JOIN Project Team writes: Guido> Hi Pedro, Guido> On Sun, 19 Oct 1997, Pedro Marques wrote: Guido> AS1275 is registered (in the RIPE db) as "DFN-IP service Guido> and DFN customer networks". We use it for our IPv6 JOIN Guido> project (it is an DFN project). There should be only one entry for as1275 in the 6bone registry. That would make figuring out the right site much easier. >> What i don't really understand is why, if all the sites share >> the same AS, aren't they all under the same prefix which can be >> cleanly annouced. And if there is a good reason why this can't >> be done then perhaps they shoulnd't be in the same AS... Guido> All IPv6 sites using AS1275 should have the same prefixes Guido> 3ffe:400::/24 or 5f04:fb00::/32. In general these are Guido> German sites like Universities. Good. Guido> For these two prefixes we do BGP route aggregation, so i Guido> wonder if you see more and/or longer prefixes *originated* Guido> at JOIN. Like i mentioned in my previous message i see close to the full routing table *originating* at as1275. Guido> These days i discussed similar problems with Guy Guido> (UUNET-UK). He also received a lot of routes which should Guido> be originated by JOIN according to his routing table. Now Guido> this seems to be the case also at your site :-( Guido> When i examine our routing table i find for all the routes Guido> (which you claim as "tons of doubtable information"), a Guido> source from which our router gets them. The important thing would be to figure out what your router annouces. Either misconfiguration or software bug, it would be nice to figure out the problem. Guido> I wonder why your routing table mentions AS1275 as Guido> originator of all these routes. We have no problems whatsoever with routes from any other sites. I pretty much doubt those path are "invented" along the way. Guido> What does "i" (IGP) as origin code mean in your routing Guido> table? It is the value of the BGP origin attribute (check rfc 1771). Guido> Does it mean that these routes are learned via Guido> RIPng at our site? The value of that attribute is set by the originator of a bgp annoucement. Guido> I believe there should be "e"'s (EGP), Guido> because we got these routes via BGP from other sites. I believe that is not too relevant at the moment. The important thing is to figure out how to solve the problem. Guido> Some of your routes specify "?" (incomplete) as source of Guido> (our?) information: when i check these routes i get Guido> "BGP-INCOMPLETE" in our routing table. That means, that Guido> this route is learned via BGP from our router, but has not Guido> a complete BGP path to the originator of the prefix - Guido> e.g. there is some RIPng or static routing inbetween. No, it doesn't mean anything close to that. Guido> I did not find a default route in our table. Maybe this Guido> route was visible at the time you examined your table - but Guido> i am quite sure that we are *not* the originator of a Guido> default route (hopefully i am right ;-) I really hate to disappoint you but that seems to me to be the most probable alternative at the moment. The others would be for the AS path you are annoucing to get truncated by one of your peers, or having someone else using your as #. Pedro. From patrikg@edu.jonkoping.se Mon Oct 20 21:45:48 1997 From: patrikg@edu.jonkoping.se (Patrik Graeser) Date: Mon, 20 Oct 1997 20:45:48 +0000 Subject: Literal addresses in URLs - 'splain to me In-Reply-To: <9710200825.AA15774@hursley.ibm.com> References: <9710181537.AA14668@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Oct 18, 97 11:37:26 am Message-ID: <199710201846.UAA09996@jkpadm.jonkoping.se> > Right, this is *exactly* what we have to decide about. > Are there any operational situations where fixing DNS *requires* > web access? > > Brian > > >- bound@zk3.dec.com said: > > > > > > >However the fact is that when there is a catastrophic operational > > >problem with DNS, there can be cases where the *only* way to > > >repair the network is by using literal addresses, either to > > >send mail to another site, or to access remote systems - > > >and URLs are one of the ways we access remote systems these days. > > >So while I stick to the deprecation of literal addresses that is > > >in RFC 1900, I regretfully feel that we need them as emergency backup. > > > > A valid point. But I don't see repairing DNS using URLs. No one is > > saying you can't use IPv6 addresses in this input. Just we don't need > > them for URLs. They work fine now with FTP, Telnet, etc.. > > > > /jim > > > In todays "way to work" a lot of admin is done using web... Some machines *require* admin to take place over web since that is the primary interface... Some just use admin over web since that is the "easy" way and they don't know enough to do otherwise! Don't flame me if I'm wrong but... In the SUN Netra I use(d to use) for primary DNS/mail exchanger the only way to make changes AND be sure they stick during the next reboot is to use the supplied web-based admin tools! Since the tools are there and a lot of administrators don't know enough to do things otherwise there should be ways to use the tools (from an location other than the console) even if the DNS is totaly gone! //Patrik Graeser ---------------------------------------------------- Chief network administrator, educational net's the IT-management unit, SBF, Jonkopings kommun E-mail (preferred): patrikg@edu.jonkoping.se ---------------------------------------------------- From roque@cisco.com Thu Oct 23 05:47:33 1997 From: roque@cisco.com (Pedro Marques) Date: Wed, 22 Oct 1997 21:47:33 -0700 (PDT) Subject: as1275 In-Reply-To: References: <199710210730.JAA03880@eekholt.NL.net> Message-ID: <199710230447.VAA03988@pedrom-ultra.cisco.com> >>>>> "Guido" == JOIN Project Team writes: Guido> Hi, Guido> i asked Herluf Hansen (Telebit) to help us solving our Guido> common serious routing problem. Herluf examined our routing Guido> tabel and configuration in detail (thanks!) and presumed Guido> that our problem is caused by our BGP4+ tunnel to SWITCH. He Guido> said that is seems that SWITCH advertises the prefixes with Guido> an empty AS path. Guido> When these prefixes are redistributed (by Guido> JOIN) 1275 is added to the AS path and that is the reason Guido> why it looks as if the prefixes belong to AS 1275. Somehow i find that explanation unprobable... (not impossible but it does seem unlikely). Switch (as559) does have one annoucement (5F04:B500::0/32) which has as second hop as1717 and as1717 doesn't show any strange behaviour. Also the data you supplied bellow seems to contradict this statement. Guido> I checked the BGP statistics to all our BGP4+ peers and only Guido> on the tunnel to SWITCH we have a huge among of AS loops Guido> (nearly every bgp msg in seems to cause a loop): When you have a loop this means that the neighbor choose as best path a path that as your AS in it... just that. For instance both switch and join have a tunnel to G6... G6 may send switch paths which include your as, if switch picks this path as best path (because you have not annouced it or because a route is going down and it hasn't receive the withdrawn from the other side) it'll annouce that path to you. BGP prevents the loop formation by rejecting that path. This is just BGP doing it's thing... But what this does show is that switch doesn't send you prefixes with an empty AS path (empty AS paths are not in loop). > BGP statistics at 1997-10-22 09:59:32, epoch is 0 days, 00:49:56 > Bgp ups: 1 > Bgp backws: 0 > Bgp upd msg in: 62074 > Bgp upd msg out: 506 > Bgp msg in: 62176 > Bgp msg out: 583 > Bgp notific in: 0 > Bgp notific out: 0 > AS loops: 61921 > Invalid Nexhops: 0 Guido> I stopped our BGP session to SWITCH for now. It didn't solve the problem... I cleared the filters in one of my sessions and i see as1275 annoucing a full bunch of routes. BGP IPv6 table version is 8215, local router id is 192.31.7.217 Status codes: * - valid, > - best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete 3FFE:301:DEC1::0/48 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:400::0/24 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:604:2::0/48 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:700:20:1::14/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 ? 3FFE:7C0:40::0/48 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:D01::4/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:DFE:1::4/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:DFE:1::8/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:DFE:1::C/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:DFE:FFFE::4/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:DFE:FFFE::8/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1300::0/24 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1400::0/24 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1500::FFFE:0:0:0/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1500::FFFE:0:0:4/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1500::FFFE:0:0:8/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1500::FFFE:0:0:C/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1500::FFFE:0:0:10/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1500::FFFE:0:0:14/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i 3FFE:1500::FFFE:0:0:1C/126 *> 3FFE:1100:0:C1B::1 FE80::60:3E59:4D90:E Tunnel20 1849 1225 1275 i [...] and so on... Guido> Please can you all check whether the problem has Guido> disappeared. Nope... It is still there... Pedro. From bmanning@ISI.EDU Thu Oct 23 14:50:17 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Thu, 23 Oct 1997 06:50:17 -0700 (PDT) Subject: No subject Message-ID: <199710231350.AA04356@zed.isi.edu> A recent (22oct97) change in maillist software has triggered a "feature" such that no mail from the list has been archived since the change. It is being worked on. -- --bill From JOIN Project Team Thu Oct 23 16:28:01 1997 From: JOIN Project Team (JOIN Project Team) Date: Thu, 23 Oct 1997 17:28:01 +0200 (MEZ) Subject: as1275 In-Reply-To: <199710230447.VAA03988@pedrom-ultra.cisco.com> Message-ID: Hi Pedro, hi 6bone folks, On Wed, 22 Oct 1997, Pedro Marques wrote: > Guido> Please can you all check whether the problem has > Guido> disappeared. > > Nope... It is still there... > > Pedro. :-( Ok. Let us test whether the reduction of our among of bgp4+ tunnels will help: I temporarily stopped all our bgp4+ sessions execept the ones to G6, CICNET and TELEBIT. Please can you check your routing tables again. If that won't help i will test strong bgp filters on all our tunnels. But first i like to know whether it is better now... All the best - Guido ------------------------------------------------------------------------------ JOIN -- IP Version 6 in the WiN Guido Wessendorf A project of DFN Westfaelische Wilhelms-Universitaet Muenster Project Team email: Universitaetsrechenzentrum join@uni-muenster.de Einsteinstrasse 60 http://www.join.uni-muenster.de D-48149 Muenster / Germany phone: +49 251 83 31639, fax: +49 251 83 31653, email: wessend@uni-muenster.de ------------------------------------------------------------------------------ From bmanning@ISI.EDU Fri Oct 24 17:53:25 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Fri, 24 Oct 1997 09:53:25 -0700 (PDT) Subject: list archives Message-ID: <199710241653.AA20168@zed.isi.edu> have been fixed. -- "Are you trying to tell us that you get up incredibly early, just to spend an hour reading news and not having any breakfast? [...] I'm aghast that any human being would ever leave the sweet arms of Morpheus, unless forced to by powers beyond his control." - Dan Sorenson From MOSTHAVM@plcman.siemens.co.uk Mon Oct 27 18:27:00 1997 From: MOSTHAVM@plcman.siemens.co.uk (Mosthav, Marc (IT Man.)) Date: Mon, 27 Oct 1997 18:27:00 -0000 Subject: DNS??? Message-ID: Hi all, I am giving up, I'm trying to set up my DNS to work but I get all sorts of strange error messages. Just as an example here is my named.hosts and the error messages. Does anybody have any ideas - I am starting to get rather desperate ;-) named.hosts: --------------------------------------------------------------- ;etc/named.hosts @ IN SOA nsv6.ipv6.siemens.co.uk ( 19971027 ; serial 12H ; refresh twice a day 15M ; retry after 15 minutes 1W ; expire after 42 days 1D ; minimum is 1 day ) IN NS nsv6.ipv6.siemens.co.uk. IN MX 5 mail.ipv6.siemens.co.uk. ; manpc900v6 IN AAAA 3ffe:1f00:0002:0001:0040:1cFF:FE60:D829 IN HINFO "Linux IPv6 test" "V2.1.59" win95v6 IN AAAA 3ffe:1f00:0002:0001::e81a:112 --------------------------------------------------------------- ERROR MESSAGES??? --------------------------------------------------------------- Oct 27 19:15:23 manpc900v6 named[708]: named.hosts: WARNING SOA expire value is less than SOA refresh+retry (0 < 2+43200) Oct 27 19:15:23 manpc900v6 named[708]: named.hosts: WARNING SOA expire value is less than refresh + 10 * retry (0 < (2 + 10 * 43200)) Oct 27 19:15:23 manpc900v6 named[708]: named.hosts: WARNING SOA expire value is less than 7 days (0) Oct 27 19:15:23 manpc900v6 named[708]: named.hosts: WARNING SOA refresh value is less than 2 * retry (2 < 43200 * 2) Oct 27 19:15:23 manpc900v6 named[708]: named.hosts:6: Database error () Oct 27 19:15:23 manpc900v6 named[708]: named.hosts:7: Database error () Oct 27 19:15:23 manpc900v6 named[708]: named.hosts: Line 8: Unknown type: ). Oct 27 19:15:23 manpc900v6 named[708]: named.hosts:8: Database error ()) Oct 27 19:15:23 manpc900v6 named[708]: master zone "ipv6.siemens.co.uk" (IN) rejected due to errors (serial 19971027) --------------------------------------------------------------- Any help would be greatly appreciated. Marc From bound@zk3.dec.com Mon Oct 27 18:25:34 1997 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 27 Oct 1997 13:25:34 -0500 Subject: Literal addresses in URLs - 'splain to me In-Reply-To: Your message of "Mon, 20 Oct 1997 20:45:48 -0000." <199710201846.UAA09996@jkpadm.jonkoping.se> Message-ID: <9710271825.AA22654@wasted.zk3.dec.com> I administer several DNS machines. I don't need WEB and when I do this I am down in the nitty gritty of this beast. Would someone state "1" task that requires WEB interface or uses a WEB interface to do "real" administration to DNS. So far all I hear is nice to have???? thanks /jim From bound@ZK3.DEC.COM Mon Oct 27 21:34:54 1997 From: bound@ZK3.DEC.COM (bound@ZK3.DEC.COM) Date: Mon, 27 Oct 1997 16:34:54 -0500 Subject: Literal addresses in URLs - 'splain to me In-Reply-To: Your message of "Mon, 27 Oct 1997 22:27:36 BST." Message-ID: <9710272134.AA05952@wasted.zk3.dec.com> Bertrand, Good response that is what I was looking to hear. As an engineer I need to hear things like this as I shut off all user interfaces when I am at work except for what UNIX gives me naturally and Netscape of course. I agree teaching them to put that in the URL box is much easier. OK I agree with Brian Carpenter now. Sorry I did not take it at face value... Bertrand has changed my mind. p.s. As a side comment seems like FTP may beccome deprecated in the user world too? /jim From dragon@dcn.soongsil.ac.kr Mon Oct 27 13:31:50 1997 From: dragon@dcn.soongsil.ac.kr (kim yong sin) Date: Mon, 27 Oct 1997 22:31:50 +0900 Subject: ipv6 web client Message-ID: <3.0.1.32.19971027223150.006acaa4@dcn.soongsil.ac.kr> DCN lab. SSU in KOREA, is implementing ipv6 in FreeBSD. Then, We hope support WEB server/client to our ipv6. Could you help? We searching web client... From dragon@dcn.soongsil.ac.kr Thu Oct 23 14:37:38 1997 From: dragon@dcn.soongsil.ac.kr (kim yong sin) Date: Thu, 23 Oct 1997 22:37:38 +0900 Subject: ipv6 web client Message-ID: <3.0.1.32.19971023223738.006b1ee4@dcn.soongsil.ac.kr> DCN lab. SSU in KOREA, is implementing ipv6 in FreeBSD. Then, We hope support WEB server/client to our ipv6. Could you help? We searching web client... From dauphin@sig.enst.fr Tue Oct 28 15:12:02 1997 From: dauphin@sig.enst.fr (Gilles Dauphin) Date: Tue, 28 Oct 1997 16:12:02 +0100 Subject: ipv6 web client Message-ID: <199710281512.QAA27433@tomcat.enst.fr> > From dragon@dcn.soongsil.ac.kr Tue Oct 28 15:58:13 1997 > > DCN lab. SSU in KOREA, is implementing ipv6 in FreeBSD. > Then, We hope support WEB server/client to our ipv6. > Could you help? > > We searching web client... Source code of ipv6 web client: ftp://sig.enst.fr/pub/multicast/mMosaic/mMosaic-3.2.0.tar.gz You need lesstif and some graphical library. you must adjust some paramters when compiling. Good Luck, Gilles From bmanning@ISI.EDU Tue Oct 28 16:05:00 1997 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Tue, 28 Oct 1997 08:05:00 -0800 (PST) Subject: How do I leave this list? In-Reply-To: <01BCE391.50780FE0.sjaumann@crcg.edu> from "Shad J. Aumann" at Oct 28, 97 11:04:50 am Message-ID: <199710281605.AA12777@zed.isi.edu> > > Try as I may, I cannot seem to stop receiving emails from "6bone@isi.edu". Can > somebody tell me how? Thanks in advance. > > Shad > > Shad J. Aumann | sjaumann@crcg.edu | > Researcher, Fraunhofer CRCG | 401-453-6363 (x209) | > 321 South Main Street | 401-453-0444 (fax) | > Providence, RI 02903 USA | http://www.crcg.edu/Staff/sjaumann.html | > Send your request to the list administrator not the list. -- --bill From RLFink@lbl.gov Thu Oct 30 01:05:24 1997 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 29 Oct 1997 17:05:24 -0800 Subject: FYI for Wash DC IETF 6bone/ngtrans scheduling Message-ID: This is to confirm two one-hour sessions for NGTRANS as follows: Tuesday, December 9 at 1300-1400 and 1415-1515 (opposite urlreg, ssh, ippcp) - Bob