From ksbn@kt.co.kr Mon Nov 1 05:45:47 1999 From: ksbn@kt.co.kr (ksb) Date: Mon, 01 Nov 1999 14:45:47 +0900 Subject: IPv6 frame Message-ID: <381D290B.6E8A500E@kt.co.kr> How are you? I make the IPv6 address plan for my company. Should I follow the IETF RFC to make IPv6 address plan. By IPv6 address plan, Should I save 64bits for cutomer ID ? I think it is a non-sense. Can I change the 64bits for cutomer ID, 56bits, 48bits ?. If you have any advice, send me it Thanks. ksb -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- From ksbn@kt.co.kr Mon Nov 1 06:26:00 1999 From: ksbn@kt.co.kr (ksb) Date: Mon, 01 Nov 1999 15:26:00 +0900 Subject: (6bone-jp 1006) IPv6 frame References: <22653.941435855@coconut.itojun.org> Message-ID: <381D3278.AD76F43E@kt.co.kr> Then how about NLA, SLA? Can I decide NLA1, NLA2 and SLA by myself? Are there some more rules ? Thnaks in advance. ksb itojun@iijlab.net wrote: > >I make the IPv6 address plan for my company. > >Should I follow the IETF RFC to make IPv6 address plan. > >By IPv6 address plan, Should I save 64bits for cutomer > >ID ? > > Yes, as long as you use RFC2373 addressing architecture (which is > required for hooking your box to worldwide IPv6 network) > If you do not obey it, you will not be able to use IPv6 autoconfig on > most of the implementations. > > itojun -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- From ksbn@kt.co.kr Mon Nov 1 06:46:44 1999 From: ksbn@kt.co.kr (ksb) Date: Mon, 01 Nov 1999 15:46:44 +0900 Subject: (6bone-jp 1006) IPv6 frame References: <23130.941437733@coconut.itojun.org> Message-ID: <381D3754.9391D515@kt.co.kr> I'm sorry for you to make misunderstand. I got sTLA from APNIC.(sTLA 2001:220::/35) Now I should the addressing plan for the sTLA. Korea Telecom is biggest company in Korea. So maybe some ISPs hope get the KT sTLA. My plan is ------------------------------------------ NLA1 Res NLA2 SLA Interface ------------------------------------------ I hope that SLA is given Organizations or Univs. NLA2 is given for projects. NLA1 is given for ISPs. Is this pland resonable? I hope to know your advice about IPv6 address plan, Thanks ksb itojun@iijlab.net wrote: > >Then how about NLA, SLA? > >Can I decide NLA1, NLA2 and SLA by myself? > >Are there some more rules ? > > I don't know what you trying to say. > - If you hook up to ISP as a leaf organization (you have no > downstream), you will be getting /48 and you have 2^16 subnets > (and possible to accomodate 2^64 hosts onto each subnet). > - If you hook up to big ISP as smaller ISP, you may end up becoming > NLA1 or NLA2. You will get address block like /40 or something > like that (it is up to big ISP to choose bit boundary, I believe). > - If you obtain address block from IANA, you will get /35 (sTLA) > or /16 (TLA, which can be obtained only after you use up sTLAs) > > So if you are not ISP, you will get /48. > > itojun -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- From kenken@sfc.wide.ad.jp Mon Nov 1 07:26:27 1999 From: kenken@sfc.wide.ad.jp (Kengo NAGAHASHI) Date: Mon, 01 Nov 1999 16:26:27 +0900 Subject: (6bone-jp 1011) Re: IPv6 frame In-Reply-To: In your message of "Mon, 01 Nov 1999 15:50:41 +0900" <23473.941439041@coconut.itojun.org> References: <381D3754.9391D515@kt.co.kr> <23473.941439041@coconut.itojun.org> Message-ID: <14365.16547.417167.55557V@selphie.sfc.wide.ad.jp> At Mon, 01 Nov 1999 15:50:41 +0900, itojun@iijlab.net wrote: > > > >I'm sorry for you to make misunderstand. > >I got sTLA from APNIC.(sTLA 2001:220::/35) > >Now I should the addressing plan for the sTLA. > >Korea Telecom is biggest company in Korea. > >So maybe some ISPs hope get the KT sTLA. > >My plan is > >------------------------------------------ > >NLA1 Res NLA2 SLA Interface > >------------------------------------------ > >I hope that SLA is given Organizations or Univs. > >NLA2 is given for projects. > >NLA1 is given for ISPs. > >Is this pland resonable? > >I hope to know your advice about IPv6 address plan, > > Please specify prefix length in your mind for NLA1/NLA2/SLA, for > correctness of discussion. > > kenken, you'd better describe your current plan about 2001:200::/35 > (sTLA for WIDE project). > In WIDE project,we'll allocate sTLA address prefix as follows: /35 /41 /48 /64 /128 +----------+-------+--------+-----+----------+ |sTLA | NLA1 | NLA2 |SLA | ID | +----------+-------+--------+-----+----------+ We divied NLA space as NLA1(/41) and NLA2(/48) -The target of NLA1 is a {small,medium} ISPs that want to allocate IPv6 address prefix for customes(DO NOT use for bussiness in our rules) -And the target of NLA2 is Academics,Companies,Research Institue and so. -We don't assign SLA space and organizations decide to allocate SLA address space. regards. -- Kengo NAGHASHI Keio University/WIDE Project From ksbn@kt.co.kr Mon Nov 1 09:14:32 1999 From: ksbn@kt.co.kr (ksb) Date: Mon, 01 Nov 1999 18:14:32 +0900 Subject: (6bone-jp 1006) IPv6 frame References: <22653.941435855@coconut.itojun.org> <381D3278.AD76F43E@kt.co.kr> Message-ID: <381D59F8.6A967D9E@kt.co.kr> Dear itojun, I planed like following from. Wlii you send me some comment? Thank you. (sTLA 2001:220::/35) /35 /40 /42 /48 /64 /128 +--------+-------+------+-----+---------+----------+ | sTLA | NLA1 | RES |NLA2 | SLA | ID | +--------+-------+------+-----+---------+----------+ NLA1: ISP RES: reservation NLA2: orgization SLA: organization area ID : interface ID -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- From fink@es.net Mon Nov 1 17:50:34 1999 From: fink@es.net (Bob Fink) Date: Mon, 01 Nov 1999 09:50:34 -0800 Subject: IPv6 Operational Topics Meeting in DC Message-ID: <4.1.19991101094924.015bea90@imap2.es.net> IPv6 operational folk, Marc Blanchet and I will be hosting a one-hour mid-day IPv6 Operational Topics Meeting during the Washington DC IETF week to discuss operational ipv6-related topics. Potential topics we would like to see covered are: a. state of 6tap peering b. state of other peering points (Amsterdam, Japan...) c. exploring options for maximal interconnect (6to4 relays, etc.) d. explore interest in ipv6 route server availability e. state of production-ipv6-nets (various 2001::/35 sTLA prefixes are being handed out so folk should be willing to say what they are doing) f. advice for getting production (sTLA) prefixes g. discuss hardening activities for 6bone h. IPv6 (6bone) registry usage, what to expand, what to enforce i. real application usage experience j. your ideas here?! So, please comment on the following things: 1. The agenda above, i.e., will you want to speak and for what topic. 2. Additional topics for the agenda that you will speak to or want others to speak to. [Note that given the limit of one-hour for the meeting that these items are for very brief status updates and key issue presentations.] 3. Best time (for you) for the meeting: Choices are 11:45 till 12:45 (in the same room that the IPng will be in) either Wed. or Thurs. We will announce the exact time/day and the agenda the lists as soon as we can. Whatever the day, assume it will be in the same room that the IPng will be in, which is currently the Regency. As the IPng meeting will be Wed. and Thurs. from 1-3, the IPv6 Operational meeting will end just before IPng starts, either Wed. or Thurs., depending on the day we choose. Thanks, Bob (and Marc) PS: for those in town on Sunday, there will be an IEPG meeting (10-?? at the Omni) for which Marc and I will try to get on the agenda to speak to some operational topics listed above. Get yourselves on that meeting's agenda if you can do it. From Ivano.Guardini@CSELT.IT Wed Nov 3 10:54:48 1999 From: Ivano.Guardini@CSELT.IT (Guardini Ivano) Date: Wed, 03 Nov 1999 11:54:48 +0100 Subject: Unaggregated prefixes in BGP4+ cloud Message-ID: <9187FF572943D211B28100805FC130FC011DA857@xrr1.cselt.it> Hi all, during the last two weeks the number of unaggregated IPv6 prefixes advertised within the BGP4+ cloud is increased a lot (look at http://carmen.cselt.it/ipv6/bgp/odd-routes.html and http://carmen.cselt.it/ipv6/bgp/graphs/index.html) and I think that this is a very undesirable thing that should be fixed especially if we really consider the 6bone as a gymnasium for production use of IPv6. The ASs that are currently generating most of the unaggregated prefixes are: - AS7680 with 22 unaggregated prefixes - AS4556 with 20 unaggregated prefixes - AS2852 (CESNET) with 8 unaggregated prefixes - AS11008 (CENTAURI-AR) with 8 unaggregated prefixes Unfortunately I was not able to locate contact persons for AS7680 and AS4556 in that they seem not to be registered in the 6bone database. The poor use of the 6bone registry is another critical issue that we should try to address especially for the sites participating in the BGP4+ cloud. For example I think that any pTLA or pNLA should make sure that any new downstream BGP4+ peer is correctly registered in the 6bone database before setting up the connection. Bye Ivano From rrockell@sprint.net Wed Nov 3 14:22:23 1999 From: rrockell@sprint.net (Robert J. Rockell) Date: Wed, 3 Nov 1999 09:22:23 -0500 (EST) Subject: Unaggregated prefixes in BGP4+ cloud In-Reply-To: <9187FF572943D211B28100805FC130FC011DA857@xrr1.cselt.it> Message-ID: Give them a week, and then filter them? :) 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 Wed, 3 Nov 1999, Guardini Ivano wrote: ->Hi all, -> ->during the last two weeks the number of unaggregated IPv6 prefixes ->advertised ->within the BGP4+ cloud is increased a lot (look at ->http://carmen.cselt.it/ipv6/bgp/odd-routes.html ->and http://carmen.cselt.it/ipv6/bgp/graphs/index.html) and I think that this ->is a ->very undesirable thing that should be fixed especially if we really consider ->the 6bone as a ->gymnasium for production use of IPv6. ->The ASs that are currently generating most of the unaggregated prefixes are: -> ->- AS7680 with 22 unaggregated prefixes ->- AS4556 with 20 unaggregated prefixes ->- AS2852 (CESNET) with 8 unaggregated prefixes ->- AS11008 (CENTAURI-AR) with 8 unaggregated prefixes -> ->Unfortunately I was not able to locate contact persons for AS7680 and AS4556 ->in that they ->seem not to be registered in the 6bone database. ->The poor use of the 6bone registry is another critical issue that we should ->try ->to address especially for the sites participating in the BGP4+ cloud. For ->example ->I think that any pTLA or pNLA should make sure that any new downstream BGP4+ ->peer ->is correctly registered in the 6bone database before setting up the ->connection. -> ->Bye ->Ivano -> -> -> From Ivano.Guardini@CSELT.IT Wed Nov 3 15:13:35 1999 From: Ivano.Guardini@CSELT.IT (Guardini Ivano) Date: Wed, 03 Nov 1999 16:13:35 +0100 Subject: Unaggregated prefixes in BGP4+ cloud Message-ID: <9187FF572943D211B28100805FC130FC011DA858@xrr1.cselt.it> Hi Rob, so far I have always tried to avoid prefix filtering on my IPv6 routers. The problem is that this practice may hide some of the router bugs or configuration mistakes that we are trying to fix as part of the 6bone effort. Anyway I think that at present we do need some kind of mechanism to enforce the 6bone hardening rules outlined in your draft and prefix filtering seems to be an effective way to deal with the matter. So I will do as you suggest. In addition, in order to help debugging, I'm going to make available an html page showing the prefix filters configured at the CSELT pTLA. Bye Ivano > ---------- > From: Robert J. Rockell[SMTP:rrockell@sprint.net] > Sent: Wednesday, November 03, 1999 3:22 PM > To: Guardini Ivano > Cc: '6bone' > Subject: Re: Unaggregated prefixes in BGP4+ cloud > > Give them a week, and then filter them? :) > > 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 Wed, 3 Nov 1999, Guardini Ivano wrote: > > ->Hi all, > -> > ->during the last two weeks the number of unaggregated IPv6 prefixes > ->advertised > ->within the BGP4+ cloud is increased a lot (look at > ->http://carmen.cselt.it/ipv6/bgp/odd-routes.html > ->and http://carmen.cselt.it/ipv6/bgp/graphs/index.html) and I think that > this > ->is a > ->very undesirable thing that should be fixed especially if we really > consider > ->the 6bone as a > ->gymnasium for production use of IPv6. > ->The ASs that are currently generating most of the unaggregated prefixes > are: > -> > ->- AS7680 with 22 unaggregated prefixes > ->- AS4556 with 20 unaggregated prefixes > ->- AS2852 (CESNET) with 8 unaggregated prefixes > ->- AS11008 (CENTAURI-AR) with 8 unaggregated prefixes > -> > ->Unfortunately I was not able to locate contact persons for AS7680 and > AS4556 > ->in that they > ->seem not to be registered in the 6bone database. > ->The poor use of the 6bone registry is another critical issue that we > should > ->try > ->to address especially for the sites participating in the BGP4+ cloud. > For > ->example > ->I think that any pTLA or pNLA should make sure that any new downstream > BGP4+ > ->peer > ->is correctly registered in the 6bone database before setting up the > ->connection. > -> > ->Bye > ->Ivano > -> > -> > -> > From seirios@Matrix.iri.co.jp Wed Nov 3 17:01:21 1999 From: seirios@Matrix.iri.co.jp (HEO SeonMeyong) Date: Thu, 04 Nov 1999 02:01:21 +0900 Subject: Unaggregated prefixes in BGP4+ cloud In-Reply-To: <9187FF572943D211B28100805FC130FC011DA857@xrr1.cselt.it> References: <9187FF572943D211B28100805FC130FC011DA857@xrr1.cselt.it> Message-ID: <19991104020121G.seirios@Matrix.iri.co.jp> $B5v$G$9!#(B > - AS7680 with 22 unaggregated prefixes $B$3$l$O!"F|K\$NAH?%$G$9$M!#(B > - AS4556 with 20 unaggregated prefixes $B$3$l$O!"$I$&$d$i%"%a%j%+$NAH?%$+$J!#(B $B$[(B From fink@es.net Wed Nov 3 18:00:38 1999 From: fink@es.net (Bob Fink) Date: Wed, 03 Nov 1999 10:00:38 -0800 Subject: pchar for v6 Message-ID: <4.1.19991103095845.018f48c0@imap2.es.net> Look at this! pathchar for v6! Neat. Good work Bruce. Bob >------- Forwarded Message > >To: pchar-announce@stennis.ca.sandia.gov >Cc: bmah@ca.sandia.gov >Subject: pchar-1.0 available >From: bmah@ca.sandia.gov (Bruce A. Mah) >Date: Wed, 03 Nov 1999 09:45:12 -0800 > >I'm pleased to announce the release of pchar-1.0, a reimplementation >of Van Jacobson's pathchar utility for characterizing the individual >hops of a path between two network hosts. pchar works on both IPv4 >and IPv6 networks. > >pchar has been tested on various versions of FreeBSD, Solaris, Linux, >and IRIX, with the primary development on FreeBSD and Solaris. pchar >is written is C++, primarily using recent versions of gcc, but with >some testing also on the SparcWorks C++ compiler. > >Recent additions to pchar include: IPv6 support, better Linux >compatability, a more comprehensive tracefile format, and mroe options >for measurement and analysis. A number of bugs have been fixed as >well. > >More information, as well as downloadable source code, can be found at: > >http://www.ca.sandia.gov/~bmah/Software/pchar/ > >Bruce. > > > > > >- --==_Exmh_-105180048P >Content-Type: application/pgp-signature > >- -----BEGIN PGP SIGNATURE----- >Version: PGPfreeware 5.0i for non-commercial use >MessageID: 9et7kMy+Sh6v1JHdunI6zJwRE/kPJyVC > >iQA/AwUBOCB0qNjKMXFboFLDEQI2WQCg9pdLp4iVsBc5dB//ycY0OepsE84An3lX >OX3MvaprMYvet8/lZ6qE82RR >=swT3 >- -----END PGP SIGNATURE----- > >- --==_Exmh_-105180048P-- > >------- End of Forwarded Message From bmah@CA.Sandia.GOV Wed Nov 3 18:37:16 1999 From: bmah@CA.Sandia.GOV (Bruce A. Mah) Date: Wed, 03 Nov 1999 10:37:16 -0800 Subject: pchar for v6 In-Reply-To: Your message of "Wed, 03 Nov 1999 10:00:38 PST." <4.1.19991103095845.018f48c0@imap2.es.net> Message-ID: <199911031837.KAA03911@nimitz.ca.sandia.gov> --==_Exmh_814271940P Content-Type: text/plain; charset=us-ascii If memory serves me right, Bob Fink wrote: > Look at this! pathchar for v6! Neat. Good work Bruce. Thanks. I'd be interested to hear from people about their successes and failures with pchar on IPv6 (particularly on stacks other than KAME since that's all I have at my disposal right now). Cheers, Bruce. --==_Exmh_814271940P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: Ih6zFgZBNCfnBAeMm+tG1KMVKHpJQ9K8 iQA/AwUBOCCA3NjKMXFboFLDEQIGrQCgpOEml/+97HIg+GWF6bxnXOMWbcYAnAxK AZGTIgsEYkQlHXVNK3ZrufQi =cmIV -----END PGP SIGNATURE----- --==_Exmh_814271940P-- From rrockell@sprint.net Wed Nov 3 22:09:37 1999 From: rrockell@sprint.net (Robert J. Rockell) Date: Wed, 3 Nov 1999 17:09:37 -0500 (EST) Subject: bad routing Message-ID: Forewarning: if you are going to be offended by seeing your own AS in this mail, do not read any further. I will use my own example, so as to not affend anyone, but I did want to mention something more regarding Ivano's mail about poorly aggregated prefixes. Please consider the following excerpt from yesterday's report: SPRINT (3ffe:2900::/24) had 10 route(s) 3ffe:2900:1::18/126 path 1225 1849 5539 4556 ( -- 100%) 3ffe:2900:c:8::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%) 3ffe:29a1::/64 path 1225 1103 786 1849 3251 1930 1251 4270 11008 3ffe:2900:1::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%) 3ffe:2900:ffe3::/48 path 1225 1103 1200 8251 8731 8319 6175 7838 (USAA 3ffe:2900:5::/48 path 1225 1312 (LORE/VT -- 100%) 3ffe:29a1:c::/48 path 1225 1103 786 1849 3251 1930 1251 4270 11008 3ffe:2900:c005::/48 path 1225 1103 1200 8251 8731 8319 6175 11017 ( -- 3ffe:2900:9::/48 path 1225 1103 1200 8251 8731 8319 6175 71 (HP -- 93%) 3ffe:29a2::/32 path 1225 1103 1200 8251 8731 8319 6175 11261 (ASCI -- Looking at these, one may think "wow, Sprint sure is bad at aggregating it's prefixes". However, if you look at this, one can see that SPrint's ASN (6175) is only in four of these BAD routes' AS path. 3ffe:29a2::/32 3ffe:2900:9::/48 3ffe:2900:c005::/48 3ffe:2900:ffe3::/48 Now, as these do have Sprint in the AS path, we can see that the next AS in the path is both accepting these routes, and propogating them back up. AS 8319 is a peer of Sprint, and Sprint is sending more specifics, and breaking aggregation rules. This has been fixed. However one may argue that AS8319 could filter more specifics from sprint, and help to alleviate this problem. I have adjusted my outbound filters to compensate. SPRINT is at fault, but the upstream who allowed them shares blame (AS8319). The theory that filtering is bad because it does not show bugs in your system is no longer valid. If your IPv6 node is a single router, then you shoudl not be a pTLA, but a leaf node. One's internal network should suffice to test implementations. This way, it does not affect the rest of us. Every other route in this case does not even have Sprint in the AS path, which means someone else (usually the Sprint downstream) is leaking the route back up to their other upstreams. We have been trying to curtail this since orlando IETF. It is the fault of the upstream provider to allow these announcements out,a nd the fault of EVERY PTLA in the AS path to allow these prefixes to be transitted. If you cannot filter, then give back your pTLA please. This is a testbed, but this is not a lab. You affect others when you break aggregation. I will be glad to give you a transit connection, and some IPv6 space to play. I will be contacting each of my downstreams who are leaking bad routes, and helping to get this fixed. If you have a lot of customers, please do the same. People who are on the bad rotuing report more than usually are not to blaim for most of the bad rotues. It is their downstream customers other providers who have the problem. MERIT: Woudl it be possible to jog this report to start blaiming the AS who is at fault, rather than the pTLA who cannot fix it? The worst offenders: AS 4555 AS 7680 AS 11008 AS 2852 IF you have these customers as direct downsteams, please filter them, for the sake of the rest of us. Bob, perhaps we need to start actively policing this. I can see people on the bad routing report who have been there since I first heard of IPv6, and still refuse to filter. I will begin to take action on my pTLA. I encourage the rest of you to do so as well. Write to me personally if you do not nkow how/what to filter, and I can point you somewhere to learn. 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 seirios@Matrix.iri.co.jp Thu Nov 4 07:13:49 1999 From: seirios@Matrix.iri.co.jp (HEO SeonMeyong) Date: Thu, 04 Nov 1999 16:13:49 +0900 Subject: Unaggregated prefixes in BGP4+ cloud In-Reply-To: <19991104020121G.seirios@Matrix.iri.co.jp> References: <9187FF572943D211B28100805FC130FC011DA857@xrr1.cselt.it> <19991104020121G.seirios@Matrix.iri.co.jp> Message-ID: <19991104161349D.seirios@Matrix.iri.co.jp> This is HEO SeonMeyong writing. I'm very sorry for may Japanese Encoding Mail. I want to send it for Japanese ML... I resend it in English. > > - AS7680 with 22 unaggregated prefixes This is Japanese Organization. From APNIC, This is RADIX > > - AS4556 with 20 unaggregated prefixes This is in America Organization, maybe. HEO From sumikawa@ebina.hitachi.co.jp Thu Nov 4 08:31:40 1999 From: sumikawa@ebina.hitachi.co.jp (SUMIKAWA Munechika (=?ISO-2022-JP?B?GyRCM1FAbj0hNmEbKEI=?=)) Date: Thu, 04 Nov 1999 17:31:40 +0900 (JST) Subject: pchar for v6 In-Reply-To: <199911031837.KAA03911@nimitz.ca.sandia.gov> References: <4.1.19991103095845.018f48c0@imap2.es.net> <199911031837.KAA03911@nimitz.ca.sandia.gov> Message-ID: <19991104173140V.sumikawa@ebina.hitachi.co.jp> Bruce, We, KAME developers, made port/pkgsrc of KAME-NetBSD and KAME-FreeBSD for easily installation. It will be distributed at next snap on Monday. Tiny patch for pchar-1.0 is attached as below. You should use $(INSTALL_DATA) to install manuals. Could you merge it at next release? Thanks, --- Munechika SUMIKAWA @ KAME Project ------------------------------------------------------------ --- Makefile.in.orig Thu Nov 4 02:12:36 1999 +++ Makefile.in Thu Nov 4 14:42:00 1999 @@ -179,7 +179,7 @@ install-man: $(MKINSTALLDIRS) ${mandir}/man1 - $(INSTALL_PROGRAM) pchar.1 ${mandir}/man1/pchar.1 + $(INSTALL_DATA) pchar.1 ${mandir}/man1/pchar.1 # # clean From aljaz@iskratel.si Thu Nov 4 11:51:10 1999 From: aljaz@iskratel.si (Aljaz Tomaz RDSI) Date: Thu, 4 Nov 1999 12:51:10 +0100 Subject: ATM PVC &IPv6 Message-ID: <7E8519F1A7C0D211B0D200A0C93AA60F3D28C9@ntmail.iskratel.si> Hi all! I wonder how IPv6 communicate via ATM PVC. Does it employ some protokolol like Invers ARP in IPv4 or you have to configure static address maping IPv6/ATM. Could someone explain me this situation? Regards, Tomaz From Francis.Dupont@inria.fr Thu Nov 4 13:55:07 1999 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Thu, 04 Nov 1999 14:55:07 +0100 Subject: ATM PVC &IPv6 In-Reply-To: Your message of Thu, 04 Nov 1999 12:51:10 +0100. <7E8519F1A7C0D211B0D200A0C93AA60F3D28C9@ntmail.iskratel.si> Message-ID: <199911041355.OAA04600@givry.inria.fr> In your previous mail you wrote: I wonder how IPv6 communicate via ATM PVC. => IPv6 over ATM PVCs works very well. Does it employ some protokolol like Invers ARP in IPv4 or => there is an Internet Draft about inverse discovery by Alex Conta (draft-ietf-ion-ipv6-ind-03.txt) but the target is Frame Relay (but this "may also apply to other networks with similar behavior", ie. other NBMA like ATM). you have to configure static address maping IPv6/ATM. => this is the standard way to do it, for instance on a Cisco with an IPv6 enable IOS in a "map-list" you can have something like: ipv6 3FFE:306:1051:D6DB:2020:EAFF:FE00:2D5F atm-vc 70 Could someone explain me this situation? => just try it! Regards Francis.Dupont@inria.fr From rob@consoftware.com Thu Nov 4 15:01:14 1999 From: rob@consoftware.com (rob) Date: Thu, 4 Nov 1999 10:01:14 -0500 Subject: bad routing In-Reply-To: Message-ID: <002201bf26d6$7350df80$450101c0@rob> Robert, you need to relax. -----Original Message----- From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU]On Behalf Of Robert J. Rockell Sent: Thursday, November 04, 1999 8:57 AM To: 6bone@ISI.EDU Subject: bad routing Forewarning: if you are going to be offended by seeing your own AS in this mail, do not read any further. I will use my own example, so as to not affend anyone, but I did want to mention something more regarding Ivano's mail about poorly aggregated prefixes. Please consider the following excerpt from yesterday's report: SPRINT (3ffe:2900::/24) had 10 route(s) 3ffe:2900:1::18/126 path 1225 1849 5539 4556 ( -- 100%) 3ffe:2900:c:8::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%) 3ffe:29a1::/64 path 1225 1103 786 1849 3251 1930 1251 4270 11008 3ffe:2900:1::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%) 3ffe:2900:ffe3::/48 path 1225 1103 1200 8251 8731 8319 6175 7838 (USAA 3ffe:2900:5::/48 path 1225 1312 (LORE/VT -- 100%) 3ffe:29a1:c::/48 path 1225 1103 786 1849 3251 1930 1251 4270 11008 3ffe:2900:c005::/48 path 1225 1103 1200 8251 8731 8319 6175 11017 ( -- 3ffe:2900:9::/48 path 1225 1103 1200 8251 8731 8319 6175 71 (HP -- 93%) 3ffe:29a2::/32 path 1225 1103 1200 8251 8731 8319 6175 11261 (ASCI -- Looking at these, one may think "wow, Sprint sure is bad at aggregating it's prefixes". However, if you look at this, one can see that SPrint's ASN (6175) is only in four of these BAD routes' AS path. 3ffe:29a2::/32 3ffe:2900:9::/48 3ffe:2900:c005::/48 3ffe:2900:ffe3::/48 Now, as these do have Sprint in the AS path, we can see that the next AS in the path is both accepting these routes, and propogating them back up. AS 8319 is a peer of Sprint, and Sprint is sending more specifics, and breaking aggregation rules. This has been fixed. However one may argue that AS8319 could filter more specifics from sprint, and help to alleviate this problem. I have adjusted my outbound filters to compensate. SPRINT is at fault, but the upstream who allowed them shares blame (AS8319). The theory that filtering is bad because it does not show bugs in your system is no longer valid. If your IPv6 node is a single router, then you shoudl not be a pTLA, but a leaf node. One's internal network should suffice to test implementations. This way, it does not affect the rest of us. Every other route in this case does not even have Sprint in the AS path, which means someone else (usually the Sprint downstream) is leaking the route back up to their other upstreams. We have been trying to curtail this since orlando IETF. It is the fault of the upstream provider to allow these announcements out,a nd the fault of EVERY PTLA in the AS path to allow these prefixes to be transitted. If you cannot filter, then give back your pTLA please. This is a testbed, but this is not a lab. You affect others when you break aggregation. I will be glad to give you a transit connection, and some IPv6 space to play. I will be contacting each of my downstreams who are leaking bad routes, and helping to get this fixed. If you have a lot of customers, please do the same. People who are on the bad rotuing report more than usually are not to blaim for most of the bad rotues. It is their downstream customers other providers who have the problem. MERIT: Woudl it be possible to jog this report to start blaiming the AS who is at fault, rather than the pTLA who cannot fix it? The worst offenders: AS 4555 AS 7680 AS 11008 AS 2852 IF you have these customers as direct downsteams, please filter them, for the sake of the rest of us. Bob, perhaps we need to start actively policing this. I can see people on the bad routing report who have been there since I first heard of IPv6, and still refuse to filter. I will begin to take action on my pTLA. I encourage the rest of you to do so as well. Write to me personally if you do not nkow how/what to filter, and I can point you somewhere to learn. 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 Thu Nov 4 15:25:42 1999 From: rrockell@sprint.net (Robert J. Rockell) Date: Thu, 4 Nov 1999 10:25:42 -0500 (EST) Subject: bad routing In-Reply-To: <002201bf26d6$7350df80$450101c0@rob> Message-ID: I would agree with that :) However, I believe that ipv6 backbone stability is going to be more than just nice if we are to convince the mostly anti-v6 world that this stuff works. If the "experts" can't make it work, how do we get the rest of the world on board? Big Business involvement is the key to IPv6's sucess. Big Business is wary to change. If we can't show EXPLICIT improvement in IPv6 over IPv4, the transition will be delayed till the very end. I just don't want to see this happen. Sorry if I strap my boots on a little to tight. I think it is time someone did. If SPRINT did this in the Internet, we would get killed on the NANOG mailing list... I think it would be nice if everyone took this a little more seriously. Sorry if I offend anyone. 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 Thu, 4 Nov 1999, rob wrote: -> ->Robert, you need to relax. -> -> ->-----Original Message----- ->From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU]On Behalf Of ->Robert J. Rockell ->Sent: Thursday, November 04, 1999 8:57 AM ->To: 6bone@ISI.EDU ->Subject: bad routing -> -> ->Forewarning: if you are going to be offended by seeing your own AS in this ->mail, do not read any further. -> -> ->I will use my own example, so as to not affend anyone, but I did want to ->mention something more regarding Ivano's mail about poorly aggregated ->prefixes. Please consider the following excerpt from yesterday's report: -> -> SPRINT (3ffe:2900::/24) had 10 route(s) -> 3ffe:2900:1::18/126 path 1225 1849 5539 4556 ( -- 100%) -> 3ffe:2900:c:8::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%) -> 3ffe:29a1::/64 path 1225 1103 786 1849 3251 1930 1251 4270 11008 -> 3ffe:2900:1::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%) -> 3ffe:2900:ffe3::/48 path 1225 1103 1200 8251 8731 8319 6175 7838 (USAA -> 3ffe:2900:5::/48 path 1225 1312 (LORE/VT -- 100%) -> 3ffe:29a1:c::/48 path 1225 1103 786 1849 3251 1930 1251 4270 11008 -> 3ffe:2900:c005::/48 path 1225 1103 1200 8251 8731 8319 6175 11017 ( -- -> 3ffe:2900:9::/48 path 1225 1103 1200 8251 8731 8319 6175 71 (HP -- 93%) -> 3ffe:29a2::/32 path 1225 1103 1200 8251 8731 8319 6175 11261 (ASCI -- -> ->Looking at these, one may think "wow, Sprint sure is bad at aggregating it's ->prefixes". However, if you look at this, one can see that SPrint's ASN ->(6175) is only in four of these BAD routes' AS path. -> ->3ffe:29a2::/32 ->3ffe:2900:9::/48 ->3ffe:2900:c005::/48 ->3ffe:2900:ffe3::/48 -> -> ->Now, as these do have Sprint in the AS path, we can see that the next AS in ->the path is both accepting these routes, and propogating them back up. AS ->8319 is a peer of Sprint, and Sprint is sending more specifics, and breaking ->aggregation rules. -> ->This has been fixed. However one may argue that AS8319 could filter more ->specifics from sprint, and help to alleviate this problem. I have adjusted ->my outbound filters to compensate. SPRINT is at fault, but the upstream who ->allowed them shares blame (AS8319). -> ->The theory that filtering is bad because it does not show bugs in your ->system is no longer valid. If your IPv6 node is a single router, then you ->shoudl not be a pTLA, but a leaf node. One's internal network should suffice ->to test implementations. This way, it does not affect the rest of us. -> ->Every other route in this case does not even have Sprint in the AS path, ->which means someone else (usually the Sprint downstream) is leaking the ->route ->back up to their other upstreams. -> ->We have been trying to curtail this since orlando IETF. -> ->It is the fault of the upstream provider to allow these announcements out,a ->nd the fault of EVERY PTLA in the AS path to allow these prefixes to be ->transitted. If you cannot filter, then give back your pTLA please. This is ->a ->testbed, but this is not a lab. You affect others when you break ->aggregation. I will be glad to give you a transit connection, and some IPv6 ->space to play. -> -> ->I will be contacting each of my downstreams who are leaking bad routes, and ->helping to get this fixed. If you have a lot of customers, please do the ->same. People who are on the bad rotuing report more than usually are not to ->blaim for most of the bad rotues. It is their downstream customers other ->providers who have the problem. -> ->MERIT: Woudl it be possible to jog this report to start blaiming the AS who ->is at fault, rather than the pTLA who cannot fix it? -> -> ->The worst offenders: -> ->AS 4555 ->AS 7680 ->AS 11008 ->AS 2852 -> ->IF you have these customers as direct downsteams, please filter them, for ->the sake of the rest of us. -> ->Bob, perhaps we need to start actively policing this. I can see people on ->the bad routing report who have been there since I first heard of IPv6, and ->still refuse to filter. I will begin to take action on my pTLA. I encourage ->the rest of you to do so as well. Write to me personally if you do not nkow ->how/what to filter, and I can point you somewhere to learn. -> -> -> -> -> -> -> -> -> -> -> -> ->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 bmah@CA.Sandia.GOV Thu Nov 4 16:17:10 1999 From: bmah@CA.Sandia.GOV (Bruce A. Mah) Date: Thu, 04 Nov 1999 08:17:10 -0800 Subject: pchar for v6 In-Reply-To: Your message of "Thu, 04 Nov 1999 17:31:40 +0900." <19991104173140V.sumikawa@ebina.hitachi.co.jp> Message-ID: <199911041617.IAA13810@nimitz.ca.sandia.gov> --==_Exmh_-1131497428P Content-Type: text/plain; charset=us-ascii If memory serves me right, SUMIKAWA Munechika wrote: > We, KAME developers, made port/pkgsrc of KAME-NetBSD and KAME-FreeBSD > for easily installation. It will be distributed at next snap on Monday. Cool. Does this mean that pchar works on NetBSD? On which platform(s)? > Tiny patch for pchar-1.0 is attached as below. You should use > $(INSTALL_DATA) to install manuals. Could you merge it at next > release? [snip] Just committed this, thanks for the correction! Bruce. --==_Exmh_-1131497428P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: iNdETv3sjNUGnLObbd5Gg/aoqXzmpZ84 iQA/AwUBOCGxhdjKMXFboFLDEQLqpQCfcPAWq5ls7JsSOd4pxmH7+1u8bQcAnifl zkUMJviB4HStyaY4hEvasQ5i =83Gv -----END PGP SIGNATURE----- --==_Exmh_-1131497428P-- From fink@es.net Thu Nov 4 16:29:30 1999 From: fink@es.net (Bob Fink) Date: Thu, 04 Nov 1999 08:29:30 -0800 Subject: production IPv6 subTLA allocations Message-ID: <4.1.19991104082511.00cbdb70@imap2.es.net> Juergen Rauschenbach of DFN has kindly generated a consolidated and regularly (?) updated list of subTLA allocations from the APNIC, ARIN and RIPE-NCC registries. I have added a pointer to it on the 6bone and 6ren pages, but here is the url. Thanks Juergen! Bob From sumikawa@ebina.hitachi.co.jp Thu Nov 4 17:35:26 1999 From: sumikawa@ebina.hitachi.co.jp (SUMIKAWA Munechika (=?ISO-2022-JP?B?GyRCM1FAbj0hNmEbKEI=?=)) Date: Fri, 05 Nov 1999 02:35:26 +0900 (JST) Subject: pchar for v6 In-Reply-To: <199911041617.IAA13810@nimitz.ca.sandia.gov> References: <19991104173140V.sumikawa@ebina.hitachi.co.jp> <199911041617.IAA13810@nimitz.ca.sandia.gov> Message-ID: <19991105023526P.sumikawa@ebina.hitachi.co.jp> > We, KAME developers, made port/pkgsrc of KAME-NetBSD and KAME-FreeBSD > for easily installation. It will be distributed at next snap on Monday. bmah> Cool. Does this mean that pchar works on NetBSD? On which platform(s)? Yes. We checked that it works on only KAME-NetBSD1.4.1-i386. But, I got strage results in some situation. See #3 item in the following results. Pchar reports minus Band Width. What happens? It happend on KAME-FreeBSD3.3-i386 box. If you need more information for debugging, let me know. Thanks, --- Munechika SUMIKAWA @ KAME Project -------------------------------------------------------- prince:~% root pchar -p ipv6udp june.v6.wide.ad.jp pchar to june.v6.wide.ad.jp (3ffe:501:0:801:290:27ff:fe61:b0dd) using UDP/IPv6 Packet size increments by 32 to 1500 46 test(s) per repetition 32 repetition(s) per hop 0: Partial loss: 0 / 1440 (0%) Partial char: rtt = 0.502937 ms, (b = 0.002287 ms/B), r2 = 0.997345 stddev rtt = 0.013819, stddev b = 0.000018 Hop char: rtt = 0.502937 ms, bw = 3498.514557 Kbps Partial queueing: avg = 0.000084 ms (36 bytes) 1: 3ffe:501:4819:8000:200:f8ff:fe04:5469 (3ffe:501:4819:8000:200:f8ff:fe04:5469) Partial loss: 194 / 1440 (13%) Partial char: rtt = 22.162998 ms, (b = 0.015425 ms/B), r2 = 0.989061 stddev rtt = 0.179215, stddev b = 0.000267 Hop char: rtt = 21.660061 ms, bw = 608.906665 Kbps Partial queueing: avg = 0.005603 ms (363 bytes) 2: 3ffe:501:0:4800:21:6a39:6174:3 (paradise.karigome.wide.ad.jp) Partial loss: 192 / 1440 (13%) Partial char: rtt = 26.774703 ms, (b = 0.025138 ms/B), r2 = 0.996783 stddev rtt = 0.157757, stddev b = 0.000235 Hop char: rtt = 4.611704 ms, bw = 823.676532 Kbps Partial queueing: avg = 0.003620 ms (144 bytes) 3: 3ffe:501:0:1c01:200:f8ff:fe03:d9c0 (pc3.nezu.wide.ad.jp) Partial loss: 4 / 1440 (0%) Partial char: rtt = 47.038458 ms, (b = 0.024740 ms/B), r2 = 0.996857 stddev rtt = 0.162686, stddev b = 0.000212 Hop char: rtt = 20.263755 ms, bw = -20116.530889 Kbps Partial queueing: avg = 0.009824 ms (397 bytes) 4: 3ffe:501:0:801:290:27ff:fe61:b0dd (june.nara.wide.ad.jp) Path length: 4 hops Path char: rtt = 47.038458 ms, r2 = 0.996857 Path bottleneck: 608.906665 Kbps Path pipe: 3580 bytes Path queueing: average = 0.009824 ms (397 bytes) From fink@es.net Thu Nov 4 18:34:12 1999 From: fink@es.net (Bob Fink) Date: Thu, 04 Nov 1999 10:34:12 -0800 Subject: bad routing In-Reply-To: Message-ID: <4.1.19991104103021.00ca0280@imap2.es.net> Rob, I certainly agree with most of what you say. Getting the 6bone backbone as stable and production oriented as possible is very important and I will continue to push and support efforts to make it so. Hopefully at the IETF next week we can address this: First, at the NGtrans meeting when we talk about your current HARDEN draft: Second, at the IPv6 Operational Topics meeting (day yet to be announced). See you in DC, and thanks for pushing on this. Bob === At 05:09 PM 11/3/99 -0500, Robert J. Rockell wrote: >Forewarning: if you are going to be offended by seeing your own AS in this >mail, do not read any further. > > >I will use my own example, so as to not affend anyone, but I did want to >mention something more regarding Ivano's mail about poorly aggregated >prefixes. Please consider the following excerpt from yesterday's report: > > SPRINT (3ffe:2900::/24) had 10 route(s) > 3ffe:2900:1::18/126 path 1225 1849 5539 4556 ( -- 100%) > 3ffe:2900:c:8::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%) > 3ffe:29a1::/64 path 1225 1103 786 1849 3251 1930 1251 4270 11008 > 3ffe:2900:1::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%) > 3ffe:2900:ffe3::/48 path 1225 1103 1200 8251 8731 8319 6175 7838 (USAA > 3ffe:2900:5::/48 path 1225 1312 (LORE/VT -- 100%) > 3ffe:29a1:c::/48 path 1225 1103 786 1849 3251 1930 1251 4270 11008 > 3ffe:2900:c005::/48 path 1225 1103 1200 8251 8731 8319 6175 11017 ( -- > 3ffe:2900:9::/48 path 1225 1103 1200 8251 8731 8319 6175 71 (HP -- 93%) > 3ffe:29a2::/32 path 1225 1103 1200 8251 8731 8319 6175 11261 (ASCI -- > >Looking at these, one may think "wow, Sprint sure is bad at aggregating it's >prefixes". However, if you look at this, one can see that SPrint's ASN >(6175) is only in four of these BAD routes' AS path. > >3ffe:29a2::/32 >3ffe:2900:9::/48 >3ffe:2900:c005::/48 >3ffe:2900:ffe3::/48 > > >Now, as these do have Sprint in the AS path, we can see that the next AS in >the path is both accepting these routes, and propogating them back up. AS >8319 is a peer of Sprint, and Sprint is sending more specifics, and breaking >aggregation rules. > >This has been fixed. However one may argue that AS8319 could filter more >specifics from sprint, and help to alleviate this problem. I have adjusted >my outbound filters to compensate. SPRINT is at fault, but the upstream who >allowed them shares blame (AS8319). > >The theory that filtering is bad because it does not show bugs in your >system is no longer valid. If your IPv6 node is a single router, then you >shoudl not be a pTLA, but a leaf node. One's internal network should suffice >to test implementations. This way, it does not affect the rest of us. > >Every other route in this case does not even have Sprint in the AS path, >which means someone else (usually the Sprint downstream) is leaking the route >back up to their other upstreams. > >We have been trying to curtail this since orlando IETF. > >It is the fault of the upstream provider to allow these announcements out,a >nd the fault of EVERY PTLA in the AS path to allow these prefixes to be >transitted. If you cannot filter, then give back your pTLA please. This is a >testbed, but this is not a lab. You affect others when you break >aggregation. I will be glad to give you a transit connection, and some IPv6 >space to play. > > >I will be contacting each of my downstreams who are leaking bad routes, and >helping to get this fixed. If you have a lot of customers, please do the >same. People who are on the bad rotuing report more than usually are not to >blaim for most of the bad rotues. It is their downstream customers other >providers who have the problem. > >MERIT: Woudl it be possible to jog this report to start blaiming the AS who >is at fault, rather than the pTLA who cannot fix it? > > >The worst offenders: > >AS 4555 >AS 7680 >AS 11008 >AS 2852 > >IF you have these customers as direct downsteams, please filter them, for >the sake of the rest of us. > >Bob, perhaps we need to start actively policing this. I can see people on >the bad routing report who have been there since I first heard of IPv6, and >still refuse to filter. I will begin to take action on my pTLA. I encourage >the rest of you to do so as well. Write to me personally if you do not nkow >how/what to filter, and I can point you somewhere to learn. > > > > > > > > > > > > >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 bmah@CA.Sandia.GOV Thu Nov 4 21:47:47 1999 From: bmah@CA.Sandia.GOV (Bruce A. Mah) Date: Thu, 04 Nov 1999 13:47:47 -0800 Subject: pchar for v6 In-Reply-To: Your message of "Fri, 05 Nov 1999 02:35:26 +0900." <19991105023526P.sumikawa@ebina.hitachi.co.jp> Message-ID: <199911042147.NAA18735@nimitz.ca.sandia.gov> --==_Exmh_-420695554P Content-Type: text/plain; charset=us-ascii If memory serves me right, SUMIKAWA Munechika wrote: > > We, KAME developers, made port/pkgsrc of KAME-NetBSD and KAME-FreeBSD > > for easily installation. It will be distributed at next snap on Monday. > bmah> Cool. Does this mean that pchar works on NetBSD? On which platform(s) > ? > > Yes. We checked that it works on only KAME-NetBSD1.4.1-i386. OK, I'll make a note of that, thanks! > But, I got strage results in some situation. See #3 item in the > following results. Pchar reports minus Band Width. What happens? [snip] > prince:~% root pchar -p ipv6udp june.v6.wide.ad.jp > pchar to june.v6.wide.ad.jp (3ffe:501:0:801:290:27ff:fe61:b0dd) using UDP/IPv > 6 > Packet size increments by 32 to 1500 > 46 test(s) per repetition > 32 repetition(s) per hop > 0: > Partial loss: 0 / 1440 (0%) > Partial char: rtt = 0.502937 ms, (b = 0.002287 ms/B), r2 = 0.997345 > stddev rtt = 0.013819, stddev b = 0.000018 Hop char: rtt = 0.502937 ms, bw = 3498.514557 Kbps > Partial queueing: avg = 0.000084 ms (36 bytes) > 1: 3ffe:501:4819:8000:200:f8ff:fe04:5469 (3ffe:501:4819:8000:200:f8ff:fe04:5 > 469) > Partial loss: 194 / 1440 (13%) > Partial char: rtt = 22.162998 ms, (b = 0.015425 ms/B), r2 = 0.989061 > stddev rtt = 0.179215, stddev b = 0.000267 > Hop char: rtt = 21.660061 ms, bw = 608.906665 Kbps > Partial queueing: avg = 0.005603 ms (363 bytes) > 2: 3ffe:501:0:4800:21:6a39:6174:3 (paradise.karigome.wide.ad.jp) > Partial loss: 192 / 1440 (13%) > Partial char: rtt = 26.774703 ms, (b = 0.025138 ms/B), r2 = 0.996783 > stddev rtt = 0.157757, stddev b = 0.000235 > Hop char: rtt = 4.611704 ms, bw = 823.676532 Kbps > Partial queueing: avg = 0.003620 ms (144 bytes) > 3: 3ffe:501:0:1c01:200:f8ff:fe03:d9c0 (pc3.nezu.wide.ad.jp) > Partial loss: 4 / 1440 (0%) > Partial char: rtt = 47.038458 ms, (b = 0.024740 ms/B), r2 = 0.996857 > stddev rtt = 0.162686, stddev b = 0.000212 > Hop char: rtt = 20.263755 ms, bw = -20116.530889 Kbps > Partial queueing: avg = 0.009824 ms (397 bytes) > 4: 3ffe:501:0:801:290:27ff:fe61:b0dd (june.nara.wide.ad.jp) > Path length: 4 hops > Path char: rtt = 47.038458 ms, r2 = 0.996857 > Path bottleneck: 608.906665 Kbps > Path pipe: 3580 bytes > Path queueing: average = 0.009824 ms (397 bytes) What's happening here is that pchar has estimated the incremental time to send a byte to be 0.025138, three hops into the network. Normally you would expect this cost to increase for measurements going four hops into the network. However, this wasn't the case (to go four hops, the incremental time per byte was 0.024740). The inverse of the difference is the negative bandwidth estimate (-20 Mbps). This can happen in cases where you have differences in processing speed of routers, lots of loss or transient changes, or just poor curve fits. (Actually the least squares fit did pretty well, since the r2 parameter is pretty close to 1.) It isn't quite a bug, it's just a case that pchar doesn't know how to handle. I need to make a FAQ item on this...I've answered this question three times (in different forums) today. :-) Cheers, Bruce. PS. Actually if you could make up a tracefile with the -w option and send it to me, that'd be interesting to see. I can't promise it'll lead to a fix, but you never know.... --==_Exmh_-420695554P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: KxruldRedkGCdk1/uct5TNuPUJ7+tZL1 iQA/AwUBOCH/A9jKMXFboFLDEQI5qgCgxbKzywO+QFqdv/NCX9YKj7TqcFYAn3rY LEsyUi80OzxfQ/lvdGrunZpF =vbWh -----END PGP SIGNATURE----- --==_Exmh_-420695554P-- From fink@es.net Thu Nov 4 22:44:27 1999 From: fink@es.net (Bob Fink) Date: Thu, 04 Nov 1999 14:44:27 -0800 Subject: IPv6 Operational Topics Meeting in DC Message-ID: <4.1.19991104144051.00c395d0@imap2.es.net> At 09:50 AM 11/1/99 -0800, Bob Fink wrote: >IPv6 operational folk, > >Marc Blanchet and I will be hosting a one-hour mid-day IPv6 Operational >Topics Meeting during the Washington DC IETF week to discuss operational >ipv6-related topics. ... >We will announce the exact time/day and the agenda the lists as soon as we >can. Whatever the day, assume it will be in the same room that the IPng >will be in, which is currently the Regency. As the IPng meeting will be >Wed. and Thurs. from 1-3, the IPv6 Operational meeting will end just before >IPng starts, either Wed. or Thurs., depending on the day we choose. The IPv6 Operational Topics Meeting is now scheduled for Thursday from 11:45 till 12:45 in the Regency room. If the location changes I will let everyone know by email and by announcement at the IPng Wed. meeting. I still have time slots avaialable for a few more speakers. Please let me know if you wish to speak. Marc and I will be around for the Sunday Social, so you can speak with either of us there if you want. Thanks, Bob From sekiya@ISI.EDU Fri Nov 5 00:12:41 1999 From: sekiya@ISI.EDU (Yuji Sekiya) Date: Fri, 05 Nov 1999 09:12:41 +0900 Subject: Unaggregated prefixes in BGP4+ cloud In-Reply-To: In your message of "Wed, 03 Nov 1999 11:54:48 +0100" <9187FF572943D211B28100805FC130FC011DA857@xrr1.cselt.it> References: <9187FF572943D211B28100805FC130FC011DA857@xrr1.cselt.it> Message-ID: <14370.8441.12521.97176J@kanako.v6.linux.or.jp> At Wed, 03 Nov 1999 11:54:48 +0100, Guardini Ivano wrote: Hi all, > The ASs that are currently generating most of the unaggregated prefixes are: > > - AS7680 with 22 unaggregated prefixes > - AS4556 with 20 unaggregated prefixes AS4665 is ours. We are ISI/LAP,3ffe:800::/24. Sorry for poor aggregation. I will make filter for pTLA and sTLA. But , our CISCO router looks something strange. > show ipv6 route B 2001:200::0/35 [20/6] via FE80::C8E:50C2:10, Tunnel5, 1w3d/never B 2001:218::0/35 [20/4] via FE80::C8E:50C2:10, Tunnel5, 1w3d/never B 2001:400::0/35 [20/6] via FE80::C8E:50C2:10, Tunnel5, 1w3d/never All bgp routes have permanent expire time. So, any bogus BGP routes have never exipred. I don't understand whether our configuration is something wrong or IOSv6 have a bug. Does anyone have same experiences ? > Unfortunately I was not able to locate contact persons for AS7680 and AS4556 > in that they seem not to be registered in the 6bone database. The contact person for AS4556 IPv6 network is me. I apologize for our 6bone registry data is too old. I will revise them soon. -- SEKIYA Yuji USC/ISI Computer Networks Division 7 From kita@isl.intec.co.jp Fri Nov 5 01:50:13 1999 From: kita@isl.intec.co.jp (kita@isl.intec.co.jp) Date: Fri, 5 Nov 1999 10:50:13 +0900 (JST) Subject: Unaggregated prefixes in BGP4+ cloud In-Reply-To: <9187FF572943D211B28100805FC130FC011DA857@xrr1.cselt.it> Message-ID: <199911050150.KAA19354@king.noc.intec.co.jp> This is Yoshiaki Kitaguchi, one of administrators of AS7680 On October 22nd, we announced unexpected (unaggregated) IPv6 prefixes from AS7680 and we fixed the problem immediately. We DO NOT announce unaggregated prefixes now. But, it seems to be that these bogus routes remain in 6bone. A certain AS might not withdraw these bogus route, and still propagate them. We are contacting maintainers of some networks, to solve the problem. Best regards, Guardini Ivano wrote: >Hi all, > >during the last two weeks the number of unaggregated IPv6 prefixes >advertised >within the BGP4+ cloud is increased a lot (look at >http://carmen.cselt.it/ipv6/bgp/odd-routes.html >and http://carmen.cselt.it/ipv6/bgp/graphs/index.html) and I think that this >is a >very undesirable thing that should be fixed especially if we really consider >the 6bone as a >gymnasium for production use of IPv6. >The ASs that are currently generating most of the unaggregated prefixes are: > >- AS7680 with 22 unaggregated prefixes >- AS4556 with 20 unaggregated prefixes >- AS2852 (CESNET) with 8 unaggregated prefixes >- AS11008 (CENTAURI-AR) with 8 unaggregated prefixes > >Unfortunately I was not able to locate contact persons for AS7680 and AS4556 >in that they >seem not to be registered in the 6bone database. >The poor use of the 6bone registry is another critical issue that we should >try >to address especially for the sites participating in the BGP4+ cloud. For >example >I think that any pTLA or pNLA should make sure that any new downstream BGP4+ >peer >is correctly registered in the 6bone database before setting up the >connection. --- Yoshiaki Kitaguchi INTEC Systems Laboratory Inc. From Warren Matthews Fri Nov 5 03:47:42 1999 From: Warren Matthews (Warren Matthews) Date: Thu, 04 Nov 1999 19:47:42 -0800 (PST) Subject: IPv6 Network Monitoring Message-ID: I would like to monitor network performance to your IPv6 node. The pingER project has been gathering data on internet end-to-end performance for nearly 5 years and I am pleased to announce our monitoring software now runs on IPv6. We would like to get the PingER-6 project off the ground and gather some data. All we want from you is the name of an IPv6 machine and your permission to ping it. Details of PingER are available at http://www-iepm.slac.stanford.edu -------------------------------------------------------------------------- Warren Matthews If ease of use was the highest goal, Senior Network Specialist we'd all be driving golf carts. Stanford Linear Accelerator Center. - Larry Wall. From aljaz@iskratel.si Fri Nov 5 06:19:29 1999 From: aljaz@iskratel.si (Aljaz Tomaz RDSI) Date: Fri, 5 Nov 1999 07:19:29 +0100 Subject: pchar for v6 - problem Message-ID: <7E8519F1A7C0D211B0D200A0C93AA60F3D28CC@ntmail.iskratel.si> Hi! I have problem compiling pchar on Linux. I'm not a Linux expert so can anyone help me. Here is an error: c++ -g -O2 -I. -DSIZEOF_BOOL=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_STRINGo In file included from PctestIpv6Udp.h:40, from main.cc:53: PctestIpv6.h:77: field `targetAddress' has incomplete type PctestIpv6.h:78: field `targetSocketAddress' has incomplete type PctestIpv6.h:79: field `icmpDestSocketAddress' has incomplete type PctestIpv6.h:80: field `icmpSourceSocketAddress' has incomplete type main.cc: In function `int main(int, char **)': main.cc:537: warning: implicit declaration of function `int random(...)' make: *** [main.o] Error 1 Regrds, Tomaz From tkuiper@tobit.com Fri Nov 5 08:21:44 1999 From: tkuiper@tobit.com (tkuiper@tobit.com) Date: 05 Nov 99 08:21:44 UT Subject: Novell Netware IPv6 Implementation Message-ID: <199911050821.AAA20454@tnt.isi.edu> --------------1DD2510B41FE Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Does anyone know about an IPv6 Implementation for Novell Netware? I've send severall mails to Novell but all I get back is a pointer to some web sites which say its "going to be" built in into Netware 5 (documents are from this March). However, I didn't find any IPv6 stuff in the Netware 5 Version. Some real info would be welcome. Regards Thomas Kuiper Thomas Kuiper | tkuiper@tobit.com | __ Core Development | TK3680-RIPE | /__/\ Tobit Software GmbH | ICQ #8345483 | ask your server. \__\/ To: 6bone@ISI.EDU Cc: ipng@sunroof.eng.sun.com ipv6@uni-muenster.de --------------1DD2510B41FE-- From Ivano.Guardini@CSELT.IT Fri Nov 5 13:19:48 1999 From: Ivano.Guardini@CSELT.IT (Guardini Ivano) Date: Fri, 05 Nov 1999 14:19:48 +0100 Subject: odd routes report Message-ID: <9187FF572943D211B28100805FC130FC011DA860@xrr1.cselt.it> Itojun, yesterday night I fixed the problem with the odd routes page. Now the new prefixes (sTLA and 6to4) assigned by IANA and the Regional IRs are not marked any more as being invalid. Instead they are now listed in a new web page which is linked on the CSELT's Routing information home page (look at http://carmen.cselt.it/ipv6/bgp/index.html). After the Washington DC IETF I'll distribute a new version of ASpath-tree including all the above changes. Bye Ivano > ---------- > From: itojun@iijlab.net[SMTP:itojun@iijlab.net] > Sent: Monday, November 01, 1999 11:30 AM > To: ivano.guardini@cselt.it > Cc: 6bone@isi.edu > Subject: odd routes report > > http://carmen.cselt.it/ipv6/bgp/odd-routes.html > lists sTLA routes (like 2001:200::/35) as invalid prefixes. > Could you please update your software? > > itojun > From marcelo@sosa.com.ar Fri Nov 5 16:41:16 1999 From: marcelo@sosa.com.ar (Marcelo M. Sosa Lugones) Date: Fri, 5 Nov 1999 13:41:16 -0300 (ART) Subject: bad routing (fwd) Message-ID: Hello, this is the cc of a mail i sent to Rob Rockell. On Thu, 4 Nov 1999, Marcelo M. Sosa Lugones wrote: ->Hello Robert, -> ->> SPRINT (3ffe:2900::/24) had 10 route(s) ->> 3ffe:29a1::/64 path 1225 1103 786 1849 3251 1930 1251 4270 11008 ->> 3ffe:29a1:c::/48 path 1225 1103 786 1849 3251 1930 1251 4270 11008 ->> The worst offenders: ->> AS 11008 -> ->I am the mantainer of AS11008 in the 6bone, and i stopped announcing those ->routes some time ago, when i changed uplink from Horacio Pe#a to Patricio ->Latini (10318), two weeks ago from now, i shutdownd my bgp session with ->4270 because the matainer went to germany and we didn't want to make test ->with zebra and ipv6 if both were not available, so we shutdown the bgp ->session, and now i see that they are still anounced in the 6bone, but our ->session is down, i removed him (4270) from my bgp and i am only running ->bgp with Patricio Latini of Fibertel (10318) and he aggregates me. ->I dont want to disturb the 6bone, but now i am interested in knowing how ->long ago did this routes started being propagated to investigate the ->cause. -> ->Thanks, ->Marcelo M. Sosa Lugones From platini@fibertel.com.ar Fri Nov 5 20:50:08 1999 From: platini@fibertel.com.ar (Patricio Latini) Date: Fri, 5 Nov 1999 15:50:08 -0500 Subject: bad routing Message-ID: <006601bf27cf$dcd93840$770ae818@patis123sprynet.com> I agree with you Robert the problem is not yours, the problem is of the pTLAs that do not filter the upstreams from their sub TLAs and they inject a lot of unagregatted prefixes in the backbone. I think that some pTLAs should take more soriously their positiion in the 6bone and know that the stability of the entire 6 bone depens from all. Thanks Patricio Latini Fibertel TCI2 Buenos Aires - Argentina -----Original Message----- From: Robert J. Rockell To: 6bone@ISI.EDU <6bone@ISI.EDU> Date: Thursday, November 04, 1999 2:10 AM Subject: bad routing >Forewarning: if you are going to be offended by seeing your own AS in this >mail, do not read any further. > > >I will use my own example, so as to not affend anyone, but I did want to >mention something more regarding Ivano's mail about poorly aggregated >prefixes. Please consider the following excerpt from yesterday's report: > > SPRINT (3ffe:2900::/24) had 10 route(s) > 3ffe:2900:1::18/126 path 1225 1849 5539 4556 ( -- 100%) > 3ffe:2900:c:8::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%) > 3ffe:29a1::/64 path 1225 1103 786 1849 3251 1930 1251 4270 11008 > 3ffe:2900:1::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%) > 3ffe:2900:ffe3::/48 path 1225 1103 1200 8251 8731 8319 6175 7838 (USAA > 3ffe:2900:5::/48 path 1225 1312 (LORE/VT -- 100%) > 3ffe:29a1:c::/48 path 1225 1103 786 1849 3251 1930 1251 4270 11008 > 3ffe:2900:c005::/48 path 1225 1103 1200 8251 8731 8319 6175 11017 ( -- > 3ffe:2900:9::/48 path 1225 1103 1200 8251 8731 8319 6175 71 (HP -- 93%) > 3ffe:29a2::/32 path 1225 1103 1200 8251 8731 8319 6175 11261 (ASCI -- > >Looking at these, one may think "wow, Sprint sure is bad at aggregating it's >prefixes". However, if you look at this, one can see that SPrint's ASN >(6175) is only in four of these BAD routes' AS path. > >3ffe:29a2::/32 >3ffe:2900:9::/48 >3ffe:2900:c005::/48 >3ffe:2900:ffe3::/48 > > >Now, as these do have Sprint in the AS path, we can see that the next AS in >the path is both accepting these routes, and propogating them back up. AS >8319 is a peer of Sprint, and Sprint is sending more specifics, and breaking >aggregation rules. > >This has been fixed. However one may argue that AS8319 could filter more >specifics from sprint, and help to alleviate this problem. I have adjusted >my outbound filters to compensate. SPRINT is at fault, but the upstream who >allowed them shares blame (AS8319). > >The theory that filtering is bad because it does not show bugs in your >system is no longer valid. If your IPv6 node is a single router, then you >shoudl not be a pTLA, but a leaf node. One's internal network should suffice >to test implementations. This way, it does not affect the rest of us. > >Every other route in this case does not even have Sprint in the AS path, >which means someone else (usually the Sprint downstream) is leaking the route >back up to their other upstreams. > >We have been trying to curtail this since orlando IETF. > >It is the fault of the upstream provider to allow these announcements out,a >nd the fault of EVERY PTLA in the AS path to allow these prefixes to be >transitted. If you cannot filter, then give back your pTLA please. This is a >testbed, but this is not a lab. You affect others when you break >aggregation. I will be glad to give you a transit connection, and some IPv6 >space to play. > > >I will be contacting each of my downstreams who are leaking bad routes, and >helping to get this fixed. If you have a lot of customers, please do the >same. People who are on the bad rotuing report more than usually are not to >blaim for most of the bad rotues. It is their downstream customers other >providers who have the problem. > >MERIT: Woudl it be possible to jog this report to start blaiming the AS who >is at fault, rather than the pTLA who cannot fix it? > > >The worst offenders: > >AS 4555 >AS 7680 >AS 11008 >AS 2852 > >IF you have these customers as direct downsteams, please filter them, for >the sake of the rest of us. > >Bob, perhaps we need to start actively policing this. I can see people on >the bad routing report who have been there since I first heard of IPv6, and >still refuse to filter. I will begin to take action on my pTLA. I encourage >the rest of you to do so as well. Write to me personally if you do not nkow >how/what to filter, and I can point you somewhere to learn. > > > > > > > > > > > > >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 bmah@CA.Sandia.GOV Fri Nov 5 23:10:48 1999 From: bmah@CA.Sandia.GOV (Bruce A. Mah) Date: Fri, 05 Nov 1999 15:10:48 -0800 Subject: pchar for v6 - problem In-Reply-To: Your message of "Fri, 05 Nov 1999 07:19:29 +0100." <7E8519F1A7C0D211B0D200A0C93AA60F3D28CC@ntmail.iskratel.si> Message-ID: <199911052310.PAA27895@nimitz.ca.sandia.gov> --==_Exmh_23037560P Content-Type: text/plain; charset=us-ascii If memory serves me right, Aljaz Tomaz RDSI wrote: > I have problem compiling pchar on Linux. I'm not a Linux expert so can > anyone help me. Here is an error: > c++ -g -O2 -I. -DSIZEOF_BOOL=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 > -DHAVE_STRINGo > In file included from PctestIpv6Udp.h:40, > from main.cc:53: > PctestIpv6.h:77: field `targetAddress' has incomplete type > PctestIpv6.h:78: field `targetSocketAddress' has incomplete type > PctestIpv6.h:79: field `icmpDestSocketAddress' has incomplete type > PctestIpv6.h:80: field `icmpSourceSocketAddress' has incomplete type > main.cc: In function `int main(int, char **)': > main.cc:537: warning: implicit declaration of function `int random(...)' > make: *** [main.o] Error 1 You need to give a little more information...like what version of Linux you're running and the options you gave to the configure script. It sounds like the compile process isn't finding the definition for a "struct sockaddr_in6". Are you sure your kernel and libraries support IPv6? Caveat: I've never tested pchar for IPv6 under Linux. Bruce. --==_Exmh_23037560P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: 0E36NtGVYzdrB44riV9cyeFsQnAphZPZ iQA/AwUBOCNj+NjKMXFboFLDEQI8/gCeOXGx5gXHvktHbiQEYsNbSP3H7lsAmwW8 C7wJzh/F7iwLe9MUQOYbiMgm =pllk -----END PGP SIGNATURE----- --==_Exmh_23037560P-- From bmanning@ISI.EDU Sat Nov 6 03:58:02 1999 From: bmanning@ISI.EDU (Bill Manning) Date: Fri, 5 Nov 1999 19:58:02 -0800 (PST) Subject: wierdness at cisco Message-ID: <199911060358.TAA15647@zed.isi.edu> Before the reaper culls the chaff, is there anyone at cisco who is aware that the cisco mail gateway is -rejecting- about 20 registered cisco email entries on the 6bone@isi.edu list? -- "When in doubt, Twirl..." -anon From Arthur Harris" I am located in the US (Ashland, Massachusetts )with have dedicated IPV4 connection to the internet. This is a request to establish an IPV6-IPV4 tunnel with an other site in Massachusetts. Thank you in advance, Arthur Harris harris@shawn.com From aljaz@iskratel.si Mon Nov 8 06:18:34 1999 From: aljaz@iskratel.si (Aljaz Tomaz RDSI) Date: Mon, 8 Nov 1999 07:18:34 +0100 Subject: pchar for v6 - problem Message-ID: <7E8519F1A7C0D211B0D200A0C93AA60F3D28D4@ntmail.iskratel.si> Hi! > -----Original Message----- > From: bmah@CA.Sandia.GOV [mailto:bmah@CA.Sandia.GOV] > Sent: Saturday, November 06, 1999 12:11 AM > To: Aljaz Tomaz RDSI > Cc: 6BONE List > Subject: Re: pchar for v6 - problem > > > If memory serves me right, Aljaz Tomaz RDSI wrote: > > > I have problem compiling pchar on Linux. I'm not a Linux > expert so can > > anyone help me. Here is an error: > > c++ -g -O2 -I. -DSIZEOF_BOOL=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 > > -DHAVE_STRINGo > > In file included from PctestIpv6Udp.h:40, > > from main.cc:53: > > PctestIpv6.h:77: field `targetAddress' has incomplete type > > PctestIpv6.h:78: field `targetSocketAddress' has incomplete type > > PctestIpv6.h:79: field `icmpDestSocketAddress' has incomplete type > > PctestIpv6.h:80: field `icmpSourceSocketAddress' has incomplete type > > main.cc: In function `int main(int, char **)': > > main.cc:537: warning: implicit declaration of function `int > random(...)' > > make: *** [main.o] Error 1 > > You need to give a little more information...like what > version of Linux > you're running and the options you gave to the configure script. > I'm using kernel 2.2.1 with experminetal IPv6 support. Linux is my main router to 6bone and provides stateles avtoconfiuration for IPv6 hosts, ... ./configure --with-ipv6 > It sounds like the compile process isn't finding the definition for a > "struct sockaddr_in6". Are you sure your kernel and libraries support > IPv6? > > Caveat: I've never tested pchar for IPv6 under Linux. > > Bruce. > > > > From bmah@CA.Sandia.GOV Mon Nov 8 16:50:34 1999 From: bmah@CA.Sandia.GOV (Bruce A. Mah) Date: Mon, 08 Nov 1999 08:50:34 -0800 Subject: pchar for v6 - problem In-Reply-To: Your message of "Mon, 08 Nov 1999 07:18:34 +0100." <7E8519F1A7C0D211B0D200A0C93AA60F3D28D4@ntmail.iskratel.si> Message-ID: <199911081650.IAA40391@nimitz.ca.sandia.gov> --==_Exmh_1945414072P Content-Type: text/plain; charset=us-ascii If memory serves me right, Aljaz Tomaz RDSI wrote: > > > I have problem compiling pchar on Linux. I'm not a Linux > > expert so can > > > anyone help me. Here is an error: > > > c++ -g -O2 -I. -DSIZEOF_BOOL=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 > > > -DHAVE_STRINGo > > > In file included from PctestIpv6Udp.h:40, > > > from main.cc:53: > > > PctestIpv6.h:77: field `targetAddress' has incomplete type > > > PctestIpv6.h:78: field `targetSocketAddress' has incomplete type > > > PctestIpv6.h:79: field `icmpDestSocketAddress' has incomplete type > > > PctestIpv6.h:80: field `icmpSourceSocketAddress' has incomplete type > > > main.cc: In function `int main(int, char **)': > > > main.cc:537: warning: implicit declaration of function `int > > random(...)' > > > make: *** [main.o] Error 1 > > > > You need to give a little more information...like what > > version of Linux > > you're running and the options you gave to the configure script. > > > I'm using kernel 2.2.1 with experminetal IPv6 support. Linux is my main > router to 6bone and provides stateles avtoconfiuration for IPv6 hosts, ... > > ./configure --with-ipv6 OK...if your IPv6 libraries are in the right place this shouldn't be a problem. I wrote: > > It sounds like the compile process isn't finding the definition for a > > "struct sockaddr_in6". Are you sure your kernel and libraries support > > IPv6? I think this might be your problem. One of the Linux machines I test on (RedHat 5.2 I think) doesn't have definitions for the sockaddr_in6 or in6_addr structures. Another one (heavily customized Debian?) *does* have them. My guess is that your header files don't have the right structure definitions and may need updating to something that's more in line with RFC 2553 ("Basic Socket Interface Extensions for IPv6"). I'm more a daemon-type person than a penguin-type person, so I might not be able to tell you much else that's useful. Hope this helps at least a little bit... Bruce. --==_Exmh_1945414072P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: 5QFAo/1TQ6J6IofqUV2Gmf0FJ3lRJjm/ iQA/AwUBOCb/WtjKMXFboFLDEQLBPQCeJS/bwqlfGun9L6pVA7Jb8iiSdZoAnjKH /6zv4kkGuenSDGje1cD8rUjB =0kEX -----END PGP SIGNATURE----- --==_Exmh_1945414072P-- From jason@jax-inc.com Tue Nov 9 06:49:54 1999 From: jason@jax-inc.com (Jason S. Bogin) Date: Tue, 9 Nov 1999 01:49:54 -0500 Subject: New to the 6bone mailing list... Message-ID: <003901bf2a7e$a0c6eb20$0264a8c0@mediaone.net> Hello everyone, I am an undergraduate student (graduating this term, starting master's next term) at the University of North Florida at the College of Computing Sciences and Engineering. I have spent a number of years in networking and have focused my college curriculum accordingly. I have undertaken an independent study at UNF on IPv6 under the supervision of Mr. Paul Higbee (phigbee@unf.edu). I have done extensive research and software configuration on Windows NT and Linux using experimental IPv6 stacks. The University of North Florida has allowed me to configure a Cisco router to communicate with the 6bone through our computer network. They have granted me a static IPv4 address to assign to a Cisco 2501 router and tunnel to the 6bone network. I am in need of assistance in making arrangements with the closest IPv4-to-IPv6 peer. Can anyone here guide me in the right direction? Thank you, Jason S. Bogin, CNE, MCSE University of North Florida College of Computing Sciences and Engineering http://www.unf.edu bogj0001@unf.edu jason@jax-inc.com From jason@jax-inc.com Tue Nov 9 15:12:16 1999 From: jason@jax-inc.com (Jason S. Bogin) Date: Tue, 9 Nov 1999 10:12:16 -0500 Subject: New to the 6bone mailing list... In-Reply-To: <85256824.004EE973.00@metlife.com> Message-ID: <000001bf2ac4$cf4622e0$0264a8c0@mediaone.net> http://research.microsoft.com/msripv6/ http://research.microsoft.com/msripv6/newreg.asp There you go! Thanks, Jason -----Original Message----- From: Carlos Davila [mailto:cdavila@metlife.com] Sent: Tuesday, November 09, 1999 9:32 AM To: jason@jax-inc.com Subject: Re: New to the 6bone mailing list... Jason, Where did you get your IPV6 stack for your NT workstation. Carlos From fink@es.net Tue Nov 9 22:06:14 1999 From: fink@es.net (Bob Fink) Date: Tue, 09 Nov 1999 14:06:14 -0800 Subject: reminder of IPv6 Ops Topics meeting THURSDAY, 11:45-12:45, Regency Room prior to IPng Message-ID: <4.1.19991109135723.015e7a60@imap2.es.net> This is just a reminder of the: IPv6 Ops Topics meeting Thursday 11:45-12:45 Regency Room (where IPng will meet when we are done) I may have misled some that it was Wed., but it is THURSDAY. Current agenda: (but Marc Blanchet and I are still changing/adding/...) 6bone cleanup/hardening Rob Rockell - HARDEN and routes (along with Ivano) What registry enhancements do we want David Kessens (mainly responding to change ideas) Production sTLA allocation Kengo NAGAHASHI - net allocs in JP Bob Fink - 6PAPA process PingER for IPv6 Bob Fink (get people to volunteer pingable hosts) v6-Exchanges Itojun et al - IPv6 exchange in Japan Marc Blanchet - 6TAP Thanks, Bob From kunihiro@zebra.org Wed Nov 10 16:18:18 1999 From: kunihiro@zebra.org (Kunihiro Ishiguro) Date: Wed, 10 Nov 1999 08:18:18 -0800 Subject: reminder of IPv6 Ops Topics meeting THURSDAY, 11:45-12:45, Regency Room prior to IPng In-Reply-To: In your message of "Tue, 09 Nov 1999 14:06:14 -0800" <4.1.19991109135723.015e7a60@imap2.es.net> References: <4.1.19991109135723.015e7a60@imap2.es.net> Message-ID: <14377.39626.630252.26482Z@vaio.zebra.org> Hi, this is Kunihiro Ishiguro. >6bone cleanup/hardening > Rob Rockell - HARDEN and routes (along with Ivano) I know there are several ugly routes in current 6bone. Definitely it is an operational issue (announce routes which shouldn't be announced). Adding to that I'm thinking there could be an BGP-4+ implementation issue. Even though originator stopped the announcement, it seems that some routes never disappear from the 6bone. Let me show an example. Todays BGP-4+ logging information at Merit shows that: http://www.merit.net/mail.archives/html/6bone-routing-report/msg00596.html ========================================================================== Poorly Aggregated Prefixes (>24 in 3ffe:0000::/17 or >28 in 3ffe:8000::/17): Format: Prefix path AS-Path (Origin-AS -- Availability) -------------------------------- WIDE (3ffe:500::/24) had 18 route(s) 3ffe:508:0:3::/64 path 1225 2547 559 5408 1752 3185 786 1849 2839 237 7680 ( -- 0%) 3ffe:508:0:2::/64 path 1225 2547 559 5408 1752 3185 786 1849 2839 237 7680 ( -- 0%) 3ffe:508:1::/64 path 1225 2547 559 5408 1752 3185 786 1849 2839 237 7680 ( -- 0%) 3ffe:508::/64 path 1225 2547 559 5408 1752 3185 786 1849 2839 237 7680 ( -- 0%) 3ffe:503:1050::/48 path 1225 2547 559 5408 1752 3185 786 1849 2839 237 7680 ( -- 0%) 3ffe:508:5::/48 path 1225 2547 559 5408 1752 3185 786 1849 2839 237 7680 ( -- 0%) I'm sure that originator already stopped the announcement. So the bad guy is not the originator at this moment. I'm thinking there may be an router which never forget BGP-4+ routes. And worse, those routes are flapping!. The logging shows it is 0% life time. The routes are withdrawn right after the announcement. So it is hard to find the problem. When you type `show ipv6 bgp' like command from your terminal interface, it will not be shown. Let me call those routes as `zombie routes'. If we have time, I and Mr. Ikuo Nakagawa talk about this problem at IPv6 Ops Topics meeting. -- Kunihiro Ishiguro From tallship@access1.net Thu Nov 11 02:10:19 1999 From: tallship@access1.net (Bradley D. Thornton) Date: Wed, 10 Nov 1999 18:10:19 -0800 Subject: reminder of IPv6 Ops Topics meeting THURSDAY, 11:45-12:45, Regency Room prior to IPng References: <4.1.19991109135723.015e7a60@imap2.es.net> Message-ID: <382A258B.B90C253F@access1.net> Bob Fink wrote: > This is just a reminder of the: > > IPv6 Ops Topics meeting > Thursday > 11:45-12:45 > Regency Room > (where IPng will meet when we are done) Whoa, I must have missed something while I was out of town last week. That's this Thursday in the Regency Room of What Hotel, What city? > > > -- ,,, (o o) |----------------------oOO-(_)-OOo-------------------------| | Bradley D. Thornton "So foul a sky clears | | Mgr NetWork Services not without a storm" | | NOMAD Internetwork - Shakespeare - | | www.linboard.com | |----------------------------------------------------------| |-----On the Beaches of Super Sunny Southern California----| |==========================================================| From fink@es.net Thu Nov 11 03:51:33 1999 From: fink@es.net (Bob Fink) Date: Wed, 10 Nov 1999 19:51:33 -0800 Subject: reminder of IPv6 Ops Topics meeting THURSDAY, 11:45-12:45, Regency Room prior to IPng In-Reply-To: <382A258B.B90C253F@access1.net> References: <4.1.19991109135723.015e7a60@imap2.es.net> Message-ID: <4.2.2.19991110195023.01c82f00@imap2.es.net> --=====================_26704028==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 06:10 PM 11/10/99 -0800, Bradley D. Thornton wrote: >Bob Fink wrote: > > > This is just a reminder of the: > > > > IPv6 Ops Topics meeting > > Thursday > > 11:45-12:45 > > Regency Room > > (where IPng will meet when we are done) > >Whoa, I must have missed something while I was out of town last week. >That's this Thursday in the Regency Room of What Hotel, What city? This is at the IETF meeting. If you don't know where that is, you don't need to worry about it :-) Bob --=====================_26704028==_.ALT Content-Type: text/html; charset="us-ascii" At 06:10 PM 11/10/99 -0800, Bradley D. Thornton wrote:
Bob Fink wrote:

> This is just a reminder of the:
>
>        IPv6 Ops Topics meeting
>               Thursday
>              11:45-12:45
>             Regency Room
> (where IPng will meet when we are done)

Whoa, I must have missed something while I was out of town last week.
That's this Thursday in the Regency Room of What Hotel, What city?


This is at the IETF meeting. If you don't know where that is, you don't need to worry about it :-)


<http://www.ietf.org/meetings/directions.html>


Bob
--=====================_26704028==_.ALT-- From fink@es.net Tue Nov 16 01:17:07 1999 From: fink@es.net (Bob Fink) Date: Mon, 15 Nov 1999 17:17:07 -0800 Subject: 6bone pTLA request from DTI starts 2-week review, closes 29 Nov 99 Message-ID: <4.2.2.19991115170655.00cb45c0@imap2.es.net> 6bone Folk, DTI (Dream Train Internet) in Japan has applied for a pTLA, thus I'm opening a two week review of their pTLA request (see below). This closes on 29 Nov 99. Note that this request is being made using the HARDEN I-D, not RFC 2546, which are more stringent that 2546: I think this is appropriate as this I-D passed WG last call last Monday and will be forwarded soon to the IESG to replace 2546. Thanks, Bob ==== >To: fink@es.net >Cc: koji@dti.ad.jp, kay@v6.access.co.jp >Subject: pTLA request from DTI >From: Koji Kondo X-Mailer: Mew version 1.95b3 on Emacs >20.3 / Mule 4.0 (HANANOEN) >Date: Tue, 16 Nov 1999 09:57:54 +0900 > >Hi, > >We, DTI, would like to request a pTLA prefix. >In draft-ietf-ngtrans-harden-01.txt Chapter 7: > > 1. The pTLA Applicant must have a minimum of three (3) months > qualifying experience as a 6Bone end-site or pNLA transit. > During this entire qualifying period the Applicant must be > operationally providing the following: > >We are a transit pNLA site under the WIDE pTLA since August 1998. >Now, we have 6bone connectivity as follows, >- some pTLAs peering with BGP4+ at NSPIXP6(IPv6-based IX in Tokyo). >- some NLAs peering with BGP4+ or RIPng. > > 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. > >ipv6-site object is DTI. >inet6num object is 3FFE:50A::/32. >mntner object is MNT-DTI. > > b. Fully maintained, and reliable, BGP4+ peering and connec- > tivity between the Applicant's boundary router with the > appropriate hierarchy. This includes a high uptime > availability of the site router (greater than 99%). This > router must be IPv6 pingable. > >We maintain BGP4+ router(ix6.v6.dti.ad.jp) at NSPIXP6 in tokyo and have >high uptime availability. > > c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > entries for their site's router, and at least one host ser- > ver system. > >DNS forward (AAAA) and reverse (ip6.int) are available. > > d. A fully maintained, and reliable host server system providing, > at a mimimum, one or more web pages describing the applicant's > project and service on the 6Bone, available via IPv6. This > server must be IPv6 pingable. > >Web page is available. This server can connect via IPv4 and IPv6, >and IPv6 pingable. > > 2. The pTLA Applicant MUST have the ability and intent to provide > "production-like" 6Bone backbone service to provide a robust > and operationally reliable 6Bone backbone. Applicants must pro- > vide a statement and some supportable information to support > this claim. This MUST include the following: > >We are now providing connectivity services to three IPv6 leaf sites. >Our connection details is available at >"http://www.v6.dti.ad.jp/connections.html" . > > a. a support staff of two persons minimum, 3 preferable, with > person attributes registered for each in the ipv6-site object > for the pTLA applicant. > >Person attributes are "KK1-6BONE" and "ST1-6BONE". > > b. a common mailbox for support contact purposes that all staff > have acess to , pointed to with a notify attribute in the ipv6- > site object for the pTLA Applicant. > >All of staffs have accesstable mailbox both via ipv4 and ipv6. > > 3. The pTLA Applicant MUST have a potential "user community" that > would be served by 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 some > supportable information to support this claim. > >We are one of the major ISPs in Japan. And already offering connectivity >to three IPv6 leaf sites(see above "connection details page"). > > 4. The pTLA Applicant MUST commit to abide by the current 6Bone > operational rules and policies as they exist at time of appli- > cation, and agree to abide by future 6Bone backbone operational > rules and policies as they evolve by consensus of the 6Bone > backbone and user community. > >We will commit to abide by the 6Bone backbone operational rules and >policies. > >regards, >koji From ipversion6@mail.com Tue Nov 16 13:33:01 1999 From: ipversion6@mail.com (Edward Verweij) Date: Tue, 16 Nov 1999 08:33:01 -0500 (EST) Subject: Tokenring Message-ID: <388074987.942759181916.JavaMail.root@web01.pub01> Hi, For my company I’m busy with research on IPv6. I always see configurations with Ethernet. Does anyone have experience with a tokenring network? Is er anyone how has experience with tokering to Ethernet routers en vice versa? And is the Cisco 2500 and 2600 series capable of upgrading to IPv6. Specially the 2502, 2513 and 2612. Thanks, Edward __________________________________________________ FREE Email for ALL! Sign up at http://www.mail.com From fink@es.net Tue Nov 16 16:13:53 1999 From: fink@es.net (Bob Fink) Date: Tue, 16 Nov 1999 08:13:53 -0800 Subject: PingERv6 participants needed Message-ID: <4.2.2.19991116080558.01969790@imap2.es.net> This is a reminder to 6bone (and other IPv6 providers) that there is an excellent service now available for IPv6 networks that has been of great use (in its IPv4 form) to the inernational Energy Research networking community of labs, universities and other collaborators around the world. So please re-read :-) Warren Matthews email below, and help us provide PingERv6 service. The www-iepm web pages at SLAC, provide an excellent overview as wellas access to some really need performance data about IPv4. So let's get started to collect IPv6 data as well. Thanks, Bob === Date: Thu, 04 Nov 1999 19:47:42 -0800 (PST) From: Warren Matthews Subject: IPv6 Network Monitoring To: 6bone@ISI.EDU Cc: iepm@SLAC.Stanford.EDU I would like to monitor network performance to your IPv6 node. The pingER project has been gathering data on internet end-to-end performance for nearly 5 years and I am pleased to announce our monitoring software now runs on IPv6. We would like to get the PingER-6 project off the ground and gather some data. All we want from you is the name of an IPv6 machine and your permission to ping it. Details of PingER are available at http://www-iepm.slac.stanford.edu -------------------------------------------------------------------------- Warren Matthews If ease of use was the highest goal, Senior Network Specialist we'd all be driving golf carts. Stanford Linear Accelerator Center. - Larry Wall. -end From Latif LADID" Yes, please speak directly to Jens (copied above) at Ericsson Telebit about the impelemntation of IPv6 over Token-ring. /Latif -----Original Message----- From: Edward Verweij To: 6bone@ISI.EDU <6bone@ISI.EDU> Date: Tuesday, November 16, 1999 05:15 Subject: Tokenring :Hi, : :For my company I’m busy with research on IPv6. I always see configurations :with Ethernet. Does anyone have experience with a tokenring network? :Is er anyone how has experience with tokering to Ethernet routers en vice :versa? : :And is the Cisco 2500 and 2600 series capable of upgrading to IPv6. :Specially the 2502, 2513 and 2612. : :Thanks, : :Edward : :__________________________________________________ :FREE Email for ALL! Sign up at http://www.mail.com : : From ji@research.att.com Tue Nov 16 17:17:06 1999 From: ji@research.att.com (John Ioannidis) Date: Tue, 16 Nov 1999 12:17:06 -0500 (EST) Subject: I need a tunnel for AT&T Labs - Research Message-ID: <199911161717.MAA09899@bual.research.att.com> Our network provider is UUNET (I know, it's funny), and we're hanging off one of their Newark pops. Here are the few lines of a traceroute: # traceroute 135.207.1.1 ... 11 101.ATM6-0.TR1.EWR1.ALTER.NET (146.188.136.186) 9.771 ms 11.417 ms 8.731 ms 12 200.ATM7-0.XR1.EWR1.ALTER.NET (146.188.176.77) 10.160 ms 9.868 ms 9.102 ms 13 193.ATM9-0-0.GW1.EWR1.ALTER.NET (146.188.176.41) 11.744 ms 11.699 ms 11.945 ms 14 attfp-gw.customer.ALTER.NET (157.130.0.178) 13.407 ms 14.029 ms 12.789 ms Thanks, /ji From Marc.Blanchet@viagenie.qc.ca Wed Nov 17 03:17:32 1999 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Tue, 16 Nov 1999 22:17:32 -0500 Subject: I need a tunnel for AT&T Labs - Research In-Reply-To: <199911161717.MAA09899@bual.research.att.com> Message-ID: <4.2.2.19991116221613.0439a230@mail.viagenie.qc.ca> JI, we are also with uunet. We can provide you a tunnel. I'll continue that conversation off this list. Please send email to our ipv6 group at ipv6@viagenie.qc.ca Regards, Marc. At 12:17 99-11-16 -0500, John Ioannidis wrote: >Our network provider is UUNET (I know, it's funny), and we're hanging off >one of their Newark pops. Here are the few lines of a traceroute: > ># traceroute 135.207.1.1 >... >11 101.ATM6-0.TR1.EWR1.ALTER.NET (146.188.136.186) 9.771 ms 11.417 >ms 8.731 ms >12 200.ATM7-0.XR1.EWR1.ALTER.NET (146.188.176.77) 10.160 ms 9.868 >ms 9.102 ms >13 193.ATM9-0-0.GW1.EWR1.ALTER.NET (146.188.176.41) 11.744 ms 11.699 >ms 11.945 ms >14 attfp-gw.customer.ALTER.NET (157.130.0.178) 13.407 ms 14.029 >ms 12.789 ms > >Thanks, > >/ji ----------------------------------------------------------- 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 fink@es.net Wed Nov 17 20:59:32 1999 From: fink@es.net (Bob Fink) Date: Wed, 17 Nov 1999 12:59:32 -0800 Subject: PingERv6 data In-Reply-To: References: <4.2.2.19991117103308.00cadc60@imap2.es.net> Message-ID: <4.2.2.19991117125730.00cbc440@imap2.es.net> --=====================_192682451==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:34 PM 11/17/99 -0800, Warren Matthews wrote: >Indeed there has been a wonderful response. We are now monitoring 26 nodes >all around the world. > >For the links, please point to > > http://www-iepm.slac.stanford.edu/monitoring/6ren/ > >This page will (eventually) have discussion as well as a link to the >report. Cool! No,fantastic! Great work. It's now got a pointer on the 6bone pages: Thanks, Bob --=====================_192682451==_.ALT Content-Type: text/html; charset="us-ascii" At 12:34 PM 11/17/99 -0800, Warren Matthews wrote:

Indeed there has been a wonderful response. We are now monitoring 26 nodes
all around the world.

For the links, please point to

  http://www-iepm.slac.stanford.edu/monitoring/6ren/

This page will (eventually) have discussion as well as a link to the
report.


Cool! No,fantastic! Great work.

It's now got a pointer on the 6bone pages:

 <http://6bone.net>


Thanks,

Bob
--=====================_192682451==_.ALT-- From Ivano.Guardini@CSELT.IT Thu Nov 18 09:40:12 1999 From: Ivano.Guardini@CSELT.IT (Guardini Ivano) Date: Thu, 18 Nov 1999 10:40:12 +0100 Subject: (ngtrans) Working Group last call for BROKER-02, closes 1 Dec 99 Message-ID: <9187FF572943D211B28100805FC130FC011DA879@xrr1.cselt.it> Matt, draft-ietf-ngtrans-broker-02 is intended to be framework document describing the guidelines for the provision of a Tunnel Broker service within the Internet. For this reason it does not specifies any protocol or MIME type but details the general architecture of the proposed approach and outlines a set of available alternatives for implementing it. Anyway I agree with you when you say that the use of a newly defined MIME type to deliver the tunnel parameters to the client is a very attractive alternative which is certainly worth envisaging. But I think that such an effort should be the subject of a companion document to be published on the standards track. What I can certainly do in broker-02 is to add a few sentences clarifying that the MIME-based approach you propose is a valuable alternative for the implementation of the broker-client interaction and that for this reason the definition of a new MIME type to deliver tunnel configuration parameters is strongly recommended. In addition I can better clarify in the security considerations that the use of .bat or shell scripts to configure the client is frightening insecure and should be considered only for early implementations of the Tunnel Broker approach. Bye Ivano > ---------- > From: Matt Crawford[SMTP:crawdad@fnal.gov] > Reply To: Matt Crawford > Sent: Wednesday, November 17, 1999 11:52 PM > To: NGtrans List > Subject: Re: (ngtrans) Working Group last call for BROKER-02, closes > 1 Dec 99 > > Sorry, Bob and authors, but I don't think there's enough material > there to publish as an RFC unless you define the format of the tunnel > parameters returned to the client. I've been saying for a year now > that there ought to be such a definition and it should be client- > platform independent. (To preserve the attractive convenience -- and > frightening insecurity -- of sending over a .BAT file or shell > script, the response might be a MIME multipart/alternative.) > > Matt > From tkuiper@tobit.com Thu Nov 18 14:20:38 1999 From: tkuiper@tobit.com (tkuiper@tobit.com) Date: 18 Nov 99 14:20:38 UT Subject: Fun with Novell and IPv6 Message-ID: <199911181420.GAA09941@tnt.isi.edu> --------------1DD2510B41FE Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Since I try to get IPv6 running with Netware (its one of the main reasons I try IPv6 here and connected to 6bone) I tried once again to find someone who could tell me about a Novell Netware implementation for IPv6. So I tried forums.novell.com (NNTP). I can only see this issue with a bit sarcasm, but, read ahead. Subject: No IPv6 for Netware? Date: Wed, 17 Nov 1999 09:49:18 +0100 From: Thomas Kuiper Organization: Tobit Software Newsgroups: novell.generaltcpip Hi, I've been looking around for a Netware IPv6 Stack but couldn't find it either on Netware 5 or somewhere on the Novell site. Are there any IPv6 implementations for Netware? On http://developer.novell.com/research/appnotes/1997/march/03/04.htm its noted that there is "going to be" support for it in the next generation of products (Netware 5?). Also NTP is mentioned there as upcoming feature, but I didn't find IP Security/NTP or IPv6 inside Netware 5. Best regards, Thomas Kuiper ~~~ First reply: Subject: Re: No IPv6 for Netware? Date: Wed, 17 Nov 1999 08:29:34 -0500 From: Michael Bell Organization: Novell Support Connection Forums Newsgroups: novell.generaltcpip NTP is built into TIMESYNC as of SP1 or 2. IPv6 -- no, I think this is still not available. Michael J. Bell Novell Support Connection Volunteer Sysop ~~~ Second reply: Subject: Re: No IPv6 for Netware? Date: Wed, 17 Nov 1999 08:56:23 EST From: Joseph Moore [SysOp] Organization: Novell Support Connection Forums Newsgroups: novell.generaltcpip I don't think IPv6 is available for NetWare yet. Joe Moore Novell Support Connection Volunteer Sysop http://www.joenettroll.net/network.html http://www.planetall.com/main.asp?s=3D1043&cid=3D223904 http://www.planetall.com/main.asp?cid=3D223904&gid=3D40734&s=3D40 NO EMAIL PLEASE!!!!! ~~~ Third reply: Subject: Re: No IPv6 for Netware? Date: Wed, 17 Nov 1999 20:21:29 -0700 From: Craig Johnson Organization: Novell Support Connection Forums Newsgroups: novell.generaltcpip Ipv6 isn't there yet. I believe that is still 'in development'. Craig Johnson Novell Support Connection SysOp ~~~~~~~~~~~~~~~~~ cut here ~~~~~~~~~~~~~~~~~~~~~~~~~ so I thought: wow, hm, 2 support guys of Novell say "I *think* its not done yet" and one says "I BELIEVE(!) its in development", lets ask them for a time. So I wrote: Subject: Re: No IPv6 for Netware? Date: Wed, 17 Nov 1999 15:53:04 +0100 From: Thomas Kuiper Organization: Tobit Software Newsgroups: novell.generaltcpip I really would like to know but nobody at Novell could tell me this. There are the specs... ~~~ and the best reply I have ever seen from a support guy: Subject: Re: No IPv6 for Netware? Date: Thu, 18 Nov 1999 06:00:08 EST From: Joseph Moore [SysOp] Organization: Novell Support Connection Forums Newsgroups: novell.generaltcpip Thomas Kuiper : Well, none of us work for Novell...so we don't know either. Joe Moore Novell Support Connection Volunteer Sysop http://www.joenettroll.net/network.html http://www.planetall.com/main.asp?s=3D1043&cid=3D223904 http://www.planetall.com/main.asp?cid=3D223904&gid=3D40734&s=3D40 NO EMAIL PLEASE!!!!! ~~~~~~~~~~~~~~~~~ cut here ~~~~~~~~~~~~~~~~~~~~~~~~~ why couldn't they say that in the first place :( Novell has a contact listed about IPv6 on: http://playground.sun.com/ipng/ipng-implementations.html#Novell if you try to mail him postmaster@novell.com sends you back that andy@novell.com isn't valid anymore :-< So IPv6 got dropped at all now at Novell or what? Only one document from 1997 on their server telling it will be availiable "in a future release". I'm lost now. It would be really wonderfull if someone could tell me what is going on at Novell with IPv6. Gruss/Regards, Thomas Thomas Kuiper | tkuiper@tobit.com | www.tobit.com __ Core Development | TK3680-RIPE | /__/\ Tobit Software GmbH | ICQ #8345483 | ask your server. \__\/ To: join@uni-muenster.de ipng@sunroof.eng.sun.com 6bone@isi.edu Cc: jokes@irc.ircnet.dk dv@engerim.dachbu.de --------------1DD2510B41FE-- From fink@es.net Mon Nov 22 17:02:09 1999 From: fink@es.net (Bob Fink) Date: Mon, 22 Nov 1999 09:02:09 -0800 Subject: draft minutes of IPv6 Ops Topics meeting at IETF46 in Wash DC Message-ID: <4.2.2.19991122071805.00cf4a40@imap2.es.net> 6bone and ngtrans folk, This is the first draft of the IPv6 Ops Topics meeting held during the noon break on Thursday at the IETF. This is an extension of the ngtrans/6bone activity to attempt to generalize our operational experience to include early production networks. Please forgive my forgetting peoples names and scrambled events, but Thanksgiving preparations have made me forgetful (or was it old age?). Anyway, please send me corrections, additions, etc. Thanks, Bob === IPv6 Operational Topics meeting IETF46 in Wash DC 11 November 1999 ___ Organizers: Bob Fink Marc Blanchet This ngtrans meeting reported by Marc Blanchet and Bob Fink. Attendance was estimated as 75-100. Bob Fink chaired the meeting. This meeting is actually part of the ngtrans/6bone activity, but designed to focus a little more on general operational topics beyond just the 6bone, e.g., 6REN and other early production IPv6 nets, hence the title "IPv6 Ops Topics". Bob Fink asked attendees if they had any preference as to how this meeting be held in future IETFs. Matt Crawford suggested under the IEPG, to which Bob noted that he and Marc had given some IPv6 presentations at at this IETF, but was not sure this was the best time as there is limited attendance on Sundays. ___ Zombie routes in 6bone Ikuo Nakagawa and Kunihiro Ishiguro spoke on the phenomenon they called Zombie routes, which are non-aggregated routes that happened to be announced from somewhere, but not actually the neighbor forwarding them, and they are not even in the ASpath. The behavior is that the originator has announced once, but no more announce it, but someone propagates infinitely. It is most liekly a bug in some routing code. To fix one has to find which site and then find which code they run and then upgrade ASAP. Marc Blanchet noted that we should not fingerpoint at people, rather we should try to collaborate, as we always have on the 6bone. Francis Dupont pointed out the need to move to the latest BGP4+ draft. Ivano Guardini commented that aggregration has to be fixed as it is currently very poor. Rob Rockell commented that most problems can be fixed by filtering. He asked if we should do a draft on how to filter? William Maton note that onecould use the registry and RPSL to help filtering. ___ 6bone Registry David Kessens noted that he was going to (or was it "able to") provide a web interface to help people filtering in config files. Joan ? noted that the inet6num object is used by RIPE-NCC and APNIC, but not ARIN at this time. David Kessens noted that a subgroup of db-rpsl works on the ipv6 features in the current registry. He will do a script to automatically fetch v6 objects from RIR registries. Alain Durand commented that if we provide tools for filtering, then people will be interested in updating their objects. W. Wober commented that instead of throwing away problems by upgrading software, we should fix the problems. ___ WIDE IPv6 addressing architecture ?? presented an overview of the WIDE IPv6 addressing architecture. The WIDE production subTLA (2001:200::/35) has been divided into 2 spaces: NLA1 divided at /31 for ISPs NLA2 divided at /48 for end-sites 2001:200:0::/48 is used for the backbone Use policies are: not for commerce do not connect to grand-children orgs must announce aggregated routes must report the status of IPv6 utilisation of each org must update registry database ___ 6PAPA Bob Fink noted that he had written the 6papa-00 I-D (under ngtrans) to formalize the RIR-6bone pre-qualification process. An updated version will follow soon which will be then sent to WG last call for forwarding to the IESG as an Informational RFC. ___ NSPIXP-6 v6 exchange in Japan Akiro Kato gave an overview of the NSPIXP-6 IPv6 exchange in Japan. experimental purpose: route server, IX-based address single FE switch 5 ISPs connected: 2 sTLAs, 2 NLA1s extensions via ATM/FE bridge, using ATM network via apan/transpac to startap, to Korea, Singapore and Malaysia It was noted that there are v6-exchanges at: 6tap, Chicago NAP/STAR TAP NSPIXP-6, Japan AMS-IX - Amsterdam/ND plans for New York/US, Palo Alto/US ___ PingERv6 Bob Fink briefly noted that the US Energy Research PingER (over IPv4) project lead by SLAC now supports IPv6. Ping statistics are gathered with extensive data basing, analysis and graphical display. Bob asked people to send host addresses to be pinged, or ping sources, as had been previously announced on the 6bone list. -end From hansolofalcon@worldnet.att.net Tue Nov 23 01:03:58 1999 From: hansolofalcon@worldnet.att.net (Gregg C Levine) Date: Mon, 22 Nov 1999 20:03:58 -0500 Subject: Linux operating system kernel versions Message-ID: <01BF3524.BA445B40.hansolofalcon@worldnet.att.net> Hello from Gregg C Levine usually at Jedi Knight Computers What is the current version of the kernel for the Linux distributions, that support IPv6? I see a driver/module for Slackware versions 4.0 to 7.0, and those two, inconclusive are using version 2.0.34. Naturally the methods described by that driver/module may not be current. I only need to know what the current kernel version is, that support IPv6. Gregg C Levine mailto:hansolofalcon@worldnet.att.net "They were in the wrong place, at the wrong time, naturally they became heroes." Princess Leia Organna of Alderann, Senator "Remember, the Force will be with you." Obi-Wan(Ben) Kenobi, Jedi Knight and, General, (Retired) From rzm@icm.edu.pl Tue Nov 23 04:29:58 1999 From: rzm@icm.edu.pl (Rafal Maszkowski) Date: Tue, 23 Nov 1999 05:29:58 +0100 Subject: Linux operating system kernel versions In-Reply-To: <01BF3524.BA445B40.hansolofalcon@worldnet.att.net>; from hansolofalcon@worldnet.att.net on Mon, Nov 22, 1999 at 08:03:58PM -0500 References: <01BF3524.BA445B40.hansolofalcon@worldnet.att.net> Message-ID: <19991123052958.D17971@burza.icm.edu.pl> On Mon, Nov 22, 1999 at 08:03:58PM -0500, Gregg C Levine wrote: > Hello from Gregg C Levine usually at Jedi Knight Computers > What is the current version of the kernel for the Linux distributions, that > support IPv6? I see a driver/module for Slackware versions 4.0 to 7.0, and 2.2.x or development (dangerous) version 2.3.x . Don't know about Slackware, RedHat 6.x includes kernels from 2.2 series but you have to compile it yourself from original or RedHat modified sources with IPv6 turned on. R. -- Ale kto by my³ rêce po przywitaniu siê z mê¿em? - A. Fedorczyk From venaas@itea.ntnu.no Tue Nov 23 06:10:49 1999 From: venaas@itea.ntnu.no (Stig Venaas) Date: Tue, 23 Nov 1999 07:10:49 +0100 Subject: Linux operating system kernel versions In-Reply-To: <01BF3524.BA445B40.hansolofalcon@worldnet.att.net>; from Gregg C Levine on Mon, Nov 22, 1999 at 08:03:58PM -0500 References: <01BF3524.BA445B40.hansolofalcon@worldnet.att.net> Message-ID: <19991123071049.A16237@itea.ntnu.no> On Mon, Nov 22, 1999 at 08:03:58PM -0500, Gregg C Levine wrote: > Hello from Gregg C Levine usually at Jedi Knight Computers > What is the current version of the kernel for the Linux distributions, that > support IPv6? I see a driver/module for Slackware versions 4.0 to 7.0, and > those two, inconclusive are using version 2.0.34. Naturally the methods 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 brian@entropy.net Tue Nov 23 07:35:27 1999 From: brian@entropy.net (Brian Russo) Date: Mon, 22 Nov 1999 21:35:27 -1000 Subject: Linux operating system kernel versions In-Reply-To: <01BF3524.BA445B40.hansolofalcon@worldnet.att.net>; from hansolofalcon@worldnet.att.net on Mon, Nov 22, 1999 at 08:03:58PM -0500 References: <01BF3524.BA445B40.hansolofalcon@worldnet.att.net> Message-ID: <19991122213527.A21748@cornflake.entropy.net> --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Mon, Nov 22, 1999 at 08:03:58PM -0500, Gregg C Levine wrote: > Hello from Gregg C Levine usually at Jedi Knight Computers > What is the current version of the kernel for the Linux distributions, th= at=20 > support IPv6? I see a driver/module for Slackware versions 4.0 to 7.0, an= d=20 > those two, inconclusive are using version 2.0.34. Naturally the methods= =20 > described by that driver/module may not be current. I only need to know= =20 > what the current kernel version is, that support IPv6. > Gregg C Levine mailto:hansolofalcon@worldnet.att.net The 2.2.x series has support for IPV6 Remember you will have to set CONFIG_EXPERIMENTAL when configuring the kernel so that IPV6 support is available as an option. hope this helps. --=20 +-----------------------------------------------------------+ | Brian Russo | | UH High Energy Physics Group | | PGP Key Available at http://www.entropy.net/~brian/pgpkey | +-----------------------------------------------------------+ --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3a iQCVAwUBODpDv1p0S0uDjJllAQE4RAP+OlzjsuN1H3MktarJuBDwazop+VSh7yri aL6EK/5EuQ/yiR+lR1ppmAQ9kG2qTVisZiq1tUcz4hzfxGyjQUNpUMMHVllnjrLC oRMgjx8mH3obUkTja63CsbbLQu2U33Tv4xA5jQ5eBthAABOvd1JU4iJwyeBpSpkl h8+z3wfdegY= =FMnH -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From sgunderson@bigfoot.com Tue Nov 23 10:12:36 1999 From: sgunderson@bigfoot.com (Steinar H. Gunderson) Date: Tue, 23 Nov 1999 10:12:36 +0000 Subject: Linux operating system kernel versions In-Reply-To: <19991123052958.D17971@burza.icm.edu.pl>; from rzm@icm.edu.pl on Tue, Nov 23, 1999 at 05:29:58AM +0100 References: <01BF3524.BA445B40.hansolofalcon@worldnet.att.net> <19991123052958.D17971@burza.icm.edu.pl> Message-ID: <19991123101236.A16351@kg.vgs.no> On Tue, Nov 23, 1999 at 05:29:58AM +0100, Rafal Maszkowski wrote: >2.2.x or development (dangerous) version 2.3.x . Don't know about Slackware, >RedHat 6.x includes kernels from 2.2 series but you have to compile it yourself >from original or RedHat modified sources with IPv6 turned on. Slackware 4.0 and up (at least) includes 2.2.x kernel. Slackware 7.0 and up uses glibc2 instead of libc5 as the main C library. /* Steinar */ From hermans@touro.edu Tue Nov 23 08:31:04 1999 From: hermans@touro.edu (Herman Strom) Date: Tue, 23 Nov 1999 03:31:04 -0500 (EST) Subject: Linux operating system kernel versions In-Reply-To: <19991123052958.D17971@burza.icm.edu.pl> Message-ID: Hi! I am working with Slackware 6.3-beta. It runs on Linux 2.2.12 and 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. I am on linux-net@vger.rutger.edu list and I asked there afew question. One of the people from Finland answered me. He has patches that fix the above problems and also do few good thing besides it. But unfortunately, again, the patch is old for Linux-2.1.131. And my finnish friend doesn't have time to rewrite it. Tell me if you want to do the job. And I will provide you with the necessary information. Thanks, 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, Rafal Maszkowski wrote: On Mon, Nov 22, 1999 at 08:03:58PM -0500, Gregg C Levine wrote: > Hello from Gregg C Levine usually at Jedi Knight Computers > What is the current version of the kernel for the Linux > distributions, that support IPv6? I see a driver/module for > Slackware versions 4.0 to 7.0, and 2.2.x or development (dangerous) version 2.3.x . Don't know about Slackware, RedHat 6.x includes kernels from 2.2 series but you have to compile it yourself from original or RedHat modified sources with IPv6 turned on. R. -- Ale kto by my³ rêce po przywitaniu siê z mê¿em? - A. Fedorczyk From venaas@itea.ntnu.no Tue Nov 23 11:29:57 1999 From: venaas@itea.ntnu.no (Stig Venaas) Date: Tue, 23 Nov 1999 12:29:57 +0100 Subject: Linux operating system kernel versions In-Reply-To: ; from Herman Strom on Tue, Nov 23, 1999 at 03:31:04AM -0500 References: <19991123052958.D17971@burza.icm.edu.pl> Message-ID: <19991123122957.A7072@itea.ntnu.no> On Tue, Nov 23, 1999 at 03:31:04AM -0500, Herman Strom wrote: > Hi! > > I am working with Slackware 6.3-beta. It runs on Linux 2.2.12 and > 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. I am on > linux-net@vger.rutger.edu list and I asked there afew question. One of > the people from Finland answered me. He has patches that fix the above > problems and also do few good thing besides it. But unfortunately, > again, the patch is old for Linux-2.1.131. And my finnish friend > doesn't have time to rewrite it. > > Tell me if you want to do the job. And I will provide you with the > necessary information. I'm not aware of these problems, give me the info and I'll have a look at it. Stig -- Stig Venaas UNINETT/NTNU From kuznet@ms2.inr.ac.ru Tue Nov 23 16:19:52 1999 From: kuznet@ms2.inr.ac.ru (kuznet@ms2.inr.ac.ru) Date: Tue, 23 Nov 1999 19:19:52 +0300 (MSK) Subject: Linux operating system kernel versions In-Reply-To: from "Herman Strom" at Nov 23, 99 03:31:04 am Message-ID: <199911231619.TAA30449@ms2.inr.ac.ru> 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 timothy.b.whitmore@lmco.com Wed Nov 24 21:47:35 1999 From: timothy.b.whitmore@lmco.com (Whitmore, Timothy B) Date: Wed, 24 Nov 1999 16:47:35 -0500 Subject: No subject Message-ID: <40D23851A09ED211B3430000F8081AD0031BED52@emss04m16.ems.lmco.com> http://www.nola.com/cgi-bin/nola_cards/getmycard.cgi?1.39552694703179e+17.ht ml Tim Whitmore Network System Design Lockheed Martin GES tel: (609) 722-7378 fax: (609) 273-5379 From mkshin@pec.etri.re.kr Fri Nov 26 02:45:29 1999 From: mkshin@pec.etri.re.kr (Myung-Ki Shin) Date: Fri, 26 Nov 1999 11:45:29 +0900 Subject: ETRI, sTLA, 2001:230::/35 Message-ID: <383DF449.71AF0115@pec.etri.re.kr> Dear IPv6 members. I'm Myung-Ki Shin from ETRI, Korea. We got 2001:230::/35 sTLA block from APNIC. Right now, We start renumbering from ETRI pTLA (3ffe:2e00::/24). In addition, In near future, we will assign the IPv6 addresses to IMT-2000 network and Cable network or ADSL ISPs in Korea. Thanks, Myung-Ki. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Myung-Ki Shin | mkshin@pec.etri.re.kr ETRI/PEC | 161 Kajong-Dong, Yusong-Gu, | Taejon, 305-390, Korea | Tel:+82-42-860-4847 | FAX:+82-42-861-5404 | http://pec.etri.re.kr/~mkshin/ From Latif.LADID@village.uunet.lu Fri Nov 26 07:52:08 1999 From: Latif.LADID@village.uunet.lu (Latif LADID) Date: Fri, 26 Nov 1999 08:52:08 +0100 Subject: ETRI, sTLA, 2001:230::/35 In-Reply-To: <383DF449.71AF0115@pec.etri.re.kr> Message-ID: <4.2.0.58.19991126084210.00a70a50@j.pop.uunet.lu> Thanks Myung-Ki! Congratulations! Yes, we saw your announcement on the automatic counter, see www.ipv6forum.com section project / assigned subTLAs getting you to http://www.dfn.de/service/ipv6/ipv6aggis.html The subTLA race is as follows: Europe: 9 Asia : 8 US : 3 Total : 20 in 4 months What's wrong with the US? The land of of pioneers and leadership..... R, /Latif At 11:45 AM 26/11/99 +0900, Myung-Ki Shin wrote: >Dear IPv6 members. > >I'm Myung-Ki Shin from ETRI, Korea. > >We got 2001:230::/35 sTLA block from APNIC. >Right now, We start renumbering from ETRI pTLA (3ffe:2e00::/24). > >In addition, In near future, >we will assign the IPv6 addresses to IMT-2000 >network and Cable network or ADSL ISPs in Korea. > >Thanks, >Myung-Ki. >-- >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Myung-Ki Shin | mkshin@pec.etri.re.kr >ETRI/PEC | 161 Kajong-Dong, Yusong-Gu, > | Taejon, 305-390, Korea > | Tel:+82-42-860-4847 > | FAX:+82-42-861-5404 > | http://pec.etri.re.kr/~mkshin/ > From dlitz@cheerful.com Sat Nov 27 20:34:03 1999 From: dlitz@cheerful.com (Dwayne C . Litzenberger) Date: Sat, 27 Nov 1999 14:34:03 -0600 Subject: newbie: need tunnel for dialup/dynamic Message-ID: <19991127143403.A3166@dlitz.dyn.dhs.org> --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'm a relative newbie to IPv6, and I'd like to get my home network on the 6bone, but I have a dial-up dynamic IP address. I'm running Linux 2.2, if that matters. Anyway, anyone know where I can get a good tunnel? 2 mainrouter.cableregina.com (204.83.142.1) 119.862 ms 108.877 ms 129.= 921 ms 3 spc-tor-8-Hssi9-1-1.Sprint-Canada.Net (206.186.248.29) 129.857 ms 128= .881 ms 129.928 ms 4 core-spc-tor-2-POS4-0-0.Sprint-Canada.Net (204.50.128.22) 154.534 ms = 134.079 ms 149.870 ms 5 204.50.128.38 (204.50.128.38) 129.889 ms 161.941 ms 146.845 ms 6 sl-gw21-pen-6-0-0.sprintlink.net (144.228.178.29) 149.864 ms 138.838 = ms 169.854 ms 7 sl-bb13-pen-2-2.sprintlink.net (144.232.5.133) 179.843 ms 158.851 ms = 195.503 ms --=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://DLitzPower.tripod.com/spamoff.htm GnuPG Public Key: http://DLitzPower.tripod.com/gpgkey.asc Fingerprint: 0535 F7CF FF5F 8547 E5A5 695E 4456 FB6C BC39 A4B0 --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4QEA7RFb7bLw5pLARAdCIAJ9SxqSPg1Qi2MQqvyJVLpU+6PsGtACfU1Tl XAQ0Kbh0QrgbSG3A3eNdGTQ= =OKVm -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From rrockell@sprint.net Sun Nov 28 21:54:41 1999 From: rrockell@sprint.net (Robert J. Rockell) Date: Sun, 28 Nov 1999 16:54:41 -0500 (EST) Subject: some more help (fwd) Message-ID: These questions were posed to the IPv6 Forum, but I wanted to forward, as this arena may be optimal for Operations Experience. Please feel free to write to the original author directly. (jordi@consulintel.se) 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? ---------- Forwarded message ---------- Date: Sun, 28 Nov 1999 20:55:32 +0100 From: JORDI PALET MARTINEZ To: IPv6 Deployment List , education@ipv6forum.com, tech@ipv6forum.com Subject: some more help >From the answers I got as response to my last email, I will like somebody taking a few minutes to describe the following problems: - Multi-homing problem. What's the problem (from the user point of view), and what alternatives we have to solve it ? - Is fixed length addressing the right approach ? why yes or why not ? Alternatives ? - DHCPv6 according to the IETF DHCP WG (not for the IPng WG). What's the problem ? - Use of scopes for unicast IPv6 addresses as far as nailing down how they are used and deployed. What this will mean ? - Still need to deploy and test IPv6 Multicast protocols. It means that Multicast protocol isn't tested enough ? I hope some of you can take a few minutes to describe your point of view on these issues, or provide me some direct links that already talk on these ... I will like to finish this work before end of this week, so I can present the document on the next Berlin GIS. Please copy to anybody that do you think can give a good think and isn't in these list ... Thanks and best regards, Jordi Palet Consulintel http://www.consulintel.es Tel: 91 858 75 09 - Fax: 91 858 76 31 From fink@es.net Tue Nov 30 01:58:24 1999 From: fink@es.net (Bob Fink) Date: Mon, 29 Nov 1999 17:58:24 -0800 Subject: new 6bone pTLA 3FFE:8080::/28 assigned to DTI Message-ID: <4.2.2.19991129175220.00c4e860@imap2.es.net> I would like to announce the assignment of a pTLA to DTI(Dream Train Internet) in Japan, based on comments received during the open review period ending 29 November 1999. --- DTI is the Dream Train Internet ISP in Japan. 3FFE:8080::/28 netname: DTI --- Welcome DTI to the 6bone backbone! Bob From masaki@merit.edu Tue Nov 30 03:53:38 1999 From: masaki@merit.edu (Masaki Hirabaru) Date: Mon, 29 Nov 1999 22:53:38 -0500 Subject: bad routing In-Reply-To: <006601bf27cf$dcd93840$770ae818@patis123sprynet.com> References: <006601bf27cf$dcd93840$770ae818@patis123sprynet.com> Message-ID: <19991129225338Y.masaki@merit.edu> Hi. Patricio, >> >MERIT: Woudl it be possible to jog this report to start blaiming the AS who >> >is at fault, rather than the pTLA who cannot fix it? I thought request is reasonable, so I tried to find my time to improve our report script. Today, I did it. New report will be delivered later today. To do it, the script had to know which AS is a backbone (pTLA). The information is retrieved from 6bone db but it may be inaccurate or incomplete and there may be a delay. (Since our report is not intended to blame someone, so please allow this inaccuracy.) The right most pTLA's AS (or the left most AS if there is no pTLA AS) appeared in the path of a poorly aggregated prefix will be listed to be a candidate who allows this first. If the pTLA allows prefixes within its pTLA, the entry will be listed with "*". (Note that even if the pTLA fixes its filter, the same route may be appeared through another pTLA in the next report.) I also modified a part of the report which lists reserved AS numbers used in 6bone. This part now lists unknown AS numbers that are not registered in 6bone db. (This will result in listing reserved AS numbers, too.) The same modification was applied to unknown prefixes. It now lists prefixes not registered in 6bone db. I hope this helps 6bone hardening. Masaki IPMA Project Here is a part of the report generated with data up to now today. > Subject: 11/29/99 6Bone Routing Report > To: 6bone-routing-report@merit.edu > From: owner-6bone-routing-report@merit.edu > > See http://www.merit.edu/ipma for a more detailed report on routing > problems and recommendations on ways service providers can limit the > spread of invalid routing information. > Send comments and questions to ipma-support@merit.edu > > To unsubscribe from this list, send mail to > 6bone-routing-report-request@merit.edu. > A hypermail archive is available at > http://www.merit.net/mail.archives/html/6bone-routing-report/ > > Also see http://www.caida.org for more information about Internet > statistics collection research efforts. > > --------------------------------------------- > This report is for 11/29/99, peering with > VIAGENIE (AS10566) CISCO (AS109) IDIR (AS11264) CICNET (AS1225) WIDE (AS2500) SICS (AS2839) MIT-SIPB (AS3) TELEBIT (AS3263) ETRI (AS3559) CERNET (AS4538) 6COM (AS561) MSR-REDMOND (AS5761) UUNET-US (AS704) CAIRN (AS7081) NUS-IRDU (AS7610) RADIX (AS7680) > --------------------------------------------- > > Size of 6Bone Routing Table: > Max = 97, Min = 94, Average = 94 > 60 pTLAs (in 3ffe::/16), 7 sTLAs (in 2001::/16) > 83 Unique Autonomous System (AS) numbers > > BGP4+ Traffic Summary: > Announcements = 200865 Withdraws = 32470 Unique Routes = 109 > > Unknown AS Numbers (not in 6bone registry): > Format: AS-Path (Unknown-AS-Number -- Availability) > -------------------------------- > 10566 1930 3243 (3243 -- 100%) > 1225 1275 559 8933 1122 (1122 -- 48%) > 1225 1849 1103 766 8933 1122 1121 (1122 1121 -- 26%) > 3 145 4557 (4557 -- 35%) > 3 145 6509 (6509 -- 1%) > 561 5408 10566 6509 818 (6509 818 -- 29%) > > Unknown Prefixes (not in 6bone registry): > Format: Prefix path AS-Path (Origin-AS -- Availability) > -------------------------------- > 0000::/0 path 1225 1673 (ANSNET -- 0%) > 0000::/0 path 561 5408 1752 3185 786 1103 1849 4697 (NTT-ECL -- -71%) > 0200::/1 path 10566 5408 1752 3185 786 1103 1849 4697 (NTT-ECL -- 30%) > 1000::/4 path 561 5408 10566 237 1225 1673 (ANSNET -- 8%) > 1800::/4 path 1225 1673 (ANSNET -- 0%) > 2000::/6 path 109 1251 1930 10566 5408 1752 3185 786 2547 2547 1225 1673 237 7610 3425 2500 (WIDE -- 47%) > 2002::/16 path 5761 (MSR-REDMOND -- 100%) > 5f0c:bf00::/32 path 7610 3462 3263 (TELEBIT -- 2%) > ::35e0/120 path 7610 3462 3263 (TELEBIT -- 2%) > > Poorly Aggregated Announcements (>24 in 3ffe:0000::/17 or >28 in 3ffe:8000::/17 or >35 in 2001::/16): > Format: Prefix path AS-Path (Origin-AS -- Availability) > asterisk(*) means the route is within its pTLA > -------------------------------- > SWITCH (AS559) announced 4 route(s) > 3ffe:8034:80::/48 path 1225 1275 559 8933 1122 ( -- 48%) > 3ffe:1108:800::/40 path 1225 1275 559 8933 3172 (USOT-ECS -- 48%) > 3ffe:8038::/34 path 1225 1275 559 8933 (QTPVSIX -- 48%) > 3ffe:803c::/34 path 1225 1275 559 8933 3172 (USOT-ECS -- 48%) > > CICNET (AS1225) announced 4 route(s) > * 3ffe:900:1::/48 path 1225 1312 (LORE/VT -- 99%) > * 3ffe:900:2::/48 path 1225 3899 (CHICO -- 100%) > 3ffe:2900:5::/48 path 1225 1312 (LORE/VT -- 99%) > 3ffe:2802::/32 path 1225 1312 (LORE/VT -- 99%) > > SICS (AS2839) announced 4 route(s) > 3ffe:2610:2::/48 path 2839 3274 8432 (TF-INET-DEV -- 100%) > 3ffe:2610:5::/48 path 2839 3274 5469 (AHLSTROM -- 100%) > 3ffe:1001:60::/48 path 2839 3274 3336 (HTC -- 100%) > 3ffe:2620::/32 path 2839 1741 (FUNET/OTOL/VTTMPOLI -- 95%) > > IPF (AS5409) announced 3 route(s) > 3ffe:3001:3::/48 path 109 5409 8731 8251 (CISTRON -- 98%) > 3ffe:604:5::/48 path 109 5409 8731 8251 (CISTRON -- 98%) > * 3ffe:3400:100::/48 path 109 5409 8731 (SGH-NET -- 98%) > > MIT-SIPB (AS3) announced 3 route(s) > 3ffe:28ff:4::/48 path 3 (MIT-SIPB -- 80%) > 3ffe:2801::/32 path 3 145 5050 (PSC-GP -- 80%) > 3ffe:2803::/32 path 3 145 4557 ( -- 35%) > > JOIN (AS1275) announced 2 route(s) > 3ffe:2100:1:17::/64 path 1225 1275 (JOIN -- 88%) > 3ffe:3400:300::/48 path 1225 1275 5424 (GST/RMACH/FX/CHRIST/LAX/JSB/FIDENTIA-AT/WAECHTER-AT/GEORG-AT/TIVISION-AT/T0-AT/COGIDATA-AT/TCTL-AT/MEDHOST-AT/SWSCHMIEDE-AT/ENEMY-AT/DUNSHIRN-AT/ATNET-AT -- 12%) > > REDIRIS (AS766) announced 1 route(s) > 3ffe:8034:c0::/48 path 1225 1849 1103 766 8933 1122 1121 ( -- 26%) > > VIAGENIE (AS10566) announced 1 route(s) > 3ffe:400:d0::/47 path 561 5408 10566 6509 818 ( -- 29%) > > RCCN (AS1930) announced 1 route(s) > * 3ffe:3102::/48 path 10566 1930 3243 ( -- 100%) > > TELEBIT (AS3263) announced 1 route(s) > 3ffe:2280:4::/48 path 7610 3462 3263 2852 (CESNET -- 2%) > > BT-LABS (AS1752) announced 1 route(s) > 3ffe:2101::/48 path 10566 5408 1752 3185 (ULANC -- 99%) > > REGIO-DE (AS8319) announced 1 route(s) > 3ffe:400:1c0::/48 path 2839 3274 8319 (REGIO-DE -- 100%) > > GRNET (AS5408) announced 1 route(s) > * 3ffe:2d00:b::/48 path 10566 5408 8617 (AEGEAN -- 99%) > > SPACENET-DE (AS5539) announced 1 route(s) > 3ffe:1402:1:1::/64 path 1225 1103 5539 1273 (NAHENET/ECRC -- 20%) > > ICM-PL (AS8664) announced 1 route(s) > 3ffe:902::/32 path 1225 8664 (ICM-PL -- 98%) > > UUNET-US (AS704) announced 1 route(s) > 3ffe:1108:1400::/40 path 704 (UUNET-US -- 100%) > > 6COM (AS561) announced 1 route(s) > * 3ffe:1900:9::/48 path 561 11261 (ASCI -- 66%) > > Prefixes from Different Origin AS: > Format: Prefix path AS-Path (Origin-AS -- Availability) > -------------------------------- > BAY (3ffe:1300::/24) path 561 10318 (FIBERTEL -- 59%) > BAY (3ffe:1300::/24) path 1225 6175 (SPRINT -- 100%) > VIAGENIE (3ffe:b00::/24) path 10566 (VIAGENIE -- 100%) > VIAGENIE (3ffe:b00::/24) path 3 145 6509 ( -- 1%) > > The Top Five Most Active Prefixes (more than 1000 changes): > Format: AS-Path (Announce/Withdraw -- Availability) > ---------------------------------- > 1. SICS (3ffe:200::/24) had 31737 BGP+ updates (28 unique aspaths) > 2839 (904/0 -- 100%) > 7610 3425 293 5609 2839 (49/2 -- 98%) > 3 10566 6175 3274 2839 (3904/8 -- 98%) > 2500 2500 2500 33 5609 2839 (27/15 -- 70%) > 109 33 5609 2839 (3/0 -- 69%) > 7081 293 5609 2839 (4540/1627 -- 42%) > 10566 6175 3274 2839 (3955/909 -- 29%) > 5761 6175 3274 2839 (897/891 -- 29%) > 109 1849 5623 2839 (1/0 -- 28%) > 561 10318 1849 5623 2839 (5/5 -- 26%) > 1225 1275 1835 2839 (995/417 -- 15%) > ...Truncated... > > 2. G6 (3ffe:300::/24) had 16546 BGP+ updates (29 unique aspaths) > 10566 1930 559 1717 (4415/60 -- 99%) > 2839 1835 1717 (888/0 -- 99%) > 3 10566 1930 559 1717 (4397/21 -- 98%) > 7081 5409 559 1717 (1173/3 -- 97%) > 1225 1275 1717 (948/4 -- 88%) > 109 1849 786 1717 (3/0 -- 72%) > 7610 3425 293 1275 1717 (49/0 -- 66%) > 2500 2500 2500 109 1849 786 1717 (10/10 -- 53%) > 7610 1849 786 1717 (3/1 -- 32%) > 109 5409 559 1717 (2/0 -- 27%) > 561 10318 1849 786 1717 (2/2 -- 26%) > ...Truncated... > > 3. UIO (3ffe:2a00::/24) had 15200 BGP+ updates (68 unique aspaths) > 2839 224 (887/0 -- 100%) > 7610 3425 293 5609 2839 224 (49/1 -- 98%) > 3 10566 6175 3274 2839 224 (2735/1 -- 98%) > 2500 2500 2500 33 5609 2839 224 (28/16 -- 70%) > 7081 293 5609 2839 224 (2234/0 -- 58%) > 109 33 5609 2839 224 (3/0 -- 47%) > 7081 6175 3274 2839 224 (234/1 -- 41%) > 10566 6175 3274 2839 224 (2772/892 -- 30%) > 5761 6175 3274 2839 224 (880/735 -- 30%) > 109 1849 5623 2839 224 (2/0 -- 20%) > 1225 1275 1835 2839 224 (1002/288 -- 15%) > ...Truncated... > > 4. UNI-C (3ffe:1400::/24) had 15039 BGP+ updates (51 unique aspaths) > 2839 1835 (901/0 -- 99%) > 7610 3425 293 1275 1835 (46/1 -- 96%) > 1225 1275 1835 (782/21 -- 83%) > 7081 293 1275 1835 (469/3 -- 78%) > 2500 2500 2500 33 3462 3263 1835 (25/15 -- 70%) > 3 10566 1930 559 1717 1835 (1658/1 -- 70%) > 109 5409 559 1717 1835 (6/0 -- 63%) > 561 5609 2839 1835 (5/5 -- 35%) > 3 10566 1930 559 1275 1835 (386/0 -- 27%) > 7081 5409 559 1717 1835 (1284/3 -- 21%) > 109 5409 559 1275 1835 (1/0 -- 20%) > ...Truncated... > > 5. JOIN (3ffe:400::/24) had 8777 BGP+ updates (26 unique aspaths) > 4538 1275 (6/1 -- 100%) > 2839 1835 1275 (663/0 -- 92%) > 1225 1275 (949/0 -- 88%) > 7610 3425 293 1275 (49/0 -- 66%) > 2500 2500 2500 33 1225 1275 (803/599 -- 61%) > 109 4556 1225 1275 (3/0 -- 60%) > 10566 5408 559 1275 (422/3 -- 50%) > 10566 1930 559 1275 (3356/0 -- 49%) > 7081 293 1275 (16/0 -- 47%) > 561 5609 1225 1275 (4/3 -- 45%) > 3 145 7081 293 1275 (1/0 -- 33%) > ...Truncated... > > From rrockell@sprint.net Tue Nov 30 04:32:21 1999 From: rrockell@sprint.net (Robert J. Rockell) Date: Mon, 29 Nov 1999 23:32:21 -0500 (EST) Subject: bad routing In-Reply-To: <19991129225338Y.masaki@merit.edu> Message-ID: This will go a long way to improving the stability of the 6bone as a whole Thank you very much. p.s. if you still want to run the old report, it will give pTLA's the chance to pressure downstreams that are leaking. Thanks again!! 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 Mon, 29 Nov 1999, Masaki Hirabaru wrote: ->Hi. Patricio, -> ->>> >MERIT: Woudl it be possible to jog this report to start blaiming the AS who ->>> >is at fault, rather than the pTLA who cannot fix it? -> ->I thought request is reasonable, so I tried to find my time to ->improve our report script. Today, I did it. New report will be ->delivered later today. To do it, the script had to know which AS ->is a backbone (pTLA). The information is retrieved from 6bone db ->but it may be inaccurate or incomplete and there may be a ->delay. (Since our report is not intended to blame someone, so ->please allow this inaccuracy.) -> ->The right most pTLA's AS (or the left most AS if there is no pTLA ->AS) appeared in the path of a poorly aggregated prefix will be ->listed to be a candidate who allows this first. If the pTLA ->allows prefixes within its pTLA, the entry will be listed with ->"*". (Note that even if the pTLA fixes its filter, the same ->route may be appeared through another pTLA in the next report.) -> ->I also modified a part of the report which lists reserved AS ->numbers used in 6bone. This part now lists unknown AS numbers ->that are not registered in 6bone db. (This will result in listing ->reserved AS numbers, too.) -> ->The same modification was applied to unknown prefixes. It now ->lists prefixes not registered in 6bone db. -> ->I hope this helps 6bone hardening. ->Masaki ->IPMA Project -> ->Here is a part of the report generated with data up to now today. -> ->> Subject: 11/29/99 6Bone Routing Report ->> To: 6bone-routing-report@merit.edu ->> From: owner-6bone-routing-report@merit.edu ->> ->> See http://www.merit.edu/ipma for a more detailed report on routing ->> problems and recommendations on ways service providers can limit the ->> spread of invalid routing information. ->> Send comments and questions to ipma-support@merit.edu ->> ->> To unsubscribe from this list, send mail to ->> 6bone-routing-report-request@merit.edu. ->> A hypermail archive is available at ->> http://www.merit.net/mail.archives/html/6bone-routing-report/ ->> ->> Also see http://www.caida.org for more information about Internet ->> statistics collection research efforts. ->> ->> --------------------------------------------- ->> This report is for 11/29/99, peering with ->> VIAGENIE (AS10566) CISCO (AS109) IDIR (AS11264) CICNET (AS1225) WIDE (AS2500) SICS (AS2839) MIT-SIPB (AS3) TELEBIT (AS3263) ETRI (AS3559) CERNET (AS4538) 6COM (AS561) MSR-REDMOND (AS5761) UUNET-US (AS704) CAIRN (AS7081) NUS-IRDU (AS761 0) RADIX (AS7680) ->> --------------------------------------------- ->> ->> Size of 6Bone Routing Table: ->> Max = 97, Min = 94, Average = 94 ->> 60 pTLAs (in 3ffe::/16), 7 sTLAs (in 2001::/16) ->> 83 Unique Autonomous System (AS) numbers ->> ->> BGP4+ Traffic Summary: ->> Announcements = 200865 Withdraws = 32470 Unique Routes = 109 ->> ->> Unknown AS Numbers (not in 6bone registry): ->> Format: AS-Path (Unknown-AS-Number -- Availability) ->> -------------------------------- ->> 10566 1930 3243 (3243 -- 100%) ->> 1225 1275 559 8933 1122 (1122 -- 48%) ->> 1225 1849 1103 766 8933 1122 1121 (1122 1121 -- 26%) ->> 3 145 4557 (4557 -- 35%) ->> 3 145 6509 (6509 -- 1%) ->> 561 5408 10566 6509 818 (6509 818 -- 29%) ->> ->> Unknown Prefixes (not in 6bone registry): ->> Format: Prefix path AS-Path (Origin-AS -- Availability) ->> -------------------------------- ->> 0000::/0 path 1225 1673 (ANSNET -- 0%) ->> 0000::/0 path 561 5408 1752 3185 786 1103 1849 4697 (NTT-ECL -- -71%) ->> 0200::/1 path 10566 5408 1752 3185 786 1103 1849 4697 (NTT-ECL -- 30%) ->> 1000::/4 path 561 5408 10566 237 1225 1673 (ANSNET -- 8%) ->> 1800::/4 path 1225 1673 (ANSNET -- 0%) ->> 2000::/6 path 109 1251 1930 10566 5408 1752 3185 786 2547 2547 1225 1673 237 7610 3425 2500 (WIDE -- 47%) ->> 2002::/16 path 5761 (MSR-REDMOND -- 100%) ->> 5f0c:bf00::/32 path 7610 3462 3263 (TELEBIT -- 2%) ->> ::35e0/120 path 7610 3462 3263 (TELEBIT -- 2%) ->> ->> Poorly Aggregated Announcements (>24 in 3ffe:0000::/17 or >28 in 3ffe:8000::/17 or >35 in 2001::/16): ->> Format: Prefix path AS-Path (Origin-AS -- Availability) ->> asterisk(*) means the route is within its pTLA ->> -------------------------------- ->> SWITCH (AS559) announced 4 route(s) ->> 3ffe:8034:80::/48 path 1225 1275 559 8933 1122 ( -- 48%) ->> 3ffe:1108:800::/40 path 1225 1275 559 8933 3172 (USOT-ECS -- 48%) ->> 3ffe:8038::/34 path 1225 1275 559 8933 (QTPVSIX -- 48%) ->> 3ffe:803c::/34 path 1225 1275 559 8933 3172 (USOT-ECS -- 48%) ->> ->> CICNET (AS1225) announced 4 route(s) ->> * 3ffe:900:1::/48 path 1225 1312 (LORE/VT -- 99%) ->> * 3ffe:900:2::/48 path 1225 3899 (CHICO -- 100%) ->> 3ffe:2900:5::/48 path 1225 1312 (LORE/VT -- 99%) ->> 3ffe:2802::/32 path 1225 1312 (LORE/VT -- 99%) ->> ->> SICS (AS2839) announced 4 route(s) ->> 3ffe:2610:2::/48 path 2839 3274 8432 (TF-INET-DEV -- 100%) ->> 3ffe:2610:5::/48 path 2839 3274 5469 (AHLSTROM -- 100%) ->> 3ffe:1001:60::/48 path 2839 3274 3336 (HTC -- 100%) ->> 3ffe:2620::/32 path 2839 1741 (FUNET/OTOL/VTTMPOLI -- 95%) ->> ->> IPF (AS5409) announced 3 route(s) ->> 3ffe:3001:3::/48 path 109 5409 8731 8251 (CISTRON -- 98%) ->> 3ffe:604:5::/48 path 109 5409 8731 8251 (CISTRON -- 98%) ->> * 3ffe:3400:100::/48 path 109 5409 8731 (SGH-NET -- 98%) ->> ->> MIT-SIPB (AS3) announced 3 route(s) ->> 3ffe:28ff:4::/48 path 3 (MIT-SIPB -- 80%) ->> 3ffe:2801::/32 path 3 145 5050 (PSC-GP -- 80%) ->> 3ffe:2803::/32 path 3 145 4557 ( -- 35%) ->> ->> JOIN (AS1275) announced 2 route(s) ->> 3ffe:2100:1:17::/64 path 1225 1275 (JOIN -- 88%) ->> 3ffe:3400:300::/48 path 1225 1275 5424 (GST/RMACH/FX/CHRIST/LAX/JSB/FIDENTIA-AT/WAECHTER-AT/GEORG-AT/TIVISION-AT/T0-AT/COGIDATA-AT/TCTL-AT/MEDHOST-AT/SWSCHMIEDE-AT/ENEMY-AT/DUNSHIRN-AT/ATNET-AT -- 12%) ->> ->> REDIRIS (AS766) announced 1 route(s) ->> 3ffe:8034:c0::/48 path 1225 1849 1103 766 8933 1122 1121 ( -- 26%) ->> ->> VIAGENIE (AS10566) announced 1 route(s) ->> 3ffe:400:d0::/47 path 561 5408 10566 6509 818 ( -- 29%) ->> ->> RCCN (AS1930) announced 1 route(s) ->> * 3ffe:3102::/48 path 10566 1930 3243 ( -- 100%) ->> ->> TELEBIT (AS3263) announced 1 route(s) ->> 3ffe:2280:4::/48 path 7610 3462 3263 2852 (CESNET -- 2%) ->> ->> BT-LABS (AS1752) announced 1 route(s) ->> 3ffe:2101::/48 path 10566 5408 1752 3185 (ULANC -- 99%) ->> ->> REGIO-DE (AS8319) announced 1 route(s) ->> 3ffe:400:1c0::/48 path 2839 3274 8319 (REGIO-DE -- 100%) ->> ->> GRNET (AS5408) announced 1 route(s) ->> * 3ffe:2d00:b::/48 path 10566 5408 8617 (AEGEAN -- 99%) ->> ->> SPACENET-DE (AS5539) announced 1 route(s) ->> 3ffe:1402:1:1::/64 path 1225 1103 5539 1273 (NAHENET/ECRC -- 20%) ->> ->> ICM-PL (AS8664) announced 1 route(s) ->> 3ffe:902::/32 path 1225 8664 (ICM-PL -- 98%) ->> ->> UUNET-US (AS704) announced 1 route(s) ->> 3ffe:1108:1400::/40 path 704 (UUNET-US -- 100%) ->> ->> 6COM (AS561) announced 1 route(s) ->> * 3ffe:1900:9::/48 path 561 11261 (ASCI -- 66%) ->> ->> Prefixes from Different Origin AS: ->> Format: Prefix path AS-Path (Origin-AS -- Availability) ->> -------------------------------- ->> BAY (3ffe:1300::/24) path 561 10318 (FIBERTEL -- 59%) ->> BAY (3ffe:1300::/24) path 1225 6175 (SPRINT -- 100%) ->> VIAGENIE (3ffe:b00::/24) path 10566 (VIAGENIE -- 100%) ->> VIAGENIE (3ffe:b00::/24) path 3 145 6509 ( -- 1%) ->> ->> The Top Five Most Active Prefixes (more than 1000 changes): ->> Format: AS-Path (Announce/Withdraw -- Availability) ->> ---------------------------------- ->> 1. SICS (3ffe:200::/24) had 31737 BGP+ updates (28 unique aspaths) ->> 2839 (904/0 -- 100%) ->> 7610 3425 293 5609 2839 (49/2 -- 98%) ->> 3 10566 6175 3274 2839 (3904/8 -- 98%) ->> 2500 2500 2500 33 5609 2839 (27/15 -- 70%) ->> 109 33 5609 2839 (3/0 -- 69%) ->> 7081 293 5609 2839 (4540/1627 -- 42%) ->> 10566 6175 3274 2839 (3955/909 -- 29%) ->> 5761 6175 3274 2839 (897/891 -- 29%) ->> 109 1849 5623 2839 (1/0 -- 28%) ->> 561 10318 1849 5623 2839 (5/5 -- 26%) ->> 1225 1275 1835 2839 (995/417 -- 15%) ->> ...Truncated... ->> ->> 2. G6 (3ffe:300::/24) had 16546 BGP+ updates (29 unique aspaths) ->> 10566 1930 559 1717 (4415/60 -- 99%) ->> 2839 1835 1717 (888/0 -- 99%) ->> 3 10566 1930 559 1717 (4397/21 -- 98%) ->> 7081 5409 559 1717 (1173/3 -- 97%) ->> 1225 1275 1717 (948/4 -- 88%) ->> 109 1849 786 1717 (3/0 -- 72%) ->> 7610 3425 293 1275 1717 (49/0 -- 66%) ->> 2500 2500 2500 109 1849 786 1717 (10/10 -- 53%) ->> 7610 1849 786 1717 (3/1 -- 32%) ->> 109 5409 559 1717 (2/0 -- 27%) ->> 561 10318 1849 786 1717 (2/2 -- 26%) ->> ...Truncated... ->> ->> 3. UIO (3ffe:2a00::/24) had 15200 BGP+ updates (68 unique aspaths) ->> 2839 224 (887/0 -- 100%) ->> 7610 3425 293 5609 2839 224 (49/1 -- 98%) ->> 3 10566 6175 3274 2839 224 (2735/1 -- 98%) ->> 2500 2500 2500 33 5609 2839 224 (28/16 -- 70%) ->> 7081 293 5609 2839 224 (2234/0 -- 58%) ->> 109 33 5609 2839 224 (3/0 -- 47%) ->> 7081 6175 3274 2839 224 (234/1 -- 41%) ->> 10566 6175 3274 2839 224 (2772/892 -- 30%) ->> 5761 6175 3274 2839 224 (880/735 -- 30%) ->> 109 1849 5623 2839 224 (2/0 -- 20%) ->> 1225 1275 1835 2839 224 (1002/288 -- 15%) ->> ...Truncated... ->> ->> 4. UNI-C (3ffe:1400::/24) had 15039 BGP+ updates (51 unique aspaths) ->> 2839 1835 (901/0 -- 99%) ->> 7610 3425 293 1275 1835 (46/1 -- 96%) ->> 1225 1275 1835 (782/21 -- 83%) ->> 7081 293 1275 1835 (469/3 -- 78%) ->> 2500 2500 2500 33 3462 3263 1835 (25/15 -- 70%) ->> 3 10566 1930 559 1717 1835 (1658/1 -- 70%) ->> 109 5409 559 1717 1835 (6/0 -- 63%) ->> 561 5609 2839 1835 (5/5 -- 35%) ->> 3 10566 1930 559 1275 1835 (386/0 -- 27%) ->> 7081 5409 559 1717 1835 (1284/3 -- 21%) ->> 109 5409 559 1275 1835 (1/0 -- 20%) ->> ...Truncated... ->> ->> 5. JOIN (3ffe:400::/24) had 8777 BGP+ updates (26 unique aspaths) ->> 4538 1275 (6/1 -- 100%) ->> 2839 1835 1275 (663/0 -- 92%) ->> 1225 1275 (949/0 -- 88%) ->> 7610 3425 293 1275 (49/0 -- 66%) ->> 2500 2500 2500 33 1225 1275 (803/599 -- 61%) ->> 109 4556 1225 1275 (3/0 -- 60%) ->> 10566 5408 559 1275 (422/3 -- 50%) ->> 10566 1930 559 1275 (3356/0 -- 49%) ->> 7081 293 1275 (16/0 -- 47%) ->> 561 5609 1225 1275 (4/3 -- 45%) ->> 3 145 7081 293 1275 (1/0 -- 33%) ->> ...Truncated... ->> ->> -> From george+6bone@m5p.com Tue Nov 30 06:32:22 1999 From: george+6bone@m5p.com (george+6bone@m5p.com) Date: Mon, 29 Nov 1999 22:32:22 -0800 (PST) Subject: Testing SMTP over IPv6 Message-ID: <199911300632.dAU6WMw65066@southstation.m5p.com> I'm running Sendmail-8.10.0 Beta 6 with IPv6 support compiled in on FreeBSD 3.2 with the KAME IPv6 stack. Unfortunately, I'm not aware of a single other site with which I can exchange email over IPv6. So, if you have SMTP bound to an IPv6 socket somewhere, would you either let me send you a message to you via IPv6, or else send me a message at george@ip6.m5p.com to let me see if my setup is working? To get sendmail to compile, I made a couple of changes to sendmail/conf.h and devtools/OS/FreeBSD, but I've been told that I did it wrong. The correct way should have been to a new file, devtools/Site/site.config.m4, containing the following: APPENDDEF(`confENVDEF', `-DNETINET6=1') APPENDDEF(`confLIBDIRS',`-L/usr/local/v6/lib') APPENDDEF(`confLIBS', `-linet6') As time goes on and people desire to accept mail over either IPv4 or IPv6, will we just put MX records of equal priority for an IPv4 server and an IPv6 server, or just put in one MX record referring to a name with both an A and AAAA (or A6) record? -- George Mitchell (george+6bone@m5p.com) From psb@ast.cam.ac.uk Tue Nov 30 08:50:23 1999 From: psb@ast.cam.ac.uk (Peter Bunclark) Date: Tue, 30 Nov 1999 08:50:23 +0000 (GMT) Subject: Testing SMTP over IPv6 In-Reply-To: <199911300632.dAU6WMw65066@southstation.m5p.com> Message-ID: We're running Sun's sendmail on Solaris 5.7 IPv6_Prototype-01; try psb@cadsa.ast.ipv6.cam.ac.uk Pete. On Mon, 29 Nov 1999 george+6bone@m5p.com wrote: > I'm running Sendmail-8.10.0 Beta 6 with IPv6 support compiled in on FreeBSD > 3.2 with the KAME IPv6 stack. Unfortunately, I'm not aware of a single > other site with which I can exchange email over IPv6. So, if you have > SMTP bound to an IPv6 socket somewhere, would you either let me send you > a message to you via IPv6, or else send me a message at > > george@ip6.m5p.com > > to let me see if my setup is working? From nitehawk@1ststep.net Tue Nov 30 14:34:45 1999 From: nitehawk@1ststep.net (Matthew Schlegel) Date: Tue, 30 Nov 1999 06:34:45 -0800 Subject: Testing SMTP over IPv6 In-Reply-To: ; from psb@ast.cam.ac.uk on Tue, Nov 30, 1999 at 08:50:23AM +0000 References: <199911300632.dAU6WMw65066@southstation.m5p.com> Message-ID: <19991130063445.A3044@1ststep.net> My mail server is IP6 enabled as well. Exim-3.02 on linux. Try nitehawk@1ststep.net or nitehawk@ipv6.1ststep.net On Tue Nov 30 12:23:22 1999, Peter Bunclark rambled into the ether: > We're running Sun's sendmail on Solaris 5.7 IPv6_Prototype-01; try > psb@cadsa.ast.ipv6.cam.ac.uk > > Pete. > > On Mon, 29 Nov 1999 george+6bone@m5p.com wrote: > > > I'm running Sendmail-8.10.0 Beta 6 with IPv6 support compiled in on FreeBSD > > 3.2 with the KAME IPv6 stack. Unfortunately, I'm not aware of a single > > other site with which I can exchange email over IPv6. So, if you have > > SMTP bound to an IPv6 socket somewhere, would you either let me send you > > a message to you via IPv6, or else send me a message at > > > > george@ip6.m5p.com > > > > to let me see if my setup is working? > -- Matthew Schlegel Get Paid to surf the web! http://www.alladvantage.com/go.asp?refid=dsc304 Encryption Keys: Type KeyID Created Fingerprint PGP DSS 0x30AFD26D 1998-08-20 FC89 1E36 353E BDAA FF81 DD30 A7B0 3942 30AF D26D PGP RSA 0x3B80FDDF 1998-09-15 2110 E419 93DD 27DD 3229 168F D091 B9F2 From george+6bone@m5p.com Tue Nov 30 18:31:15 1999 From: george+6bone@m5p.com (george+6bone@m5p.com) Date: Tue, 30 Nov 1999 10:31:15 -0800 (PST) Subject: IPv6 Email Test Was Successful Message-ID: <199911301831.dAUIVFh02932@southstation.m5p.com> Thanks to all! I've successfully exchanged email over IPv6 with seven or eight helpful people from this list, and it works just fine. Thanks again! -- George From nitehawk@1ststep.net Tue Nov 30 14:34:45 1999 From: nitehawk@1ststep.net (Matthew Schlegel) Date: Tue, 30 Nov 1999 06:34:45 -0800 Subject: Testing SMTP over IPv6 In-Reply-To: ; from psb@ast.cam.ac.uk on Tue, Nov 30, 1999 at 08:50:23AM +0000 References: <199911300632.dAU6WMw65066@southstation.m5p.com> Message-ID: <19991130063445.A3044@1ststep.net> My mail server is IP6 enabled as well. Exim-3.02 on linux. Try nitehawk@1ststep.net or nitehawk@ipv6.1ststep.net On Tue Nov 30 12:23:22 1999, Peter Bunclark rambled into the ether: > We're running Sun's sendmail on Solaris 5.7 IPv6_Prototype-01; try > psb@cadsa.ast.ipv6.cam.ac.uk > > Pete. > > On Mon, 29 Nov 1999 george+6bone@m5p.com wrote: > > > I'm running Sendmail-8.10.0 Beta 6 with IPv6 support compiled in on FreeBSD > > 3.2 with the KAME IPv6 stack. Unfortunately, I'm not aware of a single > > other site with which I can exchange email over IPv6. So, if you have > > SMTP bound to an IPv6 socket somewhere, would you either let me send you > > a message to you via IPv6, or else send me a message at > > > > george@ip6.m5p.com > > > > to let me see if my setup is working? > -- Matthew Schlegel Get Paid to surf the web! http://www.alladvantage.com/go.asp?refid=dsc304 Encryption Keys: Type KeyID Created Fingerprint PGP DSS 0x30AFD26D 1998-08-20 FC89 1E36 353E BDAA FF81 DD30 A7B0 3942 30AF D26D PGP RSA 0x3B80FDDF 1998-09-15 2110 E419 93DD 27DD 3229 168F D091 B9F2 >From analevin@redestb.es Tue Nov 30 18:53:51 1999 Received: from mailgw1.swip.net (mailgw1.swip.net [193.12.122.145]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id SAA12544 for ; Tue, 30 Nov 1999 18:53:51 +0100 (MET) Received: from tinet0.redestb.es (tinet0.redestb.es [194.179.106.117]) by mailgw1.swip.net (8.8.8/8.8.8) with ESMTP id SAA15349 for ; Tue, 30 Nov 1999 18:53:49 +0100 (MET) Message-Id: <199911301753.SAA15349@mailgw1.swip.net> Received: from fclients0.redestb.es ([194.179.106.116]) by tinet0.redestb.es (Post.Office MTA v3.1 release PO203a ID# 0-0U10L2S100) with ESMTP id AAA220 for ; Tue, 30 Nov 1999 18:54:24 +0100 Received: from analevin ([62.82.228.82]) by fclients0.redestb.es (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100) with ESMTP id AAB233 for ; Tue, 30 Nov 1999 18:54:23 +0100 From: "Ana Levin" To: "Helen Dagerus" Subject: Last days. Date: Tue, 30 Nov 1999 18:20:24 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi Helen! How are you? I suposed very nervous, because theres only a few days to move to Amsterdam.Isn´t it? I´m doing my last things too, but i suposed i ´ll arrive at December 10 or 11. This weekend i was in another city, Albacete, and someone stoled my wallet with all, my I.D, credit cards, driving license, and 10.000 pesetas!!.The worst of all is that theres only few days to go and i´m unidentificated, well i still having my passport, it will be enough to go to Holland. Well i hope everything will be fine and we can se each other in a couple of days in OUR HOUSE.I´m very happy!! See you soon, and lots of luck. Ana >From nk-kunder-bounce@netch.se Tue Nov 30 19:23:15 1999 Received: from mailgw5.swip.net (mailgw5.swip.net [193.12.122.181]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id TAA14428 for ; Tue, 30 Nov 1999 19:23:15 +0100 (MET) Received: from hermes.netch.se (hermes.netch.se [194.218.230.35]) by mailgw5.swip.net (8.8.8/8.8.8) with ESMTP id TAA14675; Tue, 30 Nov 1999 19:23:54 +0100 (MET) Received: (from ola@localhost) by hermes.netch.se (8.9.3/8.9.3/asi-redhat) id QAA20152 for nk-kunder-outgoing; Tue, 30 Nov 1999 16:03:53 +0100 Date: Tue, 30 Nov 1999 16:03:53 +0100 From: nk-hallen@netch.se Message-Id: <199911301503.QAA20152@hermes.netch.se> X-Authentication-Warning: hermes.netch.se: ola set sender to nk-hallen@netch.se using -f To: nk-hallen@netch.se Subject: Information =?iso-8859-1?Q?fr=E5n?= NK Hallen Reply-To: nk-hallen@netch.se Errors-To: nk-kunder-bounce@netch.se Precedence: bulk MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Vecka 48 p=E5 NK Hallen. http://www.nk.se/stockholm/NKhallen/ Best=E4ll maten via din dator - vi b=E4r hem kassarna =E5t dig. B=E4ste kund! November blir denna vecka december och en mysig julst=E4mning smyger sig p= =E5. Ta hj=E4lp av oss p=E5 NK Hallen i dina julf=F6rberedelser. Best=E4ll din ma= t direkt via n=E4tet. Den h=E4r veckan hittar du NK pastasallader f=F6r 59:00/= kg och kalvinnanl=E5r f=F6r 149.00/kg. Best=E4ller du din hemleverans till tisd= ag eller onsdag underl=E4ttar du v=E5rt vardagliga arbete. Det bel=F6nar vi med= ett extra erbjudande i din matkasse. Denna veckas erbjudande =E4r Zoegas= Julkaffe. Vi forts=E4tter med levereranser till d=F6rr i v=E5ra splitternya kylbilar. Best=E4ll din hemleverans till f=F6ljande tre leveransturer: Tur 1: kl 9-12 Tur 2: kl 14-17 Tur 3: kl 17-21 Bra priser denna vecka: NK Pastasallader 59:00/kg Laxrom 129:00/kg Kalvinnanl=E5r 149:00/kg Skivat hamburgerk=F6tt 99:00/kg Spanska apelsiner 7:90/kg Herrg=E5rdsost 59:90/kg Froza =E4ppel- eller k=F6rsb=E4rspaj 29:90/kg Sonnessons grekiska lantbr=F6d 11:90/st Blossa L=E4ttgl=F6gg 750 ml 25:90 Cafe Tasse Drickchoklad 250 gr 59:90 2 pack Julmust 2*1,5L 19:90 Samarin fruktsalt 240 gr 54:50 Jordan Tandborste 14:90 Comfort sk=F6ljmedel 500 ml 21:90 NK Bageriet Baguetter 12:50/st Lindt Praline Hochfine 350 gr 119:00 Tidsam Elle 44:50 Ha en trevlig vecka! nk-hallen@netch.se P.S. Om du vill ta en paus fr=E5n veckobrevet kan du genom ett enkelt handgrepp ordna detta sj=E4lv. Under http://www.nk.se/html loggar du in i butiken, sedan under "=D6vrigt" i valen du kan g=F6ra till v=E4nster (v=E4nsterframen). S=E5 vidare med "=E4ndra personuppgifter", och markera att du inte vill ha veckobrevet. P=E5 samma s=E4tt kan du =E4ndra tillbaka n=E4r du vill ha veckobrevet igen. NK Hallens n=E4tbutik =E4r producerad av Brand Internet och /netch/. >From 6bone-owner@ISI.EDU Tue Nov 30 20:33:19 1999 Received: from mailgw4.swip.net (mailgw4.swip.net [193.12.122.180]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id UAA17668 for ; Tue, 30 Nov 1999 20:33:18 +0100 (MET) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailgw4.swip.net (8.8.8/8.8.8) with ESMTP id UAA25080; Tue, 30 Nov 1999 20:33:15 +0100 (MET) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id KAA20680 for 6bone-outgoing; Tue, 30 Nov 1999 10:31:27 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA20668 for <6bone@zephyr.isi.edu>; Tue, 30 Nov 1999 10:31:15 -0800 (PST) Received: from southstation.m5p.com (dsl-209-162-215-52.easystreet.com [209.162.215.52]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA01410 for <6bone@isi.edu>; Tue, 30 Nov 1999 10:31:16 -0800 (PST) Received: (from george@localhost) by southstation.m5p.com (8.10.0.Beta6/8.10.0.Beta6) id dAUIVFh02932; Tue, 30 Nov 1999 10:31:15 -0800 (PST) Date: Tue, 30 Nov 1999 10:31:15 -0800 (PST) Message-Id: <199911301831.dAUIVFh02932@southstation.m5p.com> From: george+6bone@m5p.com To: 6bone@ISI.EDU Subject: IPv6 Email Test Was Successful Sender: owner-6bone@ISI.EDU Precedence: bulk Thanks to all! I've successfully exchanged email over IPv6 with seven or eight helpful people from this list, and it works just fine. Thanks again! -- George >From 6bone-owner@ISI.EDU Wed Dec 1 04:42:51 1999 Received: from mailgw1.swip.net (mailgw1.swip.net [193.12.122.145]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id EAA00515 for ; Wed, 1 Dec 1999 04:42:51 +0100 (MET) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailgw1.swip.net (8.8.8/8.8.8) with ESMTP id EAA10038; Wed, 1 Dec 1999 04:42:48 +0100 (MET) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id SAA23894 for 6bone-outgoing; Tue, 30 Nov 1999 18:48:28 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA23888 for <6bone@zephyr.isi.edu>; Tue, 30 Nov 1999 18:48:24 -0800 (PST) Received: from academic.touro.edu (academic.touro.edu [192.245.89.2]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA25193 for <6bone@ISI.EDU>; Tue, 30 Nov 1999 18:48:25 -0800 (PST) Received: from localhost (hermans@localhost) by academic.touro.edu (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA07304; Tue, 30 Nov 1999 21:51:49 -0500 Date: Tue, 30 Nov 1999 21:51:47 -0500 (EST) From: Herman Strom To: Stig Venaas cc: Gregg C Levine , 6bone <6bone@ISI.EDU> Subject: Re: Linux operating system kernel versions In-Reply-To: <19991123071049.A16237@itea.ntnu.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-6bone@ISI.EDU Precedence: bulk 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 6bone-owner@ISI.EDU Wed Dec 1 05:03:15 1999 Received: from mailgw2.swip.net (mailgw2.swip.net [193.12.122.161]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id FAA00887 for ; Wed, 1 Dec 1999 05:03:14 +0100 (MET) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailgw2.swip.net (8.8.8/8.8.8) with ESMTP id FAA01556; Wed, 1 Dec 1999 05:03:10 +0100 (MET) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id TAA25578 for 6bone-outgoing; Tue, 30 Nov 1999 19:24:10 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA25573 for <6bone@zephyr.isi.edu>; Tue, 30 Nov 1999 19:24:07 -0800 (PST) Received: from academic.touro.edu (academic.touro.edu [192.245.89.2]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA26977 for <6bone@ISI.EDU>; Tue, 30 Nov 1999 19:24:08 -0800 (PST) Received: from localhost (hermans@localhost) by academic.touro.edu (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA20868; Tue, 30 Nov 1999 22:27:16 -0500 Date: Tue, 30 Nov 1999 22:27:15 -0500 (EST) From: Herman Strom To: kuznet@ms2.inr.ac.ru cc: 6bone@ISI.EDU, rzm@icm.edu.pl, hansolofalcon@worldnet.att.net Subject: Re: Linux operating system kernel versions In-Reply-To: <199911231619.TAA30449@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-6bone@ISI.EDU Precedence: bulk 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 6bone-owner@ISI.EDU Wed Dec 1 10:41:25 1999 Received: from mailgw3.swip.net (mailgw3.swip.net [193.12.122.165]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id KAA11473 for ; Wed, 1 Dec 1999 10:41:24 +0100 (MET) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mailgw3.swip.net (8.8.8/8.8.8) with ESMTP id KAA06420; Wed, 1 Dec 1999 10:41:31 +0100 (MET) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id AAA14946 for 6bone-outgoing; Wed, 1 Dec 1999 00:56:00 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA14940 for <6bone@zephyr.isi.edu>; Wed, 1 Dec 1999 00:55:57 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA13844 for <6bone@ISI.EDU>; Wed, 1 Dec 1999 00:55:57 -0800 (PST) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id TAA26635; Wed, 1 Dec 1999 19:55:50 +1100 (EST) Date: Wed, 1 Dec 1999 19:55:49 +1100 (EST) From: Peter Tattam Reply-To: Peter Tattam To: george+6bone@m5p.com cc: 6bone@ISI.EDU Subject: Re: Testing SMTP over IPv6 In-Reply-To: <199911300632.dAU6WMw65066@southstation.m5p.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-6bone@ISI.EDU Precedence: bulk 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 info@teamdivers.se Wed Dec 1 14:58:49 1999 Received: from mailgw7.swip.net (mailgw7.swip.net [193.12.122.183]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id OAA25528 for ; Wed, 1 Dec 1999 14:58:48 +0100 (MET) Received: from angel.algonet.se (angel.algonet.se [194.213.74.112]) by mailgw7.swip.net (8.8.8/8.8.8) with SMTP id OAA25451 for ; Wed, 1 Dec 1999 14:58:40 +0100 (MET) Received: (qmail 19949 invoked from network); 1 Dec 1999 14:59:04 +0100 Received: from enok.algonet.se (194.213.74.88) by angel.algonet.se with SMTP; 1 Dec 1999 14:59:04 +0100 Received: from sdu56-245.ppp.algonet.se ([195.163.245.56]) by algonet.se (BLUETAIL Mail Robustifier1.0.4) with ESMTP ; Wed, 01 Dec 1999 13:59:04 GMT Message-ID: <3845383B.92451D93@teamdivers.se> Date: Wed, 01 Dec 1999 16:01:15 +0100 From: Team Divers Reply-To: johan@teamdivers.se Organization: Team Divers X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Subject: Ny kod! Content-Type: multipart/mixed; boundary="------------9133E0373A15CEF1C9263AD8" Content-Transfer-Encoding: 8bit This is a multi-part message in MIME format. --------------9133E0373A15CEF1C9263AD8 Content-Type: multipart/alternative; boundary="------------26768938010E2BB07324A276" --------------26768938010E2BB07324A276 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Bäste dykare! * Fr.o.m. 991201 har vi ny kod till "Dygnet runt fyllningen" Koden är # 1035 och avser både boxen + stora grinden. * För Er som inte har ordnat alla julklappar ännu kan jag tipsa om vår hemsida www.teamdivers.se. mvh/TEAM DIVERS Staff --------------26768938010E2BB07324A276 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bäste dykare!
 
  • Fr.o.m. 991201 har vi ny kod till "Dygnet runt fyllningen" Koden är # 1035 och avser både boxen + stora grinden.
  • För Er som inte har ordnat alla julklappar ännu kan jag tipsa om vår hemsida www.teamdivers.se.


mvh/TEAM DIVERS
Staff --------------26768938010E2BB07324A276-- --------------9133E0373A15CEF1C9263AD8 Content-Type: text/x-vcard; charset=us-ascii; name="info.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Team Divers Content-Disposition: attachment; filename="info.vcf" begin:vcard n:;Johan tel;fax:+46-(0)8-583 600 55 tel;work:+46-(0)8-583 600 50 x-mozilla-html:FALSE org:Team Divers adr:;;Fabriksvägen Hus B;176 71 Järfälla;;;Sweden version:2.1 email;internet:johan@teamdivers.se end:vcard --------------9133E0373A15CEF1C9263AD8--