From hermans@touro.edu Wed Dec 1 02:51:47 1999 From: hermans@touro.edu (Herman Strom) Date: Tue, 30 Nov 1999 21:51:47 -0500 (EST) Subject: Linux operating system kernel versions In-Reply-To: <19991123071049.A16237@itea.ntnu.no> Message-ID: Hi! Slackware 4.0 runs on 2.2.12 but it doesn't have glibc-2.1. Slackware 3.9 is a step back for 2.0 lovers it runs 2.0.36pre7 if I am not mistaken. Who else out there works with Slackware + IPv6. I need help. Where can I get some utilities and application that can run on glibc-2.1. Thanks. bye, Herm --------------------------------------- Herman Strom - Academic Computing Dept. Touro College -- Contact me via: -------------------- Check out my Personal Home Page at: email: Work Phone: 718 871-7292 Home Phone: 718 972-2173 --------------------------------------- On Tue, 23 Nov 1999, Stig Venaas wrote: Date: Tue, 23 Nov 1999 07:10:49 +0100 From: Stig Venaas To: Gregg C Levine , "'6bone@isi.edu'" <6bone@ISI.EDU> Subject: Re: Linux operating system kernel versions > On Mon, Nov 22, 1999 at 08:03:58PM -0500, Gregg C Levine wrote: The current stable Linux kernel is 2.2 (latest is 2.2.13) and has IPv6 support, 2.0.34 is really old. I haven't followed Slackware lately, but I'm surprised if the current Slackware uses 2.0. Most distributions will give you a kernel image with IPv6 disabled, so you will probably have to compile the kernel yourself, and say yes to IPv6. If you have more questions, please ask. Stig -- Stig Venaas UNINETT/NTNU From hermans@touro.edu Wed Dec 1 03:27:15 1999 From: hermans@touro.edu (Herman Strom) Date: Tue, 30 Nov 1999 22:27:15 -0500 (EST) Subject: Linux operating system kernel versions In-Reply-To: <199911231619.TAA30449@ms2.inr.ac.ru> Message-ID: Hi! Alexis, I sent this message to I don't know why didn't pick it up. Here it is again for you. ------- The Message ------ Date: Mon, 15 Nov 1999 20:25:10 -0500 (EST) From: Herman Strom To: linux-net@vger.rutgers.edu Subject: Hi! and IPv6 module situation. Hi! Everyone, Thanks to those of you who replied to help me to sign up onto this list. My name is Herman Strom. I work for Touro College located the heart of New York City. I have checked some of the topic you discuss here. They are pretty impressive. I work on a project involving IPv6 and its Linux implementation. I run it on DELL Pentium 100 system with IBM Token-Ring network adapter. I have Slackware 6.3-beta running on my box with kernel version 2.2.12 and glibc-2.1.1. I am not exactly sure how to detect bugs but this might be it. From all the documentation that I have read on IPv6, it seems like as IPv6 is self-configured. And particularly, from all Linux+IPv6 documents that I have read, I gather that as soon as IPv6 module loads, it must self-configure 'lo' device as 'inet6 addr: 0::1/128 Scope:Host' and any other network device with a link-local use address (on FE80::0/10 the link-local use network). In actuality, though when I load IPv6 module with 'insmod ipv6' command, and run 'lsmod' command, it concerns me when I see (-1) in the 'Used' column. 'lo' gets self-configured when I do 'ifconfig sit0 up'. However 'tr0' never gets self-configured. Later when I want to unload 'ipv6' module, having de-ifconfig all of the IPv6 interfaces, I find that the module is still busy. It might be a buggy interaction between 'ibmtr' and 'ipv6' modules or maybe something else. Please Comment if you can. Thanks alot. --------- END of Messasge --------------- Yes, my friend submitted it but it didn't get through for some reason. maybe you would have better luck. By the way where are you from in Russia. I am from russia too but now I live ii USA. Thanks. Have a great day. bye, Herm On Tue, 23 Nov 1999 kuznet@ms2.inr.ac.ru wrote: Date: Tue, 23 Nov 1999 19:19:52 +0300 (MSK) From: kuznet@ms2.inr.ac.ru To: Herman Strom Cc: 6bone@ISI.EDU, rzm@icm.edu.pl, hansolofalcon@worldnet.att.net Subject: Re: Linux operating system kernel versions Hello! > glibc-2.1.1. Unfortunately, IPv6 Support in 2.2.x kernel has at least > two bugs: usage counter and local-link autoconfig don't work. Please, explain. > again, the patch is old for Linux-2.1.131. And my finnish friend > doesn't have time to rewrite it. Did your friend have time to submit the patch to maintainers? If he does not, please, send it yourself in reply to this mail. Alexey Kuznetsov From Peter Tattam Wed Dec 1 08:55:49 1999 From: Peter Tattam (Peter Tattam) Date: Wed, 1 Dec 1999 19:55:49 +1100 (EST) Subject: Testing SMTP over IPv6 In-Reply-To: <199911300632.dAU6WMw65066@southstation.m5p.com> Message-ID: My mail server is now configured to receive IPv6 mail. Mail sent to *@ip6.trumpet.net should end up at our server. If you wish to test, send a message to autoreply@ip6.trumpet.net As I set it up, I came to the realization that MX will need to be set up correctly for mail to be reliable to IPv6 machines. Here is the MX list for ip6.trumpet.net ip6.trumpet.net. 43200 MX 10 louie.ip6.trumpet.net. ip6.trumpet.net. 43200 MX 15 louie.trumpet.com.au. ip6.trumpet.net. 43200 MX 20 jazz-1.trumpet.com.au. ip6.trumpet.net. 43200 MX 30 yarrina.connect.com.au. ip6.trumpet.net. 43200 MX 40 warrane.connect.com.au. If you are mixing IPv4 & IPv6 servers in the MX list, it is important that the MX list be set in the following manner... IPv6 only servers MX a .... IPv6 + IPv4 servers MX b .... IPv4 only servers MX c Where a < b < c If there is a mix of IPv4 & IPv4 MX's, there must be a dual IPv6 + IPv4 server either at the start of the list or before all the IPv4 only servers. Otherwise mail will queue indefinitely at the IPv4 servers if the IPv6 only server is down. In my example, louie.ip6.trumpet.net and louie.trumpet.com.au are the same machine. The rest are IPv4 only servers. Finally, please note that this IPv6 mail server is running over win32 using Trumpet Fanfare 1.09 and Trumpet Winsock 5.0D (beta). The setup is quite stable and operates for months at a time. The machine is a Pentium 100 with 16 megs running Win95-original. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From crawdad@fnal.gov Wed Dec 1 15:21:49 1999 From: crawdad@fnal.gov (Matt Crawford) Date: Wed, 01 Dec 1999 09:21:49 -0600 Subject: Testing SMTP over IPv6 In-Reply-To: Your message of Wed, 01 Dec 1999 19:55:49 +1100. Message-ID: <199912011521.JAA26722@gungnir.fnal.gov> > If you are mixing IPv4 & IPv6 servers in the MX list, it is important that > the MX list be set in the following manner... > > IPv6 only servers MX a > IPv6 + IPv4 servers MX b > IPv4 only servers MX c > > Where a < b < c No, this sort of ordering is only important if not all the servers can do "final delivery" (i.e., take the message out of the SMTP world). From deering@cisco.com Wed Dec 1 15:42:51 1999 From: deering@cisco.com (Steve Deering) Date: Wed, 1 Dec 1999 07:42:51 -0800 Subject: Testing SMTP over IPv6 In-Reply-To: References: Message-ID: Peter, It would be good to document this advice in an Informational RFC, either as an individual contribution or as an ngtrans submission (assuming it's correct, of course :-). Steve --------- At 7:55 PM +1100 12/1/99, Peter Tattam wrote: >As I set it up, I came to the realization that MX will need to be set up >correctly for mail to be reliable to IPv6 machines. > >Here is the MX list for ip6.trumpet.net > >ip6.trumpet.net. 43200 MX 10 louie.ip6.trumpet.net. >ip6.trumpet.net. 43200 MX 15 louie.trumpet.com.au. >ip6.trumpet.net. 43200 MX 20 jazz-1.trumpet.com.au. >ip6.trumpet.net. 43200 MX 30 yarrina.connect.com.au. >ip6.trumpet.net. 43200 MX 40 warrane.connect.com.au. > > >If you are mixing IPv4 & IPv6 servers in the MX list, it is important that >the MX list be set in the following manner... > >IPv6 only servers MX a >.... >IPv6 + IPv4 servers MX b >.... >IPv4 only servers MX c > > >Where a < b < c > >If there is a mix of IPv4 & IPv4 MX's, there must be a dual IPv6 + IPv4 server >either at the start of the list or before all the IPv4 only servers. >Otherwise mail will queue indefinitely at the IPv4 servers if the IPv6 only >server is down. > >In my example, louie.ip6.trumpet.net and louie.trumpet.com.au are the same >machine. The rest are IPv4 only servers. From kuznet@ms2.inr.ac.ru Wed Dec 1 16:30:10 1999 From: kuznet@ms2.inr.ac.ru (kuznet@ms2.inr.ac.ru) Date: Wed, 1 Dec 1999 19:30:10 +0300 (MSK) Subject: Linux operating system kernel versions In-Reply-To: from "Herman Strom" at Nov 30, 99 10:27:15 pm Message-ID: <199912011630.TAA31348@ms2.inr.ac.ru> Hello! > In actuality, though when I load IPv6 module with 'insmod ipv6' > command, and run 'lsmod' command, it concerns me when I see (-1) in > the 'Used' column. It means that IPv6 module is _not_ unloadable. You can load it once. > However 'tr0' never gets self-configured. Autoconfiguration is supported _only_ on ethernet interfaces. Nobody of folks having access to token ring took care of sending a patch to calculate eui64 tokens and to map multicast addresses for token ring. The problem is that existing specs for IPv6 over tr are _expired_ long time ago, so that implementor have to verify against any existing implementation. > Later when I want to > unload 'ipv6' module, having de-ifconfig all of the IPv6 interfaces, You choosed a strange method to deconfig IPv6 interfaces. Use ifconfig instead. > I find that the module is still busy. It is correct. IPv6 module cannot be unloaded. > Yes, my friend submitted it but it didn't get through for some reason. I did not receive any patches handling token ring for last two years. Alexey Kuznetsov From sommerfeld@orchard.arlington.ma.us Wed Dec 1 18:50:23 1999 From: sommerfeld@orchard.arlington.ma.us (Bill Sommerfeld) Date: Wed, 01 Dec 1999 13:50:23 -0500 Subject: zombie routes to 3ffe:1ce1::/32 ? Message-ID: <199912011850.SAA16557@orchard.arlington.ma.us> I'm attempting to implement some of the 6bone hardening recommendations at my site (MIT-SIPB, AS3).. While doing so, I (stupidly) tried an experiment with the use of the "no-export" community which appears to have backfired and left some of what Itojun refers to as "zombie routes" floating around. It appeared from source-routed traceroutes that the no-export-tagged route propagated further than I expected it to, so I stopped bgp and restarted it without this; however, I have reason to believe that the route is still floating around in the 6bone bgp cloud.. My understanding is that dropping the bgp connection should have caused the bgp peer to withdraw any routes it learned from me.. unfortuneately, that doesn't seem to have happened. I have reason to believe that there are currently some "zombie routes" to 3ffe:1ce1::/32 floating about as a result of this. Anyone have any advice as to what I can do from here to get the route withdrawn for real? (I'm using zebra bgp 0.80 on NetBSD+KAME). Any help would be greatly appreciated.. - Bill From sommerfeld@orchard.arlington.ma.us Wed Dec 1 21:59:55 1999 From: sommerfeld@orchard.arlington.ma.us (Bill Sommerfeld) Date: Wed, 01 Dec 1999 16:59:55 -0500 Subject: zombie routes to 3ffe:1ce1::/32 ? Message-ID: <199912012159.VAA17590@orchard.arlington.ma.us> [resent, since it didn't seem to get through the first time..] I'm attempting to implement some of the 6bone hardening recommendations at my site (MIT-SIPB, AS3).. While doing so, I (stupidly) tried an experiment with the use of the "no-export" community which appears to have backfired and left some of what Itojun refers to as "zombie routes" floating around. It appeared from source-routed traceroutes that the no-export-tagged route propagated further than I expected it to, so I stopped bgp and restarted it without this; however, I have reason to believe that the route is still floating around in the 6bone bgp cloud.. My understanding is that dropping the bgp connection should have caused the bgp peer to withdraw any routes it learned from me.. unfortuneately, that doesn't seem to have happened. I have reason to believe that there are currently some "zombie routes" to 3ffe:1ce1::/32 floating about as a result of this. Anyone have any advice as to what I can do from here to get the route withdrawn for real? (I'm using zebra bgp 0.80 on NetBSD+KAME). - Bill From hermans@touro.edu Wed Dec 1 23:23:54 1999 From: hermans@touro.edu (Herman Strom) Date: Wed, 1 Dec 1999 18:23:54 -0500 (EST) Subject: IPv6 over Token-Ring in Linux Message-ID: Hi! Does anyone know anything about configuring IPv6 over Token-Ring in Linux. Any information would be appreciated. Thanks. Bye, Herm --------------------------------------- Herman Strom - Academic Computing Dept. Touro College -- Contact me via: -------------------- Check out my Personal Home Page at: email: Work Phone: 718 871-7292 Home Phone: 718 972-2173 --------------------------------------- From peter@jazz-1.trumpet.com.au Thu Dec 2 00:54:42 1999 From: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Thu, 2 Dec 1999 11:54:42 +1100 (EST) Subject: Testing SMTP over IPv6 In-Reply-To: <199912011521.JAA26722@gungnir.fnal.gov> Message-ID: On Wed, 1 Dec 1999, Matt Crawford wrote: > > If you are mixing IPv4 & IPv6 servers in the MX list, it is important that > > the MX list be set in the following manner... > > > > IPv6 only servers MX a > > IPv6 + IPv4 servers MX b > > IPv4 only servers MX c > > > > Where a < b < c > > No, this sort of ordering is only important if not all the servers > can do "final delivery" (i.e., take the message out of the SMTP > world). > By definition, MXs that are greater than the the mininmum would not remove mail messages from the SMTP world. If they don't have v6 access, the mail will queue indefinitely, or possibly bounce if it can't reach any MX's that are lower. I am uncertain as to whether how an SMTP server would interpret an MX list that had pointers to AAAA or A6 records in them. Anyone have any ideas? Would they simply remove those names from the list resulting in truncated MX list? Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From Daniel Hagerty Thu Dec 2 01:51:27 1999 From: Daniel Hagerty (Daniel Hagerty) Date: Wed, 1 Dec 1999 20:51:27 -0500 Subject: zombie routes to 3ffe:1ce1::/32 ? In-Reply-To: <199912011850.SAA16557@orchard.arlington.ma.us> References: <199912011850.SAA16557@orchard.arlington.ma.us> Message-ID: <199912020151.UAA06070@neuralgia.linnaean.org> [ Yes, both posts you made got through. ] > It appeared from source-routed traceroutes that the no-export-tagged > route propagated further than I expected it to, so I stopped bgp and > restarted it without this; however, I have reason to believe that the > route is still floating around in the 6bone bgp cloud.. > > My understanding is that dropping the bgp connection should have > caused the bgp peer to withdraw any routes it learned from > me.. unfortuneately, that doesn't seem to have happened. An AS that forwarded that no-export tagged route across an AS boundary is broken. Since it didn't drop the annoucement on peering reset, you probably have borked BGP implentation(s) upstream from you (as opposed to a broken route-map stripping the no-export community tag). > I have reason to believe that there are currently some "zombie routes" > to 3ffe:1ce1::/32 floating about as a result of this. > > Anyone have any advice as to what I can do from here to get the route > withdrawn for real? (I'm using zebra bgp 0.80 on NetBSD+KAME). The short answer is "no" (though you might try tearing down peering for 2 * holdtime or other silliness). You have to get the broken peer to withdraw the bogus annoucement. I'm only seeing AS 10566 propagating the announcement, according to http://lookingglass.imag.fr/. What's the deal with you announcing 3ffe:1ce1::/32 ? I didn't dig deeply, bug 3ffe:1c::/24 is a merit pTLA, and MIT is delegated 3ffe:1ce1::/48 . Right now, unless you can provide a 100% up routing guarantee between merit & MIT, you can black hole traffic for prefixes outside your netblock. From sommerfeld@orchard.arlington.ma.us Thu Dec 2 01:54:39 1999 From: sommerfeld@orchard.arlington.ma.us (Bill Sommerfeld) Date: Wed, 01 Dec 1999 20:54:39 -0500 Subject: zombie routes to 3ffe:1ce1::/32 ? In-Reply-To: Message from Daniel Hagerty of "Wed, 01 Dec 1999 20:51:27 EST." <199912020151.UAA06070@neuralgia.linnaean.org> Message-ID: <199912020154.BAA18577@orchard.arlington.ma.us> > What's the deal with you announcing 3ffe:1ce1::/32 ? I didn't dig > deeply, bug 3ffe:1c::/24 is a merit pTLA, and MIT is delegated > 3ffe:1ce1::/48 . Right now, unless you can provide a 100% up routing > guarantee between merit & MIT, you can black hole traffic for prefixes > outside your netblock. Merit recently upgraded MIT from a /48 to a /32; the 6bone registry just hasn't been updated yet. - Bill From crawdad@fnal.gov Thu Dec 2 14:53:41 1999 From: crawdad@fnal.gov (Matt Crawford) Date: Thu, 02 Dec 1999 08:53:41 -0600 Subject: Testing SMTP over IPv6 In-Reply-To: Your message of Thu, 02 Dec 1999 11:54:42 +1100. Message-ID: <199912021453.IAA08390@gungnir.fnal.gov> > > > IPv6 only servers MX a > > > IPv6 + IPv4 servers MX b > > > IPv4 only servers MX c > > > > > > Where a < b < c > > > > No, this sort of ordering is only important if not all the servers > > can do "final delivery" (i.e., take the message out of the SMTP > > world). > > By definition, MXs that are greater than the the mininmum would not > remove mail messages from the SMTP world. No, not by definition. Those "non-best" MX's *need not* remove messages from SMTP, because they have somewhere "better" to send them by SMTP. But they MAY, and often DO, perform what SMTP would call "final delivery". > If they don't have v6 access, the mail will queue indefinitely, or > possibly bounce if it can't reach any MX's that are lower. *Assuming* the non-best mail exchangers can't do final delivery, this is correct. > I am uncertain as to whether how an SMTP server would interpret an > MX list that had pointers to AAAA or A6 records in them. Anyone > have any ideas? Would they simply remove those names from the list > resulting in truncated MX list? Since the MX record points to a FQDN, not an address. A pure IPv4 node would fail to get any addresses for the IPv6-only "best" MX. Here comes the big gotcha: RFC 974 (full standard STD 14) requires the seding host to try (one of) the lowest-preference MX target(s) first, but DOES NOT REQUIRE that any of the others be tried at all! Of course it's recommended that all be tried, with the words "Implementors are encouraged to". So in your example, mail could hit one of the v4-only mailers and that mailer could never attempt to connect to a dual-stack mailer and yet still be strictly compliant. True, such a mailer would still fail in some v4-only scenarios, such as when the destination host is "mx 0" for itself, but is permanently smtp-unreachable behind a firewall, with an "mx 10" relay provided. It's an ugly internet. Matt From peter@jazz-1.trumpet.com.au Fri Dec 3 03:59:56 1999 From: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Fri, 3 Dec 1999 14:59:56 +1100 (EST) Subject: Testing SMTP over IPv6 In-Reply-To: <199912021453.IAA08390@gungnir.fnal.gov> Message-ID: I stand corrected. Thanks for tha clarification. I would hazard a guess though that for at least 75% of cases the guidelines I suggested might apply. Anyone like to comment as to how sendmail will typically react in the suggested scenario? Peter On Thu, 2 Dec 1999, Matt Crawford wrote: > > > > IPv6 only servers MX a > > > > IPv6 + IPv4 servers MX b > > > > IPv4 only servers MX c > > > > > > > > Where a < b < c > > > > > > No, this sort of ordering is only important if not all the servers > > > can do "final delivery" (i.e., take the message out of the SMTP > > > world). > > > > By definition, MXs that are greater than the the mininmum would not > > remove mail messages from the SMTP world. > > No, not by definition. Those "non-best" MX's *need not* remove > messages from SMTP, because they have somewhere "better" to send them > by SMTP. But they MAY, and often DO, perform what SMTP would > call "final delivery". > > > If they don't have v6 access, the mail will queue indefinitely, or > > possibly bounce if it can't reach any MX's that are lower. > > *Assuming* the non-best mail exchangers can't do final delivery, this > is correct. > > > I am uncertain as to whether how an SMTP server would interpret an > > MX list that had pointers to AAAA or A6 records in them. Anyone > > have any ideas? Would they simply remove those names from the list > > resulting in truncated MX list? > > Since the MX record points to a FQDN, not an address. A pure IPv4 > node would fail to get any addresses for the IPv6-only "best" MX. > Here comes the big gotcha: RFC 974 (full standard STD 14) requires > the seding host to try (one of) the lowest-preference MX target(s) > first, but DOES NOT REQUIRE that any of the others be tried at all! > Of course it's recommended that all be tried, with the words > "Implementors are encouraged to". > > So in your example, mail could hit one of the v4-only mailers and > that mailer could never attempt to connect to a dual-stack mailer and > yet still be strictly compliant. True, such a mailer would still > fail in some v4-only scenarios, such as when the destination host is > "mx 0" for itself, but is permanently smtp-unreachable behind a > firewall, with an "mx 10" relay provided. > > It's an ugly internet. > > Matt > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From Latif LADID" Great Initiative Cesar! Next time invite us on time to come and support you! Have a good conference and let us know of outcome! Regards, Latif ****************************************** Latif LADID, President, IPv6 FORUM Vice President, Ericsson Telebit A/S 31, Domaine de Brameschhof L-8290 KEHLEN - LUXEMBOURG Tel: + 352 - 30 71 35 Fax: + 352 - 30 53 64 @-mail: latif.ladid@tbit.dk http://www.tbit.dk ******************** IPv6 Forum************* The New Internet: http://www.ipv6forum.com Internet For EveryOne ------ Security & Quality -------- ****************************************** UPCOMING EVENTS: -- German IPv6 Conference in Berlin, Germany Dec 8-9, run jointly by Deutsche Telekom and DFN -- GLOBAL IPvIPv6 SUMMIT in US, March 13-15, 2000 run jointly by Stardust.com and IPv6 Forum --GLOBAL IPv6 SUMMIT in UK, May 10, 2000 hosted by BT and WTC in Birmingham -- ComNet 2000 - Washington D.C.- Jan 25-27 Joint appearance: ISOC / IPv6 Forum ******************************************** -----Original Message----- From: Cesar Olvera Morales To: fink@es.net ; latif.ladid@tbit.dk ; 6bone@ISI.EDU <6bone@ISI.EDU>; ipng@sunroof.eng.sun.com ; ipv6@redes.unam.mx Cc: cesar@redes.unam.mx Date: Thursday, December 02, 1999 11:46 Subject: National IPv6 Seminar in Mexico : :The National Autonomous University of Mexico, UNAM, (6Bone pTLA :3FFE:8070::/28) are organizing the First National IPv6 Seminar in Mexico, :December 10, 1999, Mexico City. : :The main goal of this Seminar is to assist in the evolution and deployment :of IPv6 in Mexico. : :World IPv6 Community are Welcome. : :Further information: : :Cesar Olvera :Interoperability Lab :Networks Subdirection :Telecommunications Direction :DGSCA-UNAM : :(+52) 56 22 8526 : :cesar@redes.unam.mx :http://www.ipv6.unam.mx/seminario/ : : : From crawdad@fnal.gov Fri Dec 3 15:03:54 1999 From: crawdad@fnal.gov (Matt Crawford) Date: Fri, 03 Dec 1999 09:03:54 -0600 Subject: Testing SMTP over IPv6 In-Reply-To: Your message of Fri, 03 Dec 1999 14:59:56 +1100. Message-ID: <199912031503.JAA19209@gungnir.fnal.gov> > ... I would hazard a guess > though that for at least 75% of cases the guidelines I suggested might apply. Yes, or more. > Anyone like to comment as to how sendmail will typically react in > the suggested scenario? Except in pathological cases (DNS answer > 8192 bytes, pinhead admin configured "ignore truncation", or more than 100 MX records for target) sendmail will try all the mail exchangers it should. Your guidelines would then "win". Hm, except, does it need to be pointed out that > > > > > IPv6 only servers MX a > > > > > IPv6 + IPv4 servers MX b > > > > > IPv4 only servers MX c > > > > > > > > > > Where a < b < c should be c < b < a if the "final delivery" is made only on v4-only hosts? Matt From peter@jazz-1.trumpet.com.au Sat Dec 4 03:34:50 1999 From: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Sat, 4 Dec 1999 14:34:50 +1100 (EST) Subject: Testing SMTP over IPv6 In-Reply-To: <199912031503.JAA19209@gungnir.fnal.gov> Message-ID: On Fri, 3 Dec 1999, Matt Crawford wrote: > > ... I would hazard a guess > > though that for at least 75% of cases the guidelines I suggested might apply. > > Yes, or more. > > > Anyone like to comment as to how sendmail will typically react in > > the suggested scenario? > > Except in pathological cases (DNS answer > 8192 bytes, pinhead admin > configured "ignore truncation", or more than 100 MX records for > target) sendmail will try all the mail exchangers it should. Your > guidelines would then "win". Hm, except, does it need to be pointed > out that > > > > > > > IPv6 only servers MX a > > > > > > IPv6 + IPv4 servers MX b > > > > > > IPv4 only servers MX c > > > > > > > > > > > > Where a < b < c > > should be c < b < a if the "final delivery" is made only on v4-only > hosts? > Matt > Yes... if that is the intention. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From fink@es.net Mon Dec 6 23:09:28 1999 From: fink@es.net (Bob Fink) Date: Mon, 06 Dec 1999 15:09:28 -0800 Subject: 6bone Routing Guidelines I-D (HARDEN-03) cleanup for forwarding Message-ID: <4.2.2.19991206150512.00dec7e0@imap2.es.net> ngtrans/6bone folk, The following 6bone Routing Guidelines I-D (HARDEN-03) replace the current draft (HARDEN-02) that recently passed WG last call. It is essentially only a cleanup version and will be forwarded to the AD's for consideration as an Informational RFC to replace the current 6Bone Backbone Routing Guildelines (RFC2456). Thanks to Rob Rockell for all his work on this. Thanks, Bob Fink co-author and ngtrans co-chair ======================================================================== INTERNET-DRAFT R. Rockell (Sprint) Obsoletes: 2546 R. Fink (ESnet) Category: Informational 6 December 1999 6Bone Backbone Routing Guildelines Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at The list of Internet-Draft Shadow Directories can be accessed at This draft expires on 6 June 2000. Abstract The 6Bone is an Ipv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guildelines by which to deploy IPv6 routing equipment. This document provides a set of guildelines for all IPv6 routing equipment operators to use as a reference for efficient and stable deployment of IPv6 routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist. Table of Contents 1. Introduction....................................................... 2. Scope of this document............................................. 3. Common Rules....................................................... 3.1 Link-local prefixes 3.2 Site-local prefixes 3.3 Loopback and unspecified prefixes 3.4 Multicast prefixes 3.5 IPv4 compatible prefixes 3.6 IPv4-mapped prefixes 3.7 Default routes 3.8 Yet undefined unicast prefixes 3.9 Inter-site links 3.10 6to4 Prefixes 3.11 Aggregation & advertisement issues 4. Routing Policies................................................... 5. The 6Bone Registry................................................. 6. Guidelines for new sites joining the 6Bone......................... 7. Guidelines for 6Bone pTLA sites.................................... 8. 6Bone Operations group............................................. 9. Common rules enforcement........................................... 10. Security Considerations........................................... 11. References........................................................ 12. Authors' Addresses................................................ 1. Introduction The 6Bone is an IPv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guildelines by which to deploy IPv6 routing equipment. This document provides a set of guildelines for all IPv6 routing equipment operators to use as a reference for efficient and stable deployment of IPv6 routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist. This document uses BGP-4 with Multiprotocol Extensions for BGP-4 as defined [RFC 2283], commonly referred to as BGP4+, as the currently accepted EGP. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Scope of this document This document is a best-practices Informational document aimed at all entities which connect to, or interact with, the 6Bone. 3. Common Rules This section details common rules governing the routing of the 6Bone. They are derived from the issues encountered on the 6Bone, with respect to the routes advertised, handling of special addresses, and aggregation: 1) link local prefixes 2) site local prefixes 3) loopback and unspecified prefixes 4) multicast prefixes 5) IPv4-compatible prefixes 6) IPv4-mapped prefixes 7) default routes 8) yet undefined unicast prefixes (from a different /3 prefix) 9) inter-site links issues 10) 6to4 prefixes 11) aggregation & advertisement issues 3.1 Link-local prefixes This link-local prefix (FE80::/10) MUST NOT be advertised through either an IGP or an EGP. Under no circumstance should this prefix be seen in the 6Bone backbone routing table. By definition, the link-local prefix has a scope limited to a specific link. Since the prefix is the same on all IPv6 links, advertising it in any routing protocol does not make sense and, worse, may introduce nasty error conditions. Well known cases where link-local prefixes could be advertised by mistake include, but are not limited to: - a router advertising all directly connected network prefixes including the link-local one - subnetting of the link-local prefix In such cases, vendors should be urged to correct their code. While vendors should be encouraged to fix the problem, the ultimate responsibility lies on the operator of that IPv6 site to correct the problem through whatever means necessary. Should a pTLA discover link-local prefixes coming from another pTLA, it is the responsibility of the pTLA leaking the routes to filter these, and correct the problem in a timely fashion. Should a pTLA discover that a downstream of that pTLA is leaking link-local prefixes, it is the pTLA's responsibility to ensure that these prefixes are not leaked to other pTLA's, or to other downstreams of that pTLA. Failure to filter such routes in a timely fashion may result in the manual shutting down of BGP4+ sessions to that pTLA, from other pTLA's. (Also, it is each pTLA, pNLA, and end-site's responsibility to not only filter their own BGP4+ sessions appropriately to peers, but to filter routes coming from peers as well, and to only allow those routes that fit the aggregation model, and do not cause operational problems). 3.2 Site-local prefixes Site local prefixes (in the FEC0::/10 range) MAY be advertised by IGP's or EGP's within a site. The precise definition of a site is ongoing work of the IPng working group, but should generally include a group of nodes that are operating under one administrator or group of administrators, or a group of nodes which are used for a common purpose. Site-local prefixes MUST NOT be advertised across transit pNLAs, pTLAs, or leaf-sites. Again, should site-local prefixes be leaked outside of a given site, it is the responsibility of the site to fix the problem in a timely manner, either through filters, or via other means which remove the operational impact that those prefixes had on the peering sites involved. However, every site SHOULD filter not only outbound on their EGP, but also inbound, in order to ensure proper routing announcements are not only sent, but also received. 3.3 Loopback and unspecified prefixes The loopback prefix (::1/128) and the unspecified prefix (::0/128) MUST NOT be advertised by any routing protocol. The same responsibility lies with the party guilty of advertising the loopback or unspecified prefix as in Section 3.1 and 3.2. 3.4 Multicast prefixes Multicast prefixes MUST NOT be advertised by any unicast routing protocol. Multicast routing protocols are designed to respect the semantics of multicast and MUST therefore be used to route packets with multicast destination addresses (in the range of FF00::/8). Multicast address scopes MUST be respected on the 6Bone. Only global scope multicast addresses MAY be routed across transit pNLAs and pTLAs. There is no requirement on a pTLA to route multicast packets at the time of the writing of this draft. Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges) MAY be routed across a pNLA to its leaf sites. Site-local multicasts MUST NOT be routed toward transit pNLAs or pTLAs. Link-local multicasts and node-local multicasts MUST NOT be routed at all. 3.5 IPv4 compatible prefixes Sites may choose to use IPv4 compatible addresses (::a.b.c.d where a.b.c.d represents the octets of an IPv4 address) internally. As there is no real rationale today for doing so, these address SHOULD NOT be used or routed in the 6Bone. The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs. IPv4 compatible prefixes MUST NOT be advertised by EGPs to transit pNLAs or pTLAs. Should ::/96 IPv4-compatible prefixes be leaked into an EGP, it is the responsibility of the party who is advertising the route to fix the problem, either through proper filters, or through other means, while it remains in the best interest of all particiapants of the 6Bone to filter both outbound and inbound at their IGP borders. 3.6 IPv4-mapped prefixes IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d represents the octets of an IPv4 address) MAY be advertised by IGPs within a site. It may be useful for some IPv6 only nodes within a site to have such a route pointing to a translation device, to aid in deployment of IPv6. IPv4-mapped prefixes MUST NOT be advertised by EGPs. 3.7 Default routes 6Bone core pTLA routers MUST be default-free. pTLAs MAY advertise a default route to any downstream peer (non-pTLA site). Transit pNLAs MAY advertise a default route to any of their downstreams (other transit pNLA or leaf site). Should a default route be redistributed into an EGP and found on any pTLA EGP sessions, it is the responsibility of the pTLA to fix this problem immediately upon realization of the route's existence, and the responsibility of the guilty pTLA to push the entity from which the default route was originated, should the default route have originated from downstream of a pTLA. 3.8 Yet undefined unicast prefixes Yet undefined unicast prefixes from a format prefix other than 2000::/3 MUST NOT be advertised by any routing protocol in the 6Bone. In particular, RFC 2471 test addresses MUST NOT be advertised on the 6Bone. Routing of global unicast prefixes outside the 6Bone range (3ffe::/16), and routing of global unicast prefixes yet undelegated in the range (3ffe::/16) are discussed in section 4, Routing policies, below. 3.9 Inter-site links Global IPv6 addresses must be used for the end points of inter-site links. In particular, IPv4 compatible addresses MUST NOT be used for tunnels. Sites MAY use Other addressing schemes for Inter-site links, but these addresses MUST NOT be advertised into the IPv6 global routing table. Prefixes for inter-site links MUST NOT be injected in the global routing tables. 3.10 6to4 Prefixes The 6to4 prefix, or some portion thereof, MAY be announced by any pTLA which has a current implementation of 6to4 in their IPv6 network. However, as 6to4 implementors gain more operational experience, it MAY be necessary to change this in some way. At the time of the writing of this docuement, any pTLA MAY announce the 6to4 prefix into global EBGP. However, in order to announce this block, the pTLA MUST have a 6to4 router active, sourcing this prefix announcement. This section subject to change, and MAY vary, depending on 6to4 progress within the NGTRANS working group. 3.11 Aggregation & advertisement issues Route aggregation MUST be performed by any border router talking EGP with any other IPv6 sites. More-specifics MUST NOT be leaked into or across the IPv6 6Bone backbone. 4. Routing Policies Leaf sites or pNLAs MUST only advertise to an upstream provider the prefixes assigned by that provider. Advertising a prefix assigned by another provider to a provider is not acceptable, and breaks the aggregation model. A site MUST NOT advertise a prefix from another provider to a provider as a way around the multi-homing problem. However, in the interest of testing new solutions, one may break this policy, so long as ALL affected parties are aware of this test, and all agree to support this testing. These policy breaks MUST NOT affect the 6bone routing table globally. To clarify, if one has two upstream pNLA or pTLA providers, (A and B for this example), one MUST only announce the prefix delegated to one by provider A to provider A, and one MUST only announce the prefeix delegated by one from provider B upstream to provider B. There exists no circumstance where this should be violated, as it breaks the aggregation model, and could globally affect routing decisions if downstreams are able to leak other providers' more specific delegations up to a pTLA. As the IPNG working group works through the multi-homing problem, there may be a need to alter this rule slightly, to test new strategies for deployment. However, in the case of current specifications at the time of this writing, there is no reason to advertise more specifics, and pTLA's MUST adhere to the current aggregation model. Site border routers for pNLA or leaf sites MUST NOT advertise prefixes more specific (longer) than the prefix that was allocated by their upstream provider. All pTLAs MUST NOT advertise prefixes longer than a given pTLA delegation (currently /24 or /28) to other pTLAs unless special peering arrangements are implemented. When such special peering aggreements are in place between any two or more pTLAs, care MUST be taken not to leak the more specifics to other pTLAs not participating in the peering aggreement. pTLAs which have such agreements in place MUST NOT advertise other pTLA more specifics to downstream pNLAs or leaf sites, as this will break the best-path routing decision. The peering agreements across the 6Bone may be by nature non-commercial, and therefore MAY allow transit traffic, if peering agreements of this nature are made. However, no pTLA is REQUIRED to give or receive transit service from another pTLA. Eventually, the Internet registries will assign prefixes under other than the 6Bone TLA (3FFE::/16). As of the time this document was written in 1999, the Internet registries were starting to assig /35 sub-TLA (sTLA) blocks from the 2001::/16 TLA. Others will certainly be used in the future. The organizations receiving prefixes under these newer TLAs would be expected to want to establish peering and connectivity relationships with other IPv6 networks, both in the newer TLA space and in the 6bone pTLA space. Peering between new TLA's and the current 6Bone pTLA's MAY occur, and details such as transit, and what routes are received by each, are outside of general peering rules as stated in this draft, and are left up to the members of those TLA's and pTLA's that are establishing said peerings. However, it is expected that most of the rules discussed here are equally applicable to new TLAs. 5. The 6Bone Registry The 6Bone registry is a RIPE-181 database with IPv6 extensions used to store information about the 6Bone, and its sites. The 6bone is accessible at: ) Each 6Bone site MUST maintain the relevant entries in the 6Bone registry. In particular, the following object MUST be present for all 6Bone leaf sites, pNLAs and pTLAs: -IPv6-site: site description -Inet6num: prefix delegation (one record MUST exist for each delegation) -Mntner: contact info for site maintance/administration staff. Other object MAY be maintained at the discretion of the sites such as routing policy descriptors, person, or role objects. The Mntner object MUST make reference to a role or person object, but those MAY NOT necessarily reside in the 6Bone registry. They can be stored within any of the Internet registry databases (ARIN, APNIC, RIPE-NCC, etc.) 6. Guidelines for new sites joining the 6Bone New sites joining the 6Bone should seek to connect to a transit pNLA or a pTLA within their region, and preferably as close as possible to their existing IPv4 physical and routing path for Internet service. The 6Bone web site at has various information and tools to help find candidate 6bone networks. Any site connected to the 6Bone MUST maintain a DNS server for forward name lookups and reverse address lookups. The joining site MUST maintain the 6Bone objects relative to its site, as describe in section 5. The upstream provider MUST delegate the reverse address translation zone in DNS to the joining site, or have an agreement in place to perform primary DNS for that downstream. The provider MUST also create the 6Bone registry inet6num object reflecting the delegated address space. Up to date informatino about how to join the 6Bone is available on the 6Bone Web site at . 7. Guidelines for 6Bone pTLA sites The following rules apply to qualify for a 6Bone pTLA allocation. It should be recognized that holders of 6Bone pTLA allocations are expected to provide production quality backbone network services for the 6Bone. 1. The pTLA Applicant must have a minimum of three (3) months qualifying experience as a 6Bone end-site or pNLA transit. During the entire qualifying period the Applicant must be operationally providing the following: a. Fully maintained, up to date, 6Bone Registry entries for their ipv6-site inet6num, mntner, and person objects, including each tunnel that the Applicant has. b. Fully maintained, and reliable, BGP4+ peering and connectivity between the Applicant's boundary router and the appropriate connection point into the 6Bone. This router must be IPv6 pingable. This criteria is judged by members of the 6Bone Operations Group at the time of the Applicant's pTLA request. c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) entries for the Applicant's router(s) and at least one host system. d. A fully maintained, and reliable, IPv6-accessible system providing, at a mimimum, one or more web pages, describing the Applicant's IPv6 services. This server must be IPv6 pingable. 2. The pTLA Applicant MUST have the ability and intent to provide "production-quality" 6Bone backbone service. Applicants must provide a statement and information in support of this claim. This MUST include the following: a. A support staff of two persons minimum, three preferable, with person attributes registered for each in the ipv6-site object for the pTLA applicant. b. A common mailbox for support contact purposes that all support staff have acess to, pointed to with a notify attribute in the ipv6-site object for the pTLA Applicant. 3. The pTLA Applicant MUST have a potential "user community" that would be served by its becoming a pTLA, e.g., the Applicant is a major provider of Internet service in a region, country, or focus of interest. Applicant must provide a statement and information in support this claim. 4. The pTLA Applicant MUST commit to abide by the current 6Bone operational rules and policies as they exist at time of its application, and agree to abide by future 6Bone backbone operational rules and policies as they evolve by consensus of the 6Bone backbone and user community. When an Applicant seeks to receive a pTLA allocation, it will apply to the 6Bone Operations Group (see section 8 below) by providing to the Group information in support of its claims that it meets the criteria above. 8. 6Bone Operations Group The 6Bone Operations Group is the group in charge of monitoring and policing adherence to the current rules. Membership in the 6Bone Operations Group is mandatory for, and restricted to, sites connected to the 6Bone. The 6Bone Operations Group is currently defined by those members of the existing 6Bone mailing list who represent sites participating in the 6Bone. Therefore it is incumbent on relevant site contacts to join the 6Bone mailing list. Instructions on how to join the list are maintained on the 6Bone web site at < http://www.6bone.net>. 9. Common rules enforcement Participation in the 6Bone is a voluntary and benevolent undertaking. However, participating sites are expected to adhere to the rules and policies described in this document in order to maintain the 6Bone as a quality tool for the deployment of, and transition to, IPv6 protocols and the products implementing them. The following is in support of policing adherence to 6Bone rules and policies: 1. Each pTLA site has committed to implement the 6Bone's rules and policies, and SHOULD try to ensure they are adhered to by sites within their administrative control, i.e. those to who prefixes under their respective pTLA prefix have been delegated. 2. When a site detects an issue, it SHOULD first use the 6Bone registry to contact the site maintainer and work the issue. 3. If nothing happens, or there is disagreement on what the right solution is, the issue SHOULD be brought to the 6Bone Operations Group. 4. When the problem is related to a product issue, the site(s) involved SHOULD be responsible for contacting the product vendor and work toward its resolution. 5. When an issue causes major operational problems, backbone sites SHOULD decide to temporarily set filters in order to restore service. 10. Security Considerations The result of incorrect entries in routing tables is usually unreachable sites. Having guidelines to aggregate or reject routes will clean up the routing tables. It is expected that using these rules and policies, routing on the 6Bone will be less sensitive to denial of service attacks due to misleading routes. The 6Bone is an IPv6 testbed to assist in the evolution and deployment of IPv6. Therefore, denial of service or packet disclosure are to be expected. However, it is the pTLA from where the attack originated who has ultimate responsibility for isolating and fixing problems of this nature. It is also every 6Bone site's responsibility to safely introduce new test systems into the 6Bone, by placing them at a strategically safe places which will have minimal impact on other 6Bone sites, should bugs or misconfigurations occur. 11. References [RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC 2471] Hinden, R., Fink, R. and J. Postel (deceased), "IPv6 Testing Address Allocation", RFC 2471, December 1998. [RFC 2546] Durand, A., Buclin, B, "6Bone Routing Practice", RFC 2546, March 1999 [RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, March 1998. [RIPE-181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J., Karrenberg, D., Terpstra, M. and J. Yu, Representation of IP Routing Policies in a Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994. 12. Authors' Addresses Rob Rockell rrockell@sprint.net Bob Fink fink@es.net -end From yjchui@ms.chttl.com.tw Tue Dec 7 02:46:37 1999 From: yjchui@ms.chttl.com.tw (Yann-Ju Chu) Date: Tue, 07 Dec 1999 10:46:37 +0800 Subject: Whois server Message-ID: <384C750D.D5119098@ms.chttl.com.tw> Does anybody know how to get a freeware Whois server? just like the one for 6Bone -- --------------------------------- Yann-Ju Chu Telecommunication Laboratories ChungHwa Telecom Co., Ltd. TEL: +886 3 424-5681 FAX: +886 3 424-4888 http://www.chttl.com.tw --------------------------------- From dste@intranet.gr Tue Dec 7 06:46:26 1999 From: dste@intranet.gr (Dimitrios Stergiou) Date: Tue, 7 Dec 1999 08:46:26 +0200 (EET) Subject: Whois server In-Reply-To: <384C750D.D5119098@ms.chttl.com.tw> Message-ID: On Tue, 7 Dec 1999, Yann-Ju Chu wrote: > Does anybody know how to get a freeware Whois server? just like the one for 6Bone I don't know if the following is ok for you, but you can get a whois server from RIPE , at the following address: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.3.1.tar.gz This one works like a charm, but it doesn't handle IPv6 (6bone) extensions Take care, -- hermes The linuX-Files ... the source is out there ... From psb@ast.cam.ac.uk Tue Dec 7 08:57:26 1999 From: psb@ast.cam.ac.uk (Peter Bunclark) Date: Tue, 7 Dec 1999 08:57:26 +0000 (GMT) Subject: 6bone Routing Guidelines I-D (HARDEN-03) cleanup for forwarding In-Reply-To: <4.2.2.19991206150512.00dec7e0@imap2.es.net> Message-ID: On Mon, 6 Dec 1999, Bob Fink wrote: > ngtrans/6bone folk, > > The following 6bone Routing Guidelines I-D (HARDEN-03) replace the current > draft (HARDEN-02) that recently passed WG last call. It is essentially only Many of the recent ipv6-site (including mine, JANET-UCAM-ASTR) are failing to generate HTML pages; this is due at least in part because your statement: > > Up to date informatino about how to join the 6Bone is available on the > 6Bone Web site at . > Isn't true; in particular, the vital link "draft-ietf-ngtrans-6bone-registry-01.txt" goes nowhere. I'd really appreciate some accurate informatino (sic) on the precise syntax required to make 6BONE objects work! Cheers, Pete. From woeber@cc.univie.ac.at Tue Dec 7 13:18:50 1999 From: woeber@cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 07 Dec 1999 13:18:50 MET Subject: Whois server Message-ID: <009E243E.10B913B8.7@cc.univie.ac.at> Dear all, => Does anybody know how to get a freeware Whois server? just like the one for 6Bone = =I don't know if the following is ok for you, but you can get a whois =server from RIPE , at the following address: = =ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.3.1.tar.gz = =This one works like a charm, but it doesn't handle IPv6 (6bone) extensions ...it *does* support the IPv6 address registry (see below). [ Btw, alongside the most recent IETF in W/DC we've already started the effort to extend/develop the tools for a future IPv6 *routing* registry, like RPSL, tunnel definition, etc... Initially this is going to be persued in the framework of the RIPE Routing WG ] > whois -h whois.ripe.net -r at-aconet-19990920 % Rights restricted by copyright. See http://www.ripe.net/db/dbcopyright.html inet6num: 2001:0628::/35 netname: AT-ACONET-19990920 descr: ACOnet Sub-TLA block country: AT admin-c: WW144 tech-c: WW144 tech-c: WK42 tech-c: EJ63 tech-c: CP8-RIPE status: SUBTLA notify: Domain-Admin@UniVie.ac.at mnt-by: RIPE-NCC-HM-MNT mnt-lower: ACONET-LIR-MNT changed: hostmaster@ripe.net 19990920 source: RIPE In case you're looking for the 6bone specific things, David Kessens' 6bone-version is available by way of the 6Bone pages, specifically at http://www.ip.qwest.net/~david/6bone/ripe-whois-tools+6bone-extensions-latest.tar.gz Cheers, Wilfried. (RIPE DataBase WG chair) -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________ From woeber@cc.univie.ac.at Tue Dec 7 14:02:16 1999 From: woeber@cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 07 Dec 1999 14:02:16 MET Subject: 6bone Routing Guidelines I-D (HARDEN-03) cleanup for forwarding Message-ID: <009E2444.21B7C208.11@cc.univie.ac.at> => Up to date informatino about how to join the 6Bone is available on the => 6Bone Web site at . => =Isn't true; in particular, the vital link ="draft-ietf-ngtrans-6bone-registry-01.txt" goes nowhere. I'd really =appreciate some accurate informatino (sic) on the precise syntax required =to make 6BONE objects work! Puzzled.... Have you been a victim of an outdate local or cache copy? I've pulled the doc from the server only yesterday, and just re-checked, the link is working fine, although it points to http://www.ip.qwest.net/~david/6bone/draft-ietf-ngtrans-6bone-registry-02.txt ^^ But I agree, there are some loose ends, still :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Common sense requires a common language... __________________________________________________________________________ From psb@ast.cam.ac.uk Tue Dec 7 13:10:35 1999 From: psb@ast.cam.ac.uk (Peter Bunclark) Date: Tue, 7 Dec 1999 13:10:35 +0000 (GMT) Subject: 6bone Routing Guidelines I-D (HARDEN-03) cleanup for forwarding In-Reply-To: <009E2444.21B7C208.11@cc.univie.ac.at> Message-ID: On Tue, 7 Dec 1999, Wilfried Woeber, UniVie/ACOnet wrote: > Puzzled.... > Have you been a victim of an outdate local or cache copy? Go to http://www.6bone.net/ and click on ``6bone Registry Documentation'' which takes you to http://www.6bone.net/RIPE-registry.html where there's a link to http://www.es.net/pub/internet-drafts/draft-ietf-ngtrans-6bone-registry-01.txt ^^ which is non-existant. > > I've pulled the doc from the server only yesterday, and just re-checked, > the link is working fine, although it points to > > http://www.ip.qwest.net/~david/6bone/draft-ietf-ngtrans-6bone-registry-02.txt > ^^ Ah, great, I can see that document, thanks. Somebody needs to fix the broken link, though. > But I agree, there are some loose ends, still :-) > Wilfried. Thanks for your help, Pete. From fink@es.net Tue Dec 7 18:29:22 1999 From: fink@es.net (Bob Fink) Date: Tue, 07 Dec 1999 10:29:22 -0800 Subject: 6bone Routing Guidelines I-D (HARDEN-03) cleanup for forwarding In-Reply-To: References: <009E2444.21B7C208.11@cc.univie.ac.at> Message-ID: <4.2.2.19991207102555.00d26760@imap2.es.net> --=====================_102647042==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Peter, At 01:10 PM 12/7/99 +0000, Peter Bunclark wrote: >On Tue, 7 Dec 1999, Wilfried Woeber, UniVie/ACOnet wrote: > > Puzzled.... > > Have you been a victim of an outdate local or cache copy? >Go to http://www.6bone.net/ and click on ``6bone Registry Documentation'' >which takes you to http://www.6bone.net/RIPE-registry.html where there's a >link to >http://www.es.net/pub/internet-drafts/draft-ietf-ngtrans-6bone-registry-01.txt > ^^ >which is non-existant. Absolutely true... sorry about that. > > I've pulled the doc from the server only yesterday, and just re-checked, > > the link is working fine, although it points to > > > > > http://www.ip.qwest.net/~david/6bone/draft-ietf-ngtrans-6bone-registry-02.txt > > ^^ >Ah, great, I can see that document, thanks. Somebody needs to fix the >broken link, though. It's fixed. > > But I agree, there are some loose ends, still :-) > > Wilfried. Much of the user-level documentation for the registry is only minimal. I would very much appreciate suggestions of what folk think needs to be more clearly spelled out, etc. I've been planning a rewrite for a while, but haven't gotten around to it, so this is good impetus. So... keep those suggestions coming in. Thanks, Bob --=====================_102647042==_.ALT Content-Type: text/html; charset="us-ascii" Peter,

At 01:10 PM 12/7/99 +0000, Peter Bunclark wrote:

On Tue, 7 Dec 1999, Wilfried Woeber, UniVie/ACOnet wrote:
>   Puzzled....
>   Have you been a victim of an outdate local or cache copy?
Go to http://www.6bone.net/ and click on ``6bone Registry Documentation''
which takes you to http://www.6bone.net/RIPE-registry.html where there's a
link to
http://www.es.net/pub/internet-drafts/draft-ietf-ngtrans-6bone-registry-01.txt
                                                                        ^^
which is non-existant.

Absolutely true... sorry about that.


>   I've pulled the doc from the server only yesterday, and just re-checked,
>   the link is working fine, although it points to
>  
> http://www.ip.qwest.net/~david/6bone/draft-ietf-ngtrans-6bone-registry-02.txt
>                                                                        ^^
Ah, great, I can see that document, thanks.  Somebody needs to fix the
broken link, though.

It's fixed.


>   But I agree, there are some loose ends, still :-)
>   Wilfried.


Much of the user-level documentation for the registry is only minimal. I would very much appreciate suggestions of what folk think needs to be more clearly spelled out, etc. I've been planning a rewrite for a while, but haven't gotten around to it, so this is good impetus.

So... keep those suggestions coming in.


Thanks,

Bob
--=====================_102647042==_.ALT-- From Stefan.Gasteiger@Gendorf.de Wed Dec 8 13:55:45 1999 From: Stefan.Gasteiger@Gendorf.de (Stefan.Gasteiger@Gendorf.de) Date: Wed, 8 Dec 1999 14:55:45 +0100 Subject: example router config Message-ID: <31C2776E83B7D211A9600008C7337A2E01056850@atlantis.gendorf.hoechst.com> Does anyone out there know, where to find an example configuration of a Cisco router with 2 or more v6 tunnels and BGP4+ ? If using BGP do we need an official AS number? Thanks for your efforts! Regards, Stefan Gasteiger SG5599-RIPE I+K Betrieb (zertifiziert nach DIN EN ISO 9001) InfraServ Gendorf Tel.: +49 8679 7 5599 Fax: +49 8679 7 39 5599 Mobiltel.: +49 172 8649205 E-Mail: Stefan.Gasteiger@gendorf.de From rogelio_s@quickweb.com.ph Fri Dec 10 06:24:04 1999 From: rogelio_s@quickweb.com.ph (rogelio_s@quickweb.com.ph) Date: Fri, 10 Dec 1999 14:24:04 +0800 Subject: ppp 6bone Message-ID: <199912100624.OAA07031@hut.quickweb.com.ph> Can I join 6bone on a dialup connection? From aljaz@iskratel.si Fri Dec 10 07:50:52 1999 From: aljaz@iskratel.si (Aljaz Tomaz RDSI) Date: Fri, 10 Dec 1999 08:50:52 +0100 Subject: Mobility Message-ID: <7E8519F1A7C0D211B0D200A0C93AA60F3D2960@ntmail.iskratel.si> Hi all! I need some clarification in MobileIPv6 implementation. When the mobile node is connected to its home link it get IP address via adrress autoconfiguration and care-of adrress when is connected to foreign link. Here is a question. When PC boots in home link it gets its "home" IP address. Then it shuts down and moves to foreign link. On foreign link boots up and get "care-of" address via autoconfiguration. How does that "mobile" node know that this is a care-of address and not his home address. Regards, Tomaz From 1193016@student.unpar.ac.id Fri Dec 10 09:18:57 1999 From: 1193016@student.unpar.ac.id (Thomas Wahyudi) Date: Fri, 10 Dec 1999 16:18:57 +0700 (JAVT) Subject: ppp 6bone In-Reply-To: <199912100624.OAA07031@hut.quickweb.com.ph> Message-ID: On Fri, 10 Dec 1999 rogelio_s@quickweb.com.ph wrote: ] Can I join 6bone on a dialup connection? yes, you can. perharps you should try freenet6 service http://www.freenet6.net Best regard, from #### # Thomas Wahyudi UIN:535778 # # # # 1193016@student.unpar.ac.id # ## ## http://student.unpar.ac.id/~1193016 -=-=-=-=-=PARAHYANGAN UNIVERSITY=-=-=-=-=-=- From Francis.Dupont@inria.fr Fri Dec 10 09:53:08 1999 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Fri, 10 Dec 1999 10:53:08 +0100 Subject: Mobility In-Reply-To: Your message of Fri, 10 Dec 1999 08:50:52 +0100. <7E8519F1A7C0D211B0D200A0C93AA60F3D2960@ntmail.iskratel.si> Message-ID: <199912100953.KAA20056@givry.inria.fr> In your previous mail you wrote: When PC boots in home link it gets its "home" IP address. Then it shuts down and moves to foreign link. On foreign link boots up and get "care-of" address via autoconfiguration. How does that "mobile" node know that this is a care-of address and not his home address. => we discussed about this problem at the last IETF meeting in the zero-conf session. I believe there is no good way for the software to know if the node is at home or in visit (same question at a more abstrat level) without some config (for instance the home address or prefix: a simple match will be enough) or a human interaction. Then the answer is the mobile node knows because someone gives this info to it, it cannot know by itself. Regards Francis.Dupont@inria.fr PS: in order to find a home agent the mobile node needs something like the home prefix then I believe the common solution is to put the home prefix in a config file or to give it as a parameter to a management tool. From rzm@icm.edu.pl Fri Dec 10 10:23:42 1999 From: rzm@icm.edu.pl (Rafal Maszkowski) Date: Fri, 10 Dec 1999 11:23:42 +0100 Subject: ppp 6bone In-Reply-To: <199912100624.OAA07031@hut.quickweb.com.ph>; from rogelio_s@quickweb.com.ph on Fri, Dec 10, 1999 at 02:24:04PM +0800 References: <199912100624.OAA07031@hut.quickweb.com.ph> Message-ID: <19991210112342.L10262@burza.icm.edu.pl> On Fri, Dec 10, 1999 at 02:24:04PM +0800, rogelio_s@quickweb.com.ph wrote: > Can I join 6bone on a dialup connection? Recent pppd package (e.g. http://freshmeat.net/appindex/1998/04/24/893447159.html ) should work with v6. I haven't tried though. R. -- Ale kto by my³ rêce po przywitaniu siê z mê¿em? - A. Fedorczyk From fink@es.net Sat Dec 11 03:32:36 1999 From: fink@es.net (Bob Fink) Date: Fri, 10 Dec 1999 19:32:36 -0800 Subject: sunroof down until 12/14 - affects ngtrans and ipng mailing lists In-Reply-To: Message-ID: <4.2.2.19991210193032.00a36af0@imap2.es.net> --=====================_1075134==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 06:10 PM 12/10/99 -0800, Erik Nordmark wrote: >Sorry, I wasn't aware that things were going to be down that long >and it is disappearing as we speak. > >Folks are going through our labs (where sunroof sits) and upgrading >all the equipment to be y2k compliant. >Thus the routers are down etc. > >Back up on Tuesday. > >I'll see if I can get them to get sunroof accessible sooner. In the interim, many of our community are on the 6bone list, so if you need to reach either group you may find they will see a message sent to the 6bone list (it's hosted by ISI). Bob --=====================_1075134==_.ALT Content-Type: text/html; charset="us-ascii" At 06:10 PM 12/10/99 -0800, Erik Nordmark wrote:

Sorry, I wasn't aware that things were going to be down that long
and it is disappearing as we speak.

Folks are going through our labs (where sunroof sits) and upgrading
all the equipment to be y2k compliant.
Thus the routers are down etc.

Back up on Tuesday.

I'll see if I can get them to get sunroof accessible sooner.


In the interim, many of our community are on the 6bone list, so if you need to reach either group you may find they will see a message sent to the 6bone list (it's hosted by ISI).


Bob
--=====================_1075134==_.ALT-- From p.checchi@agora.it Sat Dec 11 17:59:09 1999 From: p.checchi@agora.it (Pierluigi Checchi) Date: Sat, 11 Dec 1999 18:59:09 +0100 Subject: ppp 6bone Message-ID: # Reply-to msg from owner-6bone@ISI.EDU # submitted 10-Dec-1999 10:18:57, # delivered to p.checchi@agora.it 10-Dec-1999 14:55:39, # read Sat Dec 11 09:52:23 1999: Ciao owner-6bone@ISI.EDU, > On Fri, 10 Dec 1999 rogelio_s@quickweb.com.ph wrote: > > ] Can I join 6bone on a dialup connection? > > yes, you can. > perharps you should try freenet6 service > http://www.freenet6.net > The msr NT stack is able to speak ipv6 on RAS ppp? Saluti, Pierluigi CHECCHI ----------------------------------------------------Rome city, JN61FU-- p.checchi@agora.it (main internet mailbox) ik0xfa@gw.ik0xfa.ampr.org (internet <--> packet radio gateway) pierlu@mail.omnitel.it (urgent mail, notification via GSM) http://www.checchi.net (main web site) http://www.agora.stm.it/P.Checchi/pgp (public key for pgp emails) politically incorrect random from fortune-it: Culturista, s.m.: Gay in vacanza. ----------------------------------------------------------------------- disclaimer: this message is confidential and not intended to be public. From RAYMOND-CC_TEE@Non-HP-Singapore-om9.om.hp.com Mon Dec 13 05:40:17 1999 From: RAYMOND-CC_TEE@Non-HP-Singapore-om9.om.hp.com (RAYMOND-CC_TEE@Non-HP-Singapore-om9.om.hp.com) Date: Mon, 13 Dec 1999 13:40:17 +0800 Subject: ppp 6bone Message-ID: --openmail-part-20efc6ec-00000002 Content-Type: text/plain; charset=ISO-8859-1; name="BDY.RTF" Content-Disposition: inline; filename="BDY.RTF" Content-Transfer-Encoding: quoted-printable Hi, Can I know how to configure my laptop for updial up connection to 6bone and what are the requirements. =20 Regards, Raymond Tee =2D----Original Message----- From: rogelio_s@quickweb.com.ph [mailto:rogelio_s@quickweb.com.ph] Sent: Friday, December 10, 1999 2:24 PM To: 6bone@ISI.EDU Cc: rogelio_s@quickweb.com.ph Subject: ppp 6bone Can I join 6bone on a dialup connection? --openmail-part-20efc6ec-00000002 Content-Type: application/rtf; name="BDY.RTF" Content-Disposition: attachment; filename="BDY.RTF" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJsDQp7XGYw XGZzd2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmls XGZjaGFyc2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5l dzt9fQ0Ke1xjb2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1 NTt9DQpcdWMxXHBhcmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwXGNmMCBIaSxccGFyDQpc cGFyDQpDYW4gSSBrbm93IGhvdyB0byBjb25maWd1cmUgbXkgbGFwdG9wIGZvciB1cGRpYWwg dXAgY29ubmVjdGlvbiB0byA2Ym9uZSBhbmRccGFyDQp3aGF0IGFyZSB0aGUgcmVxdWlyZW1l bnRzLiBccGFyDQpccGFyDQpccGFyDQpSZWdhcmRzLFxwYXINClJheW1vbmQgVGVlXHBhcg0K XHBhcg0KXHBhcg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS1ccGFyDQpGcm9tOiByb2dl bGlvX3NAcXVpY2t3ZWIuY29tLnBoIFttYWlsdG86cm9nZWxpb19zQHF1aWNrd2ViLmNvbS5w aF1ccGFyDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDEwLCAxOTk5IDI6MjQgUE1ccGFyDQpU bzogNmJvbmVASVNJLkVEVVxwYXINCkNjOiByb2dlbGlvX3NAcXVpY2t3ZWIuY29tLnBoXHBh cg0KU3ViamVjdDogcHBwIDZib25lXHBhcg0KXHBhcg0KXHBhcg0KQ2FuIEkgam9pbiA2Ym9u ZSBvbiAgYSBkaWFsdXAgY29ubmVjdGlvbj9ccGFyDQp9 --openmail-part-20efc6ec-00000002-- From hermans@touro.edu Tue Dec 14 01:20:16 1999 From: hermans@touro.edu (Herman Strom) Date: Mon, 13 Dec 1999 20:20:16 -0500 (EST) Subject: IPv6 over Token-Ring in Linux In-Reply-To: Message-ID: Hi! Jochen, I am running Linux-2.2.12. I aplied the patch that you've recommended. And this is what I got: [lyonb://usr/src/linux#]> patch -p1 < ../tr_ipv6.patch patching file drivers/net/ibmtr.c Hunk #1 FAILED at 1621. 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/ibmtr.c.rej patching file drivers/net/net_init.c Hunk #1 succeeded at 524 (offset 1 line). Hunk #2 FAILED at 587. Hunk #3 FAILED at 642. 2 out of 3 hunks FAILED -- saving rejects to file drivers/net/net_init.c.rej patching file include/linux/if_tr.h patch: **** malformed patch at line 59: LINUX What did I do wrong? BTW, Are you the Jochen that wrote this patch? If yes, and you want the details of the accident. I can send them to you. Thanks ahead, Bye, Herm --------------------------------------- Herman Strom - Academic Computing Dept. Touro College -- Contact me via: -------------------- Check out my Personal Home Page at: email: Work Phone: 718 871-7292 Home Phone: 718 972-2173 --------------------------------------- On Thu, 2 Dec 1999, Jochen Friedrich wrote: Date: Thu, 2 Dec 1999 11:33:31 +0100 (CET) From: Jochen Friedrich To: Herman Strom Cc: 6bone <6bone@ISI.EDU> Subject: Re: IPv6 over Token-Ring in Linux Hi Herman, > Does anyone know anything about configuring IPv6 over Token-Ring in > Linux. Any information would be appreciated. On http://www.linuxtr.net, there is a patch for 2.2.12 to allow IPv6 over Token Ring. Cheers, Jochen From tkuiper@tobit.com Wed Dec 15 08:27:10 1999 From: tkuiper@tobit.com (tkuiper@tobit.com) Date: 15 Dec 99 08:27:10 UT Subject: Tunelling with Solaris 8 <-> Linux Message-ID: <199912150827.AAA05718@tnt.isi.edu> --------------1DD2510B41FE Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I tryed to link a Solaris 8 box (with buildin IPv6) to my Linux tunnel. However its not working correctly (I see data on the interface but there is nothing coming back if I send a ping and stuff). Solaris 8 box config: $> cat /etc/hostname6.iprb0 addif 3ffe:400:380:1234::1/128 up $> cat /etc/hostname6.ip.tun0 tsrc 206.191.192.57 tdst 62.52.79.1 up $> /usr/sbin/route add -inet6 2000::/3 fe80::3e34:4f01 add net 2000::/3 $> $> cat /etc/inet/ndpd.conf if ip.tun0 AdvSendAdvertisements 1 prefix 3ffe:400:380:1234::/64 ip.tun0 Linux system script: #!/bin/sh PATH=3D/sbin:$PATH case "$1" in start) echo "Starting v6..." insmod ipv6 ifconfig eth1 add 3ffe:400:380::1 iptunnel add v6_6bone remote 128.176.191.66 mode sit ttl 64 ifconfig v6_6bone up route add -A inet6 2000::/3 dev v6_6bone iptunnel add v6_sol8 remote 206.191.192.57 mode sit ttl 64 ifconfig v6_sol8 up route add -A inet6 3ffe:400:380:1234::1 dev v6_sol8 echo 1 >/proc/sys/net/ipv4/ip_forward echo 1 >/proc/sys/net/ipv6/conf/all/forwarding ;; stop) echo -n "Stopping v6:" ifconfig v6_6bone down ifconfig v6_sol8 down ifconfig eth1 del 3ffe:400:380::1 ;; status) iptunnel /usr/inet6/bin/ping -q -c 1 -a inet6 3ffe:400:380::1 /usr/inet6/bin/ping -q -c 1 -a inet6 3ffe:400:380:1234::1 ;; *) echo "Usage: (start|stop|status)" esac what I see on this interface of data: proto src-addr src-port dest-addr dest-port size if IPV6 206.191.192.57 0 62.52.79.1 0 112 v6_sol8 The linux configuration of the tunnel works with 3 other tunnels not mentioned above. Any ideas or advices what's wrong? Gruss/Regards, Thomas Thomas Kuiper | tkuiper@tobit.com | www.tobit.com __ Core Development | TK3680-RIPE | /__/\ Tobit Software GmbH | ICQ #8345483 | ask your server. \__\/ To: ipng@sunroof.eng.sun.com 6bone@isi.edu --------------1DD2510B41FE-- From Manoj.Raizada@sisl.co.in Thu Dec 16 06:26:25 1999 From: Manoj.Raizada@sisl.co.in (Raizada Manoj) Date: Thu, 16 Dec 1999 11:56:25 +0530 Subject: Tunelling with Solaris 8 <-> Linux Message-ID: <7D29C1B86A55D3119EF400A0C9E9597638EAAE@DELG001A> Hi all I am trying to get the Linux freeware with IPV6 implementation. Could someone help me to get the source code with the installation guidelines. Thanks Manoj -----Original Message----- From: tkuiper@tobit.com [SMTP:tkuiper@tobit.com] Sent: Wednesday, December 15, 1999 1:57 PM To: 6bone@ISI.EDU Subject: Tunelling with Solaris 8 <-> Linux Hi all, I tryed to link a Solaris 8 box (with buildin IPv6) to my Linux tunnel. However its not working correctly (I see data on the interface but there is nothing coming back if I send a ping and stuff). Solaris 8 box config: $> cat /etc/hostname6.iprb0 addif 3ffe:400:380:1234::1/128 up $> cat /etc/hostname6.ip.tun0 tsrc 206.191.192.57 tdst 62.52.79.1 up $> /usr/sbin/route add -inet6 2000::/3 fe80::3e34:4f01 add net 2000::/3 $> $> cat /etc/inet/ndpd.conf if ip.tun0 AdvSendAdvertisements 1 prefix 3ffe:400:380:1234::/64 ip.tun0 Linux system script: #!/bin/sh PATH=/sbin:$PATH case "$1" in start) echo "Starting v6..." insmod ipv6 ifconfig eth1 add 3ffe:400:380::1 iptunnel add v6_6bone remote 128.176.191.66 mode sit ttl 64 ifconfig v6_6bone up route add -A inet6 2000::/3 dev v6_6bone iptunnel add v6_sol8 remote 206.191.192.57 mode sit ttl 64 ifconfig v6_sol8 up route add -A inet6 3ffe:400:380:1234::1 dev v6_sol8 echo 1 >/proc/sys/net/ipv4/ip_forward echo 1 >/proc/sys/net/ipv6/conf/all/forwarding ;; stop) echo -n "Stopping v6:" ifconfig v6_6bone down ifconfig v6_sol8 down ifconfig eth1 del 3ffe:400:380::1 ;; status) iptunnel /usr/inet6/bin/ping -q -c 1 -a inet6 3ffe:400:380::1 /usr/inet6/bin/ping -q -c 1 -a inet6 3ffe:400:380:1234::1 ;; *) echo "Usage: (start|stop|status)" esac what I see on this interface of data: proto src-addr src-port dest-addr dest-port size if IPV6 206.191.192.57 0 62.52.79.1 0 112 v6_sol8 The linux configuration of the tunnel works with 3 other tunnels not mentioned above. Any ideas or advices what's wrong? Gruss/Regards, Thomas Thomas Kuiper | tkuiper@tobit.com | www.tobit.com __ Core Development | TK3680-RIPE | /__/\ Tobit Software GmbH | ICQ #8345483 | ask your server. \__\/ To: ipng@sunroof.eng.sun.com 6bone@isi.edu From oliver.michael@gargantuan.com Mon Dec 20 05:23:00 1999 From: oliver.michael@gargantuan.com (Michael W. Oliver) Date: Mon, 20 Dec 1999 00:23:00 -0500 Subject: PPP tunnel configuration Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Has anyone successfully created a tunnel to the 6bone via PPP yet? If so, please share the process that you followed. Thanks! Michael W. Oliver Gargantuan Inter-Intranet Solutions oliver.michael@gargantuan.com http://michael.gargantuan.com/ -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQEVAwUBOF288Lb0AdLpZ89hAQGAxwf/efvbVsgNwAWLGSRMly+aw3fe/q1szLka me3auGt+zsy212NCnMjItJrsvVpLZh7tT9quVQ+rBAGMXRNt2X6eIVYEE5Ew4MEX gNRX56GlzrxEDaZiNN8RxdPHMt/ycio1RIYa5xxkxcyodlBa9hFBISBOAjHSkack 5FIgy5GcpxBY0a8b/awPgHRecABa4d8l5HinR3w7cCvFMOYUgBlwHTWWhcAy3P3T JiZk+kKsGylHT1oWoQE6YL/fUxnBO6KOC7ZzwatH2JJItBe/uiyUZ70cvAhLt/Ui mXz2s0TUIke4K/1S2k1quxGDxyuN5JgkAU/5YADQjhlcKp+kOzh/OA== =jM3i -----END PGP SIGNATURE----- From jvaarani@ees2.oulu.fi Mon Dec 20 10:22:28 1999 From: jvaarani@ees2.oulu.fi (Jarkko Vaaraniemi) Date: Mon, 20 Dec 1999 12:22:28 +0200 (EET) Subject: PPP tunnel configuration In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- On Mon, 20 Dec 1999, Michael W. Oliver wrote: >Has anyone successfully created a tunnel to the 6bone via PPP yet? I succeeded using www.freenet6.net's instructions, try them. - --- Jarkko Vääräniemi (GSM O4249999529 FAX O4O783O829) jvaarani@ee.oulu.fi http://www.ee.oulu.fi/~jvaarani OH8HQL PGP key at http://www.ee.oulu.fi/~jvaarani/pgp.asc -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOF4DadZ2s8cUbVH9AQHY6AgAhgOpXdaUMPNuyofs91bNAENIYA/TjxR4 f1IgkOossZJCQHKYpGX0Gebs7FD3+aTmcYDz3CvA2HKj99mavf08hYsJ9P2sbTTe L+GEnxNQ9IUQp/MtyUg+LfERMDCfamFXprct6tlSXgtLBEp0eiOi+3BTa7opBhUy JM003fz+WSnxEOJeoaq5vOlU887IvCJzgYMVht84DBk2FX6b9a+3JB6GvzHuPvO/ y3YANJFbtkzQz+XC5pNTOES7eVvrLEJNx0suU2/IAco5ehV5SluP9lKlYK7k/Qlm jbAVgYSxJViPIEZ1LCunbNnP5LEUZDiXU+YXZN8+dKsThMtHN9Zoiw== =lRAD -----END PGP SIGNATURE----- From oliver.michael@gargantuan.com Mon Dec 20 14:10:23 1999 From: oliver.michael@gargantuan.com (Michael W. Oliver) Date: Mon, 20 Dec 1999 09:10:23 -0500 Subject: PPP tunnel configuration Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Thanks! I have it running on an NT box over my cable modem and it works like a champ! The only downside is that I have to shutdown my software router (WinRoute Pro) to make it work :-((( Oh well.....thanks again for the tip! Michael W. Oliver oliver.michael@gargantuan.com http://michael.gargantuan.com/ - -----Original Message----- From: Jarkko Vaaraniemi [mailto:jvaarani@ees2.oulu.fi] Sent: Monday, December 20, 1999 5:22 AM To: Michael W. Oliver Cc: '6bone@isi.edu' Subject: Re: PPP tunnel configuration - -----BEGIN PGP SIGNED MESSAGE----- On Mon, 20 Dec 1999, Michael W. Oliver wrote: >Has anyone successfully created a tunnel to the 6bone via PPP yet? I succeeded using www.freenet6.net's instructions, try them. - - --- Jarkko Vääräniemi (GSM O4249999529 FAX O4O783O829) jvaarani@ee.oulu.fi http://www.ee.oulu.fi/~jvaarani OH8HQL PGP key at http://www.ee.oulu.fi/~jvaarani/pgp.asc - -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOF4DadZ2s8cUbVH9AQHY6AgAhgOpXdaUMPNuyofs91bNAENIYA/TjxR4 f1IgkOossZJCQHKYpGX0Gebs7FD3+aTmcYDz3CvA2HKj99mavf08hYsJ9P2sbTTe L+GEnxNQ9IUQp/MtyUg+LfERMDCfamFXprct6tlSXgtLBEp0eiOi+3BTa7opBhUy JM003fz+WSnxEOJeoaq5vOlU887IvCJzgYMVht84DBk2FX6b9a+3JB6GvzHuPvO/ y3YANJFbtkzQz+XC5pNTOES7eVvrLEJNx0suU2/IAco5ehV5SluP9lKlYK7k/Qlm jbAVgYSxJViPIEZ1LCunbNnP5LEUZDiXU+YXZN8+dKsThMtHN9Zoiw== =lRAD - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: 6.5.1ckt http://cyberkt.tripod.com/ Comment: KeyID: 0xE967CF61 Comment: Fingerprint: 0D35 9DB9 FA53 EA67 27FA D99B 1AC4 F13E iQEVAwUBOF44hbb0AdLpZ89hAQEsoggAgE2KVOvNtG17XjSQNHGkp+PwsWa3q0Z2 QM2DIARkRWEF3fSdemAPMqojopcDK55BYxxxtvSKDXWQp/27V7QFe3HthY7Y05Sy NnCo5lcgzZzgponT9dpcNjVIg5Ztknxp9xbBbhxzvcUDYm+UtVQpK7vKe4kFVag2 E55xaZuSZpcXqEilUMKZi1RoofMyppVCUmMk3O07HS0JnjlJ+DypVjVWg66Qb14L TRF6DZs60cb0vfPYGFaNSnc06Ll3ZoD0c/NgGVg9ibYFWouaifAxJreu4jzqNm8L 7/BiMFSWKL1RmuE0slpcIQ3Zuk3QlcOnH7YgFuG3zNDWNUyox7FY5g== =FxP5 -----END PGP SIGNATURE----- From kenken@sfc.wide.ad.jp Mon Dec 20 18:14:26 1999 From: kenken@sfc.wide.ad.jp (Kengo NAGAHASHI) Date: Tue, 21 Dec 1999 03:14:26 +0900 Subject: stla registry db issue Message-ID: <87d7s1lbst.wl@hirosue.v6.sfc.wide.ad.jp> Folks. I have some questions about stla reigstry database. In delegating IPv6 stla address for another organizations(upper than /48) from Local Internet Registry(LIR),it is need to update Regional Internet Registry(RIR)'s database.(It was defined by IPv6 policy draft of RIR) So the problem is how we should do in following situation. +----------+ |RIR X(/29)| +----+-----+ | +----+-----+ |LIR Y(/35)+ +----+-----+ | +----+------+ |NLA1 Z(/40)| NLA1 is assumed to be a kind of +--------+--+ ISP which allocates IPv6 address | for another organizations. update| orgA(/48) The goal of this figure is that organization A which was allocated by NLA1 Z can update RIR X's registry database tranceparency. The simplest way of this situation is that org A updates RIR's database directly and RIR's "mnt-lower" syntax may help it. But in just my opinion,it's not utilized IPv6 hierarchy address structure (and is not clarified who will delegate reverse DNS zone). In our current rules, org A updates LIR Y's database once and LIR Y registry will update this information to RIR X's database in hand and also LIR Y registry delegates reverse DNS zone for org A in this time.(accutual allocation will be held at 1/1/2000) In this method,it takes many human consts if 50 update queries are coming per a day. So I think it will very helpful that there is some mechanism that can make it automatically by sharing registry database or whatever. So does anybody know or experiment such situation ? Or is there any pointer to refer this matter? I think using Referral whois system is one of a solution.But I'm not expert in rwhois and never experimenced this in IPv6 hierarchy address. regards. -- Kengo Nagahashi Keio University/WIDE Project kenken@sfc.wide.ad.jp From cmj@3Com.com Mon Dec 20 18:40:03 1999 From: cmj@3Com.com (Cyndi Jung) Date: Mon, 20 Dec 1999 10:40:03 -0800 Subject: UNH test in Telluride in March Message-ID: <3.0.2.32.19991220104003.00909580@mailhost.ewd.3com.com> IPv6 implementors - The IPv6 Forum is having a series of conferences in various places around the world. The first was in Paris in October, the second one in Berlin in December, and the next one is in the US in March, and you can blame me that we are having it in Telluride, Colorado. I want very much to have a UNH test period in conjunction with the US Summit in Telluride, Colorado, March 13-15 - the test period would be March 15-17. I need to work this out with whatever testing is happening in Connect-a-thon - I need to start this NOW. Anyone that is interested should contact me via e-mail as soon as possible. I have been working with Bill Lenharth on this for a couple of months now, but I need you guys to show a measureable interest NOW - committment can come at a later date, but an initial head count for interest is a critical thing NOW - just respond to this if you even just think it could happen. Also, IPv6 has been selected as a showcase technology for the iLabs booth in the Las Vegas 2000 Networld+Interop. Perhaps this can drive the focus of the UNH testing in Telluride. Cyndi From brian@hursley.ibm.com Mon Dec 20 22:17:40 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Mon, 20 Dec 1999 16:17:40 -0600 Subject: stla registry db issue References: <87d7s1lbst.wl@hirosue.v6.sfc.wide.ad.jp> Message-ID: <385EAB04.2A6DF369@hursley.ibm.com> LIRs should **definitely** not split /35s among multiple ISPs. One /35 is for one ISP, with the whole /29 reserved for later expansion. If NLA1 Z is an ISP, it will be given the whole /35. So why will there be updates? With the hierarchical delegation model of IPv6, it is not obvious that the RIRs actually need any detail beyond who got the /35. We shouldn't blindly assume that what was done for IPv4 is needed for IPv6. Brian Kengo NAGAHASHI wrote: > > Folks. > > I have some questions about stla reigstry database. > > In delegating IPv6 stla address for another organizations(upper > than /48) from Local Internet Registry(LIR),it is need to update > Regional Internet Registry(RIR)'s database.(It was defined by > IPv6 policy draft of RIR) > > So the problem is how we should do in following situation. > +----------+ > |RIR X(/29)| > +----+-----+ > | > +----+-----+ > |LIR Y(/35)+ > +----+-----+ > | > +----+------+ > |NLA1 Z(/40)| NLA1 is assumed to be a kind of > +--------+--+ ISP which allocates IPv6 address > | for another organizations. > update| > orgA(/48) > > The goal of this figure is that organization A which was allocated > by NLA1 Z can update RIR X's registry database tranceparency. > > The simplest way of this situation is that org A updates RIR's > database directly and RIR's "mnt-lower" syntax may help it. > But in just my opinion,it's not utilized IPv6 hierarchy address > structure (and is not clarified who will delegate reverse DNS zone). > > In our current rules, org A updates LIR Y's database once > and LIR Y registry will update this information to RIR X's database > in hand and also LIR Y registry delegates reverse DNS zone for org A > in this time.(accutual allocation will be held at 1/1/2000) > In this method,it takes many human consts if 50 update queries > are coming per a day. > > So I think it will very helpful that there is some mechanism that can > make it automatically by sharing registry database or whatever. > > So does anybody know or experiment such situation ? Or is there > any pointer to refer this matter? > > I think using Referral whois system is one of a solution.But I'm not > expert in rwhois and never experimenced this in IPv6 hierarchy address. > > regards. > > -- > Kengo Nagahashi > Keio University/WIDE Project > kenken@sfc.wide.ad.jp From kazu@iijlab.net Tue Dec 21 01:58:03 1999 From: kazu@iijlab.net (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 21 Dec 1999 10:58:03 +0900 (JST) Subject: stla registry db issue In-Reply-To: <385EAB04.2A6DF369@hursley.ibm.com> References: <87d7s1lbst.wl@hirosue.v6.sfc.wide.ad.jp> <385EAB04.2A6DF369@hursley.ibm.com> Message-ID: <19991221.105803.74751139.kazu@Mew.org> From: Brian E Carpenter Subject: Re: stla registry db issue > LIRs should **definitely** not split /35s among multiple ISPs. One > /35 is for one ISP, with the whole /29 reserved for later expansion. In kenken's example, RIR is APNIC, LIR is WIDE Project, and NLA1 is a child ISP under WIDE Project. APNIC is certainly assigned /35 to one ISP, WIDE Project. It is up to WIDE Project how to use its /35 address block. Actually, when an ISP reguests sTLA, the ISP is required to explain how to use its sTLA (e.g. 5(NLA1) + 13(NLA2) in the case of WIDE Project). Or is there any consensus not to split sTLA for child ISPs? --Kazu From rrockell@sprint.net Tue Dec 21 14:46:50 1999 From: rrockell@sprint.net (Robert J. Rockell) Date: Tue, 21 Dec 1999 09:46:50 -0500 (EST) Subject: Sprint (3ffe:2900::/24) change announcement Message-ID: Sprint (3ffe:2900::/24) will be changing their Peering policy to no longer provide transit for other pTLA's. Change will be made 1/10/99 at/around midnight EST. If any pTLA has any special arrangements they would need, please contact me prior to that date, and we can work something out. The boots are not fully on yet :) All downstreams (if you get IPv6 address space from Sprint) will continue to receive full transit to all 6bone destinations. Thanks Rob Rockell Sprintlink Internet Service Center Operations Engineering 703-689-6322 1-800-724-3329, PIN 385-8833 Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne? From rrockell@sprint.net Tue Dec 21 16:00:06 1999 From: rrockell@sprint.net (Robert J. Rockell) Date: Tue, 21 Dec 1999 11:00:06 -0500 (EST) Subject: Sprint (3ffe:2900::/24) change announcement In-Reply-To: Message-ID: Oops. y2k bug in my fingers.. date of change will be Jan. 10, 2000 around midnight, EST. Thanks Rob Rockell Sprintlink Internet Service Center Operations Engineering 703-689-6322 1-800-724-3329, PIN 385-8833 Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne? On Tue, 21 Dec 1999, Robert J. Rockell wrote: ->Sprint (3ffe:2900::/24) will be changing their Peering policy to no longer ->provide transit for other pTLA's. Change will be made 1/10/99 at/around ->midnight EST. If any pTLA has any special arrangements they would need, ->please contact me prior to that date, and we can work something out. The ->boots are not fully on yet :) -> ->All downstreams (if you get IPv6 address space from Sprint) will continue to ->receive full transit to all 6bone destinations. -> ->Thanks ->Rob Rockell ->Sprintlink Internet Service Center ->Operations Engineering ->703-689-6322 ->1-800-724-3329, PIN 385-8833 ->Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne? -> From brian@hursley.ibm.com Tue Dec 21 16:02:59 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Tue, 21 Dec 1999 10:02:59 -0600 Subject: stla registry db issue References: <87d7s1lbst.wl@hirosue.v6.sfc.wide.ad.jp> <385EAB04.2A6DF369@hursley.ibm.com> <19991221.105803.74751139.kazu@Mew.org> Message-ID: <385FA4B3.A39E7C0D@hursley.ibm.com> Kazu, that is exactly what I am saying. It is a serious error to split a subTLA for subISPs. One ISP must get one subTLA. Never split a subTLA between ISPs. (The same applies to exchange points.) If you split subTLAs between ISPs, you create the IPv6 toxic waste dump. Brian "Kazu Yamamoto ($B;3K\OBI'(B)" wrote: > > From: Brian E Carpenter > Subject: Re: stla registry db issue > > > LIRs should **definitely** not split /35s among multiple ISPs. One > > /35 is for one ISP, with the whole /29 reserved for later expansion. > > In kenken's example, > RIR is APNIC, > LIR is WIDE Project, > and > NLA1 is a child ISP under WIDE Project. > > APNIC is certainly assigned /35 to one ISP, WIDE Project. It is up to > WIDE Project how to use its /35 address block. Actually, when an ISP > reguests sTLA, the ISP is required to explain how to use its sTLA > (e.g. 5(NLA1) + 13(NLA2) in the case of WIDE Project). > > Or is there any consensus not to split sTLA for child ISPs? > > --Kazu -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org Ethernet address: 00-00-AC-CF-5B-82 From Marc.Blanchet@viagenie.qc.ca Tue Dec 21 16:47:20 1999 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Tue, 21 Dec 1999 11:47:20 -0500 Subject: Sprint (3ffe:2900::/24) change announcement In-Reply-To: Message-ID: <4.2.2.19991221114633.04243710@mail.viagenie.qc.ca> At 09:46 99-12-21 -0500, Robert J. Rockell wrote: >Sprint (3ffe:2900::/24) will be changing their Peering policy to no longer >provide transit for other pTLA's. Change will be made 1/10/99 at/around 1/10/99 is what: - 1st october 1999? - 10th january 1999 - 10th january 2000 - 10th december 1999 Marc. >midnight EST. If any pTLA has any special arrangements they would need, >please contact me prior to that date, and we can work something out. The >boots are not fully on yet :) > >All downstreams (if you get IPv6 address space from Sprint) will continue to >receive full transit to all 6bone destinations. > >Thanks >Rob Rockell >Sprintlink Internet Service Center >Operations Engineering >703-689-6322 >1-800-724-3329, PIN 385-8833 >Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne? ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 2875 boul. Laurier, suite 300 | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-266-5539 Canada, G1V 2M2 | radio: VA2-JAZ ------------------------------------------------------------ Internet Engineering Standards/Normes d'ingénierie Internet http://www.normos.org ------------------------------------------------------------ From oliver.michael@gargantuan.com Mon Dec 20 05:23:00 1999 From: oliver.michael@gargantuan.com (Michael W. Oliver) Date: Mon, 20 Dec 1999 00:23:00 -0500 Subject: PPP tunnel configuration Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Has anyone successfully created a tunnel to the 6bone via PPP yet? If so, please share the process that you followed. Thanks! Michael W. Oliver Gargantuan Inter-Intranet Solutions oliver.michael@gargantuan.com http://michael.gargantuan.com/ -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQEVAwUBOF288Lb0AdLpZ89hAQGAxwf/efvbVsgNwAWLGSRMly+aw3fe/q1szLka me3auGt+zsy212NCnMjItJrsvVpLZh7tT9quVQ+rBAGMXRNt2X6eIVYEE5Ew4MEX gNRX56GlzrxEDaZiNN8RxdPHMt/ycio1RIYa5xxkxcyodlBa9hFBISBOAjHSkack 5FIgy5GcpxBY0a8b/awPgHRecABa4d8l5HinR3w7cCvFMOYUgBlwHTWWhcAy3P3T JiZk+kKsGylHT1oWoQE6YL/fUxnBO6KOC7ZzwatH2JJItBe/uiyUZ70cvAhLt/Ui mXz2s0TUIke4K/1S2k1quxGDxyuN5JgkAU/5YADQjhlcKp+kOzh/OA== =jM3i -----END PGP SIGNATURE----- From kazu@iijlab.net Wed Dec 22 02:08:15 1999 From: kazu@iijlab.net (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 22 Dec 1999 11:08:15 +0900 (JST) Subject: stla registry db issue In-Reply-To: <385FA4B3.A39E7C0D@hursley.ibm.com> References: <385EAB04.2A6DF369@hursley.ibm.com> <19991221.105803.74751139.kazu@Mew.org> <385FA4B3.A39E7C0D@hursley.ibm.com> Message-ID: <19991222.110815.41631605.kazu@Mew.org> From: Brian E Carpenter Subject: Re: stla registry db issue > Kazu, that is exactly what I am saying. It is a serious error to > split a subTLA for subISPs. One ISP must get one subTLA. Never split > a subTLA between ISPs. (The same applies to exchange points.) If > you split subTLAs between ISPs, you create the IPv6 toxic waste > dump. In my understanding, the difference between TLA and sTLA is only scale. As TLA is to be split into NLAs, sTLA is to be split into NLAs. Nobody knows what is the best component/organization for TLAs and NLAs. However, in the current Internet model, TLA is big ISPs and NLA is medium ISPs. It seems to me that your opinion is incorrect. --Kazu From oliver.michael@gargantuan.com Wed Dec 22 05:06:36 1999 From: oliver.michael@gargantuan.com (Michael W. Oliver) Date: Wed, 22 Dec 1999 00:06:36 -0500 Subject: PPP tunnel configuration Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Please disregard this post. Somehow, it has shown its face twice....... Michael W. Oliver Gargantuan Inter-Intranet Solutions oliver.michael@gargantuan.com http://michael.gargantuan.com/ - -----Original Message----- From: itojun@iijlab.net [mailto:itojun@iijlab.net] Sent: Tuesday, December 21, 1999 8:40 PM To: Michael W. Oliver Cc: '6bone@isi.edu' Subject: Re: PPP tunnel configuration >Has anyone successfully created a tunnel to the 6bone via PPP yet? >If so, please share the process that you followed. Thanks! can you state the platform you are using? itojun -----BEGIN PGP SIGNATURE----- Version: 6.5.1ckt http://cyberkt.tripod.com/ Comment: PGP Page ---> http://michael.gargantuan.com/pgp/ Comment: KeyID: 0xE967CF61 Comment: Fingerprint: 0D35 9DB9 FA53 EA67 27FA D99B 1AC4 F13E iQEVAwUBOGBcDbb0AdLpZ89hAQGPHwf/Rn+wxj+4sBug5z742CHkfhRQjgTNbj88 CmNDHimB9ISOOV/ENt6XZyK2Hn0kZMbREb6I9KpoMSw1lWGnR7o+fxde/atn+8b1 1+T6A0ORK4AzvG6TJp3kbyDM59+ltuW5L9ycVm98lnGXxqHNZRLMPrjGDLTrem4l q8JjzAV5PxGkk3eh0U9jHHnKEHuO4lJ7VPum243MO8szntZeNW/Vp7H+cvF8gISC skl9cBg93Vupk2SOsVizEPx+KqHrG4KpZBSJA6n0Jh07HrpMWkUNJMYJVSDdViWH +ekx9v9b4P6veZf68ZMsG+aeajVc+OpcSHsyBsxod47lKhSs0GXDyg== =ktPu -----END PGP SIGNATURE----- From fink@es.net Wed Dec 22 15:40:54 1999 From: fink@es.net (Bob Fink) Date: Wed, 22 Dec 1999 07:40:54 -0800 Subject: stla registry db issue In-Reply-To: <19991222.110815.41631605.kazu@Mew.org> References: <385FA4B3.A39E7C0D@hursley.ibm.com> <385EAB04.2A6DF369@hursley.ibm.com> <19991221.105803.74751139.kazu@Mew.org> <385FA4B3.A39E7C0D@hursley.ibm.com> Message-ID: <4.2.2.19991222073443.00b6fd50@imap2.es.net> At 11:08 AM 12/22/99 +0900, =?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?= wrote: >From: Brian E Carpenter >Subject: Re: stla registry db issue > > > Kazu, that is exactly what I am saying. It is a serious error to > > split a subTLA for subISPs. One ISP must get one subTLA. Never split > > a subTLA between ISPs. (The same applies to exchange points.) If > > you split subTLAs between ISPs, you create the IPv6 toxic waste > > dump. > >In my understanding, the difference between TLA and sTLA is only >scale. As TLA is to be split into NLAs, sTLA is to be split into NLAs. > >Nobody knows what is the best component/organization for TLAs and >NLAs. However, in the current Internet model, TLA is big ISPs and NLA >is medium ISPs. > >It seems to me that your opinion is incorrect. In looking at the mail on this it seems that there is a confusion between you folk over what splitting the subTLA means, and you both have it right, but think the other is not understanding you. The /35 subTLA assigned by the RIR is intended to be split up to the right of the /35 (i.e., in the NLA space) for use by lower level providers, but not to the left of the /35 (as this is part of the extended subTLA field the RIR is holding back for future use, unspecified for now). Bob From kazu@iijlab.net Wed Dec 22 16:00:12 1999 From: kazu@iijlab.net (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 23 Dec 1999 01:00:12 +0900 (JST) Subject: stla registry db issue In-Reply-To: <4.2.2.19991222073443.00b6fd50@imap2.es.net> References: <385FA4B3.A39E7C0D@hursley.ibm.com> <19991222.110815.41631605.kazu@Mew.org> <4.2.2.19991222073443.00b6fd50@imap2.es.net> Message-ID: <19991223.010012.74748698.kazu@Mew.org> From: Bob Fink Subject: Re: stla registry db issue > In looking at the mail on this it seems that there is a confusion between > you folk over what splitting the subTLA means, and you both have it right, > but think the other is not understanding you. The /35 subTLA assigned by > the RIR is intended to be split up to the right of the /35 (i.e., in the > NLA space) for use by lower level providers, but not to the left of the /35 > (as this is part of the extended subTLA field the RIR is holding back for > future use, unspecified for now). Both kenken and I have never ever talked the reserved space (29-35). We are just talikng about the NLA space(36-48). The original message is as follows: --- So the problem is how we should do in following situation. +----------+ |RIR X(/29)| +----+-----+ | +----+-----+ |LIR Y(/35)+ +----+-----+ | +----+------+ |NLA1 Z(/40)| NLA1 is assumed to be a kind of +--------+--+ ISP which allocates IPv6 address | for another organizations. update| orgA(/48) The goal of this figure is that organization A which was allocated by NLA1 Z can update RIR X's registry database tranceparency. --- Which part is unclear? --Kazu From brian@hursley.ibm.com Wed Dec 22 17:21:51 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Wed, 22 Dec 1999 11:21:51 -0600 Subject: stla registry db issue References: <385FA4B3.A39E7C0D@hursley.ibm.com> <385EAB04.2A6DF369@hursley.ibm.com> <19991221.105803.74751139.kazu@Mew.org> <385FA4B3.A39E7C0D@hursley.ibm.com> <4.2.2.19991222073443.00b6fd50@imap2.es.net> Message-ID: <386108AF.E70A1FCC@hursley.ibm.com> Well, here is the key text from RFC 2374. (there is no reason it should be different in subTLA space): ...It is recommended that organizations assigning NLA address space use "slow start" allocation procedures similar to [RFC2050]. The design of an NLA ID allocation plan is a tradeoff between routing aggregation efficiency and flexibility. Creating hierarchies allows for greater amount of aggregation and results in smaller routing tables. Flat NLA ID assignment provides for easier allocation and attachment flexibility, but results in larger routing tables. My concern is that the way Kazu asked his question, with the concern about frequent updates, did not seem compatible with the idea of slow start and hierarchical aggregation. If we don't start with habits that create aggressive aggregation, IPv6 routing will be in deep trouble as it grows. I also have a concern that if an operator is really an ISP, giving them an NLA instead of a subTLA may be a problem until we have proved how to do convenient renumbering. What happens when they want to migrate away from using WIDE as their aggregator? (I realise that this is a heretical thought, since the current rules on subTLAs are more restrictive.) However, I agree that Kazu is not describing a strict violation of the RFCs. Brian Bob Fink wrote: > > At 11:08 AM 12/22/99 +0900, =?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?= wrote: > >From: Brian E Carpenter > >Subject: Re: stla registry db issue > > > > > Kazu, that is exactly what I am saying. It is a serious error to > > > split a subTLA for subISPs. One ISP must get one subTLA. Never split > > > a subTLA between ISPs. (The same applies to exchange points.) If > > > you split subTLAs between ISPs, you create the IPv6 toxic waste > > > dump. > > > >In my understanding, the difference between TLA and sTLA is only > >scale. As TLA is to be split into NLAs, sTLA is to be split into NLAs. > > > >Nobody knows what is the best component/organization for TLAs and > >NLAs. However, in the current Internet model, TLA is big ISPs and NLA > >is medium ISPs. > > > >It seems to me that your opinion is incorrect. > > In looking at the mail on this it seems that there is a confusion between > you folk over what splitting the subTLA means, and you both have it right, > but think the other is not understanding you. The /35 subTLA assigned by > the RIR is intended to be split up to the right of the /35 (i.e., in the > NLA space) for use by lower level providers, but not to the left of the /35 > (as this is part of the extended subTLA field the RIR is holding back for > future use, unspecified for now). > > Bob From fink@es.net Wed Dec 22 19:27:27 1999 From: fink@es.net (Bob Fink) Date: Wed, 22 Dec 1999 11:27:27 -0800 Subject: stla registry db issue In-Reply-To: <386108AF.E70A1FCC@hursley.ibm.com> References: <385FA4B3.A39E7C0D@hursley.ibm.com> <385EAB04.2A6DF369@hursley.ibm.com> <19991221.105803.74751139.kazu@Mew.org> <385FA4B3.A39E7C0D@hursley.ibm.com> <4.2.2.19991222073443.00b6fd50@imap2.es.net> Message-ID: <4.2.2.19991222111858.00a67f00@imap2.es.net> --=====================_185895261==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Brian, At 11:21 AM 12/22/99 -0600, Brian E Carpenter wrote: >Well, here is the key text from RFC 2374. (there is no reason it should >be different in subTLA space): > > ...It is recommended that > organizations assigning NLA address space use "slow start" allocation > procedures similar to [RFC2050]. > > The design of an NLA ID allocation plan is a tradeoff between routing > aggregation efficiency and flexibility. Creating hierarchies allows > for greater amount of aggregation and results in smaller routing > tables. Flat NLA ID assignment provides for easier allocation and > attachment flexibility, but results in larger routing tables. > >My concern is that the way Kazu asked his question, with the concern about >frequent updates, did not seem compatible with the idea of slow start and >hierarchical aggregation. If we don't start with habits that create aggressive >aggregation, IPv6 routing will be in deep trouble as it grows. > >I also have a concern that if an operator is really an ISP, giving them an >NLA instead of a subTLA may be a problem until we have proved how to do >convenient renumbering. What happens when they want to migrate away from >using >WIDE as their aggregator? (I realise that this is a heretical thought, since >the current rules on subTLAs are more restrictive.) > >However, I agree that Kazu is not describing a strict violation of the RFCs. Sorry I misinterpreted your concern, but at least it is clear to me now. I've never discouraged anyone from trying to hand out intermediate transit NLAs between the subTLA (or pTLA) holder and the end-user site (/48), and I think what the WIDE folk are doing is just fine. Thanks, Bob --=====================_185895261==_.ALT Content-Type: text/html; charset="us-ascii" Brian,

At 11:21 AM 12/22/99 -0600, Brian E Carpenter wrote:
Well, here is the key text from RFC 2374. (there is no reason it should
be different in subTLA space):

   ...It is recommended that
   organizations assigning NLA address space use "slow start" allocation
   procedures similar to [RFC2050].

   The design of an NLA ID allocation plan is a tradeoff between routing
   aggregation efficiency and flexibility.  Creating hierarchies allows
   for greater amount of aggregation and results in smaller routing
   tables.  Flat NLA ID assignment provides for easier allocation and
   attachment flexibility, but results in larger routing tables.

My concern is that the way Kazu asked his question, with the concern about
frequent updates, did not seem compatible with the idea of slow start and
hierarchical aggregation. If we don't start with habits that create aggressive
aggregation, IPv6 routing will be in deep trouble as it grows.

I also have a concern that if an operator is really an ISP, giving them an
NLA instead of a subTLA may be a problem until we have proved how to do
convenient renumbering. What happens when they want to migrate away from using
WIDE as their aggregator? (I realise that this is a heretical thought, since
the current rules on subTLAs are more restrictive.)

However, I agree that Kazu is not describing a strict violation of the RFCs.

Sorry I misinterpreted your concern, but at least it is clear to me now.

I've never discouraged anyone from trying to hand out intermediate transit NLAs between the subTLA (or pTLA) holder and the end-user site (/48), and I think what the WIDE folk are doing is just fine.


Thanks,

Bob
--=====================_185895261==_.ALT-- From brian@hursley.ibm.com Wed Dec 22 20:24:18 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Wed, 22 Dec 1999 14:24:18 -0600 Subject: stla registry db issue References: <385FA4B3.A39E7C0D@hursley.ibm.com> <385EAB04.2A6DF369@hursley.ibm.com> <19991221.105803.74751139.kazu@Mew.org> <385FA4B3.A39E7C0D@hursley.ibm.com> <4.2.2.19991222073443.00b6fd50@imap2.es.net> <4.2.2.19991222111858.00a67f00@imap2.es.net> Message-ID: <38613372.6E08370C@hursley.ibm.com> OK, as long as we never see anything longer than a /29 from the outside, of course. That is what matters. Brian Bob Fink wrote: > > Brian, > > At 11:21 AM 12/22/99 -0600, Brian E Carpenter wrote: > > > Well, here is the key text from RFC 2374. (there is no reason it should > > be different in subTLA space): > > > > ...It is recommended that > > organizations assigning NLA address space use "slow start" allocation > > procedures similar to [RFC2050]. > > > > The design of an NLA ID allocation plan is a tradeoff between routing > > aggregation efficiency and flexibility. Creating hierarchies allows > > for greater amount of aggregation and results in smaller routing > > tables. Flat NLA ID assignment provides for easier allocation and > > attachment flexibility, but results in larger routing tables. > > > > My concern is that the way Kazu asked his question, with the concern about > > frequent updates, did not seem compatible with the idea of slow start and > > hierarchical aggregation. If we don't start with habits that create aggressive > > aggregation, IPv6 routing will be in deep trouble as it grows. > > > > I also have a concern that if an operator is really an ISP, giving them an > > NLA instead of a subTLA may be a problem until we have proved how to do > > convenient renumbering. What happens when they want to migrate away from using > > WIDE as their aggregator? (I realise that this is a heretical thought, since > > the current rules on subTLAs are more restrictive.) > > > > However, I agree that Kazu is not describing a strict violation of the RFCs. > > Sorry I misinterpreted your concern, but at least it is clear to me now. > > I've never discouraged anyone from trying to hand out intermediate transit NLAs between the subTLA (or pTLA) holder and the > end-user site (/48), and I think what the WIDE folk are doing is just fine. > > Thanks, > > Bob -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org Ethernet address: 00-00-AC-CF-5B-82 From dlitz@cheerful.com Wed Dec 22 23:13:31 1999 From: dlitz@cheerful.com (Dwayne C . Litzenberger) Date: Wed, 22 Dec 1999 17:13:31 -0600 Subject: ppp 6bone In-Reply-To: ; from 1193016@student.unpar.ac.id on Fri, Dec 10, 1999 at 04:18:57PM +0700 References: <199912100624.OAA07031@hut.quickweb.com.ph> Message-ID: <19991222171331.B5697@dlitz.dyn.dhs.org> --kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Fri, Dec 10, 1999 at 04:18:57PM +0700, Thomas Wahyudi wrote: > On Fri, 10 Dec 1999 rogelio_s@quickweb.com.ph wrote: >=20 > ] Can I join 6bone on a dialup connection? >=20 > yes, you can. > perharps you should try freenet6 service > http://www.freenet6.net >=20 What about people like me who have their home network on a dialup connection? I could really use the standard 64-bit address space.=20 --=20 "I already have all the latest software." -- Laura Winslow, "Family Matters" Dwayne C. Litzenberger - dlitz@cheerful.com Please always Cc to me when replying to me on the lists. Advertising Policy: http://www.redrival.com/dlitz/spamoff.html GnuPG Public Key: http://www.redrival.com/dlitz/gpgkey.asc Fingerprint: 0535 F7CF FF5F 8547 E5A5 695E 4456 FB6C BC39 A4B0 --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEAREBAAYFAjhhWxsACgkQRFb7bLw5pLCtQgCglp9L3exN4zerWYHcZ/voM3mp y/QAn1BDbrpS5v1s/zyA9pjW1rvwYbLc =4hMj -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R-- From dlitz@cheerful.com Wed Dec 22 23:15:26 1999 From: dlitz@cheerful.com (Dwayne C . Litzenberger) Date: Wed, 22 Dec 1999 17:15:26 -0600 Subject: IPv6 over Token-Ring in Linux In-Reply-To: ; from hermans@touro.edu on Mon, Dec 13, 1999 at 08:20:16PM -0500 References: Message-ID: <19991222171526.C5697@dlitz.dyn.dhs.org> --8X7/QrJGcKSMr1RN Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable [snip] > [lyonb://usr/src/linux#]> patch -p1 < ../tr_ipv6.patch > patching file drivers/net/ibmtr.c > Hunk #1 FAILED at 1621. > 1 out of 1 hunk FAILED -- saving rejects to file > drivers/net/ibmtr.c.rej > patching file drivers/net/net_init.c > Hunk #1 succeeded at 524 (offset 1 line). > Hunk #2 FAILED at 587. > Hunk #3 FAILED at 642. > 2 out of 3 hunks FAILED -- saving rejects to file > drivers/net/net_init.c.rej > patching file include/linux/if_tr.h > patch: **** malformed patch at line 59: LINUX >=20 > What did I do wrong? [snip] Sometimes it's as easy as using a fuzz of 3 or 4. (eg patch -F 3 ) --=20 "I already have all the latest software." -- Laura Winslow, "Family Matters" Dwayne C. Litzenberger - dlitz@cheerful.com Please always Cc to me when replying to me on the lists. Advertising Policy: http://www.redrival.com/dlitz/spamoff.html GnuPG Public Key: http://www.redrival.com/dlitz/gpgkey.asc Fingerprint: 0535 F7CF FF5F 8547 E5A5 695E 4456 FB6C BC39 A4B0 --8X7/QrJGcKSMr1RN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEAREBAAYFAjhhW44ACgkQRFb7bLw5pLDSwwCghuS5OiZbXVqkdHvfAPnmwZjk spUAoInNj5ivVf34uJtdWZ54V7B6DJWE =ZgHF -----END PGP SIGNATURE----- --8X7/QrJGcKSMr1RN-- From kazu@iijlab.net Thu Dec 23 01:32:03 1999 From: kazu@iijlab.net (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 23 Dec 1999 10:32:03 +0900 (JST) Subject: stla registry db issue In-Reply-To: <386108AF.E70A1FCC@hursley.ibm.com> References: <385FA4B3.A39E7C0D@hursley.ibm.com> <4.2.2.19991222073443.00b6fd50@imap2.es.net> <386108AF.E70A1FCC@hursley.ibm.com> Message-ID: <19991223.103203.74749188.kazu@Mew.org> From: Brian E Carpenter Subject: Re: stla registry db issue > My concern is that the way Kazu asked his question, with the concern > about frequent updates, did not seem compatible with the idea of > slow start and hierarchical aggregation. If we don't start with > habits that create aggressive aggregation, IPv6 routing will be in > deep trouble as it grows. We never discuss routing problems. We are talking about issues on registry DB updates. > I also have a concern that if an operator is really an ISP, giving > them an NLA instead of a subTLA may be a problem until we have > proved how to do convenient renumbering. What happens when they want > to migrate away from using WIDE as their aggregator? (I realise that > this is a heretical thought, since the current rules on subTLAs are > more restrictive.) This is also out of the scope of kenken's question. Kenken asked how to eat an apple. You said it is not an orange. > However, I agree that Kazu is not describing a strict violation of > the RFCs. I don't see *any* violation. Our activities are consistent to all RFCs, I believe. --Kazu From kazu@iijlab.net Thu Dec 23 02:00:52 1999 From: kazu@iijlab.net (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 23 Dec 1999 11:00:52 +0900 (JST) Subject: registry DB issues Message-ID: <19991223.110052.41633972.kazu@Mew.org> ----Next_Part(Thu_Dec_23_11:00:52_1999_535)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think it is a good time to explain what's going on between APNIC and JPNIC. I will explain it with a JPNIC hat. Some countries has a NIR under a RIR. For example, there is JPNIC in Japan, which is a sub registry under APNIC. In such country, *IPv4* address space is allocated as follows: (1) IPv4 address block is deligated to the NIR by the RIR. (2) An ISP requests IPv4 address block to the NIR. (3) The NIR assigns a portion of the IPv4 address block to the ISP. (4) The ISP assigns some IPv4 addresss to its customers. (5) The ISP updates customer information on NIR DB. (6) The NIR configures DNS reverse lookup according to the information. For IPv6, there are many differences. (a) The RIR has IPv6 sTLA block and its DB. (b) An ISP requests a sTLA to the RIR. (c) RIR assigns a sTLA to the ISP and RIR configures DNS reverse lookup (/35) to ISP's DNS server. (d) The ISP has responsibility to update RIR DB. Also, it is up to ISP to configure DNS reverse lookup for its customers. So, our current question is what roles NIR should play in this model? Kenken's plan is as follows: (i) Prepare NIR DB. (ii) ISPs updates NIR DB. (iii) The NIR syncs its DB with RIR DB. Currently, this is a tough job, at least for JPNIC. So, WIDE Project decided to do research on this for JPNIC. P.S. As far as (b) is concerned, JPNIC is preparing agency service. For more information, see an attached message. --Kazu ----Next_Part(Thu_Dec_23_11:00:52_1999_535)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Received: from mgi.iij.ad.jp (mgi.iij.ad.jp [192.168.2.5]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA28007 for ; Mon, 13 Dec 1999 12:58:28 +0900 (JST) Received: from sh1.iijlab.net (sh1.iijlab.net [202.232.15.98]) by mgi.iij.ad.jp (8.8.8/MGI2.0) with ESMTP id MAA17251 for ; Mon, 13 Dec 1999 12:58:28 +0900 (JST) Received: from msgmgr.nic.ad.jp (msgmgr.nic.ad.jp [202.12.30.226]) by sh1.iijlab.net (8.9.1+3.1W/3.7W) with ESMTP id MAA12755 for ; Mon, 13 Dec 1999 12:57:20 +0900 (JST) Received: (from majordom@localhost) by msgmgr.nic.ad.jp (8.9.3+3.1W/3.7W/JPNIC-msgmgr.def,v-99091900/smtpfeed 0.92) id MAA16386 for ip-v6-out; Mon, 13 Dec 1999 12:58:27 +0900 (JST) (envelope-from owner-ip-v6) Received: from spool.nic.ad.jp (spool.nic.ad.jp [192.168.10.252]) by msgmgr.nic.ad.jp (8.9.3+3.1W/3.7W/JPNIC-msgmgr.def,v-99091900) with ESMTP id MAA16381 for ; Mon, 13 Dec 1999 12:58:26 +0900 (JST) (envelope-from owner-ip-v6@msgmgr.nic.ad.jp) Received: from mx1.nic.ad.jp (mx1.nic.ad.jp [202.12.30.137]) by spool.nic.ad.jp (8.9.3+3.1W/3.7W/JPNIC-spool.def,v-1.7-1999111822) with ESMTP id MAA03604; Mon, 13 Dec 1999 12:58:23 +0900 (JST) (envelope-from owner-nir-discuss@whois.apnic.net) Received: from whois.apnic.net (whois1.apnic.net [203.37.255.98]) by mx1.nic.ad.jp (8.9.3+3.1W/3.7W/JPNIC-relay.def,v-99111822) with ESMTP id MAA19475; Mon, 13 Dec 1999 12:57:15 +0900 (JST) (envelope-from owner-nir-discuss@whois.apnic.net) Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id NAA86217; Mon, 13 Dec 1999 13:54:02 +1000 (EST) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id NAA86203 for ; Mon, 13 Dec 1999 13:53:58 +1000 (EST) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id MAA25502 for ; Mon, 13 Dec 1999 12:53:56 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA27381 for ; Mon, 13 Dec 1999 12:53:56 +0900 (JST) Received: from Mew.org (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id MAA22061 for ; Mon, 13 Dec 1999 12:53:56 +0900 (JST) Date: Mon, 13 Dec 1999 12:54:53 +0900 (JST) Message-Id: <19991213.125453.112542885.kazu@Mew.org> To: nir-discuss@ns.apnic.net Subject: [JPNIC ip-v6 170] the entire procedure From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b11 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ip-v6@nic.ad.jp Precedence: bulk Reply-To: ip-v6@nic.ad.jp X-UIDL: 1772b9ad327dfa95d5aa7022d823aa47 Here is the entire picture of the JPNIC service for sTLA. If you have comments, please speak up right now. (0) JPNIC prepares a web page which is a modification version of APNIC's one. Also, JPNIC prepares some documents on the service. (1) A sTLA applicant of JPNIC member (say an ISP hereafter) first obtains a APNIC NIC handle from APNIC. (2) The ISP fills the web then press the submit button. An email will be sent to the ISP according to the email address in the form. The intention here is authentication of email reachability. (3) When the ISP receives the email, the ISP checks out the form. If there are no errors, the ISP sends the form to JPNIC by email. (4) When JPNIC receives the email from the ISP, JPNIC sees whether or not the form is sent by JPNIC members. If so, JPNIC forwards the form to APNIC. (5) APNIC may want to ask some questions to the ISP. In this case, APNIC sends them to JPNIC. JPNIC then relays questions/answers between APNIC and the ISP. (6) APNIC assigns one sTLA to the ISP then tells APNIC. JPNIC relays the notification to the ISP. (7) JPNIC requests payment for the ISP. (8) The ISP pays the fee. (9) JPNIC pays 245.76 USD into APNIC account. --Kazu ----Next_Part(Thu_Dec_23_11:00:52_1999_535)---- From woeber@cc.univie.ac.at Thu Dec 23 11:19:44 1999 From: woeber@cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 23 Dec 1999 11:19:44 MET Subject: stla registry db issue Message-ID: <009E30C0.13AFC614.1@cc.univie.ac.at> >OK, as long as we never see anything longer than a /29 from the outside, of course. >That is what matters. > > Brian Brian, so what are we supposed to do with the /35 sTLA allocations that the RIRs dish out for permanent (as opposed to 6bone) addresses? Puzzled. Regards, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________ From fink@es.net Thu Dec 23 17:35:24 1999 From: fink@es.net (Bob Fink) Date: Thu, 23 Dec 1999 09:35:24 -0800 Subject: registry DB issues In-Reply-To: <19991223.110052.41633972.kazu@Mew.org> Message-ID: <4.2.2.19991223093201.00c6d930@imap2.es.net> Kazu, I have looked over your (JPNIC) plans for how, as a national registry, to interact with APNIC for IPv6 allocation to your cusomers. I think it is a good plan, and makes logical sense. I hope that other national registries can so similar things around the world. Thanks, Bob At 11:00 AM 12/23/99 +0900, =?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?= wrote: >I think it is a good time to explain what's going on between APNIC and >JPNIC. I will explain it with a JPNIC hat. > >Some countries has a NIR under a RIR. For example, there is JPNIC in >Japan, which is a sub registry under APNIC. > >In such country, *IPv4* address space is allocated as follows: > >(1) IPv4 address block is deligated to the NIR by the RIR. >(2) An ISP requests IPv4 address block to the NIR. >(3) The NIR assigns a portion of the IPv4 address block to the ISP. >(4) The ISP assigns some IPv4 addresss to its customers. >(5) The ISP updates customer information on NIR DB. >(6) The NIR configures DNS reverse lookup according to the information. > >For IPv6, there are many differences. > >(a) The RIR has IPv6 sTLA block and its DB. >(b) An ISP requests a sTLA to the RIR. >(c) RIR assigns a sTLA to the ISP and RIR configures DNS reverse > lookup (/35) to ISP's DNS server. >(d) The ISP has responsibility to update RIR DB. Also, it is up to ISP > to configure DNS reverse lookup for its customers. > >So, our current question is what roles NIR should play in this model? > >Kenken's plan is as follows: > >(i) Prepare NIR DB. >(ii) ISPs updates NIR DB. >(iii) The NIR syncs its DB with RIR DB. > >Currently, this is a tough job, at least for JPNIC. So, WIDE Project >decided to do research on this for JPNIC. > >P.S. > >As far as (b) is concerned, JPNIC is preparing agency service. For more >information, see an attached message. > >--Kazu > >Date: Mon, 13 Dec 1999 12:54:53 +0900 (JST) >To: nir-discuss@ns.apnic.net >Subject: [JPNIC ip-v6 170] the entire procedure >From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) > > >Here is the entire picture of the JPNIC service for sTLA. If you have >comments, please speak up right now. > >(0) JPNIC prepares a web page which is a modification version of > APNIC's one. Also, JPNIC prepares some documents on the service. > >(1) A sTLA applicant of JPNIC member (say an ISP hereafter) first > obtains a APNIC NIC handle from APNIC. > >(2) The ISP fills the web then press the submit button. An email will > be sent to the ISP according to the email address in the form. > > The intention here is authentication of email reachability. > >(3) When the ISP receives the email, the ISP checks out the form. If > there are no errors, the ISP sends the form to JPNIC by email. > >(4) When JPNIC receives the email from the ISP, JPNIC sees whether or > not the form is sent by JPNIC members. If so, JPNIC forwards the > form to APNIC. > >(5) APNIC may want to ask some questions to the ISP. In this case, > APNIC sends them to JPNIC. JPNIC then relays questions/answers > between APNIC and the ISP. > >(6) APNIC assigns one sTLA to the ISP then tells APNIC. JPNIC relays > the notification to the ISP. > >(7) JPNIC requests payment for the ISP. > >(8) The ISP pays the fee. > >(9) JPNIC pays 245.76 USD into APNIC account. > >--Kazu From brian@hursley.ibm.com Thu Dec 23 22:33:12 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 23 Dec 1999 16:33:12 -0600 Subject: stla registry db issue References: <009E30C0.13AFC614.1@cc.univie.ac.at> Message-ID: <3862A328.1F943814@hursley.ibm.com> "Wilfried Woeber, UniVie/ACOnet" wrote: > > >OK, as long as we never see anything longer than a /29 from the outside, of course. > >That is what matters. > > > > Brian > > Brian, > > so what are we supposed to do with the /35 sTLA allocations that > the RIRs dish out for permanent (as opposed to 6bone) addresses? The RIR policy is to reserve the whole /29 for expansion of the /35. They promised never to allocate parts of the same /29 to more than one user. Therefore, the /35 can be announced simply by announcing the whole /29 that contains it. There will never be anyone else in that /29, so there is no need to announce the longer prefix. We must establish this principle solidly now, so that we **never** see holes punched in /29s. Brian From brian@hursley.ibm.com Thu Dec 23 22:37:06 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 23 Dec 1999 16:37:06 -0600 Subject: stla registry db issue References: <385FA4B3.A39E7C0D@hursley.ibm.com> <4.2.2.19991222073443.00b6fd50@imap2.es.net> <386108AF.E70A1FCC@hursley.ibm.com> <19991223.103203.74749188.kazu@Mew.org> Message-ID: <3862A412.8D982364@hursley.ibm.com> "Kazu Yamamoto ($B;3K\OBI'(B)" wrote: > > From: Brian E Carpenter > Subject: Re: stla registry db issue > > > My concern is that the way Kazu asked his question, with the concern > > about frequent updates, did not seem compatible with the idea of > > slow start and hierarchical aggregation. If we don't start with > > habits that create aggressive aggregation, IPv6 routing will be in > > deep trouble as it grows. > > We never discuss routing problems. We are talking about issues on > registry DB updates. I know. My worry is that any errors in allocation policy will damage aggregation in the routing tables, which as IPv4 proves is impossible to fix later. > > > I also have a concern that if an operator is really an ISP, giving > > them an NLA instead of a subTLA may be a problem until we have > > proved how to do convenient renumbering. What happens when they want > > to migrate away from using WIDE as their aggregator? (I realise that > > this is a heretical thought, since the current rules on subTLAs are > > more restrictive.) > > This is also out of the scope of kenken's question. > > Kenken asked how to eat an apple. You said it is not an orange. Yes, I was confused. > > > However, I agree that Kazu is not describing a strict violation of > > the RFCs. > > I don't see *any* violation. Our activities are consistent to all > RFCs, I believe. I agree. Brian From bmanning@ISI.EDU Fri Dec 24 00:48:00 1999 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 23 Dec 1999 16:48:00 -0800 (PST) Subject: stla registry db issue In-Reply-To: <3862A328.1F943814@hursley.ibm.com> from "Brian E Carpenter" at Dec 23, 99 04:33:12 pm Message-ID: <199912240048.QAA21438@zephyr.isi.edu> % > so what are we supposed to do with the /35 sTLA allocations that % > the RIRs dish out for permanent (as opposed to 6bone) addresses? % % The RIR policy is to reserve the whole /29 for expansion of the /35. % They promised never to allocate parts of the same /29 to more than % one user. % % Therefore, the /35 can be announced simply by announcing the whole /29 % that contains it. There will never be anyone else in that /29, so there % is no need to announce the longer prefix. % % We must establish this principle solidly now, so that we **never** see % holes punched in /29s. % % Brian This has its own set of problems. See the current discussion on micro-allocations inside ARIN. In IPv4 parlence, it seems a tremendous waste of space to delegate a /19 for a site that will never have more than a few hosts yet will be multiply homed. What I see here is the same argument, a /29 for a small set of nodes that will -never- meet the growth prospects for numbers of end-nodes. Historically this was also the case for IPv4 and its design, pre-subnetting. It became clear that there would not be a small number of networks with millions of nodes. Hence the initial subnettting model (class A/B/C) and the CIDR refinements. Is it just me or are we failing to learn from history here? This looks like a small number of networks with order(n) number of end-systems... all over again. --bill From peter@jazz-1.trumpet.com.au Fri Dec 24 03:35:43 1999 From: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Fri, 24 Dec 1999 14:35:43 +1100 (EST) Subject: stla registry db issue In-Reply-To: <199912240048.QAA21438@zephyr.isi.edu> Message-ID: On Thu, 23 Dec 1999, Bill Manning wrote: > % > so what are we supposed to do with the /35 sTLA allocations that > % > the RIRs dish out for permanent (as opposed to 6bone) addresses? > % > % The RIR policy is to reserve the whole /29 for expansion of the /35. > % They promised never to allocate parts of the same /29 to more than > % one user. > % > % Therefore, the /35 can be announced simply by announcing the whole /29 > % that contains it. There will never be anyone else in that /29, so there > % is no need to announce the longer prefix. > % > % We must establish this principle solidly now, so that we **never** see > % holes punched in /29s. > % > % Brian > > This has its own set of problems. See the current discussion > on micro-allocations inside ARIN. In IPv4 parlence, it seems > a tremendous waste of space to delegate a /19 for a site that > will never have more than a few hosts yet will be multiply > homed. What I see here is the same argument, a /29 for a small > set of nodes that will -never- meet the growth prospects for > numbers of end-nodes. Historically this was also the case for > IPv4 and its design, pre-subnetting. It became clear that > there would not be a small number of networks with millions of > nodes. Hence the initial subnettting model (class A/B/C) and > the CIDR refinements. > Is it just me or are we failing to learn from history here? > This looks like a small number of networks with order(n) number > of end-systems... all over again. > > --bill > A micro allocation in V6 is quite a bit different to V4 in that the basic /64 unit should cater for virtually unlimited numbers of hosts. Allowing a small number of bits for subnetting & routing would be all that's needed, so I would suggest anything between /48 & /64 would be more than adequate. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From bmanning@ISI.EDU Fri Dec 24 04:02:35 1999 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 23 Dec 1999 20:02:35 -0800 (PST) Subject: stla registry db issue In-Reply-To: from "Peter Tattam" at Dec 24, 99 02:35:43 pm Message-ID: <199912240402.UAA01583@zephyr.isi.edu> % > % > so what are we supposed to do with the /35 sTLA allocations that % > % > the RIRs dish out for permanent (as opposed to 6bone) addresses? % > % % > % The RIR policy is to reserve the whole /29 for expansion of the /35. % > % They promised never to allocate parts of the same /29 to more than % > % one user. % > % % > % Therefore, the /35 can be announced simply by announcing the whole /29 % > % that contains it. There will never be anyone else in that /29, so there % > % is no need to announce the longer prefix. % > % % > % We must establish this principle solidly now, so that we **never** see % > % holes punched in /29s. % > % % > % Brian % > % > This has its own set of problems. See the current discussion % > on micro-allocations inside ARIN. In IPv4 parlence, it seems % > a tremendous waste of space to delegate a /19 for a site that % > will never have more than a few hosts yet will be multiply % > ..... % > Is it just me or are we failing to learn from history here? % > This looks like a small number of networks with order(n) number % > of end-systems... all over again. % > % > --bill % > % % A micro allocation in V6 is quite a bit different to V4 in that the basic /64 % unit should cater for virtually unlimited numbers of hosts. Allowing a small % number of bits for subnetting & routing would be all that's needed, so I would % suggest anything between /48 & /64 would be more than adequate. % % Peter Er, that is pretty much exactly the point I was trying to make. If Brian is right and that group is successful in restricting announcements to /29's, how much space is wasted for the sixty nodes that form the cluster "www.bigco.com" that has connections to 20 major ISPs? -- --bill From lambert@psc.edu Fri Dec 24 14:31:17 1999 From: lambert@psc.edu (Michael H. Lambert) Date: Fri, 24 Dec 1999 09:31:17 -0500 (EST) Subject: stla registry db issue In-Reply-To: <199912240402.UAA01583@zephyr.isi.edu> Message-ID: On Thu, 23 Dec 1999, Bill Manning wrote: > > Er, that is pretty much exactly the point I was trying to make. > If Brian is right and that group is successful in restricting > announcements to /29's, how much space is wasted for the sixty > nodes that form the cluster "www.bigco.com" that has connections > to 20 major ISPs? But is "bigco.com" a transit IPv6 provider? My understanding is that if it isn't, it should never be allocated its own TLA. It should receive a small block from each of its ISPs. Or am I missing something? Michael +----------------------------------------------------------------------------+ | Michael H. Lambert, Network Engineer Phone: +1 412 268-4960 | | Pittsburgh Supercomputing Center FAX: +1 412 268-8200 | | 4400 Fifth Avenue, Pittsburgh, PA 15213 lambert@psc.edu | +----------------------------------------------------------------------------+ From bmanning@ISI.EDU Fri Dec 24 15:54:03 1999 From: bmanning@ISI.EDU (Bill Manning) Date: Fri, 24 Dec 1999 07:54:03 -0800 (PST) Subject: stla registry db issue In-Reply-To: from "Michael H. Lambert" at Dec 24, 99 09:31:17 am Message-ID: <199912241554.HAA03307@zephyr.isi.edu> % % On Thu, 23 Dec 1999, Bill Manning wrote: % > % > Er, that is pretty much exactly the point I was trying to make. % > If Brian is right and that group is successful in restricting % > announcements to /29's, how much space is wasted for the sixty % > nodes that form the cluster "www.bigco.com" that has connections % > to 20 major ISPs? % % But is "bigco.com" a transit IPv6 provider? My understanding is that if % it isn't, it should never be allocated its own TLA. It should receive a % small block from each of its ISPs. Or am I missing something? % % Michael Nope, its not. But it has -lots- of cash and is willing to do whatever it takes. Same as today for folks dealing w/ the micro-allocation issue. They don't want to get a small block from each of their providers and run virtual interfaces, they want a canonical name/number mapping. e.g. www.bigco.com is always reachable at 127.127.0.127. -- --bill From perry@piermont.com Sat Dec 25 19:26:59 1999 From: perry@piermont.com (Perry E. Metzger) Date: 25 Dec 1999 14:26:59 -0500 Subject: stla registry db issue In-Reply-To: "Michael H. Lambert"'s message of "Fri, 24 Dec 1999 09:31:17 -0500 (EST)" References: Message-ID: <87k8m2izy4.fsf@snark.piermont.com> "Michael H. Lambert" writes: > On Thu, 23 Dec 1999, Bill Manning wrote: > > > > Er, that is pretty much exactly the point I was trying to make. > > If Brian is right and that group is successful in restricting > > announcements to /29's, how much space is wasted for the sixty > > nodes that form the cluster "www.bigco.com" that has connections > > to 20 major ISPs? > > But is "bigco.com" a transit IPv6 provider? My understanding is that if > it isn't, it should never be allocated its own TLA. It should receive a > small block from each of its ISPs. Or am I missing something? Anyone out there who thinks they can actually prevent GM or Yahoo or the like from getting their own routes announced should talk to an anti-trust lawyer. Perry From snaraya2@Bayou.UH.EDU Tue Dec 28 03:38:15 1999 From: snaraya2@Bayou.UH.EDU (Shiva Narayanaswamy) Date: Mon, 27 Dec 1999 21:38:15 -0600 Subject: No subject Message-ID: <02cf01bf50e4$f96514a0$a8030781@phys.uh.edu> This is a multi-part message in MIME format. ------=_NextPart_000_02CC_01BF50B2.AEBB6260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I am a graduate student in Houston, about to begin work on some = aspect of IPv6. I am currently involved in Literary Survey, and am yet = to narrow down mu problem statement. I have narrowed it down to doing = some work on routing aspects of 4 to 6 transition, especially concerned = with Automatic Tunneling. I would be obliged if someone on the list = could guide me furthur with some current problems in this area which are = yet to be solved. Please add a cc to my address snaraya2@bayou.uh.edu while replying = to the mail. Thanks a lot in advance. Shiva ------=_NextPart_000_02CC_01BF50B2.AEBB6260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
    I am a graduate = student in=20 Houston, about to begin work on some aspect of IPv6. I am currently = involved in=20 Literary Survey, and am yet to narrow down mu problem statement. I have = narrowed=20 it down to doing some work on routing aspects of 4 to 6 transition, = especially=20 concerned with Automatic Tunneling. I would be obliged if someone on the = list=20 could guide me furthur with some current problems in this area which are = yet to=20 be solved.
    Please add a cc to = my address snaraya2@bayou.uh.edu while = replying to=20 the mail. Thanks a lot in advance.
 
Shiva
------=_NextPart_000_02CC_01BF50B2.AEBB6260-- From brian@hursley.ibm.com Tue Dec 28 17:51:15 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Tue, 28 Dec 1999 11:51:15 -0600 Subject: prefix lengths [was Re: stla registry db issue] References: <87k8m2izy4.fsf@snark.piermont.com> Message-ID: <3868F893.DC849329@hursley.ibm.com> Folks, 2**64 is a big number. It's the square of 2**32 if nobody noticed. The majority of BigCos will be able to understand this and use no more than an SLA. If there are a few idiot CIOs who insist on more for no good reason, it isn't the end of the world. I am very relaxed about /29s being reserved at this stage of the life of IPv6, because 2**29 is also a big number. I'm not recommending any change in the RIR guideline of only allocating /35s; all I'm doing is saying that we must stick to the rule of not splitting /29s between ISPs. If BigCo is 20-homed, and doesn't want to deal with 20 prefixes, then I can certainly see a case for them leasing a prefix that can be in the default-free table. But this really will be the exception case. What we must do is ensure that a 2-homed site can easily deal with 2 prefixes. BTW, how many 6bone sites are multihomed today? Brian "Perry E. Metzger" wrote: > > "Michael H. Lambert" writes: > > On Thu, 23 Dec 1999, Bill Manning wrote: > > > > > > Er, that is pretty much exactly the point I was trying to make. > > > If Brian is right and that group is successful in restricting > > > announcements to /29's, how much space is wasted for the sixty > > > nodes that form the cluster "www.bigco.com" that has connections > > > to 20 major ISPs? > > > > But is "bigco.com" a transit IPv6 provider? My understanding is that if > > it isn't, it should never be allocated its own TLA. It should receive a > > small block from each of its ISPs. Or am I missing something? > > Anyone out there who thinks they can actually prevent GM or Yahoo or > the like from getting their own routes announced should talk to an > anti-trust lawyer. > > Perry -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org From cmk@6bone.ipv6.net.edu.cn Thu Dec 30 03:00:36 1999 From: cmk@6bone.ipv6.net.edu.cn (Maoke Chen) Date: Thu, 30 Dec 1999 11:00:36 +0800 (CST) Subject: Sprint (3ffe:2900::/24) change announcement In-Reply-To: Message-ID: <199912300300.LAA09753@6bone.ipv6.net.edu.cn> Robert, Happy New Year at first! About your policy changing, Could I ask you for keeping our backup peer? (i.e. that one between 202.38.99.1 and 208.19.223.204. Thanks and Best Wishes, Maoke