From ksbn@kt.co.kr Thu Jul 1 07:09:18 1999 From: ksbn@kt.co.kr (ksb) Date: Thu, 01 Jul 1999 15:09:18 +0900 Subject: v6 browser Message-ID: <377B060E.9129AEAC@kt.co.kr> How are you? members, I'm looking for IPv6 web browsers for Solaris 7. Will you send me some information? Thank you. -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- From rsofia@rccn.net Thu Jul 1 14:34:02 1999 From: rsofia@rccn.net (Rute Sofia) Date: Thu, 1 Jul 1999 14:34:02 +0100 (WET DST) Subject: DiffServ and IPv6 In-Reply-To: <377A8772.11875F88@hursley.ibm.com> Message-ID: Well, I was thinking more about addressing, something like using anycast and, for instance, bandwidth brokers. Sorry for pushing it :-), but I am interested in exploring new areas related with IPv6, not meaning to put aside IPv4. :-) Thanks, Rute Sofia --------------------------------------------------- Helena Rute Esteves Carvalho Sofia FCCN Av. do Brasil, 101 1799 LISBOA CODEX tel.: 8440115 fax: 8472167 e-mail: rsofia@rccn.net "After silence, that which comes nearest to expressing the inexpressible is Music." - Aldous Huxley --------------------------------------------------- On Wed, 30 Jun 1999, Brian E Carpenter wrote: > Diffserv only uses the Traffic Class field, and operates identically > for IPv4 and IPv6. It would be interesting to hear if anyone > has implemented diffserv for IPv6 so far, but there should be no > difference from IPv4. > > Brian > > Rute Sofia wrote: > > > > Hi. > > > > I would like to know if anyone's working in DiffServ but specifically > > with IPv6, besides the use of the Traffic Class field as the DS byte. > > > > Does anyone have any ideas on this? If yes, could you please point out > > some links or papers on the subject ? > > > > Thanks, > > > > Rute Sofia > > > > --------------------------------------------------- > > Helena Rute Esteves Carvalho Sofia > > FCCN > > Av. do Brasil, 101 > > 1799 LISBOA CODEX > > tel.: 8440115 > > fax: 8472167 > > e-mail: rsofia@rccn.net > > "After silence, that which comes nearest to expressing > > the inexpressible is Music." - Aldous Huxley > > > > --------------------------------------------------- > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter (IAB Chair) > Program Director, Internet Standards & Technology, IBM Internet Div > As of May 24, 1999: on assignment for IBM at http://www.iCAIR.org > Non-IBM email: brian@icair.org > From dancer@zeor.simegen.com Thu Jul 1 15:04:24 1999 From: dancer@zeor.simegen.com (Dancer) Date: Fri, 02 Jul 1999 00:04:24 +1000 Subject: v6 browser References: <377B060E.9129AEAC@kt.co.kr> Message-ID: <377B7568.FC01515F@zeor.simegen.com> ksb wrote: > > How are you? members, > > I'm looking for IPv6 web browsers for Solaris 7. > Will you send me some information? > > Thank you. > > -- > Kim, Sahng-Beom / Korea Telecom > TEL : +82-42-870-8322 > FAX : +82-42-870-8329 > E-mail : ksbn@kt.co.kr > -- I have a small proxy that can access ipv4/ipv6 HTTP servers. It's getting a rewrite before release. (it's a hack of something else I did, so it's pretty ugly) D From perry@piermont.com Thu Jul 1 15:12:57 1999 From: perry@piermont.com (Perry E. Metzger) Date: 01 Jul 1999 10:12:57 -0400 Subject: v6 browser In-Reply-To: ksb's message of "Thu, 01 Jul 1999 15:09:18 +0900" References: <377B060E.9129AEAC@kt.co.kr> Message-ID: <87lnd0o3va.fsf@jekyll.piermont.com> ksb writes: > How are you? members, > > I'm looking for IPv6 web browsers for Solaris 7. > Will you send me some information? The KAME project has patches for Mozilla -- see http://www.ipv6.org/ for information (which should be reasonably up to date). You can also ask on users@ipv6.org (subscribe via majordomo@ipv6.org). Perry From deering@cisco.com Thu Jul 1 16:08:26 1999 From: deering@cisco.com (Steve Deering) Date: Thu, 1 Jul 1999 08:08:26 -0700 Subject: pTLAs missing in action In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101451545D@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101451545D@RED-MSG-50> Message-ID: At 11:30 AM -0700 6/30/99, Richard Draves wrote: >OK, some progress... now the list of pTLAs for which I have no addresses to >ping is > > 3ffe:800::/24 (ISI-LAP) > 3ffe:d00::/24 (ANSNET) > 3ffe:1500::/24 (UO) > 3ffe:1600::/24 (NUS-IRDU) > 3ffe:1700::/24 (MREN) > 3ffe:1f00::/24 (NETCOM-UK) > 3ffe:2700::/24 (ERA) > 3ffe:2d00::/24 (GRNET) > 3ffe:3500::/24 (REGIO-DE) > 3ffe:3700::/24 (ABILENE) > 3ffe:8010::/28 (ICM-PL) > 3ffe:8030::/28 (QTPVSIX) It would be very nice if, for every piece of topology identified by an address prefix, the border routers of that piece of topology would automatically assign to themselves an anycast address consisting of the relevant prefix followed by all zeros. The anycast address would be assigned to the interface(s) attached to the prefixed topology. This would allow you to ping a prefix and get an answer from the nearest border router of that prefix. This particular use of anycast addressing does not impose any additional load on routing outside the piece of topology (since it aggregates with all the other addresses for that piece of topology), and adds only one entry to the routing inside the piece of topology (for the zero-valued next-level-down prefix). Note that we already require this for the border routers of subnets (effectively, all routers), and I recall that the IPv6 address allocation policies that the regional registries are proposing/using requires this for border routers of sites. I suggest we require it for the border routers of all prefixes. Comments? Steve From richdr@microsoft.com Thu Jul 1 20:45:23 1999 From: richdr@microsoft.com (Richard Draves) Date: Thu, 1 Jul 1999 12:45:23 -0700 Subject: pTLAs missing in action Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515493@RED-MSG-50> > It would be very nice if, for every piece of topology identified by an > address prefix, the border routers of that piece of topology would > automatically assign to themselves an anycast address consisting of > the relevant prefix followed by all zeros. The anycast address would > be assigned to the interface(s) attached to the prefixed topology. > This would allow you to ping a prefix and get an answer from > the nearest > border router of that prefix. This particular use of anycast > addressing > does not impose any additional load on routing outside the piece of > topology (since it aggregates with all the other addresses for that > piece of topology), and adds only one entry to the routing inside the > piece of topology (for the zero-valued next-level-down prefix). Well this would certainly make my life easier right now. > Note that we already require this for the border routers of subnets > (effectively, all routers), and I recall that the IPv6 > address allocation > policies that the regional registries are proposing/using > requires this > for border routers of sites. I suggest we require it for the border > routers of all prefixes. Does anyone actually implement the subnet anycast addresses? I know I've been lax about it, and from the brief experiment I just tried it seems Cisco & Telebit routers also do not. Something for UNH to check... Rich From dancer@zeor.simegen.com Thu Jul 1 23:00:22 1999 From: dancer@zeor.simegen.com (Dancer) Date: Fri, 02 Jul 1999 08:00:22 +1000 Subject: v6 browser References: <2206.930839539@coconut.itojun.org> Message-ID: <377BE4F6.E0F92B39@zeor.simegen.com> itojun@iijlab.net wrote: > > >I have a small proxy that can access ipv4/ipv6 HTTP servers. It's > >getting a rewrite before release. (it's a hack of something else I did, > >so it's pretty ugly) > > If you are okay with proxy, we have patch for squid and apache > (which has proxy mode) at ftp://ftp.kame.net/pub/kame/misc/. > > itojun I noticed. The squid version's one of the old 1.1 versions, which aren't really supported anymore. Currently we're up to 2.2stable3. I'm in the development team and I've got a development snapshot of 2.3 that I'm working on converting so that v6 (protocol independent) support will be the default for the application. D From richdr@microsoft.com Tue Jul 6 22:47:54 1999 From: richdr@microsoft.com (Richard Draves) Date: Tue, 6 Jul 1999 14:47:54 -0700 Subject: pTLAs missing in action Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145154C4@RED-MSG-50> OK, more progress. Now there are only 5 pTLAs for which I have no information: 3FFE:0800::/24 (ISI-LAP) 3FFE:0D00::/24 (ANSNET) 3FFE:1500::/24 (UO) 3FFE:2700::/24 (ERA) 3FFE:3500::/24 (REGIO-DE) If you know of any active addresses within those pTLAs, or know that they are inactive pTLAs, please let me know. Thanks, Rich From richdr@microsoft.com Tue Jul 6 23:46:27 1999 From: richdr@microsoft.com (Richard Draves) Date: Tue, 6 Jul 1999 15:46:27 -0700 Subject: pTLAs missing in action Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145154C9@RED-MSG-50> > >Does anyone actually implement the subnet anycast addresses? > I know I've > >been lax about it, and from the brief experiment I just > tried it seems Cisco > >& Telebit routers also do not. > > My reply vanished somewhere in the cyberspace so I resend this. > > KAME can configure anycast address by using ifconfig, > and default > IPv6 initialization script (rc.net6) configures subnet > anycast address > for your subnet, on routers. I just implemented support for subnet anycast addresses in MSR IPv6 - they are configured automatically when a router has a subnet prefix on an interface. Rich From bmanning@ISI.EDU Wed Jul 7 00:41:06 1999 From: bmanning@ISI.EDU (Bill Manning) Date: Tue, 6 Jul 1999 16:41:06 -0700 (PDT) Subject: pTLAs missing in action In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D810145154C4@RED-MSG-50> from "Richard Draves" at Jul 06, 1999 02:47:54 PM Message-ID: <199907062341.QAA05548@gnat.isi.edu> > > OK, more progress. Now there are only 5 pTLAs for which I have no > information: > 3FFE:0800::/24 (ISI-LAP) > 3FFE:0D00::/24 (ANSNET) > 3FFE:1500::/24 (UO) > 3FFE:2700::/24 (ERA) > 3FFE:3500::/24 (REGIO-DE) > > If you know of any active addresses within those pTLAs, or know that they > are inactive pTLAs, please let me know. > > Thanks, > Rich While an interesting exercise, your "inactive" pTLAs are dependent on your IPv4 unicast reachability. 3FFE:800:0:C620:920B::0 ping 3FFE:800:0:C620:920B::0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3FFE:800:0:C620:920B::0, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms --bill From richdr@microsoft.com Wed Jul 7 01:29:55 1999 From: richdr@microsoft.com (Richard Draves) Date: Tue, 6 Jul 1999 17:29:55 -0700 Subject: pTLAs missing in action Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145154D0@RED-MSG-50> > While an interesting exercise, your "inactive" pTLAs are dependent on > your IPv4 unicast reachability. > > 3FFE:800:0:C620:920B::0 The 5 pTLAs were just those for which I know no v6 addresses to try pinging, and have not heard confirmation from the pTLA admin that the pTLA is offline. This is very different from a list of pTLAs unreachable by me, which would be much longer. Now that I have an address in 3ffe:800::/24 to add to my list, I'm down to 4 "missing" pTLAs. Thanks, Rich From ntle@vnn.vn Wed Jul 7 05:24:58 1999 From: ntle@vnn.vn (nguyen Thanh Le) Date: Wed, 7 Jul 1999 11:24:58 +0700 Subject: Transition from IPv4 to IPV6 References: Message-ID: <003301bec833$09ece540$8001a8c0@vnn.vn> I would like to introduce myself : My name is Le Thanh. I'm working at Investisement and Development Division of the biggest IPS in Vietnam. Currently, I work on an important pilot project named "Transition from IPv4 to IPV6" that allow us to transform smoothly our network backbone IPV4 verus IPV6. Our national network uses Bay Network Access Server, Cisco Routers, SUN stations and servers, ...etc. I'm very new to this mailling-list, so I have somes questions that I would like to receive the answers : - What is the first thing I have to do (ex : Change DNS, ..etc.) ?. - Which devices and servers elses we have to use for the compatibilities between IPV4 and IPV6. If you are interessing to these questions, I would like to send to you a Network Topology in Winword format. Could any one give me somes advises ?. Thank you very much and I'm looking toward to hearing from you soon. Le Nguyen. From peter@jazz-1.trumpet.com.au Wed Jul 7 11:09:12 1999 From: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Wed, 7 Jul 1999 20:09:12 +1000 (EST) Subject: No subject Message-ID: Just posted on the newsgroups. pardon the blatant advertising. From: peternews@trumpet.com.au (Peter R. Tattam) Newsgroups: trumpet.announce,alt.winsock.trumpet,comp.protocols.tcp-ip.ibmpc Subject: Trumpet Winsock 5.0 released Date: Wed, 7 Jul 1999 20:05:56 +1100 Now available for download ftp://ftp.trumpet.com/winsock/twsk50b.exe From our USA site ftp://ftp.trumpet.com.au/winsock/twsk50b.exe From our Aus site Like the Trumpet Winsock v 4.0, Trumpet Winsock v5.0 is a fully-featured 32-bit dialer for use with both Windows95/98 and Windows NT as well as having IPv6 capability. It can be used to dial into the Internet to connect to your local service provider and is a Winsock v1.1 compliant TCP/IP stack. You should be able to make IPv6 name lookups and reverse lookups, TCP and UDP connections on IPv6. Your application will need to be IPv6 aware to make connections, however this version also includes an IPv6 -> IPv4 translator that allows most IPv4 apps to work over IPv6. IPv6 is a replacement Internet Protocol that will enhance the ability to sustain the continuous growth of theInternet, solving the IP address space depletion dilemma and enhancing other properties that willeventually impact on the viability of the Internet. By the use of the IPv6 Addressing capability, rather than the existing IPv4 protocol, the limit on addresseshas been extended from a theoretical 4 billion to 340 trillion, trillion, trillion (3.4x10**38) Trumpet is rapidly becoming a market leader in IPv6 software for Win32 platforms, for example, our Fanfare Internet server is IPv6 capable. For more information, read the following URL. http://www.trumpet.com.au/ipv6.htm Important bug fixes include the installer problem with Win95/98 and it is now compatible with IE 4.0 Enjoy!!! 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 ksbn@kt.co.kr Wed Jul 7 11:21:45 1999 From: ksbn@kt.co.kr (ksb) Date: Wed, 07 Jul 1999 19:21:45 +0900 Subject: multicast tool Message-ID: <37832A39.9DA3F6C3@kt.co.kr> Dear members: I got a small IPv6 network based on Solaris7 hosts. I hope to experiment the IPv6 multicast on Solaris7 hosts(IPv6 prototype patch installed). But it's difficult to find proper software. Will you send me some information? Sincerely, -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- From richdr@microsoft.com Fri Jul 9 00:44:13 1999 From: richdr@microsoft.com (Richard Draves) Date: Thu, 8 Jul 1999 16:44:13 -0700 Subject: 6to4 status report Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101451553C@RED-MSG-50> Currently two ASes (MSR-REDMOND and CAIRN) are advertising the 2010::/16 prefix into the 6bone. There's actually just one 6to4 relay router - CAIRN has a static tunnel to me. For the 61 pTLAs in the 6bone, I have the following statistics: 3 Unknown - meaning no known v6 addresses, no response from pTLA administrator 6 Offline - meaning pTLA administrator confirms that the pTLA is inactive 16 Bad - meaning I've never succeeded in pinging the pTLA with a 6to4 source address 36 OK - meaning I've succeeded in pinging the pTLA at least once Note that my connectivity to the 36 "OK" pTLAs is often intermittent at best, but that's par for the 6bone :-). Rich From perry@piermont.com Fri Jul 9 21:48:50 1999 From: perry@piermont.com (Perry E. Metzger) Date: 09 Jul 1999 16:48:50 -0400 Subject: we need better "join the 6bone tools" Message-ID: <87g12xmtvx.fsf@jekyll.piermont.com> It has become apparent that we need some better tools for helping organizations trying to play with v6 find 6bone connectivity. The current method is basically "hunt through long lists and try to find someone sympathetic", which is going to break down if we start getting any real volume out. What I'd like to do is to get some web pages, hopefully dual-hosted at www.6bone.net and www.ipv6.org, that are broken down geographically and by "netspace location" (i.e. major backbone provider) that list organizations explicitly willing to give out tunnels in those physical/virtual locations. That way, you can locate the five or ten organizations to talk to quickly instead of hunting down five URLs and going through long lists. We really need various tunnel broker things eventually, but this should only take a volunteer a matter of hours to set up, and it will be done. An imperfect solution, but one that we could have up in days. I'll happily give anyone willing to maintain such a thing an account on www.ipv6.org so they can do the work. What do people think? Perry From lalartu@obscure.org Sun Jul 11 10:01:13 1999 From: lalartu@obscure.org (Shawn Ferry) Date: Sun, 11 Jul 1999 05:01:13 -0400 Subject: we need better "join the 6bone tools" In-Reply-To: <87g12xmtvx.fsf@jekyll.piermont.com>; from Perry E. Metzger on Fri, Jul 09, 1999 at 04:48:50PM -0400 References: <87g12xmtvx.fsf@jekyll.piermont.com> Message-ID: <19990711050112.A11474@tiamat.obscure.org> I agree with you there, I am currently in the process of trying to find someone to connect my site. It is getting a bit frustrating, just wating for someone to respond. I would be willing to keep up the pages, on an opt in basis, although I do not claim that they will be overly nice to look at(especially if it helps me get my own connectivity). Shawn Ferry Quoting Perry E. Metzger : > > It has become apparent that we need some better tools for helping > organizations trying to play with v6 find 6bone connectivity. The > current method is basically "hunt through long lists and try to find > someone sympathetic", which is going to break down if we start getting > any real volume out. > > What I'd like to do is to get some web pages, hopefully dual-hosted at > www.6bone.net and www.ipv6.org, that are broken down geographically > and by "netspace location" (i.e. major backbone provider) that list > organizations explicitly willing to give out tunnels in those > physical/virtual locations. That way, you can locate the five or ten > organizations to talk to quickly instead of hunting down five URLs and > going through long lists. > > We really need various tunnel broker things eventually, but this > should only take a volunteer a matter of hours to set up, and it will > be done. An imperfect solution, but one that we could have up in days. > > I'll happily give anyone willing to maintain such a thing an account > on www.ipv6.org so they can do the work. > > What do people think? > > Perry From dancer@zeor.simegen.com Sun Jul 11 15:07:35 1999 From: dancer@zeor.simegen.com (Dancer) Date: Mon, 12 Jul 1999 00:07:35 +1000 Subject: we need better "join the 6bone tools" References: <87g12xmtvx.fsf@jekyll.piermont.com> Message-ID: <3788A527.A9CA4C38@zeor.simegen.com> "Perry E. Metzger" wrote: > > It has become apparent that we need some better tools for helping > organizations trying to play with v6 find 6bone connectivity. The > current method is basically "hunt through long lists and try to find > someone sympathetic", which is going to break down if we start getting > any real volume out. Especially since the lists and info tend to age rapidly. Lancashire's pages (until a few days ago) hadn't been updated for months (the automatic process that munges them out of the registry must have broken down). I was lucky. Out in Australia, there wasn't a lot of choice, so the list was short, and Trumpet made the top of it, since Peter was generating mail traffic on the lists. > > What I'd like to do is to get some web pages, hopefully dual-hosted at > www.6bone.net and www.ipv6.org, that are broken down geographically > and by "netspace location" (i.e. major backbone provider) that list > organizations explicitly willing to give out tunnels in those > physical/virtual locations. That way, you can locate the five or ten > organizations to talk to quickly instead of hunting down five URLs and > going through long lists. > > We really need various tunnel broker things eventually, but this You mean as in a bunch of preallocated networks and tunnel connection points that could be handed out on a semi-automated basis? Or am I misinterpreting? > should only take a volunteer a matter of hours to set up, and it will > be done. An imperfect solution, but one that we could have up in days. > > I'll happily give anyone willing to maintain such a thing an account > on www.ipv6.org so they can do the work. Really good idea. Unable to help with the work, but the idea is great, and much needed. From richdr@microsoft.com Tue Jul 13 16:33:23 1999 From: richdr@microsoft.com (Richard Draves) Date: Tue, 13 Jul 1999 08:33:23 -0700 Subject: 3ffe:2a00::/24 routing loop? Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101451556E@RED-MSG-50> It looks like there's a routing loop in the 3ffe:2a00::/24 pTLA... see below. I'm running in the IETF terminal room. Thanks, Rich tracert6 -d 3ffe:dfe:fffe::9 Tracing route to 3ffe:dfe:fffe::9 over a maximum of 30 hops: 1 1 ms <1 ms <1 ms 3ffe:2a00:100:7031::1 2 3 ms 3 ms 3 ms 3ffe:2a00:100:7ffd::1 3 177 ms 177 ms 182 ms 3ffe:2a00:100:7ffc::2 4 183 ms 182 ms 181 ms 3ffe:2a00:100:7ffd::1 5 356 ms 355 ms 349 ms 3ffe:2a00:100:7ffc::2 6 358 ms 349 ms 355 ms 3ffe:2a00:100:7ffd::1 7 542 ms 544 ms ^C From richdr@microsoft.com Tue Jul 13 16:54:10 1999 From: richdr@microsoft.com (Richard Draves) Date: Tue, 13 Jul 1999 08:54:10 -0700 Subject: 3ffe:2a00::/24 routing loop? Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515574@RED-MSG-50> Well, there's strangeness afoot. A couple minutes after I sent the below message, the routing loop fixed itself. Then a few minutes later it broke again, but in a different pTLA: Now the loop is: tracert6 -d 3ffe:dfe:fffe::9 Tracing route to 3ffe:dfe:fffe::9 over a maximum of 30 hops: 1 1 ms <1 ms 1 ms 3ffe:2a00:100:7031::1 2 3 ms 3 ms 3 ms 3ffe:2a00:100:7ffd::1 3 20 ms 19 ms 23 ms 3ffe:200:1:b::1 4 82 ms 69 ms 69 ms 3ffe:1d00:2:4::1 5 75 ms 68 ms * 3ffe:200:1:2::2 6 105 ms 226 ms 163 ms 3ffe:1d00:2:4::1 7 199 ms 112 ms 122 ms 3ffe:200:1:2::2 8 167 ms 157 ms 188 ms 3ffe:1d00:2:4::1 9 171 ms 187 ms 196 ms 3ffe:200:1:2::2 10 ^C > -----Original Message----- > From: Richard Draves > Sent: Tuesday, July 13, 1999 8:33 AM > To: 'jane@ifi.uio.no' > Cc: '6bone' > Subject: 3ffe:2a00::/24 routing loop? > > It looks like there's a routing loop in the 3ffe:2a00::/24 > pTLA... see below. > I'm running in the IETF terminal room. > > Thanks, > Rich > > tracert6 -d 3ffe:dfe:fffe::9 > > Tracing route to 3ffe:dfe:fffe::9 > over a maximum of 30 hops: > > 1 1 ms <1 ms <1 ms 3ffe:2a00:100:7031::1 > 2 3 ms 3 ms 3 ms 3ffe:2a00:100:7ffd::1 > 3 177 ms 177 ms 182 ms 3ffe:2a00:100:7ffc::2 > 4 183 ms 182 ms 181 ms 3ffe:2a00:100:7ffd::1 > 5 356 ms 355 ms 349 ms 3ffe:2a00:100:7ffc::2 > 6 358 ms 349 ms 355 ms 3ffe:2a00:100:7ffd::1 > 7 542 ms 544 ms ^C From ettikan@nttmsc.com.my Wed Jul 14 00:52:34 1999 From: ettikan@nttmsc.com.my (Ettikan Kandasamy) Date: Wed, 14 Jul 1999 08:52:34 +0900 Subject: How to join the v6 groups Message-ID: Hello I'm interested in IPv6 testing and development activities. Currently I have a 2 PC's running IPv6 ( on FreeBSD with Kame). Could anyone tell me how could I connect ( besides - freenet6's tunnel broker ) to some other sides for testing ??? Thanks. ettikan From xavier@euro.net Wed Jul 14 07:07:31 1999 From: xavier@euro.net (Xavier) Date: Wed, 14 Jul 1999 08:07:31 +0200 (MET DST) Subject: IPv6 compliant applications? Message-ID: Hi, Where can I find an index of IPv6 compliant applications (or patches, updates, ...) for Solaris? Ex: Apache, lynx, wuftpd, ... Regards, Xavier -- Xavier Mertens, * * EuroNet Internet Network Operation Center * * a subsidiary of France Telecom XM3-RIPE * From Trond.Skjesol@uninett.no Wed Jul 14 08:46:56 1999 From: Trond.Skjesol@uninett.no (Trond Skjesol) Date: Wed, 14 Jul 1999 09:46:56 +0200 Subject: 3ffe:2a00::/24 routing loop? In-Reply-To: Your message of "Tue, 13 Jul 1999 08:54:10 PDT." <4D0A23B3F74DD111ACCD00805F31D81014515574@RED-MSG-50> Message-ID: <199907140746.JAA22760@tyholt.uninett.no> During this period we had some routing problems with the routing into US, the problem was somewhere at Teleglobe. I guess thats why the 6bone routing also failed. -Trond staff@nordu.net said: > Ticket Number : NORDUnet/19990713-00 Ticket Status : OPEN, UPDATED > Ticket Type : Unscheduled Ticket Source : KTHNOC > Site/Line : Most US sites unreachable > Ticket Scope : Routing Ticket Priority : Normal > Ticket Owner : KTHNOC Ticket Issuer : nnc@sunet.se > Problem Fixer : N/A Time to Fix : N/A > Ticket Opened : 19990713 19:13 UTC Problem Starts : 19990713 17:20 UTC ? > Closed : Ended : 19990713 20:20 UTC ? > Problem Description: > Loss of routing to most US. > Affected: > All NORDUNet traffic to/from US > Action: > Contated Teleglobe (by fax!) > Fix: > Teleglobe (Mia) confirmed reception of fax at 19.20, > handing the case to techn. staff. > ----- > 990713 20:50 Update by nnc@sunet.se > At 20:35 (UTC) Teleglobe called and told allocation > of Ticken-# 81844. Problem escalated to 1:st level > support for investignation. > GÅ told them that the problem is currently not there. > (since some 10-15 min.) They will continue to > investignate, and inform by E-Mail. > Now the loop is: > > tracert6 -d 3ffe:dfe:fffe::9 > > Tracing route to 3ffe:dfe:fffe::9 > over a maximum of 30 hops: > > 1 1 ms <1 ms 1 ms 3ffe:2a00:100:7031::1 > 2 3 ms 3 ms 3 ms 3ffe:2a00:100:7ffd::1 > 3 20 ms 19 ms 23 ms 3ffe:200:1:b::1 > 4 82 ms 69 ms 69 ms 3ffe:1d00:2:4::1 > 5 75 ms 68 ms * 3ffe:200:1:2::2 > 6 105 ms 226 ms 163 ms 3ffe:1d00:2:4::1 > 7 199 ms 112 ms 122 ms 3ffe:200:1:2::2 > 8 167 ms 157 ms 188 ms 3ffe:1d00:2:4::1 > 9 171 ms 187 ms 196 ms 3ffe:200:1:2::2 > 10 ^C > > > -----Original Message----- > > From: Richard Draves > > Sent: Tuesday, July 13, 1999 8:33 AM > > To: 'jane@ifi.uio.no' > > Cc: '6bone' > > Subject: 3ffe:2a00::/24 routing loop? > > > > It looks like there's a routing loop in the 3ffe:2a00::/24 > > pTLA... see below. > > I'm running in the IETF terminal room. > > > > Thanks, > > Rich > > > > tracert6 -d 3ffe:dfe:fffe::9 > > > > Tracing route to 3ffe:dfe:fffe::9 > > over a maximum of 30 hops: > > > > 1 1 ms <1 ms <1 ms 3ffe:2a00:100:7031::1 > > 2 3 ms 3 ms 3 ms 3ffe:2a00:100:7ffd::1 > > 3 177 ms 177 ms 182 ms 3ffe:2a00:100:7ffc::2 > > 4 183 ms 182 ms 181 ms 3ffe:2a00:100:7ffd::1 > > 5 356 ms 355 ms 349 ms 3ffe:2a00:100:7ffc::2 > > 6 358 ms 349 ms 355 ms 3ffe:2a00:100:7ffd::1 > > 7 542 ms 544 ms ^C From richdr@microsoft.com Wed Jul 14 12:35:20 1999 From: richdr@microsoft.com (Richard Draves) Date: Wed, 14 Jul 1999 04:35:20 -0700 Subject: 3ffe:2a00::/24 routing loop? Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515580@RED-MSG-50> Well, it's fixed at this moment: tracert6 -d 3ffe:dfe:fffe::9 Tracing route to 3ffe:dfe:fffe::9 over a maximum of 30 hops: 1 7 ms 1 ms 1 ms 3ffe:2a00:100:7031::1 2 3 ms 3 ms 3 ms 3ffe:2a00:100:7ffd::1 3 21 ms 19 ms 19 ms 3ffe:200:1:b::1 4 69 ms 60 ms 68 ms 3ffe:1100:0:c06::1 5 200 ms 199 ms 204 ms 3ffe:1100:0:f004::2 6 197 ms 203 ms 199 ms 3ffe:1280:1001:1::1 7 419 ms 417 ms 405 ms 3ffe:1001:1:f001::1 8 971 ms 623 ms 980 ms 3ffe:dfe:fffe::9 Trace complete. Thanks, Rich From perry@piermont.com Wed Jul 14 14:58:23 1999 From: perry@piermont.com (Perry E. Metzger) Date: 14 Jul 1999 09:58:23 -0400 Subject: IPv6 compliant applications? In-Reply-To: Xavier's message of "Wed, 14 Jul 1999 08:07:31 +0200 (MET DST)" References: Message-ID: <87vhbn72ps.fsf@jekyll.piermont.com> Xavier writes: > Where can I find an index of IPv6 compliant applications (or patches, > updates, ...) for Solaris? > > Ex: Apache, lynx, wuftpd, ... We have the beginnings of such a thing on www.ipv6.org, but it is really only a beginning. We could use help in improving it... Perry From Alain.Durand@imag.fr Wed Jul 14 20:25:41 1999 From: Alain.Durand@imag.fr (Alain Durand) Date: Wed, 14 Jul 1999 21:25:41 +0200 Subject: IPv6 addresses Message-ID: <4.2.0.56.19990714212237.00aab3c0@brahma.imag.fr> Just a minute ago, IANA announced they've done the delegation of blocks of IPv6 addresses to the registries. This is a major step forward. - Alain. From richdr@microsoft.com Wed Jul 14 21:17:52 1999 From: richdr@microsoft.com (Richard Draves) Date: Wed, 14 Jul 1999 13:17:52 -0700 Subject: routing loops redux Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515596@RED-MSG-50> This is in the terminal room again, using 3ffe:2a00:100:7031:280:c7ff:fe03:79a1 as my source address. tracert6 -d 3FFE:1500::FFFE:0:0:2 Tracing route to 3ffe:1500::fffe:0:0:2 over a maximum of 30 hops: 1 1 ms <1 ms <1 ms 3ffe:2a00:100:7031::1 2 3 ms 4 ms 3 ms 3ffe:2a00:100:7ffd::1 3 20 ms 19 ms 19 ms 3ffe:200:1:b::1 4 160 ms 173 ms * 3ffe:1d00:2:4::1 5 156 ms 126 ms 224 ms 3ffe:200:1:2::2 6 294 ms 352 ms 341 ms 3ffe:1d00:2:4::1 7 317 ms 309 ms 361 ms 3ffe:200:1:2::2 8 508 ms 455 ms 466 ms 3ffe:1d00:2:4::1 9 * * 446 ms 3ffe:200:1:2::2 10 511 ms 576 ms 598 ms 3ffe:1d00:2:4::1 11 455 ms 373 ms 772 ms 3ffe:200:1:2::2 12 * 508 ms * 3ffe:1d00:2:4::1 13 357 ms 310 ms 439 ms 3ffe:200:1:2::2 14 644 ms 670 ms 675 ms 3ffe:1d00:2:4::1 15 735 ms 578 ms 570 ms 3ffe:200:1:2::2 16 * 339 ms 1576 ms 3ffe:1d00:2:4::1 17 812 ms * * 3ffe:200:1:2::2 18 1145 ms * ^C tracert6 -d 3ffe:dfe:fffe::9 Tracing route to 3ffe:dfe:fffe::9 over a maximum of 30 hops: 1 1 ms <1 ms <1 ms 3ffe:2a00:100:7031::1 2 3 ms 3 ms 3 ms 3ffe:2a00:100:7ffd::1 3 20 ms 19 ms 19 ms 3ffe:200:1:b::1 4 59 ms 59 ms 60 ms 3ffe:1100:0:c06::1 5 198 ms 195 ms 197 ms 3ffe:1100:0:f004::2 6 289 ms 288 ms 289 ms 3ffe:1100:0:cc07::2 7 402 ms 389 ms 395 ms 3ffe:28ff:ffff:4:: 8 * * * Request timed out. 9 * * * Request timed out. 10 330 ms 331 ms 333 ms 3ffe:600:8000::19 11 345 ms 363 ms 345 ms 3ffe:1100:0:c06::1 12 482 ms 479 ms 627 ms 3ffe:1100:0:f004::2 13 694 ms 572 ms 576 ms 3ffe:1100:0:cc07::2 ^C From cdavila@metlife.com Wed Jul 14 22:29:19 1999 From: cdavila@metlife.com (Carlos Davila) Date: Wed, 14 Jul 1999 17:29:19 -0400 Subject: IPv6 compliant applications? Message-ID: <852567AE.00758972.00@metlife.com> I would like to know too. Carlos ---------------------- Forwarded by Carlos Davila/Bsg/MetLife/US on 07/14/99 05:29 PM --------------------------- "Xavier" on 07/14/99 02:07:31 AM To: 6bone@ISI.EDU cc: (bcc: Carlos Davila/Bsg/MetLife/US) Subject: IPv6 compliant applications? Hi, Where can I find an index of IPv6 compliant applications (or patches, updates, ...) for Solaris? Ex: Apache, lynx, wuftpd, ... Regards, Xavier -- Xavier Mertens, * * EuroNet Internet Network Operation Center * * a subsidiary of France Telecom XM3-RIPE * From perry@piermont.com Wed Jul 14 23:04:36 1999 From: perry@piermont.com (Perry E. Metzger) Date: 14 Jul 1999 18:04:36 -0400 Subject: ["IANA" ] Delegation of IPv6 address space Message-ID: <87lncievm3.fsf@jekyll.piermont.com> --Multipart_Wed_Jul_14_18:04:09_1999-1 Content-Type: text/plain; charset=US-ASCII And so it begins, at long last. Perry [Please don't crosspost replies to this.] --Multipart_Wed_Jul_14_18:04:09_1999-1 Content-Type: message/rfc822 From: "IANA" To: Subject: Delegation of IPv6 address space Date: Wed, 14 Jul 1999 12:32:07 -0700 Message-ID: <004801bece2f$8fe532e0$22a00980@icann1.isi.edu> Internet Community, After much discussion concerning the policy guidelines for the deployment of IPv6 addresses, in addition to the years of technical development done throughout the Internet community, the IANA has delegated the initial IPv6 address space to the regional registries in order to begin immediate worldwide deployment of IPv6 addresses. We would like to thank the current Regional Internet Registries (RIR) for their invaluable work in the construction of the policy guidelines, which seem to have general consensus from the Internet community. We would also like to thank the efforts of the IETF community and the support of the IAB in making this effort a reality. If you have further questions concerning this issue, please contact your RIR, or you may also contact the IANA at iana@iana.org. The policy guidelines can be found online at one of the Regional Internet Registries: http://www.apnic.net http://www.arin.net http://www.ripe.net This is an historic moment in the continued development of the Internet. Thank you for your valuable support and participation in the Internet community. Josh Elliott On Behalf of the IANA Staff --Multipart_Wed_Jul_14_18:04:09_1999-1-- From dancer@zeor.simegen.com Thu Jul 15 00:32:35 1999 From: dancer@zeor.simegen.com (Dancer) Date: Thu, 15 Jul 1999 09:32:35 +1000 Subject: IPv6 addresses References: <4.2.0.56.19990714212237.00aab3c0@brahma.imag.fr> Message-ID: <378D1E13.3E93C6BA@zeor.simegen.com> Alain Durand wrote: > > Just a minute ago, IANA announced they've done the delegation of > blocks of IPv6 addresses to the registries. > > This is a major step forward. > > - Alain. I am already trying to raise info from my regional IR. D From =?iso-8859-1?Q?Fernando_Mendon=E7a?= Thu Jul 15 01:00:48 1999 From: =?iso-8859-1?Q?Fernando_Mendon=E7a?= (=?iso-8859-1?Q?Fernando_Mendon=E7a?=) Date: Wed, 14 Jul 1999 21:00:48 -0300 Subject: IPv6 addresses References: <4.2.0.56.19990714212237.00aab3c0@brahma.imag.fr> Message-ID: <001501bece55$18baf440$7a81f4c8@fernando> Por favor, Me excluam desta lista. É um endereço comercial. Valeu !!!! Abraços, Fernando From sgunderson@bigfoot.com Thu Jul 15 07:51:31 1999 From: sgunderson@bigfoot.com (Steinar H. Gunderson) Date: Thu, 15 Jul 1999 08:51:31 +0200 Subject: IPv6 compliant applications? In-Reply-To: <852567AE.00758972.00@metlife.com> Message-ID: <4.1.19990715084958.0093aae0@uio-pop.uio.no> At 17:29 14.07.99 -0400, Carlos Davila wrote: >I would like to know too. ATM, it isn't so easy to _make_ IPv6 compliant programs... At least for Linux, there are at least two different libraries available, and lots of other hassle. It could be interesting, though... Being among the first here would be an advantage :-) Any links to programming information? (I remember seing this in a FAQ once, but it wasn't very helpful.) /* Steinar */ From fink@es.net Thu Jul 15 09:50:23 1999 From: fink@es.net (Bob Fink) Date: Thu, 15 Jul 1999 01:50:23 -0700 Subject: 6TAP router operational Message-ID: <4.1.19990715012922.00c126e0@imap2.es.net> During the 5 weeks I was on vacation, ESnet staff installed and configured the 6TAP router at the StarTAP in Chicago. During this process, the ESnet folk decided that it would be most appropriate to not have the 6TAP routing domain be part of ESnet's routing domain. Thus I agreed to assign a separate pTLA (this by phone as I was out of email contact). I did not feel that this would be an issue for the 6bone community as the 6TAP represents a public, no cost, native interconnect and transit domain for IPv6 networks. The 6TAP pTLA assigned is: 3FFE:3900::0/24 In addition, ESnet assigned an AS number to the 6TAP: AS3425 I would like to thank the ESnet folk for moving ahead aggressively on this phase of the 6TAP project. Native IPv6 interconnect and transit is an important next phase of early production IPv6 deployment. CANARIE, ESnet's partner on the 6TAP project, will be moving ahead in coming months in getting an IPv6 Route Server up at the 6TAP. In addition, an effort is now underway to provide a native 2 mbps IPv6 path between the 6TAP in Chicago and the Amsterdam IPv6 Exchange. More info on the 6TAP and related projects will follow as they happen. Thanks, Bob --- Bob will be on travel from June 9 until the Oslo IETF meeting (July 11-16), and will not be responsive to email until July 21. Please direct 6bone & ngtrans questions to Alain Durand . From fink@es.net Thu Jul 15 11:28:49 1999 From: fink@es.net (Bob Fink) Date: Thu, 15 Jul 1999 03:28:49 -0700 Subject: pTLA request for APAN-KR In-Reply-To: <19990628201721.A47456@cosmos.kaist.ac.kr> Message-ID: <4.1.19990715032601.00bd4760@imap2.es.net> 6bone Folk, Per the request from Woohyong Choi (below), I'm opening a two week window for the review of a pTLA for APAN-KR. I will close this on 30 July 99. Note that this will be a /28 pTLA assignment. Thanks, Bob === At 08:17 PM 6/28/99 +0900, Woohyong Choi wrote: >Hi, > >This is a pTLA request for APAN-KR (Asia Pacific Advanced >Network - Korea). APAN-KR is a domestic network within >Korea established to provide high performance connectivity >among its R&E member institutions and to other networks >connected to APAN. > >http://noc.kr.apan.net/ > >IPv6 deployment is one of the projects within APAN-KR. >We currently have four participants which we expect to >glow to include many of APAN-KR member institutions. > >Initial members are > > KAIST (Korea Advanced Institute of Science and Technology) > KT (Korea Telecom Research Labs) > SNU (Seoul National University) > ETRI (Electronics Technology Research Institute) > >We have ATM PVC based native v6 links and tunnel based >(for those who don't have atm interface in their routers) >links among these institutions. > >We have an ATM PVC link to WIDE through APAN ATM >infrastructure (peering with BGP4+), and in the process >of establishing another ATM PVC to 6TAP through >APAN and TransPAC to participate in 6REN activities. > >Currently we're using a block delegated from WIDE pTLA. >We hope to get allocated a new pTLA for independent routing >as we are preparing a direct link to 6TAP. > >We understand the routing practices documented in RFC2546 >and have been following the rules during the past. > >We also believe that we meet the requirements listed >in Section 7 of the document. -end --- Bob will be on travel from June 9 until the Oslo IETF meeting (July 11-16), and will not be responsive to email until July 21. Please direct 6bone & ngtrans questions to Alain Durand . From bound@zk3.dec.com Fri Jul 16 01:04:57 1999 From: bound@zk3.dec.com (Jim Bound) Date: Thu, 15 Jul 1999 20:04:57 -0400 Subject: IPv6 compliant applications? In-Reply-To: Your message of "Wed, 14 Jul 1999 17:29:19 EDT." <852567AE.00758972.00@metlife.com> Message-ID: <199907160004.UAA0000019577@quarry.zk3.dec.com> >I would like to know too. >Where can I find an index of IPv6 compliant applications (or patches, >updates, ...) for Solaris? >Ex: Apache, lynx, wuftpd, ... Do you mean IPv6 "ported" or "aware" applications. There are no tests to compliancyy at this point? /jim From xavier@euro.net Fri Jul 16 05:51:12 1999 From: xavier@euro.net (Xavier) Date: Fri, 16 Jul 1999 06:51:12 +0200 (MET DST) Subject: IPv6 compliant applications? In-Reply-To: <25925.931934120@coconut.itojun.org> Message-ID: On Wed, 14 Jul 1999 itojun@iijlab.net wrote: > >Where can I find an index of IPv6 compliant applications (or patches, > >updates, ...) for Solaris? > >Ex: Apache, lynx, wuftpd, ... > > The best starting point is www.ipv6.org. My personal collection is in > ftp://ftp.kame.net/pub/kame/misc/. (the server is down this week so > please use the mirror. mirrors are listed in > ftp://powercut.kame.net/README or ftp://ftp.kame.net/README) Well, very nice patches source! I tried to patch lynx 2.8.1 on Solaris but I can't get a working lynx. Does somebody has an binary available? Xavier -- Xavier Mertens, * * EuroNet Internet Network Operation Center * * a subsidiary of France Telecom XM3-RIPE * From bruce.campbell@apnic.net Fri Jul 16 07:21:46 1999 From: bruce.campbell@apnic.net (Bruce Campbell) Date: Fri, 16 Jul 1999 16:21:46 +1000 (EST) Subject: we need better "join the 6bone tools" In-Reply-To: <87g12xmtvx.fsf@jekyll.piermont.com> Message-ID: On 9 Jul 1999, Perry E. Metzger wrote: (first time I replied to this it wasn't back to the list) perry> It has become apparent that we need some better tools for helping perry> organizations trying to play with v6 find 6bone connectivity. The APNIC (well, myself) currently maintains a list of basic information about various countries beneath http://www.apnic.net/maps/ . As part of this, I've taken the liberty of adding[1] a list of 6bone sites in each of APNIC's countries[2] to the above url. Regards, -- Bruce Campbell +61-7-3367-0490 Systems Administrator (#2) Regional Internet Registry Asia Pacific Network Information Centre For the Asia Pacific Region [1] Currently in the middle thereof. [2] AF,AS,AU,BD,BN,IO,BN,KH,CN,CX,CC,KM,CK,TP,FJ,PF,TF,GU,HK,IN,ID,JP,KI, KP,KR,LA,MO,MG,MY,MV,MH,MU,YT,FM,MN,MM,NR,NP,NC,NZ,NU,NF,MP,PK,PW,PG, PH,PN,RE,WS,SC,SG,SB,LK,TW,TH,TK,TO,TV,VU,VN and WF From isabelle.labbe@crc.ca Fri Jul 16 15:54:34 1999 From: isabelle.labbe@crc.ca (Isabelle Labbe) Date: Fri, 16 Jul 1999 10:54:34 -0400 Subject: IPv6 multicast on the 6bone Message-ID: <378F47AA.4D63453B@crc.ca> I would like to find out more about the current state of IPv6 multicast routing on the 6bone? My understanding is that very little implementations of IPv6 multicast routing protocols (e.g. PIMv6) exist. Our site connection to the 6bone is done through a Cisco IPv6 router. Cisco has currently no provision for IPv6 multicast routing. If I wish to test an IPv6 multicast application on the 6bone, is it possible at all through tunneling? Are there any package such as mrouted (used on the mbone) that has been ported to IPv6? What are the current solutions to forward IPv6 multicast on the 6bone? Isabelle Labbe -- Isabelle Labbe isabelle.labbe@crc.ca Communications Research Centre http://www.crc.ca 3701 Carling Av. P.O.Box 11490 Stn. H, Ottawa, ON CANADA K2H 8S2 phone(office): (613) 990-8777 Fax : (613) 998-9648 From Francis.Dupont@inria.fr Sat Jul 17 14:07:11 1999 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Sat, 17 Jul 1999 15:07:11 +0200 Subject: IPv6 multicast on the 6bone In-Reply-To: Your message of Fri, 16 Jul 1999 10:54:34 EDT. <378F47AA.4D63453B@crc.ca> Message-ID: <199907171307.PAA08836@givry.inria.fr> In your previous mail you wrote: I would like to find out more about the current state of IPv6 multicast routing on the 6bone? => there is no IPv6 multicast routing on the 6bone because of the lack of it on Cisco routers... My understanding is that very little implementations of IPv6 multicast routing protocols (e.g. PIMv6) exist. => We ("INRIA") have a PIMv6 DM which seems to be now uptodate and fixed (even a little tested :-). I know there are other PIMv6, even some partial Sparse-Mode (KAME, Telebit DK, ...). Our site connection to the 6bone is done through a Cisco IPv6 router. Cisco has currently no provision for IPv6 multicast routing. => this is the reason why IPv6 multicast routing is not used. If I wish to test an IPv6 multicast application on the 6bone, is it possible at all through tunneling? => DVMRP has no IPv6 reason and tunnels defeat RPF checks then this is not a really usable solution... Are there any package such as mrouted (used on the mbone) that has been ported to IPv6? What are the current solutions to forward IPv6 multicast on the 6bone? => avoid Cisco routers or wait for IPv6 multicast in IOS... (:-) I believe IPv6 multicast will not be used on large scale before several months. Regards Francis.Dupont@inria.fr From Latif.LADID@village.uunet.lu Mon Jul 19 12:24:16 1999 From: Latif.LADID@village.uunet.lu (Latif LADID ( latif.ladid@tbit.dk)) Date: Mon, 19 Jul 1999 13:24:16 +0200 Subject: Global IPv6 Summit - Paris - Agenda on email Message-ID: <01BED1EA.02B632C0.Latif.LADID@village.uunet.lu> Please find attached the draft agenda of the first IPv6 Forum Summit under the double theme of: - IPv6 Around the World and - Call for IPv6 Growth - Date : October 6-8, 99 - Place: Paris - Organisor: Patrick Cocquet at Thomson CSF- Detexis We would like to call for more speakers on IPv6-based solutions for the open slots. Please, address your interest directly to Patrick. A logistics message will follow regarding hotel, registration, sponsorship and exhibition facilities. Thanks for your active participating making IPv6 happen around the world! Regards, Latif Patrick Global IPv6 Summit Jouy-en-Josas near PARIS (France), October 6-8, 99 Advanced Program ( Call For Speakers ) Day 1 October 6 0830 - 0930 Registration 0930 Opening Plenary 0930 - 0950 Welcome session Thomson-CSF welcome,(TBA) IPv6 Forum Chairperson welcome, Latif Ladid, Telebit 0950 - 1100 New Internet - Key-Note Speeches - French Ministry's Vision, (TBA) - Christian HUITEMA's Vision - Vint CERF's Vision Coffee 1100 - 1130 1130 - 1245 IPv6 Clearly Explained Chairperson : Patrick Cocquet, Thomson-CSF Detexis - Why do we need IPv6, (G6 member, TBA) - Standardisation status, (G6 member, TBA) Questions & Answers Lunch 1245 - 1415 1415 - 1600 IPv6 Succes Stories Around the World Chairperson : TBA - Norway, Haakon Bryhni, Thomson-CSF Norcom - Japan, Jun Murai, Wide Japan (TBC) - France, TBA, France Telecom CNET - Canada, Marc Blanchet, Viagenie inc. Questions & Answers Coffee 1600 - 1615 1615 - 1745 IPv6 FORUM Chairperson : TBA Goals and organisation, Latif Ladid IPv6 Forum Promotion group, WG leaders IPv6 Forum Deployment group, Jim Bound Questions & Answers Close 1745 1900 Jazz Night Dinner Day 2 October 7 0830 - 0900 Registration 0900 New Internet deployment (Stream 1) Learn about the applications that will help sell IPv6 Stream 1 0900 - 1030 Calling for IPv6 Growth Chairperson : TBA -Quality of Service for the new IP Networks, Serge Fdida, LIP6, @IRS Project -IPv6 Multicast, the future challenge, (TBA) -IPSEC, the IPv6 solution, TBA, Thomson-CSF Detexis Questions & Answers Coffee 1030 - 1100 Stream 1 1100 - 1230 Calling for IPv6 Growth contd. Chairperson : TBA -IPv6 for future wireless networks, (TBA) -IPv6 for Telephony Services, (TBA) -IPv6 for future ISP Services, (TBA) Questions & Answers Lunch 1230 - 1400 Stream 1 1400 - 1530 Calling for IPv6 Growth contd. Chairperson : TBA -IPv6 in the sky, Gilles Gawinowsky, Eurocontrol, COIAS Project -IPv6 in military systems, (TBA) -IPv6 for professional applications: (TBA) Questions & Answers Coffee 1530 - 1600 1600 - 1700 Plenary Information on IPv6 Forum Information Points manned by relevant experts will be available for delegates to come and discuss IPv6 related issues. These will include :- -Forum Membership and Constitution Latif Ladid, Telebit -IPv6 Projects Patrick Cocquet, Thomson-CSF Detexis -Deployment Issues Jim Bound, -Promotion Issues TBA -Education and Awareness Program TBA -Standards issues TBA 1700 - 1745 Closing Plenary Chairperson: IPv6 Forum Chairperson - Latif Ladid, Telebit Round table with speakers and Forum working groups leaders Close 1745 1900 Paris by Night Dinner on a Ship on the Seine Day 2 October 7 IPv6 Forum Members Only (stream 2) 0900 IPv6 Promotion / Deployment Projects Working Sessions for Forum Members and Observers 0900 - 1030 IPv6 Promotion Groups and IPv6 Deployment Groups working in parallel Coffee 1030 - 1100 1100 - 1230 IPv6 Promotion Groups and IPv6 Deployment Groups working in parallel Lunch 1230 - 1400 1400 - 1545 IPv6 Promotion Groups and IPv6 Deployment Groups Debriefing Session Day 3 October 8 0830 - 0900 Registration 0900 IPv6 Forum Members Plenary (Stream 2) Chairperson: IPv6 Forum Chairperson - Latif Ladid, Telebit 0900 - 1030 Presentation of Results of IPv6 Promotion and IPv6 Deployment Groups Coffee 1030 - 1100 1100 - 1230 Presentation of Results of IPv6 Promotion and Deployment Groups - Results of voting on board - IPv6 Success Story / Applications Challenge Competition results - Closing remarks and thanks Lunch 1230 - 1400 Close 1400 R, /Latif From haberman@raleigh.ibm.com Mon Jul 19 13:17:29 1999 From: haberman@raleigh.ibm.com (Brian Haberman) Date: Mon, 19 Jul 1999 08:17:29 -0400 Subject: IPv6 multicast on the 6bone References: <378F47AA.4D63453B@crc.ca> Message-ID: <37931759.532D5905@raleigh.ibm.com> Isabelle, There are only a few code bases that have any IPv6 multicast support as Francis pointed out. In addition, IBM and Lixia Zhang's lab at UCLA have implementations of PIM-DM for IPv6. Microsoft has support for MLD for workstations. So your best bet right now is to try and work with one of those code bases. One of the work items that came out of this IETF is to bolster the work going on with multicast and IPv6. Hopefully, I will have additional news in the coming weeks about this effort. Brian Haberman Isabelle Labbe wrote: > > I would like to find out more about the current state of IPv6 multicast > routing on the 6bone? My understanding is that very little > implementations of IPv6 multicast routing protocols (e.g. PIMv6) exist. > Our site connection to the 6bone is done through a Cisco IPv6 router. > Cisco has currently no provision for IPv6 multicast routing. If I wish > to test an IPv6 multicast application on the 6bone, is it possible at > all through tunneling? Are there any package such as mrouted (used on > the mbone) that has been ported to IPv6? What are the current solutions > to forward IPv6 multicast on the 6bone? > -- *----------------------------------- ----------------------------* | Brian K. Haberman / / | | Remote Access Products \ \ A simple man, a simple | | IBM Research Triangle Park, NC / / plan. The world's too | | Internal Phone : 8-444-2673 \ \ big to understand. | | External Phone : (919) 254-2673 / / -- J. Buffett | | email : haberman@raleigh.ibm.com \ \ | *----------------------------------- ----------------------------* From masaki@merit.edu Mon Jul 19 18:05:26 1999 From: masaki@merit.edu (Masaki Hirabaru) Date: Mon, 19 Jul 1999 13:05:26 -0400 Subject: 07/01/99 6Bone Routing Report In-Reply-To: <19990719104152B.masaki@merit.edu> References: <19990704095603M.masaki@merit.edu> <19990719104152B.masaki@merit.edu> 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 rrockell@sprint.net Tue Jul 20 03:45:29 1999 From: rrockell@sprint.net (Robert Rockell) Date: Mon, 19 Jul 1999 22:45:29 -0400 (EDT) Subject: Bad routes update Message-ID: After tearing down my inbound filter to only ONE peer of all of my pTLA peers, I see the following bad routes (as path withheld to protect poor non-filtering transit party that I used :) ) block Most downstream AS (not full path) ----------------- ---------------------------------- 3FFE:400:1C0::0/48 8319 3FFE:900:1::0/48 1312 3FFE:900:2::0/48 3899 3FFE:902::0/32 8664 3FFE:F00:2::0/48 11261 3FFE:1108:40A::0/48 5539 3FFE:1108:1400::0/40 704 3FFE:2024:1::0/48 1205 3FFE:202A:1::0/64 1836 3FFE:2401::0/32 2118 3FFE:2610:2::0/48 8432 3FFE:2610:5::0/48 5469 3FFE:2620::0/32 1741 3FFE:2802::0/32 1312 3FFE:2900:5::0/48 1312 3FFE:2900:FFE1::0/48 4768 3FFE:2D00:2::0/48 3323 3FFE:2D00:3::0/48 8643 3FFE::0/16 2497 (prepended) While this is a small list when considering every member of the 6bone, this will obviously not scale should content on the 6bone become important. Note: not all bad prefixes are leaking from the PTLA who owns that prefix. For instance, the 3ffe:2900 prefix is coming from a customer of 3ffe:2900::/24 who is multihomed, but their other upstream is allowing this prefix to be advertised. This is the case for many of them, BUT NOT ALL. PTLA's: Please fix the easy ones, and pressure other pTLA's to fix the ones that are out of your hands. 3ffe::/16 .... enough said. Please have this removed. You are offically acting as default route (effectively) to 6bone. We appreciate it, but please refrain. A couple suggestions to people who are concerned about fixing this (everyone should be). Rob's diatribe on how to stop this from happenning. -------------------------------------------------- I. If you redistribute static/connected routes into bgp 1.tag [static connected] routes with a community, and filter on that community at your edges -or- 2.try to aggregate via an access-list Examples: --------- I apologize for the cisco-centric configuration suggestions. Feel free to port them to your bgp speaker and post them to the list. 1. ipv access-list aggreagte permit any (0::0/0) route-map aggregate-today permit 10 match ipv address aggregate set community :123 router bgp redistribute static route-map no-statics-out then on your outbound filter: ipv community-list 1 deny :123 ipv community-list 1 permit .* route-map filter-out permit 10 match community 1 set metric (insert transitive attribute tweaks here) (note: the "match any and tag" technique works in v6 but not v4... aggregation model says that for no reason should you route other people's space, if you are a pTLA, unless it is a transit aggregate, and these SHOULD NOT be static) 2. (this one is harder, and may not be possible with the given implemtations of bgp4+ and access-lists that I have seen) ipv prefix-list aggregate deny le route-map aggregate-toady permit 10 match ipv prefix aggreagte set and apply it outbound. #1 is more scalable, at least in my opinion. it also allows for a more stable IBGP, especially since most people are running IBGP as their sole IGP (RIP only carries you so far before one gets angry). ================================================= II. If you are multi-homed: Filter Outbound, please. It is simple. ipv access-list firstprovider permit ::/ ipv access-list secondprovider permit ::/ Then simply route-map -out permit 10 match ipv address <[first second] provider> set attribute here Bob, et al, do we think there needs to be something more stringent in place for providers who are allowing transit stray prefixes from other providers to get injected into their IBGP and thus into EBGP (when I am multi-homed, and send prefix A up provider B's pipe, and they accept it). When Ipv6 goes live, unless business is more good-willed than it is now, this is going to break things, and one pTLA may not have much motivation to fix the problem (unless flames on the 6bone mailing lists really hurt). Anyway, if you've gotten this far, thanks for reading. Anyone who can program their way out of a box, perhaps an expect script to pull this stuff out and publish a report once a week would be nice. However, if someone is going to knock down their filters temporarily to see the nastiness in the 6bone, they have to make sure their customers and peers do not see if for that time period. 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 cmetz@inner.net Tue Jul 20 05:37:25 1999 From: cmetz@inner.net (Craig Metz) Date: Tue, 20 Jul 1999 00:37:25 -0400 Subject: Private ASN space Message-ID: <199907200437.EAA26126@inner.net> Would someone kindly remind me what the reserved-for-private-use ASNs are? I need an ASN for use with my 6Bone routers (my == me, not NRL), and getting a "real" one is well outside my budget. Barring constructive objections, I'd like to claim one of the private ones for this purpose. -Craig From jabley@clear.co.nz Tue Jul 20 06:17:53 1999 From: jabley@clear.co.nz (Joe Abley) Date: Tue, 20 Jul 1999 17:17:53 +1200 Subject: Bad routes update In-Reply-To: ; from Robert Rockell on Mon, Jul 19, 1999 at 10:45:29PM -0400 References: Message-ID: <19990720171753.A60925@clear.co.nz> On Mon, Jul 19, 1999 at 10:45:29PM -0400, Robert Rockell wrote: > After tearing down my inbound filter to only ONE peer of all of my pTLA > peers, I see the following bad routes (as path withheld to protect poor > non-filtering transit party that I used :) ) > > > block Most downstream AS (not full path) > ----------------- ---------------------------------- > > [snip!] > > 3FFE:2900:FFE1::0/48 4768 When I set up our first tunnels to the 6bone, I was keen to set up more than one, since managing a multi-homed environment is the main thing I wanted to test. We are multi-homed in our IPv4 network, and this requirement will not go away as we transition to v6. At the time, I asked about the multi-homing/non-(p)TLA problem, and got various conflicting responses. More telling, when I progressed to setting up tunnels to our first test router, only one of the upstream networks was willing to delegate any address space to me -- the others all said "you already have some from Sprint, just announce that to us". > II. If you are multi-homed: > > Filter Outbound, please. It is simple. > > ipv access-list firstprovider permit ::/ > > ipv access-list secondprovider permit ::/ We _are_ filtering outbound route advertisements; however, we are restricting each one to the same Sprint-provided prefix, since that's all we have. This is clearly wrong, according to all the routing practices drafts I have seen for the 6Bone. > When Ipv6 goes live, unless business is more good-willed than it is now, > this is going to break things, and one pTLA may not have much motivation to > fix the problem (unless flames on the 6bone mailing lists really hurt). Should I be demanding v6 address prefixes from all my pTLAs? On a related note, I've looked, but I can't find the recommended solution to the following problem; I also asked Steve Deering about this during his IPv6 tutorial at Apricot this year, and at the time he didn't know the operational policy on this either (although he could have been trying to encourage me to stop asking stupid questions by feigning ignorance :) o NLA is multi-homed to several pTLAs; o Each pTLA delegates a v6 address prefix to that NLA; o NLA has a customer who needs addresses. Does the NLA delegate one prefix to the customer per pTLA? Does the customer then delegate address(es) from each supplied prefix to every interface they have to number in their network? Given that the reason we are (and will be) multi-homed is for resilience, and reduce dependency on any single upstream provider, if I don't announce all prefixes to all providers we're never going to get TCP sessions (as they exist now) to survive a "pTLA down" event. At the moment it looks like the only way to multi-home in the manner that we are used to with IPv4 is to become a (p)TLA. I'm confused :) If someone could point me towards some written words on this stuff, I would be very appreciative. Thanks, Joe -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Te Kaihoahoa Kawei, CLEAR Communications Ltd http://www.clear.net.nz/ From cmetz@inner.net Tue Jul 20 07:06:12 1999 From: cmetz@inner.net (Craig Metz) Date: Tue, 20 Jul 1999 02:06:12 -0400 Subject: Bad routes update In-Reply-To: Your message of "Mon, 19 Jul 1999 22:45:29 EDT." Message-ID: <199907200606.GAA26327@inner.net> In message , you write: >3FFE:F00:2::0/48 11261 This is not a bogus route per se. I told them to set it up this way. I have been recommending that non-pTLA multi-homed sites use a /48, which happens to mesh nicely with the way I've been managing tunnel address space at NRL. I can see a very very strong case for making it /32 and setting a hard and fast rule that prefixes >/32 are not allowed into the cloud. I think that it would be a Very Very Good Thing if no backbone router ever had to look at beyond the first 32 bits of the address, as this would make life a Whole Lot Easier for hardware that is designed for the best-performance case being 32 bit addresses (like, oh, say, most backbone routers). Now, these other prefixes are bogon. I'd like to add one I saw in my routing tables: 3FFE:F00:A:1133::0/64 *> 3FFE:F01:0:FFFF::5 FE80::C8E:50C2:7 Tunnel1 1225 1103 65502 5623 559 1717 1835 1849 109 3462 3263 49 i * 3FFE:F01:0:FFFF::19 FE80::E0:1E8E:C2C1:18 Tunnel6 5609 1225 1275 1103 222 5623 559 1717 1835 1849 109 3462 3263 49 i 3FFE:F00:A:11E1::0/64 *> 3FFE:F01:0:FFFF::5 FE80::C8E:50C2:7 Tunnel1 1225 1103 65502 5623 559 1717 786 1849 109 3462 3263 49 ? * 3FFE:F01:0:FFFF::19 FE80::E0:1E8E:C2C1:18 Tunnel6 5609 1225 1275 1103 222 5623 559 1717 786 1849 109 3462 3263 49 ? NIST guys, please fix. >3FFE::0/16 2497 (prepended) Sigh. >When Ipv6 goes live, unless business is more good-willed than it is now, >this is going to break things, and one pTLA may not have much motivation to >fix the problem (unless flames on the 6bone mailing lists really hurt). What's basically going to have to happen soon is that we're going to have to turn on the basic BGP knobs. I'd like to see routing transit policy stuff in place on the 6Bone as well as reasonable path metrics and such, as it would stop much of the current tunnel routing insanity. Perhaps the Cisco guys could elaborate, but I had the impression that only a very limited subset of the knobs are really built for IPv6. This might complicate things. -Craig From richdr@microsoft.com Tue Jul 20 07:16:48 1999 From: richdr@microsoft.com (Richard Draves) Date: Mon, 19 Jul 1999 23:16:48 -0700 Subject: Bad routes update Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145155E4@RED-MSG-50> > More telling, when I progressed to setting up tunnels to our first > test router, only one of the upstream networks was willing to delegate > any address space to me -- the others all said "you already have some > from Sprint, just announce that to us". They were wrong... > Should I be demanding v6 address prefixes from all my pTLAs? Yes. > On a related note, I've looked, but I can't find the > recommended solution > to the following problem; I also asked Steve Deering about this during > his IPv6 tutorial at Apricot this year, and at the time he > didn't know the > operational policy on this either (although he could have been trying > to encourage me to stop asking stupid questions by feigning > ignorance :) > > o NLA is multi-homed to several pTLAs; > o Each pTLA delegates a v6 address prefix to that NLA; > o NLA has a customer who needs addresses. > > Does the NLA delegate one prefix to the customer per pTLA? Yes, you should give your customer multiple prefixes in this situation. > Does the customer then delegate address(es) from each supplied prefix > to every interface they have to number in their network? Yes, the customer's interfaces will get multiple addresses. > At the moment it looks like the only way to multi-home in the manner > that we are used to with IPv4 is to become a (p)TLA. We're trying to avoid that. > I'm confused :) If someone could point me towards some > written words on > this stuff, I would be very appreciative. There were some presentations on this (although not from a 6bone operational viewpoint) last week at the second IPNG meeting in Oslo - look for the minutes. Thanks, Rich From cmetz@inner.net Tue Jul 20 07:55:44 1999 From: cmetz@inner.net (Craig Metz) Date: Tue, 20 Jul 1999 02:55:44 -0400 Subject: Bad routes update In-Reply-To: Your message of "Mon, 19 Jul 1999 23:50:44 PDT." <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50> Message-ID: <199907200655.GAA26375@inner.net> In message <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50>, you write: >> >3FFE:F00:2::0/48 11261 >> >> This is not a bogus route per se. I told them to set it up >> this way. I have >> been recommending that non-pTLA multi-homed sites use a /48, >> which happens to >> mesh nicely with the way I've been managing tunnel address >> space at NRL. > >This is bogus - the backbone should only see /24s. First off, you're going to have a very hard time arguing that the new /28s shouldn't be seen. Second, there *must* be some provision for sites to multi-home without being a full pTLA, or pTLA allocations will explode as will the allocations of pTLAs to people who shouldn't have them. -Craig From cmetz@inner.net Tue Jul 20 08:06:46 1999 From: cmetz@inner.net (Craig Metz) Date: Tue, 20 Jul 1999 03:06:46 -0400 Subject: Bad routes update In-Reply-To: Your message of "Tue, 20 Jul 1999 16:54:42 +1000." <37941D32.989451DE@iprg.nokia.com> Message-ID: <199907200706.HAA26397@inner.net> [IMO this thread should probably move to deployment, but anyway...] In message <37941D32.989451DE@iprg.nokia.com>, you write: >> I think that it >> would be a Very Very Good Thing if no backbone router ever had to look at >> beyond the first 32 bits of the address, as this would make life a Whole Lot >> Easier for hardware that is designed for the best-performance case being 32 >> bit addresses (like, oh, say, most backbone routers). > > Having worked on a high-speed forwarding ASIC that can do v6, I'd say >that it makes No Difference At All. If it did, I'd suggest that the >design would be very poor. Vendors seem to be taking one of two approaches. One of them is to build an extremely flexible router that will just not have a serious problem dealing with stuff like IPv6 should it need to be dealt with. Another is to build an IPv4 router, and anything not IPv4 might be shoehorned later but it isn't going to be graceful. If prefixes are restricted to /32, there just isn't a problem for either sort of box. (On the latter sort of box, IPv6 multicast loses in a big way though) I agree that the 32-bit-centric (or 64-bit-centric for multicast purposes) design is a poor one, but it exists. Okay, so maybe it's a feature and not a bug if those boxes have a hard time.... -Craig From richdr@microsoft.com Tue Jul 20 07:59:36 1999 From: richdr@microsoft.com (Richard Draves) Date: Mon, 19 Jul 1999 23:59:36 -0700 Subject: Bad routes update Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145155E8@RED-MSG-50> > First off, you're going to have a very hard time arguing > that the new /28s > shouldn't be seen. Quite right, I was forgetting the new /28s. So make that /28s. (If we moved away from test addresses to real TLAs, then it would be /16s.) > Second, there *must* be some provision for sites to > multi-home without being a full pTLA, or pTLA allocations > will explode as will > the allocations of pTLAs to people who shouldn't have them. Yes, we spent two hours on this in Oslo - look for the minutes. But the basic idea is to trade more scalable backbone routing for greater complexity at the network periphery doing source & destination address selection. An RFC 2260-style approach is another part of the proposed solution. Rich From richdr@microsoft.com Tue Jul 20 07:50:44 1999 From: richdr@microsoft.com (Richard Draves) Date: Mon, 19 Jul 1999 23:50:44 -0700 Subject: Bad routes update Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50> > >3FFE:F00:2::0/48 11261 > > This is not a bogus route per se. I told them to set it up > this way. I have > been recommending that non-pTLA multi-homed sites use a /48, > which happens to > mesh nicely with the way I've been managing tunnel address > space at NRL. This is bogus - the backbone should only see /24s. Rich From jabley@clear.co.nz Tue Jul 20 10:33:34 1999 From: jabley@clear.co.nz (Joe Abley) Date: Tue, 20 Jul 1999 21:33:34 +1200 Subject: Bad routes update In-Reply-To: <199907200655.GAA26375@inner.net>; from Craig Metz on Tue, Jul 20, 1999 at 02:55:44AM -0400 References: <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50> <199907200655.GAA26375@inner.net> Message-ID: <19990720213333.D62668@clear.co.nz> Hi, On Tue, Jul 20, 1999 at 02:55:44AM -0400, Craig Metz wrote: > In message <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50>, you write: > >> >3FFE:F00:2::0/48 11261 > >> > >> This is not a bogus route per se. I told them to set it up > >> this way. I have > >> been recommending that non-pTLA multi-homed sites use a /48, > >> which happens to > >> mesh nicely with the way I've been managing tunnel address > >> space at NRL. > > > >This is bogus - the backbone should only see /24s. > > First off, you're going to have a very hard time arguing that the new /28s > shouldn't be seen. Second, there *must* be some provision for sites to > multi-home without being a full pTLA, or pTLA allocations will explode as will > the allocations of pTLAs to people who shouldn't have them. I was going to keep quiet about this until I had done a lot more reading, but it seems that perhaps things aren't as cut and dried as I had imagined, and perhaps there is some benefit in raising this on the 6bone list. I asked questions about multi-homing a long time ago, and the prevelant answer at the time (which I am hearing from Richard again, so I guess it hasn't changed) was: o if you connect to multiple pTLAs, you will get multple allocations of address space, since aggregation in the backbone is important and must not be compromised. o if you connect to an NLA which is multi-homed, you will be provided with multiple addresses for every host. I raised some issues regarding resilience of individual TCP sessions in the event of a pTLA-NLA event upstream, and the answers were (and are): o stability of individual sessions is not important in the event of a routing change upstream; o having _new_ sessions connect correctly (i.e. handling the change of TCP session endpoint address) is more important; this will be done by o an algorithm for choosing suitable source and destination addresses for TCP virtual circuit endpoints that will become clear with operational experience. I am not convinced by the first point, and the second and third ideas look very clumsy to me. Much more clumsy than having long-prefix routes injected into the backbone, leading to routers with 80,000 routes in them, to be honest. Personal opinion, and a little diversionary. My real concern is the operational impact of managing IP addresses of end users, or of the administrators just before the end-users. Suppose we, as a large (by NZ terms; tiny in global terms) operator decide to multi-home to four backbone providers. We will not be alone; other providers in NZ will do similar things. This happens now with IPv4 in one way or another. Today we have smaller ISPs who dual-attach to two or more of the major carriers. And below them we have customers who dual-home between ISPs. All this dual-homing is done for a reason, and that's diversity -- the way we build fault tolerance into our IP networks is to provision multiple, diverse and independent paths, and to advertise our networks in every direction. This takes care and skill to manage correctly, but if done well can be very effective. With IPv6, this means that the poor customer will need to number each address on their equipment with as many as 16 different addresses (their upstreams will each have to deal with 8). >From an operational perspective, we deal with dual-homed customers today who do not have technical staff in-house -- they hire it in, by the hour, and pay through the nose for it. A change in a customer relationship for one of the NLAs (who have no direct relationship with the end customer in question) now has the knock-on effect of requiring all downstream users to change addresses on their interfaces. I believe the IPv6 autoconfiguration story, but only as far as it goes -- I don't believe in effective automatic DNS and route filter updates, for example. There is going to be manual intervention required all along the track. The number of end-users just in our customer base that have a business requirement to multi-home increases every month. This sounds a little bit like a nightmare. Is this for real? This sounds a little less like IP, and a little more like E.164 number portability in the switched voice network, complete with business cards that need re-printing every two months (cue Psycho violins, trembling shower curtain, shadow of hand c/w bloody knife). For pTLA above, also read TLA in the real network -- I am presuming that the original aims of the 6bone hold true, and that operational procedures developed here will migrate their way to the Real Network. I still presume that I am under some basic misconception that, once cleared, will leave me happy and relaxed. The sooner someone can point it out to me, the sooner I can get some sleep :) Joe -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Te Kaihoahoa Kawei, CLEAR Communications Ltd http://www.clear.net.nz/ From peter@jazz-1.trumpet.com.au Tue Jul 20 10:37:48 1999 From: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Tue, 20 Jul 1999 19:37:48 +1000 (EST) Subject: Bad routes update In-Reply-To: <19990720171753.A60925@clear.co.nz> Message-ID: On Tue, 20 Jul 1999, Joe Abley wrote: > On Mon, Jul 19, 1999 at 10:45:29PM -0400, Robert Rockell wrote: > > After tearing down my inbound filter to only ONE peer of all of my pTLA > > peers, I see the following bad routes (as path withheld to protect poor > > non-filtering transit party that I used :) ) > > > > > > block Most downstream AS (not full path) > > ----------------- ---------------------------------- > > > > [snip!] > > > > 3FFE:2900:FFE1::0/48 4768 > > When I set up our first tunnels to the 6bone, I was keen to set up > more than one, since managing a multi-homed environment is the main > thing I wanted to test. We are multi-homed in our IPv4 network, and > this requirement will not go away as we transition to v6. > > At the time, I asked about the multi-homing/non-(p)TLA problem, and > got various conflicting responses. > > More telling, when I progressed to setting up tunnels to our first > test router, only one of the upstream networks was willing to delegate > any address space to me -- the others all said "you already have some > from Sprint, just announce that to us". > > > II. If you are multi-homed: > > > > Filter Outbound, please. It is simple. > > > > ipv access-list firstprovider permit ::/ > > > > ipv access-list secondprovider permit ::/ > > We _are_ filtering outbound route advertisements; however, we are > restricting each one to the same Sprint-provided prefix, since that's > all we have. > > This is clearly wrong, according to all the routing practices drafts > I have seen for the 6Bone. > > > When Ipv6 goes live, unless business is more good-willed than it is now, > > this is going to break things, and one pTLA may not have much motivation to > > fix the problem (unless flames on the 6bone mailing lists really hurt). > > Should I be demanding v6 address prefixes from all my pTLAs? > > On a related note, I've looked, but I can't find the recommended solution > to the following problem; I also asked Steve Deering about this during > his IPv6 tutorial at Apricot this year, and at the time he didn't know the > operational policy on this either (although he could have been trying > to encourage me to stop asking stupid questions by feigning ignorance :) > > o NLA is multi-homed to several pTLAs; > o Each pTLA delegates a v6 address prefix to that NLA; > o NLA has a customer who needs addresses. > > Does the NLA delegate one prefix to the customer per pTLA? > > Does the customer then delegate address(es) from each supplied prefix > to every interface they have to number in their network? > > Given that the reason we are (and will be) multi-homed is for resilience, > and reduce dependency on any single upstream provider, if I don't > announce all prefixes to all providers we're never going to get TCP > sessions (as they exist now) to survive a "pTLA down" event. > > At the moment it looks like the only way to multi-home in the manner > that we are used to with IPv4 is to become a (p)TLA. > > I'm confused :) If someone could point me towards some written words on > this stuff, I would be very appreciative. > > Thanks, > > > Joe Tell me about it. I banged on enough doors about the subject, but never got a definitive answer from my point of view. At the time I was running two NLA's with suballocations from each which was the "done" thing. The bottom line was I had difficulty at the host level in making decisions as to which source address to choose. All the rules under the sun didn't (IMHO) help me make those decisions and in the end it was arbitrary - it was pretty hit & miss networking. I believe the answer lay in utilizing RA, but it was my impression that this was still work in progress. It was listed as a hot topic at the last IETF meeting, but as I wasn't there, I can't comment on the outcome. I did read the latest draft on the subject, but it didn't satisfy me either. I've had the impression it's been stuck in the too hard basket for too long. My problems went away by moving to a pTLA, which I believe has been the de facto answer to the problem :) Clearly this is not a realistic scenario. If there's anyone who multi homes NLA or SLA please speak up for I think you would be a rarity. BTW, a couple of months ago, for my own enjoyment, I put together a derivation of the GSE proposal that may solve the problem of multihoming. Sadly, however, it is probably too late for this as too many things are set in concrete. I can throw it up on our web site for any interested parties. anyway... back to writing OS's... seeya. Peter > > -- > Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 > Te Kaihoahoa Kawei, CLEAR Communications Ltd http://www.clear.net.nz/ > -- 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 LHart38357@aol.com Tue Jul 20 10:54:28 1999 From: LHart38357@aol.com (LHart38357@aol.com) Date: Tue, 20 Jul 1999 05:54:28 EDT Subject: Private ASN space Message-ID: <7919b4a0.24c5a154@aol.com> In a message dated 99-07-20 00:44:03 EDT, you write: << 6bone@ISI.EDU >> how do i get off of this listing? Larry H From jabley@clear.co.nz Tue Jul 20 13:09:28 1999 From: jabley@clear.co.nz (Joe Abley) Date: Wed, 21 Jul 1999 00:09:28 +1200 Subject: Private ASN space In-Reply-To: <199907200437.EAA26126@inner.net>; from Craig Metz on Tue, Jul 20, 1999 at 12:37:25AM -0400 References: <199907200437.EAA26126@inner.net> Message-ID: <19990721000928.A65571@clear.co.nz> On Tue, Jul 20, 1999 at 12:37:25AM -0400, Craig Metz wrote: > > Would someone kindly remind me what the reserved-for-private-use ASNs are? > > I need an ASN for use with my 6Bone routers (my == me, not NRL), and getting > a "real" one is well outside my budget. Barring constructive objections, I'd > like to claim one of the private ones for this purpose. RFC1930: Guidelines for creation, selection and registration of an Autonomous System (AS), J. Hawkinson, T. Bates, March 1996. ... 10. Reserved AS Numbers The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): 64512 through 65535 ... -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Te Kaihoahoa Kawei, CLEAR Communications Ltd http://www.clear.net.nz/ From jimmy.kyriannis@nyu.edu Tue Jul 20 14:41:04 1999 From: jimmy.kyriannis@nyu.edu (Jimmy Kyriannis) Date: Tue, 20 Jul 1999 09:41:04 -0400 Subject: Private ASN space In-Reply-To: <199907200437.EAA26126@inner.net> Message-ID: At 12:37 AM -0400 7/20/99, Craig Metz wrote: > Would someone kindly remind me what the reserved-for-private-use ASNs are? > > I need an ASN for use with my 6Bone routers (my == me, not NRL), and getting >a "real" one is well outside my budget. Barring constructive objections, I'd >like to claim one of the private ones for this purpose. > > -Craig In a nutshell, it means that "reserved-for-private-use ASNs" are reserved for internal use on an enterprise network, but may not be used on the Internet at large. To the Internet, an enterprise has only one ASN that's advertised to all routers on the backbone. However, a problem arises when some large networks use an EGP (such as BGP) internally to aggregate large routing tables and establish routing policies between sections of the network. When used internally with the enterprise, some BGP configurations require multiple ASNs to be used in order to achieve certain functionality. Hence, a dilemma: an enterprise has only one ASN, yet may need more than one to achieve certain routing topologies within. This is solved through the use of these private ASNs; they can be used safely within an enterprise network, however, may not be used for reachability advertisements to the Internet at large. Sorry if this slightly of-topic, but hopefully answers the question raised. Jimmy From perry@piermont.com Tue Jul 20 14:54:45 1999 From: perry@piermont.com (Perry E. Metzger) Date: 20 Jul 1999 09:54:45 -0400 Subject: Bad routes update In-Reply-To: Craig Metz's message of "Tue, 20 Jul 1999 02:55:44 -0400" References: <199907200655.GAA26375@inner.net> Message-ID: <87673fzasa.fsf@jekyll.piermont.com> Craig Metz writes: > >This is bogus - the backbone should only see /24s. > > First off, you're going to have a very hard time arguing that the new /28s > shouldn't be seen. Second, there *must* be some provision for sites to > multi-home without being a full pTLA, or pTLA allocations will explode as will > the allocations of pTLAs to people who shouldn't have them. There are some people who try to pretend that multihoming doesn't happen. It does, though, and there really is no way people are going to convince others to eliminate the redundancy they've had in their IPv4 links, especially when it has worked well for them. Perry From perry@piermont.com Tue Jul 20 14:58:45 1999 From: perry@piermont.com (Perry E. Metzger) Date: 20 Jul 1999 09:58:45 -0400 Subject: Bad routes update In-Reply-To: Joe Abley's message of "Tue, 20 Jul 1999 21:33:34 +1200" References: <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50> <199907200655.GAA26375@inner.net> <19990720213333.D62668@clear.co.nz> Message-ID: <874sizzalm.fsf@jekyll.piermont.com> Joe Abley writes: > I raised some issues regarding resilience of individual TCP sessions > in the event of a pTLA-NLA event upstream, and the answers were (and are): > > o stability of individual sessions is not important in the event of > a routing change upstream; I have a bridge to sell you in lower Manhattan, too. > o having _new_ sessions connect correctly (i.e. handling the change > of TCP session endpoint address) is more important; this will be done by > > o an algorithm for choosing suitable source and destination addresses > for TCP virtual circuit endpoints that will become clear with > operational experience. > > I am not convinced by the first point, and the second and third ideas > look very clumsy to me. I agree. They're basically wishing, not technology. Right now, we have v4 users who are doing just fine with redundant links which *don't* lose their connectivity, and right now, we *don't* have these magic algorithms in any state that will work right. I think those v4 users are not going to accept being told that they can't do what they're doing now. Like it or not, we will have to accept multiple announcements of "punched-through" address blocks way below the /28 level. I understand the desire to reduce the number of routes out there -- really, I do! -- and the strategy will work fine for many users. It just isn't going to fly, though, with folks who are out there paying for multiple carriers now so that they get reliability. Perry From kuznet@ms2.inr.ac.ru Tue Jul 20 14:49:06 1999 From: kuznet@ms2.inr.ac.ru (kuznet@ms2.inr.ac.ru) Date: Tue, 20 Jul 1999 17:49:06 +0400 (MSK DST) Subject: Bad routes update In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D810145155E8@RED-MSG-50> from "Richard Draves" at Jul 19, 99 11:59:36 pm Message-ID: <199907201349.RAA28251@ms2.inr.ac.ru> Hello! > Quite right, I was forgetting the new /28s. So make that /28s. Maybe /32 then to keep it even? 8)8) It starts to sound ridiculous. I see no reasons to restrict route propagation via 6bone, it is experimental network and its goal is to experiment. 6bone routing table is so small, that putting any restrictions is meaningless. All the problems may be solved on peer-to-peer base, rather then by enforcing artifical constraints, which are wrong by defintion: goto the very beginning. Alexey Kuznetsov From map@stacken.kth.se Tue Jul 20 19:01:17 1999 From: map@stacken.kth.se (Magnus Ahltorp) Date: 20 Jul 1999 20:01:17 +0200 Subject: Bad routes update In-Reply-To: Peter Tattam's message of "Tue, 20 Jul 1999 19:37:48 +1000 (EST)" References: Message-ID: > If there's anyone who multi homes NLA or SLA please speak up for I > think you would be a rarity. I'm multihoming as a site (/48), and I have separate address assignments from all my peers and I talk BGP with my peers. I announce all my addresses to all peers, but that gets filtered out in the peer. I only use BGP to construct a path tree for me and to get my peers to route my prefix to me. /Magnus From rrockell@sprint.net Tue Jul 20 19:50:22 1999 From: rrockell@sprint.net (Robert Rockell) Date: Tue, 20 Jul 1999 14:50:22 -0400 (EDT) Subject: Bad routes update In-Reply-To: <19990720171753.A60925@clear.co.nz> Message-ID: ->More telling, when I progressed to setting up tunnels to our first ->test router, only one of the upstream networks was willing to delegate ->any address space to me -- the others all said "you already have some ->from Sprint, just announce that to us". your other pTLA should read the spec, and delegate you address space. If you want another tunnel to me, let me know, and you can get rid of your other provider. -> ->We _are_ filtering outbound route advertisements; however, we are ->restricting each one to the same Sprint-provided prefix, since that's ->all we have. -> ->This is clearly wrong, according to all the routing practices drafts ->I have seen for the 6Bone. -> ->> When Ipv6 goes live, unless business is more good-willed than it is now, ->> this is going to break things, and one pTLA may not have much motivation to ->> fix the problem (unless flames on the 6bone mailing lists really hurt). -> ->Should I be demanding v6 address prefixes from all my pTLAs? yes. -> ->On a related note, I've looked, but I can't find the recommended solution ->to the following problem; I also asked Steve Deering about this during ->his IPv6 tutorial at Apricot this year, and at the time he didn't know the ->operational policy on this either (although he could have been trying ->to encourage me to stop asking stupid questions by feigning ignorance :) -> -> o NLA is multi-homed to several pTLAs; -> o Each pTLA delegates a v6 address prefix to that NLA; -> o NLA has a customer who needs addresses. -> ->Does the NLA delegate one prefix to the customer per pTLA? -> ->Does the customer then delegate address(es) from each supplied prefix ->to every interface they have to number in their network? -> ->Given that the reason we are (and will be) multi-homed is for resilience, ->and reduce dependency on any single upstream provider, if I don't ->announce all prefixes to all providers we're never going to get TCP ->sessions (as they exist now) to survive a "pTLA down" event. -> ->At the moment it looks like the only way to multi-home in the manner ->that we are used to with IPv4 is to become a (p)TLA. or dual-assign and cry for TCPng to fail you over :) From rrockell@sprint.net Tue Jul 20 19:52:00 1999 From: rrockell@sprint.net (Robert Rockell) Date: Tue, 20 Jul 1999 14:52:00 -0400 (EDT) Subject: Bad routes update In-Reply-To: <199907200606.GAA26327@inner.net> Message-ID: No PTLA SHOULD RECIEVE A ROUTE FROM OTHER PTLA'S MORE SPECIFIC THEN THE FULL PTLA ROUTE. THERE IS NO CURRENT NEED FOR IT (other than maybe to do hot-potato routing eventually, but this needs to be fixed, not worked around. Thanks Rob Rockell Sprintlink Internet Service Center Operations Engineering 703-689-6322 1-800-724-3329, PIN 385-8833 Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne? On Tue, 20 Jul 1999, Craig Metz wrote: ->In message , you write: ->>3FFE:F00:2::0/48 11261 -> -> This is not a bogus route per se. I told them to set it up this way. I have ->been recommending that non-pTLA multi-homed sites use a /48, which happens to ->mesh nicely with the way I've been managing tunnel address space at NRL. -> -> I can see a very very strong case for making it /32 and setting a hard and ->fast rule that prefixes >/32 are not allowed into the cloud. I think that it ->would be a Very Very Good Thing if no backbone router ever had to look at ->beyond the first 32 bits of the address, as this would make life a Whole Lot ->Easier for hardware that is designed for the best-performance case being 32 ->bit addresses (like, oh, say, most backbone routers). -> -> Now, these other prefixes are bogon. -> -> I'd like to add one I saw in my routing tables: -> -> 3FFE:F00:A:1133::0/64 -> *> 3FFE:F01:0:FFFF::5 FE80::C8E:50C2:7 Tunnel1 1225 1103 65502 5623 559 1717 1835 1849 109 3462 3263 49 i -> * 3FFE:F01:0:FFFF::19 FE80::E0:1E8E:C2C1:18 Tunnel6 5609 1225 1275 1103 222 5623 559 1717 1835 1849 109 3462 3263 49 i -> 3FFE:F00:A:11E1::0/64 -> *> 3FFE:F01:0:FFFF::5 FE80::C8E:50C2:7 Tunnel1 1225 1103 65502 5623 559 1717 786 1849 109 3462 3263 49 ? -> * 3FFE:F01:0:FFFF::19 FE80::E0:1E8E:C2C1:18 Tunnel6 5609 1225 1275 1103 222 5623 559 1717 786 1849 109 3462 3263 49 ? -> -> NIST guys, please fix. -> ->>3FFE::0/16 2497 (prepended) -> -> Sigh. -> ->>When Ipv6 goes live, unless business is more good-willed than it is now, ->>this is going to break things, and one pTLA may not have much motivation to ->>fix the problem (unless flames on the 6bone mailing lists really hurt). -> -> What's basically going to have to happen soon is that we're going to have to ->turn on the basic BGP knobs. I'd like to see routing transit policy stuff in ->place on the 6Bone as well as reasonable path metrics and such, as it would ->stop much of the current tunnel routing insanity. -> -> Perhaps the Cisco guys could elaborate, but I had the impression that only ->a very limited subset of the knobs are really built for IPv6. This might ->complicate things. -> -> -Craig -> From map@stacken.kth.se Tue Jul 20 19:58:10 1999 From: map@stacken.kth.se (Magnus Ahltorp) Date: 20 Jul 1999 20:58:10 +0200 Subject: Bad routes update In-Reply-To: Joe Abley's message of "Tue, 20 Jul 1999 21:33:34 +1200" References: <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50> <199907200655.GAA26375@inner.net> <19990720213333.D62668@clear.co.nz> Message-ID: > o stability of individual sessions is not important in the event of > a routing change upstream; There is an internet-draft on how to use Mobile IP to solve this issue. > o having _new_ sessions connect correctly (i.e. handling the change > of TCP session endpoint address) is more important; this will be done by > > o an algorithm for choosing suitable source and destination addresses > for TCP virtual circuit endpoints that will become clear with > operational experience. There were presentations in Oslo that addressed these issues. > I am not convinced by the first point, and the second and third ideas > look very clumsy to me. Much more clumsy than having long-prefix routes > injected into the backbone, leading to routers with 80,000 routes in them, > to be honest. Personal opinion, and a little diversionary. Do you really think that there are only 80000 sites that want to be multi-homed? > With IPv6, this means that the poor customer will need to number each > address on their equipment with as many as 16 different addresses > (their upstreams will each have to deal with 8). And in what way is 16 addresses "many"? Compared to most IPv4 hosts, it's a huge amount, but then, this isn't IPv4. > >From an operational perspective, we deal with dual-homed customers today > who do not have technical staff in-house -- they hire it in, by the > hour, and pay through the nose for it. A change in a customer > relationship for one of the NLAs (who have no direct relationship with > the end customer in question) now has the knock-on effect of requiring > all downstream users to change addresses on their interfaces. > > I believe the IPv6 autoconfiguration story, but only as far as it > goes -- I don't believe in effective automatic DNS The DNS issues are addressed by the A6 RR. > and route filter updates, for example. There is going to be manual > intervention required all along the track. IP number dependency in route filters is just broken anyway. Normally, filters are there to allow or disallow some pattern of source/destination IP address prefixes and port numbers. I don't really see the problem in making those IP address prefixes symbolic. Once they are symbolic, I don't see why automatic updating and multiple prefixes should be a problem. > The number of end-users just in our customer base that have a business > requirement to multi-home increases every month. Yes, the requirement to multi-home increases. It will continue to increase. _That_ is the reason for not allowing IPv4 style multi-homing. The routing tables would become enormous. /Magnus From map@stacken.kth.se Tue Jul 20 20:07:05 1999 From: map@stacken.kth.se (Magnus Ahltorp) Date: 20 Jul 1999 21:07:05 +0200 Subject: Bad routes update In-Reply-To: "Perry E. Metzger"'s message of "20 Jul 1999 09:58:45 -0400" References: <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50> <199907200655.GAA26375@inner.net> <19990720213333.D62668@clear.co.nz> <874sizzalm.fsf@jekyll.piermont.com> Message-ID: > Like it or not, we will have to accept multiple announcements of > "punched-through" address blocks way below the /28 level. No, we don't have to accept that. Accepting it will just make people think that the multi-homing problem is solved. /Magnus From fink@es.net Tue Jul 20 20:20:45 1999 From: fink@es.net (Bob Fink) Date: Tue, 20 Jul 1999 12:20:45 -0700 Subject: pTLA request for MIBH Message-ID: <4.1.19990720121457.020d7bd0@imap2.es.net> 6bone Folk, Per the request from Stephen Stuart (below), I'm opening a two week window for the review of a pTLA for MIBH. I will close this on 3 August 99. Note that this will be a /28 pTLA assignment. If you will look closely at Stephen's experience, coupled with the customers he will have, I consider this one to easily qualify for a pTLA and very important to the IPv6 deployment program. Comments to the list please. Thanks, Bob === >To: Bob Fink >cc: Stephen Stuart >Subject: Request for pTLA >Date: Tue, 20 Jul 1999 11:59:44 -0700 >From: Stephen Stuart > >I'd like to get a pTLA for the MIBH network I'm building/expanding, so >that we can build in IPv6 from a relatively early stage. > >RFC 2546 6bone backbone pTLA requirements: > >> 1. The site MUST have experience with IPv6 on the 6Bone, at least as >> a leaf site and preferably as a transit pNLA under an existing >> pTLA. > >While at DEC's Network Research Laboratory, I was responsible for >setting up and operating the Digital Palo Alto IPv6 pTLA known as >DIGITAL-CA, and the native IPv6 exchange fabric at PAIX. I am still >involved in network architecture for PAIX, including future >IPv6-related services. I am very familiar with IPv6 issues for pTLAs. > >> 2. The site MUST have the ability and intent to provide "production- >> like" 6Bone backbone service to provide a robust and operationally >> reliable 6Bone backbone. > >My network's customers include AltaVista (high volume content >provider) and the Internet Software Consortium (for purposes of >demonstrating robustness, a root nameserver operator); we are >commited to reliability in every aspect of our network. We currently >exchange traffic with 40 other autonomous systems in three US west >coast sites, and are planning expansion to the US east coast and >Europe. > >> 3. The site MUST have a potential "user community" that would be >> served by becoming a pTLA, e.g., the requester is a major player >> in a region, country or focus of interest. > >Our immediate user community includes: > > - ISC's software developers, interested in testing IPv6-capable >versions of BIND and deploying them in an enviroment capable of >supporting root nameserver activity. > - The NetBSD team's software distribution folks, interested in making >ftp.netbsd.org IPv6-capable. > >Future users include AltaVista's software development arm. > >> > 4. Must commit to abide by the 6Bone backbone operational rules and >> > policies as defined in the present document. > >I so commit. > >Thanks, >Stephen From perry@piermont.com Tue Jul 20 20:26:05 1999 From: perry@piermont.com (Perry E. Metzger) Date: 20 Jul 1999 15:26:05 -0400 Subject: Bad routes update In-Reply-To: Magnus Ahltorp's message of "20 Jul 1999 21:07:05 +0200" References: <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50> <199907200655.GAA26375@inner.net> <19990720213333.D62668@clear.co.nz> <874sizzalm.fsf@jekyll.piermont.com> Message-ID: <87n1wrunqq.fsf@jekyll.piermont.com> Magnus Ahltorp writes: > > Like it or not, we will have to accept multiple announcements of > > "punched-through" address blocks way below the /28 level. > > No, we don't have to accept that. Accepting it will just make people > think that the multi-homing problem is solved. It isn't clear that the "multi-homing problem" has any other solution. Think of it from a systematic viewpoint. Is there actually a way for a multi-homed host both to get service from "two parts of the tree" and yet not announce that into the default free zone? Thinking about it for several minutes indicates "no". There are, of course, possible solutions, but they involve radical changes to the internet architecture. Stuff like having EIDs that do not contain routing information has been contemplated, but no one has yet produced a real functioning protocol based on such mechanisms. v6 as currently defined is not a new architecture with routing separated somehow from endpoint addressing. Given the architecture we have right now, how else can one really imagine doing multi-homing but with added announcements? You can't get around the fact that people will need the routing data to make a routing decision in the current architecture. Unless we come up with a new internet architecture in addition to a new addressing plan, it is unlikely we'll have a technical fix for this. I think the long term solution here is *financial*, not *technical*. A BGP route announcement imposes a cost on all of the routers in the default free zone. By finding a way to pass the cost of BGP announcements back to the announcer, we can assure that only those networks that "need" an announcement (with need defined by market forces) will make such announcements. If someone really needs multi-homing, they then help pay for the cost this imposes on everyone else. Perry From richdr@microsoft.com Tue Jul 20 23:36:19 1999 From: richdr@microsoft.com (Richard Draves) Date: Tue, 20 Jul 1999 15:36:19 -0700 Subject: Bad routes update Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515604@RED-MSG-50> > I see no reasons to restrict route propagation via 6bone, > it is experimental network and its goal is to experiment. > 6bone routing table is so small, that putting any restrictions > is meaningless. All the problems may be solved on peer-to-peer base, > rather then by enforcing artifical constraints, which are wrong > by defintion: goto the very beginning. I think thrashing out these routing policy issues and actually trying them in practice is one of the best uses of the 6bone. It's certainly not much good for getting packets from A to B :-). Rich From fink@es.net Wed Jul 21 00:22:34 1999 From: fink@es.net (Bob Fink) Date: Tue, 20 Jul 1999 16:22:34 -0700 Subject: Bad routes update In-Reply-To: <874sizzalm.fsf@jekyll.piermont.com> References: <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50> <199907200655.GAA26375@inner.net> <19990720213333.D62668@clear.co.nz> Message-ID: <4.1.19990720110647.020d3de0@imap2.es.net> 6bone list in general, Time for a long email on both the hardening effort and this very tough multihoming issue and how it relates to the 6bone. Note, I am not claiming to be an expert on either routing or multihoming problems (v4 or v6), rather I'm trying to steer the 6bone activity so the v6 community gets the most out of it. The intent of Rob Rockell's "6bone hardening effort" draft is to make the 6bone more operationally robust, and (unstated) to make sure the 6bone operates in the manner that the IPv6 development and standards community envisions with the Aggregation based unicast addressing format that established the TLA concept. >From the draft: >1. Abstract > >The 6Bone is an Ipv6 testbed to assist in the evolution and deployment >of IPv6. Because of this, it is important that the core backbone >of the IPv6 network maintain stability, and that all operators have >a common set of rules and guildelines by which to deploy IPv6 routing >equipment. This document provides a set of guildelines for all IPv6 >routing equipment operators to use as a reference for efficient and stable >deployment of IPv6 routing systems. As the complexity of the 6Bone grows, >the adherence to a common set of rules becomes increasingly important in >order for an efficient backbone to exist. Regarding making the 6bone operationally robust, the current state of routing policy (or lack thereof) combined with some sites that often don't take adequate responsibility to configure and operate for reliable production operation, leaves the 6bone very difficult to use for any real production use. Though some parts of the 6bone world, say in Japan for the WIDE project, run production, most don't do anything other than trade routes and pings (and not too well at that). Please don't be offended if you really do get production use out of your piece of the 6bone as I'm referring to the larger whole (and what many of us observe from the traffic we see). I would venture to say the longer term aspect of an end-user site surviving an ISP (pTLA) outage is not the primary issue at this time (yes, it's very important for the future). Rather, just making a simple 6bone work consistently and reliably is a first order high priority. Much work is going on in this regard from the 6REN/6TAP to Rob's Hardening effort (sanctioned by the 6bone/ngtrans community by the way). So to the first order what Rob has proposed (and presented to the list and in Oslo) are good engineering procedures to make a useful 6bone backone for reliable operation. Secondarily, we have a role related to the IPv6 development and standards community to provide a viable testbed (proving ground) for ideas related to future backbone operation. Having a coordinated effort to support this is very important. Everyone has recognized the problem with multi-homing in v6 for quite a while, especially those folk participating in the IPng WG for the last few years. I would generally characterize their view about the multi-homing problem as it being a very hard problem, yet necessary to tackle or we will have every /48 v6 prefix propagated in everyone's routing table. So what to do. First and foremost, the IPng community is now focusing on the multi-homing problem. There was a small team that decided to tackle it between Minneapolis and Oslo, offline to the WG, who then reported on their efforts to the IPng WG last week in Oslo. It is now viewed by the IPng WG as the highest priority work going on and there will be a multi-day IPng interim meeting on it before the Washington IETF meeting. Stay tuned to the ipng list for reports and info on all this. So, we need a 6bone that helps with this effort in the best way possible. I believe that this means we agree to operate the 6bone backbone with rules that are consistent with the current agreed IPng WG procedures as opposed to just polluting our routing tables with everyones' routes. Certainly one model for the 6bone (often suggested, I believe) is one of real world operation (and competition) determining how it will work. I can see that model possibly working in a real thriving fee for service competitive IPv6 ISP world but we aren't even close to that point yet. Also, we are less clear on many solutions to our problems yet, which is why IPng work is underway on multihoming. So we need some discipline and method to what we will try to do on the 6bone backbone. Thus I propose that we, for now, implement Rob's proposed hardening rules and don't try solve the multihoming issue by ad hoc methods for now. Then we review the current ideas and proposals coming out of the IPng WG on this over the next several months and entertain proposals for modifications to our operating policies as necessary to try out new multihoming techniques on the larger scale 6bone backbone. I definitely believe that to just allow all routes to be accepted will lead to problems and certainly not to any good long term solutions. Soon enough, if we are wrong about how much we can do to solve the v6 multihoming problem, we can revert to the methods used in the v4 world. Meanwhile I hope we will not only have a reliable backbone, but one that can support new ideas from the v6 development and standards community. I also agree with Rich Draves that debate on actual multihoming issues should move to the ipng list as they are working it there, leaving just the 6bone related stuff on the 6bone list. This is not to stifle the list at all, rather to get those working on multihoming maximally involved in the discussions. I hope you will agree to support some version of what I've described above so we can move ahead. Comments to the list please. Bob From perry@piermont.com Wed Jul 21 00:35:35 1999 From: perry@piermont.com (Perry E. Metzger) Date: 20 Jul 1999 19:35:35 -0400 Subject: Bad routes update In-Reply-To: Magnus Ahltorp's message of "20 Jul 1999 20:58:10 +0200" References: <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50> <199907200655.GAA26375@inner.net> <19990720213333.D62668@clear.co.nz> Message-ID: <87btd6uc6w.fsf@jekyll.piermont.com> Magnus Ahltorp writes: > > o stability of individual sessions is not important in the event of > > a routing change upstream; > > There is an internet-draft on how to use Mobile IP to solve this > issue. And how much operational experience is there? > Do you really think that there are only 80000 sites that want to be > multi-homed? Right now, there don't seem to be any real restrictions on the practice in v4 land other than taste, and yet, we aren't overwhelmed yet. I suspect that the desire will not expand faster than Moore's Law. If it does, market (financial) rather than technical solutions would seem to me to be superior. Perry From bound@zk3.dec.com Wed Jul 21 01:18:01 1999 From: bound@zk3.dec.com (Jim Bound) Date: Tue, 20 Jul 1999 20:18:01 -0400 Subject: pTLA request for MIBH In-Reply-To: Your message of "Tue, 20 Jul 1999 12:20:45 PDT." <4.1.19990720121457.020d7bd0@imap2.es.net> Message-ID: <199907210018.UAA0000013035@quarry.zk3.dec.com> Having Stephen Stuart work on IPv6 anywhere is a good thing and will be good for IPv6. Having Altavista and ISC as customers and what Stephen is doing here qualifies for real IPv6 work. This should be supported. /jim From rrockell@sprint.net Wed Jul 21 01:39:41 1999 From: rrockell@sprint.net (Robert Rockell) Date: Tue, 20 Jul 1999 20:39:41 -0400 (EDT) Subject: Bad routes update In-Reply-To: <87btd6uc6w.fsf@jekyll.piermont.com> Message-ID: ->Right now, there don't seem to be any real restrictions on the ->practice in v4 land other than taste, and yet, we aren't overwhelmed ->yet. I suspect that the desire will not expand faster than Moore's ->Law. If it does, market (financial) rather than technical solutions ->would seem to me to be superior. I disagree. With registries demanding the providers delegate down below /24 and /25, we can begin to expand more exponentially than may be first noted. With singly-homed (at least to one provider) sites, we may not see this unscale too quickly. however, with multiple-provider "small network" customers, we can imagine routing tables exploding beyond what we expect. Remember, small networks may be large networks with firewalls, so this can, in affect, get popular fast, if there are more address space conservationalists out there. As far as letting multi-homing go with v6 as it appears people do now, I can see the value in that, but I believe it is important to keep our engineering/operator hats on. To see multi-homing work correctly (one option is via RFC2260; outside of whether or not it will work), I think it important to work early on this, instead of the end-around approach we have had to suffer through with IPv4 (IPSec, traffic engineering, Qos, routing table size, etc...) I wonder if it important to keep the tenaments of IPv6 that we have held important since the protocol's inception, and work now to fix the problems and retain the inherent benefits the protocol can give, rather than compromise protocol beauty for "what will hopefully scale". Moore's Law MAY have an upper limit (though maybe not a forseeable one). 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 20 Jul 1999, Perry E. Metzger wrote: -> ->Magnus Ahltorp writes: ->> > o stability of individual sessions is not important in the event of ->> > a routing change upstream; ->> ->> There is an internet-draft on how to use Mobile IP to solve this ->> issue. -> ->And how much operational experience is there? -> ->> Do you really think that there are only 80000 sites that want to be ->> multi-homed? -> ->Right now, there don't seem to be any real restrictions on the ->practice in v4 land other than taste, and yet, we aren't overwhelmed ->yet. I suspect that the desire will not expand faster than Moore's ->Law. If it does, market (financial) rather than technical solutions ->would seem to me to be superior. -> ->Perry -> From Francis.Dupont@inria.fr Wed Jul 21 08:51:56 1999 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Wed, 21 Jul 1999 09:51:56 +0200 Subject: Bad routes update In-Reply-To: Your message of 20 Jul 1999 19:35:35 EDT. <87btd6uc6w.fsf@jekyll.piermont.com> Message-ID: <199907210752.JAA17270@givry.inria.fr> In your previous mail you wrote: Magnus Ahltorp writes: > > o stability of individual sessions is not important in the event of > > a routing change upstream; > > There is an internet-draft on how to use Mobile IP to solve this > issue. And how much operational experience is there? => the mobility stuff (use of bindings) is implemented but not yet the router renumbering (needed to set preferred lifetimes). Of course it needs some security (authentication) too. Another point: this works for ISP failures, not for renumbering because old addresses should be stiff valid (but default lifetimes are 7 and 30 days then renumbering survival is only a concern with very long connections). Regards Francis.Dupont@inria.fr PS: there already are some multihomed sites on the 6bone, operational experience will come with router renumbering implementations. From jabley@patho.gen.nz Wed Jul 21 10:13:57 1999 From: jabley@patho.gen.nz (Joe Abley) Date: Wed, 21 Jul 1999 21:13:57 +1200 Subject: MultiHoming with IPv6 Message-ID: <19990721211356.B17512@patho.gen.nz> Hi, I've been cluttering the 6bone list with some concerns about multi- homing from an operational perspective, and the subject has been deemed off-topic for now. Rob Rockell of Sprint suggested this was a better place to raise some of the issues in the post that follows, so here we go. Apologies for not lurking for longer than two minutes before barging in :) 6bone folk: apologies for the rude bcc'ing; just letting people know where at least one branch of this thread has been taken. I have been surprised by some of the vehement opposition to the idea of compromising the pure backbone aggregation model, given the amount of complexity that seems to be involved in the alternatives. Is it not more reasonable to expect to have to make compromises in this area, in the interests of a realistic transition to IPv6? Isn't it _unreasonable_ to effectively change the semantics of TCP, such that a distant network event could disrupt an active session (by making one or both endpoint addresses unreachable), rather than allowing it to recover and continue? Earlier 6bone post is attached, to provide some context. Joe --- Date: Tue, 20 Jul 1999 21:33:34 +1200 >From: Joe Abley To: Craig Metz Cc: Richard Draves , 6bone@ISI.EDU Subject: Re: Bad routes update X-Mailer: Mutt 0.95.4i In-Reply-To: <199907200655.GAA26375@inner.net>; from Craig Metz on Tue, Jul 20, 1999 at 02:55:44AM -0400 Precedence: bulk Hi, On Tue, Jul 20, 1999 at 02:55:44AM -0400, Craig Metz wrote: > In message <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50>, you write: > >> >3FFE:F00:2::0/48 11261 > >> > >> This is not a bogus route per se. I told them to set it up > >> this way. I have > >> been recommending that non-pTLA multi-homed sites use a /48, > >> which happens to > >> mesh nicely with the way I've been managing tunnel address > >> space at NRL. > > > >This is bogus - the backbone should only see /24s. > > First off, you're going to have a very hard time arguing that the new /28s > shouldn't be seen. Second, there *must* be some provision for sites to > multi-home without being a full pTLA, or pTLA allocations will explode as will > the allocations of pTLAs to people who shouldn't have them. I was going to keep quiet about this until I had done a lot more reading, but it seems that perhaps things aren't as cut and dried as I had imagined, and perhaps there is some benefit in raising this on the 6bone list. I asked questions about multi-homing a long time ago, and the prevelant answer at the time (which I am hearing from Richard again, so I guess it hasn't changed) was: o if you connect to multiple pTLAs, you will get multple allocations of address space, since aggregation in the backbone is important and must not be compromised. o if you connect to an NLA which is multi-homed, you will be provided with multiple addresses for every host. I raised some issues regarding resilience of individual TCP sessions in the event of a pTLA-NLA event upstream, and the answers were (and are): o stability of individual sessions is not important in the event of a routing change upstream; o having _new_ sessions connect correctly (i.e. handling the change of TCP session endpoint address) is more important; this will be done by o an algorithm for choosing suitable source and destination addresses for TCP virtual circuit endpoints that will become clear with operational experience. I am not convinced by the first point, and the second and third ideas look very clumsy to me. Much more clumsy than having long-prefix routes injected into the backbone, leading to routers with 80,000 routes in them, to be honest. Personal opinion, and a little diversionary. My real concern is the operational impact of managing IP addresses of end users, or of the administrators just before the end-users. Suppose we, as a large (by NZ terms; tiny in global terms) operator decide to multi-home to four backbone providers. We will not be alone; other providers in NZ will do similar things. This happens now with IPv4 in one way or another. Today we have smaller ISPs who dual-attach to two or more of the major carriers. And below them we have customers who dual-home between ISPs. All this dual-homing is done for a reason, and that's diversity -- the way we build fault tolerance into our IP networks is to provision multiple, diverse and independent paths, and to advertise our networks in every direction. This takes care and skill to manage correctly, but if done well can be very effective. With IPv6, this means that the poor customer will need to number each address on their equipment with as many as 16 different addresses (their upstreams will each have to deal with 8). >From an operational perspective, we deal with dual-homed customers today who do not have technical staff in-house -- they hire it in, by the hour, and pay through the nose for it. A change in a customer relationship for one of the NLAs (who have no direct relationship with the end customer in question) now has the knock-on effect of requiring all downstream users to change addresses on their interfaces. I believe the IPv6 autoconfiguration story, but only as far as it goes -- I don't believe in effective automatic DNS and route filter updates, for example. There is going to be manual intervention required all along the track. The number of end-users just in our customer base that have a business requirement to multi-home increases every month. This sounds a little bit like a nightmare. Is this for real? This sounds a little less like IP, and a little more like E.164 number portability in the switched voice network, complete with business cards that need re-printing every two months (cue Psycho violins, trembling shower curtain, shadow of hand c/w bloody knife). For pTLA above, also read TLA in the real network -- I am presuming that the original aims of the 6bone hold true, and that operational procedures developed here will migrate their way to the Real Network. I still presume that I am under some basic misconception that, once cleared, will leave me happy and relaxed. The sooner someone can point it out to me, the sooner I can get some sleep :) Joe -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Te Kaihoahoa Kawei, CLEAR Communications Ltd http://www.clear.net.nz/ From kuznet@ms2.inr.ac.ru Wed Jul 21 12:25:47 1999 From: kuznet@ms2.inr.ac.ru (kuznet@ms2.inr.ac.ru) Date: Wed, 21 Jul 1999 15:25:47 +0400 (MSK DST) Subject: Bad routes update In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515604@RED-MSG-50> from "Richard Draves" at Jul 20, 99 03:36:19 pm Message-ID: <199907211125.PAA22977@ms2.inr.ac.ru> Hello! > I think thrashing out these routing policy issues and actually trying them > in practice is one of the best uses of the 6bone. It's certainly not much > good for getting packets from A to B :-). Yup, it is truth 8)8) Thing, which I do not understand is how you want to investigate routing policy with <256 policed entities involved? It cannot result in any realistic results. That's my main point. You have to explode 6bone to make it closer to reality, rather than shrink it. Alexey From Alain.Durand@imag.fr Wed Jul 21 12:39:53 1999 From: Alain.Durand@imag.fr (Alain Durand) Date: Wed, 21 Jul 1999 13:39:53 +0200 Subject: Bad routes update In-Reply-To: <199907211125.PAA22977@ms2.inr.ac.ru> References: <4D0A23B3F74DD111ACCD00805F31D81014515604@RED-MSG-50> Message-ID: <4.2.0.56.19990721133209.00bef7f0@brahma.imag.fr> At 15:25 21/07/99 +0400, kuznet@ms2.inr.ac.ru wrote: >Hello! > > > I think thrashing out these routing policy issues and actually trying them > > in practice is one of the best uses of the 6bone. It's certainly not much > > good for getting packets from A to B :-). > >Yup, it is truth 8)8) > >Thing, which I do not understand is how you want to investigate >routing policy with <256 policed entities involved? It cannot result >in any realistic results. That's my main point. You have to explode >6bone to make it closer to reality, rather than shrink it. > >Alexey We have been operating the 6 bone for about 2 years with BGP4+ without enforcing any policy. This gave us enough time to understand what can/will go wrong with route announcement. All this experience lead us to RFC2546 and the current hardening draft. It is now time to move from an experimental network to a pre-production one. This means some kind of quality and robustness. This is in my opinion an important step forward to get ISP on board and convince them to offer native v6 service to their customers. - Alain. From masaki@merit.edu Wed Jul 21 18:53:13 1999 From: masaki@merit.edu (Masaki Hirabaru) Date: Wed, 21 Jul 1999 13:53:13 -0400 Subject: Bad routes update In-Reply-To: <4.1.19990720110647.020d3de0@imap2.es.net> References: <19990720213333.D62668@clear.co.nz> <874sizzalm.fsf@jekyll.piermont.com> <4.1.19990720110647.020d3de0@imap2.es.net> <4.1.19990720110647.020d3de0@imap2.es.net>,<4.1.19990720110647.020d3de0@imap2.es.net>,<4.1.19990720110647.020d3de0@imap2.es.net> Message-ID: <19990721135313F.masaki@merit.edu> Hi. Bob and all, >> Regarding making the 6bone operationally robust, the current state of >> routing policy (or lack thereof) combined with some sites that often don't >> take adequate responsibility to configure and operate for reliable >> production operation, leaves the 6bone very difficult to use for any real >> production use. Do you really think enforcing the routing policy leads to hardening (solving the current routing issues)? It will cut a couple of multi-homed sites to make the 6bone topology simple and decrease the number of routing table entries from ~200 to ~170 as well as other bogus routes by a few. But, I don't think it will help to improve the current state of routing reliability. Introducing the routing policy at each pTLA routers increases the complexity of 6bone routing (in configuration by hand). Before practicing the complex routing policy (that may be called a real-world practice), don't we have a couple of things to do? 1) Still a couple of pTLA sites are using the obsolete BGP4MP version incompatible to the RFC version of BGP4MP. The problems are that this is undocumented (since it's been obsolete) and that it can not be automatically detected. It would happen easily to configure the both sides with the different versions. A BGP session can be established, but the update formats are different. 2) There are a lot of route flapping even within the valid pTLA space. A long time ago, I tried to figure out the origins, but I gave up to continue it for all the occasions. It keeps happening. 3) There are a couple of strange routes outside the 6bone pTLA space drafting over the 6bone. We could get it covered by imposing the routing policy rather than solving the real problem. Masaki >> From: Bob Fink >> Subject: Re: Bad routes update >> Date: Tue, 20 Jul 1999 16:22:34 -0700 >> Message-ID: <4.1.19990720110647.020d3de0@imap2.es.net>,<4.1.19990720110647.020d3de0@imap2.es.net>,<4.1.19990720110647.020d3de0@imap2.es.net> >> >> 6bone list in general, >> >> Time for a long email on both the hardening effort and this very tough >> multihoming issue and how it relates to the 6bone. Note, I am not claiming >> to be an expert on either routing or multihoming problems (v4 or v6), >> rather I'm trying to steer the 6bone activity so the v6 community gets the >> most out of it. >> >> The intent of Rob Rockell's "6bone hardening effort" draft >> is >> to make the 6bone more operationally robust, and (unstated) to make sure >> the 6bone operates in the manner that the IPv6 development and standards >> community envisions with the Aggregation based unicast addressing format >> that established the TLA concept. >> >> >From the draft: >> >> >1. Abstract >> > >> >The 6Bone is an Ipv6 testbed to assist in the evolution and deployment >> >of IPv6. Because of this, it is important that the core backbone >> >of the IPv6 network maintain stability, and that all operators have >> >a common set of rules and guildelines by which to deploy IPv6 routing >> >equipment. This document provides a set of guildelines for all IPv6 >> >routing equipment operators to use as a reference for efficient and stable >> >deployment of IPv6 routing systems. As the complexity of the 6Bone grows, >> >the adherence to a common set of rules becomes increasingly important in >> >order for an efficient backbone to exist. >> >> Regarding making the 6bone operationally robust, the current state of >> routing policy (or lack thereof) combined with some sites that often don't >> take adequate responsibility to configure and operate for reliable >> production operation, leaves the 6bone very difficult to use for any real >> production use. Though some parts of the 6bone world, say in Japan for the >> WIDE project, run production, most don't do anything other than trade >> routes and pings (and not too well at that). Please don't be offended if >> you really do get production use out of your piece of the 6bone as I'm >> referring to the larger whole (and what many of us observe from the traffic >> we see). >> >> I would venture to say the longer term aspect of an end-user site surviving >> an ISP (pTLA) outage is not the primary issue at this time (yes, it's very >> important for the future). Rather, just making a simple 6bone work >> consistently and reliably is a first order high priority. Much work is >> going on in this regard from the 6REN/6TAP to Rob's Hardening effort >> (sanctioned by the 6bone/ngtrans community by the way). >> >> So to the first order what Rob has proposed (and presented to the list and >> in Oslo) are good engineering procedures to make a useful 6bone backone for >> reliable operation. >> >> Secondarily, we have a role related to the IPv6 development and standards >> community to provide a viable testbed (proving ground) for ideas related to >> future backbone operation. Having a coordinated effort to support this is >> very important. >> >> Everyone has recognized the problem with multi-homing in v6 for quite a >> while, especially those folk participating in the IPng WG for the last few >> years. I would generally characterize their view about the multi-homing >> problem as it being a very hard problem, yet necessary to tackle or we will >> have every /48 v6 prefix propagated in everyone's routing table. >> >> So what to do. First and foremost, the IPng community is now focusing on >> the multi-homing problem. There was a small team that decided to tackle it >> between Minneapolis and Oslo, offline to the WG, who then reported on their >> efforts to the IPng WG last week in Oslo. It is now viewed by the IPng WG >> as the highest priority work going on and there will be a multi-day IPng >> interim meeting on it before the Washington IETF meeting. Stay tuned to the >> ipng list for reports and info on all this. >> >> So, we need a 6bone that helps with this effort in the best way possible. I >> believe that this means we agree to operate the 6bone backbone with rules >> that are consistent with the current agreed IPng WG procedures as opposed >> to just polluting our routing tables with everyones' routes. >> >> Certainly one model for the 6bone (often suggested, I believe) is one of >> real world operation (and competition) determining how it will work. I can >> see that model possibly working in a real thriving fee for service >> competitive IPv6 ISP world but we aren't even close to that point yet. >> Also, we are less clear on many solutions to our problems yet, which is why >> IPng work is underway on multihoming. So we need some discipline and method >> to what we will try to do on the 6bone backbone. >> >> >> Thus I propose that we, for now, implement Rob's proposed hardening rules >> and don't try solve the multihoming issue by ad hoc methods for now. Then >> we review the current ideas and proposals coming out of the IPng WG on this >> over the next several months and entertain proposals for modifications to >> our operating policies as necessary to try out new multihoming techniques >> on the larger scale 6bone backbone. I definitely believe that to just allow >> all routes to be accepted will lead to problems and certainly not to any >> good long term solutions. >> >> Soon enough, if we are wrong about how much we can do to solve the v6 >> multihoming problem, we can revert to the methods used in the v4 world. >> Meanwhile I hope we will not only have a reliable backbone, but one that >> can support new ideas from the v6 development and standards community. >> >> >> I also agree with Rich Draves that debate on actual multihoming issues >> should move to the ipng list as they are working it there, leaving just the >> 6bone related stuff on the 6bone list. This is not to stifle the list at >> all, rather to get those working on multihoming maximally involved in the >> discussions. >> >> >> I hope you will agree to support some version of what I've described above >> so we can move ahead. >> >> >> Comments to the list please. >> >> Bob From rrockell@sprint.net Wed Jul 21 21:01:36 1999 From: rrockell@sprint.net (Robert Rockell) Date: Wed, 21 Jul 1999 16:01:36 -0400 (EDT) Subject: Bad routes update In-Reply-To: <19990721135313F.masaki@merit.edu> Message-ID: ->1) Still a couple of pTLA sites are using the obsolete BGP4MP ->version incompatible to the RFC version of BGP4MP. The problems ->are that this is undocumented (since it's been obsolete) and that ->it can not be automatically detected. It would happen easily to ->configure the both sides with the different versions. A BGP ->session can be established, but the update formats are different. Implementation issue. While it should be corrected, I don't know that this affects our ability to limit route annoucements to the aggregation model. ->2) There are a lot of route flapping even within the valid pTLA ->space. A long time ago, I tried to figure out the origins, but I ->gave up to continue it for all the occasions. It keeps happening. If we aggregate, I think we will see this diminish. many routes that flap come from statics that point to interfaces that go down, etc... If we aggregate, we won't see the affects of these, except in the case of yoru IBGP, where you will want your own specifics. ->3) There are a couple of strange routes outside the 6bone pTLA ->space drafting over the 6bone. We could get it covered by ->imposing the routing policy rather than solving the real problem. Filter them. That way, they will be gone. If you look closely enough, you can see 10/8 v4 space around. You just have to filter it at your edges to make sure it doesn't affect anyone. While I would personally like for these people to fix the problem, in this case, you can only control your own routing domain, thus going around them with a filter would be just as handy, and effectively the same thing. -> ->Masaki -> ->>> From: Bob Fink ->>> Subject: Re: Bad routes update ->>> Date: Tue, 20 Jul 1999 16:22:34 -0700 ->>> Message-ID: <4.1.19990720110647.020d3de0@imap2.es.net>,<4.1.19990720110647.020d3de0@imap2.es.net>,<4.1.19990720110647.020d3de0@imap2.es.net> ->>> ->>> 6bone list in general, ->>> ->>> Time for a long email on both the hardening effort and this very tough ->>> multihoming issue and how it relates to the 6bone. Note, I am not claiming ->>> to be an expert on either routing or multihoming problems (v4 or v6), ->>> rather I'm trying to steer the 6bone activity so the v6 community gets the ->>> most out of it. ->>> ->>> The intent of Rob Rockell's "6bone hardening effort" draft ->>> is ->>> to make the 6bone more operationally robust, and (unstated) to make sure ->>> the 6bone operates in the manner that the IPv6 development and standards ->>> community envisions with the Aggregation based unicast addressing format ->>> that established the TLA concept. ->>> ->>> >From the draft: ->>> ->>> >1. Abstract ->>> > ->>> >The 6Bone is an Ipv6 testbed to assist in the evolution and deployment ->>> >of IPv6. Because of this, it is important that the core backbone ->>> >of the IPv6 network maintain stability, and that all operators have ->>> >a common set of rules and guildelines by which to deploy IPv6 routing ->>> >equipment. This document provides a set of guildelines for all IPv6 ->>> >routing equipment operators to use as a reference for efficient and stable ->>> >deployment of IPv6 routing systems. As the complexity of the 6Bone grows, ->>> >the adherence to a common set of rules becomes increasingly important in ->>> >order for an efficient backbone to exist. ->>> ->>> Regarding making the 6bone operationally robust, the current state of ->>> routing policy (or lack thereof) combined with some sites that often don't ->>> take adequate responsibility to configure and operate for reliable ->>> production operation, leaves the 6bone very difficult to use for any real ->>> production use. Though some parts of the 6bone world, say in Japan for the ->>> WIDE project, run production, most don't do anything other than trade ->>> routes and pings (and not too well at that). Please don't be offended if ->>> you really do get production use out of your piece of the 6bone as I'm ->>> referring to the larger whole (and what many of us observe from the traffic ->>> we see). ->>> ->>> I would venture to say the longer term aspect of an end-user site surviving ->>> an ISP (pTLA) outage is not the primary issue at this time (yes, it's very ->>> important for the future). Rather, just making a simple 6bone work ->>> consistently and reliably is a first order high priority. Much work is ->>> going on in this regard from the 6REN/6TAP to Rob's Hardening effort ->>> (sanctioned by the 6bone/ngtrans community by the way). ->>> ->>> So to the first order what Rob has proposed (and presented to the list and ->>> in Oslo) are good engineering procedures to make a useful 6bone backone for ->>> reliable operation. ->>> ->>> Secondarily, we have a role related to the IPv6 development and standards ->>> community to provide a viable testbed (proving ground) for ideas related to ->>> future backbone operation. Having a coordinated effort to support this is ->>> very important. ->>> ->>> Everyone has recognized the problem with multi-homing in v6 for quite a ->>> while, especially those folk participating in the IPng WG for the last few ->>> years. I would generally characterize their view about the multi-homing ->>> problem as it being a very hard problem, yet necessary to tackle or we will ->>> have every /48 v6 prefix propagated in everyone's routing table. ->>> ->>> So what to do. First and foremost, the IPng community is now focusing on ->>> the multi-homing problem. There was a small team that decided to tackle it ->>> between Minneapolis and Oslo, offline to the WG, who then reported on their ->>> efforts to the IPng WG last week in Oslo. It is now viewed by the IPng WG ->>> as the highest priority work going on and there will be a multi-day IPng ->>> interim meeting on it before the Washington IETF meeting. Stay tuned to the ->>> ipng list for reports and info on all this. ->>> ->>> So, we need a 6bone that helps with this effort in the best way possible. I ->>> believe that this means we agree to operate the 6bone backbone with rules ->>> that are consistent with the current agreed IPng WG procedures as opposed ->>> to just polluting our routing tables with everyones' routes. ->>> ->>> Certainly one model for the 6bone (often suggested, I believe) is one of ->>> real world operation (and competition) determining how it will work. I can ->>> see that model possibly working in a real thriving fee for service ->>> competitive IPv6 ISP world but we aren't even close to that point yet. ->>> Also, we are less clear on many solutions to our problems yet, which is why ->>> IPng work is underway on multihoming. So we need some discipline and method ->>> to what we will try to do on the 6bone backbone. ->>> ->>> ->>> Thus I propose that we, for now, implement Rob's proposed hardening rules ->>> and don't try solve the multihoming issue by ad hoc methods for now. Then ->>> we review the current ideas and proposals coming out of the IPng WG on this ->>> over the next several months and entertain proposals for modifications to ->>> our operating policies as necessary to try out new multihoming techniques ->>> on the larger scale 6bone backbone. I definitely believe that to just allow ->>> all routes to be accepted will lead to problems and certainly not to any ->>> good long term solutions. ->>> ->>> Soon enough, if we are wrong about how much we can do to solve the v6 ->>> multihoming problem, we can revert to the methods used in the v4 world. ->>> Meanwhile I hope we will not only have a reliable backbone, but one that ->>> can support new ideas from the v6 development and standards community. ->>> ->>> ->>> I also agree with Rich Draves that debate on actual multihoming issues ->>> should move to the ipng list as they are working it there, leaving just the ->>> 6bone related stuff on the 6bone list. This is not to stifle the list at ->>> all, rather to get those working on multihoming maximally involved in the ->>> discussions. ->>> ->>> ->>> I hope you will agree to support some version of what I've described above ->>> so we can move ahead. ->>> ->>> ->>> Comments to the list please. ->>> ->>> Bob -> From masaki@merit.edu Wed Jul 21 21:55:14 1999 From: masaki@merit.edu (Masaki Hirabaru) Date: Wed, 21 Jul 1999 16:55:14 -0400 Subject: Bad routes update In-Reply-To: References: <19990721135313F.masaki@merit.edu> Message-ID: <19990721165514F.masaki@merit.edu> >> ->2) There are a lot of route flapping even within the valid pTLA >> ->space. A long time ago, I tried to figure out the origins, but I >> ->gave up to continue it for all the occasions. It keeps happening. >> >> If we aggregate, I think we will see this diminish. many routes that flap >> come from statics that point to interfaces that go down, etc... If we >> aggregate, we won't see the affects of these, except in the case of yoru >> IBGP, where you will want your own specifics. I don't think that most of the flapping on 6bone comes from interface up/down. And, pTLA routes are flapping, so we can not diminish them by aggregation. >> ->3) There are a couple of strange routes outside the 6bone pTLA >> ->space drafting over the 6bone. We could get it covered by >> ->imposing the routing policy rather than solving the real problem. >> >> Filter them. That way, they will be gone. If you look closely enough, you >> can see 10/8 v4 space around. You just have to filter it at your edges to >> make sure it doesn't affect anyone. While I would personally like for these >> people to fix the problem, in this case, you can only control your own >> routing domain, thus going around them with a filter would be just as >> handy, and effectively the same thing. Let me explain how they are strange. They have a strange as path and are flapping. It would indicate something wrong on 6bone. If the routing policy intends to solve the current 6bone routing issues, it would not work. It will just decrease the size of routing table but may introduce another complexity that may make it harder to catch the real problems. Masaki From fink@es.net Thu Jul 22 00:07:59 1999 From: fink@es.net (Bob Fink) Date: Wed, 21 Jul 1999 16:07:59 -0700 Subject: Bad routes update In-Reply-To: <19990721135313F.masaki@merit.edu> References: <4.1.19990720110647.020d3de0@imap2.es.net> <19990720213333.D62668@clear.co.nz> <874sizzalm.fsf@jekyll.piermont.com> <4.1.19990720110647.020d3de0@imap2.es.net> <4.1.19990720110647.020d3de0@imap2.es.net> <4.1.19990720110647.020d3de0@imap2.es.net> <4.1.19990720110647.020d3de0@imap2.es.net> Message-ID: <4.1.19990721154744.00d04c60@imap2.es.net> Masaki, At 01:53 PM 7/21/99 -0400, Masaki Hirabaru wrote: >Hi. Bob and all, > >>> Regarding making the 6bone operationally robust, the current state of >>> routing policy (or lack thereof) combined with some sites that often don't >>> take adequate responsibility to configure and operate for reliable >>> production operation, leaves the 6bone very difficult to use for any real >>> production use. > >Do you really think enforcing the routing policy leads to >hardening (solving the current routing issues)? It will cut a >couple of multi-homed sites to make the 6bone topology simple and >decrease the number of routing table entries from ~200 to ~170 as >well as other bogus routes by a few. But, I don't think it will >help to improve the current state of routing reliability. > >Introducing the routing policy at each pTLA routers increases the >complexity of 6bone routing (in configuration by hand). Before >practicing the complex routing policy (that may be called a >real-world practice), don't we have a couple of things to do? > >1) Still a couple of pTLA sites are using the obsolete BGP4MP >version incompatible to the RFC version of BGP4MP. The problems >are that this is undocumented (since it's been obsolete) and that >it can not be automatically detected. It would happen easily to >configure the both sides with the different versions. A BGP >session can be established, but the update formats are different. > >2) There are a lot of route flapping even within the valid pTLA >space. A long time ago, I tried to figure out the origins, but I >gave up to continue it for all the occasions. It keeps happening. > >3) There are a couple of strange routes outside the 6bone pTLA >space drafting over the 6bone. We could get it covered by >imposing the routing policy rather than solving the real problem. > I agree with your points in general. Note that the Hardening draft covers most of this in the context of requiring stable practice and good operational support to be a pTLA. My worry is not in reducing routing table entries at this stage of the 6bone, rather encouraging a discipline on the 6bone of good policy and good practice. If we agree in prinicpal on the draft, and each pTLA implements it in general, with the goal of a production quality network, we will start to identify (and force changes on) the unreliable pTLAs. I believe that a quality production backbone environment is what we are after now, with most of the testing occurring at sites. We have had little or no comment on Rob's Hardening draft to date, so I would encourage everyone to read it, make comments and improvements to it (to the list please). Bob From rrockell@sprint.net Thu Jul 22 01:04:09 1999 From: rrockell@sprint.net (Robert Rockell) Date: Wed, 21 Jul 1999 20:04:09 -0400 (EDT) Subject: Bad routes update In-Reply-To: <4.1.19990721154744.00d04c60@imap2.es.net> Message-ID: Please send comments. I have just submitted -01.txt, so see that soon. I will give two weeks, and submit -02.txt Changes: added statement regarding 6to4 (kept ambiguous so as to not impede its development, from a routing perspective). Added in a statement about multi-homing directly, to indicate future flexibility should the multi-homing solution need testing. 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, 21 Jul 1999, Bob Fink wrote: ->Masaki, -> ->At 01:53 PM 7/21/99 -0400, Masaki Hirabaru wrote: ->>Hi. Bob and all, ->> ->>>> Regarding making the 6bone operationally robust, the current state of ->>>> routing policy (or lack thereof) combined with some sites that often don't ->>>> take adequate responsibility to configure and operate for reliable ->>>> production operation, leaves the 6bone very difficult to use for any real ->>>> production use. ->> ->>Do you really think enforcing the routing policy leads to ->>hardening (solving the current routing issues)? It will cut a ->>couple of multi-homed sites to make the 6bone topology simple and ->>decrease the number of routing table entries from ~200 to ~170 as ->>well as other bogus routes by a few. But, I don't think it will ->>help to improve the current state of routing reliability. ->> ->>Introducing the routing policy at each pTLA routers increases the ->>complexity of 6bone routing (in configuration by hand). Before ->>practicing the complex routing policy (that may be called a ->>real-world practice), don't we have a couple of things to do? ->> ->>1) Still a couple of pTLA sites are using the obsolete BGP4MP ->>version incompatible to the RFC version of BGP4MP. The problems ->>are that this is undocumented (since it's been obsolete) and that ->>it can not be automatically detected. It would happen easily to ->>configure the both sides with the different versions. A BGP ->>session can be established, but the update formats are different. ->> ->>2) There are a lot of route flapping even within the valid pTLA ->>space. A long time ago, I tried to figure out the origins, but I ->>gave up to continue it for all the occasions. It keeps happening. ->> ->>3) There are a couple of strange routes outside the 6bone pTLA ->>space drafting over the 6bone. We could get it covered by ->>imposing the routing policy rather than solving the real problem. ->> -> ->I agree with your points in general. Note that the Hardening draft covers ->most of this in the context of requiring stable practice and good ->operational support to be a pTLA. My worry is not in reducing routing table ->entries at this stage of the 6bone, rather encouraging a discipline on the ->6bone of good policy and good practice. -> ->If we agree in prinicpal on the draft, and each pTLA implements it in ->general, with the goal of a production quality network, we will start to ->identify (and force changes on) the unreliable pTLAs. -> ->I believe that a quality production backbone environment is what we are ->after now, with most of the testing occurring at sites. -> ->We have had little or no comment on Rob's Hardening draft to date, so I ->would encourage everyone to read it, make comments and improvements to it ->(to the list please). -> -> -> -> ->Bob -> -> -> From jabley@clear.co.nz Thu Jul 22 01:56:35 1999 From: jabley@clear.co.nz (Joe Abley) Date: Thu, 22 Jul 1999 12:56:35 +1200 Subject: Could someone give me a hand with this? Message-ID: <19990722125634.A93744@clear.co.nz> Hi all, I have just been working with Canterbury University here in NZ trying to get them connected to the 6bone -- everything is looking good between us and them, but they seem to be having problems getting traffic from the rest of the network routed back to them. If someone could let me know how this looks from ourside our AS, I'd be very grateful. In particular, could people could let me know whether they can ping the following addresses? 3FFE:2900:FFE1::0 3FFE:2900:B:C::2 3FFE:2900:FFE1::2 3FFE:2900:FFE1::3 3FFE:2900:FFE1:1::1 More elaborately: We are AS4768, and are announcing 3FFE:2900:FFE1::0/48 to Sprint using BGP4+ with origin 4768. This address block is part of Sprint's /24, and was delegated to me by Rob when he kindly set up our tunnel. AS6175 (Sprint) --------- AS4768 (CLEAR) --------- AS9432 (Canterbury) Our tunnel to Sprint has endpoints 3FFE:2900:B:C::2/64 (our side) and 3FFE:2900:B:C::1/64 (Sprint side). Our tunnel to Canterbury has endpoints 3FFE:2900:FFE1::2/127 (our side) and 3FFE:2900:FFE1::3/127 (Canty side). I have delegated 3FFE:2900:FFE1:1::0/64 to Canterbury, and they are advertising it to us using BGP4+ with origin 9432. We are sending Canterbury a full route table, and are filtering what they are sending us (restricting to just 3FFE:2900:FFE1:1::0/64). We are filtering the advertisements we send to Sprint (and others) (restricting to just 3FFE:2900:FFE1::0/48). >From Canterbury's router: o we can ping 3FFE:2900:FFE1::2 (CLEAR's router's tunnel interface) o we can see the full 6bone routing table, including Sprint's /24 o we can get no ping replies from 3FFE:2900:B:C::1 which is Sprint's side of our tunnel to Sprint. >From CLEAR's router: o we can ping 3FFE:2900:FFE1::3 (Canterbury's router's tunnel interface) o we can see the full 6bone routing table, including Sprint's /24 and Canterbury's /64 o we can ping everybody (within reason :) When Canterbury is pinging, I can see the packets on a debug trace on the CLEAR router with source address 3FFE:2900:FFE1::3. I don't see any replies, though. Canterbury's router is a cisco 2514 running (C2500-TIPV6-M), Experimental Version 11.3(19980421:205904) [raj-ipv6 223]. CLEAR's router is a cisco 1603 running (C1600-YIPV6-M), Experimental Version 11.3(19980421:205904) [raj-ipv6 228] Thanks in anticipation, Joe From map@stacken.kth.se Thu Jul 22 03:21:31 1999 From: map@stacken.kth.se (Magnus Ahltorp) Date: 22 Jul 1999 04:21:31 +0200 Subject: Bad routes update In-Reply-To: "Perry E. Metzger"'s message of "20 Jul 1999 19:35:35 -0400" References: <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50> <199907200655.GAA26375@inner.net> <19990720213333.D62668@clear.co.nz> <87btd6uc6w.fsf@jekyll.piermont.com> Message-ID: > > Do you really think that there are only 80000 sites that want to be > > multi-homed? > > Right now, there don't seem to be any real restrictions on the > practice in v4 land other than taste, and yet, we aren't overwhelmed > yet. I suspect that the desire will not expand faster than Moore's > Law. Does Moore's Law increase the number of available AS numbers also? /Magnus From bound@zk3.dec.com Thu Jul 22 06:04:07 1999 From: bound@zk3.dec.com (Jim Bound) Date: Thu, 22 Jul 1999 01:04:07 -0400 Subject: INPUT draft-ietf-ngtrans-harden-00.txt Message-ID: <199907220504.BAA0000031918@sigma.zk3.dec.com> Hi Bob, >If we agree in prinicpal on the draft, and each pTLA implements it in >general, with the goal of a production quality network, we will start to >identify (and force changes on) the unreliable pTLAs. I have spent the evening with the draft on hardening and have given this a lot of thought and just read Steve's mail to the IPng list. I think we need to move forward with the draft, whatever that means, are we talking BCP or Informational? >I believe that a quality production backbone environment is what we are >after now, with most of the testing occurring at sites. I agree and I can't believe anyone can live without sending non-Provider upstream advertisements for now as stated in the harden draft. I think this is fine for now. >We have had little or no comment on Rob's Hardening draft to date, so I >would encourage everyone to read it, make comments and improvements to it >(to the list please). > I think its an excellent piece of work and document to read. Very well structured and very clear on what the rules are so all the pTLAs and the pNLAs should be pretty clear on what filtering means. If one does not know what lead and filltering means then they should not be implementing the draft most likely. So it might be good up front to say the background a reader should have to read this draft, if customer X picks it up because they are reading all the IPv6 specs (and some do) they might want a hint that they should get their network operator folks to parse this spec if they are not of that discipline. Its intuitive to me being around IPv6 and the GSE meetings and discussions and I have a bias to favor |absolute| aggregation as I did in those discussions. But it might be nice to add a paragraph on what that means as some of the intense discussion was willing to give up aggregation to solve a need rather quickly IMO. My head jerked on not advertising link-local addresses in an IGP at first because we need to survive renumbering in an IGP as we test that function. But we do permit adv's of sitelocal addresses and that will work too. For the case where all the prefixes are really dead at a site and new ones were not provided during the renumbering phase fast enough through some SNAFU or something via administration at the border routers. In that case sitelocal addresses will be very useful. I have not looked at the OSPFv6 stuff for awhile but it used to provide linklocal addresses to adjacent nodes. So I am not sure this applies or still the case as OSPFv6 was not in the hardening draft. But I will check eventually. I also think the authors did a good job of focusing on where this applies. My input is its fine and we should move on here. Good Job to you and the authors, /jim From peter@jazz-1.trumpet.com.au Thu Jul 22 06:22:17 1999 From: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Thu, 22 Jul 1999 15:22:17 +1000 (EST) Subject: Bad routes update In-Reply-To: <19990721165514F.masaki@merit.edu> Message-ID: On Wed, 21 Jul 1999, Masaki Hirabaru wrote: > >> ->2) There are a lot of route flapping even within the valid pTLA > >> ->space. A long time ago, I tried to figure out the origins, but I > >> ->gave up to continue it for all the occasions. It keeps happening. > >> > >> If we aggregate, I think we will see this diminish. many routes that flap > >> come from statics that point to interfaces that go down, etc... If we > >> aggregate, we won't see the affects of these, except in the case of yoru > >> IBGP, where you will want your own specifics. > > I don't think that most of the flapping on 6bone comes from > interface up/down. And, pTLA routes are flapping, so we can not > diminish them by aggregation. My guess it's a result of having to use tunnels over Ipv4. Some of the Ipv4 network is unstable IMHO, and this could be reflected into the 6bone. I don't think this is coincidental as I suspect that a significant body of users deploying IPv6 are doing so because of their own perceived instability of IPv4 services. We for one experience this - our backbone provider won't give us an honest answer as to what the problem is, and is indicative of the way things really are. For some regions, choice of backbone provider is limited too, so letting the market decide is not a complete answer. Peter > > >> ->3) There are a couple of strange routes outside the 6bone pTLA > >> ->space drafting over the 6bone. We could get it covered by > >> ->imposing the routing policy rather than solving the real problem. > >> > >> Filter them. That way, they will be gone. If you look closely enough, you > >> can see 10/8 v4 space around. You just have to filter it at your edges to > >> make sure it doesn't affect anyone. While I would personally like for these > >> people to fix the problem, in this case, you can only control your own > >> routing domain, thus going around them with a filter would be just as > >> handy, and effectively the same thing. > > Let me explain how they are strange. They have a strange as path > and are flapping. It would indicate something wrong on 6bone. > > If the routing policy intends to solve the current 6bone routing > issues, it would not work. It will just decrease the size of > routing table but may introduce another complexity that may make > it harder to catch the real problems. > > Masaki > -- 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 sponkane@cc.hut.fi Thu Jul 22 08:13:12 1999 From: sponkane@cc.hut.fi (Sami P) Date: Thu, 22 Jul 1999 10:13:12 +0300 (EET DST) Subject: Could someone give me a hand with this? In-Reply-To: <19990722125634.A93744@clear.co.nz> Message-ID: On Thu, 22 Jul 1999, Joe Abley wrote: > Hi all, > > If someone could let me know how this looks from ourside our AS, I'd > be very grateful. In particular, could people could let me know whether > they can ping the following addresses? > > 3FFE:2900:FFE1::0 > 3FFE:2900:B:C::2 > 3FFE:2900:FFE1::2 > 3FFE:2900:FFE1::3 > 3FFE:2900:FFE1:1::1 Hi, The first three addresses reply to a ping but the rest do not. Sami PING 3FFE:2900:FFE1::0 (3ffe:2900:ffe1::): 56 data bytes 64 bytes from 3ffe:2900:ffe1::: icmp_seq=0 ttl=252 time=982.49 ms 64 bytes from 3ffe:2900:ffe1::: icmp_seq=1 ttl=252 time=977.427 ms 64 bytes from 3ffe:2900:ffe1::: icmp_seq=2 ttl=252 time=991.973 ms 64 bytes from 3ffe:2900:ffe1::: icmp_seq=3 ttl=252 time=978.168 ms 64 bytes from 3ffe:2900:ffe1::: icmp_seq=4 ttl=252 time=980.387 ms --- 3FFE:2900:FFE1::0 ping statistics --- 6 packets transmitted, 5 packets received, 16% packet loss round-trip min/avg/max = 977.427/982.088/991.973 ms PING 3FFE:2900:B:C::2 (3ffe:2900:b:c::2): 56 data bytes 64 bytes from 3ffe:2900:b:c::2: icmp_seq=0 ttl=252 time=995.445 ms 64 bytes from 3ffe:2900:b:c::2: icmp_seq=1 ttl=252 time=733.917 ms 64 bytes from 3ffe:2900:b:c::2: icmp_seq=2 ttl=252 time=737.607 ms 64 bytes from 3ffe:2900:b:c::2: icmp_seq=3 ttl=252 time=751.693 ms 64 bytes from 3ffe:2900:b:c::2: icmp_seq=4 ttl=252 time=753.953 ms --- 3FFE:2900:B:C::2 ping statistics --- 6 packets transmitted, 5 packets received, 16% packet loss round-trip min/avg/max = 733.917/794.523/995.445 ms PING 3FFE:2900:FFE1::2 (3ffe:2900:ffe1::2): 56 data bytes 64 bytes from 3ffe:2900:ffe1::2: icmp_seq=0 ttl=252 time=982.57 ms 64 bytes from 3ffe:2900:ffe1::2: icmp_seq=1 ttl=252 time=994.346 ms 64 bytes from 3ffe:2900:ffe1::2: icmp_seq=2 ttl=252 time=1072.11 ms 64 bytes from 3ffe:2900:ffe1::2: icmp_seq=3 ttl=252 time=1005.99 ms --- 3FFE:2900:FFE1::2 ping statistics --- 5 packets transmitted, 4 packets received, 20% packet loss round-trip min/avg/max = 982.57/1013.75/1072.11 ms PING 3FFE:2900:FFE1::3 (3ffe:2900:ffe1::3): 56 data bytes --- 3FFE:2900:FFE1::3 ping statistics --- 13 packets transmitted, 0 packets received, 100% packet loss PING 3FFE:2900:FFE1:1::1 (3ffe:2900:ffe1:1::1): 56 data bytes --- 3FFE:2900:FFE1:1::1 ping statistics --- 20 packets transmitted, 0 packets received, 100% packet loss From milek@rudy.mif.pg.gda.pl Thu Jul 22 10:55:57 1999 From: milek@rudy.mif.pg.gda.pl (Robert Milkowski) Date: Thu, 22 Jul 1999 11:55:57 +0200 (CEST) Subject: Could someone give me a hand with this? In-Reply-To: <19990722125634.A93744@clear.co.nz> Message-ID: On Thu, 22 Jul 1999, Joe Abley wrote: > If someone could let me know how this looks from ourside our AS, I'd > be very grateful. In particular, could people could let me know whether > they can ping the following addresses? > > 3FFE:2900:FFE1::0 ok > 3FFE:2900:B:C::2 ok > 3FFE:2900:FFE1::2 ok > 3FFE:2900:FFE1::3 no response > 3FFE:2900:FFE1:1::1 no response ------------------------------------------------------------------------------- A1240D 18MB EDO RAM + HD 2.5GB + CD +... Student of mail to: milek@rudy.mif.pg.gda.pl Technical University of Gdansk Happy owner of Amiga Milek Faculty of Applied Physics ------------------------------------------------------------------------------- From perry@piermont.com Thu Jul 22 14:43:41 1999 From: perry@piermont.com (Perry E. Metzger) Date: 22 Jul 1999 09:43:41 -0400 Subject: Bad routes update In-Reply-To: Magnus Ahltorp's message of "22 Jul 1999 04:21:31 +0200" References: <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50> <199907200655.GAA26375@inner.net> <19990720213333.D62668@clear.co.nz> <87btd6uc6w.fsf@jekyll.piermont.com> Message-ID: <87n1wo6bqq.fsf@jekyll.piermont.com> Magnus Ahltorp writes: > > > Do you really think that there are only 80000 sites that want to be > > > multi-homed? > > > > Right now, there don't seem to be any real restrictions on the > > practice in v4 land other than taste, and yet, we aren't overwhelmed > > yet. I suspect that the desire will not expand faster than Moore's > > Law. > > Does Moore's Law increase the number of available AS numbers also? No, but we can deploy a new external gateway protocol with a 32 or 64 bit AS space far more easily than we can deploy a new version of IP. I've seen external routing protocols come and go over the the years... Perry From fink@es.net Fri Jul 23 01:49:32 1999 From: fink@es.net (Bob Fink) Date: Thu, 22 Jul 1999 17:49:32 -0700 Subject: INPUT draft-ietf-ngtrans-harden-00.txt In-Reply-To: <199907220504.BAA0000031918@sigma.zk3.dec.com> Message-ID: <4.1.19990722082802.01df52b0@imap2.es.net> Jim, Thanks for your comments. The draft is intended to replace the current RFC 2546 on 6bone routing practice which is informational. Bob === At 01:04 AM 7/22/99 -0400, Jim Bound wrote: >Hi Bob, > >>If we agree in prinicpal on the draft, and each pTLA implements it in >>general, with the goal of a production quality network, we will start to >>identify (and force changes on) the unreliable pTLAs. > >I have spent the evening with the draft on hardening and have given this >a lot of thought and just read Steve's mail to the IPng list. I think >we need to move forward with the draft, whatever that means, are we >talking BCP or Informational? > >>I believe that a quality production backbone environment is what we are >>after now, with most of the testing occurring at sites. > >I agree and I can't believe anyone can live without sending non-Provider >upstream advertisements for now as stated in the harden draft. I think >this is fine for now. > >>We have had little or no comment on Rob's Hardening draft to date, so I >>would encourage everyone to read it, make comments and improvements to it >>(to the list please). > >> > >I think its an excellent piece of work and document to read. Very well >structured and very clear on what the rules are so all the pTLAs and the >pNLAs should be pretty clear on what filtering means. If one does not >know what lead and filltering means then they should not be implementing >the draft most likely. So it might be good up front to say the >background a reader should have to read this draft, if customer X picks >it up because they are reading all the IPv6 specs (and some do) they >might want a hint that they should get their network operator folks to >parse this spec if they are not of that discipline. > >Its intuitive to me being around IPv6 and the GSE meetings and >discussions and I have a bias to favor |absolute| aggregation as I did >in those discussions. But it might be nice to add a paragraph on what >that means as some of the intense discussion was willing to give up >aggregation to solve a need rather quickly IMO. > >My head jerked on not advertising link-local addresses in an IGP at first >because we need to survive renumbering in an IGP as we test that function. >But we do permit adv's of sitelocal addresses and that will work too. >For the case where all the prefixes are really dead at a site and new >ones were not provided during the renumbering phase fast enough through >some SNAFU or something via administration at the border routers. In >that case sitelocal addresses will be very useful. > >I have not looked at the OSPFv6 stuff for awhile but it used to provide >linklocal addresses to adjacent nodes. So I am not sure this applies or >still the case as OSPFv6 was not in the hardening draft. But I will >check eventually. > >I also think the authors did a good job of focusing on where this >applies. > >My input is its fine and we should move on here. > >Good Job to you and the authors, >/jim > From jabley@clear.co.nz Fri Jul 23 04:14:29 1999 From: jabley@clear.co.nz (Joe Abley) Date: Fri, 23 Jul 1999 15:14:29 +1200 Subject: General cisco ipv6 discussions Message-ID: <19990723151422.B2626@clear.co.nz> Hi, I'm still trying to track down this illusive Canterbury problem, and I have some cisco specific questions. Rather than pollute the 6bone list with such vendor-specific trivia, could someone perhaps point me towards an appropriate cisco forum? Is there a list somewhere where IOS ipv6 questions are on-topic? Sorry about the noise, Joe From ntle@vnn.vn Fri Jul 23 06:59:59 1999 From: ntle@vnn.vn (Thanh Le) Date: Fri, 23 Jul 1999 12:59:59 +0700 Subject: Dial-up in IPV6 , Message-ID: <379804DF.C61FB0CC@vnn.vn> Hi all, I want my clients using PPP to connect to our network that supports IPV6. If someone could let me know if there is an access server software (like tacacs or Radius ) supported IPV6, I'd be very grateful. In particular, could people could let me know whether I can get the documents related this topic ?. Thanks very much for your response. Nguyen Thanh Le. From mmcnealis@cisco.com Fri Jul 23 07:36:26 1999 From: mmcnealis@cisco.com (Martin McNealis) Date: Thu, 22 Jul 1999 23:36:26 -0700 Subject: General cisco IPv6 discussions In-Reply-To: <19990723151422.B2626@clear.co.nz> Message-ID: <199907230641.XAA10228@mailman.cisco.com> Hi Joe, Please direct your questions on Cisco IOS IPv6 support to myself and "ipv6-support@cisco.com". Cheers, -Martin- At 03:14 PM 7/23/99 +1200, Joe Abley wrote: >Hi, > >I'm still trying to track down this illusive Canterbury problem, and >I have some cisco specific questions. > >Rather than pollute the 6bone list with such vendor-specific trivia, >could someone perhaps point me towards an appropriate cisco forum? Is >there a list somewhere where IOS ipv6 questions are on-topic? > >Sorry about the noise, > > >Joe > From christian.jacquenet@cnet.francetelecom.fr Fri Jul 23 07:53:03 1999 From: christian.jacquenet@cnet.francetelecom.fr (JACQUENET Christian CNET/DSE/CAE) Date: Fri, 23 Jul 1999 08:53:03 +0200 Subject: General cisco ipv6 discussions Message-ID: <00DC997FEFAFD21192D800A024D43F4D43B436@c-mhs.caen.cnet.fr> Hi, Let me suggest you try this list : ipv6-deployment@external.cisco.com Best regards, Christian. _________________ ________ ______ ______ /_____________ /__ /_ _ / / / / / Christian "I'm a ZZ Fan" Jacquenet /_________/ / / / / / / / / /__/ France Telecom CNET DSE/SPI / / /___/__/___/_____/_/__/____ "I was born my papa's son, /__/ /__________________________/_ 'til I hit the ground, I was on the run." /_______________________________/ - Just got paid. -----Message d'origine----- De: Joe Abley [mailto:jabley@clear.co.nz] Date: vendredi 23 juillet 1999 05:14 À: 6bone@ISI.EDU Cc: Kerry Baker Objet: General cisco ipv6 discussions Hi, I'm still trying to track down this illusive Canterbury problem, and I have some cisco specific questions. Rather than pollute the 6bone list with such vendor-specific trivia, could someone perhaps point me towards an appropriate cisco forum? Is there a list somewhere where IOS ipv6 questions are on-topic? Sorry about the noise, Joe From jabley@clear.co.nz Fri Jul 23 09:03:29 1999 From: jabley@clear.co.nz (Joe Abley) Date: Fri, 23 Jul 1999 20:03:29 +1200 Subject: Could someone give me a hand with this? In-Reply-To: <19990722125634.A93744@clear.co.nz>; from Joe Abley on Thu, Jul 22, 1999 at 12:56:35PM +1200 References: <19990722125634.A93744@clear.co.nz> Message-ID: <19990723200329.F44637@clear.co.nz> On Thu, Jul 22, 1999 at 12:56:35PM +1200, Joe Abley wrote: > I have just been working with Canterbury University here in NZ trying > to get them connected to the 6bone -- everything is looking good between > us and them, but they seem to be having problems getting traffic from > the rest of the network routed back to them. Thanks very much to everybody for their assistance in this. The problem turned out to be that I hadn't entered "ipv6 unicast-routing" on my router, which is evidently a mistake on an ipv6 unicast router ;) How embarassing. Never mind. Joe From masaki@merit.edu Fri Jul 23 11:33:14 1999 From: masaki@merit.edu (Masaki Hirabaru) Date: Fri, 23 Jul 1999 06:33:14 -0400 Subject: Bad routes update In-Reply-To: References: <19990721165514F.masaki@merit.edu> Message-ID: <19990723063314E.masaki@merit.edu> >> > I don't think that most of the flapping on 6bone comes from >> > interface up/down. And, pTLA routes are flapping, so we can not >> > diminish them by aggregation. >> >> My guess it's a result of having to use tunnels over Ipv4. Some of the Ipv4 >> network is unstable IMHO, and this could be reflected into the 6bone. I don't >> think this is coincidental as I suspect that a significant body of users >> deploying IPv6 are doing so because of their own perceived instability of IPv4 >> services. We for one experience this You mean that IPv4 networks even among pTLAs are unstable. There was a case that an unstable IPv4 connection caused an excessive BGP updates on 6bone. If your connection is too unstable to keep the BGP/TCP connection (for example, it closes by error every few minutes), I'm afraid that it may affect 6bone backbone routing. If you are not a pTLA, aggregation will eliminate flapping. If you are a pTLA, have mesh connections with other pTLAs, and act as a transit as requested, your unstable connection will affect other 6bone people as well as you. Among pTLAs on 6bone, we have mesh connections regardless of the IPv4 physical topology, so IPv6 traffic even within US could travel through Japan, Europe, or your country where pTLA exists. Masaki >> From: Peter Tattam >> Subject: Re: Bad routes update >> Date: Thu, 22 Jul 1999 15:22:17 +1000 (EST) >> Message-ID: >> >> On Wed, 21 Jul 1999, Masaki Hirabaru wrote: >> >> > >> ->2) There are a lot of route flapping even within the valid pTLA >> > >> ->space. A long time ago, I tried to figure out the origins, but I >> > >> ->gave up to continue it for all the occasions. It keeps happening. >> > >> >> > >> If we aggregate, I think we will see this diminish. many routes that flap >> > >> come from statics that point to interfaces that go down, etc... If we >> > >> aggregate, we won't see the affects of these, except in the case of yoru >> > >> IBGP, where you will want your own specifics. >> > >> > I don't think that most of the flapping on 6bone comes from >> > interface up/down. And, pTLA routes are flapping, so we can not >> > diminish them by aggregation. >> >> My guess it's a result of having to use tunnels over Ipv4. Some of the Ipv4 >> network is unstable IMHO, and this could be reflected into the 6bone. I don't >> think this is coincidental as I suspect that a significant body of users >> deploying IPv6 are doing so because of their own perceived instability of IPv4 >> services. We for one experience this - our backbone provider won't give us an >> honest answer as to what the problem is, and is indicative of the way things >> really are. For some regions, choice of backbone provider is limited too, so >> letting the market decide is not a complete answer. >> >> Peter >> >> > >> > >> ->3) There are a couple of strange routes outside the 6bone pTLA >> > >> ->space drafting over the 6bone. We could get it covered by >> > >> ->imposing the routing policy rather than solving the real problem. >> > >> >> > >> Filter them. That way, they will be gone. If you look closely enough, you >> > >> can see 10/8 v4 space around. You just have to filter it at your edges to >> > >> make sure it doesn't affect anyone. While I would personally like for these >> > >> people to fix the problem, in this case, you can only control your own >> > >> routing domain, thus going around them with a filter would be just as >> > >> handy, and effectively the same thing. >> > >> > Let me explain how they are strange. They have a strange as path >> > and are flapping. It would indicate something wrong on 6bone. >> > >> > If the routing policy intends to solve the current 6bone routing >> > issues, it would not work. It will just decrease the size of >> > routing table but may introduce another complexity that may make >> > it harder to catch the real problems. >> > >> > Masaki >> > >> >> -- >> 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 masaki@merit.edu Fri Jul 23 11:38:48 1999 From: masaki@merit.edu (Masaki Hirabaru) Date: Fri, 23 Jul 1999 06:38:48 -0400 Subject: Bad routes update In-Reply-To: <4.1.19990720110647.020d3de0@imap2.es.net> References: <19990720213333.D62668@clear.co.nz> <874sizzalm.fsf@jekyll.piermont.com> <4.1.19990720110647.020d3de0@imap2.es.net> <4.1.19990720110647.020d3de0@imap2.es.net>,<4.1.19990720110647.020d3de0@imap2.es.net>,<4.1.19990720110647.020d3de0@imap2.es.net> Message-ID: <19990723063848U.masaki@merit.edu> >> So to the first order what Rob has proposed (and presented to the list and >> in Oslo) are good engineering procedures to make a useful 6bone backone for >> reliable operation. My comments on draft-ietf-ngtrans-harden-00.txt: < 3.9 Inter-site links < Global IPv6 addresses must be used for the end points of < inter-site links. In particular, IPv4 compatible addresses < MUST NOT be used for tunnels. < Prefixes for inter-site links MUST NOT be injected in the < global routing tables. 1) I don't understand why this has to be mentioned. There may be a inter-site link without global addresses. I think that this is a matter local to the peers, and we don't have to limit possible solutions. 2) This document focuses on prefixes so I'm not sure this should be included: a pTLA should use the RFC version of BGP4+ (RFC??). < 4. Routing Policies >> Secondarily, we have a role related to the IPv6 development and standards >> community to provide a viable testbed (proving ground) for ideas related to >> future backbone operation. Having a coordinated effort to support this is >> very important. >> >> Everyone has recognized the problem with multi-homing in v6 for quite a >> while, especially those folk participating in the IPng WG for the last few >> years. I would generally characterize their view about the multi-homing >> problem as it being a very hard problem, yet necessary to tackle or we will >> have every /48 v6 prefix propagated in everyone's routing table. >> >> So what to do. First and foremost, the IPng community is now focusing on >> the multi-homing problem. There was a small team that decided to tackle it >> between Minneapolis and Oslo, offline to the WG, who then reported on their >> efforts to the IPng WG last week in Oslo. It is now viewed by the IPng WG >> as the highest priority work going on and there will be a multi-day IPng >> interim meeting on it before the Washington IETF meeting. Stay tuned to the >> ipng list for reports and info on all this. >> >> So, we need a 6bone that helps with this effort in the best way possible. I >> believe that this means we agree to operate the 6bone backbone with rules >> that are consistent with the current agreed IPng WG procedures as opposed >> to just polluting our routing tables with everyones' routes. >> >> Certainly one model for the 6bone (often suggested, I believe) is one of >> real world operation (and competition) determining how it will work. I can >> see that model possibly working in a real thriving fee for service >> competitive IPv6 ISP world but we aren't even close to that point yet. >> Also, we are less clear on many solutions to our problems yet, which is why >> IPng work is underway on multihoming. So we need some discipline and method >> to what we will try to do on the 6bone backbone. >> >> >> Thus I propose that we, for now, implement Rob's proposed hardening rules >> and don't try solve the multihoming issue by ad hoc methods for now. Then >> we review the current ideas and proposals coming out of the IPng WG on this >> over the next several months and entertain proposals for modifications to >> our operating policies as necessary to try out new multihoming techniques >> on the larger scale 6bone backbone. I definitely believe that to just allow >> all routes to be accepted will lead to problems and certainly not to any >> good long term solutions. 3) About multi-homing. As you mentioned the current agreed IPng WG procedures, is limiting to /24 and /28 a requirement that comes from IPng WG? Or, is it expressing that 6bone doesn't accept any other solutions which may require even a little bit relaxed rules? I personally agree to pursue solutions that conform to this routing policy, but I think that the discussion/deployment is still on-going in IPng WG. I'd like to clarify the position of 6bone. Thanks, Masaki From cmetz@inner.net Fri Jul 23 18:59:30 1999 From: cmetz@inner.net (Craig Metz) Date: Fri, 23 Jul 1999 13:59:30 -0400 Subject: Bad routes update In-Reply-To: Your message of "22 Jul 1999 09:43:41 EDT." <87n1wo6bqq.fsf@jekyll.piermont.com> Message-ID: <199907231757.RAA01253@inner.net> In message <87n1wo6bqq.fsf@jekyll.piermont.com>, you write: >No, but we can deploy a new external gateway protocol with a 32 or 64 >bit AS space far more easily than we can deploy a new version of >IP. I've seen external routing protocols come and go over the the >years... Perhaps one of the real routing geeks can comment better than I can on this issue, but I have been told by several routing geeks who know what they're talking about that the world is currently fairly locked into BGP4; any new protocols or even major changes to BGP4 run into big deployment problems. So IMO more likely that more aggressive ASN space management would come before the number space problem gets fixed. -Craig From perry@piermont.com Fri Jul 23 19:09:10 1999 From: perry@piermont.com (Perry E. Metzger) Date: 23 Jul 1999 14:09:10 -0400 Subject: Bad routes update In-Reply-To: Craig Metz's message of "Fri, 23 Jul 1999 13:59:30 -0400" References: <199907231757.RAA01253@inner.net> Message-ID: <87d7xj9r21.fsf@jekyll.piermont.com> Craig Metz writes: > In message <87n1wo6bqq.fsf@jekyll.piermont.com>, you write: > >No, but we can deploy a new external gateway protocol with a 32 or 64 > >bit AS space far more easily than we can deploy a new version of > >IP. I've seen external routing protocols come and go over the the > >years... > > Perhaps one of the real routing geeks can comment better than I can on this > issue, but I have been told by several routing geeks who know what they're > talking about that the world is currently fairly locked into BGP4; any new > protocols or even major changes to BGP4 run into big deployment problems. So > IMO more likely that more aggressive ASN space management would come before > the number space problem gets fixed. Although I can't possibly imagine a world where we'll need four billion ASes, I can easily imagine one where we need two hundred thousand, which certainly exceeds 16 bits. Perhaps, given that IPv6 is not yet widely deployed, this would be the time to expand the width of that field, if only in an IPv6 context, so that we won't have to worry in five or ten years. Perry From cmetz@inner.net Fri Jul 23 19:13:27 1999 From: cmetz@inner.net (Craig Metz) Date: Fri, 23 Jul 1999 14:13:27 -0400 Subject: Bad routes update In-Reply-To: Your message of "23 Jul 1999 14:09:10 EDT." <87d7xj9r21.fsf@jekyll.piermont.com> Message-ID: <199907231811.SAA01331@inner.net> In message <87d7xj9r21.fsf@jekyll.piermont.com>, you write: >Although I can't possibly imagine a world where we'll need four >billion ASes, I can easily imagine one where we need two hundred >thousand, which certainly exceeds 16 bits. Remember that an AS more or less represents an independent inter-domain routing policy. I suspect that there are other complexity reasons why more than 15k independent inter-domain routing policies would be a Bad Thing, making the number space not as much of a problem. I'm no BGP expert. Hopefully, someone who is will step up and clarify. -Craig From perry@piermont.com Fri Jul 23 19:20:48 1999 From: perry@piermont.com (Perry E. Metzger) Date: 23 Jul 1999 14:20:48 -0400 Subject: Bad routes update In-Reply-To: Craig Metz's message of "Fri, 23 Jul 1999 14:13:27 -0400" References: <199907231811.SAA01331@inner.net> Message-ID: <8790879qin.fsf@jekyll.piermont.com> Craig Metz writes: > In message <87d7xj9r21.fsf@jekyll.piermont.com>, you write: > >Although I can't possibly imagine a world where we'll need four > >billion ASes, I can easily imagine one where we need two hundred > >thousand, which certainly exceeds 16 bits. > > Remember that an AS more or less represents an independent inter-domain > routing policy. I suspect that there are other complexity reasons why more than > 15k independent inter-domain routing policies would be a Bad Thing, making the > number space not as much of a problem. > > I'm no BGP expert. Hopefully, someone who is will step up and clarify. I think that we're thinking way too small. I'm sure that number would be bad NOW, but will it be bad in fifteen years, when lightbulbs will have more compute power than high end PCs do now? Best not to limit the future overmuch. Perry From majdi@puck.nether.net Fri Jul 23 19:48:47 1999 From: majdi@puck.nether.net (Majdi Abbas) Date: Fri, 23 Jul 1999 14:48:47 -0400 (EDT) Subject: Bad routes update In-Reply-To: <199907231811.SAA01331@inner.net> from Craig Metz at "Jul 23, 99 02:13:27 pm" Message-ID: <199907231848.OAA19863@puck.nether.net> > Remember that an AS more or less represents an independent inter-domain > routing policy. I suspect that there are other complexity reasons why more > than 15k independent inter-domain routing policies would be a Bad Thing, > making the number space not as much of a problem. Who cares? I don't care about the other 14k ASNs...I do care about my own. What they do internally -does not matter- because it's outside the scope of BGP...as far as I'm concerned they're just a number. More numbers means more state information to keep track of, but that's true of the growth of the net as a whole. --msa From sumikawa@ebina.hitachi.co.jp Sat Jul 24 08:28:46 1999 From: sumikawa@ebina.hitachi.co.jp (SUMIKAWA Munechika (=?ISO-2022-JP?B?GyRCM1FAbj0hNmEbKEI=?=)) Date: Sat, 24 Jul 1999 16:28:46 +0900 (JST) 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: <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 bound@zk3.dec.com Sat Jul 24 15:47:18 1999 From: bound@zk3.dec.com (Jim Bound) Date: Sat, 24 Jul 1999 10:47:18 -0400 Subject: Bad routes update In-Reply-To: Your message of "Fri, 23 Jul 1999 13:59:30 EDT." <199907231757.RAA01253@inner.net> Message-ID: <199907241447.KAA0000006246@quarry.zk3.dec.com> >>No, but we can deploy a new external gateway protocol with a 32 or 64 >>bit AS space far more easily than we can deploy a new version of >>IP. I've seen external routing protocols come and go over the the >>years... The AS number in BGP4+ is 16bits. /jim From 6bone@fips.de Mon Jul 26 11:44:21 1999 From: 6bone@fips.de (Philipp Buehler) Date: Mon, 26 Jul 1999 12:44:21 +0200 Subject: New subscriber Message-ID: <19990726124421.A11346@taubenschlag.ttt.de> Hi subscribed yesterday to this list, and .. nothing? Seems to be pretty low traffic. Anyway, whish to connect to 6bone after some more testing with cisco and linux. I live in Cologne, Germany.. possible the main- tainer of uni-koeln is reading this also? Would be a join there possible for a private person? (Back to some more reading on 6bone.ner ;-) ) ciao -- Philipp Buehler, aka fIpS | BOfH | NUCH | double-p on IRC VAX/OpenVMS: 24/365 No compromise computing. "...submit yourself to new rules - get used to a set of new tools - Vortex" --Krupps, 1997 From bruce.campbell@apnic.net Wed Jul 28 09:54:24 1999 From: bruce.campbell@apnic.net (Bruce Campbell) Date: Wed, 28 Jul 1999 18:54:24 +1000 (EST) Subject: How do I get Off This List? In-Reply-To: <01bedbb6$8500b720$33008bd1@l> Message-ID: On Sat, 31 Jul 1999, Bruce Ballaban wrote: beam> I need to get off this list. Can somebody please tell me what to do? -- Welcome to the 6bone mailing list! If you ever want to remove yourself from this mailing list, send the following command in email to "6bone-request@zephyr.isi.edu": unsubscribe Or you can send mail to "majordomo@zephyr.isi.edu" with the following command in the body of your email message: unsubscribe 6bone From ksbn@kt.co.kr Wed Jul 28 10:42:42 1999 From: ksbn@kt.co.kr (ksb) Date: Wed, 28 Jul 1999 18:42:42 +0900 Subject: URL Message-ID: <379ED092.D5A68507@kt.co.kr> Dear members: If you are still running http servers for IPv6, please send me the URL address. Sincerely, -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- From bmanning@ISI.EDU Wed Jul 28 16:59:48 1999 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Wed, 28 Jul 1999 08:59:48 -0700 (PDT) Subject: BOUNCE 6bone@zephyr.isi.edu: Non-member submission from [phantom ] (fwd) Message-ID: <199907281559.AA24128@zed.isi.edu> >From bmanning@ISI.EDU Wed Jul 28 05:51:15 1999 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id FAA25657 for ; Wed, 28 Jul 1999 05:51:15 -0700 (PDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA20421; Wed, 28 Jul 1999 05:51:15 -0700 (PDT) Date: Wed, 28 Jul 1999 05:51:15 -0700 (PDT) Message-Id: <199907281251.FAA20421@zephyr.isi.edu> To: owner-6bone@ISI.EDU From: owner-6bone@ISI.EDU Subject: BOUNCE 6bone@zephyr.isi.edu: Non-member submission from [phantom ] >From 6bone-owner@ISI.EDU Wed Jul 28 05:51:10 1999 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 FAA20415 for <6bone@zephyr.isi.edu>; Wed, 28 Jul 1999 05:51:09 -0700 (PDT) Received: from hermes.tconl.com (root@mail.tconl.com [204.26.80.9]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA11563 for <6bone@isi.edu>; Wed, 28 Jul 1999 05:51:08 -0700 (PDT) Received: from san ([10.42.0.16]) by hermes.tconl.com (8.9.3/TeleChoice) with SMTP id HAA08807 for <6bone@isi.edu>; Wed, 28 Jul 1999 07:51:07 -0500 Received: by localhost with Microsoft MAPI; Wed, 28 Jul 1999 07:56:56 -0500 Message-ID: <01BED8CE.C31A35D0.phantom@tconl.com> From: phantom To: "'6bone@isi.edu'" <6bone@ISI.EDU> Subject: Transmission of IPv6 Packets over Wireless Medium Call Sign WLW-992 Date: Wed, 28 Jul 1999 07:56:54 -0500 Organization: IETC X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 22 TEXT Hello Sir I would like your assistance in a Test TLA Assignment for our Broadcast Station WLW-992 This is Private radio spectrum allocated by the FCC. The station is in Omaha, NE. I have been running various datagram tests over the last 9 months on this station. The application is (laptop mobile) and fixed transceiver facilities(i.e. ISP's) I am reviewing what all will be involved in refitting this broadcast facility for IPv6. I have been studying the 6bone site which I might add is quit helpful. I would like to connect this facility to the Chicago 6bone facility Any assistance you would provide would be greatly appreciated Best Regards Ron I can be reached by e-mail or phone (402)290-9000 -- "When in doubt, Twirl..." -anon From evecchio@thomsys.com.ar Thu Jul 29 17:42:19 1999 From: evecchio@thomsys.com.ar (Emanuel Vecchio) Date: Thu, 29 Jul 1999 16:42:19 -0000 Subject: IOS with IPv6 enable. Message-ID: <01BED9E1.539AB770@EVECCHIO> hi dears Can somebody please tell me where i can get the Cisco IOS with ipv6 enable? Emanuel Vecchio Research & Development Thomson-CSF Systems Argentina S.A. Bulnes 2756 (1425) Buenos Aires Tel.:(+54 11) 4801-8170 (L.Rot.) Fax:(+54 11) 4801-8214 From ot@cisco.com Thu Jul 29 21:33:49 1999 From: ot@cisco.com (Ole Troan) Date: Thu, 29 Jul 1999 22:33:49 +0200 Subject: IOS with IPv6 enable. In-Reply-To: Message from Emanuel Vecchio of "Thu, 29 Jul 1999 16:42:19 -0000." <01BED9E1.539AB770@EVECCHIO> Message-ID: <199907292133.WAA27224@otroan-u5.cisco.com> > Can somebody please tell me where i can get the Cisco IOS with ipv6 enable? http://www.cisco.com/ipv6/ Ole From yjchui@ms.chttl.com.tw Fri Jul 30 01:44:30 1999 From: yjchui@ms.chttl.com.tw (Yann-Ju Chu) Date: Fri, 30 Jul 1999 08:44:30 +0800 Subject: IOS with IPv6 enable. References: <01BED9E1.539AB770@EVECCHIO> Message-ID: <37A0F56E.2BABDAE@ms.chttl.com.tw> Emanuel Vecchio wrote: > > hi dears > > Can somebody please tell me where i can get the Cisco IOS with ipv6 enable? > > Emanuel Vecchio > > Research & Development > Thomson-CSF Systems Argentina S.A. > Bulnes 2756 (1425) Buenos Aires > Tel.:(+54 11) 4801-8170 (L.Rot.) > Fax:(+54 11) 4801-8214 Please refer to http://www.6bone.net/ipv6org/implementations.html Y.J. Chu ChungHwa Telecom. Co. From xavier@euro.net Fri Jul 30 11:42:51 1999 From: xavier@euro.net (Xavier) Date: Fri, 30 Jul 1999 12:42:51 +0200 (MET DST) Subject: mntnr object? Message-ID: FYI, Does somebody help me on this problem?! --- Date: Thu, 29 Jul 1999 01:10:48 -0600 From: 6BONE Database Management To: Xavier Subject: FAILURE: LONGACK Part of your update FAILED > From: Xavier > Subject: LONGACK > Date: Thu, 29 Jul 1999 09:10:36 +0200 (MET DST) > Msg-Id: For help see or include 'help' in the subject line of your message Objects without errors have been processed. New FAILED: [mntner] MNT-EURONET mntner: MNT-EURONET descr: Maintainer of EURONET-BE 6bone registry objects admin-c: XM1-RIPE upd-to: ip6-operator@ipv6.euronet.be mnt-nfy: ip6-operator@ipv6.euronet.be auth: NONE mnt-by: MNT-EURONET changed: xavier@ipv6.euronet.be 19990729 source: 6BONE *ERROR*: 'mntner' objects cannot be created automatically *ERROR*: This object has been forwarded to *ERROR*: for authorisation. *ERROR*: No further action from your part is required -- Xavier Mertens, * * EuroNet Internet Network Operation Center * * a subsidiary of France Telecom XM3-RIPE * From xavier@euro.net Fri Jul 30 13:21:38 1999 From: xavier@euro.net (Xavier) Date: Fri, 30 Jul 1999 14:21:38 +0200 (MET DST) Subject: Reverse mapping? Message-ID: Hi *, Someone has good tips, urls about reverse mapping for IPv6 adresses? X -- Xavier Mertens, * * EuroNet Internet Network Operation Center * * a subsidiary of France Telecom XM3-RIPE * From kaos@ocs.com.au Fri Jul 30 15:51:36 1999 From: kaos@ocs.com.au (Keith Owens) Date: Sat, 31 Jul 1999 00:51:36 +1000 Subject: Reverse mapping? In-Reply-To: Your message of "Fri, 30 Jul 1999 14:21:38 +0200." Message-ID: <19990730145139.10865.qmail@mail.ocs.com.au> On Fri, 30 Jul 1999 14:21:38 +0200 (MET DST), Xavier wrote: >Someone has good tips, urls about reverse mapping for IPv6 adresses? Nothing difficult. Get a version of BIND that understands IPv6 addresses, release 4 has security holes but any release 8 BIND understands AAAA records. My /etc/named.conf contains zone "6.0.0.0.0.0.9.0.e.f.f.3.ip6.int" { type master; file "db.3ffe.0900.0006"; }; File db.3ffe.0900.0006 contains ; ; origin is 6.0.0.0.0.0.9.0.e.f.f.3.ip6.int ; @ IN SOA firewall.ocs.com.au. admin.ocs.com.au. ( 199809301 ; Serial 172800 ; Refresh after 2 days 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day ; ; Name server(s) ; IN NS firewall.ocs.com.au. IN NS mail.ocs.com.au. ; ; Host addresses ; 6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR router-6.ocs.com.au. db.ocs.com.au contains ; ; origin is ocs.com.au ; @ IN SOA firewall.ocs.com.au. admin.ocs.com.au. ( 199809301 ; Serial 172800 ; Refresh after 2 days 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day ; ; Name server(s) ; IN NS firewall.ocs.com.au. IN NS mail.ocs.com.au. ; ; Host addresses ; router-6 IN AAAA 3ffe:900:6::6 To help writing out those long reverse addresses, try ftp://ftp.ocs.com.au/pub/ip6_int.gz. ip6_int 3ffe:900:6::6/48 gives 6.0.0.0.0.0.9.0.e.f.f.3.ip6.int ip6_int 3ffe:900:6::6/-48 gives what is left after removing the first 48 bits, 6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 From fink@es.net Fri Jul 30 16:35:53 1999 From: fink@es.net (Bob Fink) Date: Fri, 30 Jul 1999 08:35:53 -0700 Subject: mntnr object? In-Reply-To: Message-ID: <4.1.19990730083313.009bdbf0@imap2.es.net> Xavier, I have added your mntner object. See below: It is still required that David Kessens or I make 6bone mntner entries, but I hope to soon change this to allow everyone to make these entries themselves. Bob === At 12:42 PM 7/30/99 +0200, Xavier wrote: >FYI, > >Does somebody help me on this problem?! > >--- >Date: Thu, 29 Jul 1999 01:10:48 -0600 >From: 6BONE Database Management >To: Xavier >Subject: FAILURE: LONGACK > >Part of your update FAILED > >> From: Xavier >> Subject: LONGACK >> Date: Thu, 29 Jul 1999 09:10:36 +0200 (MET DST) >> Msg-Id: > >For help see or >include 'help' in the subject line of your message > >Objects without errors have been processed. > >New FAILED: [mntner] MNT-EURONET > >mntner: MNT-EURONET >descr: Maintainer of EURONET-BE 6bone registry objects >admin-c: XM1-RIPE >upd-to: ip6-operator@ipv6.euronet.be >mnt-nfy: ip6-operator@ipv6.euronet.be >auth: NONE >mnt-by: MNT-EURONET >changed: xavier@ipv6.euronet.be 19990729 >source: 6BONE >*ERROR*: 'mntner' objects cannot be created automatically >*ERROR*: This object has been forwarded to > >*ERROR*: for authorisation. >*ERROR*: No further action from your part is required > >-- >Xavier Mertens, * * EuroNet Internet >Network Operation Center * * a subsidiary of France Telecom >XM3-RIPE * From rrockell@sprint.net Fri Jul 30 17:49:15 1999 From: rrockell@sprint.net (Robert Rockell) Date: Fri, 30 Jul 1999 12:49:15 -0400 (EDT) Subject: Bad routes update In-Reply-To: <4.1.19990730090825.009a3960@imap2.es.net> Message-ID: SOrry for the latency on this. ->My comments on draft-ietf-ngtrans-harden-00.txt: -> -> < 3.9 Inter-site links -> -> < Global IPv6 addresses must be used for the end points of -> < inter-site links. In particular, IPv4 compatible addresses -> < MUST NOT be used for tunnels. -> -> < Prefixes for inter-site links MUST NOT be injected in the -> < global routing tables. -> ->1) I don't understand why this has to be mentioned. There may be ->a inter-site link without global addresses. I think that this is ->a matter local to the peers, and we don't have to limit possible ->solutions. -> ->2) This document focuses on prefixes so I'm not sure this should ->be included: a pTLA should use the RFC version of BGP4+ (RFC??). -> I will make sure to add the RFC number. As far as comment #1, I believe that it is technically feasible to use non-standard IPv6 address for inter-site links. I can agree that MUST NOT may need to be changed to SHOULD NOT here. My motiviation for this statement was from a best-practices point of view, rather than a technically-in-order-to-work point of view, so relaxing this si viable. Good comment. -> < 4. Routing Policies -> -> ->3) About multi-homing. As you mentioned the current agreed IPng ->WG procedures, is limiting to /24 and /28 a requirement that ->comes from IPng WG? Or, is it expressing that 6bone doesn't ->accept any other solutions which may require even a little bit ->relaxed rules? I can and have put some verbiage in version 01.txt for this document to relax this, to say that we will operate within current aggregation policy constraints, but that we may change this should it become necessary to test the feasibility of multi-homing solutions. However, I think it very important to operate in the aggregation scheme now, as what people are doing on the 6bone now is NOT a viable solution, but a fundamental break in v6 routing, in order to get around a problem. -> ->I personally agree to pursue solutions that conform to this ->routing policy, but I think that the discussion/deployment is ->still on-going in IPng WG. I'd like to clarify the position of ->6bone. -> ->Thanks, ->Masaki -> From dancer@zeor.simegen.com Sat Jul 31 01:26:39 1999 From: dancer@zeor.simegen.com (Dancer) Date: Sat, 31 Jul 1999 10:26:39 +1000 Subject: mntnr object? References: Message-ID: <37A242BF.9565B04C@zeor.simegen.com> Relax, it's okay. The message is telling you that someone's been notified to do the approval. Since I don't see any other errors offhand, you should get an email back later telling you it's been approved. D Xavier wrote: > > FYI, > > Does somebody help me on this problem?! > > --- > Date: Thu, 29 Jul 1999 01:10:48 -0600 > From: 6BONE Database Management > To: Xavier > Subject: FAILURE: LONGACK > > Part of your update FAILED > > > From: Xavier > > Subject: LONGACK > > Date: Thu, 29 Jul 1999 09:10:36 +0200 (MET DST) > > Msg-Id: > > For help see or > include 'help' in the subject line of your message > > Objects without errors have been processed. > > New FAILED: [mntner] MNT-EURONET > > mntner: MNT-EURONET > descr: Maintainer of EURONET-BE 6bone registry objects > admin-c: XM1-RIPE > upd-to: ip6-operator@ipv6.euronet.be > mnt-nfy: ip6-operator@ipv6.euronet.be > auth: NONE > mnt-by: MNT-EURONET > changed: xavier@ipv6.euronet.be 19990729 > source: 6BONE > *ERROR*: 'mntner' objects cannot be created automatically > *ERROR*: This object has been forwarded to > > *ERROR*: for authorisation. > *ERROR*: No further action from your part is required > > -- > Xavier Mertens, * * EuroNet Internet > Network Operation Center * * a subsidiary of France Telecom > XM3-RIPE * From xavier@euro.net Sat Jul 31 14:09:20 1999 From: xavier@euro.net (Xavier) Date: Sat, 31 Jul 1999 15:09:20 +0200 (MET DST) Subject: Reverse mapping? In-Reply-To: <19990730145139.10865.qmail@mail.ocs.com.au> Message-ID: On Sat, 31 Jul 1999, Keith Owens wrote: > Date: Sat, 31 Jul 1999 00:51:36 +1000 > From: Keith Owens > To: Xavier > Cc: 6bone@ISI.EDU > Subject: Re: Reverse mapping? > > On Fri, 30 Jul 1999 14:21:38 +0200 (MET DST), > Xavier wrote: > >Someone has good tips, urls about reverse mapping for IPv6 adresses? > > Nothing difficult. Get a version of BIND that understands IPv6 > addresses, release 4 has security holes but any release 8 BIND > understands AAAA records. My /etc/named.conf contains > > zone "6.0.0.0.0.0.9.0.e.f.f.3.ip6.int" { > type master; > file "db.3ffe.0900.0006"; > }; [stuff deleted] > ; > ; Host addresses > ; > router-6 IN AAAA 3ffe:900:6::6 > > To help writing out those long reverse addresses, try > ftp://ftp.ocs.com.au/pub/ip6_int.gz. > > ip6_int 3ffe:900:6::6/48 gives 6.0.0.0.0.0.9.0.e.f.f.3.ip6.int > ip6_int 3ffe:900:6::6/-48 gives what is left after removing the first > 48 bits, 6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 Hi Keyth, Thanks for your help! I download your tool and configured my bind. But where do I register that I'm master for the zone '0.0.2.0.1.0.5.2.e.f.f.3.ip6.int' (We have 3ffe:2501:200/48) X -- Xavier Mertens, . . EuroNet Internet Network Operation Center . * a subsidiary of France Telecom XM3-RIPE XM1-6BONE . From bmanning@ISI.EDU Sat Jul 31 22:04:18 1999 From: bmanning@ISI.EDU (Bill Manning) Date: Sat, 31 Jul 1999 14:04:18 -0700 (PDT) Subject: Reverse mapping? In-Reply-To: from "Xavier" at Jul 31, 1999 03:09:20 PM Message-ID: <199907312104.OAA00746@zephyr.isi.edu> > But where do I register that I'm master for the zone > '0.0.2.0.1.0.5.2.e.f.f.3.ip6.int' (We have 3ffe:2501:200/48) > > X > > -- > Xavier Mertens, . . EuroNet Internet Thats easy. Where did you get your delegation? They will provide you the cut point to be master for the delegation they made to you. --bill