From beam@li.net Sun Aug 1 01:40:56 1999 From: beam@li.net (Bruce Ballaban) Date: Sat, 31 Jul 1999 20:40:56 -0400 Subject: How do I get Off This List? Message-ID: <01bedbb6$8500b720$33008bd1@l> This is a multi-part message in MIME format. ------=_NextPart_000_0014_01BEDB94.FDEF1720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I need to get off this list. Can somebody please tell me what to do? Thanks ------=_NextPart_000_0014_01BEDB94.FDEF1720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I need to get off this list. = Can somebody=20 please tell me what to do?

Thanks

------=_NextPart_000_0014_01BEDB94.FDEF1720-- From fink@es.net Sun Aug 1 01:04:09 1999 From: fink@es.net (Bob Fink) Date: Sat, 31 Jul 1999 17:04:09 -0700 Subject: new 6bone pTLA 3FFE:8040::/28 assigned to APAN-KR Message-ID: <4.1.19990731165858.02315d70@imap2.es.net> Per the review of APAN-KR's request for a pTLA which ended on 30 July, I have assigned pTLA 3FFE:8040::/28 to APAN-KR. See: Bob From masaki@merit.edu Tue Aug 3 18:38:30 1999 From: masaki@merit.edu (Masaki Hirabaru) Date: Tue, 03 Aug 1999 13:38:30 -0400 Subject: Bad routes update In-Reply-To: References: <4.1.19990730090825.009a3960@imap2.es.net> <199908030628.CAA22524@zounds.merit.net> Message-ID: <19990803133830F.masaki@merit.edu> I recently updated our routing report. Let me explain some on this since it's intended to help hardening efforts on 6bone. 1) I added availability in most routes. For example, the route is seen in total 6 hours a day, the availability will be 25%. If there is a path that's availability is close to 100% but some of alternative paths are flapping, it probably would be OK in terms of the stability of the prefix. 2) I added a check of AS numbers. << Reserved, Private, or Invalid AS Numbers: << Format: AS-Path (Bad-AS-Numbers -- Availability) << -------------------------------- << 7610 1849 1103 65502 (65502 -- 100%) << 7610 1849 786 1103 65502 2839 5609 1225 237 2500 2500 2500 109 4608 (65502 -- 42%) 3) This check may be too restrictive (if the sites are intended to do so.) << Prefixes from Different Origin AS: << Format: Prefix path AS-Path (Origin-AS -- Availability) << -------------------------------- << AMS-IX (3ffe:3000::/24) path 1225 1849 1890 (NLNET -- 42%) << AMS-IX (3ffe:3000::/24) path 2839 5623 (ATT-LABS-EUROPE -- 99%) << VIAGENIE (3ffe:b00::/24) path 10566 (VIAGENIE -- 100%) << VIAGENIE (3ffe:b00::/24) path 7081 293 6509 ( -- 46%) Basically, our report follows the 6bone routing RFC and the new hardening draft being discussed here. -- Masaki >> From: owner-6bone-routing-report@merit.edu >> Subject: 08/02/99 6Bone Routing Report >> Date: Tue, 3 Aug 1999 02:28:34 -0400 (EDT) >> Message-ID: <199908030628.CAA22524@zounds.merit.net> >> >> Subject: 08/02/99 6Bone Routing Report >> From: owner-6bone-routing-report@merit.edu >> To: 6bone-routing-report@merit.edu >> Date: Tue, 3 Aug 1999 02:28:34 -0400 (EDT) >> >> 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 08/02/99, peering with >> VIAGENIE (AS10566) CISCO (AS109) IDIR (AS11264) CICNET (AS1225) WIDE (AS2500) SICS (AS2839) TELEBIT (AS3263) ETRI (AS3559) CERNET (AS4538) EWD-3COM (AS561) MSR-REDMOND (AS5761) UUNET-US (AS704) CAIRN (AS7081) NUS-IRDU (AS7610) >> --------------------------------------------- >> >> Size of 6Bone Routing Table: >> Max = 202, Min = 53, Average = 201 >> 74 Unique Autonomous System (AS) numbers >> >> BGP4+ Traffic Summary: >> Announcements = 235874 Withdraws = 15683 Unique Routes = 92 >> >> Reserved, Private, or Invalid AS Numbers: >> Format: AS-Path (Bad-AS-Numbers -- Availability) >> -------------------------------- >> 7610 1849 1103 65502 (65502 -- 100%) >> 7610 1849 786 1103 65502 2839 5609 1225 237 2500 2500 2500 109 4608 (65502 -- 42%) >> >> Non-6Bone Prefixes (outside of 3ffe::/16): >> Format: Prefix path AS-Path (Origin-AS -- Availability) >> -------------------------------- >> 0000::/0 path 1225 33 109 237 5761 (MSR-REDMOND -- 0%) >> 1000::/3 path 1225 33 109 237 5761 (MSR-REDMOND -- 0%) >> 2010::/16 path 5761 (MSR-REDMOND -- 100%) >> >> Poorly Aggregated Prefixes (>24 in 3ffe:0000::/17 or >28 in 3ffe:8000::/17): >> Format: Prefix path AS-Path (Origin-AS -- Availability) >> -------------------------------- >> STUBA (3ffe:2200::/24) had 7 route(s) >> 3ffe:2280:4:2::/64 path 109 3462 3263 2852 (CESNET -- 97%) >> 3ffe:2280:4:3::/64 path 109 3462 3263 2852 (CESNET -- 97%) >> 3ffe:2200:0:8007::/64 path 109 3462 3263 2852 (CESNET -- 97%) >> 3ffe:2280:4:5::/64 path 109 3462 3263 2852 (CESNET -- 97%) >> 3ffe:2280:4:6::/64 path 109 3462 3263 2852 (CESNET -- 97%) >> 3ffe:2280:4:601::/64 path 109 3462 3263 2852 (CESNET -- 97%) >> 3ffe:2280:3::/48 path 2839 1849 786 5623 222 ( -- 99%) >> 3ffe:2280:3::/48 path 7610 1849 1103 65502 ( -- 57%) >> >> CICNET (3ffe:900::/24) had 3 route(s) >> 3ffe:900:1::/48 path 1225 1312 (LORE/VT -- 100%) >> 3ffe:900:2::/48 path 1225 3899 (CHICO -- 100%) >> 3ffe:902::/32 path 1225 8664 (ICM-PL -- 99%) >> >> SMS (3ffe:2600::/24) had 3 route(s) >> 3ffe:2610:2::/48 path 2839 3274 8432 (TF-INET-DEV -- 97%) >> 3ffe:2610:5::/48 path 2839 3274 5469 (AHLSTROM -- 97%) >> 3ffe:2620::/32 path 2839 1741 (FUNET/OTOL -- 79%) >> >> UUNET-UK (3ffe:1100::/24) had 2 route(s) >> 3ffe:1108:40a::/48 path 1225 4556 5539 (SPACENET-DE -- 100%) >> 3ffe:1108:1400::/40 path 704 (UUNET-US -- 100%) >> >> SWITCH (3ffe:2000::/24) had 2 route(s) >> 3ffe:202a:1::/64 path 10566 1930 559 1836 (SIMULTAN -- 99%) >> 3ffe:2024:1::/48 path 10566 1930 559 1205 (TK-LINZ/JKU-LINZ -- 99%) >> >> GRNET (3ffe:2d00::/24) had 2 route(s) >> 3ffe:2d00:3::/48 path 1225 48 1752 5408 8643 (UOA -- 95%) >> 3ffe:2d00:2::/48 path 1225 48 1752 5408 3323 (NTUA -- 99%) >> >> SPRINT (3ffe:2900::/24) had 1 route(s) >> 3ffe:2900:5::/48 path 1225 1312 (LORE/VT -- 100%) >> >> SICS (3ffe:200::/24) had 1 route(s) >> 3ffe:200:2::/48 path 7610 1849 1103 65502 ( -- 57%) >> >> JANET (3ffe:2100::/24) had 1 route(s) >> 3ffe:2100:1:17::/64 path 1225 1275 (JOIN -- 99%) >> >> VBNS (3ffe:2800::/24) had 1 route(s) >> 3ffe:2802::/32 path 1225 1312 (LORE/VT -- 100%) >> >> JOIN (3ffe:400::/24) had 1 route(s) >> 3ffe:400:1c0::/48 path 1225 48 8319 (REGIO-DE -- 99%) >> >> NTT-ECL (3ffe:1800::/24) had 1 route(s) >> 3ffe:1810::/64 path 1225 1849 5623 1103 2839 224 4697 (NTT-ECL -- 57%) >> >> ATT-LABS-EUROPE (3ffe:1d00::/24) had 1 route(s) >> 3ffe:1d01:3::/48 path 2839 1849 786 1103 222 ( -- 99%) >> 3ffe:1d01:3::/48 path 7610 1849 1103 65502 ( -- 57%) >> >> UNI-C (3ffe:1400::/24) had 1 route(s) >> 3ffe:1402:1:1::/64 path 1225 1849 5539 1273 (ECRC -- 99%) >> >> NRL (3ffe:f00::/24) had 1 route(s) >> 3ffe:f00:2::/48 path 1225 48 11261 (ASCI -- 100%) >> >> INR (3ffe:2400::/24) had 1 route(s) >> 3ffe:2401::/32 path 109 2895 2118 (STC-IPNG -- 95%) >> >> CISCO (3ffe:c00::/24) had 1 route(s) >> 3ffe:c00:800f::/48 path 7610 1849 786 1103 65502 2839 5609 1225 237 2500 2500 2500 109 4608 (APNIC -- 42%) >> >> Prefixes from Different Origin AS: >> Format: Prefix path AS-Path (Origin-AS -- Availability) >> -------------------------------- >> AMS-IX (3ffe:3000::/24) path 1225 1849 1890 (NLNET -- 42%) >> AMS-IX (3ffe:3000::/24) path 2839 5623 (ATT-LABS-EUROPE -- 99%) >> VIAGENIE (3ffe:b00::/24) path 10566 (VIAGENIE -- 100%) >> VIAGENIE (3ffe:b00::/24) path 7081 293 6509 ( -- 46%) >> >> The Top Five Most Active Prefixes: >> Format: AS-Path (Announce/Withdraw -- Availability) >> ---------------------------------- >> 1. ANSNET (3ffe:d00::/24) had 37100 BGP+ updates (78 unique aspaths) >> 2839 5609 1673 (28051/15 -- 94%) >> 7610 1849 33 5609 1673 (5/1 -- 72%) >> 1225 5609 1673 (547/1 -- 47%) >> 109 1225 5609 1673 (539/0 -- 47%) >> 10566 561 5609 1673 (1421/22 -- 46%) >> 109 4556 5609 1673 (537/2 -- 45%) >> 1225 4556 5609 1673 (539/1 -- 45%) >> 7081 6175 1849 145 293 1673 (1/0 -- 31%) >> 561 6175 4556 5609 1673 (765/4 -- 30%) >> 5761 6175 4556 5609 1673 (293/258 -- 25%) >> 7081 293 33 5609 1673 (2/0 -- 21%) >> ...Truncated... >> >> 2. EWD-3COM (3ffe:1900::/24) had 8209 BGP+ updates (14 unique aspaths) >> 561 (1483/0 -- 100%) >> 10566 561 (15/2 -- 99%) >> 1225 5609 561 (18/1 -- 99%) >> 7081 6175 561 (14/0 -- 83%) >> 5761 6175 561 (1464/1421 -- 79%) >> 2839 5609 561 (576/1 -- 67%) >> 109 6175 561 (81/72 -- 61%) >> 7610 1849 6175 561 (1482/1464 -- 44%) >> 2500 2500 2500 109 6175 561 (29/29 -- 0%) >> 2500 2500 2500 33 5609 561 (16/16 -- 0%) >> 2839 3274 6175 561 (3/0 -- 0%) >> ...Truncated... >> >> 3. BAY (3ffe:1300::/24) had 8187 BGP+ updates (27 unique aspaths) >> 10566 6175 10318 (2958/0 -- 99%) >> 1225 6175 10318 (17/0 -- 99%) >> 561 6175 10318 (1479/0 -- 99%) >> 109 33 10318 (14/0 -- 99%) >> 5761 6175 10318 (19/1 -- 99%) >> 7081 145 10318 (2881/0 -- 95%) >> 7610 1849 33 10318 (11/1 -- 95%) >> 2839 1849 6175 10318 (51/0 -- 46%) >> 2839 1849 33 10318 (456/0 -- 42%) >> 2839 5609 33 10318 (75/0 -- 10%) >> 7081 6175 10318 (85/0 -- 4%) >> ...Truncated... >> >> 4. STUBA (3ffe:2200::/24) had 8116 BGP+ updates (13 unique aspaths) >> 109 6175 1849 2607 (8/0 -- 100%) >> 1225 6175 1849 2607 (13/0 -- 100%) >> 561 6175 1849 2607 (1483/0 -- 100%) >> 7081 6175 1849 2607 (2956/0 -- 100%) >> 10566 6175 1849 2607 (2958/0 -- 100%) >> 5761 6175 1849 2607 (16/1 -- 99%) >> 2839 1849 786 1103 2607 (554/0 -- 99%) >> 7610 1849 1103 1835 2607 (0/0 -- 57%) >> 7610 1849 786 1103 2607 (9/0 -- 42%) >> 2500 2500 2500 109 6175 1849 2607 (38/38 -- 1%) >> 2500 2500 2500 33 1849 786 1103 2607 (13/12 -- 0%) >> ...Truncated... >> >> 5. SMS (3ffe:2600::/24) had 5331 BGP+ updates (11 unique aspaths) >> 7081 6175 3274 (714/55 -- 100%) >> 10566 6175 3274 (1411/5 -- 100%) >> 7610 1849 6175 3274 (9/0 -- 100%) >> 109 6175 3274 (8/0 -- 100%) >> 1225 1103 3274 (13/0 -- 100%) >> 561 6175 3274 (1483/0 -- 100%) >> 5761 6175 3274 (19/1 -- 99%) >> 2839 3274 (702/5 -- 96%) >> 2839 1103 3274 (182/6 -- 3%) >> 2500 2500 2500 109 6175 3274 (38/38 -- 1%) >> 2500 2500 2500 33 1849 6175 3274 (10/9 -- 0%) >> From masaki@merit.edu Tue Aug 3 19:25:57 1999 From: masaki@merit.edu (Masaki Hirabaru) Date: Tue, 03 Aug 1999 14:25:57 -0400 Subject: 07/01/99 6Bone Routing Report In-Reply-To: <19990724162846Y.sumikawa@ebina.hitachi.co.jp> References: <19990719104152B.masaki@merit.edu> <19990719130526B.masaki@merit.edu> <19990724162846Y.sumikawa@ebina.hitachi.co.jp> Message-ID: <19990803142557I.masaki@merit.edu> >> I think It was occured by 'NLRI-Length attribute' probles with >> CISCO(AS 109). CISCO have announced and received routes without >> NLRI_length suddenly, so CISCO mis-recognizes our routes and announce >> them to other pTLA. And frequently termination the BGP connection >> cause route flapping. I've thought that the version difference just causes immediate BGP session closing since the code should check the packet format. If this happens, I think that we'd better stop using the old version as soon as possible. When I proposed this a long time ago, it was too early. But, now should we make a schedule to forget the obsolete BGP4+ version? Masaki >> From: SUMIKAWA Munechika (角川宗近) >> Subject: Re: 07/01/99 6Bone Routing Report >> Date: Sat, 24 Jul 1999 16:28:46 +0900 (JST) >> Message-ID: <19990724162846Y.sumikawa@ebina.hitachi.co.jp> >> >> Sorry for delay resoponse. I needed a week for investigation the >> problem. >> >> masaki> BTW, there are also similar flapping routes that look from WIDE >> masaki> Project and contribute great increase of IPv6 traffic on 6bone. >> >> masaki> 0000::/0 path 109 2500 2500 2500 2500 2500 (WIDE) >> masaki> 1800::/4 path 109 2500 2500 2500 2500 2500 (WIDE) >> masaki> 1. (0000::/0) had 93371 BGP+ updates (18 unique aspaths) >> masaki> 2. (1800::/4) had 87912 BGP+ updates (16 unique aspaths) >> >> I think It was occured by 'NLRI-Length attribute' probles with >> CISCO(AS 109). CISCO have announced and received routes without >> NLRI_length suddenly, so CISCO mis-recognizes our routes and announce >> them to other pTLA. And frequently termination the BGP connection >> cause route flapping. >> >> Now I changed my router configuration, it seems that no curious routes >> annouce to 6bone. >> >> Thanks, >> >> --- >> Munechika SUMIKAWA @ WIDE Project From masaki@merit.edu Tue Aug 3 19:44:48 1999 From: masaki@merit.edu (Masaki Hirabaru) Date: Tue, 03 Aug 1999 14:44:48 -0400 Subject: 07/01/99 6Bone Routing Report In-Reply-To: <19990719130526B.masaki@merit.edu> References: <19990719104152B.masaki@merit.edu> <19990719130526B.masaki@merit.edu> Message-ID: <19990803144448C.masaki@merit.edu> We are still seeing these bogus routes. 0000::/0 path 1225 33 109 237 5761 (MSR-REDMOND -- 0%) 1000::/3 path 1225 33 109 237 5761 (MSR-REDMOND -- 0%) Dorian Kim at as 1225 tried to catch them, but they are flapping too rapidly. However, I found that CSELT also detected this on their router according to their routing page. I did an experiment to modify a route 2010::/16 originated from 5761. BGP attribute of the routes 0000::/0 and 1000::/3 followed the change. There is another supporting fact. CAIRN was also originating 2010::/16 before, and the same bogus routes from CAIRN were also seen. After stopping 2010::/16 from CAIRN, the bogus routes from CAIRN went away. I'm sure that these bogus routes never pass through AS 237 (Merit). I have no idea about fixing these routes for the time being. If you are on or close to the above path, and find something that might to be related to this, please report it. BTW, I also tried to attach BGP community to the route (2010::/16). However, the route having traveled through 6bone back to us didn't have BGP community. BGP community is optional transitive, so an intermediate router may not know it but must pass it to next. Chris Heermann suggested me to use BGP community to help 6bone routing, but it seems it's not possible for the time being. Masaki >> From: Masaki Hirabaru >> Subject: Re: 07/01/99 6Bone Routing Report >> Date: Mon, 19 Jul 1999 13:05:26 -0400 >> Message-ID: <19990719130526B.masaki@merit.edu> >> >> Hi. 6bone folks, >> >> This issue looks like a matter local to some sites, but I'm >> bringing up this because I'm not sure where it's generated. >> >> Merit has been receiving 1000::/3 and 0000::/0 since July 1st. >> They are out of the 6bone prefix, so they should not be. But, the >> problem I want to say is not such a thing. I don't want to solve >> this just by filtering out them. (Merit doesn't accept such a >> route with an as path loop, anyway.) >> >> The AS path of them is "1225 33 109 237 7081", where 7081 - >> CAIRN, 237 - Merit, 109 - CISCO, 33 - DEC-CA, 1225 - CICNET. >> >> As long as I checked over the BGP session logs that record all >> BGP packets received here, Merit (AS 237) didn't have the routes >> from CAIRN (AS 7081). According to our routing daemon's internal >> log, it didn't announce the routes to CISCO (AS 109). However, it >> received the routes as if they were originated from CAIRN through >> Merit. >> >> Moreover, this routes are flapping. They are only alive for a >> second. Withdrawals follow right after the announcements that >> happen once every 10 or 20 minutes. >> >> This doesn't seem to cause something wrong for now, but I'd let >> you know what's being seen. >> >> BTW, there are also similar flapping routes that look from WIDE >> Project and contribute great increase of IPv6 traffic on 6bone. >> >> 0000::/0 path 109 2500 2500 2500 2500 2500 (WIDE) >> 1800::/4 path 109 2500 2500 2500 2500 2500 (WIDE) >> 1. (0000::/0) had 93371 BGP+ updates (18 unique aspaths) >> 2. (1800::/4) had 87912 BGP+ updates (16 unique aspaths) >> >> Thanks, >> Masaki >> >> >> From: Masaki Hirabaru >> >> Subject: Re: 07/01/99 6Bone Routing Report >> >> Date: Mon, 19 Jul 1999 10:41:52 -0400 >> >> Message-ID: <19990719104152B.masaki@merit.edu> >> >> >> >> I restarted about 45 hours ago, but the same thing is happening. >> >> I'm going to bring up this issue to 6bone mailing-list. -- Masaki >> >> >> >> >> From: Chris Heermann >> >> >> Subject: Re: 07/01/99 6Bone Routing Report >> >> >> Date: Mon, 19 Jul 1999 10:27:11 -0400 (EDT) >> >> >> Message-ID: >> >> >> >> >> >> >> >> >> Hi Masaki, >> >> >> >> >> >> I hope I'm not being a pain, but I wanted to ping you about restarting >> >> >> your BGP session with AS 1225 (cicnet). Can you please tell me how this >> >> >> goes? >> >> >> >> >> >> thanks, >> >> >> Chris >> >> >> >> >> >> On Sun, 4 Jul 1999, Masaki Hirabaru wrote: >> >> >> >> >> >> > Hi. Chris, >> >> >> > >> >> >> > I searched 1000::/3 in our dump data on July 1st. I couldn't find >> >> >> > the beginning of announcements of 1000::/3. If you announced the >> >> >> > route on that day, it should be recorded on this router with as >> >> >> > path "237 7081". >> >> >> > >> >> >> > Currently, we don't have 1000::/3 in our routing table, but AS >> >> >> > 1225 (cicnet) says it comes through us (originated by CAIRN). >> >> >> > According to MRTd's internal status, our router has never >> >> >> > announced 1000::/3 to AS 109 (cisco) since the BGP session >> >> >> > started 51 hours ago with cisco. 1000::/3 is flapping and I >> >> >> > suspect something wrong along with the path. >> >> >> > >> >> >> > Since July 1st, 1000::/3 has been announced as this and kept >> >> >> > flapping. MRTd doesn't accept (but record) this announcement, >> >> >> > because it detects a loop in the as path. >> >> >> > >> >> >> > I could remove this by restarting a BGP session with cisco and/or >> >> >> > cicnet, but I'll do that after I'm back from my vacation. >> >> >> > >> >> >> > Masaki >> >> >> > >> >> >> > [this is the first part of announcements of 1000::/3] >> >> >> > BGP4+|07/01/99 12:04:49|A|3ffe:900:0:3::1|1225|1000::/3|1225 33 109 237 7081|IGP >> >> >> > BGP4+|07/01/99 12:04:50|W|3ffe:900:0:3::1|1225|1000::/3 >> >> >> > BGP4+|07/01/99 12:06:24|A|3ffe:900:0:3::1|1225|1000::/3|1225 33 109 237 7081|IGP >> >> >> > BGP4+|07/01/99 12:06:25|W|3ffe:900:0:3::1|1225|1000::/3 >> >> >> > BGP4+|07/01/99 12:17:27|A|3ffe:900:0:3::1|1225|1000::/3|1225 33 109 237 7081|IGP >> >> >> > BGP4+|07/01/99 12:17:28|W|3ffe:900:0:3::1|1225|1000::/3 >> >> >> > BGP4+|07/01/99 12:26:30|A|3ffe:900:0:3::1|1225|1000::/3|1225 33 109 237 7081|IGP >> >> >> > BGP4+|07/01/99 12:26:31|W|3ffe:900:0:3::1|1225|1000::/3 >> >> >> > BGP4+|07/01/99 12:27:09|W|3ffe:900:0:3::1|1225|1000::/3 >> >> >> > BGP4+|07/01/99 12:27:12|W|3ffe:900:0:3::1|1225|1000::/3 >> >> >> > BGP4+|07/01/99 12:40:45|A|3ffe:900:0:3::1|1225|1000::/3|1225 33 109 237 7081|IGP >> >> >> > BGP4+|07/01/99 12:40:46|W|3ffe:900:0:3::1|1225|1000::/3 >> >> >> > [continues] >> >> >> > >> >> >> > >> From: Craig Labovitz >> >> >> > >> Subject: Re: 07/01/99 6Bone Routing Report >> >> >> > >> Date: Fri, 02 Jul 1999 10:11:00 -0400 >> >> >> > >> Message-ID: <3.0.6.32.19990702101100.007d8240@HOME.MERIT.EDU> >> >> >> > >> >> >> >> > >> >Delivered-To: ipma-support@merit.edu >> >> >> > >> >Date: Fri, 2 Jul 1999 09:24:21 -0400 (EDT) >> >> >> > >> >From: Chris Heermann >> >> >> > >> >To: ipma-support@merit.edu >> >> >> > >> >Cc: Chris Heermann >> >> >> > >> >Subject: Re: 07/01/99 6Bone Routing Report >> >> >> > >> > >> >> >> > >> > >> >> >> > >> >Yesterday's report shows CAIRN advertising 0000::/0 and 1000::/3. >> >> >> > >> >Apparently, we adertised to AS237, I think that's you/MERIT, and it came >> >> >> > >> >back to you from AS1225. I have no clue as to how we advertised those two >> >> >> > >> >prefixes. Unless there was a momentary window when someone was >> >> >> > >> >experimenting and got creative. >> >> >> > >> > >> >> >> > >> >Can you please provide me with the time this event occurred and any other >> >> >> > >> >helpful details. thanks, Chris >> >> >> > >> > >> >> >> > >> > >> >> >> > >> >> Non-6Bone Prefixes (outside of 3ffe::/16): >> >> >> > >> >> -------------------------------- >> >> >> > >> >> 0000::/0 path 1225 33 109 237 7081 (CAIRN) >> >> >> > >> >> 1000::/3 path 1225 33 109 237 7081 (CAIRN) >> >> >> > >> > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> >> >> >> > >> ------------------------- >> >> >> > >> Craig Labovitz (734) 764-0252 voice >> >> >> > >> Merit Network, Inc. labovit@merit.edu >> >> >> > >> 4251 Plymouth Road >> >> >> > >> Ann Arbor, MI 48105 >> >> >> > From kato@wide.ad.jp Wed Aug 4 01:25:36 1999 From: kato@wide.ad.jp (Akira Kato) Date: Wed, 04 Aug 1999 09:25:36 +0900 Subject: 07/01/99 6Bone Routing Report In-Reply-To: Your message of "Tue, 03 Aug 1999 14:25:57 -0400" <19990803142557I.masaki@merit.edu> References: <19990803142557I.masaki@merit.edu> Message-ID: <19990804092536A.kato@nezu.wide.ad.jp> > ago, it was too early. But, now should we make a schedule to > forget the obsolete BGP4+ version? Hirabaru san, Good point. Do you or does anybody have information on which version/date of Cisco IOS for IPv6 speaks what revision of BGP4+ ? -- Akira Kato From fink@es.net Fri Aug 6 21:01:12 1999 From: fink@es.net (Bob Fink) Date: Fri, 06 Aug 1999 13:01:12 -0700 Subject: first production IPv6 prefix allocated by ARIN to ESnet (2001:0400::/35) Message-ID: <4.1.19990806125706.00bab100@imap2.es.net> IPv6 community, Good news! The first production IPv6 prefix has been assigned by ARIN to ESnet (2001:0400::/35). This is a milestone for IPv6. Those networks that had previously requested sTLAs should now reapply to their respective registries (APNIC, ARIN and RIPE-NCC) for them. I have already been getting requests from these registries for validation that requestors qualify under the 6bone bootstrap policy. I would like to thank everyone involved over the last 2 1/2 years in the development of the Aggregatable Global Unicast Address Format and the policies regarding their allocation/assignment. I've included a short history and timeline of this effort below. I would especially like to commend the registries, both for their efforts to provide meaningful stewardship over the IPv6 address space, and for quickly starting the allocation process after IAB/IANA/RIR agreements on allocation policy were finalized. So many thanks to the APNIC, ARIN and RIPE-NCC staff! Regards, Bob === Fall 1996 - Mike O'Dell 8+8 (aka GSE) proposal to replace Provider Based Unicast Addressing for IPv6 Feb 1997 - Interim IPng WG meeting in Palo Alto to review 8+8 - some ideas kept, some discarded Apr 1997 - IPng WG meeting in Memphis - first idea of Aggregatable Unicast Addressing formulated May 1997 - Aggregatable Unicast Addressing draft and 6bone Test TLA draft released Oct 1997 - 6bone converts to Aggregatable Unicast Addressing under 3FFE::/16 Test TLA Jan 1998 - discussions begin between IAB/IETF, IANA, ARIN, APNIC and RIPE-NCC on policy to assign production TLAs Jul 1998 - RFC 2374, An IPv6 Aggregatable Global Unicast Address Format, published as Proposed Standard Aug 1998 - First requests for SubTLAs (sTLA) made to ARIN, APNIC and RIPE-NCC Jul 1999 - Oslo IETF - Final policy on assigning sTLAs reached (July 14) Jul 20 1999 - First sTLA request (by ESnet) made under new policy submitted to ARIN Jul 21 1999 - First sTLA request approved (for ESnet) by ARIN (July 21) pending billing Jul 31 1999 - First IPv6 production prefix (sTLA = 2001:0400::/35) assigned (to ESnet) -end From whchoi@cosmos.kaist.ac.kr Sat Aug 7 12:41:28 1999 From: whchoi@cosmos.kaist.ac.kr (Woohyong Choi) Date: Sat, 7 Aug 1999 20:41:28 +0900 Subject: current filtering too hostile for new prefixes? Message-ID: <19990807204128.B24351@cosmos.kaist.ac.kr> Greetings! I'm in charge of the new pTLA APAN-KR (3ffe:8040::/28) and have been trying to get stable routing during the past week. What I realized is that many of the 6bone routers already have very strict filter rules in place, and route advertizement from my primary peer 6TAP didn't get through most of you. Could you please update your filters to permit this prefix accepted (and even redistributed)? This led me to also think about "what is a good filtering policy for 6bone routers?" This is my current configuration for import filter. (for Zebra and hopefully for Cisco too?) neighbor prefix-list import in ! ip prefix-list import seq 5 permit 3ffe::/16 le 28 ge 24 ip prefix-list import seq 10 permit 2010::/16 ip prefix-list import seq 99 deny any My intension is to be more forgiving for what I receive and to be more strict in what I'm sending out. I have to list up every prefix I send out. Any comments? Thanks, -whchoi From george+6bone@m5p.com Tue Aug 10 01:40:32 1999 From: george+6bone@m5p.com (george+6bone@m5p.com) Date: Mon, 9 Aug 1999 17:40:32 -0700 (PDT) Subject: FreeBSD 3.2 + KAME SNAP 02 August 1999 Message-ID: <199908100040.RAA21209@southstation.m5p.com> I'm running FreeBSD version 3.2, and I'v installed the KAME SNAP patches from 02 August 1999. I've been able to run IP6 fairly successfully on my local Ethernet, but when I arranged a 6over4 tunnel to the 6bone, I find that the system is completely confused about the incoming packets. I ping6 the other end of my tunnel, and tcpdump correctly reports the encapsulated echo requests and echo replies, but my kernel gives me a pile of icmp6_input: unknown type where n is a random number apparently between 0 and 255, for each echo request. Is there anyone else out there using FreeBSD 3.2 and KAME who has seen this? Should I revert to FreeBSD 3.1 just so I can get an official KAME release? (Ping6 and tcpdump handle the unencapsulated packets on the local ethernet without difficulty.) -- George Mitchell (george+ip6@m5p.com) From rzm@icm.edu.pl Tue Aug 10 03:47:51 1999 From: rzm@icm.edu.pl (Rafal Maszkowski) Date: Tue, 10 Aug 1999 04:47:51 +0200 Subject: shared pTLA? Message-ID: <19990810044751.A21807@burza.icm.edu.pl> I would like to share our pTLA prefix with another site in Poland. Working together we will get more redundancy and more involvement from this other group. I am considering various options: - they could propagate our prefix as a pNLA - this is forbidden by routing rules, even more explicitely in recent draft - they could use our ASN for propagating pTLA prefix simultaneously (if the software allows) with their pNLA prefixes (using a separate ASN for this) - provider's branch option (testing 'provider buys another provider' on 6BONE:) - their router could work just as our another router, only placed in another city I think there is no problem with 3rd option, would not insist on breaking rules by using 1st, I wonder if 2nd is legitimate. What do you think, would we need anything more than negotiate the setups with BGP peers (to make them pass pTLA prefix and filter out the pNLA prefixes)? R. From george+6bone@m5p.com Tue Aug 10 06:31:18 1999 From: george+6bone@m5p.com (george+6bone@m5p.com) Date: Mon, 9 Aug 1999 22:31:18 -0700 (PDT) Subject: FreeBSD 3.2 + KAME STABLE 19990809 Message-ID: <199908100531.WAA00561@southstation.m5p.com> >From shin@nd.net.fujitsu.co.jp Mon Aug 9 18:43:09 1999 Return-Path: Received: from fgwmail3.fujitsu.co.jp (fgwmail3.fujitsu.co.jp [192.51.44.33]) by southstation.m5p.com (8.9.3/8.9.3) with ESMTP id SAA35364 for ; Mon, 9 Aug 1999 18:43:08 -0700 (PDT) Received: from fdmnews.fujitsu.co.jp by fgwmail3.fujitsu.co.jp (8.9.3/3.7W-MX9904-Fujitsu Gateway) id KAA11566; Tue, 10 Aug 1999 10:43:00 +0900 (JST) Received: from chisato.nd.net.fujitsu.co.jp by fdmnews.fujitsu.co.jp (8.9.3/3.7W-9907-Fujitsu Domain Master) id KAA24276; Tue, 10 Aug 1999 10:42:58 +0900 (JST) Received: from localhost (dhcp7186.nd.net.fujitsu.co.jp [10.18.7.186]) by chisato.nd.net.fujitsu.co.jp (8.6.12+2.4W/3.3W8chisato-970826) with ESMTP id KAA00138; Tue, 10 Aug 1999 10:42:58 +0900 To: george+6bone@m5p.com Cc: 6bone@ISI.EDU Subject: Re: FreeBSD 3.2 + KAME SNAP 02 August 1999 In-Reply-To: <199908100040.RAA21209@southstation.m5p.com> References: <199908100040.RAA21209@southstation.m5p.com> X-Mailer: Mew version 1.94b5 on XEmacs 20.4 (Emerald) X-Prom-Mew: Prom-Mew 1.93 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990810104246T.shin@nd.net.fujitsu.co.jp> Date: Tue, 10 Aug 1999 10:42:46 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990212(IM106) Lines: 38 Status: R I wrote: >> I'm running FreeBSD version 3.2, and I've installed the KAME SNAP >> patches from 02 August 1999. Yoshinobu Inoue wrote: > KAME/FreeBSD32 for 02 August 1999 version has a bug in icmp6 > error message handling. Which may let system panic, or cause > unpredictable problem. > There are patches for that. Please apply it at first (or use 09 > August version), if not yet applied. I got KAME stable release for FreeBSD 3.2 earlier this evening and rebuilt. There was no change in behavior. Itojun wrote: > Could you give us the configuration diagram of your setup? > Notice that KAME does not have 6over4 code yet, so configuration > that throws 6over4 packet toward KAME box does not work. > (see kit/IMPLEMENTATION for supported/unsupported items) kit/IMPLEMENTATION section 1.5 says: 1.5 Generic tunnel interface GIF (Generic InterFace) is a pseudo interface for configured tunnel. Details are described in gif(4) manpage. Currently v6 in v6 v6 in v4 v4 in v6 v4 in v4 are available. Use "gifconfig" to assign physical (outer) source and destination address to gif interfaces. Here is my configuration: Ethernet interface ed0 connects to local network running unencapsulated IPv6. It seems to work, to the limited extent that I've tested it. Ethernet interface xl0 (3Com 3C905) connects only to Cisco 675 ADSL router-bridge in bridge mode to DSL ISP, running IPv4 only. I have an IPv6-in-IPv4 tunnel to NWNET. ifconfig xl0: xl0: flags=8843 mtu 1500 inet6 fe80:1::210:5aff:fea9:3338 prefixlen 64 inet 209.162.215.52 netmask 0xffffff00 broadcast 209.162.215.255 inet6 3ffe:a00:0:160:210:5aff:fea9:3338 prefixlen 64 inet6 3ffe:a00:0:160:: prefixlen 64 anycast ether 00:10:5a:a9:33:38 media: 100baseTX gifconfig gif0: gif0: flags=8051 mtu 1280 inet6 fe80:4::210:5aff:fea9:3338 prefixlen 64 inet6 3ffe:a00:2:2::1e --> 3ffe:a00:2:2::1d prefixlen 126 physical address inet 209.162.215.52 --> 192.220.249.249 When I "ping6 3ffe:a00:2:2::1d", instead of getting replies, I get the following messages from the kernel: icmp6_input: unknown type 0 icmp6_input: unknown type 0 icmp6_input: unknown type 0 icmp6_input: unknown type 0 icmp6_input: unknown type 0 icmp6_input: unknown type 0 icmp6_input: unknown type 0 icmp6_input: unknown type 0 icmp6_input: unknown type 0 icmp6_input: unknown type 0 icmp6_input: unknown type 50 icmp6_input: unknown type 32 Meanwhile, tcpdump host 192.220.249.249 says: tcpdump: listening on xl0 22:26:45.124259 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap) 22:26:45.159733 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap) 22:26:46.124120 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap) 22:26:46.158128 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap) 22:26:47.114115 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap) 22:26:47.147930 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap) 22:26:48.114148 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap) 22:26:48.150301 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap) 22:26:49.114149 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap) 22:26:49.146042 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap) 22:26:50.114158 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap) 22:26:50.148386 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap) 22:26:51.114172 southstation.m5p.com > lo0.nwnet-6bone-gw.nw.verio.net: 3ffe:a00:2:2::1e > 3ffe:a00:2:2::1d: icmp6: echo request (encap) 22:26:51.149426 lo0.nwnet-6bone-gw.nw.verio.net > southstation.m5p.com: 3ffe:a00:2:2::1d > 3ffe:a00:2:2::1e: icmp6: echo reply (encap) What this says to me is that the tunnel is up, ping6 can send packets through it to NWNET, NWNET is responding to the packets, the replies are arriving at the xl0 interface, but then they're getting lost in the stack. Help! -- George Mitchell (george+6bone@m5p.com) From nitzan@es.net Tue Aug 10 17:34:08 1999 From: nitzan@es.net (Rebecca L. Nitzan) Date: Tue, 10 Aug 1999 09:34:08 -0700 Subject: current filtering too hostile for new prefixes? In-Reply-To: Your message of "Sat, 07 Aug 1999 20:41:28 +0900." <19990807204128.B24351@cosmos.kaist.ac.kr> Message-ID: <199908101634.JAA05462@hershey.es.net> Hi: While you're updating filter lists, add the new 6tap pTLA of 3ffe:3900/24. I think we need to filter on specific prefix, the problem is that there is not enough usage/user-complaints to put the appropriate mechanisms in place to make sure the filter lists are up-to-date (like we all make damn sure work for ipv4). One way to stay ahead of the ptla assignment game, is to add a few subsequent number assignments in advance; doesn't hurt anything to do that. -- Becca >Greetings! I'm in charge of the new pTLA APAN-KR (3ffe:8040::/28) >and have been trying to get stable routing during the past week. > >What I realized is that many of the 6bone routers already have >very strict filter rules in place, and route advertizement from >my primary peer 6TAP didn't get through most of you. > >Could you please update your filters to permit this prefix >accepted (and even redistributed)? > >This led me to also think about "what is a good filtering policy >for 6bone routers?" > >This is my current configuration for import filter. (for Zebra >and hopefully for Cisco too?) > >neighbor prefix-list import in >! >ip prefix-list import seq 5 permit 3ffe::/16 le 28 ge 24 >ip prefix-list import seq 10 permit 2010::/16 >ip prefix-list import seq 99 deny any > >My intension is to be more forgiving for what I receive and >to be more strict in what I'm sending out. I have to list >up every prefix I send out. > >Any comments? > >Thanks, >-whchoi From fink@es.net Wed Aug 11 06:01:41 1999 From: fink@es.net (Bob Fink) Date: Tue, 10 Aug 1999 22:01:41 -0700 Subject: shared pTLA? In-Reply-To: <19990810044751.A21807@burza.icm.edu.pl> Message-ID: <4.1.19990810215908.00c2cd30@imap2.es.net> Rafal, At 04:47 AM 8/10/99 +0200, Rafal Maszkowski wrote: >I would like to share our pTLA prefix with another site in Poland. Working >together we will get more redundancy and more involvement from this other >group. I am considering various options: > >- they could propagate our prefix as a pNLA - this is forbidden by routing > rules, even more explicitely in recent draft >- they could use our ASN for propagating pTLA prefix simultaneously (if the > software allows) with their pNLA prefixes (using a separate ASN for this) >- provider's branch option (testing 'provider buys another provider' on 6BONE:) > - their router could work just as our another router, only placed in another > city > >I think there is no problem with 3rd option, would not insist on breaking rules >by using 1st, I wonder if 2nd is legitimate. What do you think, would we need >anything more than negotiate the setups with BGP peers (to make them pass pTLA >prefix and filter out the pNLA prefixes)? No one else seems to have responded to you, so I'll try. In my simple view if you want to both share the same pTLA, you are both are agreeing to act as one network. This means to me same ASN, same BGP4+ policies to your peers, and literally running both sets of routers as if they are one and the same network. Essentailly your third option above. Bob From bound@zk3.dec.com Thu Aug 12 19:24:54 1999 From: bound@zk3.dec.com (Jim Bound) Date: Thu, 12 Aug 1999 14:24:54 -0400 Subject: FYI: IPv6 Forum Deployment Technical Directorate Message-ID: <199908121824.OAA0000011853@quarry.zk3.dec.com> ------- Forwarded Message Return-Path: bound@quarry.zk3.dec.com Received: from quarry.zk3.dec.com by iota.zk3.dec.com (8.7.6/UNX 1.7/1.1.20.3/24Apr98-0811AM) id NAA0000023671; Thu, 12 Aug 1999 13:50:14 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000029337; Thu, 12 Aug 1999 13:49:50 -0400 (EDT) From: Jim Bound Message-Id: <199908121749.NAA0000029337@quarry.zk3.dec.com> To: deployment@ipv6.org, members@ipv6forum.com cc: bound@zk3.dec.com, perry@piermont.com, tim@mentat.com, peter@jazz-1.trumpet.com.au, cmj@nsd.3com.com, mccann@zk3.dec.com, bzill@microsoft.com, Francis.Dupont@inria.fr, Marc.Blanchet@viagenie.qc.ca, dmf@unl.edu, thomas.eklund@broadswitch.com, venaas@alfa.itea.ntnu.no, haberman@raleigh.ibm.com, crawdad@fnal.gov, halley@vix.com, deering@cisco.com, hinden@iprg.nokia.com, huitema@bellcore.com, brian@hursley.ibm.com, sob@harvard.edu, mankin@ISI.EDU, RLFink@lbl.gov, Charles.Perkins@eng.sun.com Subject: IPv6 Forum Deployment Technical Directorate Initial Members Date: Thu, 12 Aug 1999 13:49:49 -0400 X-Mts: smtp Folks, Perry and I would like to notify you that we have identified the initial Technical Directorate members and we also felt it important to ask Sr. Technical folks who have been around IPv6 and networks for some time to be part of the Directorate as Advisors. See other caveats below too. The list is as follows: IPv6 Deployment Technical Directorate. Jim Bound & Co-Chair Perry Metzger & Co-Chair Tim Hartrick Peter Tattam Cyndi Jung Jack McCann Brian Zill Francis Dupont Marc Blanchet Dale Finkelson Thomas Eckland Stig Venass Brian Haberman Matt Crawford Bob Halley Advisors: Bob Hinden Steve Deering Brian Carpenter Allison Mankin Christian Huitema Bob Fink Charlie Perkins Scott Bradner We still are awaiting responses from other folks for the Directorate and have run into vacation times we believe. These folks are doing this for free and here are some caveats we will use to guide the Directorate: 1. The Tech Directorate will be a body to do a logic check on all technical materials and deployment strategies by the IPv6 Forum in their fever to get IPv6 deployed, which is presented to the market. It will also do education. 2. The Tech Directorate will make recommendations on deploymemnt and implementation tradeoffs for deployment if those kind of problems arise too, as it releates to IPv6 Forum marketing. 3. The Tech Directorate if it finds errors in IPv6 in their work above will relay that back to the IETF. The Directorate is not to ever become anything like the ATM Forum nor define protocols for IPv6. 4. The Tech Direcorate also is autonoumous to the IPv6 Forum so we have no Kings or Queens either, the Directorate is a complimentary body to the IPv6 Forum. 5. Tech Directorate members will do presentations and be on hand for IPv6 Forum activities when possible but that is not required as a Tech Directorate member. For some cases it may be required that the IPv6 Forum pay for the Travel/Expense for Tech Directorate members when they do not work for large corporate enterprises, if possible. 6. The Tech Directorate will have a mail list soon that folks can use which Marc Blanchet will set up soon. It is perceived the Tech Directorate will have scheduled con-calls to meet and discuss issues about every 6 weeks and as required. Tech Directorate members should be at IETF meetings as that event can be a place to huddle as a team. 7. The only real differentiation in the Advisor role is they are not expected to do "work" consistently as required by other members as most of them are busy in this space in other areas, but to help advise us on the tough deployment technical issues where there are multiple choices. We would like to note that some requests for members were turned down by the person contacted because there is some work load here, this is not expected of the Advisors. 8. Tech Directorate members must be technical and an active participant for the deployment of IPv6 in some manner which can be research, product implememntation, significant IETF IPv6 contributions, network managment and opertions DRI, etc.... 9. Other roles to evolve if necessary or adjuncts to the these caveats. Sincerely, /jim and p.m. ------- End of Forwarded Message From fink@es.net Fri Aug 13 06:31:14 1999 From: fink@es.net (Bob Fink) Date: Thu, 12 Aug 1999 22:31:14 -0700 Subject: 6bone pTLA 3FFE:8050::/28 assigned to MIBH Message-ID: <4.1.19990812222331.00bdd590@imap2.es.net> After the requisite review period, MIBH has been assigned pTLA 3FFE:8050::/28. Bob From kato@wide.ad.jp Fri Aug 13 09:10:01 1999 From: kato@wide.ad.jp (Akira Kato) Date: Fri, 13 Aug 1999 17:10:01 +0900 Subject: Two updates from WIDE Message-ID: <19990813171001J.kato@nezu.wide.ad.jp> 1. We got 2001:200::/35 sTLA block from APNIC. We will start renumbering soon. 2. Third (?) internet exchange point has been bootstraped in Tokyo called as "NSPIXP-6". Currently 4 ASs are connected. See http://www.wide.ad.jp/nspixp6/ -- Akira Kato, WIDE Project From plano@alanet.com.br Fri Aug 13 11:44:32 1999 From: plano@alanet.com.br (Plano) Date: Fri, 13 Aug 1999 07:44:32 -0300 Subject: No subject Message-ID: <000d01bee578$d60a7b80$360a0a80@chico> This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BEE55F.AE9C8660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable leave 6bone ------=_NextPart_000_000A_01BEE55F.AE9C8660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

leave = 6bone

------=_NextPart_000_000A_01BEE55F.AE9C8660-- From fink@es.net Fri Aug 13 14:05:29 1999 From: fink@es.net (Bob Fink) Date: Fri, 13 Aug 1999 06:05:29 -0700 Subject: Two updates from WIDE In-Reply-To: <19990813171001J.kato@nezu.wide.ad.jp> Message-ID: <4.1.19990813060032.00bee480@imap2.es.net> Akira, At 05:10 PM 8/13/99 +0900, Akira Kato wrote: > >1. We got 2001:200::/35 sTLA block from APNIC. We will start > renumbering soon. Wonderful. This appears to be the very first APNIC allocation. >2. Third (?) internet exchange point has been bootstraped in Tokyo > called as "NSPIXP-6". Currently 4 ASs are connected. See > http://www.wide.ad.jp/nspixp6/ This is good. Presumably this would be the peering partner for the 6TAP in Japan over the existing ATM path? We should add a pointer to this page on the 6tap.net pages. Thanks, Bob From brian@hursley.ibm.com Sun Aug 15 18:04:18 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Sun, 15 Aug 1999 12:04:18 -0500 Subject: Two updates from WIDE References: <4.1.19990813060032.00bee480@imap2.es.net> Message-ID: <37B6F312.4CF2FCCA@hursley.ibm.com> Akira, It would be really useful to get a complete report on your experience with renumbering (time spent, problems found, etc.) Brian Bob Fink wrote: > > Akira, > > At 05:10 PM 8/13/99 +0900, Akira Kato wrote: > > > >1. We got 2001:200::/35 sTLA block from APNIC. We will start > > renumbering soon. > > Wonderful. This appears to be the very first APNIC allocation. > > >2. Third (?) internet exchange point has been bootstraped in Tokyo > > called as "NSPIXP-6". Currently 4 ASs are connected. See > > http://www.wide.ad.jp/nspixp6/ > > This is good. Presumably this would be the peering partner for the 6TAP in > Japan over the existing ATM path? We should add a pointer to this page on > the 6tap.net pages. > > Thanks, > > Bob -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org From cmj@3com.com Wed Aug 18 00:17:43 1999 From: cmj@3com.com (Cyndi Jung) Date: Tue, 17 Aug 1999 16:17:43 -0700 Subject: replacement ipv6-site object in 6bone registry Message-ID: <3.0.32.19990817161743.00e12e58@pop.nsd.3com.com> For whom it may concern, I took control of our 6bone site here at 3Com a couple of months ago, and in the course of this I noticed that we had not been keeping our site documentation up to date. Also, we did not have a DNS server to keep AAAA records in, and had no web server to describe our site. So, I had a summer intern, Sonum Mathur, work on the DNS server and web server for me (thanks to any of you that gave him help this summer), and in the course of this it became clear that we needed a separate domain name to provide us with full authority over our names. That in turn led ultimately to the re-creation of the ipv6-site object in the registry. So, I am happy to announce the new ipv6-site object 6COM, and the web site that is probably still in need of work but is getting closer. I have some tunnels with some folks - I will be sending them mail begging them to change their ipv6-site objects to reflect the new name of the 3Com IPv6 site - 6COM. Thanks, Cyndi From bruce.campbell@apnic.net Wed Aug 18 04:41:12 1999 From: bruce.campbell@apnic.net (Bruce Campbell) Date: Wed, 18 Aug 1999 13:41:12 +1000 (EST) Subject: Two updates from WIDE In-Reply-To: <4.1.19990813060032.00bee480@imap2.es.net> Message-ID: On Fri, 13 Aug 1999, Bob Fink wrote: fink> Akira, fink> fink> At 05:10 PM 8/13/99 +0900, Akira Kato wrote: fink> > fink> >1. We got 2001:200::/35 sTLA block from APNIC. We will start fink> > renumbering soon. fink> fink> Wonderful. This appears to be the very first APNIC allocation. It is indeed and the only APNIC IPv6 assignment so far. Congratulations ;) On a related note, APNIC is also putting the reverse delegations for IPv4 and IPv6 as the matching in-addr.arpa and ip6.int domain objects into the APNIC whois database and generating the appropriate zone files daily. ie: whois -h whois.apnic.net 0.0.0.2.0.1.0.0.2.ip6.int As IPv6 is relatively new, does anyone have comments on how to manage IPv6 reverse delegations? Bear in mind that a human editing the zone files is *not* an option ;) . --==-- Bruce. Sysadmin, APNIC. From peter@jazz-1.trumpet.com.au Wed Aug 18 07:52:02 1999 From: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Wed, 18 Aug 1999 16:52:02 +1000 (EST) Subject: Two updates from WIDE In-Reply-To: Message-ID: On Wed, 18 Aug 1999, Bruce Campbell wrote: > On Fri, 13 Aug 1999, Bob Fink wrote: > > fink> Akira, > fink> > fink> At 05:10 PM 8/13/99 +0900, Akira Kato wrote: > fink> > > fink> >1. We got 2001:200::/35 sTLA block from APNIC. We will start > fink> > renumbering soon. > fink> > fink> Wonderful. This appears to be the very first APNIC allocation. > > It is indeed and the only APNIC IPv6 assignment so far. Congratulations ;) > > On a related note, APNIC is also putting the reverse delegations for IPv4 > and IPv6 as the matching in-addr.arpa and ip6.int domain objects into the > APNIC whois database and generating the appropriate zone files daily. > > ie: whois -h whois.apnic.net 0.0.0.2.0.1.0.0.2.ip6.int > > As IPv6 is relatively new, does anyone have comments on how to manage IPv6 > reverse delegations? Bear in mind that a human editing the zone files is > *not* an option ;) . BTW, on the reverse delegation issue, it was a hot issue recently on ipng. Most of us are stuck with manual editing at the moment. I believe there sin't a real concensus yet on the best way to manage automatic delegation. I can send you some templates of what I do manually though. > > --==-- > Bruce. > > Sysadmin, APNIC. > > > > > 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 bruce.campbell@apnic.net Wed Aug 18 08:06:51 1999 From: bruce.campbell@apnic.net (Bruce Campbell) Date: Wed, 18 Aug 1999 17:06:51 +1000 (EST) Subject: Reverse DNS, IPv6 In-Reply-To: Message-ID: On Wed, 18 Aug 1999, Peter Tattam wrote: peter> > On a related note, APNIC is also putting the reverse delegations for IPv4 peter> > and IPv6 as the matching in-addr.arpa and ip6.int domain objects into the peter> > APNIC whois database and generating the appropriate zone files daily. peter> > peter> > ie: whois -h whois.apnic.net 0.0.0.2.0.1.0.0.2.ip6.int peter> > peter> > As IPv6 is relatively new, does anyone have comments on how to manage IPv6 peter> > reverse delegations? Bear in mind that a human editing the zone files is peter> > *not* an option ;) . peter> peter> BTW, on the reverse delegation issue, it was a hot issue recently on ipng. peter> Most of us are stuck with manual editing at the moment. I believe there sin't peter> a real concensus yet on the best way to manage automatic delegation. I can peter> send you some templates of what I do manually though. After re-reading the ipng mails, the debate seemed to be more in dealing with reverse delegations for individual hosts. My concern is more with the 'lofty' (so to speak) delegations as done by the registries, or by ISPs to customer sites. I doubt that we'd would ever be using dhcp for such delegations (scary). --==-- Bruce. Sysadmin, APNIC. From peter@jazz-1.trumpet.com.au Wed Aug 18 08:22:51 1999 From: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Wed, 18 Aug 1999 17:22:51 +1000 (EST) Subject: Reverse DNS, IPv6 In-Reply-To: Message-ID: On Wed, 18 Aug 1999, Bruce Campbell wrote: > On Wed, 18 Aug 1999, Peter Tattam wrote: > > peter> > On a related note, APNIC is also putting the reverse delegations for IPv4 > peter> > and IPv6 as the matching in-addr.arpa and ip6.int domain objects into the > peter> > APNIC whois database and generating the appropriate zone files daily. > peter> > > peter> > ie: whois -h whois.apnic.net 0.0.0.2.0.1.0.0.2.ip6.int > peter> > > peter> > As IPv6 is relatively new, does anyone have comments on how to manage IPv6 > peter> > reverse delegations? Bear in mind that a human editing the zone files is > peter> > *not* an option ;) . > peter> > peter> BTW, on the reverse delegation issue, it was a hot issue recently on ipng. > peter> Most of us are stuck with manual editing at the moment. I believe there sin't > peter> a real concensus yet on the best way to manage automatic delegation. I can > peter> send you some templates of what I do manually though. > > After re-reading the ipng mails, the debate seemed to be more in dealing > with reverse delegations for individual hosts. My concern is more with > the 'lofty' (so to speak) delegations as done by the registries, or by > ISPs to customer sites. I doubt that we'd would ever be using dhcp for > such delegations (scary). > > --==-- > Bruce. > > Sysadmin, APNIC. > > It would just be a matter of allocating according to the RFC's I guess. Mind you not being aligned to 4 bit boundaries is a right pain which is I guess your question. Were they going to fix that? It ended up being fixed in the 6bone. Until A6 is available in software, things will be a bit of a pain. 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 burgess@mitre.org Wed Aug 18 16:53:58 1999 From: burgess@mitre.org (David Burgess) Date: Wed, 18 Aug 1999 10:53:58 -0500 Subject: Two updates from WIDE References: Message-ID: <37BAD716.F5380F0@mitre.org> Bruce Campbell wrote: > > On a related note, APNIC is also putting the reverse delegations for IPv4 > and IPv6 as the matching in-addr.arpa and ip6.int domain objects into the > APNIC whois database and generating the appropriate zone files daily. > > ie: whois -h whois.apnic.net 0.0.0.2.0.1.0.0.2.ip6.int > > As IPv6 is relatively new, does anyone have comments on how to manage IPv6 > reverse delegations? Bear in mind that a human editing the zone files is > *not* an option ;) . There's a product called 'webmin' that manages IPv4 DNS entries (both forward and reverse) which comes with source. It could probably be modified to include AAAA records and manage a reverse name pool with very little overhead. It's also inexpensive (free for now; low triple digit $ in the future). From bmanning@ISI.EDU Thu Aug 19 00:08:14 1999 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Wed, 18 Aug 1999 16:08:14 -0700 (PDT) Subject: subtla ip6.int greenlight Message-ID: <199908182308.AA14996@zed.isi.edu> Hi, I received this note today. ------------------------------------------------- Date: Wed, 18 Aug 1999 15:40:04 -0700 Bill, You have the green light for IN-ADDR delegations of IPv6 sub-TLAs. The new IPv6 files are on the IANA website. Thanks. -------------------------------------------------- APNIC: Aug 18 15:19:16 dot named[210]: slave zone "2.0.1.0.0.2.ip6.int" (IN) loaded (se rial 1999081601) ug 18 15:19:19 dot named[210]: slave zone "3.0.1.0.0.2.ip6.int" (IN) loaded (se rial 1999073001) ARIN: Aug 18 15:19:23 dot named[210]: Err/TO getting serial# for "4.0.1.0.0.2.ip6.int" Aug 18 15:19:24 dot named-xfer[31504]: [192.149.252.21] not authoritative for 4. 0.1.0.0.2.ip6.int, SOA query got rcode 0, aa 0, ancount 0, aucount 13 Aug 18 15:19:37 dot named[210]: Err/TO getting serial# for "5.0.1.0.0.2.ip6.int" Aug 18 15:19:38 dot named-xfer[31505]: [192.149.252.21] not authoritative for 5. 0.1.0.0.2.ip6.int, SOA query got rcode 0, aa 0, ancount 0, aucount 13 RIPE: Aug 18 15:19:14 dot named[210]: slave zone "7.0.1.0.0.2.ip6.int" (IN) loaded (serial 1999073001) Aug 18 15:19:46 dot named[210]: slave zone "6.0.1.0.0.2.ip6.int" (IN) loaded (serial 1999081702) --bill From Alain.Durand@imag.fr Thu Aug 19 08:08:44 1999 From: Alain.Durand@imag.fr (Alain Durand) Date: Thu, 19 Aug 1999 09:08:44 +0200 Subject: 6to4 TLA Message-ID: <4.2.0.58.19990819090426.00b645e0@brahma.imag.fr> Hi Folks, I just received a note from IANA saying that they have approved the delegation of TLA 0x2002 to 6to4. Note: this is not the same TLA number as the one we have been using in the early test period. So people using the "old" 6to4 TLA 0x2010 will have to renumber. - Alain. From bmanning@ISI.EDU Thu Aug 19 19:10:08 1999 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 19 Aug 1999 11:10:08 -0700 (PDT) Subject: subtla ip6.int greenlight In-Reply-To: from "Shane Kerr" at Aug 19, 99 12:56:32 pm Message-ID: <199908191810.LAA25559@zephyr.isi.edu> > Bill, > > I've looked at our zone files, and corrected an error in the SOA field. > Your named-xfer should (hopefully) work properly now. Thanks! > In the future, it would probably be easier on everyone if you first > contacted me (or Kim) directly if there's a technical problem. This DNS > issue is the kind of bootstrapping problem I was hoping to avoid when I > tried contacting you last month. You did tell me that these were working servers. Just like the RIPE & APNIC folks told me they had working servers. Just in a hurry to get the DNS piece working since ARIN, along with the other RIRs have been busy delegating sub-blocks for a couple of weeks now. --bill From ksbn@kt.co.kr Thu Aug 26 03:37:11 1999 From: ksbn@kt.co.kr (ksb) Date: Thu, 26 Aug 1999 11:37:11 +0900 Subject: question Message-ID: <37C4A857.3C1A82ED@kt.co.kr> How are you? Could you send me a E-mail for how to be the member? Sincerely, Sahng-Beom Kim -- 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 Thu Aug 26 05:07:27 1999 From: fink@es.net (Bob Fink) Date: Wed, 25 Aug 1999 21:07:27 -0700 Subject: question In-Reply-To: <37C4A857.3C1A82ED@kt.co.kr> Message-ID: <4.1.19990825210651.00b73260@imap2.es.net> At 11:37 AM 8/26/99 +0900, ksb wrote: >How are you? > >Could you send me a E-mail for how to be the member? See the page for mail list info. Bob From kay@v6.access.co.jp Mon Aug 30 10:04:02 1999 From: kay@v6.access.co.jp (kay (=?iso-2022-jp?B?GyRCJU4lMCVBJTElJBsoQg==?=)) Date: Mon, 30 Aug 1999 18:04:02 +0900 Subject: question in draft-ietf-ngtrans-harden-01.txt In-Reply-To: <19990830165842W.koji@dti.ad.jp> References: <19990830165842W.koji@dti.ad.jp> Message-ID: <19990830180402S.kay@v6.access.co.jp> Hi, folks I have one question in draft-ietf-ngtrans-harden-01.txt. In Section 7.1, b, draft says appropriate hierarchy. This includes a high uptime availability of the site router (greater than 99%). This What does this "99%" digit mean? 1) availability of bgp peering with neighbours? 2) availability of router machine itself? 3) or something else? Thanks in advance --- kay Koji Kondo (近藤浩志) wrote | 今、熟読中。 | draft-ietf-ngtrans-harden-01.txt の section 7 にて、 | | 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. | | ここの、"This includes a high uptime availability of the site router | (greater than 99%)." の部分って、どういうことなんかな？ | From fink@es.net Mon Aug 30 16:38:59 1999 From: fink@es.net (Bob Fink) Date: Mon, 30 Aug 1999 08:38:59 -0700 Subject: question in draft-ietf-ngtrans-harden-01.txt In-Reply-To: <19990830180402S.kay@v6.access.co.jp> References: <19990830165842W.koji@dti.ad.jp> <19990830165842W.koji@dti.ad.jp> Message-ID: <4.1.19990830082736.00c52c70@imap2.es.net> At 06:04 PM 8/30/99 +0900, =?iso-2022-jp?B?GyRCJU4lMCVBJTElJBsoQg==?= wrote: >Hi, folks > >I have one question in draft-ietf-ngtrans-harden-01.txt. >In Section 7.1, b, draft says > > appropriate hierarchy. This includes a high uptime > availability of the site router (greater than 99%). This > >What does this "99%" digit mean? > > 1) availability of bgp peering with neighbours? > 2) availability of router machine itself? > 3) or something else? It is meant to be vague so so to imply high reliability in any and all meaningful areas. It is unlikely it would ever be really measured as we are by and large self policing, but it tries to convey intent. Bob From kay@v6.access.co.jp Mon Aug 30 17:51:11 1999 From: kay@v6.access.co.jp (kay (=?iso-2022-jp?B?GyRCJU4lMCVBJTElJBsoQg==?=)) Date: Tue, 31 Aug 1999 01:51:11 +0900 Subject: question in draft-ietf-ngtrans-harden-01.txt In-Reply-To: <4.1.19990830082736.00c52c70@imap2.es.net> References: <19990830165842W.koji@dti.ad.jp> <19990830180402S.kay@v6.access.co.jp> <4.1.19990830082736.00c52c70@imap2.es.net> Message-ID: <19990831015111X.kay@v6.access.co.jp> Hi bob, Thank you for quick reply. | It is meant to be vague so so to imply high reliability in any and all | meaningful areas. It is unlikely it would ever be really measured as we are | by and large self policing, but it tries to convey intent. I understand above. Is this RFC standard style to mention reliability? How about exactly mentioning like above(imply high reliability) to avoid confusion? P.S. Sorry for appending your mail, koji ;p Bob Fink wrote | At 06:04 PM 8/30/99 +0900, =?iso-2022-jp?B?GyRCJU4lMCVBJTElJBsoQg==?= wrote: | >Hi, folks | > | >I have one question in draft-ietf-ngtrans-harden-01.txt. | >In Section 7.1, b, draft says | > | > appropriate hierarchy. This includes a high uptime | > availability of the site router (greater than 99%). This | > | >What does this "99%" digit mean? | > | > 1) availability of bgp peering with neighbours? | > 2) availability of router machine itself? | > 3) or something else? | | It is meant to be vague so so to imply high reliability in any and all | meaningful areas. It is unlikely it would ever be really measured as we are | by and large self policing, but it tries to convey intent. | | | Bob --- kay From fink@es.net Mon Aug 30 23:24:41 1999 From: fink@es.net (Bob Fink) Date: Mon, 30 Aug 1999 15:24:41 -0700 Subject: question in draft-ietf-ngtrans-harden-01.txt In-Reply-To: <19990831015111X.kay@v6.access.co.jp> References: <4.1.19990830082736.00c52c70@imap2.es.net> <19990830165842W.koji@dti.ad.jp> <19990830180402S.kay@v6.access.co.jp> <4.1.19990830082736.00c52c70@imap2.es.net> Message-ID: <4.1.19990830152244.00c9a310@imap2.es.net> At 01:51 AM 8/31/99 +0900, =?iso-2022-jp?B?GyRCJU4lMCVBJTElJBsoQg==?= wrote: >Hi bob, >Thank you for quick reply. > >| It is meant to be vague so so to imply high reliability in any and all >| meaningful areas. It is unlikely it would ever be really measured as we are >| by and large self policing, but it tries to convey intent. > >I understand above. > >Is this RFC standard style to mention reliability? Though this is to eventually be an RFC, it is an informational RFC, not a standards track or experimental RFC, thus there aren't any hard and fast rules. >How about exactly mentioning like above(imply high reliability) >to avoid confusion? Ok, I'll ask Rob Rockell as he is the author. Thanks, Bob From rrockell@sprint.net Tue Aug 31 02:22:42 1999 From: rrockell@sprint.net (Robert Rockell) Date: Mon, 30 Aug 1999 21:22:42 -0400 (EDT) Subject: question in draft-ietf-ngtrans-harden-01.txt In-Reply-To: <4.1.19990830152244.00c9a310@imap2.es.net> Message-ID: I will make changes (there a couple others I'd been meaning to make as well, but have been busy with my real job) and post another draft by end of week. good input. It seems like there should be something in there to quantify how we give out pTLA's, especially if it is to be taken seriously, or it can be used to influence how ARIN does it in the future, or whatever the scope of this paper may be. Kay, do you have any ideas? I can't think of anything quantitative that isn't militaristic. 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, 30 Aug 1999, Bob Fink wrote: ->At 01:51 AM 8/31/99 +0900, =?iso-2022-jp?B?GyRCJU4lMCVBJTElJBsoQg==?= wrote: ->>Hi bob, ->>Thank you for quick reply. ->> ->>| It is meant to be vague so so to imply high reliability in any and all ->>| meaningful areas. It is unlikely it would ever be really measured as we are ->>| by and large self policing, but it tries to convey intent. ->> ->>I understand above. ->> ->>Is this RFC standard style to mention reliability? -> ->Though this is to eventually be an RFC, it is an informational RFC, not a ->standards track or experimental RFC, thus there aren't any hard and fast rules. -> -> ->>How about exactly mentioning like above(imply high reliability) ->>to avoid confusion? -> ->Ok, I'll ask Rob Rockell as he is the author. -> -> ->Thanks, -> ->Bob -> From kay@v6.access.co.jp Tue Aug 31 03:14:42 1999 From: kay@v6.access.co.jp (kay (=?iso-2022-jp?B?GyRCJU4lMCVBJTElJBsoQg==?=)) Date: Tue, 31 Aug 1999 11:14:42 +0900 Subject: question in draft-ietf-ngtrans-harden-01.txt In-Reply-To: References: <4.1.19990830152244.00c9a310@imap2.es.net> Message-ID: <19990831111442R.kay@v6.access.co.jp> Hi Rob, Robert Rockell wrote | I will make changes (there a couple others I'd been meaning to make as well, | but have been busy with my real job) and post another draft by end of week. Thank you for quick responce. | good input. It seems like there should be something in there to quantify how | we give out pTLA's, especially if it is to be taken seriously, or it can be | used to influence how ARIN does it in the future, or whatever the scope of | this paper may be. Kay, do you have any ideas? I can't think of anything | quantitative that isn't militaristic. I think that any quantitative exclamation(99%) is confusing thing in this section, so that just "high uptime availability" is good enough. If you use something quantitavive, please add some explanation what that quantify means. Thank you --- kay