From fink@es.net Tue Jul 3 00:33:52 2001 From: fink@es.net (Bob Fink) Date: Mon, 02 Jul 2001 16:33:52 -0700 Subject: 6bone pTLA 3FFE:8250::/28 allocated to NTT-SMC Message-ID: <5.1.0.14.0.20010702163047.04f71af8@imap2.es.net> NTT-SMC in Japan has been allocated pTLA 3FFE:8250::/28 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: Thanks, Bob From peter.lewis@upperside.fr Wed Jul 4 13:17:19 2001 From: peter.lewis@upperside.fr (Peter Lewis) Date: Wed, 4 Jul 2001 14:17:19 +0200 Subject: Deploying IPv6 Networks Message-ID: <004101c10483$4591e260$0601a8c0@oleane.com> This is a multi-part message in MIME format. ------=_NextPart_000_003E_01C10494.08B5FD20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "Deploying IPv6 Networks" international conference, Paris, November = 20-23rd. A call for proposals is on-line at: http://www.upperside.fr/ipv6/deployipv6intro.htm =20 ------=_NextPart_000_003E_01C10494.08B5FD20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
"Deploying IPv6 Networks" international conference, = Paris,=20 November 20-23rd.
A call for proposals is on-line at:
http://www.uppe= rside.fr/ipv6/deployipv6intro.htm
 
------=_NextPart_000_003E_01C10494.08B5FD20-- From fink@es.net Thu Jul 5 01:53:48 2001 From: fink@es.net (Bob Fink) Date: Wed, 04 Jul 2001 17:53:48 -0700 Subject: pTLA request for COMPENDIUM-AR - review closes 18 July 2001 Message-ID: <5.1.0.14.0.20010704174801.03057d30@imap2.es.net> 6bone Folk, COMPENDIUM-AR has requested a pTLA allocation. The open review period for this request will close 18 July 2001. Please send your comments to me or the list. As has been noted by various comments to this list, your comments on these pTLA requests do matter, so please don't hesitate to voice your support or concerns. Thanks, Bob === >Date: Wed, 4 Jul 2001 20:19:20 -0300 >From: horape@tinuviel.compendium.net.ar >To: Bob Fink >Subject: pTLA request > >¡Hola! > >This is a pTLA request for COMPENDIUM-AR. We're a R&D lab and do consulting >on networking in Hispan America (including Spain) > >----- > From RFC 2772: > > 7. Guidelines for 6Bone pTLA sites > > The following rules apply to qualify for a 6Bone pTLA allocation. It > should be recognized that holders of 6Bone pTLA allocations are > expected to provide production quality backbone network services for > the 6Bone. > > 1. The pTLA Applicant must have a minimum of three (3) months > qualifying experience as a 6Bone end-site or pNLA transit. During > the entire qualifying period the Applicant must be operationally > providing the following: > >We're active as a pNLA in the 6bone since early 1999. > > a. Fully maintained, up to date, 6Bone Registry entries for their > ipv6-site inet6num, mntner, and person objects, including each > tunnel that the Applicant has. > >ipv6-site: COMPENDIUM-AR >inet6num: 3FFE:29A1::/32 > > b. Fully maintained, and reliable, BGP4+ peering and connectivity > between the Applicant's boundary router and the appropriate > connection point into the 6Bone. This router must be IPv6 > pingable. This criteria is judged by members of the 6Bone > Operations Group at the time of the Applicant's pTLA request. > >ipv6-gw.compendium.net.ar (3ffe:29a1::201:2ff:febf:1dc1) is >our main IPv6 gateway. > > c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > entries for the Applicant's router(s) and at least one host > system. > >ipv6-gw.compendium.net.ar. 86400 IN AAAA 3ffe:29a1::201:2ff:febf:1dc1 > >Main router. > >tinuviel.compendium.net.ar. 86400 IN AAAA 3ffe:29a1::200:21ff:fe47:2d95 > >DNS and IRC server. > >palermo.compendium.net.ar. 86400 IN AAAA 3ffe:29a1::2e0:7dff:fe83:a68 > >IPv6 only host (lent by Universidad de Palermo for own joint network research >projects) > >Reverse is set up at our DNS server (tinuviel.compendium.net.ar), but Sprint >haven't delegated it yet, so it's non functional. > > d. A fully maintained, and reliable, IPv6-accessible system > providing, at a mimimum, one or more web pages, describing the > Applicant's IPv6 services. This server must be IPv6 pingable. > >http://ipv6-gw.compendium.net.ar/ > > 2. The pTLA Applicant MUST have the ability and intent to provide > "production-quality" 6Bone backbone service. Applicants must > provide a statement and information in support of this claim. > This MUST include the following: > >We have the ability and intent to provide production-quality 6Bone backbone >service. > > a. A support staff of two persons minimum, three preferable, with > person attributes registered for each in the ipv6-site object > for the pTLA applicant. > >person: Horacio Jose Penya >nic-hdl: HJP1-6BONE > >(BTW, it's Peña, not Penya, but the registry don't allow my real name in) > >person: Florencia Ithurralde >nic-hdl: FI-6BONE > > b. A common mailbox for support contact purposes that all support > staff have acess to, pointed to with a notify attribute in the > ipv6-site object for the pTLA Applicant. > >notify: ipv6@compendium.net.ar > > 3. The pTLA Applicant MUST have a potential "user community" that > would be served by its becoming a pTLA, e.g., the Applicant is a > major provider of Internet service in a region, country, or focus > of interest. Applicant must provide a statement and information in > support this claim. > >We've two different potential user communities. > >We work very closely with PuntoAr, a local ISP. They provide dialup and >wireless access. We're planning to start providing their wireless customers >IPv6 connectivity in the next months. > >And, we're organizing Uninet's "IPv6 en Hispanoamérica" project, where we're >promoting IPv6 in the region. We're providing connections to 8 islands in >the region, with 14 more in preparation. > >We've introduced IPv6 in Colombia (by CORUNIVERSITEC university) and are >working on creating new islands in countries where there isn't any 6bone >project yet, as Republica Dominicana, Nicaragua, Cuba and Venezuela. > > 4. The pTLA Applicant MUST commit to abide by the current 6Bone > operational rules and policies as they exist at time of its > application, and agree to abide by future 6Bone backbone > operational rules and policies as they evolve by consensus of the > 6Bone backbone and user community. > >We commit to abide by current and future 6bone operational rules. > >----- > >Saludos, > HoraPe >--- >Horacio J. Peña >horape@compendium.com.ar >horape@uninet.edu >bofh@puntoar.net.ar >horape@hcdn.gov.ar -end From bnilso@csc.com Thu Jul 5 12:11:05 2001 From: bnilso@csc.com (Bo Nilso) Date: Thu, 5 Jul 2001 13:11:05 +0200 Subject: DNS support Message-ID: Hi! Building my first IP v6 test network. Have router, and 3 nodes. In my Solaris( machine, I have the DNS prepared with AAAA records. It responds correctly to queries, but only if the QUERY comes across IPv4. Questions: - How can I get it to respond to DNS lookups (UDP 53) across V6? - Does nslookup in solaris SUPPORT V6? When I say "server f6-6", wich is the same machine, but a name with only the V6 address, it says "Server failed". - Does Linux or FreeBSD have a more complete V6 support for DNS, both server and resolv? /BosseN ----------------------------------------------------------------- AVS: Bo Nilsö, CSC Sweden, Linköping Mail: bnilso@csc.com Phone: +46 (0) 13 465 3631 ------------------------------------------------------------------- From psb@ast.cam.ac.uk Thu Jul 5 14:17:18 2001 From: psb@ast.cam.ac.uk (Peter Bunclark) Date: Thu, 5 Jul 2001 14:17:18 +0100 (BST) Subject: DNS support In-Reply-To: Message-ID: On Thu, 5 Jul 2001, Bo Nilso wrote: > Hi! > > Building my first IP v6 test network. Have router, and 3 nodes. > > In my Solaris( machine, I have the DNS prepared with AAAA records. It > responds correctly to queries, but only if the QUERY comes across IPv4. > > Questions: > > - How can I get it to respond to DNS lookups (UDP 53) across V6? Have you put listen-on-ipv6 in named.conf ? (You _are_ running bind 9.x ?) options { directory "/var/named"; pid-file "/var/named/named.pid"; listen-on-v6 { any; }; ... > > - Does nslookup in solaris SUPPORT V6? When I say "server f6-6", wich is > the same machine, but a name with only the V6 address, it says "Server > failed". # nslookup -q=aaaa hostname > > - Does Linux or FreeBSD have a more complete V6 support for DNS, both > server and resolv? You're not runnind bind 9.x, are you? > > /Bosse Pete. From feico@pasta.cs.uit.no Thu Jul 5 14:44:55 2001 From: feico@pasta.cs.uit.no (Feico Dillema) Date: Thu, 5 Jul 2001 15:44:55 +0200 Subject: DNS support In-Reply-To: ; from bnilso@csc.com on Thu, Jul 05, 2001 at 01:11:05PM +0200 References: Message-ID: <20010705154455.O23160@pasta.cs.uit.no> On Thu, Jul 05, 2001 at 01:11:05PM +0200, Bo Nilso wrote: > - Does Linux or FreeBSD have a more complete V6 support for DNS, both > server and resolv? Yes, NetBSD and FreeBSD have IPv6 support in their resolvers... Am not sure about Linux. Maybe my DNS proxy 'totd' is of use to you to, see: http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html It is not tested on Solaris, so if you have problems just send me an email (linux support will be in the next release). Feico. From ot@cisco.com Thu Jul 5 15:09:17 2001 From: ot@cisco.com (Ole Troan) Date: 05 Jul 2001 15:09:17 +0100 Subject: 5 year anniversary! Message-ID: <7t5r8vv1n8y.fsf@onatopp.cisco.com> please join us in a toast, we've now been connected to the 6bone for 5 years. hopefully there will be no 6bone in another 5. cheers, Ole From alopez@tyr.mty.itesm.mx Fri Jul 6 17:27:55 2001 From: alopez@tyr.mty.itesm.mx (Alfredo Lopez) Date: Fri, 06 Jul 2001 09:27:55 -0700 Subject: pTLA request for COMPENDIUM-AR - review closes 18 July 2001 In-Reply-To: <5.1.0.14.0.20010704174801.03057d30@imap2.es.net> Message-ID: <5.0.0.25.0.20010706092717.02355810@tyr.mty.itesm.mx> 6bone folk compendium-ar has been working to promote the ipv6 use in Latin America. Given the wotk done by COMPENDIUM , I support this request >6bone Folk, > >COMPENDIUM-AR has requested a pTLA allocation. The open review period for >this request will close 18 July 2001. Please send your comments to me or >the list. As has been noted by various comments to this list, your >comments on these pTLA requests do matter, so please don't hesitate to >voice your support or concerns. > > > > > > >Thanks, > >Bob From david@IPRG.nokia.com Mon Jul 9 03:09:44 2001 From: david@IPRG.nokia.com (David Kessens) Date: Sun, 8 Jul 2001 19:09:44 -0700 Subject: New countries in the 6bone In-Reply-To: <20010708225615.A14186@tinuviel.compendium.net.ar> References: <20010708225615.A14186@tinuviel.compendium.net.ar> Message-ID: <20010708190944.A2678@iprg.nokia.com> Horacio, On Sun, Jul 08, 2001 at 10:56:15PM -0300, horape@tinuviel.compendium.net.ar wrote: > > David, could you made the changes needed in the 6bone registry so they can > register? (DO and CU country codes) Done. David K. --- From pekkas@netcore.fi Mon Jul 9 12:22:52 2001 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 9 Jul 2001 14:22:52 +0300 (EEST) Subject: Filtering prefixes longer than /24 Message-ID: Hi, It appears some people are filtering prefixes longer than /24 in 6bone. We'd like to advertise /32. This was noticed when we wanted to change the peerings to a second router, and moved a "backup one" first and forced the traffic go through there; to certain locations, the return packets disappeared to the network advertising /24. The routing document says you MUST make arrangements with your peers if you do longer advertisements, but advertising these prefixes doesn't help any if they are being filtered by the third parties. Filtering /48 and more specific is IMO ok to me, but /32 appears a little too strict. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From itojun@iijlab.net Mon Jul 9 13:45:33 2001 From: itojun@iijlab.net (itojun@iijlab.net) Date: Mon, 09 Jul 2001 21:45:33 +0900 Subject: Filtering prefixes longer than /24 In-Reply-To: pekkas's message of Mon, 09 Jul 2001 14:22:52 +0300. Message-ID: <13564.994682733@itojun.org> >It appears some people are filtering prefixes longer than /24 in 6bone. >We'd like to advertise /32. >This was noticed when we wanted to change the peerings to a second router, >and moved a "backup one" first and forced the traffic go through there; to >certain locations, the return packets disappeared to the network >advertising /24. >The routing document says you MUST make arrangements with your peers if >you do longer advertisements, but advertising these prefixes doesn't help >any if they are being filtered by the third parties. because third parties are not in your arrangements. >Filtering /48 and more specific is IMO ok to me, but /32 appears a little >too strict. based on RFC2772 recommendation, i see the following filter in many places. how do you measure "too strict"? ipv6 prefix-list 6bone-filter seq 5 permit 3ffe::/17 le 24 ge 24 ipv6 prefix-list 6bone-filter seq 10 permit 3ffe:8000::/17 le 28 ge 28 ipv6 prefix-list 6bone-filter seq 12 deny 3ffe::/16 ipv6 prefix-list 6bone-filter seq 15 permit 2000::/3 le 16 ge 16 ipv6 prefix-list 6bone-filter seq 20 permit 2001::/16 le 35 ge 29 itojun From pekkas@netcore.fi Mon Jul 9 14:05:49 2001 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 9 Jul 2001 16:05:49 +0300 (EEST) Subject: Filtering prefixes longer than /24 In-Reply-To: <13564.994682733@itojun.org> Message-ID: On Mon, 9 Jul 2001 itojun@iijlab.net wrote: > >The routing document says you MUST make arrangements with your peers if > >you do longer advertisements, but advertising these prefixes doesn't help > >any if they are being filtered by the third parties. > > because third parties are not in your arrangements. True, which is why I'm taking up the issue for general consideration. > >Filtering /48 and more specific is IMO ok to me, but /32 appears a little > >too strict. > > based on RFC2772 recommendation, i see the following filter in > many places. how do you measure "too strict"? > > ipv6 prefix-list 6bone-filter seq 5 permit 3ffe::/17 le 24 ge 24 > ipv6 prefix-list 6bone-filter seq 10 permit 3ffe:8000::/17 le 28 ge 28 > ipv6 prefix-list 6bone-filter seq 12 deny 3ffe::/16 > ipv6 prefix-list 6bone-filter seq 15 permit 2000::/3 le 16 ge 16 > ipv6 prefix-list 6bone-filter seq 20 permit 2001::/16 le 35 ge 29 With "too strict" I mean preventing prefixes that: - aren't there by accident (redistributing connected and static routes causing various /64 - /128 in DFZ) - don't bloat the routing table by too specific routes (/48) as a principle - could actually be used in some valid environments (if your upstream pTLA peering isn't optimal, you can't go peer with anyone else, or create backup peering; you have to renumber the site or use two addresses in each box..) Ie, the current behaviour is easily defined, but also kind of "because we can". -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From rrockell@sprint.net Mon Jul 9 19:35:17 2001 From: rrockell@sprint.net (Robert J. Rockell) Date: Mon, 9 Jul 2001 14:35:17 -0400 (EDT) Subject: Filtering prefixes longer than /24 In-Reply-To: <13564.994682733@itojun.org> Message-ID: I think the basis for 2772 was to establish a 'minimal' set of filtering guidelines upon which we could form a 'stable' 6bone. Without at least this much participation in filtering, it would be difficult to find problems in Ipv6 deployment (at the protocol level; not necessarily the implementations). What one does with their immediate upstream for load-sharing when they have multiple connections to one upstream is up to them and their upstream. I agree with Itojun here. If this makes multi-homing difficult, or the like; that is sort of the point. This is all supposed to be aggregatable at the most fundamental levels, thus putting a top limit on the number of non-customer routes a TLA will have to carry. Violating this just adds factors of 2 to the routing table size, in theoretical limit. I agree there is problems, specifically in multi-homing. The goal was to fix the problems with multi-homing, and this was a good way to bring the problems out. IMHO, I don't want to fix the symptoms. If you are homed to one provider with multiple connections, and have a /32 from them, one can either negotiate de-aggregation with them, or use other BGP attributes to make one's desired policy to work. If you are announcing pTLA A's /32 to pTLA B, and this caused a problem when you moved, then you have violated rfc2772 already. Thanks Rob Rockell Principal Engineer SprintLink Europe/Asia Sprint E|Solutions: Thinking outside the 435 box ----------------------------------------------------------------------- On Mon, 9 Jul 2001 itojun@iijlab.net wrote: ->>It appears some people are filtering prefixes longer than /24 in 6bone. ->>We'd like to advertise /32. ->>This was noticed when we wanted to change the peerings to a second router, ->>and moved a "backup one" first and forced the traffic go through there; to ->>certain locations, the return packets disappeared to the network ->>advertising /24. ->>The routing document says you MUST make arrangements with your peers if ->>you do longer advertisements, but advertising these prefixes doesn't help ->>any if they are being filtered by the third parties. -> -> because third parties are not in your arrangements. -> ->>Filtering /48 and more specific is IMO ok to me, but /32 appears a little ->>too strict. -> -> based on RFC2772 recommendation, i see the following filter in -> many places. how do you measure "too strict"? -> ->ipv6 prefix-list 6bone-filter seq 5 permit 3ffe::/17 le 24 ge 24 ->ipv6 prefix-list 6bone-filter seq 10 permit 3ffe:8000::/17 le 28 ge 28 ->ipv6 prefix-list 6bone-filter seq 12 deny 3ffe::/16 ->ipv6 prefix-list 6bone-filter seq 15 permit 2000::/3 le 16 ge 16 ->ipv6 prefix-list 6bone-filter seq 20 permit 2001::/16 le 35 ge 29 -> ->itojun -> From pekkas@netcore.fi Mon Jul 9 20:45:19 2001 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 9 Jul 2001 22:45:19 +0300 (EEST) Subject: Filtering prefixes longer than /24 In-Reply-To: Message-ID: On Mon, 9 Jul 2001, Robert J. Rockell wrote: > If this makes multi-homing difficult, or the like; that is sort of the > point. This is all supposed to be aggregatable at the most fundamental > levels, thus putting a top limit on the number of non-customer routes a TLA > will have to carry. Violating this just adds factors of 2 to the routing > table size, in theoretical limit. I agree there is problems, specifically > in multi-homing. The goal was to fix the problems with multi-homing, and > this was a good way to bring the problems out. IMHO, I don't want to fix > the symptoms. This might lead to a trend where organizations not really needing pTLA assignment apply for one, instead of getting a fragment from an existing pTLA -- if this is the only way to avoid multihoming considerations. I'm not sure about the multihoming status, but I don't think it's really scales up to 6bone /32's and the like, connecting dozens of sites which would also need to multihome or renumber -- the maximum unit is a /48 site at most I think. Ie. this probably leads to an increase of pTLA or equivalent "non-filtered" organizations which may not be good from the aggregation point of view either. The scaling of IPv6 wrt. routing table size is IMO a big non-issue; a remnant from the '95 when people started to get worried about the growth of DFZ. Nowadays 100,000 routes is no big deal. Any "core" router which should be able to get full internet table can deal with this without problems. You shouldn't be participating with your old 4500 Cisco with 16 MB of memory. Thus, I don't see what's the point of trying to minimize the size with all costs. Currently, the effectively changing IPv6 prefix size is smaller than with IPv4, and the population of it going to be sparser. Also remember a big problem of current IPv4 routing table size are small advertisements, like /24 and /23 -- with IPv6 these are all within one /48, and are thus automatically very effectively aggregated. What's more worrying is complete fragmentation wrt. RIR allocations. Suppose all dial-up's and DSL's etc. are all given /48 as IESG requires. In effect, this requires RIR's take back (or assign new ones) all the current /35 allocations, and use a much sparser mode, like: really huge ISP's: /16 basic block for an ISP participating in DFZ: /24 smaller ISP: /32 small ISP: /40 site: /48 Without this, the current scheme is bound for disaster, and not because of someone is filtering a little longer than /24 when /24 is a basic allocation. > If you are announcing > pTLA A's /32 to pTLA B, and this caused a problem when you moved, then you > have violated rfc2772 already. This is the case, but I fail to see the big problem with this. In a "perfect world", organizations in this situation would renumber, use multihoming or whatever; in real world both are diffcult and the problem is avoided by getting a pTLA on your own. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From itojun@iijlab.net Mon Jul 9 23:56:37 2001 From: itojun@iijlab.net (itojun@iijlab.net) Date: Tue, 10 Jul 2001 07:56:37 +0900 Subject: Filtering prefixes longer than /24 In-Reply-To: pekkas's message of Mon, 09 Jul 2001 22:45:19 +0300. Message-ID: <19169.994719397@itojun.org> >The scaling of IPv6 wrt. routing table size is IMO a big non-issue; a >remnant from the '95 when people started to get worried about the growth >of DFZ. > >Nowadays 100,000 routes is no big deal. Any "core" router which should be >able to get full internet table can deal with this without problems. You >shouldn't be participating with your old 4500 Cisco with 16 MB of memory. >Thus, I don't see what's the point of trying to minimize the size with all >costs. two comments: - core routers need to carry both IPv4 full routing table and IPv6 full routing table, until we phase out IPv4. (or you need to babysit separate routers, separate fibers...) - routing table in IPv6 will eat 4 times more memory than IPv4 if the # of entries is the same. so I believe it is not a "non-issue" (or it is safer to think that way). does anyone have performance measurement/whatever with big big big IPv6 routing table installed onto a router? what is the routing table size vendors use for toture-test? >Currently, the effectively changing IPv6 prefix size is smaller than with >IPv4, and the population of it going to be sparser. Also remember a big >problem of current IPv4 routing table size are small advertisements, >like /24 and /23 -- with IPv6 these are all within one /48, and are thus >automatically very effectively aggregated. we can *potentially* have a lot of routes if you advertise /48 to worldwide. compare 2^(48-16) and 2^(24-8). itojun From dorian@blackrose.org Tue Jul 10 01:23:06 2001 From: dorian@blackrose.org (Dorian Kim) Date: Mon, 9 Jul 2001 20:23:06 -0400 Subject: Filtering prefixes longer than /24 In-Reply-To: <19169.994719397@itojun.org>; from itojun@iijlab.net on Tue, Jul 10, 2001 at 07:56:37AM +0900 References: <19169.994719397@itojun.org> Message-ID: <20010709202306.B10643@blackrose.org> On Tue, Jul 10, 2001 at 07:56:37AM +0900, itojun@iijlab.net wrote: > >The scaling of IPv6 wrt. routing table size is IMO a big non-issue; a > >remnant from the '95 when people started to get worried about the growth > >of DFZ. > > > >Nowadays 100,000 routes is no big deal. Any "core" router which should be > >able to get full internet table can deal with this without problems. You > >shouldn't be participating with your old 4500 Cisco with 16 MB of memory. > >Thus, I don't see what's the point of trying to minimize the size with all > >costs. > > two comments: > - core routers need to carry both IPv4 full routing table and IPv6 > full routing table, until we phase out IPv4. > (or you need to babysit separate routers, separate fibers...) > - routing table in IPv6 will eat 4 times more memory than IPv4 > if the # of entries is the same. > so I believe it is not a "non-issue" (or it is safer to think that way). All good and valid points. Furthermore, real concern regarding routing table size now, as was in mid 90s isn't so much to do with handling the memory requirements related to prefix table, but rather scaling the computational power necessary to do path computation in an Internet whose path diverity is increasing rapidly along with prefix table size. There are networks today that are seeing internal prefix table size in excess of 200,000 prefixes and millions of paths. When things grow faster than Moore's law for long enough, you lose, and we've jumped back on that trajectory after the temporary breaking affects post-CIDR. Of course, when people need a multi-million-dollar-liquid-cooled-faster-than- Cray-SV2 for every default free router, perhaps economic barrier to entry will solve this problems for us... -dorian From pekkas@netcore.fi Tue Jul 10 07:17:13 2001 From: pekkas@netcore.fi (Pekka Savola) Date: Tue, 10 Jul 2001 09:17:13 +0300 (EEST) Subject: Filtering prefixes longer than /24 In-Reply-To: <19169.994719397@itojun.org> Message-ID: On Tue, 10 Jul 2001 itojun@iijlab.net wrote: > >The scaling of IPv6 wrt. routing table size is IMO a big non-issue; a > >remnant from the '95 when people started to get worried about the growth > >of DFZ. > > > >Nowadays 100,000 routes is no big deal. Any "core" router which should be > >able to get full internet table can deal with this without problems. You > >shouldn't be participating with your old 4500 Cisco with 16 MB of memory. > >Thus, I don't see what's the point of trying to minimize the size with all > >costs. > > two comments: > - core routers need to carry both IPv4 full routing table and IPv6 > full routing table, until we phase out IPv4. > (or you need to babysit separate routers, separate fibers...) > - routing table in IPv6 will eat 4 times more memory than IPv4 > if the # of entries is the same. > so I believe it is not a "non-issue" (or it is safer to think that way). You're right; it's not a complete non-issue, but I feel it's very safe to assume that at least 10,000 routes can be handled just fine. Building IPv6 routing archtitecture on the fact that aggregation is very aggressive and DFZ has only e.g. less than 500 routes or the like would probably lead to some sort of CIDR disaster. > does anyone have performance measurement/whatever with big big big > IPv6 routing table installed onto a router? what is the routing table > size vendors use for toture-test? This would be interesting to know. >From Dorian's mail: > All good and valid points. Furthermore, real concern regarding routing > table size now, as was in mid 90s isn't so much to do with handling the > memory requirements related to prefix table, but rather scaling the > computational power necessary to do path computation in an Internet > whose path diverity is increasing rapidly along with prefix table size. Calculating these once doesn't appear to be a big problem, and the effect of more consistent changes are reduced by flap dampening. > >Currently, the effectively changing IPv6 prefix size is smaller than with > >IPv4, and the population of it going to be sparser. Also remember a big > >problem of current IPv4 routing table size are small advertisements, > >like /24 and /23 -- with IPv6 these are all within one /48, and are thus > >automatically very effectively aggregated. > > we can *potentially* have a lot of routes if you advertise /48 to > worldwide. compare 2^(48-16) and 2^(24-8). Well, you can get a lot of routes if you advertise every address as it's own route; this is what I feel is the equivalent in ipv4 world of of advertising /48's. Current multihoming mechanisms deal with one site. You cannot use these to multihome a (non-pTLA) ISP the address space of which is allocated to a dozen sites. Only thing you could do, I suppose, is getting your pTLA and some foreign pTLA do some peering (doesn't work in the real world) to protect against your physical link to pTLA ISP failing. On the other hand, currently: - 6bone MUST: ~2^(28-16) = 2^12 - 6bone idea: 2^(32-16) = 2^16 - IPv6 RIR (effective): 2^(25-16) = 2^9 - IPv6 RIR (theoretical): 2^(32-16) = 2^16 In addition, the allocations are not as dense as in IPv4. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From itojun@iijlab.net Tue Jul 10 08:46:44 2001 From: itojun@iijlab.net (itojun@iijlab.net) Date: Tue, 10 Jul 2001 16:46:44 +0900 Subject: Filtering prefixes longer than /24 In-Reply-To: pekkas's message of Tue, 10 Jul 2001 09:17:13 +0300. Message-ID: <25354.994751204@itojun.org> >You're right; it's not a complete non-issue, but I feel it's very safe to >assume that at least 10,000 routes can be handled just fine. Building >IPv6 routing archtitecture on the fact that aggregation is very aggressive >and DFZ has only e.g. less than 500 routes or the like would probably lead >to some sort of CIDR disaster. who is going to decide whether you are within the first 10000 (lucky) routes, or you are outside of it and now can't advertise? there are other multihoming mechanisms that does not impact worldwide routing table size. for example, draft-ietf-ipngwg-ipv6-2260-01.txt and some others. you may want to try these. (but "multihoming" is rather a vague term, so the goals may be different by who you talk to - the goals of the above draft is clearly stated in the draft) itojun From pekkas@netcore.fi Tue Jul 10 09:04:20 2001 From: pekkas@netcore.fi (Pekka Savola) Date: Tue, 10 Jul 2001 11:04:20 +0300 (EEST) Subject: Filtering prefixes longer than /24 In-Reply-To: <25354.994751204@itojun.org> Message-ID: On Tue, 10 Jul 2001 itojun@iijlab.net wrote: > >You're right; it's not a complete non-issue, but I feel it's very safe to > >assume that at least 10,000 routes can be handled just fine. Building > >IPv6 routing archtitecture on the fact that aggregation is very aggressive > >and DFZ has only e.g. less than 500 routes or the like would probably lead > >to some sort of CIDR disaster. > > who is going to decide whether you are within the first 10000 > (lucky) routes, or you are outside of it and now can't advertise? Currently full 6bone routing table is like 260 routes (if not filtered). Filtered to the maximum, it's like 160. By allowing something I don't think it immediately means everyone starts doing so. By defining the limit just so, the increase might not even be that significant. > there are other multihoming mechanisms that does not impact worldwide > routing table size. for example, draft-ietf-ipngwg-ipv6-2260-01.txt > and some others. you may want to try these. > (but "multihoming" is rather a vague term, so the goals may be > different by who you talk to - the goals of the above draft is > clearly stated in the draft) This only protects from YourOrg-ISP link failure. Often you might want to protect from routing failures of your ISP too, or set preference when using multiple peers (e.g. if your ISP's peering gets too bad). Anyway.. this doesn't seem to be going anywhere so I guess we'll just start to use the RIR assigned /35 more aggressively and flush out the 6bone /32. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From crawdad@fnal.gov Tue Jul 10 14:33:25 2001 From: crawdad@fnal.gov (Matt Crawford) Date: Tue, 10 Jul 2001 08:33:25 -0500 Subject: Filtering prefixes longer than /24 In-Reply-To: "10 Jul 2001 07:56:37 +0900." <19169.994719397@itojun.org> Message-ID: <200107101333.f6ADXPF19988@gungnir.fnal.gov> > - routing table in IPv6 will eat 4 times more memory than IPv4 > if the # of entries is the same. It shouldn't be more than 2 times, for the currently defined unicast address formats. If you can be flexible on alignment, maybe even closer to 1.5 times. From mcr@sandelman.ottawa.on.ca Tue Jul 10 19:06:04 2001 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 10 Jul 2001 14:06:04 -0400 Subject: Filtering prefixes longer than /24 In-Reply-To: Your message of "Tue, 10 Jul 2001 08:33:25 CDT." <200107101333.f6ADXPF19988@gungnir.fnal.gov> Message-ID: <200107101806.f6AI64P13530@marajade.sandelman.ottawa.on.ca> >>>>> "Matt" == Matt Crawford writes: >> - routing table in IPv6 will eat 4 times more memory than IPv4 >> if the # of entries is the same. Matt> It shouldn't be more than 2 times, for the currently defined unicast Matt> address formats. If you can be flexible on alignment, maybe even Matt> closer to 1.5 times. It shouldn't, but hardware people building CAM based table lookup engines do not benefit from the left associative routing stuff, so it does take 4x times. 2x times if the vendor is willing to compromise on dmakign /64s the longest they will do in the fast path. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From fink@es.net Tue Jul 10 21:28:42 2001 From: fink@es.net (Bob Fink) Date: Tue, 10 Jul 2001 13:28:42 -0700 Subject: pTLA request for CALADAN - review closes 24 July 2001 Message-ID: <5.1.0.14.0.20010710132408.02627d40@imap2.es.net> 6bone Folk, CALADAN has requested a pTLA allocation. The open review period for this request will close 24 July 2001. Please send your comments to me or the list. As has been noted by various comments to this list, your comments on these pTLA requests do matter, so please don't hesitate to voice your support or concerns. Thanks, Bob === >From: "Chris Smith" >To: >Subject: 6bone pTLA Request >Date: Tue, 10 Jul 2001 17:52:27 +0100 > >Hi Bob, > >We would like to apply for a pTLA allocation: > >1. We have been operational since February 2001 > >a) ipv6-site: CALADAN > >b) tunnel: IPV6 in IPV6 fremen.ip6.caladan.net -> 6r1.doc.london.pipex.net >UUNET-UK BGP4+ > >c) nameserver is thns.ip6.caladan.net > >d) www.ip6.caladan.net > >2. We are a UK based ISP, with our own racks in Telehouse North. We >currently have an ethernet feed from UUNET, but have just applied to peer at >the ipv6 London exchange in Telehouse. We have an open peering policy both >for ipv4 and ipv6 and are therefore happy to peer with anyone who is >interested. We are also happy to provide IP transit to anyone interested, >either by direct connect or via tunnels. > >a) We have two people registered in the database as contacts for ipv6 >related queries. > >b) ipv6@caladan.net > >3. We are RIPE members and currently provide ipv4 bandwidth to our >customers, some of which have expressed an interest in ipv6. > >4. We agree to abide by the rules as they exist now and as they may evolve >in the future. > >Regards, >Chris Smith From kre@munnari.OZ.AU Wed Jul 11 05:52:24 2001 From: kre@munnari.OZ.AU (Robert Elz) Date: Wed, 11 Jul 2001 11:52:24 +0700 Subject: Filtering prefixes longer than /24 In-Reply-To: References: Message-ID: <2825.994827144@brandenburg.cs.mu.OZ.AU> Date: Tue, 10 Jul 2001 11:04:20 +0300 (EEST) From: Pekka Savola Message-ID: | By allowing something I don't think it immediately means everyone starts | doing so. By defining the limit just so, the increase might not even be | that significant. There's no question, the 6bone could easily survive now with everyone announcing whatever they like ... But the point of the 6bone is to be able to test the real (full scale) environment. That means sites not advertising private prefixes, no matter what the justification seems to be, because if any site can justify that, so can every site. If this means that you need to renumber to fit in the 6bone addresses from your pTLA, then renumber - that's what all this is supposed to be about. And then contribute back whatever you learn from that, so we can try and make it easier in the future. kre From Pavel.Satrapa@vslib.cz Wed Jul 11 08:30:04 2001 From: Pavel.Satrapa@vslib.cz (Pavel Satrapa) Date: Wed, 11 Jul 2001 09:30:04 +0200 Subject: Filtering prefixes longer than /24 Message-ID: > But the point of the 6bone is to be able to test the real (full scale) > environment. That means sites not advertising private prefixes, no Clear. But the real SubTLA prefixes assigned by RIPE NCC (and probably by other registries too) are /35 :-( It looks like the production IPv6 network will be aggregated at the /35 level. ---------------------------------------------------------------------- Pavel Satrapa Technical University of Liberec E-Mail: Pavel.Satrapa@vslib.cz Dept. of Information Technology Phone: +420-48-535-2385 Halkova 6, 461 17 Liberec Fax: +420-48-535-2229 Czech Republic ---------------------------------------------------------------------- From kre@munnari.OZ.AU Wed Jul 11 09:31:15 2001 From: kre@munnari.OZ.AU (Robert Elz) Date: Wed, 11 Jul 2001 15:31:15 +0700 Subject: Filtering prefixes longer than /24 In-Reply-To: References: Message-ID: <7468.994840275@brandenburg.cs.mu.OZ.AU> Date: Wed, 11 Jul 2001 09:30:04 +0200 From: "Pavel Satrapa" Message-ID: | But the real SubTLA prefixes assigned by RIPE NCC (and probably by | other registries too) are /35 :-( It looks like the production IPv6 | network will be aggregated at the /35 level. Sure, but there's also supposed to be a higher level of aggregation at the /16 level, isn't there? kre From rrockell@sprint.net Wed Jul 11 10:31:16 2001 From: rrockell@sprint.net (Robert J. Rockell) Date: Wed, 11 Jul 2001 05:31:16 -0400 (EDT) Subject: Filtering prefixes longer than /24 In-Reply-To: Message-ID: I know of networks other than my own that are running over 200,000 routes currently (granted, probably not optimal). The table size is not onlyk a memory issue, but a forwarding ASIC issue that needs consideration. I would argue (and here comes a giant thread) that a TCP enhancement/re-write with renumbering may provide the scale people want, without putting the burden on the mtrie. Thanks Rob Rockell Principal Engineer SprintLink Europe/Asia 703-689-6322 Sprint E|Solutions: Thinking outside the 435 box ----------------------------------------------------------------------- On Mon, 9 Jul 2001, Pekka Savola wrote: ->On Mon, 9 Jul 2001, Robert J. Rockell wrote: ->> If this makes multi-homing difficult, or the like; that is sort of the ->> point. This is all supposed to be aggregatable at the most fundamental ->> levels, thus putting a top limit on the number of non-customer routes a TLA ->> will have to carry. Violating this just adds factors of 2 to the routing ->> table size, in theoretical limit. I agree there is problems, specifically ->> in multi-homing. The goal was to fix the problems with multi-homing, and ->> this was a good way to bring the problems out. IMHO, I don't want to fix ->> the symptoms. -> ->This might lead to a trend where organizations not really needing pTLA ->assignment apply for one, instead of getting a fragment from an existing ->pTLA -- if this is the only way to avoid multihoming considerations. I'm ->not sure about the multihoming status, but I don't think it's really ->scales up to 6bone /32's and the like, connecting dozens of sites which ->would also need to multihome or renumber -- the maximum unit is a /48 site ->at most I think. -> ->Ie. this probably leads to an increase of pTLA or equivalent ->"non-filtered" organizations which may not be good from the aggregation ->point of view either. -> ->The scaling of IPv6 wrt. routing table size is IMO a big non-issue; a ->remnant from the '95 when people started to get worried about the growth ->of DFZ. -> ->Nowadays 100,000 routes is no big deal. Any "core" router which should be ->able to get full internet table can deal with this without problems. You ->shouldn't be participating with your old 4500 Cisco with 16 MB of memory. ->Thus, I don't see what's the point of trying to minimize the size with all ->costs. -> ->Currently, the effectively changing IPv6 prefix size is smaller than with ->IPv4, and the population of it going to be sparser. Also remember a big ->problem of current IPv4 routing table size are small advertisements, ->like /24 and /23 -- with IPv6 these are all within one /48, and are thus ->automatically very effectively aggregated. -> -> ->What's more worrying is complete fragmentation wrt. RIR allocations. ->Suppose all dial-up's and DSL's etc. are all given /48 as IESG requires. ->In effect, this requires RIR's take back (or assign new ones) all the ->current /35 allocations, and use a much sparser mode, like: -> ->really huge ISP's: /16 ->basic block for an ISP participating in DFZ: /24 ->smaller ISP: /32 ->small ISP: /40 ->site: /48 -> ->Without this, the current scheme is bound for disaster, and not because of ->someone is filtering a little longer than /24 when /24 is a basic ->allocation. -> ->> If you are announcing ->> pTLA A's /32 to pTLA B, and this caused a problem when you moved, then you ->> have violated rfc2772 already. -> ->This is the case, but I fail to see the big problem with this. -> ->In a "perfect world", organizations in this situation would renumber, use ->multihoming or whatever; in real world both are diffcult and the problem ->is avoided by getting a pTLA on your own. -> ->-- ->Pekka Savola "Tell me of difficulties surmounted, ->Netcore Oy not those you stumble over and fall" ->Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -> -> From itojun@iijlab.net Wed Jul 11 10:43:34 2001 From: itojun@iijlab.net (Jun-ichiro itojun Hagino) Date: Wed, 11 Jul 2001 18:43:34 +0900 Subject: Filtering prefixes longer than /24 In-Reply-To: rrockell's message of Wed, 11 Jul 2001 05:31:16 -0400. Message-ID: <20010711094334.41DDF7BC@starfruit.itojun.org> >The table size is not onlyk a memory issue, but a forwarding ASIC issue that >needs consideration. I would argue (and here comes a giant thread) that a >TCP enhancement/re-write with renumbering may provide the scale people want, >without putting the burden on the mtrie. we may need sctp sooner...? itojun From pekkas@netcore.fi Wed Jul 11 14:58:17 2001 From: pekkas@netcore.fi (Pekka Savola) Date: Wed, 11 Jul 2001 16:58:17 +0300 (EEST) Subject: Filtering prefixes longer than /24 In-Reply-To: Message-ID: On Wed, 11 Jul 2001, Pavel Satrapa wrote: > > But the point of the 6bone is to be able to test the real (full scale) > > environment. That means sites not advertising private prefixes, no > > Clear. But the real SubTLA prefixes assigned by RIPE NCC (and probably by > other registries too) are /35 :-( It looks like the production IPv6 > network will be aggregated at the /35 level. Luckily enough, if you look at the assigments, you can see that RIR's are reserving everyone basically a /25 but giving out only 1/1024th of that now... Too bad they wouldn't "reserve" /24 which would have been on the nibble boundary; on the other hand, then RIR's would have to have been real stingy about who they're allocating to; only 256 candidates, and little room for expansion. Currently there are less than 100, and some are ones that should not have been given one IMO; however, I'm of the opinion not every local ISP should be given one anyway.. Now it won't matter, but it _will_ once after ISP's start doing dialup and dsl over IPv6 in a more widespread fashion (in a two years, perhaps). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From hostmast@nic.or.kr Thu Jul 12 03:07:15 2001 From: hostmast@nic.or.kr (KRNIC Hostmaster) Date: Thu, 12 Jul 2001 11:07:15 +0900 Subject: Filtering prefixes longer than /24 References: <7468.994840275@brandenburg.cs.mu.OZ.AU> Message-ID: <024b01c10a77$5f396ef0$8ed0ffcb@ywju> Dear all, This is Yong Wan Ju at KRNIC, one of National Internet Registries, under APNIC. Regarding your mail, > | But the real SubTLA prefixes assigned by RIPE NCC (and probably by > | other registries too) are /35 :-( It looks like the production IPv6 > | network will be aggregated at the /35 level. All RIRs such as RIPE NCC, ARIN & APNIC have allocated /35 to Sub-TLA registry based on slow-start mechanism but actually /29 are reserved for that Sub-TLA regsitry. Therefore, in the intial stage, It looks like the production IPv6 network will be aggregated at the level between /35 and /29. > Sure, but there's also supposed to be a higher level of aggregation at > the /16 level, isn't there? Maybe, after initial stage, it would be possible. But who knows that ...... Have a nice day !!! From whipple@zama.net Tue Jul 17 19:21:45 2001 From: whipple@zama.net (Todd Whipple) Date: Tue, 17 Jul 2001 11:21:45 -0700 Subject: New Services at Zama Networks Message-ID: <5.1.0.14.2.20010717111535.02d92b98@postoff1.zama.net> Zama is pleased to announce 2 new services, IPv6 Tunnel Broker and a 6to4 relay. Please visit our web site at www.zamanetworks.com to find out more information about these two services. For those with an OS capable to handle 6to4, point your 6to4 configuration to 6to4.zama6.com. We have also added an IPv6 FAQ to our site to answer the basic questions about IPv6. Hope you all find this information useful. Enjoy Todd Whipple VP of IPv6 Technologies Zama Networks, Inc. Seattle, Wa From pekkas@netcore.fi Tue Jul 17 19:55:01 2001 From: pekkas@netcore.fi (Pekka Savola) Date: Tue, 17 Jul 2001 21:55:01 +0300 (EEST) Subject: Inflexible ICMP6 Error-limiting Considered Harmful Message-ID: Hello all, Current Cisco IOS (12.2(2)T, and previous betas) rate-limit all icmp6 error messages (including time exceeded and port unreachable) by default. The default _interval_ between error of any two messages is 500 msec. I guess this was added as a security measure (you can still pingflood the router without limits, though!), or to provide maximum CPU power to actual packet forwarding (I'd rather save the 0.1% for the system..). Unfortunately, this breaks traceroute pretty badly; I think the huge timeouts now associated with IPv6 do not paint a good picture about the reliability (even though the reality may be different). For example, tracerouting from a looking glass [http://www.ipv6.euronet.be/looking/]: 1 gate.ipv6.wanadoo.be (3ffe:8100:200:1fff::1) 1.736 ms * 1.927 ms 2 2001:658:0:1::1 (2001:658:0:1::1) 62.505 ms * 70.661 ms 3 2001:680:0:1::10 (2001:680:0:1::10) 72.154 ms * 71.249 ms 4 2001:680:0:1::3 (2001:680:0:1::3) 109.85 ms * 103.641 ms 5 ipv6.netcore.fi (2001:670:86::1) 153.934 ms 113.085 ms 115.128 ms Wonder which ones are Ciscos? That's right. I just love demonstrating IPv6 to people when something like this has been happening for years now.. Of course, this can be "fixed" by disabling the rate-limiting completely with: ipv6 icmp error-interval 0 (smaller values than 500, like 50 equally break traceroute for high-speed connectivity) Real fix would be to implement _error-rate_, in addition to _error-interval_ (with sane defaults). For example, if sampling period would be 100 ms and it would be acceptable to have 5 _packets_ per period, the potential denial of service attacks would be prevented but the traceroute, etc. functionality would still work. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From itojun@iijlab.net Wed Jul 18 16:48:17 2001 From: itojun@iijlab.net (itojun@iijlab.net) Date: Thu, 19 Jul 2001 00:48:17 +0900 Subject: Inflexible ICMP6 Error-limiting Considered Harmful In-Reply-To: pekkas's message of Tue, 17 Jul 2001 21:55:01 +0300. Message-ID: <10924.995471297@itojun.org> this portion is implementation-dependent (as described in RFC2463) so noone is right and noone is wrong, but... >Real fix would be to implement _error-rate_, in addition to >_error-interval_ (with sane defaults). For example, if sampling period >would be 100 ms and it would be acceptable to have 5 _packets_ per period, >the potential denial of service attacks would be prevented but the >traceroute, etc. functionality would still work. during KAME development process, it was found that error interval limitation is not a good way. we now impose "maximum N outgoing icmp6 per second" (packet-per-second) limitation, which works quite well. itojun From fink@es.net Wed Jul 18 16:49:35 2001 From: fink@es.net (Bob Fink) Date: Wed, 18 Jul 2001 08:49:35 -0700 Subject: 6bone pTLA 3FFE:8260::/28 allocated to COMPENDIUM-AR Message-ID: <5.1.0.14.0.20010718084723.024e0e48@imap2.es.net> COMPENDIUM-AR in Argentina has been allocated pTLA 3FFE:8260::/28 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: Thanks, Bob From mmuller@niksula.hut.fi Thu Jul 19 07:45:00 2001 From: mmuller@niksula.hut.fi (Mika Kristian Muller) Date: Thu, 19 Jul 2001 09:45:00 +0300 (EEST) Subject: DoS against IPv6? Message-ID: I'm writing a thesis about DoS/DDoS methods against IPv6/IPsec. If anyone knows any previous papers about subject, especially if they contain DoS-attacks in theory, but haven't implemented them, I could use those as references. I allready have some ICMPv6 attacks documented, but I need still more and other types. -Mika From itojun@iijlab.net Thu Jul 19 09:08:57 2001 From: itojun@iijlab.net (itojun@iijlab.net) Date: Thu, 19 Jul 2001 17:08:57 +0900 Subject: DoS against IPv6? In-Reply-To: mmuller's message of Thu, 19 Jul 2001 09:45:00 +0300. Message-ID: <21952.995530137@itojun.org> >I'm writing a thesis about DoS/DDoS methods against IPv6/IPsec. > >If anyone knows any previous papers about subject, especially if they >contain DoS-attacks in theory, but haven't implemented them, I could use >those as references. I allready have some ICMPv6 attacks documented, but >I need still more and other types. i have never seen IPv6 DDoS papers/whatever, but there are a couple of interesting ones. abuse tools: there was a tool to forge packets that cross IPv6-over-IPv4 tunnel, and lets bad guys inject any IPv6 traffic into the 6bone without revealing identity. this could be used as a starting point for DoS. DoS possibility due to spec twist: http://www.securityfocus.com/templates/archive.pike?threads=1&list=1&start=2001-06-24&mid=193046&fromthread=1&end=2001-06-30& draft-ietf-ipngwg-p2p-pingpong-00.txt draft-itojun-ipv6-transition-abuse-01.txt itojun From mator@gsib.ru Thu Jul 19 12:05:04 2001 From: mator@gsib.ru (Anatoly Pugachev) Date: Thu, 19 Jul 2001 15:05:04 +0400 Subject: DoS against IPv6? In-Reply-To: ; from mmuller@mail.niksula.cs.hut.fi on Thu, Jul 19, 2001 at 09:45:00AM +0300 References: Message-ID: <20010719150504.A11085@p2.gsib.ru> On Thu, Jul 19, 2001 at 09:45:00AM +0300, Mika Kristian Muller wrote: > I'm writing a thesis about DoS/DDoS methods against IPv6/IPsec. > > If anyone knows any previous papers about subject, especially if they > contain DoS-attacks in theory, but haven't implemented them, I could use > those as references. I allready have some ICMPv6 attacks documented, but > I need still more and other types. something - http://www.antioffline.com/stoppingdos.html From zzl@mail.ndsc.com.cn Thu Jul 19 12:39:02 2001 From: zzl@mail.ndsc.com.cn (Zhao Zhaolin) Date: Thu, 19 Jul 2001 19:39:02 +0800 Subject: active network over ipv6 and ipv4? Message-ID: <000d01c11047$68e84720$aec8a8c0@LocalHost> ÕâÊÇ MIME ¸ñʽµÄ¾ßÓкܶಿ·ÖÏûÏ¢¡£ ------=_NextPart_000_000A_01C1108A.765D45C0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSdtIHdyaXRpbmcgYSB0aGVzaXMgYWJvdXQgYWN0aXZlIG5ldHdvcmsgb3ZlciBpcHY2IGFuZCB0 aGUgcmFuc2l0aW9uIGZyb20gaXB2NCB0byBpcHY2IGFuZCB0aGUgYXBwbGljYXRpb25zIG9mIGFj dGl2ZSBuZXR3b3Jrcy4NCg0KSWYgYW55b25lIGtub3dzIGFueSBwcmV2aW91cyBwYXBlcnMgYWJv dXQgdGhlc2Ugc3ViamVjdHMsIGVzcGVjaWFsbHkgaWYgdGhleQ0KY29udGFpbiBhY3RpdmUgbmV0 d29ya3MgYXBwbGljYXRpb25zIGluIHRoZW9yeSxvciBxdWVzdGlvbnMgb24gdGhlc2Ugc3ViamVj dHMsIGJ1dCBoYXZlbid0IHNvbHZlIHRoZW0sIEkgd291bGQgdGhhbmsgaGltIGlmIGhlIGdpdmUg bWUgYXMgcmVmZXJlbmNlLg0KDQpUaGFua3MgdmVyeSBtdWNoISENCg0KLXpoYW9saW5nLHpoYW8N Cg== ------=_NextPart_000_000A_01C1108A.765D45C0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNDYyLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBzaXplPTM+SSdtIHdy aXRpbmcgYSB0aGVzaXMgYWJvdXQgYWN0aXZlIG5ldHdvcmsgb3ZlciANCmlwdjYgYW5kIHRoZSBy YW5zaXRpb24gZnJvbSBpcHY0IHRvIGlwdjYgYW5kIHRoZSBhcHBsaWNhdGlvbnMgb2YgYWN0aXZl IA0KbmV0d29ya3MuPEJSPjxCUj5JZiBhbnlvbmUga25vd3MgYW55IHByZXZpb3VzIHBhcGVycyBh Ym91dCB0aGVzZSBzdWJqZWN0cywgDQplc3BlY2lhbGx5IGlmIHRoZXk8QlI+Y29udGFpbiZuYnNw O2FjdGl2ZSBuZXR3b3JrcyBhcHBsaWNhdGlvbnMmbmJzcDtpbiANCnRoZW9yeSxvciBxdWVzdGlv bnMgb24gdGhlc2Ugc3ViamVjdHMsIGJ1dCBoYXZlbid0Jm5ic3A7c29sdmUgdGhlbSwgSSB3b3Vs ZCANCnRoYW5rIGhpbSBpZiBoZSBnaXZlIG1lIGFzIHJlZmVyZW5jZS48L0ZPTlQ+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PEZPTlQgc2l6ZT0zPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBzaXplPTM+VGhhbmtzIHZlcnkgbXVjaCEh PC9ESVY+DQo8RElWPjxCUj4temhhb2xpbmcsemhhbzwvRk9OVD48L0RJVj48L0ZPTlQ+PC9CT0RZ PjwvSFRNTD4NCg== ------=_NextPart_000_000A_01C1108A.765D45C0-- From pekkas@netcore.fi Thu Jul 19 13:08:32 2001 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 19 Jul 2001 15:08:32 +0300 (EEST) Subject: DoS against IPv6? In-Reply-To: <21952.995530137@itojun.org> Message-ID: On Thu, 19 Jul 2001 itojun@iijlab.net wrote: > >I'm writing a thesis about DoS/DDoS methods against IPv6/IPsec. > > > >If anyone knows any previous papers about subject, especially if they > >contain DoS-attacks in theory, but haven't implemented them, I could use > >those as references. I allready have some ICMPv6 attacks documented, but > >I need still more and other types. > > i have never seen IPv6 DDoS papers/whatever, but there are a couple > of interesting ones. > > abuse tools: > > there was a tool to forge packets that cross IPv6-over-IPv4 tunnel, > and lets bad guys inject any IPv6 traffic into the 6bone without > revealing identity. this could be used as a starting point for DoS. > > DoS possibility due to spec twist: > > http://www.securityfocus.com/templates/archive.pike?threads=1&list=1&start=2001-06-24&mid=193046&fromthread=1&end=2001-06-30& > draft-ietf-ipngwg-p2p-pingpong-00.txt > draft-itojun-ipv6-transition-abuse-01.txt Also, work-in-progress draft-huitema-shipworm-00.txt (not implemented yet, just fresh out of the oven..) would allow you to anonymously flood IPv4 UDP ports with encapsulated IPv6 packets. This might be something to watch out for in the future. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From Francis.Dupont@enst-bretagne.fr Thu Jul 19 13:11:46 2001 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Thu, 19 Jul 2001 14:11:46 +0200 Subject: DoS against IPv6? In-Reply-To: Your message of Thu, 19 Jul 2001 09:45:00 +0300. Message-ID: <200107191211.f6JCBkO78467@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: I'm writing a thesis about DoS/DDoS methods against IPv6/IPsec. => with the home address option defined for/by mobile IPv6, you can build a "nice" indirect DDoS: (I suppose you know how the home address option works) from a large number of A nodes you send to B nodes requests (i.e. packets which have to be answered) with the address of C (the target) in a home address options: B nodes will send replies to C without any mention of A nodes (so this is an indirect DDoS). Regards Francis.Dupont@enst-bretagne.fr From kuznet@ms2.inr.ac.ru Thu Jul 19 20:04:11 2001 From: kuznet@ms2.inr.ac.ru (kuznet@ms2.inr.ac.ru) Date: Thu, 19 Jul 2001 23:04:11 +0400 (MSK DST) Subject: Inflexible ICMP6 Error-limiting Considered Harmful In-Reply-To: <10924.995471297@itojun.org> from "itojun@iijlab.net" at Jul 19, 1 00:48:17 am Message-ID: <200107191904.XAA00667@ms2.inr.ac.ru> Hello! > >Real fix would be to implement _error-rate_, in addition to > >_error-interval_ (with sane defaults). For example, if sampling period > >would be 100 ms and it would be acceptable to have 5 _packets_ per period, > >the potential denial of service attacks would be prevented but the > >traceroute, etc. functionality would still work. > > during KAME development process, it was found that error interval > limitation is not a good way. we now impose "maximum N outgoing > icmp6 per second" (packet-per-second) limitation, which works quite > well. Right worda are "token bucket filter". And no more words are required to implement this trivial algorithm. Alexey From ot@cisco.com Fri Jul 20 12:13:16 2001 From: ot@cisco.com (Ole Troan) Date: 20 Jul 2001 12:13:16 +0100 Subject: Inflexible ICMP6 Error-limiting Considered Harmful In-Reply-To: Pekka Savola's message of "Tue, 17 Jul 2001 21:55:01 +0300 (EEST)" References: Message-ID: <7t5lmlj4zw3.fsf@onatopp.cisco.com> yes, the purely interval based mechanism doesn't work too well. we have implemented a slightly more clever mechanism. should be in the next beta. /ot > Current Cisco IOS (12.2(2)T, and previous betas) rate-limit all icmp6 > error messages (including time exceeded and port unreachable) by default. > The default _interval_ between error of any two messages is 500 msec. > > I guess this was added as a security measure (you can still pingflood the > router without limits, though!), or to provide maximum CPU power to actual > packet forwarding (I'd rather save the 0.1% for the system..). > > Unfortunately, this breaks traceroute pretty badly; I think the huge > timeouts now associated with IPv6 do not paint a good picture about the > reliability (even though the reality may be different). For example, > tracerouting from a looking glass [http://www.ipv6.euronet.be/looking/]: > > 1 gate.ipv6.wanadoo.be (3ffe:8100:200:1fff::1) 1.736 ms * 1.927 ms > 2 2001:658:0:1::1 (2001:658:0:1::1) 62.505 ms * 70.661 ms > 3 2001:680:0:1::10 (2001:680:0:1::10) 72.154 ms * 71.249 ms > 4 2001:680:0:1::3 (2001:680:0:1::3) 109.85 ms * 103.641 ms > 5 ipv6.netcore.fi (2001:670:86::1) 153.934 ms 113.085 ms 115.128 ms > > Wonder which ones are Ciscos? That's right. > > I just love demonstrating IPv6 to people when something like this > has been happening for years now.. > > Of course, this can be "fixed" by disabling the rate-limiting > completely with: > > ipv6 icmp error-interval 0 > > (smaller values than 500, like 50 equally break traceroute for high-speed > connectivity) > > Real fix would be to implement _error-rate_, in addition to > _error-interval_ (with sane defaults). For example, if sampling period > would be 100 ms and it would be acceptable to have 5 _packets_ per period, > the potential denial of service attacks would be prevented but the > traceroute, etc. functionality would still work. > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From bnilso@csc.com Fri Jul 20 21:21:23 2001 From: bnilso@csc.com (Bo Nilso) Date: Fri, 20 Jul 2001 22:21:23 +0200 Subject: IP v6 Security Message-ID: Hi! Have listen to the mails about DOS attacs on IPv6 network. I have a more general question: Is there any FIREWALL SW for IP v6? Fuego does not have it, Checkpoint does not state to have any product, Cisco 12.2T is not anything to use on their PICS FW (as far as I have heard). Have anybody else seen anything around? Have anybody geard ANYTHING about products in pipeline? In general, IP v6 fans state security is good in IPv6 due to IPSEC. But that creates a tunnel between endpoints. Seen from an individual person viewpoint, I can protect my data transfers and dialogues from being tapped into. Seen from a Company perspective, Tunnels are not good, unless you know what is in it. You need some point in the net, in your gate to the world (Internet or other outside connections), where you can allow/deny services, based on a company IT Security policy. I appriciate an answer to my initial question, as it is part of my professional work. A discussion in general on security, FW´s and tunnels is also interesting. BosseN ----------------------------------------------------------------- AVS: Bo Nilsö, CSC Sweden, Linköping Mail: bnilso@csc.com Phone: +46 (0) 13 465 3631 ------------------------------------------------------------------- From itojun@iijlab.net Sat Jul 21 01:11:22 2001 From: itojun@iijlab.net (itojun@iijlab.net) Date: Sat, 21 Jul 2001 09:11:22 +0900 Subject: IP v6 Security In-Reply-To: bnilso's message of Fri, 20 Jul 2001 22:21:23 +0200. Message-ID: <12533.995674282@itojun.org> >I have a more general question: Is there any FIREWALL SW for IP v6? Fuego >does not have it, Checkpoint does not state to have any product, Cisco >12.2T is not anything to use on their PICS FW (as far as I have heard). >Have anybody else seen anything around? Have anybody geard ANYTHING about >products in pipeline? near-future cisco IOS will have access control list (= filters) support, I believe. if you are okay with free softwares, you can use KAME ip6fw, Darren Reed's ipfilter, and maybe some other filters. itojun From Marc.Blanchet@viagenie.qc.ca Sat Jul 21 04:14:29 2001 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Fri, 20 Jul 2001 23:14:29 -0400 Subject: IP v6 Security In-Reply-To: <12533.995674282@itojun.org> References: Message-ID: <5.1.0.14.1.20010720231256.025ccab0@mail.viagenie.qc.ca> At/À 09:11 2001-07-21 +0900, itojun@iijlab.net you wrote/vous écriviez: > >I have a more general question: Is there any FIREWALL SW for IP v6? Fuego > >does not have it, Checkpoint does not state to have any product, Cisco > >12.2T is not anything to use on their PICS FW (as far as I have heard). > >Have anybody else seen anything around? Have anybody geard ANYTHING about > >products in pipeline? > > near-future cisco IOS will have access control list (= filters) > support, I believe. - already available, but standard access list (somewhat limited). - the roadmap says that next release will have extended access list. but this doesn't handle complex security policies with stateful stuff. > if you are okay with free softwares, you can use KAME ip6fw, Darren > Reed's ipfilter, and maybe some other filters. ipfilter is better than extended access lists since it handles stateful. Marc. >itojun From gnea@garson.org Sat Jul 21 08:01:45 2001 From: gnea@garson.org (Scott Prader) Date: Sat, 21 Jul 2001 03:01:45 -0400 Subject: IP v6 Security In-Reply-To: Message-ID: <20010721030145.A14095@garson.org> * Bo Nilso (bnilso@csc.com) uttered: > Hi! > > Have listen to the mails about DOS attacs on IPv6 network. > > I have a more general question: Is there any FIREWALL SW for IP v6? Fuego > does not have it, Checkpoint does not state to have any product, Cisco > 12.2T is not anything to use on their PICS FW (as far as I have heard). > Have anybody else seen anything around? Have anybody geard ANYTHING about > products in pipeline? Yes, in Linux kerne 2.4.* there is iptables extensions for ipv6 as well as many packages and documentation (it's still growing, but usable.. ping6, traceroute6,tracepath6, etc.. .oO Gnea [gnea at garson dot com] Oo. .oO url [http://gnea.net] Oo. "You can tune a filesystem, but you can't tune a fish." -Kirk McKusick From roam@orbitel.bg Sat Jul 21 15:01:25 2001 From: roam@orbitel.bg (Peter Pentchev) Date: Sat, 21 Jul 2001 17:01:25 +0300 Subject: IP v6 Security In-Reply-To: <20010721030145.A14095@garson.org>; from gnea@garson.org on Sat, Jul 21, 2001 at 03:01:45AM -0400 References: <20010721030145.A14095@garson.org> Message-ID: <20010721170125.A571@ringworld.oblivion.bg> On Sat, Jul 21, 2001 at 03:01:45AM -0400, Scott Prader wrote: > * Bo Nilso (bnilso@csc.com) uttered: > > Hi! > > > > Have listen to the mails about DOS attacs on IPv6 network. > > > > I have a more general question: Is there any FIREWALL SW for IP v6? Fuego > > does not have it, Checkpoint does not state to have any product, Cisco > > 12.2T is not anything to use on their PICS FW (as far as I have heard). > > Have anybody else seen anything around? Have anybody geard ANYTHING about > > products in pipeline? > > Yes, in Linux kerne 2.4.* there is iptables extensions for ipv6 as well > as many packages and documentation (it's still growing, but usable.. > ping6, traceroute6,tracepath6, etc.. itojun's earlier message in this thread mentioned that KAME has a IPv6 firewall. Just for the record, the KAME software suite is included in most recent releases of *BSD, so any recent *BSD system would include an ip6fw utility. G'luck, Peter -- Hey, out there - is it *you* reading me, or is it someone else? From itojun@iijlab.net Sat Jul 21 15:56:58 2001 From: itojun@iijlab.net (itojun@iijlab.net) Date: Sat, 21 Jul 2001 23:56:58 +0900 Subject: IP v6 Security In-Reply-To: roam's message of Sat, 21 Jul 2001 17:01:25 +0300. <20010721170125.A571@ringworld.oblivion.bg> Message-ID: <18357.995727418@itojun.org> >itojun's earlier message in this thread mentioned that KAME has a IPv6 >firewall. Just for the record, the KAME software suite is included >in most recent releases of *BSD, so any recent *BSD system would include >an ip6fw utility. unfortnately, the above is not correct - every *BSD had different packet filters in it, so we could not integrate ip6fw to all of them. therefore, *BSD situation with filters are like this: - freebsd - ip6fw (yes), and ipfilter (ipv6 support - ??) - netbsd - ipfilter (ipv6 support - yes) - openbsd - pf (ipv6 support - not yet) - bsdi - ipfw (ipv6 support - yes) itojun From Marc.Blanchet@viagenie.qc.ca Sat Jul 21 21:22:05 2001 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Sat, 21 Jul 2001 16:22:05 -0400 Subject: IP v6 Security In-Reply-To: <18357.995727418@itojun.org> References: Message-ID: <5.1.0.14.1.20010721162138.0420e008@mail.viagenie.qc.ca> At/À 23:56 2001-07-21 +0900, itojun@iijlab.net you wrote/vous écriviez: > >itojun's earlier message in this thread mentioned that KAME has a IPv6 > >firewall. Just for the record, the KAME software suite is included > >in most recent releases of *BSD, so any recent *BSD system would include > >an ip6fw utility. > > unfortnately, the above is not correct - every *BSD had different > packet filters in it, so we could not integrate ip6fw to all of them. > therefore, *BSD situation with filters are like this: > - freebsd - ip6fw (yes), and ipfilter (ipv6 support - ??) freebsd - ipfilter - ipv6: confirming: yes it works. Marc. > - netbsd - ipfilter (ipv6 support - yes) > - openbsd - pf (ipv6 support - not yet) > - bsdi - ipfw (ipv6 support - yes) > >itojun From itojun@iijlab.net Sun Jul 22 08:17:36 2001 From: itojun@iijlab.net (itojun@iijlab.net) Date: Sun, 22 Jul 2001 16:17:36 +0900 Subject: merit 6bone routing report Message-ID: <24666.995786256@itojun.org> http://www.merit.edu/mail.archives/html/6bone-routing-report/ merit IPv6 routing report seems to be stopped on Mar 2001. was it terminated (then thank you for all helps and R.I.P...), or just in trouble? itojun From itojun@iijlab.net Sun Jul 22 08:17:54 2001 From: itojun@iijlab.net (itojun@iijlab.net) Date: Sun, 22 Jul 2001 16:17:54 +0900 Subject: merit 6bone routing report In-Reply-To: itojun's message of Sun, 22 Jul 2001 16:17:36 +0900. <24666.995786256@itojun.org> Message-ID: <24681.995786274@itojun.org> > http://www.merit.edu/mail.archives/html/6bone-routing-report/ > merit IPv6 routing report seems to be stopped on Mar 2001. May 2001. itojun From bnilso@csc.com Sun Jul 22 20:11:48 2001 From: bnilso@csc.com (Bo Nilso) Date: Sun, 22 Jul 2001 21:11:48 +0200 Subject: IP v6 Security Message-ID: Hi! Thanks for this, and all other replies to my question. A general question: Will it be harder to build FW´s for IPv6 vs IPv4, keeping in mind the fact that multiple header concept might make it harder (slower, cpu-consuming) trying to filter and do stateful inspection, as the data needed for making descions for each paket is not on an predictable position within each IP packet ( it depends on how many different headers that exist in the IP packet. I think it will. Am I wrong? /BosseN ----------------------------------------------------------------- AVS: Bo Nilsö, CSC Sweden, Linköping Mail: bnilso@csc.com Phone: +46 (0) 13 465 3631 ------------------------------------------------------------------- Scott Prader cc: Sent by: Subject: Re: IP v6 Security owner-6bone@I SI.EDU 2001-07-21 09:01 * Bo Nilso (bnilso@csc.com) uttered: > Hi! > > Have listen to the mails about DOS attacs on IPv6 network. > > I have a more general question: Is there any FIREWALL SW for IP v6? Fuego > does not have it, Checkpoint does not state to have any product, Cisco > 12.2T is not anything to use on their PICS FW (as far as I have heard). > Have anybody else seen anything around? Have anybody geard ANYTHING about > products in pipeline? Yes, in Linux kerne 2.4.* there is iptables extensions for ipv6 as well as many packages and documentation (it's still growing, but usable.. ping6, traceroute6,tracepath6, etc.. .oO Gnea [gnea at garson dot com] Oo. .oO url [http://gnea.net] Oo. "You can tune a filesystem, but you can't tune a fish." -Kirk McKusick From Francis.Dupont@enst-bretagne.fr Mon Jul 23 08:53:48 2001 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Mon, 23 Jul 2001 09:53:48 +0200 Subject: IP v6 Security In-Reply-To: Your message of Sun, 22 Jul 2001 21:11:48 +0200. Message-ID: <200107230753.f6N7rmO97922@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: A general question: Will it be harder to build FW´s for IPv6 vs IPv4, keeping in mind the fact that multiple header concept might make it harder (slower, cpu-consuming) trying to filter and do stateful inspection, as the data needed for making descions for each paket is not on an predictable position within each IP packet ( it depends on how many different headers that exist in the IP packet. I think it will. Am I wrong? => yes and no. The extension header mechanism is easier to use or to parse/filter than the IPv4 option mechanism, so to filter a IPv6 packet with options is simpler/faster than to filter a IPv4 packet with options... The real issue is the ratio of packets with options, this ratio is known to be very low for IPv4, making the IPv4 option mechanism near useless. The IPv6 extension mechanism is supposed to fix that so this ratio should be greater for IPv6 and the final result is not predictable... My concern about filtering/classifying devices is that CPU speed grows slower than fiber optic bandwidth: smart (?) processing (i.e. everything more complex than switching) is becoming more and more hard & expensive at full fiber speed, perhaps unfeasible if the phenomenon persits... It is already hard to do more than basic filtering at 1Gbits/s (I know no commercial product for that). Regards Francis.Dupont@enst-bretagne.fr From whipple@zama.net Tue Jul 24 17:45:08 2001 From: whipple@zama.net (Todd Whipple) Date: Tue, 24 Jul 2001 09:45:08 -0700 Subject: News server Message-ID: <5.1.0.14.2.20010724093711.02cf04a0@postoff1.zama.net> Zama Networks is pleased to announced our IPv6 news group service. The news server is open only over IPv6. To read news, point your IPv6 capable news client to news.zamanetworks.com. The server currently has the big eight group hierarchies except for alt.* Currrently, Netscape 6 and TIN 1.5.8 are IPv6 capable news clients. Enjoy. From tsoome@ut.ee Tue Jul 24 21:21:33 2001 From: tsoome@ut.ee (Toomas Soome) Date: Tue, 24 Jul 2001 22:21:33 +0200 (EET) Subject: News server In-Reply-To: <5.1.0.14.2.20010724093711.02cf04a0@postoff1.zama.net> Message-ID: unfortunately: [196] root@madli:root/kadri> traceroute news.zamanetworks.com traceroute: Warning: Multiple interfaces found; using 3ffe:200:25:500:a00:20ff:fe83:b3ae @ hme0:2 traceroute to news.zamanetworks.com (2001:2d0:2:1::3007), 30 hops max, 60 byte packets 1 kadri.ut.ee (3ffe:200:25:500:a00:20ff:fec4:93e3) 1.057 ms 0.630 ms 0.445 ms 2 ut-gw-v6.ut.ee (3ffe:200:25:f000::c128:167f) 1.599 ms 1.418 ms 1.091 ms 3 ut-cisco.ut.ee (3ffe:200:25:0:2d0:97ff:fe91:a001) 1.547 ms 2.310 ms 2.549 ms 4 2001:6c0:1fff:ffd0::4 19.557 ms 22.475 ms 22.048 ms 5 spacenet-if.6r1.doc.london.ip6.pipex.net (3ffe:1100:0:c11::1) 175.020 ms 120.682 ms * 6 * * * 7 * * * 8 * * * 9 *^C On Tue, 24 Jul 2001, Todd Whipple wrote: > Zama Networks is pleased to announced our IPv6 news group service. The > news server is open only over IPv6. To read news, point your IPv6 capable > news client to news.zamanetworks.com. The server currently has the big > eight group hierarchies except for alt.* > > Currrently, Netscape 6 and TIN 1.5.8 are IPv6 capable news clients. > > Enjoy. > toomas -- Old musicians never die, they just decompose. From fink@es.net Tue Jul 24 22:14:20 2001 From: fink@es.net (Bob Fink) Date: Tue, 24 Jul 2001 14:14:20 -0700 Subject: 6bone pTLA 3FFE:8270::/28 allocated to CALADAN Message-ID: <5.1.0.14.0.20010724141204.0286bbc0@imap2.es.net> CALADAN in Great Britain has been allocated pTLA 3FFE:8270::/28 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: Thanks, Bob From fink@es.net Tue Jul 24 22:14:20 2001 From: fink@es.net (Bob Fink) Date: Tue, 24 Jul 2001 14:14:20 -0700 Subject: 6bone pTLA 3FFE:8270::/28 allocated to CALADAN Message-ID: <5.1.0.14.0.20010724141204.0286bbc0@imap2.es.net> CALADAN in Great Britain has been allocated pTLA 3FFE:8270::/28 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: Thanks, Bob From peter.lewis@upperside.fr Wed Jul 25 16:50:34 2001 From: peter.lewis@upperside.fr (Peter Lewis) Date: Wed, 25 Jul 2001 17:50:34 +0200 Subject: Deploying IPv6 Conference Message-ID: <002801c11521$8bb53fe0$0601a8c0@oleane.com> This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C11532.4DE6BD40 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 Deploying IPv6 Conference, Paris, 20-23 November 2001. The dead line for submitting abstracts has been extended to August 15: http://www.upperside.fr/ipv6/deployipv6cfp.htm ------=_NextPart_000_0025_01C11532.4DE6BD40 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
Deploying IPv6 Conference, Paris, 20-23 November=20 2001.
The dead line for submitting abstracts has been = extended to=20 August 15:
http://www.uppers= ide.fr/ipv6/deployipv6cfp.htm
 
 
------=_NextPart_000_0025_01C11532.4DE6BD40--