From hansolofalcon@worldnet.att.net Fri Feb 1 01:04:22 2002 From: hansolofalcon@worldnet.att.net (Gregg C Levine) Date: Thu, 31 Jan 2002 20:04:22 -0500 Subject: remove In-Reply-To: Message-ID: <000201c1aabc$63693f60$ac60580c@who> Hello from Gregg C Levine normally with Jedi Knight Computers These "remove", subjected messages are getting to be a nuisance. Can the list-owner, or someone else, familiar with the way things are managed on this list, post the actual instructions? This is the third, no fourth "remove", subjected message, today, and they are getting to be a nuisance, as I have written before. I have since sent out two messages, one suggesting that the correspondent, send the appropriate message the list server address who subscribed him, and the other, simply a reminder to re-read the message that was sent out on the subject. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."  Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) -----Original Message----- From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU] Sent: Thursday, January 31, 2002 5:43 PM To: 6bone@ISI.EDU Subject: remove remove From baogf@lucent.com Fri Feb 1 01:14:46 2002 From: baogf@lucent.com (Bao, Gan Feng (Bill)) Date: Fri, 1 Feb 2002 09:14:46 +0800 Subject: remove Message-ID: <31C0F08B0D18D511ACC800508BAE7B47D4EF@CI0026EXCH001U> remove From vaxzilla@jarai.org Fri Feb 1 01:47:50 2002 From: vaxzilla@jarai.org (Brian Chase) Date: Thu, 31 Jan 2002 17:47:50 -0800 (PDT) Subject: How to remove yourself from the list In-Reply-To: <200201312104.g0VL4lcf062297@m5p.com> Message-ID: On Thu, 31 Jan 2002 george+6bone@m5p.com wrote: > It's not clear why so many people are trying to leave the mailing list, > [...] Maybe an e-mail worm? It makes no sense that there would be this many "remove" requests hitting the list so suddenly. But then looking at the message headers, there's mix of mail clients involved--everything from Outlook, to Netscape, to Pine. Possibly it's a /wetware/ level e-mail worm where the people who've wanted off the list for a while are imitating the first message--due to an incorrect assumption that sending "remove" will actually take them off the list? Barring that, I'd say attribute it to aliens. -brian. From acwest-6bone@mail.bdkw.yi.org Fri Feb 1 02:15:03 2002 From: acwest-6bone@mail.bdkw.yi.org (acwest-6bone@mail.bdkw.yi.org) Date: Thu, 31 Jan 2002 21:15:03 -0500 (EST) Subject: remove In-Reply-To: Message-ID: There have been an unusually high rate of remove requests on this list. Are they all valid, or is this some new form of cancelbot attack? I've never heard of widespread malicous cancels on a mailing list, but it could certainly happen. In the case that these requests are not bogus, it migh make life simpler if we have a default footer with remove instructions. On the one hand, the bandwidth cost would certainly be higher. On the other hand, the frustatration costs would be lower. Just a thought... -- Craig West Ph: (416) 567-1491 | It's not a bug, acwest-sig@craigwest.net | It's a feature... From john@sixgirls.org Fri Feb 1 03:53:15 2002 From: john@sixgirls.org (John Klos) Date: Thu, 31 Jan 2002 22:53:15 -0500 (EST) Subject: Gag? Joke? was Re: remove In-Reply-To: <31C0F08B0D18D511ACC800508BAE7B47D4EF@CI0026EXCH001U> Message-ID: > remove This has got to be a joke... Although I don't get it, and I don't think it's particularly witty or clever, it has to be a joke... I seriously doubt there are so many people who are or have been seriously interested in IPv6 who can't figure out a mailing list... And to post "remove" after several emails describing how to remove one's self from the list... Ok - who put these people up to this? John Klos Sixgirls Computing Labs From hansolofalcon@worldnet.att.net Fri Feb 1 03:57:14 2002 From: hansolofalcon@worldnet.att.net (Gregg C Levine) Date: Thu, 31 Jan 2002 22:57:14 -0500 Subject: How to remove yourself from the list In-Reply-To: Message-ID: <001001c1aad4$88ee6cc0$ac60580c@who> Hello from Gregg C Levine normally with Jedi Knight Computers and writing for myself Indeed. This does get filed under the heading, "Unknown Origins". If anything else, it is not aliens. I work with several here, all staff members, and I am the only one with access to the system for sending out messages. Hence the disclaimer at the top. However, it could a grouping of them elsewhere on the list, and then there is that peculiar e-mail relay problem. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."  Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU] On Behalf Of > Brian Chase > Sent: Thursday, January 31, 2002 8:48 PM > To: george+6bone@m5p.com > Cc: 6bone@ISI.EDU > Subject: Re: How to remove yourself from the list > > On Thu, 31 Jan 2002 george+6bone@m5p.com wrote: > > > It's not clear why so many people are trying to leave the mailing list, > > [...] > > Maybe an e-mail worm? It makes no sense that there would be this many > "remove" requests hitting the list so suddenly. But then looking at the > message headers, there's mix of mail clients involved--everything from > Outlook, to Netscape, to Pine. > > Possibly it's a /wetware/ level e-mail worm where the people who've > wanted off the list for a while are imitating the first message--due to > an incorrect assumption that sending "remove" will actually take them > off the list? > > Barring that, I'd say attribute it to aliens. > > -brian. > > From lucifer@lightbearer.com Fri Feb 1 04:50:24 2002 From: lucifer@lightbearer.com (Joel Baker) Date: Thu, 31 Jan 2002 21:50:24 -0700 Subject: (6bone) Ingress filtering (was: asymmetric routing) In-Reply-To: <2B81403386729140A3A899A8B39B046405DE83@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Thu, Jan 31, 2002 at 03:56:26PM -0800 References: <2B81403386729140A3A899A8B39B046405DE83@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020131215024.A24240@lightbearer.com> On Thu, Jan 31, 2002 at 03:56:26PM -0800, Michel Py wrote: > > I am a protocol designer. One of the reasons I read and post to the > 6bone mailing list is to get a feeling of how features or requirements > will be perceived by the 6bone community, so I can decide to > incorporate or not these features/requirements in my protocol. Any protocol which does not support the ability to control traffic balance to some degree... will just be ignored. After all, why should a business spend millions of dollars to adopt a protocol which makes their connections far less efficient? On the other hand, there are protocols out there that do answer this issue, used in combination with IPv6 (or even IPv4) PA space. However, until they are widely adopted (read: part of the Windows network stack by default), trying to convince a business to spend vast dollars to hurt it's own interests is... well, just read the sentance. Anything which doesn't give out PI space, and routes, to everyone who has them now, just isn't likely to really fly. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/ From michel@arneill-py.sacramento.ca.us Fri Feb 1 06:32:14 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 31 Jan 2002 22:32:14 -0800 Subject: Gag? Joke? was Re: remove Message-ID: <2B81403386729140A3A899A8B39B046406C2BA@server2000.arneill-py.sacramento.ca.us> 6bone folk, It might be worth investigating Richard & Kathleen Pearson with a road runner in the Tampa area. I do NOT like the "If not complied with," part, it sounds like a threat. Can someone dump the logs from the server to see who is it that subscribed all these people probably without their consent? Michel. ------------------------------------------------ From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU]On Behalf Of Richard & Kathleen Pearson Sent: Monday, January 28, 2002 11:54 AM To: 'Matthew Lehman'; 'Pim van Pelt'; 'Sandy Wills' Cc: ipng@uni-muenster.de; '6bone' Subject: RE: asymmetric routing Please remove me from the distribution list. This is the 3rd time I have asked. If not complied with, I will report these messages a spam mail. Microsoft Mail Internet Headers Version 2.0 Received: from zephyr.isi.edu ([128.9.160.160]) by arneill-py.sacramento.ca.us ( IA Mail Server Version: 4.1.0. Build: 1000 ) ) ; Mon, 28 Jan 2002 15:21:02 -0800 Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id LAA16706 for 6bone-outgoing; Mon, 28 Jan 2002 11:48:34 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA16693 for <6bone@zephyr.isi.edu>; Mon, 28 Jan 2002 11:48:30 -0800 (PST) Received: from smtp-server1.tampabay.rr.com (smtp-server1.tampabay.rr.com [65.32.1.34]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g0SJmVg02794 for <6bone@ISI.EDU>; Mon, 28 Jan 2002 11:48:31 -0800 (PST) Received: from leeann (6535216hfc215.tampabay.rr.com [65.35.216.215]) by smtp-server1.tampabay.rr.com (8.11.2/8.11.2) with SMTP id g0SJk9X05479; Mon, 28 Jan 2002 14:46:09 -0500 (EST) Reply-To: From: "Richard & Kathleen Pearson" To: "'Matthew Lehman'" , "'Pim van Pelt'" , "'Sandy Wills'" Cc: , "'6bone'" <6bone@ISI.EDU> Subject: RE: asymmetric routing Date: Mon, 28 Jan 2002 14:54:07 -0500 Message-ID: 004d01c1a835$8cb093c0$d7d82341@tampabay.rr.com -----Original Message----- From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU]On Behalf Of Richard & Kathleen Pearson Sent: Monday, January 28, 2002 11:54 AM To: 'Matthew Lehman'; 'Pim van Pelt'; 'Sandy Wills' Cc: ipng@uni-muenster.de; '6bone' Subject: RE: asymmetric routing Please remove me from the distribution list. This is the 3rd time I have asked. If not complied with, I will report these messages a spam mail. Thanks From rain@bluecherry.net Fri Feb 1 06:49:29 2002 From: rain@bluecherry.net (Ben Winslow) Date: 01 Feb 2002 00:49:29 -0600 Subject: Really evil list happenings Message-ID: <1012546169.10608.4.camel@portal> --=-YCv4c8qsyRhlImVJZwti Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Is it just me, or is anyone else getting duplicate messages (headers and all) in addition to all the ill-guided remove requests? (rain@spock:/var/log) grep ISI.EDU syslog | awk -F'<' '{print $3}' | cut -d'>' -f1 | sort | uniq -c 1 000201c1aabc$63693f60$ac60580c@who 1 001001c1aad4$88ee6cc0$ac60580c@who 2 002601c1aa90$39db2400$8500a8c0@Dastun 1 09a401c1aa72$78a7c8a0$834009d9@napoli.consorziocini.it 2 1012518358.11439.7.camel@halcyon 1 20020131110931.A62999@ipv6.isternet.sk 2 200201312104.g0VL4lcf062297@m5p.com 1 2B81403386729140A3A899A8B39B046405DE83@server2000.arneill-py.sacramento.ca.= us 1 31C0F08B0D18D511ACC800508BAE7B47D4EF@CI0026EXCH001U 1 3C5916F0.7010903@heanet.ie 1 3C598855.4109BC5C@campus.cem.itesm.mx 1 3C59C112.A9F1F000@safeway.com 2 NEBBKBIFCMFDBPJPMCOBGEPACCAA.marc@bleuler.net 1 Pine.GSO.4.21.0201310457230.20269-100000@millennium.stealth.net 2 Pine.GSO.4.21.0201311635490.26130-100000@apache.utdallas.edu 1 Pine.LNX.4.33.0201312109550.11697-100000@gizmo.bdkw 1 Pine.NEB.4.43.0201311735500.21374-100000@haiku.jarai.net 1 Pine.NEB.4.44.0201312250320.19035-100000@reva.sixgirls.org I'm thinking it's not just me... --=20 Ben Winslow (rain@bluecherry.net) : Nothing is so firmly believed as=20 System Administrator : that which we least know. -- Bluecherry Internet Services : Michel de Montaigne =20 http://www.bluecherry.net/ :=20 (573) 592-0800 :=20 --=-YCv4c8qsyRhlImVJZwti Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Wjp42/SfDQAyrVERAnyoAJ9UaW/xGfHbKTqf7+SvQfnEno8z1wCgrLGR z2uFuO0YqeDsxngb82QT8kQ= =oEgy -----END PGP SIGNATURE----- --=-YCv4c8qsyRhlImVJZwti-- From michel@arneill-py.sacramento.ca.us Fri Feb 1 07:21:16 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 31 Jan 2002 23:21:16 -0800 Subject: (6bone) Ingress filtering (was: asymmetric routing) Message-ID: <2B81403386729140A3A899A8B39B046405DE88@server2000.arneill-py.sacramento.ca.us> Joel, I personally agree with your post, but I can tell you that not everybody shares our point of view, especially on this: > Anything which doesn't give out PI space, and routes, to > everyone who has them now, just isn't likely to really fly. Michel. -----Original Message----- From: Joel Baker [mailto:lucifer@lightbearer.com] Sent: Thursday, January 31, 2002 8:50 PM To: 6bone@ISI.EDU Subject: Re: (6bone) Ingress filtering (was: asymmetric routing) On Thu, Jan 31, 2002 at 03:56:26PM -0800, Michel Py wrote: > > I am a protocol designer. One of the reasons I read and post to the > 6bone mailing list is to get a feeling of how features or requirements > will be perceived by the 6bone community, so I can decide to > incorporate or not these features/requirements in my protocol. Any protocol which does not support the ability to control traffic balance to some degree... will just be ignored. After all, why should a business spend millions of dollars to adopt a protocol which makes their connections far less efficient? On the other hand, there are protocols out there that do answer this issue, used in combination with IPv6 (or even IPv4) PA space. However, until they are widely adopted (read: part of the Windows network stack by default), trying to convince a business to spend vast dollars to hurt it's own interests is... well, just read the sentance. Anything which doesn't give out PI space, and routes, to everyone who has them now, just isn't likely to really fly. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/ From kre@munnari.OZ.AU Fri Feb 1 07:58:45 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Fri, 01 Feb 2002 14:58:45 +0700 Subject: remove In-Reply-To: References: Message-ID: <2704.1012550325@brandenburg.cs.mu.OZ.AU> Date: Thu, 31 Jan 2002 21:15:03 -0500 (EST) From: Message-ID: | There have been an unusually high rate of remove requests on this list. Are | they all valid, or is this some new form of cancelbot attack? The other possibility is that someone added a list (an exploder) to the 6bone list, and people on that list have suddenly started getting traffic that they never intended, and want to make it go away. That could even happen if an address that used to be a valid address for an individual on the list was reinstated as the address of a list (and I have seen sillier things happen...) kre From arun.mahabier@cmg.nl Fri Feb 1 08:02:29 2002 From: arun.mahabier@cmg.nl (Arun Mahabier) Date: Fri, 1 Feb 2002 09:02:29 +0100 Subject: remove Message-ID: REMOVE From uncsec@wlink.com.np Fri Feb 1 10:00:41 2002 From: uncsec@wlink.com.np (Sakuntala Pradhan) Date: Fri, 01 Feb 2002 15:30:41 +0530 Subject: REMOVE Message-ID: <3C5A6748.1E0EC25@wlink.com.np> REMOVE From pekkas@netcore.fi Fri Feb 1 10:46:27 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Fri, 1 Feb 2002 12:46:27 +0200 (EET) Subject: (6bone) Ingress filtering (was: asymmetric routing) In-Reply-To: <20020131215024.A24240@lightbearer.com> Message-ID: On Thu, 31 Jan 2002, Joel Baker wrote: > Any protocol which does not support the ability to control traffic balance > to some degree... will just be ignored. After all, why should a business > spend millions of dollars to adopt a protocol which makes their connections > far less efficient? A protocol that will make multihoming work _at all_ would fit the criteria IMO. > interests is... well, just read the sentance. Anything which doesn't give > out PI space, and routes, to everyone who has them now, just isn't likely > to really fly. Problem with IPv6 multihoming is that IPv4 multihoming is so "easy" and works quite well. It may be we can't design a protocol or equivalent that will handle the scenarios responsibly and as well. -- 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 bmanning@ISI.EDU Fri Feb 1 12:38:57 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Fri, 1 Feb 2002 04:38:57 -0800 Subject: The welcome message Message-ID: <20020201123857.GJ5977@zed.isi.edu> 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@isi.edu": unsubscribe Or you can send mail to "majordomo@isi.edu" with the following command in the body of your email message: unsubscribe 6bone -------------------------------------------------------- There is a relay in singapore that I -think- has been squashed. There might be another one that is still being investigated. thanks for you patience --bill From larhonig@ix.netcom.com Fri Feb 1 14:03:59 2002 From: larhonig@ix.netcom.com (Larry Honig) Date: Fri, 01 Feb 2002 09:03:59 -0500 Subject: remove References: <2704.1012550325@brandenburg.cs.mu.OZ.AU> Message-ID: <3C5AA04F.E0624595@ix.netcom.com> Nah, you're all wrong - it was that iguana (again, I hate when that happens)... /Larry Honig Robert Elz wrote: > Date: Thu, 31 Jan 2002 21:15:03 -0500 (EST) > From: > Message-ID: > > | There have been an unusually high rate of remove requests on this list. Are > | they all valid, or is this some new form of cancelbot attack? > > The other possibility is that someone added a list (an exploder) to the 6bone > list, and people on that list have suddenly started getting traffic that they > never intended, and want to make it go away. That could even happen > if an address that used to be a valid address for an individual on the > list was reinstated as the address of a list (and I have seen sillier > things happen...) > > kre From wizard@italiansky.com Fri Feb 1 15:30:27 2002 From: wizard@italiansky.com (Matteo Tescione) Date: Fri, 1 Feb 2002 16:30:27 +0100 Subject: (6bone) Ingress filtering (was: asymmetric routing) References: Message-ID: <000701c1ab35$6085ea90$8cf51150@local.comv6.com> > Problem with IPv6 multihoming is that IPv4 multihoming is so "easy" and > works quite well. It may be we can't design a protocol or equivalent that > will handle the scenarios responsibly and as well. Easy??? According to you if ipv4 multihoming is easy, ipv6 multihoming will be impossible... And if ipv6 multihoming will be impossible I suggest to stop experimenting ipv6. Again, if I can, a simple question: what is ipv6 goal? Matteo Tescione IP & Security Manager COMV6 site ----- Original Message ----- From: "Pekka Savola" To: "Joel Baker" Cc: <6bone@ISI.EDU> Sent: Friday, February 01, 2002 11:46 AM Subject: Re: (6bone) Ingress filtering (was: asymmetric routing) > On Thu, 31 Jan 2002, Joel Baker wrote: > > Any protocol which does not support the ability to control traffic balance > > to some degree... will just be ignored. After all, why should a business > > spend millions of dollars to adopt a protocol which makes their connections > > far less efficient? > > A protocol that will make multihoming work _at all_ would fit the criteria > IMO. > > > interests is... well, just read the sentance. Anything which doesn't give > > out PI space, and routes, to everyone who has them now, just isn't likely > > to really fly. > > > -- > 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 hansolofalcon@worldnet.att.net Fri Feb 1 17:31:02 2002 From: hansolofalcon@worldnet.att.net (Gregg C Levine) Date: Fri, 1 Feb 2002 12:31:02 -0500 Subject: Really evil list happenings In-Reply-To: <1012546169.10608.4.camel@portal> Message-ID: <003901c1ab46$38e9ee80$8f51580c@who> Hello from Gregg C Levine writing for myself Its not just you, Ben. I am as well. I wrote a message to the blockheads at the address which is causing the relay, and they sent me a form letter response, you know the one, stating that I should check their FAQ. I replied that the problem does not fit into their FAQ, so they darn well better get back to me, on it. As of right now, they have not. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."  Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU] On Behalf Of Ben > Winslow > Sent: Friday, February 01, 2002 1:49 AM > To: 6bone@ISI.EDU > Subject: Really evil list happenings > > Is it just me, or is anyone else getting duplicate messages (headers and > all) in addition to all the ill-guided remove requests? > > (rain@spock:/var/log) grep ISI.EDU syslog | awk -F'<' '{print $3}' | cut > -d'>' -f1 | sort | uniq -c > 1 000201c1aabc$63693f60$ac60580c@who > 1 001001c1aad4$88ee6cc0$ac60580c@who > 2 002601c1aa90$39db2400$8500a8c0@Dastun > 1 09a401c1aa72$78a7c8a0$834009d9@napoli.consorziocini.it > 2 1012518358.11439.7.camel@halcyon > 1 20020131110931.A62999@ipv6.isternet.sk > 2 200201312104.g0VL4lcf062297@m5p.com > 1 > 2B81403386729140A3A899A8B39B046405DE83@server2000.arneill- > py.sacramento.ca.us > 1 31C0F08B0D18D511ACC800508BAE7B47D4EF@CI0026EXCH001U > 1 3C5916F0.7010903@heanet.ie > 1 3C598855.4109BC5C@campus.cem.itesm.mx > 1 3C59C112.A9F1F000@safeway.com > 2 NEBBKBIFCMFDBPJPMCOBGEPACCAA.marc@bleuler.net > 1 Pine.GSO.4.21.0201310457230.20269-100000@millennium.stealth.net > 2 Pine.GSO.4.21.0201311635490.26130-100000@apache.utdallas.edu > 1 Pine.LNX.4.33.0201312109550.11697-100000@gizmo.bdkw > 1 Pine.NEB.4.43.0201311735500.21374-100000@haiku.jarai.net > 1 Pine.NEB.4.44.0201312250320.19035-100000@reva.sixgirls.org > > I'm thinking it's not just me... > > -- > Ben Winslow (rain@bluecherry.net) : Nothing is so firmly believed as > System Administrator : that which we least know. -- > Bluecherry Internet Services : Michel de Montaigne > http://www.bluecherry.net/ : > (573) 592-0800 : From hansolofalcon@worldnet.att.net Fri Feb 1 17:33:25 2002 From: hansolofalcon@worldnet.att.net (Gregg C Levine) Date: Fri, 1 Feb 2002 12:33:25 -0500 Subject: The welcome message In-Reply-To: <20020201123857.GJ5977@zed.isi.edu> Message-ID: <003a01c1ab46$8de5e9c0$8f51580c@who> Hello from Gregg C Levine writing for myself Thank you, Bill Manning for posting this message. However the Singapore relay has not been squashed, they are still doing it. Please add them back to your list. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."  Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU] On Behalf Of Bill > Manning > Sent: Friday, February 01, 2002 7:39 AM > To: 6bone@ISI.EDU > Subject: The welcome message > > > > 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@isi.edu": > > unsubscribe > > Or you can send mail to "majordomo@isi.edu" with the following command > in the body of your email message: > > unsubscribe 6bone > > -------------------------------------------------------- > > There is a relay in singapore that I -think- has been squashed. > There might be another one that is still being investigated. > > thanks for you patience > > --bill From pekkas@netcore.fi Fri Feb 1 17:53:01 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Fri, 1 Feb 2002 19:53:01 +0200 (EET) Subject: (6bone) Ingress filtering (was: asymmetric routing) In-Reply-To: <000701c1ab35$6085ea90$8cf51150@local.comv6.com> Message-ID: On Fri, 1 Feb 2002, Matteo Tescione wrote: > > Problem with IPv6 multihoming is that IPv4 multihoming is so "easy" and > > works quite well. It may be we can't design a protocol or equivalent that > > will handle the scenarios responsibly and as well. > Easy??? Just get prefix A.B.C.0/24 and two ISP's, pay them, configure BGP with them and advertise as appropriate. > According to you if ipv4 multihoming is easy, ipv6 multihoming will be > impossible... > And if ipv6 multihoming will be impossible I suggest to stop experimenting > ipv6. Who said the (only) goal of IPv6 was multihoming? This can be seen as a good thing: it forces everyone to stop the irresponsible practise of cluttering global routing table (among others). A drawback is that we don't have anything really concrete to offer for site multihoming problem in the place of old practises; there are a few proposals though. > ----- Original Message ----- > From: "Pekka Savola" > To: "Joel Baker" > Cc: <6bone@ISI.EDU> > Sent: Friday, February 01, 2002 11:46 AM > Subject: Re: (6bone) Ingress filtering (was: asymmetric routing) > > > > On Thu, 31 Jan 2002, Joel Baker wrote: > > > Any protocol which does not support the ability to control traffic > balance > > > to some degree... will just be ignored. After all, why should a business > > > spend millions of dollars to adopt a protocol which makes their > connections > > > far less efficient? > > > > A protocol that will make multihoming work _at all_ would fit the criteria > > IMO. > > > > > interests is... well, just read the sentance. Anything which doesn't > give > > > out PI space, and routes, to everyone who has them now, just isn't > likely > > > to really fly. > > > > > > -- > > 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 > > > -- 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 wizard@italiansky.com Fri Feb 1 18:54:08 2002 From: wizard@italiansky.com (Matteo Tescione) Date: Fri, 1 Feb 2002 19:54:08 +0100 Subject: (6bone) Ingress filtering (was: asymmetric routing) References: Message-ID: <004701c1ab51$d4efa3a0$8cf51150@local.comv6.com> I don't mean that the only goal of ipv6 is multihoming. I only think that multihoming in ipv6 has to be more simple than v4... A simple situation is where I get 1 prefix and 2 upstream, i don't need more... Regards, Matteo ----- Original Message ----- From: "Pekka Savola" To: "Matteo Tescione" Cc: <6bone@ISI.EDU> Sent: Friday, February 01, 2002 6:53 PM Subject: Re: (6bone) Ingress filtering (was: asymmetric routing) > On Fri, 1 Feb 2002, Matteo Tescione wrote: > > > Problem with IPv6 multihoming is that IPv4 multihoming is so "easy" and > > > works quite well. It may be we can't design a protocol or equivalent that > > > will handle the scenarios responsibly and as well. > > Easy??? > > Just get prefix A.B.C.0/24 and two ISP's, pay them, configure BGP with > them and advertise as appropriate. > > > According to you if ipv4 multihoming is easy, ipv6 multihoming will be > > impossible... > > And if ipv6 multihoming will be impossible I suggest to stop experimenting > > ipv6. > > Who said the (only) goal of IPv6 was multihoming? > > This can be seen as a good thing: it forces everyone to stop the > irresponsible practise of cluttering global routing table (among others). > A drawback is that we don't have anything really concrete to offer for > site multihoming problem in the place of old practises; there are a few > proposals though. > > > ----- Original Message ----- > > From: "Pekka Savola" > > To: "Joel Baker" > > Cc: <6bone@ISI.EDU> > > Sent: Friday, February 01, 2002 11:46 AM > > Subject: Re: (6bone) Ingress filtering (was: asymmetric routing) > > > > > > > On Thu, 31 Jan 2002, Joel Baker wrote: > > > > Any protocol which does not support the ability to control traffic > > balance > > > > to some degree... will just be ignored. After all, why should a business > > > > spend millions of dollars to adopt a protocol which makes their > > connections > > > > far less efficient? > > > > > > A protocol that will make multihoming work _at all_ would fit the criteria > > > IMO. > > > > > > > interests is... well, just read the sentance. Anything which doesn't > > give > > > > out PI space, and routes, to everyone who has them now, just isn't > > likely > > > > to really fly. > > > > > > > > > -- > > > 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 > > > > > > > -- > 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 michel@arneill-py.sacramento.ca.us Fri Feb 1 21:57:26 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 1 Feb 2002 13:57:26 -0800 Subject: (6bone) Ingress filtering (was: asymmetric routing) Message-ID: <2B81403386729140A3A899A8B39B046405DE90@server2000.arneill-py.sacramento.ca.us> > Matteo Tescione wrote: > I don't mean that the only goal of ipv6 is multihoming. > I only think that multihoming in ipv6 has to be more simple than > v4... A simple situation is where I get 1 prefix and 2 upstream, > i don't need more... Unfortunately, it turn outs that IPv6 multihoming is likely to be a complicated, multi-facetted solution. Michel. From willss@mediaone.net Sat Feb 2 00:47:44 2002 From: willss@mediaone.net (Sandy Wills) Date: Fri, 01 Feb 2002 19:47:44 -0500 Subject: remove References: Message-ID: <3C5B3730.43CDDA59@mediaone.net> acwest-6bone@mail.bdkw.yi.org wrote: > In the case that these requests are not bogus, it migh make life simpler if > we have a default footer with remove instructions. On the one hand, the > bandwidth cost would certainly be higher. On the other hand, the frustatration > costs would be lower. Just a thought... The gripping hand is, those subscribers who are unable to remember how to unsubscribe, and are unable to locate the instructions they recieved when they first subscribed, will probably also be unable to read the footer you suggest. But, it's certainly worth a try. For me, at least. I've got a T1 and I don't mind the wasted bandwidth. Those paying per byte or per second for a dialup may object. -- : Unable to locate coffee. Operator halted. From aztech@home.se Sat Feb 2 01:20:58 2002 From: aztech@home.se (Andreas Lundberg) Date: Sat, 02 Feb 2002 02:20:58 +0100 Subject: remove Message-ID: <3C5B3EFA.1020800@home.se> REMOVE From lucifer@lightbearer.com Sat Feb 2 01:22:52 2002 From: lucifer@lightbearer.com (Joel Baker) Date: Fri, 1 Feb 2002 18:22:52 -0700 Subject: (6bone) Ingress filtering (was: asymmetric routing) In-Reply-To: ; from pekkas@netcore.fi on Fri, Feb 01, 2002 at 07:53:01PM +0200 References: <000701c1ab35$6085ea90$8cf51150@local.comv6.com> Message-ID: <20020201182252.A30743@lightbearer.com> On Fri, Feb 01, 2002 at 07:53:01PM +0200, Pekka Savola wrote: > On Fri, 1 Feb 2002, Matteo Tescione wrote: > > > Problem with IPv6 multihoming is that IPv4 multihoming is so "easy" and > > > works quite well. It may be we can't design a protocol or equivalent that > > > will handle the scenarios responsibly and as well. > > Easy??? > > Just get prefix A.B.C.0/24 and two ISP's, pay them, configure BGP with > them and advertise as appropriate. Indeed. As I've said in other fora: the going rate for aquiring a swamp /24 on the gray market, the last time I checked, was about $30,000. > > According to you if ipv4 multihoming is easy, ipv6 multihoming will be > > impossible... > > And if ipv6 multihoming will be impossible I suggest to stop experimenting > > ipv6. > > Who said the (only) goal of IPv6 was multihoming? > > This can be seen as a good thing: it forces everyone to stop the > irresponsible practise of cluttering global routing table (among others). > A drawback is that we don't have anything really concrete to offer for > site multihoming problem in the place of old practises; there are a few > proposals though. You say "cluttering global routing table", I say "protecting my business investment from being vulnerable to my upstream provider's vagaries". The Internet is no longer comprised of a bunch of folks who are mostly using it as a giant experiment and are losing no money for changing over (such as was the case when IPv4 was adopted, for the most part). For the record... I strongly favor the adoption of protocols such as SCTP which can handle the fundamental problem of one machine having multiple addresses on different networks (which was not actually part of the early design requirements, except for routing gateways), which work under both IPv4 and IPv6, and remove something like 90-95% of the use for BGP for any form of end-customer (IE, non-ISP folks). As has been pointed out to me privately, there are already folks who clearly are *not* ISPs who have found it worthwhile to apply for pTLA status, simply to ensure that they have a globally routable block of space. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/ From FRAJAN@ALGHANIM.COM Sat Feb 2 04:45:51 2002 From: FRAJAN@ALGHANIM.COM (Flex Rajan) Date: Sat, 2 Feb 2002 07:45:51 +0300 Subject: remove Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1ABA4.7DE35040 Content-Type: text/plain REMOVE ------_=_NextPart_001_01C1ABA4.7DE35040 Content-Type: text/html Message
REMOVE
 
------_=_NextPart_001_01C1ABA4.7DE35040-- From raju@linux-delhi.org Sat Feb 2 05:00:14 2002 From: raju@linux-delhi.org (Raju Mathur) Date: Sat, 2 Feb 2002 10:30:14 +0530 (IST) Subject: remove In-Reply-To: <3C5B3730.43CDDA59@mediaone.net> References: <3C5B3730.43CDDA59@mediaone.net> Message-ID: <15451.29278.462227.748368@mail.linux-delhi.org> >>>>> "Sandy" == Sandy Wills writes: Sandy> acwest-6bone@mail.bdkw.yi.org wrote: >> In the case that these requests are not bogus, it migh make >> life simpler if we have a default footer with remove >> instructions. On the one hand, the bandwidth cost would >> certainly be higher. On the other hand, the frustatration costs >> would be lower. Just a thought... Sandy> The gripping hand is, those subscribers who are unable Sandy> to remember how to unsubscribe, and are unable to locate Sandy> the instructions they recieved when they first subscribed, Sandy> will probably also be unable to read the footer you Sandy> suggest. But, it's certainly worth a try. For me, at Sandy> least. I've got a T1 and I don't mind the wasted Sandy> bandwidth. Those paying per byte or per second for a Sandy> dialup may object. After managing 4 lists with over 1500 subscribers, I can testify that the number of literate people on any mailing list is close to zero. Sure, they can see black-and-white patterns on paper/screen and make words out of those patterns, but ask them to understand and follow simple instructions and you may as well wish for, umm, something which is impossible to obtain? Regards, -- Raju -- Raju Mathur raju@kandalaya.org http://kandalaya.org/ It is the mind that moves From mbiber@apnetworx.com.au Sat Feb 2 07:28:38 2002 From: mbiber@apnetworx.com.au (Michael Biber) Date: Sat, 2 Feb 2002 18:28:38 +1100 Subject: remove In-Reply-To: <3C5B3730.43CDDA59@mediaone.net> Message-ID: <00f001c1abbb$3b400550$0200a8c0@CO3051040A> Some other lists deal with this by auto issuing a monthly reminder of the key instructions. It either prompts people to leave or at the least, you only have to remember for 4 weeks, where the instructions are hiding. Sometimes, failure to comply isn't so much cluelesness, but not having great English skills...FWIW. Mike B. -----Original Message----- From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU] On Behalf Of Sandy Wills Sent: Saturday, 2 February 2002 11:48 AM To: 6bone@ISI.EDU Subject: Re: remove acwest-6bone@mail.bdkw.yi.org wrote: > In the case that these requests are not bogus, it migh make life > simpler if we have a default footer with remove instructions. On the > one hand, the bandwidth cost would certainly be higher. On the other > hand, the frustatration costs would be lower. Just a thought... The gripping hand is, those subscribers who are unable to remember how to unsubscribe, and are unable to locate the instructions they recieved when they first subscribed, will probably also be unable to read the footer you suggest. But, it's certainly worth a try. For me, at least. I've got a T1 and I don't mind the wasted bandwidth. Those paying per byte or per second for a dialup may object. -- : Unable to locate coffee. Operator halted. From lporter@cw.net Sat Feb 2 10:48:18 2002 From: lporter@cw.net (Leigh Porter) Date: Sat, 2 Feb 2002 10:48:18 +0000 Subject: remove In-Reply-To: <00f001c1abbb$3b400550$0200a8c0@CO3051040A> References: <00f001c1abbb$3b400550$0200a8c0@CO3051040A> Message-ID: <200202021049.g12Anbh01930@relay.mail.insnet.cw.net> On Saturday 02 February 2002 07:28, Michael Biber wrote: A URL to remove peopel from the list at the end of each message that goes through the list server will fix all of this. People who want to be out, just go to that URL, enter their email address and when they reply to the confirmation email (just like when you subscribe) you are removed from the list. Thay way, removal is just a simple operation away that does not require anybody to use their brains ;-) -- Leigh > Some other lists deal with this by auto issuing a monthly reminder of > the key instructions. It either prompts people to leave or at the least, > you only have to remember for 4 weeks, where the instructions are > hiding. Sometimes, failure to comply isn't so much cluelesness, but not > having great English skills...FWIW. From tlund@nxs.se Tue Feb 5 00:03:55 2002 From: tlund@nxs.se (Tomas Lund) Date: Tue, 5 Feb 2002 01:03:55 +0100 (CET) Subject: (6bone) Ingress filtering (was: asymmetric routing) In-Reply-To: <20020201182252.A30743@lightbearer.com> Message-ID: On Fri, 1 Feb 2002, Joel Baker wrote: > Indeed. As I've said in other fora: the going rate for aquiring a > swamp /24 on the gray market, the last time I checked, was about > $30,000. Every tought of just requesting the block you need from {ARIN,RIPE,APNIC}? From lucifer@lightbearer.com Tue Feb 5 01:10:10 2002 From: lucifer@lightbearer.com (Joel Baker) Date: Mon, 4 Feb 2002 18:10:10 -0700 Subject: (6bone) Ingress filtering (was: asymmetric routing) In-Reply-To: ; from tlund@nxs.se on Tue, Feb 05, 2002 at 01:03:55AM +0100 References: <20020201182252.A30743@lightbearer.com> Message-ID: <20020204181010.A29173@lightbearer.com> On Tue, Feb 05, 2002 at 01:03:55AM +0100, Tomas Lund wrote: > On Fri, 1 Feb 2002, Joel Baker wrote: > > > Indeed. As I've said in other fora: the going rate for aquiring a > > swamp /24 on the gray market, the last time I checked, was about > > $30,000. > > Every tought of just requesting the block you need from {ARIN,RIPE,APNIC}? Yup. Thought of it, and immediately dismissed it as a waste of time. Why? Anyone who follows NANOG can give you a summary of what the state of any sort of micro-allocation via ARIN is: in a word, "non-functional". Unless and until ARIN hands out /24s ** and major providers listen to those allocations ** it would be nigh-useless to even bother. Besides, my personal network can stand to be renumbered every so often. I'm not trying to run a business with network reachabilty as a core requirement and I don't run BGP, or even multiple upstream circuits. However, when I was asked, professionally, to do an architecture model for a business which needed at most a /27 worth of IPs, but absolutely had to have 5-6 nines of uptime (financial application provider) across the system as a whole... well, let's just say that I did the pricing above. I suppose I could have tried to find out how much it would cost to bribe ARIN to give me an old swamp /24 that someone returned, but the last time I checked, they weren't re-assigning any of that space legitimately... (Obviously from the abive, neither RIPE or APNIC would be of much use to me either.) -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/ From paul@clubi.ie Tue Feb 5 03:37:18 2002 From: paul@clubi.ie (Paul Jakma) Date: Tue, 5 Feb 2002 03:37:18 +0000 (GMT) Subject: (6bone) Ingress filtering (was: asymmetric routing) In-Reply-To: <2B81403386729140A3A899A8B39B046405DE90@server2000.arneill-py.sacramento.ca.us> Message-ID: On Fri, 1 Feb 2002, Michel Py wrote: > Unfortunately, it turn outs that IPv6 multihoming is likely to be > a complicated, multi-facetted solution. hmm... why not use DNS in some way? The infrastructure is there, the address space delegations (and glue) will be there. Create a new DNS RR to specify border routers (BR RR?), similar to SRV RR allow it to specify priorities and weighting of equal priority border routers. end-site client has the registrar (or have his ISP) enter this records as glue at the point of delegation. eg: $ORIGIN \[x3FFE123456789abc/64].ip6.arpa. @ BR 10 40 3ffe:100:100:100:100:1 BR 10 40 3ffe:100:100:100:100:2 BR 10 10 3ffe:200:200:200:200:1 BR 20 50 3ffe:300:100:100:100:1 BR 20 50 3ffe:300:100:100:100:2 @ NS foo.ipv6.acme.org. NS bar.ipv6.acme.org. If you specify that BR records /must/ reference routers whose address is covered by a valid and well-aggregrated BGP prefix advertisement (one that will not be filtered out), then the above will work fine. now you dont need to invent another protocol (just slightly extend an existing and well-proven protocol), you just need to teach routers to lookup 'BR' records for certain prefixes. (and most routers already have a DNS client implementation.) it'd help even more if the IPv6 address registrars handed out 'multihome IPv6' allocations from well-defined prefix ranges, then you could limit 'BR' lookups to only happen when prefix is from such a range. On possible (rough) process could be something like: is prefix 'foo' from 'multihome-ipv6' allocation? yes -> prefix=get-br(prefix) normal_bgp_lookup(prefix) get-br() { - lookup multihome-BGP view yes -> return BR else -> { - lookup 'foo'.ip6.arpa BR - for each BR in next_priority where address != 'multihome-ipv6' connect to BR using 'light-bgp' get advertisements, inject into multihome-BGP view } - lookup multihome-BGP view -> return BR } the entries in 'multihome-BGP' view would be purged after some time out. 'light-BGP would some kind of lightweight multihop on-the-fly peering BGP, purely to ask a BGP peer "give me your advertisements for xyz". (or alternatively, instead of 'lightweight BGP' you just need some other "can you route for this address?" "yes/no" protocol.) So customer advertises his networks to his ISPs via BGP. 3rd party routers that are 'close enough' to pick up those advertisements (via private peering agreements and route-map overrides, whatever) will pick up the BGP advertisements. Else 3rd party router looks up the 'BR' DNS RR to find the border routers (which are the ISPs routers). biggest problem is that the load is mainly on the ip6.{arpa,int} root servers. (but delegation of prefixes to many servers would mitigate this). mad idea? > Michel. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Don't be irreplaceable, if you can't be replaced, you can't be promoted. From micklesc@aol.net Tue Feb 5 15:36:52 2002 From: micklesc@aol.net (Cleve Mickles) Date: Tue, 5 Feb 2002 10:36:52 -0500 Subject: 6bone whois database In-Reply-To: Message-ID: Is anyone having problems downloading the whois database? My cron job hasn't been able to get in over the last few days. Also, have we considered cleaning up the database? There are a number of hosts that are referenced from companies that no longer exist and hence the various pingers out there including ours just mark the hosts as unknown. ====================================================== Date: Tue, 5 Feb 2002 02:15:03 -0500 (EST) Subject: Output from "cron" command Your "cron" job produced the following output: --02:15:01-- ftp://whois.6bone.net/6bone/6bone.db.gz => `6bonereg.2144.gz' Connecting to whois.6bone.net:21... Connection to whois.6bone.net:21 refused. ====================================================== Cleve... Cleve Mickles Network Architect America Online, Network Operations From Jan Oravec Tue Feb 5 16:41:34 2002 From: Jan Oravec (Jan Oravec) Date: Tue, 5 Feb 2002 17:41:34 +0100 Subject: (6bone) multihoming (was: Ingress filtering (was: asymmetric routing)) In-Reply-To: ; from paul@clubi.ie on Tue, Feb 05, 2002 at 03:37:18AM +0000 References: <2B81403386729140A3A899A8B39B046405DE90@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020205174134.A78473@ipv6.isternet.sk> Hello, > biggest problem is that the load is mainly on the ip6.{arpa,int} root > servers. (but delegation of prefixes to many servers would mitigate > this). > > mad idea? very mad, there is a bigger problem: this would drastically slow-down packet processing... DNS lookup may take too long... routers would require enough large cache for this, etc. The better would be to develop new routing protocol... It's proved existence of protocol which would require amortized time O(log N) for processing single update and memory O(K) for routing record of some prefix, where N is number of prefixes advertised and K is number of peers on router. The AS-PATH entry is probably good only for routing-loop detection (which can be solved other way), debugging and making BGP useless for multihoming of every site. Only few of us does routing based on the middle part of it. (usually when peer A advertises us a prefix with as-path A B ... X, we just care about A and X, not about part between). Thus we require memory O(NK), which is not a problem for several millions prefixes. About time analysis, amortized O(log N) per update gives us initial time O(N log N) for establishing session. For N -> several millions it gives us convergence time a few seconds. For IPv6 and advertisements of zones /48 and less, log N is at most 48 and I can imagine hardware solution to reduce time to O(N), thus we will be able to have billion of multihomed prefixes in presence. At the moment I do not have enough time to work on developing it, be cause I have a lot of work with our project XS26, but in 3-4 months I will be able to do so. I will consult that with multi6 WG when I have something ready. Best Regards, -- Jan Oravec project coordinator XS26 - 'Access to IPv6' jan.oravec@xs26.net From david@IPRG.nokia.com Tue Feb 5 18:33:50 2002 From: david@IPRG.nokia.com (David Kessens) Date: Tue, 5 Feb 2002 10:33:50 -0800 Subject: 6bone whois database In-Reply-To: ; from micklesc@aol.net on Tue, Feb 05, 2002 at 10:36:52AM -0500 References: Message-ID: <20020205103350.B24491@iprg.nokia.com> Cleve, On Tue, Feb 05, 2002 at 10:36:52AM -0500, Cleve Mickles wrote: > > Is anyone having problems downloading the whois > database? My cron job hasn't been able to > get in over the last few days. I will fix this today. In the future, if you experience any problem, you can contact me directly. I hope this helps, David K. --- From olof@s8n.pp.se Tue Feb 5 22:16:53 2002 From: olof@s8n.pp.se (Olof Samuelsson) Date: Tue, 05 Feb 2002 23:16:53 +0100 Subject: remove In-Reply-To: <200202021049.g12Anbh01930@relay.mail.insnet.cw.net> References: <00f001c1abbb$3b400550$0200a8c0@CO3051040A> <200202021049.g12Anbh01930@relay.mail.insnet.cw.net> Message-ID: >>>>> "Leigh" == Leigh Porter writes: > On Saturday 02 February 2002 07:28, Michael Biber wrote: A URL to > remove peopel from the list at the end of each message that goes > through the list server will fix all of this. People who want to be > out, just go to that URL, enter their email address and when they > reply to the confirmation email (just like when you subscribe) you > are removed from the list. How about the List-Unsubscribe header from RFC2369? I think at least recent pines support it. Why does all the unsubscription attempts look almost the same? Subject: remove and the body containing only "remove", albeit with some case permutations. I find that strange. /Olof -- From IPSix Developer" 1)With ref to section 3.3 of RFC 2473 : "The tunnel exit-point node, which decapsulates the tunnel packets, and the destination node, which receives the resulting original packets can be the same node". Does it mean tunnel exit-point IPv6 address and original packets destination IPv6 address are same? If they are same, how do we configure the route for the destination V6 address at the tunnel entry point? 2)With ref to section 7.1(a) of RFC 2473: When the IPv6 packet size is larger than IPv6 min link MTU, the ICMPv6 pkt too big msg is sent with MTU as max(tunnel MTU, IPv6 min link MTU) . If the furthur received packets' size is larger than IPv6 min link MTU, again TOO BIG message will be sent and a looping will occur? how to avoid this? From Francis.Dupont@enst-bretagne.fr Wed Feb 6 10:25:14 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Wed, 06 Feb 2002 11:25:14 +0100 Subject: generic v6 tunneling In-Reply-To: Your message of 06 Feb 2002 09:33:50 GMT. <20020206093350.531.qmail@mailweb19.rediffmail.com> Message-ID: <200202061025.g16APEg73338@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: 1)With ref to section 3.3 of RFC 2473 : "The tunnel exit-point node, which decapsulates the tunnel packets, and the destination node, which receives the resulting original packets can be the same node". Does it mean tunnel exit-point IPv6 address and original packets destination IPv6 address are same? => "can be" but usually they are configured to be different because: - this can too easily mess the routing system - there is no reason to encapsulate such packets (they can be sent directly). If they are same, how do we configure the route for the destination V6 address at the tunnel entry point? => there is already a route to the exit-point, not using the tunnel. If you try to misconfigure a tunnel with a route to the exit-point through the tunnel, good systems will detect the error and won't crash trying infinite encapsulation. But this is harder if the loop is distributed between different nodes so section 4 describes this kind of problems and some solutions (note that 4.1.2 check detects your problem). 2)With ref to section 7.1(a) of RFC 2473: When the IPv6 packet size is larger than IPv6 min link MTU, the ICMPv6 pkt too big msg is sent with MTU as max(tunnel MTU, IPv6 min link MTU) . If the furthur received packets' size is larger than IPv6 min link MTU, again TOO BIG message will be sent => yes, ICMPv6 are sent on errors but are rate limited. and a looping will occur? => I believe your loop is errors on errors. There are two counter-measures: (draft-ietf-ipngwg-icmp-v3-02.txt section 2.4) - (c) Every ICMPv6 error message (type < 128) includes as much of the IPv6 offending (invoking) packet (the packet that caused the error) as will fit without making the error message packet exceed the minimum IPv6 MTU. - (e.1) An ICMPv6 error message MUST NOT be sent as a result of receiving an ICMPv6 error message. (don't forget (f) aka rate limitation too). how to avoid this? => understand and implement carefully the specs (:-)! Regards Francis.Dupont@enst-bretagne.fr From IPSix Developer" The looping i'm refering to section 7.1(a) of RFC 2473, occurs when the ipv6 packet size is checked against the min. link MTU always- which is always 1280 (or PathMTU ???) I'm not refering to errors on errors loop. On Wed, 06 Feb 2002 Francis Dupont wrote : > In your previous mail you wrote: > > 1)With ref to section 3.3 of RFC 2473 : > > "The tunnel exit-point node, which decapsulates the > tunnel packets, > and the destination node, which receives the > resulting original > packets can be the same node". > > Does it mean tunnel exit-point IPv6 address and > original packets > destination IPv6 address are same? > > => "can be" but usually they are configured to be > different because: > - this can too easily mess the routing system > - there is no reason to encapsulate such packets (they > can be sent > directly). > > If they are same, how do we configure the route for > the destination > V6 address at the tunnel entry point? > > => there is already a route to the exit-point, not > using the tunnel. > > If you try to misconfigure a tunnel with a route to the > exit-point > through the tunnel, good systems will detect the error > and won't crash > trying infinite encapsulation. But this is harder if > the loop is distributed > between different nodes so section 4 describes this > kind of problems > and some solutions (note that 4.1.2 check detects your > problem). > > 2)With ref to section 7.1(a) of RFC 2473: > > When the IPv6 packet size is larger than IPv6 min > link MTU, the > ICMPv6 pkt too big msg is sent with MTU as > max(tunnel MTU, IPv6 min > link MTU) . > > If the furthur received packets' size is larger than > IPv6 min link > MTU, again TOO BIG message will be sent > > => yes, ICMPv6 are sent on errors but are rate limited. > > and a looping will occur? > > => I believe your loop is errors on errors. There are > two counter-measures: > (draft-ietf-ipngwg-icmp-v3-02.txt section 2.4) > - (c) Every ICMPv6 er IPv6 offending (invoking) packet (the packet that > caused the > error) as will fit without making the error message > packet > exceed the minimum IPv6 MTU. > - (e.1) An ICMPv6 error message MUST NOT be sent as a > result of > receiving an ICMPv6 error message. > (don't forget (f) aka rate limitation too). > > how to avoid this? > > => understand and implement carefully the specs (:-)! > > Regards > > Francis.Dupont@enst-bretagne.fr From deering@cisco.com Wed Feb 6 18:49:45 2002 From: deering@cisco.com (Steve Deering) Date: Wed, 6 Feb 2002 10:49:45 -0800 Subject: generic v6 tunneling In-Reply-To: <20020206093350.531.qmail@mailweb19.rediffmail.com> References: <20020206093350.531.qmail@mailweb19.rediffmail.com> Message-ID: At 9:33 AM +0000 2/6/02, IPSix Developer wrote: >1)With ref to section 3.3 of RFC 2473 : > "The tunnel exit-point node, which decapsulates the tunnel packets, and >the destination node, which receives the resulting original packets can >be the same node". > >Does it mean tunnel exit-point IPv6 address and original packets >destination IPv6 address are same? Possibly, but not necessarily. If the tunnel is treated as a separate link, the exit endpoint of the tunnel will have its own IPv6 address(es), distinct from those of the physical interface at which the tunnel terminates. But is also perfectly "legal" to send an IPv6 packet encapsulated within another IPv6 packet, in which both the inner and outer destination addresses are the same. > > If they are same, how do we configure >the route for the destination V6 address at the tunnel entry point? That is just an example of a router with more than one path to the same destination. That is handled as normal, either using routing protocols to choose the "shortest" or "best" path, or by configuration (a "static route"). >2)With ref to section 7.1(a) of RFC 2473: > >When the IPv6 packet size is larger than IPv6 min link MTU, the ICMPv6 >pkt too big msg is sent with MTU as max(tunnel MTU, IPv6 min link MTU) . > >If the furthur received packets' size is larger than IPv6 min link MTU, >again TOO BIG message will be sent and a looping will occur? how to >avoid this? If the source node ignores the Packet Too Big message and continues to send packets that exceed max(tunnel MTU, IPv6 min link MTU), those packets will be dropped and will trigger additional Packet Too Big messages, subject to the general rate limiting requirement imposed on transmitting ICMP error messages. Steve From deering@cisco.com Wed Feb 6 18:54:37 2002 From: deering@cisco.com (Steve Deering) Date: Wed, 6 Feb 2002 10:54:37 -0800 Subject: generic v6 tunneling In-Reply-To: <200202061025.g16APEg73338@givry.rennes.enst-bretagne.fr> References: <200202061025.g16APEg73338@givry.rennes.enst-bretagne.fr> Message-ID: At 11:25 AM +0100 2/6/02, Francis Dupont wrote: >> Does it mean tunnel exit-point IPv6 address and original packets >> destination IPv6 address are same? > > - there is no reason to encapsulate such packets (they can be sent > directly). That's not the case if the tunnel entry point node is not the original source node. Steve From Francis.Dupont@enst-bretagne.fr Wed Feb 6 19:51:05 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Wed, 06 Feb 2002 20:51:05 +0100 Subject: generic v6 tunneling In-Reply-To: Your message of Wed, 06 Feb 2002 10:54:37 PST. Message-ID: <200202061951.g16Jp5g75964@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: >> Does it mean tunnel exit-point IPv6 address and original packets >> destination IPv6 address are same? > > - there is no reason to encapsulate such packets (they can be sent > directly). That's not the case if the tunnel entry point node is not the original source node. => this changes nothing: in both cases there is a route to the destination and packets will follow it. The difference is they can be encapsulated or not, the visible source address doesn't matter... Regards Francis.Dupont@enst-bretagne.fr PS: differences can only be in source address based policies (QoS, IPsec, policy routing, etc). From deering@cisco.com Wed Feb 6 20:36:55 2002 From: deering@cisco.com (Steve Deering) Date: Wed, 6 Feb 2002 12:36:55 -0800 Subject: generic v6 tunneling In-Reply-To: <200202061951.g16Jp5g75964@givry.rennes.enst-bretagne.fr> References: <200202061951.g16Jp5g75964@givry.rennes.enst-bretagne.fr> Message-ID: At 8:51 PM +0100 2/6/02, Francis Dupont wrote: > > - there is no reason to encapsulate such packets (they can be sent > > directly). > > That's not the case if the tunnel entry point node is not the original > source node. > >=> this changes nothing: in both cases there is a route to the >destination and packets will follow it. The difference is they can be >encapsulated or not, the visible source address doesn't matter... > >PS: differences can only be in source address based policies (QoS, IPsec, >policy routing, etc). Francis, Perhaps we are saying the same thing. If the tunnel entry point is other than the source node, that intermediate node has some reason to perform the encapsulation (security, performance, policy, whatever). Simply omitting the encapsulation -- which is what I thought you were suggesting -- may fail to satisfy the reason for the tunnel. Or in other words, encapsulation adds information to the packet (additional address(es), possibly different traffic class or flow label values, possibly extension headers). Simply removing that information changes the semantics of the packets, in possibly harmful ways. Steve From pekkas@netcore.fi Sat Feb 9 18:39:38 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Sat, 9 Feb 2002 20:39:38 +0200 (EET) Subject: remove In-Reply-To: Message-ID: On Tue, 5 Feb 2002, Olof Samuelsson wrote: > > On Saturday 02 February 2002 07:28, Michael Biber wrote: A URL to > > remove peopel from the list at the end of each message that goes > > through the list server will fix all of this. People who want to be > > out, just go to that URL, enter their email address and when they > > reply to the confirmation email (just like when you subscribe) you > > are removed from the list. > > How about the List-Unsubscribe header from RFC2369? I think at least > recent pines support it. A problem may be that people trying to unsubscribe in this manner probably don't use programs that support this, or known to use this feature anyway. -- 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 bmanning@ISI.EDU Sat Feb 9 20:47:29 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Sat, 9 Feb 2002 12:47:29 -0800 Subject: IPv6 video streamer In-Reply-To: References: Message-ID: <20020209204729.GA36830@zed.isi.edu> On Thu, Feb 07, 2002 at 02:37:00PM -0800, Aouriri, Chedley wrote: > > Looking for a video streaming software (client and server) running on IPv6. > Any pointers? > > Thanks, > ..CHEDLEY.. > Chedley.Aouriri@Intel.com > > You might want to look at the DVTS work... www.sfc.wide.ad.jp/DVTS/intro.html --bill From fink@es.net Tue Feb 12 01:17:26 2002 From: fink@es.net (Bob Fink) Date: Mon, 11 Feb 2002 17:17:26 -0800 Subject: 6bone pTLA 3FFE:8340::/28 allocated to GLOBAL Message-ID: <5.1.0.14.0.20020211170950.02ac48c8@imap2.es.net> GLOBAL has been allocated pTLA 3FFE:8340::/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: [To create a reverse DNS registration for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to either bmanning@isi.edu or hostmaster@ep.net.] Thanks, Bob From michel@arneill-py.sacramento.ca.us Wed Feb 13 00:20:00 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 12 Feb 2002 16:20:00 -0800 Subject: Contact for Caladan Message-ID: <2B81403386729140A3A899A8B39B046406C319@server2000.arneill-py.sacramento.ca.us> 6bone folk, has anyone emailed to Caladan recently? I can't get in touch with Chris anymore. Thanks Michel. From jorgen@hovland.cx Wed Feb 13 19:14:36 2002 From: jorgen@hovland.cx (=?ISO-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 13 Feb 2002 20:14:36 +0100 (CET) Subject: multicast Message-ID: First.. is there a ipv6 mbone around? Any way to connect to that? How do you implement this globally? Msdp, bgmp ? What about internally? PIM6 around? Since cisco doesnt support it, are there any software around for linux/unix? I am streaming ipv6 multicast on my lan, but I could need to try it a bit more globally. thanks, Joergen Hovland WebOnline NET AS From mcr@sandelman.ottawa.on.ca Thu Feb 14 00:25:28 2002 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Wed, 13 Feb 2002 19:25:28 -0500 Subject: multicast In-Reply-To: Your message of "Wed, 13 Feb 2002 20:14:36 +0100." Message-ID: <200202140025.g1E0PSo16945@marajade.sandelman.ottawa.on.ca> >>>>> "rgen" == rgen Hovland writes: rgen> How do you implement this globally? Msdp, bgmp ? What about rgen> internally? PIM6 around? Since cisco doesnt support it, are there rgen> any software around for linux/unix? I don't know of any... I have success with IPv4+DVMRP, but nobody wants to connect with that anymore. I have little success with IPv4+PIMdd due to problems with pimdd itself (on NetBSD) it seems. I have zebra running on my IPv6 gateway doing BGP4 for IPv6 and would be happy to experiment with others if there is some MOSPF,PIM6,etc. support in zebra that I don't know about. ] 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 pekkas@netcore.fi Thu Feb 14 07:41:59 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 14 Feb 2002 09:41:59 +0200 (EET) Subject: multicast In-Reply-To: <200202140025.g1E0PSo16945@marajade.sandelman.ottawa.on.ca> Message-ID: On Wed, 13 Feb 2002, Michael Richardson wrote: > >>>>> "rgen" == rgen Hovland writes: > rgen> How do you implement this globally? Msdp, bgmp ? What about > rgen> internally? PIM6 around? Since cisco doesnt support it, are there > rgen> any software around for linux/unix? > > I don't know of any... I have success with IPv4+DVMRP, but nobody > wants to connect with that anymore. I have little success with IPv4+PIMdd due > to problems with pimdd itself (on NetBSD) it seems. > > I have zebra running on my IPv6 gateway doing BGP4 for IPv6 and would be > happy to experiment with others if there is some MOSPF,PIM6,etc. support in > zebra that I don't know about. pim6sd and pim6dd are available for *BSD; previously (at least in FreeBSD) but were removed to ports due licensing IIRC. -- 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 pim@ipng.nl Thu Feb 14 10:10:03 2002 From: pim@ipng.nl (Pim van Pelt) Date: Thu, 14 Feb 2002 11:10:03 +0100 Subject: [pim@ipng.nl: NL-BIT pTLA request] In-Reply-To: <20020124164719.GC18594@bfib.colo.bit.nl> References: <20020124164719.GC18594@bfib.colo.bit.nl> Message-ID: <20020214101002.GB24506@bfib.colo.bit.nl> Hoi Bob, others! A few weeks ago, I sent in this pTLA request on behalf of my new employer. I remember Bob was enjoying New Zealand on summers' vacation (while the rest of us were left in the winter-hemisphere :), but can we pick this back up please? Picking up where Bob and I left off, I'll quote him: | Pim, | | I think most is in order, however, you don't have any inet6num entry for | your current address allocation. Also, I need to know that NL-BIT6 has been | active for 3 months. There is an inet6num object inserted at the RIPE registry, because BIT has been an active participant from that address space. Unfortunately, I stated the wrong information in my original request. I said the object NL-BIT6 was present but the object's current name is BIT6-NL: inet6num: 2001:06E0:0209::/48 netname: BIT6-NL descr: Business Internet Trends IPv6 deployment country: NL admin-c: BITT1-RIPE tech-c: BITT1-RIPE remarks: Abuse reports go to abuse@bit.nl, peering issues remarks: go to PBVP1-RIPE mnt-by: BIT-MNT changed: pim@ipng.nl 20010811 changed: pim@ipng.nl 20010930 source: RIPE As seen from the changed fields, BIT was first active on the 6bone during the HAL2001 convention in Enschede(NL), where we set things up from a cute campsite. To further complicate things, I did set up an NL-BIT6 ipv6-site object at the 6BONE registry. I shall delete the RIPE one as soon as BIT gets its own aggregatable space. I will (at least try to) use -6 to denote things later on and try to keep the naming hierarical. I hope this clears up any pending issues. If there's anything else, please let me know! groet, Pim On Thu, Jan 24, 2002 at 05:47:20PM +0100, Pim van Pelt wrote: | Dear Bob, and 6BONE folk, | | Via these means, I would like to inform you all, that I am switching | employers on the 1st of March 2002, when my current contract at WiseGuys | Internet BV ends. My new employer, Business Internet Trends, is an ISP | and colocation provider in The Netherlands. I will be joining their | team as a network engineer per 1/3/2002. Yay! | | I plan to do many exciting things with and for BIT, one of which, you | could've known, is starting a native IPv6 deployment from the AMS-v6-IX | to the head quarters and colocation facilities in Ede (GLD). | | This is why I am requesting a pTLA allocation to be made for this | company. We hope to have this space allocated per 01/03 so we can dive | into the configuration and implementational details. | | Please let me know what you think of this. | | Kind regards, | Pim van Pelt | | ----- pTLA request form ----- | 1. The pTLA Applicant must have a minimum of three (3) months | qualifying experience as a 6Bone end-site or pNLA transit. During | the entire qualifying period the Applicant must be operationally | providing the following: | | a. Fully maintained, up to date, 6Bone Registry entries for their | ipv6-site inet6num, mntner, and person objects, including each | tunnel that the Applicant has. | | Our current inet6num is BIT6-NL (2001:06E0:0209::/48), which is natively | connected to the INTOUCH-NL networks at the AMS-v6-IX. It is maintained | by BIT-MNT (RIPE) and has a role BITT1-RIPE for technical and | administrative contact. We have inserted copies of the -RIPE objects into | the 6BONE registry where appropriate: | [ipv6-site] NL-BIT6 | [person] HM6669-6BONE (Hans van der Made) | [person] SAB666-6BONE (Sabri Berisha) | [person] AB2298-6BONE (Alex Bik) | [role] BITT1-6BONE (Business Internet Trends Technical Role Account) | and | [person] PBVP1-6BONE (Pim van Pelt) | | 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. | | We have a BGP session with AS8954 at the AMS-v6-IX, which connects our | Cisco 2600 to the 6BONE. We would like to enforce our network by setting | up additional peerings and announcing our own network via BGP. This way | AS8954 will not have to take care of our own traffic. Our address is | currently: | ipv6.bit.nl. has AAAA address 2001:6e0:0:10a::2 | ipv6.bit.nl. has AAAA address 2001:6e0:209:2:203:6bff:fe6e:52a0 | Where the former is a VLAN where Intouch AMSIX is ::1/64 and we are | ::2/64 in Ede. Both addresses are on the C2600 at our site and reply | pings. | | c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) | entries for the Applicant's router(s) and at least one host | system. | Forward entries for bit.nl (IN AAAA, and in the future IN A6) can be | found at: | bit.nl. name server ns2.bit.nl. | bit.nl. name server ns3.bit.nl. | bit.nl. name server ns.bit.nl. | The reversed zonefile from Intouch is handled by IPng at this point, | and only on one server: | 9.0.2.0.0.e.6.0.1.0.0.2.ip6.int name server ns1.ipng.nl. | but will move to ns/ns2/ns3.bit.nl per 01-03-2002. | | 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. | | We have a server ready at www.ipv6.bit.nl, and do not plan to do much | with this at the moment. There are some pages on the server, though. | It's address is: 2001:6e0:209:3:290:27ff:fe0c:5c5e, port 80. It pings. | | 2. The pTLA Applicant MUST have the ability and intent to provide | "production-quality" 6Bone backbone service. Applicants must | provide a statement and information in support of this claim. | This MUST include the following: | | a. A support staff of two persons minimum, three preferable, with | person attributes registered for each in the ipv6-site object | for the pTLA applicant. | Alex Bik, Sabri Berisha, Hans van der Made and Pim van Pelt, forming | BITT1-6BONE, as describe in section 1. | | 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. | This mailbox is ipv6@bit.nl and we will be using @ipv6.bit.nl once we | get settled. Another entry is noc@bit.nl, which is roughly the same persons | but for a more generic communication (eg v4 and v6 related) | | 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 are a hosting and application service provider, with a valid userbase | for IPv6. Two main aspects come to mind: Access and Colocation. The former | consists of a nationwide dialup network, and several leased lines to | customers and the latter is a set of colocation facilities with some | 250 customers' boxes. We are about to build a third colocation facility | on a seperate location with a gigabit uplink to the AMS-IX, providing | additional services to an ever growing customer base, including the | possibility of traffic exchange between ISPs at this location. | | 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 have a commitment to our customers and the 6bone, and armed with | technical clue, we agree to abide by these rules and policies laid down | by the 6bone community. | | When an Applicant seeks to receive a pTLA allocation, it will apply | to the 6Bone Operations Group (see section 8 below) by providing to | the Group information in support of its claims that it meets the | criteria above. | | 8. 6Bone Operations Group | | The 6Bone Operations Group is the group in charge of monitoring and | policing adherence to the current rules. Membership in the 6Bone | Operations Group is mandatory for, and restricted to, sites connected | to the 6Bone. | | The 6Bone Operations Group is currently defined by those members of | the existing 6Bone mailing list who represent sites participating in | the 6Bone. Therefore it is incumbent on relevant site contacts to | join the 6Bone mailing list. Instructions on how to join the list are | maintained on the 6Bone web site at < http://www.6bone.net>. | | | -- | ---------- - - - - -+- - - - - ---------- | Pim van Pelt Email: pim@ipng.nl | http://www.ipng.nl/ IPv6 Deployment | ----------------------------------------------- | | ----- End forwarded message ----- | | -- | ---------- - - - - -+- - - - - ---------- | Pim van Pelt Email: pim@ipng.nl | http://www.ipng.nl/ IPv6 Deployment | ----------------------------------------------- -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From fink@es.net Thu Feb 14 16:39:41 2002 From: fink@es.net (Bob Fink) Date: Thu, 14 Feb 2002 08:39:41 -0800 Subject: pTLA request for NL-BIT6 - review closes 28 February 2002 Message-ID: <5.1.0.14.0.20020214082939.09b197e0@imap2.es.net> 6bone Folk, NL-BIT6 has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 28 February 2002. Please send your comments to me or the list. Thanks, Bob === >Picking up where Bob and I left off, I'll quote him: >| Pim, >| >| I think most is in order, however, you don't have any inet6num entry for >| your current address allocation. Also, I need to know that NL-BIT6 has been >| active for 3 months. > >There is an inet6num object inserted at the RIPE registry, because BIT has >been >an active participant from that address space. Unfortunately, I stated the >wrong information in my original request. I said the object NL-BIT6 was >present >but the object's current name is BIT6-NL: > >inet6num: 2001:06E0:0209::/48 >netname: BIT6-NL >descr: Business Internet Trends IPv6 deployment >country: NL >admin-c: BITT1-RIPE >tech-c: BITT1-RIPE >remarks: Abuse reports go to abuse@bit.nl, peering issues >remarks: go to PBVP1-RIPE >mnt-by: BIT-MNT >changed: pim@ipng.nl 20010811 >changed: pim@ipng.nl 20010930 >source: RIPE > >As seen from the changed fields, BIT was first active on the 6bone during >the HAL2001 convention in Enschede(NL), where we set things up from a cute >campsite. > >To further complicate things, I did set up an NL-BIT6 ipv6-site object at >the 6BONE registry. I shall delete the RIPE one as soon as BIT gets its own >aggregatable space. I will (at least try to) use -6 >to denote things later on and try to keep the naming hierarical. > >I hope this clears up any pending issues. If there's anything else, please >let me know! > >groet, >Pim > >On Thu, Jan 24, 2002 at 05:47:20PM +0100, Pim van Pelt wrote: >| Dear Bob, and 6BONE folk, >| >| Via these means, I would like to inform you all, that I am switching >| employers on the 1st of March 2002, when my current contract at WiseGuys >| Internet BV ends. My new employer, Business Internet Trends, is an ISP >| and colocation provider in The Netherlands. I will be joining their >| team as a network engineer per 1/3/2002. Yay! >| >| I plan to do many exciting things with and for BIT, one of which, you >| could've known, is starting a native IPv6 deployment from the AMS-v6-IX >| to the head quarters and colocation facilities in Ede (GLD). >| >| This is why I am requesting a pTLA allocation to be made for this >| company. We hope to have this space allocated per 01/03 so we can dive >| into the configuration and implementational details. >| >| Please let me know what you think of this. >| >| Kind regards, >| Pim van Pelt >| >| ----- pTLA request form ----- >| 1. The pTLA Applicant must have a minimum of three (3) months >| qualifying experience as a 6Bone end-site or pNLA transit. During >| the entire qualifying period the Applicant must be operationally >| providing the following: >| >| a. Fully maintained, up to date, 6Bone Registry entries for their >| ipv6-site inet6num, mntner, and person objects, including each >| tunnel that the Applicant has. >| >| Our current inet6num is BIT6-NL (2001:06E0:0209::/48), which is natively >| connected to the INTOUCH-NL networks at the AMS-v6-IX. It is maintained >| by BIT-MNT (RIPE) and has a role BITT1-RIPE for technical and >| administrative contact. We have inserted copies of the -RIPE objects into >| the 6BONE registry where appropriate: >| [ipv6-site] NL-BIT6 >| [person] HM6669-6BONE (Hans van der Made) >| [person] SAB666-6BONE (Sabri Berisha) >| [person] AB2298-6BONE (Alex Bik) >| [role] BITT1-6BONE (Business Internet Trends Technical Role Account) >| and >| [person] PBVP1-6BONE (Pim van Pelt) >| >| 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. >| >| We have a BGP session with AS8954 at the AMS-v6-IX, which connects our >| Cisco 2600 to the 6BONE. We would like to enforce our network by setting >| up additional peerings and announcing our own network via BGP. This way >| AS8954 will not have to take care of our own traffic. Our address is >| currently: >| ipv6.bit.nl. has AAAA address 2001:6e0:0:10a::2 >| ipv6.bit.nl. has AAAA address 2001:6e0:209:2:203:6bff:fe6e:52a0 >| Where the former is a VLAN where Intouch AMSIX is ::1/64 and we are >| ::2/64 in Ede. Both addresses are on the C2600 at our site and reply >| pings. >| >| c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) >| entries for the Applicant's router(s) and at least one host >| system. >| Forward entries for bit.nl (IN AAAA, and in the future IN A6) can be >| found at: >| bit.nl. name server ns2.bit.nl. >| bit.nl. name server ns3.bit.nl. >| bit.nl. name server ns.bit.nl. >| The reversed zonefile from Intouch is handled by IPng at this point, >| and only on one server: >| 9.0.2.0.0.e.6.0.1.0.0.2.ip6.int name server ns1.ipng.nl. >| but will move to ns/ns2/ns3.bit.nl per 01-03-2002. >| >| 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. >| >| We have a server ready at www.ipv6.bit.nl, and do not plan to do much >| with this at the moment. There are some pages on the server, though. >| It's address is: 2001:6e0:209:3:290:27ff:fe0c:5c5e, port 80. It pings. >| >| 2. The pTLA Applicant MUST have the ability and intent to provide >| "production-quality" 6Bone backbone service. Applicants must >| provide a statement and information in support of this claim. >| This MUST include the following: >| >| a. A support staff of two persons minimum, three preferable, with >| person attributes registered for each in the ipv6-site object >| for the pTLA applicant. >| Alex Bik, Sabri Berisha, Hans van der Made and Pim van Pelt, forming >| BITT1-6BONE, as describe in section 1. >| >| 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. >| This mailbox is ipv6@bit.nl and we will be using @ipv6.bit.nl once we >| get settled. Another entry is noc@bit.nl, which is roughly the same persons >| but for a more generic communication (eg v4 and v6 related) >| >| 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 are a hosting and application service provider, with a valid userbase >| for IPv6. Two main aspects come to mind: Access and Colocation. The former >| consists of a nationwide dialup network, and several leased lines to >| customers and the latter is a set of colocation facilities with some >| 250 customers' boxes. We are about to build a third colocation facility >| on a seperate location with a gigabit uplink to the AMS-IX, providing >| additional services to an ever growing customer base, including the >| possibility of traffic exchange between ISPs at this location. >| >| 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 have a commitment to our customers and the 6bone, and armed with >| technical clue, we agree to abide by these rules and policies laid down >| by the 6bone community. >| >| When an Applicant seeks to receive a pTLA allocation, it will apply >| to the 6Bone Operations Group (see section 8 below) by providing to >| the Group information in support of its claims that it meets the >| criteria above. >| >| 8. 6Bone Operations Group >| >| The 6Bone Operations Group is the group in charge of monitoring and >| policing adherence to the current rules. Membership in the 6Bone >| Operations Group is mandatory for, and restricted to, sites connected >| to the 6Bone. >| >| The 6Bone Operations Group is currently defined by those members of >| the existing 6Bone mailing list who represent sites participating in >| the 6Bone. Therefore it is incumbent on relevant site contacts to >| join the 6Bone mailing list. Instructions on how to join the list are >| maintained on the 6Bone web site at < http://www.6bone.net>. >| >-end From fink@es.net Thu Feb 14 16:39:41 2002 From: fink@es.net (Bob Fink) Date: Thu, 14 Feb 2002 08:39:41 -0800 Subject: pTLA request for NL-BIT6 - review closes 28 February 2002 Message-ID: <5.1.0.14.0.20020214082939.09b197e0@imap2.es.net> 6bone Folk, NL-BIT6 has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 28 February 2002. Please send your comments to me or the list. Thanks, Bob === >Picking up where Bob and I left off, I'll quote him: >| Pim, >| >| I think most is in order, however, you don't have any inet6num entry for >| your current address allocation. Also, I need to know that NL-BIT6 has been >| active for 3 months. > >There is an inet6num object inserted at the RIPE registry, because BIT has >been >an active participant from that address space. Unfortunately, I stated the >wrong information in my original request. I said the object NL-BIT6 was >present >but the object's current name is BIT6-NL: > >inet6num: 2001:06E0:0209::/48 >netname: BIT6-NL >descr: Business Internet Trends IPv6 deployment >country: NL >admin-c: BITT1-RIPE >tech-c: BITT1-RIPE >remarks: Abuse reports go to abuse@bit.nl, peering issues >remarks: go to PBVP1-RIPE >mnt-by: BIT-MNT >changed: pim@ipng.nl 20010811 >changed: pim@ipng.nl 20010930 >source: RIPE > >As seen from the changed fields, BIT was first active on the 6bone during >the HAL2001 convention in Enschede(NL), where we set things up from a cute >campsite. > >To further complicate things, I did set up an NL-BIT6 ipv6-site object at >the 6BONE registry. I shall delete the RIPE one as soon as BIT gets its own >aggregatable space. I will (at least try to) use -6 >to denote things later on and try to keep the naming hierarical. > >I hope this clears up any pending issues. If there's anything else, please >let me know! > >groet, >Pim > >On Thu, Jan 24, 2002 at 05:47:20PM +0100, Pim van Pelt wrote: >| Dear Bob, and 6BONE folk, >| >| Via these means, I would like to inform you all, that I am switching >| employers on the 1st of March 2002, when my current contract at WiseGuys >| Internet BV ends. My new employer, Business Internet Trends, is an ISP >| and colocation provider in The Netherlands. I will be joining their >| team as a network engineer per 1/3/2002. Yay! >| >| I plan to do many exciting things with and for BIT, one of which, you >| could've known, is starting a native IPv6 deployment from the AMS-v6-IX >| to the head quarters and colocation facilities in Ede (GLD). >| >| This is why I am requesting a pTLA allocation to be made for this >| company. We hope to have this space allocated per 01/03 so we can dive >| into the configuration and implementational details. >| >| Please let me know what you think of this. >| >| Kind regards, >| Pim van Pelt >| >| ----- pTLA request form ----- >| 1. The pTLA Applicant must have a minimum of three (3) months >| qualifying experience as a 6Bone end-site or pNLA transit. During >| the entire qualifying period the Applicant must be operationally >| providing the following: >| >| a. Fully maintained, up to date, 6Bone Registry entries for their >| ipv6-site inet6num, mntner, and person objects, including each >| tunnel that the Applicant has. >| >| Our current inet6num is BIT6-NL (2001:06E0:0209::/48), which is natively >| connected to the INTOUCH-NL networks at the AMS-v6-IX. It is maintained >| by BIT-MNT (RIPE) and has a role BITT1-RIPE for technical and >| administrative contact. We have inserted copies of the -RIPE objects into >| the 6BONE registry where appropriate: >| [ipv6-site] NL-BIT6 >| [person] HM6669-6BONE (Hans van der Made) >| [person] SAB666-6BONE (Sabri Berisha) >| [person] AB2298-6BONE (Alex Bik) >| [role] BITT1-6BONE (Business Internet Trends Technical Role Account) >| and >| [person] PBVP1-6BONE (Pim van Pelt) >| >| 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. >| >| We have a BGP session with AS8954 at the AMS-v6-IX, which connects our >| Cisco 2600 to the 6BONE. We would like to enforce our network by setting >| up additional peerings and announcing our own network via BGP. This way >| AS8954 will not have to take care of our own traffic. Our address is >| currently: >| ipv6.bit.nl. has AAAA address 2001:6e0:0:10a::2 >| ipv6.bit.nl. has AAAA address 2001:6e0:209:2:203:6bff:fe6e:52a0 >| Where the former is a VLAN where Intouch AMSIX is ::1/64 and we are >| ::2/64 in Ede. Both addresses are on the C2600 at our site and reply >| pings. >| >| c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) >| entries for the Applicant's router(s) and at least one host >| system. >| Forward entries for bit.nl (IN AAAA, and in the future IN A6) can be >| found at: >| bit.nl. name server ns2.bit.nl. >| bit.nl. name server ns3.bit.nl. >| bit.nl. name server ns.bit.nl. >| The reversed zonefile from Intouch is handled by IPng at this point, >| and only on one server: >| 9.0.2.0.0.e.6.0.1.0.0.2.ip6.int name server ns1.ipng.nl. >| but will move to ns/ns2/ns3.bit.nl per 01-03-2002. >| >| 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. >| >| We have a server ready at www.ipv6.bit.nl, and do not plan to do much >| with this at the moment. There are some pages on the server, though. >| It's address is: 2001:6e0:209:3:290:27ff:fe0c:5c5e, port 80. It pings. >| >| 2. The pTLA Applicant MUST have the ability and intent to provide >| "production-quality" 6Bone backbone service. Applicants must >| provide a statement and information in support of this claim. >| This MUST include the following: >| >| a. A support staff of two persons minimum, three preferable, with >| person attributes registered for each in the ipv6-site object >| for the pTLA applicant. >| Alex Bik, Sabri Berisha, Hans van der Made and Pim van Pelt, forming >| BITT1-6BONE, as describe in section 1. >| >| 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. >| This mailbox is ipv6@bit.nl and we will be using @ipv6.bit.nl once we >| get settled. Another entry is noc@bit.nl, which is roughly the same persons >| but for a more generic communication (eg v4 and v6 related) >| >| 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 are a hosting and application service provider, with a valid userbase >| for IPv6. Two main aspects come to mind: Access and Colocation. The former >| consists of a nationwide dialup network, and several leased lines to >| customers and the latter is a set of colocation facilities with some >| 250 customers' boxes. We are about to build a third colocation facility >| on a seperate location with a gigabit uplink to the AMS-IX, providing >| additional services to an ever growing customer base, including the >| possibility of traffic exchange between ISPs at this location. >| >| 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 have a commitment to our customers and the 6bone, and armed with >| technical clue, we agree to abide by these rules and policies laid down >| by the 6bone community. >| >| When an Applicant seeks to receive a pTLA allocation, it will apply >| to the 6Bone Operations Group (see section 8 below) by providing to >| the Group information in support of its claims that it meets the >| criteria above. >| >| 8. 6Bone Operations Group >| >| The 6Bone Operations Group is the group in charge of monitoring and >| policing adherence to the current rules. Membership in the 6Bone >| Operations Group is mandatory for, and restricted to, sites connected >| to the 6Bone. >| >| The 6Bone Operations Group is currently defined by those members of >| the existing 6Bone mailing list who represent sites participating in >| the 6Bone. Therefore it is incumbent on relevant site contacts to >| join the 6Bone mailing list. Instructions on how to join the list are >| maintained on the 6Bone web site at < http://www.6bone.net>. >| >-end From fink@es.net Thu Feb 14 18:08:02 2002 From: fink@es.net (Bob Fink) Date: Thu, 14 Feb 2002 10:08:02 -0800 Subject: T-NET pTLA request In-Reply-To: Message-ID: <5.1.0.14.0.20020214100038.02bb90a0@imap2.es.net> Tamas, At 06:44 PM 2/14/2002 +0100, maray@niif.hu wrote: >...AS1955 is owned by NIIF/HUNGARNET which is the Hungarian NREN. Since there >is no any kind of such agreement between T-NET and NIIF, T-NET is *not* >authorized to use AS1955 for their IPv6 activities. >In fact, T-NET has never turned to NIIF with such requirement. > >Sincerely, > >Tamas Maray >maray@niif.hu >NIIF Technical director Thanks for your message. I had already delayed granting T-Net a pTLA until some official comment came from HUNGARNET about use of AS1955. Regards, Bob From fink@es.net Fri Feb 15 15:35:54 2002 From: fink@es.net (Bob Fink) Date: Fri, 15 Feb 2002 07:35:54 -0800 Subject: pTLA request for NTT-EAST - review closes 1 March 2002 Message-ID: <5.1.0.14.0.20020215072137.01e88368@imap2.es.net> 6bone Folk, NTT-EAST has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 1 March 2002. Please send your comments to me or the list. Note: though the NTT-EAST IPv6-site object lists AS4697 for their BGP4+ peering with their current upstream NTT-ECL, NTT-EAST will use their own AS17933 as a pTLA. Thanks, Bob === >Date: Fri, 01 Feb 2002 16:22:36 +0900 >From: Satoshi TSUNEKAWA >To: fink@es.net >Subject: pTLA request > >Dear Sir, > > This is Satoshi TSUNEKAWA$B!!(Bthat belongs to NTT East in Japan, > we reqest to allocate a pTLA address block. > NTT East is one of the subsidiaries of NTT holding company. > > We have got pNLA(3ffe:1800:f800::/40) from NTT-ECL and have been > operating this network since June 26, 2001. > > >================================ >[request form of pTLA] >================================ >7. Guidelines for 6Bone pTLA sites > > The following rules apply to qualify for a 6Bone pTLA allocation. It > should be recognized that holders of 6Bone pTLA allocations are > expected to provide production quality backbone network services for > the 6Bone. > > 1. The pTLA Applicant must have a minimum of three (3) months > qualifying experience as a 6Bone end-site or pNLA transit. During > the entire qualifying period the Applicant must be operationally > providing the following: > > a. Fully maintained, up to date, 6Bone Registry entries for their > ipv6-site inet6num, mntner, and person objects, including each > tunnel that the Applicant has. >-- >[A] >We have connected to 6bone as below. > - SLA of NTT-ECL since May 11, 2001. > inet6num: 3ffe:1800:2100::/48 > NETNAME: NTT-EAST > - NLA of NTT-ECL since June 26, 2001. > inet6num: 3ffe:1800:f800::/40 > NETNAME: NTT-EAST >-- > > 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. >--- >[A] >Now, we connected to NTT-ECL with native link using BGP4+. We have a plan >to connect to NSPIXP6(IPv6 Internet Exchange in Japan) soon. > >Our ipv6 router's FQDN is router1.ntte.net (3ffe:1800:f800:1000::31), >and it is IPv6 pingable. >--- > > c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > entries for the Applicant's router(s) and at least one host > system. >--- >[A] >We maintain nameserver forward (AAAA) and reverse (ip6.int) entries on >ns2.ntte.net (3ffe:1800:f800::9 / 61.125.0.5) >and ns3.ntte.net (3ffe:1800:f800::10 / 61.125.0.2). >--- > > 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. >--- >[A] >Our web server's FQDN is www.ntte.net. >It is currently accessible from only IPv6. >--- > > 2. The pTLA Applicant MUST have the ability and intent to provide > "production-quality" 6Bone backbone service. Applicants must > provide a statement and information in support of this claim. > This MUST include the following: > > a. A support staff of two persons minimum, three preferable, with > person attributes registered for each in the ipv6-site object > for the pTLA applicant. >--- >[A] >NTT-EAST IPv6 network support staff are following. > - Satoshi Tsunekawa (ST3-6BONE) > - Wataru Kawakami (WK2-6BONE) > - Takeshi Kusune (TK5-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. >--- >[A] >Our common e-mail address is query-v6@ipnw.rdc.east.ntt.co.jp >--- > > 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. >--- >[A] >NTT East is the largest telecommunication campany in the East Japan which >operates all cities including Tokyo, Yokohama, Saitama, Chiba, Nagano, >Sendai, Sapporo and so on. >Our Research and Development Center have built IPv6 testbed network, and we >would like to connect to potential customer by tunnel or native. >Currently, we have built IPv6 testbed network with FreeBSD 4.4, >RedHat Linux 7.2, Cisco 7206 and 3640, YAMAHA RTA52i, and so on. >--- > > 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. >--- >[A] >Of course, we agree the 6bone rules and policies. >--- > > When an Applicant seeks to receive a pTLA allocation, it will apply > to the 6Bone Operations Group (see section 8 below) by providing to > the Group information in support of its claims that it meets the > criteria above. > >================================ > >Best regards, > > >------------------------------------------------ >Satoshi TSUNEKAWA > >Technology Department >Nippon Telegraph and Telephone East Corporation(NTT East) > >19-2 Nishi-shinjuku 3-Chome Shinjuku-ku, >Tokyo 163-8019 Japan > >Phone +81-3-5359-2787 >Fax +81-3-5359-1209 -end From jmgraham@midsouth.rr.com Fri Feb 15 21:14:00 2002 From: jmgraham@midsouth.rr.com (Michael Graham) Date: Fri, 15 Feb 2002 15:14:00 -0600 Subject: Focus Applications - Ready For Staging In-Reply-To: Message-ID: <001401c1b665$b06e8630$65de12ac@funder.dnsalias.net> This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C1B633.65D41630 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0016_01C1B633.65D41630" ------=_NextPart_001_0016_01C1B633.65D41630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit PK, When sending something to our attention, please be sure to cc (if not just send to) devsa-mtp@clover.c2d.fedex.com. Thanks Michael Graham -----Original Message----- From: PK Ramesh [mailto:pkramesh@yahoo.com] Sent: Friday, February 15, 2002 1:51 PM To: Marty Bishop Cc: jeffg@clover.c2d.fedex.com; mg228815@webmail.c2d.fedex.com Subject: Focus Applications - Ready For Staging Marty, Focus and Visual Focus applications are ready for Staging. Since I have new changes (wrappers, libraries etc), you have to repackage it again. The following are the pspec Info: All pspecs are on tripsdev-svr.c2d.fedex.com machine Focus1.2: /opt/software/focus_1.2/focusEmergency.pspec VisualFocus1.0 /opt/software/visualFocus_1.0/visualFocus.pspec Please get this packaged and moved to Staging. I would appreciate if we can get to staging today as I can use the weekend to finish my stage testing. Thanks, Ramesh PK 901-797-6896 mailto:pkramesh@webmail.c2d.fedex.com ------=_NextPart_001_0016_01C1B633.65D41630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

PK, 

 

  When sending something to our attention, please be sure to cc (if = not just send to) devsa-mtp@clover.c2d.fedex= .com.

 

Thanks

 

Michael = Graham

 

-----Original = Message-----
From: PK Ramesh [mailto:pkramesh@yahoo.com]
Sent: Friday, February = 15, 2002 1:51 PM
To: Marty Bishop
Cc: = jeffg@clover.c2d.fedex.com; mg228815@webmail.c2d.fedex.com
Subject: Focus = Applications - Ready For Staging

 

Marty,

 

Focus and Visual Focus applications are ready for = Staging.

 

Since I have new changes (wrappers, libraries etc), you have to repackage it again. = The following are the pspec Info:

 

 

All pspecs = are on tripsdev-svr.c2d.fedex.com machine

 

Focus1.2:

   = /opt/software/focus_1.2/focusEmergency.pspec

 

VisualFocus1.0=

/opt/software/= visualFocus_1.0/visualFocus.pspec

 

Please get = this packaged and moved to Staging. I would appreciate if we can get to = staging today as I can use the weekend to finish my stage = testing.

 

 

Thanks,<= /p>

 

Ramesh = PK

901-797-6896

mailto:pkramesh@webmail.c2d.fedex.com

 

------=_NextPart_001_0016_01C1B633.65D41630-- ------=_NextPart_000_0015_01C1B633.65D41630 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgEASABIAAD/7QVoUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////// //////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////////// /////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQIAAAAAAAQ AAAAAQAAAkAAAAJAAAAAADhCSU0ECQAAAAAD9wAAAAEAAACAAAAAgAAAAYAAAMAAAAAD2wAYAAH/ 2P/gABBKRklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0 LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwM DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAgACAAwEiAAIRAQMR Af/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSl tcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOE w9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A 9LSS7JlWLMolMkkmpXSTpIqUnCinCQQySTSknWilJkpSQtKxSlJJBKk6ZOkFP//Q9LlJMnVZmVCY qRUUCpSRKUpkErSpBRhOkClkCkmCcJ1rVQmUk0JKUm7p0kEqSTSkUrU//9H0kKQUU8qoCzlclRTy opEqC6SSSSVwlokkihScJAJwEgEKCRTpiE6lLJJJkFLJJJJq5//S9JTJ0ypthcJJkpSUukklqipS kmhSARAQVBJOE6ctWCdJIooYlRKkSok6ppXBSRSCcodEv//T9JSSThVGwxITKZTQhSrUE6QCdOCC uEkySKF5Ugop0QgrpikSokokqCxTKSaEwrlBP8Eyfskh/9T0lSUSkCVUZ2SSYKSKFkkkgipSSdMU lLpFMmJStVLykmlOhaVJJAJ4RQslKSZBL//V9JTwkkqjOunUU4KchSQTpJKWJSTEppQtNLkpkk8I bqUAnSTIqZJSmSRQsmUlEoFIf//W9KCSSdVWdZIJQkkplKZNKSNopc6qMKSZBKycFOkB4pUq1JJ4 CUI0i1kydMUClUpkkkEv/9kAOEJJTQQGAAAAAAAHAAMAAAABAQD//gAnRmlsZSB3cml0dGVuIGJ5 IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9iZQBkAAAAAAH/2wCEAAoHBwcIBwoICAoPCggK DxINCgoNEhQQEBIQEBQRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBCwwMFRMV IhgYIhQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DP/AABEIASwBLAMBEQACEQEDEQH/3QAEACb/xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJ CgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSES MUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAkcoLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaD CQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWltcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhI WGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20B AAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEjQhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMI CQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eH l6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhED EQA/AOoZluG1hQ3TArqYpaxQ7fCrROKGtsVcadsVdthVvamBXYpcBgQ3TFk7FW8Vdtirgu+BV6rQ 1xSuGRZN0GKtU3+WFFOpirVBiq04UNYUOxVo4q49cVawoaritt1xVo4q7FDqHFLqHFW+ONpbpgta f//Q6jmU4bRGFXVxQ1XFXVxVquFDVcVawq7FXYq3gVvFXDFK4YEuOKrcKG8VXLgKQvGRZN4Eurir VcNIdXFXVxVrFDRwq7FWsULcKGjhQ1irWFXDFVwwJbxV2KXDArfbFX//0eo5lOI44ULcKHYqtOKH YVaxV2KHYpbwK3irhilvFXYEuOKGsKt4quGBK4HAluuBLWFXYENYVdXFWq4obrilrFDROFWsKGiM VawodTArsKuwKuGBLeKXYq3ir//S6kMynEaOKFuSQ7FVpxQ1hV2KHYpbwKuAxS7FXYq7FXYq1ire KuxVsYEt1wJbrirsVarih2KtHCrVcUN1xS6uKtE4UNVxV1cVbxVrFXYq7FDhilcMCW8Vdir/AP/T 6l2zKcRo4oaOFWsKHUwKtIwodhV1MCt0xS2MCuwq7FXYq0cUNVxVuuKXVxVsHFW8CXDFW8CXYodi rRwq1hQ7FXYq1ihrFWxilvFWsVdih2KtjAlvFLsVXYEv/9TqNcynDaJwq1hVvArqYq7FDVMVdhVr FXYq3irsVccCrckhrFWq4otuuK2uU4GTeBLYxVdgS1ih2KuphVxGKVuFi7FWqYq6mKt4q7FVuKGx ilumBXYVdgS4nCh1dq4rb//V6hXMtw2sKuxVsYFbwK6mKXEYoaOFVuFDWKG8Ut4q0Tiq3ChaThYt YVbGBV4OBkurkUtg4pdXFXVxVcMCXYq44qtOFDWFDsUuxV2KuxQ1TFWwMVbGBLsVaOKHYUNUHjil /9bp+Zjht4FdTFXYq2MCt4paOKrThQ1hQ7FDsUuJxVbhQ0ThQtwodireBV2BLsUrgcCW8VdilsHA q7Al2KtHFDVMKupirqYq1hQ7FXYq7FXYq7FXHAq3Ch1Ril//1+nVzMcJvFW8CXYq2MCt4paOKrTh YtYVdXFWq4odirWFWiMLFqmKupirsVbxS3gVvFK6uRS7CrYwJbwK3til2KupirWKGsKtYq6mKHYV dirVcVdXFDsVaxVrCr//0OmVzNcFcMCW8VXDAlumBLsVaJwqsJwsWsKGsVdirsVdirsUOxV1MUup irqYq7FW8CtnFXDFK4HAlvFXYFXDFLsCrTkkNYq7FXYq1hVo4oaxQ7FXYq7CrWKv/9HpmZrgNg4E rsUrhkWTZxVrFC0nChbkkNYodirsUupirsVdireKtgYFbxS1ihrFXDFW8UuGKrhgS3irYGBLeBXH Cqw4UNYq7CrsVdirsULcKGsVdirsVawof//S6Xmc69sYGS8ZFK7Al2FWq4qtOFC3ChrChvArsUt4 FdirsVdireKXYq7FWjihwxVvFLeKrsCW6YEtjFXYEtHChacKHUxV1MVdTFWsKuxQtwoW4UOrirsV bwK//9PpWZzr2wcCVwOBK6uBLq4q0ThVrChbXChquKGwcUt4FcMUt4FdireKt4pdirWKupirdMCu pirdMUrhgS3gV2KW6Yq1TChaRirsUOxV2FVuKGicKrThQ7FDVMKt4Fdil//U6Xmc69rFW64Et1xW 3VxS6uKuOKFuFDsVdiq4YEuxV1cVcMUrsCWxgV2KtYVbxVsYEt0wK3TFLeBXYpbGKt4pdTAq0jJI apihxxVZhQ7ChacUNYVdireKuxVrFX//1el5nOvdilo4odXFXVxVsHFLeBWqYVdih2KXYq7FXUxV vAlvFWwcCW64FdhVsDAlsDAldgV2KXYq7FWxirYwJbxVojFWqYULSMKFpwoaOKFuFDsKuwK2Bilx xVb3wsX/1ulkZnOA1ihxxVrCrsVbwK2MUt4EupirsVdihqmFW8CXYq7FDsUtjAq7FK4YEtjAlvAl vFXYq6mKtgYFbxS7FXYq0cVWnChaRkkLTixW4UOxVwGKrsUtHFVtMLF//9fphzNcBrCho4q1hQ4Y q3XAlsYpbwK6uKXYq7FDsUuxQ7FXYq7FVwwMlwwJbAwJXAYEt0xVumBXUxS6mKuGKt4q7FXYq0cV W4ULTkmKwnChrCh1cCrhgS7Cl2KGu+KH/9DpmZrgOOKrDhQ1hQ3irhgS3irq4q6uKt1xVsYEuxS7 FXYq3irYGBK4DAlumBVwxS2MCW8VdgS3irsVaxVvFXYq1XFWicKFhOFitOFC0nJIaxQ7FK8YEhdT Alo4qt74WL//0emZmuC7FC0jChrCrsVbwK1XFXYVdihwwJXDFLeBLeKuxVcBgS3TAlvAlvFW8Cux S2DirYwJbxV2KuxV2KuOKrScKFpOFC0nChaThQtwodireKrgMCV2RS474VW8TXrhtFP/0umHM1wG jhV2KupirqYq0RihrCrWKHYq3ileMilsDAlcMCXYpbAxVdgS6mKuGKt4Fdirq4VXA5FLeKXYq3gV 2KWjhQsyTEqZOSYra4ocThVrFW8Ct0xSuGBLeBWiaYVW8sNIt//T6YRma4LsUOxV2KXYq0cUNEYU NYVaxQuGBK7AyXDAlvAlvFW8VbGBLsVdirq4q1ihsYpXDAldgS7FXYq7FWicKrGwsSsOFitySGsV bwK7FVwwJbril1cVccVW079sNof/1OmGtMzXAarhVvAlcBgV1MVawq1TFDVMK07jja06mKtjAlcM CW8CW8Vdirq4q3XFXYFdirsVbxSuGBK7AlwxVxxVquKrSckxWnChbhVo4oapih2KuxVvFWxgS3TF LqYFaoOnbwySH//V6Z45muA0BhVcBgSuGRS7CrRxVrCh2KuwK7CrgMCrsUuxV2KuxV1cCuxVdgS3 il2KuxVcMCW8Ut1wK0Tiq2uFDRwoW4UNYVdih2KtUxQ6mKupirYwJXDAlvFKygrXvhYP/9bpmw+e ZrguxVcMCW8VdirsVdTArVMKHYq7FW8UuxV2KuxVrFW6YFdhVdgS3gS7FW8CuxS6uKt1xVquFDVc VW1woawodirsVdirsVdirhgV2KrhgS2TQVxSs2rywsX/1+m5muC1iq4YEt4q7FXYpdih2KupgV1M VdhV2KuxV2KuxV2KW6YFbxV2BW8Ut4FdirRwq1XFDq4VarirWFDsVdTArsKt0wJdirWFDsVdilvA rm3FBiFLu+Kv/9DpprXMxwGsKVwwK7FW8UuxV2Kt0wJbpirsVW4q7Ch2BLYxVumKtUxVvFXYFdhV 1cCt4pdirROKtYUNYUOxV2KuxV2KXYFXYq7ArVMKuxV2Ku7Yq1irt6e+KH//0emnrma4LWKuxVvF W64FdilcMCVwwJccVawoaxVrFW8VbwK2MUuxV1MVaxQ1hVvFXVwK6uFVtcUNVwq1XFDYxS3irsCt 0xS3TFXUwK3ilrFDRwq1hQ7FXYq7FX//0um9zma4LsVaxV2Kt4FbGKVwwJbwK3ilo4oawq1hQ2MC VwGBLsVdirsVaOFDWKt4q0cVW1woaJwoaxQ7FK4YEt4q3gS3irYwJbwK7FWjhVacKGsKGsVdXFXV xV//0+m5muA1ilvArsVbxVvFLYwJXYEuxVo4oW5JXYobGBK4YEuxV1cVaxQ44VW4q3XFWicKFuFD WKHYpdiq4YEt4q2MCW8Vb6YEt4EuOFC04oW4UOwq1irWKHdsVf/U6bma4LsVbwK6mKXAYq3irYwJ XYEuxVo4oaphV1MVdTFVwwJcTiq2uFDq4q7FWsUNE4VawoaxV2Kt4FbAxS3irYwJdTFW8Ct1xS1X FDq4pdhQtwoaxVonCh2Kt4Ff/9XpmZrgtjArYxS3irsVdirYwJbrirq4FbxS4jFWsUNjFLsVaOKF pwoarhVuuBWicKtYUNYq7FW8VbpgS3irsVcDgVuuKW8VaxV1cVbrirWKupirVMULSMkhrFW8Vf/W 6Zma4LYwK3il2Kt4q7FXYq6uBWxilcMCW8CtEYVaxVvFWjhQsJwsVuFW8VdirsVdgVumKXUxV2Kt 4q7FWsVbxVvAlrFXYq7CrsUN1wJaxVo4ULcKHYof/9fpmZrgtjpgVvFLeKuxVrFXYq1ihcMCVwwJ XYGTsUNYVdiq04QhZkmLWKHYpdirsVbwKuGBLsKuxV2KuxV2KtYq3irsUuxV2KHYq7FXYq1XFWsK GsVf/9DpoGZjgt4q7FLq4odil2Kt4qtxQ2MUrxgSuyKXYqtrhV2KHHCq0jChbhQ7FWsVbxV2KuxV sHAreKXYq7FXYq7FXYq7FLsCuwoaxVxOKGsKuxVrFXYq/wD/0emjpmY4LeKuxV2KuxS7FXVxVrFD YxSuGBK6uBLVcUOwq7FWicVawoaOKtUxQ3TFWqYq7CrWKt4quGRS7ClsDArqYq7FWsKuwK3irRxQ 1hQtOFXYodirsUuxV//S6dmY4LsVdTFW6YEtHCrWKHYq7CrYwK3iybrgV1cVawq3gVrCh2KuxV2K uxV2KtHFDWFXAYFXDAluhGLJvAh2KtHCrWFWxgVxxVaSMKGsKGsVdTFXHFDsVdil/9Pp1MzHCbAx V2BXYVaOKtYodirsVcMVXVxS6uKuqMVdUYq7FXYq1irq4q7FWxgV2FLsUNEV2xQuQb79sBLIBcSS SCMCW9sCt7YpawoWmlcVcAK4UNbYqtNKYUNbYodirsKuxV1MCXYUOxV//9TqG2ZbhuxV2BXYVccV LWFDRxVrfFDsKtYq2OuKuHfFWx0wK75YpbFMCu2xV2KtbYVbxVv4cCW9sVb22wJbwJdhVoVxQ3ir RxVw98Vawq12xQ44q0cKtHFDWKGsKt4EtiuKt4q//9k= ------=_NextPart_000_0015_01C1B633.65D41630-- From jmgraham@midsouth.rr.com Fri Feb 15 21:55:31 2002 From: jmgraham@midsouth.rr.com (Michael Graham) Date: Fri, 15 Feb 2002 15:55:31 -0600 Subject: Apologies Message-ID: <002401c1b66b$7d0610f0$65de12ac@funder.dnsalias.net> This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C1B639.326BA0F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry about that meaningless spam there. Looks like my outlook went INSANE. ------=_NextPart_000_0025_01C1B639.326BA0F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry about that meaningless spam = there.

Looks like my outlook went = INSANE.

------=_NextPart_000_0025_01C1B639.326BA0F0-- From gsepulve@chilesat.net Sun Feb 17 21:43:14 2002 From: gsepulve@chilesat.net (Gustavo Sepulveda) Date: Sun, 17 Feb 2002 17:43:14 -0400 Subject: Please remove from your mailing list Message-ID: <3C7023F2.A98E793A@chilesat.net> remove From fink@es.net Mon Feb 18 01:47:25 2002 From: fink@es.net (Bob Fink) Date: Sun, 17 Feb 2002 17:47:25 -0800 Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please Message-ID: <5.1.0.14.0.20020217173855.01f221d8@imap2.es.net> 6bone Folk, We are seeing a recent increase in pTLA requests, and it prompts me to recommend a change in pTLA prefix length to allow for future growth. Basically I propose changing from the /28 prefixes we now allocate to /32: === The current 6bone pTLA numbering plan is: 3FFE:0000::/24 thru 3FFE:3900::/24 are allocated [there are 58 /24 pTLA's] 3FFE:8000::/28 thru 3FFE:8340::/28 are allocated [there are 54 /28 pTLA's] I propose: 3FFE:0000::/24 thru 3FFE:3F00::/24 [no new allocations here] 3FFE:8000::/28 thru 3FFE:83F0::/28 [no new allocations here] 3FFE:4000::/32 thru 3FFE:7FFF::/32 [which provides for 16K /32 pTLA's] leaving: 3FFE:8400::/32 thru 3FFE:FFFF::/32 for future use === In addition, I would like you to consider some possible policy changes: 1. requiring existing pTLA /24 and /28 holders to renumber to a new /32, unless justifying why it is not possible due to usage and/or address layout issues, within 6 months (12 months?) of the change in policy. 2. encouraging pTLA holders to apply for a production subTLA allocation when they move to a fully production mode; requiring those charging for service to also apply for a production subTLA allocation; requiring the pTLA to be released within 6 months (12 months?) of acquiring a subTLA unless justifying why the pTLA allocation is still needed/required. 3. pTLA holders should not assign pTLA based allocations to paying customers except for early test/trial purposes. paying customers should always receive RIR based allocations when service is not for test/trial purposes. 4. requiring a restatement of pTLA usage and continuing need every 2 years. 5. requiring the return of a pTLA when it is no longer used by the original requesting entity. this is the de facto policy, but has not been stated previously. Please send comments to the 6bone list by 4 March 2002. Thanks, Bob From michel@arneill-py.sacramento.ca.us Mon Feb 18 05:11:59 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 17 Feb 2002 21:11:59 -0800 Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please Message-ID: <2B81403386729140A3A899A8B39B046405DEC5@server2000.arneill-py.sacramento.ca.us> > Bob Fink wrote: > Please send comments to the 6bone list by 4 March 2002. 1,3,4,5 seems reasonable to me, although 1 will require more than wishing it. > We are seeing a recent increase in pTLA requests, This is no surprise to me. In the orchestrated absence of an IPv6 multihoming solution, it makes business sense to reserve a prefix, becoming a pTLA and then a subTLA does not seem an unreasonable cost to do business. > 2. encouraging pTLA holders to apply for a production subTLA > allocation when they move to a fully production mode; requiring > chose charging for service to also apply for a production > subTLA allocation; requiring the pTLA to be released within 6 > months (12 months?) of acquiring a subTLA unless justifying why > the pTLA allocation is still needed/required. I think this will be counter-productive, because it's exactly what people that apply for a pTLA for the sole purpose of getting their prefix advertised in the DFZ want. Once a RIR based allocation has been granted to people that have no real intention of becoming an ISP, it would be very difficult to take back, and that would be going back into the routing goop we see today in v4. Sure, it might clear some 6bone pTLAs, at the expense of permanent subTLAs in the DFZ. Michel. From kre@munnari.OZ.AU Mon Feb 18 07:23:10 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Mon, 18 Feb 2002 14:23:10 +0700 Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please In-Reply-To: <5.1.0.14.0.20020217173855.01f221d8@imap2.es.net> References: <5.1.0.14.0.20020217173855.01f221d8@imap2.es.net> Message-ID: <2091.1014016990@brandenburg.cs.mu.OZ.AU> Date: Sun, 17 Feb 2002 17:47:25 -0800 From: Bob Fink Message-ID: <5.1.0.14.0.20020217173855.01f221d8@imap2.es.net> | Basically I propose changing from the /28 prefixes we now allocate to /32: Sounds like a good idea to me. | 1. requiring existing pTLA /24 and /28 holders to renumber to a new /32, I'm not too worried about pTLA usage, but I think this would be a good idea. We need a lot more renumbering testing, and this looks like it would be a good way to show people what is involved, and gain a lot more data about what more is needed. The only justification for not doing it should (I think) be that a /32 isn't big enough for the number of addresses currently allocated (or expected to be in the very near future). And those people should still have to renumber - just back into a different one of the bigger blocks (after others have been returned by those renumbering into a /32) I think I'd tend to make the time limit closer to 3 months than 6 though. And while I don't have a pTLA, I do have addresses allocated by those who do, and so this means that I get to renumber because of 2nd hand action, which is something that we should be making very very clear will happen, and preparing for. The rest of your proposals I have no particular opinion on - I suspect that just forcing the 6bone space into renumbering from time to time will drive away the commercial users without the need for any specific policies, nor the need to go and attempt to ensure compliance. So, all this sounds like exactly what the 6bone should be being used for. kre From itojun@iijlab.net Mon Feb 18 08:08:46 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Mon, 18 Feb 2002 17:08:46 +0900 Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please In-Reply-To: fink's message of Sun, 17 Feb 2002 17:47:25 PST. <5.1.0.14.0.20020217173855.01f221d8@imap2.es.net> Message-ID: <1024.1014019726@itojun.org> >1. requiring existing pTLA /24 and /28 holders to renumber to a new /32, >unless justifying why it is not possible due to usage and/or address layout >issues, within 6 months (12 months?) of the change in policy. normally /24 or /28 pTLAs behave just like an ISP, and sub-allocates its address space (like /48) to childrens. for example, WIDE (3ffe:500::/24) has 3 layers of address sub-allocation (/40 and then /48) under it. it would be rather hard for those pTLAs to renumber all suballocated regions. (imagine renumbering x/8 to y/8, where there are suballocations like x.z.u.0/24) is the scenario realistic in actual IPv6 operation? isn't it too aggressive? (example: when sTLA gets more address space, they won't asked to return their previously allocated space) itojun From michael@kjorling.com Mon Feb 18 09:16:30 2002 From: michael@kjorling.com (Michael Kjorling) Date: Mon, 18 Feb 2002 10:16:30 +0100 (CET) Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please In-Reply-To: <5.1.0.14.0.20020217173855.01f221d8@imap2.es.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 17 2002 17:47 -0800, Bob Fink wrote: > 6bone Folk, > > We are seeing a recent increase in pTLA requests, and it prompts me to > recommend a change in pTLA prefix length to allow for future growth. > Basically I propose changing from the /28 prefixes we now allocate to /32: Just a reflection: why not change to a /35, which I believe is the normal production subTLA allocation? This would mean that when companies migrate to a production subTLA there will be significantly less work involved, as they can just hand out the very same NLA/SLAs but under the new prefix. Customers would have to renumber anyway, so there is little reason they cannot renumber to the same prefix, which still means changing only the first 48 bits of the address (plus *possibly* the SLA, but that would be unrelated to the prefix change). Comments, please? > === > The current 6bone pTLA numbering plan is: > > 3FFE:0000::/24 thru 3FFE:3900::/24 are allocated [there are 58 /24 pTLA's] > > 3FFE:8000::/28 thru 3FFE:8340::/28 are allocated [there are 54 /28 pTLA's] > > I propose: > > 3FFE:0000::/24 thru 3FFE:3F00::/24 [no new allocations here] > > 3FFE:8000::/28 thru 3FFE:83F0::/28 [no new allocations here] > > 3FFE:4000::/32 thru 3FFE:7FFF::/32 [which provides for 16K /32 pTLA's] > > leaving: > > 3FFE:8400::/32 thru 3FFE:FFFF::/32 for future use I have no objections against such an allocation except the /35 proposal I mentioned above. The 16,383 new pTLAs given by 3ffe:4000->7fff::/32 as well as the 31,743 still available under 3ffe:8400->ffff::/32 should be enough for the reasonably forseeable future (especially given that the 6bone is a testbed and not a "production" network). The policy changes (which I will comment on below) does not make this worse, either. > === > > In addition, I would like you to consider some possible policy changes: > > 1. requiring existing pTLA /24 and /28 holders to renumber to a new /32, > unless justifying why it is not possible due to usage and/or address layout > issues, within 6 months (12 months?) of the change in policy. This would hopefully mean that we'd move most current pTLAs into a /32 block. (Even though it would be nice to hear comments about my proposal of a /35 pTLA allocation scheme.) It certainly does not sound like a bad idea to me. > 2. encouraging pTLA holders to apply for a production subTLA allocation > when they move to a fully production mode; requiring those charging for > service to also apply for a production subTLA allocation; requiring the > pTLA to be released within 6 months (12 months?) of acquiring a subTLA > unless justifying why the pTLA allocation is still needed/required. This was a lot at once. Let's take your individual suggestions one by one: "encouraging pTLA holders to apply for a production subTLA allocation when they move to a fully production mode": Encouraging, yes. Forcing, no, I believe that is not the way to go (e.g. by revoking the pTLA allocation.) "requiring those charging for service to also apply for a production subTLA allocation": This is not by any means an unreasonable requirement. After all, if you are paying for access you probably expect production level service. The 6bone and IPv6 part of the Internet seems fairly stable to me, but I wouldn't exactly love paying for experimental services. For dial-in/cable/etc. ISPs especially, renumbering should be fairly simple, but even with customer /48 assignments it shouldn't be impossible. "requiring the pTLA to be released within 6 months (12 months?) of acquiring a subTLA unless justifying why the pTLA allocation is still needed/required": Once one has obtained a production subTLA I can see little need for keeping the pTLA, as long as the clients' networks can be renumbered without an extreme workload on the administrators (which in one sense would go against the idea behind address autoconfiguration and such anyway). Let's not forget what Michel Py mentioned, either. One way to try to help stopping global routing table pollution might be to require those applying for production subTLAs to actually provide ISP services to customers (whether for a fee or not), but this is something that would require further discussion. > 3. pTLA holders should not assign pTLA based allocations to paying > customers except for early test/trial purposes. paying customers should > always receive RIR based allocations when service is not for test/trial > purposes. This is something I certainly have no comments about, except that I agree with it. Even for trial purposes, having a dedicated block (say, perhaps a /40 or something on that order for a really big ISP) under a subTLA where addresses can be handed out is not unreasonable. That would mean a 1/32 of the /35 subTLA. > 4. requiring a restatement of pTLA usage and continuing need every 2 years. Not by any means unreasonable. Also see below. > 5. requiring the return of a pTLA when it is no longer used by the original > requesting entity. this is the de facto policy, but has not been stated > previously. Agreed. Another idea: require that pTLA allocations are returned or at least reconsidered when the need that prompted the allocation is no longer there. This seems to be standard practice today about IPv4 allocations (even for rather small allocations like my IPv4 /28) and I cannot see why IPv6 should have to be much different in that aspect? It is better to adapt such a policy while we are still at a fairly early stage than rushing to it later on. Comments, please? > Please send comments to the 6bone list by 4 March 2002. > > > Thanks, > > Bob Michael Kjörling - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e ``And indeed people sometimes speak of man's "bestial" cruelty, but this is very unfair and insulting to the beasts: a beast can never be so cruel as a man, so ingeniously, so artistically cruel.'' (Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov') *** Thinking about sending me spam? Take a close look at *** http://michael.kjorling.com/spam/ before doing so. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE8cMZyKqN7/Ypw4z4RAvCEAJ9ZFZXSYycn6GERBYGGe6PxnfyU2gCfbvjE F0zZiO7xXH6R4XdzKK/f3xk= =mWKg -----END PGP SIGNATURE----- From michael@kjorling.com Mon Feb 18 11:51:25 2002 From: michael@kjorling.com (Michael Kjorling) Date: Mon, 18 Feb 2002 12:51:25 +0100 (CET) Subject: (resend) Re: new 6bone pTLA prefix proposal, comments by 4 March 2002 please Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This doesn't seem to have made it to the list, so I am resending it. Sorry if it duplicates. Michael Kjörling - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e ``And indeed people sometimes speak of man's "bestial" cruelty, but this is very unfair and insulting to the beasts: a beast can never be so cruel as a man, so ingeniously, so artistically cruel.'' (Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov') *** Thinking about sending me spam? Take a close look at *** http://michael.kjorling.com/spam/ before doing so. - ---------- Forwarded message ---------- Date: Mon, 18 Feb 2002 10:16:30 +0100 (CET) From: Michael Kjorling To: 6bone <6bone@isi.edu> Subject: Re: new 6bone pTLA prefix proposal, comments by 4 March 2002 please On Feb 17 2002 17:47 -0800, Bob Fink wrote: > 6bone Folk, > > We are seeing a recent increase in pTLA requests, and it prompts me to > recommend a change in pTLA prefix length to allow for future growth. > Basically I propose changing from the /28 prefixes we now allocate to /32: Just a reflection: why not change to a /35, which I believe is the normal production subTLA allocation? This would mean that when companies migrate to a production subTLA there will be significantly less work involved, as they can just hand out the very same NLA/SLAs but under the new prefix. Customers would have to renumber anyway, so there is little reason they cannot renumber to the same prefix, which still means changing only the first 48 bits of the address (plus *possibly* the SLA, but that would be unrelated to the prefix change). Comments, please? > === > The current 6bone pTLA numbering plan is: > > 3FFE:0000::/24 thru 3FFE:3900::/24 are allocated [there are 58 /24 pTLA's] > > 3FFE:8000::/28 thru 3FFE:8340::/28 are allocated [there are 54 /28 pTLA's] > > I propose: > > 3FFE:0000::/24 thru 3FFE:3F00::/24 [no new allocations here] > > 3FFE:8000::/28 thru 3FFE:83F0::/28 [no new allocations here] > > 3FFE:4000::/32 thru 3FFE:7FFF::/32 [which provides for 16K /32 pTLA's] > > leaving: > > 3FFE:8400::/32 thru 3FFE:FFFF::/32 for future use I have no objections against such an allocation except the /35 proposal I mentioned above. The 16,383 new pTLAs given by 3ffe:4000->7fff::/32 as well as the 31,743 still available under 3ffe:8400->ffff::/32 should be enough for the reasonably forseeable future (especially given that the 6bone is a testbed and not a "production" network). The policy changes (which I will comment on below) does not make this worse, either. > === > > In addition, I would like you to consider some possible policy changes: > > 1. requiring existing pTLA /24 and /28 holders to renumber to a new /32, > unless justifying why it is not possible due to usage and/or address layout > issues, within 6 months (12 months?) of the change in policy. This would hopefully mean that we'd move most current pTLAs into a /32 block. (Even though it would be nice to hear comments about my proposal of a /35 pTLA allocation scheme.) It certainly does not sound like a bad idea to me. > 2. encouraging pTLA holders to apply for a production subTLA allocation > when they move to a fully production mode; requiring those charging for > service to also apply for a production subTLA allocation; requiring the > pTLA to be released within 6 months (12 months?) of acquiring a subTLA > unless justifying why the pTLA allocation is still needed/required. This was a lot at once. Let's take your individual suggestions one by one: "encouraging pTLA holders to apply for a production subTLA allocation when they move to a fully production mode": Encouraging, yes. Forcing, no, I believe that is not the way to go (e.g. by revoking the pTLA allocation.) "requiring those charging for service to also apply for a production subTLA allocation": This is not by any means an unreasonable requirement. After all, if you are paying for access you probably expect production level service. The 6bone and IPv6 part of the Internet seems fairly stable to me, but I wouldn't exactly love paying for experimental services. For dial-in/cable/etc. ISPs especially, renumbering should be fairly simple, but even with customer /48 assignments it shouldn't be impossible. "requiring the pTLA to be released within 6 months (12 months?) of acquiring a subTLA unless justifying why the pTLA allocation is still needed/required": Once one has obtained a production subTLA I can see little need for keeping the pTLA, as long as the clients' networks can be renumbered without an extreme workload on the administrators (which in one sense would go against the idea behind address autoconfiguration and such anyway). Let's not forget what Michel Py mentioned, either. One way to try to help stopping global routing table pollution might be to require those applying for production subTLAs to actually provide ISP services to customers (whether for a fee or not), but this is something that would require further discussion. > 3. pTLA holders should not assign pTLA based allocations to paying > customers except for early test/trial purposes. paying customers should > always receive RIR based allocations when service is not for test/trial > purposes. This is something I certainly have no comments about, except that I agree with it. Even for trial purposes, having a dedicated block (say, perhaps a /40 or something on that order for a really big ISP) under a subTLA where addresses can be handed out is not unreasonable. That would mean a 1/32 of the /35 subTLA. > 4. requiring a restatement of pTLA usage and continuing need every 2 years. Not by any means unreasonable. Also see below. > 5. requiring the return of a pTLA when it is no longer used by the original > requesting entity. this is the de facto policy, but has not been stated > previously. Agreed. Another idea: require that pTLA allocations are returned or at least reconsidered when the need that prompted the allocation is no longer there. This seems to be standard practice today about IPv4 allocations (even for rather small allocations like my IPv4 /28) and I cannot see why IPv6 should have to be much different in that aspect? It is better to adapt such a policy while we are still at a fairly early stage than rushing to it later on. Comments, please? > Please send comments to the 6bone list by 4 March 2002. > > > Thanks, > > Bob Michael Kjörling - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e ``And indeed people sometimes speak of man's "bestial" cruelty, but this is very unfair and insulting to the beasts: a beast can never be so cruel as a man, so ingeniously, so artistically cruel.'' (Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov') *** Thinking about sending me spam? Take a close look at *** http://michael.kjorling.com/spam/ before doing so. - ------------ Output from gpg ------------ gpg: Signature made Mon 18 Feb 2002 10:16:34 AM CET using DSA key ID 8A70E33E gpg: Good signature from "Michael Kjorling " gpg: aka "Michael Kjorling " - ---------- End of forwarded message ---------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE8cOrBKqN7/Ypw4z4RAp+vAKC/VswKlWRb7Ze3BmbTz8uGiLMeogCcCtb5 1PoTSIqgJo+mzUntdJO31SI= =RFL0 -----END PGP SIGNATURE----- From Francis.Dupont@enst-bretagne.fr Mon Feb 18 13:30:53 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Mon, 18 Feb 2002 14:30:53 +0100 Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please In-Reply-To: Your message of Sun, 17 Feb 2002 17:47:25 PST. <5.1.0.14.0.20020217173855.01f221d8@imap2.es.net> Message-ID: <200202181330.g1IDUrg36135@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: We are seeing a recent increase in pTLA requests, and it prompts me to recommend a change in pTLA prefix length to allow for future growth. => I can't see an emergency in the current allocation system: if we use a A-B-C class-like system, we have 3FFE:8000::/28 to 3FFE:BFF0::/28 ie. 1024 /28s when only 54 are already allocated. So we can wait for 400 new allocations before looking for something else. === In addition, I would like you to consider some possible policy changes: 1. requiring existing pTLA /24 and /28 holders to renumber to a new /32, unless justifying why it is not possible due to usage and/or address layout issues, within 6 months (12 months?) of the change in policy. => I understand that first comers have an unfair advantage but have we got complains? 2. encouraging pTLA holders to apply for a production subTLA allocation when they move to a fully production mode; requiring those charging for service to also apply for a production subTLA allocation; requiring the pTLA to be released within 6 months (12 months?) of acquiring a subTLA unless justifying why the pTLA allocation is still needed/required. => production subTLAs have very different usage policies than pTLAs, for instance here we have 2 subTLAs and 1 pTLA, we'd like to keep the pTLA for special cases, for instance when an individual asks for a site prefix. You may not do such things for subTLAs... and we (G6) can not apply for a subTLA because we are not an ISP. 3. pTLA holders should not assign pTLA based allocations to paying customers except for early test/trial purposes. paying customers should always receive RIR based allocations when service is not for test/trial purposes. => I agree: test/trial should always be free! 4. requiring a restatement of pTLA usage and continuing need every 2 years. => this makes sense only with 5. 5. requiring the return of a pTLA when it is no longer used by the original requesting entity. this is the de facto policy, but has not been stated previously. => I can't see a real need but I am by principle in favour of a real management of resources. Thanks Francis.Dupont@enst-bretagne.fr From michel@arneill-py.sacramento.ca.us Mon Feb 18 16:03:37 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 18 Feb 2002 08:03:37 -0800 Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please Message-ID: <2B81403386729140A3A899A8B39B046406C352@server2000.arneill-py.sacramento.ca.us> > Michael Kjorling wrote > Just a reflection: why not change to a /35, which I believe > is the normal production subTLA allocation? This would mean > that when companies migrate to a production subTLA there > will be significantly less work involved, as they can just > hand out the very same NLA/SLAs but under the new prefix. > Customers would have to renumber anyway, so there is little > reason they cannot renumber to the same prefix, which still > means changing only the first 48 bits of the address (plus > *possibly* the SLA, but that would be unrelated to the > prefix change). Associated with the intent of encouraging pTLAs to become subTLAS, this makes perfect sense. Michel. From michel@arneill-py.sacramento.ca.us Mon Feb 18 16:10:18 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 18 Feb 2002 08:10:18 -0800 Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please Message-ID: <2B81403386729140A3A899A8B39B046406C353@server2000.arneill-py.sacramento.ca.us> > Robert Elz wrote: > And while I don't have a pTLA, I do have addresses allocated by > those who do, and so this means that I get to renumber because > of 2nd hand action, which is something that we should be making > very very clear will happen, and preparing for. > I suspect that just forcing the 6bone space into renumbering from > time to time will drive away the commercial users without the > need for any specific policies, nor the need to go and attempt > to ensure compliance. > So, all this sounds like exactly what the 6bone should be being > used for. For once, I agree with kre here. Michel. From bmanning@karoshi.com Mon Feb 18 16:52:33 2002 From: bmanning@karoshi.com (bmanning@karoshi.com) Date: Mon, 18 Feb 2002 16:52:33 +0000 (UCT) Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please In-Reply-To: <5.1.0.14.0.20020217173855.01f221d8@imap2.es.net> from "Bob Fink" at Feb 17, 2002 05:47:25 PM Message-ID: <200202181652.QAA03851@vacation.karoshi.com> > In addition, I would like you to consider some possible policy changes: > > 1. requiring existing pTLA /24 and /28 holders to renumber to a new /32, > unless justifying why it is not possible due to usage and/or address layout > issues, within 6 months (12 months?) of the change in policy. > there are areas/places where renumbering fails miserably, notably within DNS, SNMP, NTP and anywhere applications depend on knowing the whereabouts of remote systems, -by address-. Many applications use the IP address to reduce the delay in a DNS lookup. These applications are sensitive to wholesale renumbering, often to to point that they have no idea how broadly the hardcoded IP address has spread. Other than that, I expect that having processes in place to evaluate useage is a good thing. --bill From michael@kjorling.com Mon Feb 18 20:51:31 2002 From: michael@kjorling.com (Michael Kjorling) Date: Mon, 18 Feb 2002 21:51:31 +0100 (CET) Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please In-Reply-To: <200202181652.QAA03851@vacation.karoshi.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just curious - and if this is way too far off topic here please let me know (off list obviously :)): what is the reason you cannot do an initial DNS lookup and then cache the results internally? Wouldn't that be a good policy to adopt when it comes to time-critical services? NTP is quite time critical by nature, I don't know about SNMP and DNS is an obvious case - hard to ask about something when there's no place to ask, and especially for computers. Again, if this is way too far from the 6bone list's subject, please let me know. Michael Kjörling On Feb 18 2002 16:52 -0000, bmanning@karoshi.com wrote: > there are areas/places where renumbering fails miserably, > notably within DNS, SNMP, NTP and anywhere applications > depend on knowing the whereabouts of remote systems, -by > address-. Many applications use the IP address to reduce > the delay in a DNS lookup. These applications are sensitive > to wholesale renumbering, often to to point that they have > no idea how broadly the hardcoded IP address has spread. > > Other than that, I expect that having processes in place > to evaluate useage is a good thing. > > --bill - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e ``And indeed people sometimes speak of man's "bestial" cruelty, but this is very unfair and insulting to the beasts: a beast can never be so cruel as a man, so ingeniously, so artistically cruel.'' (Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov') *** Thinking about sending me spam? Take a close look at *** http://michael.kjorling.com/spam/ before doing so. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE8cWlWKqN7/Ypw4z4RAuSCAKDfWcv1Kkr7fJRLlK6rOER05CGb0wCdEQD5 kpj3p8Anb5HarjNetMxPe28= =2TDJ -----END PGP SIGNATURE----- From robert@timetraveller.org Mon Feb 18 23:35:38 2002 From: robert@timetraveller.org (Robert Brockway) Date: Tue, 19 Feb 2002 09:35:38 +1000 (EST) Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please In-Reply-To: <200202181652.QAA03851@vacation.karoshi.com> Message-ID: On Mon, 18 Feb 2002 bmanning@karoshi.com wrote: > there are areas/places where renumbering fails miserably, > notably within DNS, SNMP, NTP and anywhere applications > depend on knowing the whereabouts of remote systems, -by > address-. Many applications use the IP address to reduce > the delay in a DNS lookup. These applications are sensitive > to wholesale renumbering, often to to point that they have > no idea how broadly the hardcoded IP address has spread. Imho, an application doing this is fundamentally broken. One day this will come back to bite, especially under IPv6. I believe that avoiding renumbering to cater for apps that did the wrong thing in the first place would be a big mistake. Besides, dns data is cached, so the first lookup might be slower but the rest should come off a local dns server. Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org ICQ: 104781119 Linux counter project ID #16440 (http://counter.li.org) blake: up 40 days, 8:00, 11 users, load average: 1.00, 1.00, 1.00 "The earth is but one country and mankind its citizens" -Baha'u'llah From allgoodg@san.rr.com Tue Feb 19 00:29:59 2002 From: allgoodg@san.rr.com (Guy L. Allgood) Date: Mon, 18 Feb 2002 16:29:59 -0800 Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please Message-ID: <01c1b8dc$8febdd80$181e9a1a@dhcp-248-101> Bill Et All, With good planning, ie reducing TTL's to near nothing 1 or 2 weeks in advance, minimizing caching, and having programmers/admins review where these hard coded addresses may reside; Most should be easily cut over where DNS and DNS services are concerned. The hard coding of addresses into your utils & programs should at best, IMHO, be considered bad practice. It may be a good thing to do this just to make certain none of these practices are being used and give all a chance to review what is being done and how to do it better. Just my 2 cents worth anyway, Guy -----Original Message----- From: bmanning@karoshi.com To: Bob Fink Cc: 6bone@ISI.EDU <6bone@ISI.EDU> Date: Monday, February 18, 2002 9:42 AM Subject: Re: new 6bone pTLA prefix proposal, comments by 4 March 2002 please >> In addition, I would like you to consider some possible policy changes: >> >> 1. requiring existing pTLA /24 and /28 holders to renumber to a new /32, >> unless justifying why it is not possible due to usage and/or address layout >> issues, within 6 months (12 months?) of the change in policy. >> > > there are areas/places where renumbering fails miserably, > notably within DNS, SNMP, NTP and anywhere applications > depend on knowing the whereabouts of remote systems, -by > address-. Many applications use the IP address to reduce > the delay in a DNS lookup. These applications are sensitive > to wholesale renumbering, often to to point that they have > no idea how broadly the hardcoded IP address has spread. > > Other than that, I expect that having processes in place > to evaluate useage is a good thing. > >--bill > > From bmanning@karoshi.com Tue Feb 19 04:35:10 2002 From: bmanning@karoshi.com (bmanning@karoshi.com) Date: Tue, 19 Feb 2002 04:35:10 +0000 (UCT) Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please In-Reply-To: <01c1b8dc$8febdd80$181e9a1a@dhcp-248-101> from "Guy L. Allgood" at Feb 18, 2002 04:29:59 PM Message-ID: <200202190435.EAA04414@vacation.karoshi.com> bad practice or no, with DNS, its part of the protocol. same is true of SNMP. MIBS use IP addresses, not names. > > Bill Et All, > > With good planning, ie reducing TTL's to near nothing 1 or 2 weeks in > advance, minimizing caching, and having programmers/admins review where > these hard coded addresses may reside; Most should be easily cut over where > DNS and DNS services are concerned. The hard coding of addresses into your > utils & programs should at best, IMHO, be considered bad practice. It may > be a good thing to do this just to make certain none of these practices are > being used and give all a chance to review what is being done and how to do > it better. > > Just my 2 cents worth anyway, > Guy > > -----Original Message----- > From: bmanning@karoshi.com > To: Bob Fink > Cc: 6bone@ISI.EDU <6bone@ISI.EDU> > Date: Monday, February 18, 2002 9:42 AM > Subject: Re: new 6bone pTLA prefix proposal, comments by 4 March 2002 please > > > >> In addition, I would like you to consider some possible policy changes: > >> > >> 1. requiring existing pTLA /24 and /28 holders to renumber to a new /32, > >> unless justifying why it is not possible due to usage and/or address > layout > >> issues, within 6 months (12 months?) of the change in policy. > >> > > > > there are areas/places where renumbering fails miserably, > > notably within DNS, SNMP, NTP and anywhere applications > > depend on knowing the whereabouts of remote systems, -by > > address-. Many applications use the IP address to reduce > > the delay in a DNS lookup. These applications are sensitive > > to wholesale renumbering, often to to point that they have > > no idea how broadly the hardcoded IP address has spread. > > > > Other than that, I expect that having processes in place > > to evaluate useage is a good thing. > > > >--bill > > > > > From bmanning@karoshi.com Tue Feb 19 04:36:48 2002 From: bmanning@karoshi.com (bmanning@karoshi.com) Date: Tue, 19 Feb 2002 04:36:48 +0000 (UCT) Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please In-Reply-To: from "Robert Brockway" at Feb 19, 2002 09:35:38 AM Message-ID: <200202190436.EAA04424@vacation.karoshi.com> broken or not, its part of the protocol design. "fixing" it will take more years than has been expended on IPv6. > > On Mon, 18 Feb 2002 bmanning@karoshi.com wrote: > > > there are areas/places where renumbering fails miserably, > > notably within DNS, SNMP, NTP and anywhere applications > > depend on knowing the whereabouts of remote systems, -by > > address-. Many applications use the IP address to reduce > > the delay in a DNS lookup. These applications are sensitive > > to wholesale renumbering, often to to point that they have > > no idea how broadly the hardcoded IP address has spread. > > Imho, an application doing this is fundamentally broken. One day this > will come back to bite, especially under IPv6. I believe that avoiding > renumbering to cater for apps that did the wrong thing in the first place > would be a big mistake. Besides, dns data is cached, so the first lookup > might be slower but the rest should come off a local dns server. > Rob > > -- Robert Brockway B.Sc. email: robert@timetraveller.org ICQ: 104781119 > Linux counter project ID #16440 (http://counter.li.org) > blake: up 40 days, 8:00, 11 users, load average: 1.00, 1.00, 1.00 > "The earth is but one country and mankind its citizens" -Baha'u'llah > From pim@ipng.nl Tue Feb 19 08:20:15 2002 From: pim@ipng.nl (Pim van Pelt) Date: Tue, 19 Feb 2002 09:20:15 +0100 Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please In-Reply-To: <5.1.0.14.0.20020217173855.01f221d8@imap2.es.net> References: <5.1.0.14.0.20020217173855.01f221d8@imap2.es.net> Message-ID: <20020219082015.GH4794@bfib.colo.bit.nl> Hi, Skimming through these notes, I would like to make one point. With the recent issues concerning multicast (sorry to bring it up yet again:), and global reachability for enterprises, I can very well imagine non ISPs requesting a pTLA status (or even taking their case to a RIR) just for them to be reachable via multiple paths. This would mean that large companies will get this status where they could/would not in the IPv4 world. I see a possible and even probable explosion of the DFZ with this in mind. The first example of this has been given by our collegues from Microsoft. Not to start a bash on them, on the contrary, their research into the protocol is much welcomed by me personally. It does illustrate the point, however. With the 6bone thouroughly intermixed with the sTLA world as of today, having a pTLA has no disadvantages over RIR space. The ARIN region even has to pay for their allocation in the first place. This seems to me as a potential threat to RIR policies in the mid term future. I find your points 2 and 4 to be of some use. We should make the pTLA requester aware that these network allocations made under the 3ffe::/16 network are not to be used to circumvent RIR policies. I myself use the pTLA and sTLA for INTOUCH-NL differently, and would not like to hand in, nor renumber, the current pTLA. For the record: my sTLA is used for native (ams-ix) paying customers and affiliates of Intouch NV, and the pTLA is kind of dedicated to the IPng project (the public tunnelbroker). It makes no sense to me to renumber IPng into the sTLA. I would like to keep playtime and business (well, future potential business, anyway ;-) separated. If point 4 is satisfied, why would the exception case in point 2 have to be proven ? The 4th remark however is very smart. We (the 6bone community) should require valid use and regular reports, I would even say every 12 months, in order for the entity to be granted continued use of their pTLA. This way we might be able to catch the potential RIR circumventing entities before they make use of the 6bone for production state networks. The other points seem quite usable, and a /32 bit pTLA means we will be able to go on for some time until we hit even half of the 16K scope of these networks. It will take some filtering updates on most of our routers though, as I think most of us accept only /28 in 3ffe:8000::/17 and /24 in 3ffe::/17 ie not -le 28 (at least I am very strict on policies at the moment). | In addition, I would like you to consider some possible policy changes: | | 1. requiring existing pTLA /24 and /28 holders to renumber to a new /32, | unless justifying why it is not possible due to usage and/or address layout | issues, within 6 months (12 months?) of the change in policy. | | 2. encouraging pTLA holders to apply for a production subTLA allocation | when they move to a fully production mode; requiring those charging for | service to also apply for a production subTLA allocation; requiring the | pTLA to be released within 6 months (12 months?) of acquiring a subTLA | unless justifying why the pTLA allocation is still needed/required. | | 3. pTLA holders should not assign pTLA based allocations to paying | customers except for early test/trial purposes. paying customers should | always receive RIR based allocations when service is not for test/trial | purposes. | | 4. requiring a restatement of pTLA usage and continuing need every 2 years. | | 5. requiring the return of a pTLA when it is no longer used by the original | requesting entity. this is the de facto policy, but has not been stated | previously. | | | Please send comments to the 6bone list by 4 March 2002. | | | Thanks, | | Bob -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From pekkas@netcore.fi Tue Feb 19 10:55:11 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Tue, 19 Feb 2002 12:55:11 +0200 (EET) Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please In-Reply-To: Message-ID: On Mon, 18 Feb 2002, Michael Kjorling wrote: > > We are seeing a recent increase in pTLA requests, and it prompts me to > > recommend a change in pTLA prefix length to allow for future growth. > > Basically I propose changing from the /28 prefixes we now allocate to /32: > > Just a reflection: why not change to a /35, which I believe is the > normal production subTLA allocation? This would mean that when > companies migrate to a production subTLA there will be significantly > less work involved, as they can just hand out the very same NLA/SLAs > but under the new prefix. Customers would have to renumber anyway, so > there is little reason they cannot renumber to the same prefix, which > still means changing only the first 48 bits of the address (plus > *possibly* the SLA, but that would be unrelated to the prefix change). Policy on /35 is in the process of being changed to something like /32. Anyway.. if you want to make sure pTLA have easy transition path to "sTLA", the size of pTLA should be no bigger than sTLA. In that case, just give /36 pTLA's. In any cast, ISP's pTLA addressing is usually a mess (because it will evolve during months and years) -- we, for example, definitely wanted to re-do the addressing for most part. But I'd tend to agree with Francis that there is no problem here. -- 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 fink@es.net Tue Feb 19 17:10:54 2002 From: fink@es.net (Bob Fink) Date: Tue, 19 Feb 2002 09:10:54 -0800 Subject: pTLA request for NTT-DOCOMO - review closes 5 March 2002 Message-ID: <5.1.0.14.0.20020219085928.02891990@imap2.es.net> 6bone Folk, NTT-DOCOMO has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 1 March 2002. Please send your comments to me or the list. Thanks, Bob === >From: "Christopher Martin Kerr" >To: "Bob Fink" >Subject: pTLA Request >Date: Tue, 19 Feb 2002 17:36:32 +0900 > >Dear Bob Fink and 6Bone members, > >On behalf of NTT DoCoMo, I would like to submit our application for a pTLA. >If allocated a pTLA we will use AS9605 in our peering relationships. >Please find our other relevant information below. > >------------------------------------------------------------------ > >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 have been connected to the 6Bone natively from 15 August 2001 as a >6Bone end-site, and from 29 November 2001 as a pNLA. > > 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. > >We have fully maintained, up to date, 6Bone Registry entries as follows: >ipv6-site objects: NTT-DOCOMO >inet6num objects: 3FFE:1802:1020::/48, 3FFE:1802:D000::/40 >mntner objects: NTT-DOCOMO-MNT >person objects: NO4-6BONE > > 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. > >We have fully maintained and reliable, BGP4+ peering and native IPv6 >connectivity between our boundary router, host02.ipver6.jp, and NTT-ECL, >our connection point into the 6Bone. Our router is IPv6 pingable. > > c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > entries for the Applicant's router(s) and at least one host > system. > >We have fully maintained DNS forward (AAAA) and reverse (ip.int) entries >for all our routers and hosts. Our DNS server is dns1.ipver6.jp at >202.245.184.3. > >We have DNS forward and reverse entries including the following router and >host: >Router: host02.ipver6.jp 3ffe:1802:1020:1::1/3ffe:1802:1020:2::2 >Host: host01.ipver6.jp 3ffe:1802:1020:1::2 > > 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. > >Our IPv6 pingable WWW server is www.ipver6.jp, and is accessible by both >IPv6 and IPv4. > > 2. The pTLA Applicant MUST have the ability and intent to provide > "production-quality" 6Bone backbone service. Applicants must > provide a statement and information in support of this claim. > This MUST include the following: > a. A support staff of two persons minimum, three preferable, with > person attributes registered for each in the ipv6-site object > for the pTLA applicant. > >We have a common mailbox for our support staff, >ipv6-query@nw.yrp.nttdocomo.co.jp. > > 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. > >Our common mailbox for contact purposes, ipv6-query@nw.yrp.nttdocomo.co.jp, >is pointed to with a notify attribute in the ipv6-site object NTT-DOCOMO. > > 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. > >Statement of User Community and Intent to Provide Production-Quality >IPv6 Backbone Services: >NTT DoCoMo is a major provider of mobile Internet services in Japan. We have >a potential "user community" which includes over 36 million mobile cellular >subscribers of which currently over 21 million are using our i-mode data >service. We are currently preparing to connect our IPv6 network to NSPIXP6 >where we intend to peer with other IPv6 backbone sites in the near future. >We are also currently building the infrastructure required to offer trial >IPv6 services in the near future via our 2G and 3G mobile cellular networks. >Additionally, we intend to use our pTLA to test IPv6 technologies on a >global >and/or multi-organizational basis. > > 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 all the current and future operational rules and >policies of the 6Bone > >---------------------------------------------------------- > >Thank you very much for your assistance, > >Christopher Martin Kerr > >*********************************** > NTT DoCoMo, Inc. > Network Laboratories > Christopher Martin KERR > $B!!(Bchris@nw.yrp.nttdocomo.co.jp > NTT DoCoMo R&D Center 3F, S-317 > 3-5 Hikarinooka, Yokosuka-shi, > Kanagawa, JAPAN 239-8536 > TEL: +81 468-40-3332 > FAX: +81 468-40-3781 >*********************************** From villearc@stealth.net Thu Feb 21 15:22:09 2002 From: villearc@stealth.net (Ville) Date: Thu, 21 Feb 2002 10:22:09 -0500 (EST) Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please In-Reply-To: <5.1.0.14.0.20020217173855.01f221d8@imap2.es.net> Message-ID: Bob, On Sun, 17 Feb 2002, Bob Fink wrote: > 1. requiring existing pTLA /24 and /28 holders to renumber to a new /32, > unless justifying why it is not possible due to usage and/or address layout ^ ^ I find myself comfortable with the rest of the policy being introduced, yet I feel it would be sad trying to enforce a specific rule for renumbering - especially with an exception clause such as the one above. I'll try and outline my own view on the issue below: The exception-clause still permits for /some/ of the current pTLA-holders to continue using their present 6BONE address- space. (logically) (1) This both, introduces an advantage over other pTLA-parties (size of address-space, continued usage) and also, in a nasty - yet imaginable - scenario, even further strenghtens the pTLA's will and desire to develop services that really cannot be renumbered into another IP-block. After all, it will make for the only means of sticking on to one's "own" (current, static and free) pTLA. -- Nobody says the services developed purely for the purpose wouldn't be all useful and beneficious, yet if the exception- clause didn't exist, the renumbering probably would also have been taken into account while developing the piece of software (or H/W, for that matter), effectively avoiding the unnecessary imbalance. (2) Unfortunately, if the exception-clause exists, a rule won't help make the address-space more coherent. Individual entries will still exist in a non-continuous 3ffe:80c0- zone. Result: We still can not filter the whole, future 3ffe::-space as one of unified length (be it /32 or any other), because of the pTLA-remnants. Also, it would be difficult to determine whether the old prefix is truly still being used or just has been hijacked by future spammers (like I assume is currently happening with swamp-/24's [IPv4-wise] popping in and out). This is mostly caused by the fact the zone and any IP- blocks under do remain technically legit as opposed to being fully invalidated - which would make possible for complete and thorough filtering of the space. Other issues that do come to kind about re-numbering on the practical level include-- (1) Fair amounts of link-lists (WWW/FTP/NTP/...) are currently being maintained, largely by volunteers. Any changes to current IP-addresses mean extra work, in addition to the normal pTLA->sTLA address-updates. I suspect some of the people maintaining these lists are no longer on the 6BONE themselves, thus resulting in a number of seemingly valid, yet non-working lists of sites. (Long version: Their page states the linked site belongs to company A, which more or less makes it looks like company A simply either does not provide the service anymore or that their server is down. While company B providing the outdated listing is more the cause.) I know, all these lists should be based on DNS, but on a quick look this often seems not to be the case. :-( Digging all the info up manually is tiresome and perhaps unneeded. (2) Peering loopback-addresses, physical connections to IX'es (if using 6BONE-address-space) and reverse-DNS-servers will all have to be renumbered. Esp. the renumbering of loopback-addresses and any related tasks will need assistance from both sides of any tunnels and links. While the above clearly is useful for ensuring people do not attempt to provide production-quality service on the 6BONE, it also does produce (read: generate) a fair amount of work and puts us a number of years back in terms of quality In my opinion, it effectively makes using 6BONE for gaining operational-experience more difficult: If you cannot reach a site by its old IP-address, should you first check if they have recently swapped into new address-space? Or whether the problem is on the link-level, BGP, filtering? Everything was already working smooth for once. ,) It adds for an extra level of complexity in trying to find out why something doesn't work. Even if we have developers participating on the 6BONE (or IPv6, in general), it does not (unfortunately) necessarily mean all of them are overly keen on following the politics. (I would personally view it as more logical that this development, even if over a longer time-spam, is indeed carried out under 3ffe::/16 as opposed to under the RIR-allocations at 2001::/16 which we were wishing to use solely for production.) (3) In practice, renumbering might degrade the number of companies wanting to provide near-production-quality evaluation of IPv6 for free. Roughly, I would assume this is how generic upper-management would find it: renumbering means work, free means no pay. (Conclusion: Why is the service being provided for free in the first place?) As pointed out by Pim, people have different uses for pTLAs and sTLAs. This also applies to us: pTLA is an easy way for us to permit non-customers free use and testing of our capabilities without the fear of them more representing neither us nor our customers. Apologies if any of this has been previously stated, I had quite some catching up to do with e-mails from the past week. The rest of the proposal sounds ideal. I'm glad it was brought up at this point-- It's always easier to introduce a full-blown policy in its wholeness for new participants, instead of having to add and sum up individual requirements along the way. As for the size of the future pTLA's, personally I would most be in favour of sizes either 1-2 bits less than the RIR- standard or alternatively exactly the same size. Pekka of Netcore already put it nicely. The first would make it possible for easy migration and the latter for more broadly unified bitmask-sizes. > Bob Cheers, -- Ville Network Security/IPv6 Solutions Stealth Communications, Inc. From michel@arneill-py.sacramento.ca.us Thu Feb 21 20:37:22 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 21 Feb 2002 12:37:22 -0800 Subject: new 6bone pTLA prefix proposal, comments by 4 March 2002 please Message-ID: <2B81403386729140A3A899A8B39B046405DED0@server2000.arneill-py.sacramento.ca.us> Bob, > 1. requiring existing pTLA /24 and /28 holders to renumber to a new > /32, unless justifying why it is not possible due to usage and/or > address layout Maybe you could say: 1. requiring pTLA /24 and /28 holders to resize to a /32 that begins at the same address their /24 or /28 block begins. Assuming all pTLA /24 and /28 holders have allocated their address space by the beginning of it (that remains to be seen), and that they have more than they really need, this will achieve the savings in space without forcing them to renumber (just changing the prefix is a lot less work). Michel. From BesP Mon Feb 25 15:48:23 2002 From: BesP (BesP) Date: Mon, 25 Feb 2002 16:48:23 +0100 Subject: new one Message-ID: <1675330605.20020225164823@toya.net.pl> Hello, I'm new on this list... and I wrote just to say "hello" to all of you :) -- Best regards, Adrian (BesP) Kujawski From cmartinez@protel.net.mx Mon Feb 25 20:01:27 2002 From: cmartinez@protel.net.mx (Carlos Alberto Martinez Arce) Date: Mon, 25 Feb 2002 14:01:27 -0600 Subject: Question Message-ID: <4768F61E0618D611937C0002A57513DF1A35A3@EXCNTS0> What do I need to request a /28 ?? and where I have to request to? Carlos Alberto Martínez Arce Transporte IP Operadora Protel S.A: C.V. I-Next tel.- +52 55 53290900 From cheryl@cosynsoftware.com Mon Feb 25 21:07:47 2002 From: cheryl@cosynsoftware.com (cheryl) Date: Tue, 26 Feb 2002 10:07:47 +1300 (NZDT) Subject: new one In-Reply-To: <1675330605.20020225164823@toya.net.pl> Message-ID: Hi Adrian! I'm new to the 6bone list too, and have been 'lurking' for a few weeks. Cheryl On Mon, 25 Feb 2002, BesP wrote: > Hello, > > I'm new on this list... and I wrote just to say "hello" to all of > you :) > > -- > Best regards, > Adrian (BesP) Kujawski > From nicolas.deffayet-extml@ndsoftwaregroup.com Mon Feb 25 23:45:18 2002 From: nicolas.deffayet-extml@ndsoftwaregroup.com (Nicolas DEFFAYET) Date: Tue, 26 Feb 2002 00:45:18 +0100 Subject: Question In-Reply-To: <4768F61E0618D611937C0002A57513DF1A35A3@EXCNTS0> Message-ID: <019601c1be56$7b05ff20$0103010a@localnet.ndsoftware.net> Hi Carlos, For request pTLA (a /28) you need: - You must have a minimum of 3 months qualifying experience as a 6bone site. - You must have a fully maintained, and reliable, BGP4+ peering and connectivity between other 6bone site. - You must have fully maintained DNS forward (AAAA) and reverse (ip6.int). - You muts have fully maintained, and reliable, IPv6-accessible system providing, at a mimimum, one or more web pages, describing your IPv6 services. - You must have a support staff of two persons minimum, three preferable, with person attributes registered for each in the ipv6-site object of your whois. - You must have a common mailbox for support. - You must respect the 6bone rules... For more information: http://www.6bone.net/6bone_pTLA_rqst.html. Regards, Nicolas DEFFAYET > -----Original Message----- > From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU] On > Behalf Of Carlos Alberto Martinez Arce > Sent: Monday, February 25, 2002 9:01 PM > To: 6bone@ISI.EDU > Subject: Question > > > What do I need to request a /28 ?? and where I have to request to? > > Carlos Alberto Martínez Arce > Transporte IP > Operadora Protel S.A: C.V. I-Next > tel.- +52 55 53290900 > From 6bone@pviet.delta6.net Tue Feb 26 10:18:23 2002 From: 6bone@pviet.delta6.net (Patrick Viet) Date: Tue, 26 Feb 2002 11:18:23 +0100 Subject: Question In-Reply-To: <019601c1be56$7b05ff20$0103010a@localnet.ndsoftware.net> References: <4768F61E0618D611937C0002A57513DF1A35A3@EXCNTS0> <019601c1be56$7b05ff20$0103010a@localnet.ndsoftware.net> Message-ID: <20020226101822.GA28441@azuria.altsync.net> On Tue, Feb 26, 2002 at 12:45:18AM +0100, Nicolas DEFFAYET wrote: > Hi Carlos, > > For request pTLA (a /28) you need: > > - You must have a minimum of 3 months qualifying experience as a 6bone > site. > - You must have a fully maintained, and reliable, BGP4+ peering and > connectivity between other 6bone site. > - You must have fully maintained DNS forward (AAAA) and reverse > (ip6.int). > - You muts have fully maintained, and reliable, IPv6-accessible system > providing, at a mimimum, one or more web pages, describing your IPv6 > services. > - You must have a support staff of two persons minimum, three > preferable, with person attributes registered for each in the ipv6-site > object of your whois. > - You must have a common mailbox for support. > - You must respect the 6bone rules... You also need to have a network and an AS number (a real one, not 65000 stuff). Already established v4 BGP to physical uplinks is the normal way. -- Patrick Viet, pviet@delta6.net on the web, http://pvi.n3.net/ From michael@kjorling.com Tue Feb 26 10:51:50 2002 From: michael@kjorling.com (Michael Kjorling) Date: Tue, 26 Feb 2002 11:51:50 +0100 (CET) Subject: Question In-Reply-To: <019601c1be56$7b05ff20$0103010a@localnet.ndsoftware.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Shouldn't ip6.arpa be included in this requirement as well? Just a thought. (Think BCP 49.) My understanding is that pTLA reverse DNS is delegated directly from ip6.arpa - this would certainly help migration from RFC 1886's ip6.int to BCP 49's ip6.arpa. Michael Kjörling PS. Please use a better subject line next time. "Question" says very little about the content of your e-mail. "/28 request rules" or something would have been better. On Feb 26 2002 00:45 +0100, Nicolas DEFFAYET wrote: > - You must have fully maintained DNS forward (AAAA) and reverse > (ip6.int). - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e ``And indeed people sometimes speak of man's "bestial" cruelty, but this is very unfair and insulting to the beasts: a beast can never be so cruel as a man, so ingeniously, so artistically cruel.'' (Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov') *** Spammers: see http://michael.kjorling.com/spam *** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE8e2jMKqN7/Ypw4z4RAlvyAKD+ItV+bgzDrCnwEDCH1wI+JmqWrwCgmiX+ AwJf8eglpsu6qTc8KfPxtWg= =TZJl -----END PGP SIGNATURE----- From bmanning@ISI.EDU Tue Feb 26 12:44:32 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Tue, 26 Feb 2002 04:44:32 -0800 (PST) Subject: Question In-Reply-To: from Michael Kjorling at "Feb 26, 2 11:51:50 am" Message-ID: <200202261244.g1QCiWs22884@boreas.isi.edu> Nope, not until ICANN acks (and processes) the requests to add the 6bone prefix into ip6.arpa. Only RIR delegations are in ip6.arpa. THe 6bone is still only in ip6.int. % -----BEGIN PGP SIGNED MESSAGE----- % Hash: SHA1 % % Shouldn't ip6.arpa be included in this requirement as well? Just a % thought. % % (Think BCP 49.) My understanding is that pTLA reverse DNS is delegated % directly from ip6.arpa - this would certainly help migration from RFC % 1886's ip6.int to BCP 49's ip6.arpa. % % % Michael Kjörling % PS. Please use a better subject line next time. "Question" says very % little about the content of your e-mail. "/28 request rules" or % something would have been better. % % % On Feb 26 2002 00:45 +0100, Nicolas DEFFAYET wrote: % % > - You must have fully maintained DNS forward (AAAA) and reverse % > (ip6.int). % % - -- % Michael Kjörling -- Programmer/Network administrator ^..^ % Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ % PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e % % ``And indeed people sometimes speak of man's "bestial" cruelty, but % this is very unfair and insulting to the beasts: a beast can never be % so cruel as a man, so ingeniously, so artistically cruel.'' % (Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov') % % *** Spammers: see http://michael.kjorling.com/spam *** % -----BEGIN PGP SIGNATURE----- % Version: GnuPG v1.0.6 (GNU/Linux) % Comment: Public key is at http://michael.kjorling.com/contact/pgp.html % % iD8DBQE8e2jMKqN7/Ypw4z4RAlvyAKD+ItV+bgzDrCnwEDCH1wI+JmqWrwCgmiX+ % AwJf8eglpsu6qTc8KfPxtWg= % =TZJl % -----END PGP SIGNATURE----- % % [End of raw data] -- --bill From fink@es.net Tue Feb 26 14:40:06 2002 From: fink@es.net (Bob Fink) Date: Tue, 26 Feb 2002 06:40:06 -0800 Subject: Question In-Reply-To: <200202261244.g1QCiWs22884@boreas.isi.edu> References: Message-ID: <5.1.0.14.0.20020226063907.02643d50@imap2.es.net> At 04:44 AM 2/26/2002 -0800, Bill Manning wrote: > Nope, not until ICANN acks (and processes) the requests to > add the 6bone prefix into ip6.arpa. Only RIR delegations are in > ip6.arpa. THe 6bone is still only in ip6.int. Agree with Bill on this. However, we will be working on this and hopefully it will become a requirement too. Bob From fink@es.net Tue Feb 26 14:42:22 2002 From: fink@es.net (Bob Fink) Date: Tue, 26 Feb 2002 06:42:22 -0800 Subject: Question In-Reply-To: <20020226101822.GA28441@azuria.altsync.net> References: <019601c1be56$7b05ff20$0103010a@localnet.ndsoftware.net> <4768F61E0618D611937C0002A57513DF1A35A3@EXCNTS0> <019601c1be56$7b05ff20$0103010a@localnet.ndsoftware.net> Message-ID: <5.1.0.14.0.20020226064136.02640ff8@imap2.es.net> At 11:18 AM 2/26/2002 +0100, Patrick Viet wrote: >On Tue, Feb 26, 2002 at 12:45:18AM +0100, Nicolas DEFFAYET wrote: > > Hi Carlos, > > > > For request pTLA (a /28) you need: > > > > - You must have a minimum of 3 months qualifying experience as a 6bone > > site. > > - You must have a fully maintained, and reliable, BGP4+ peering and > > connectivity between other 6bone site. > > - You must have fully maintained DNS forward (AAAA) and reverse > > (ip6.int). > > - You muts have fully maintained, and reliable, IPv6-accessible system > > providing, at a mimimum, one or more web pages, describing your IPv6 > > services. > > - You must have a support staff of two persons minimum, three > > preferable, with person attributes registered for each in the ipv6-site > > object of your whois. > > - You must have a common mailbox for support. > > - You must respect the 6bone rules... > >You also need to have a network and an AS number >(a real one, not 65000 stuff). Already established v4 BGP to physical >uplinks is the normal way. The AS number is a requirement for a pTLA. Bob From michel@arneill-py.sacramento.ca.us Wed Feb 27 01:01:53 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 26 Feb 2002 17:01:53 -0800 Subject: (6bone) New MHTP draft. Message-ID: <2B81403386729140A3A899A8B39B046406C3AA@server2000.arneill-py.sacramento.ca.us> 6boner, I just posted release 02a here: http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhtp-02a.txt This text contains numerous references to the 6bone. > Abstract: > This document describes a protocol for IPv6 Network Layer multihoming > (MHTP) that does not affect the size of the routing table in the IPv6 > DFZ (Default Free Zone) and does not use tunnels. MHTP is a router > solution and covers home/soho to very large environments. Enjoy, Michel. From pim@ipng.nl Thu Feb 28 07:50:24 2002 From: pim@ipng.nl (Pim van Pelt) Date: Thu, 28 Feb 2002 08:50:24 +0100 Subject: whois server unreachable Message-ID: <20020228075024.GA15752@bfib.colo.bit.nl> Dear admins, We cannot reach the 6bone whois server from AS8954,AS12859,AS1103. Are there any known problems with the network connectivity of the whois.6bone.net server ? Is there any means of duplicating this service? I would be interrested in running a (realtime) copy of the 6bone database at my site for the Europe region and also in order to help enable a higher availability of the database, which I actually use quite frequently. groet, Pim -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From jeroen@unfix.org Thu Feb 28 09:43:07 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 28 Feb 2002 10:43:07 +0100 Subject: whois.6bone.net outage? Message-ID: <001401c1c03c$5483f770$534510ac@cyan> David, Bob, Is the whois.6bone.net box down? jeroen@purgatory:~$ traceroute -v whois.6bone.net traceroute to whois.6bone.net (192.103.19.12), 30 hops max, 40 byte packets 1 gw-64-92.sms-1.ams-tel.cistron.net (195.64.92.1) 36 bytes to 195.64.92.136 20.639 ms 22.794 ms 20.606 ms 2 fa-0-0-1.rtr-1.ams-tel.cistron.net (62.216.31.1) 36 bytes to 195.64.92.136 22.591 ms 22.792 ms 21.888 ms 3 pos-1-1-0.rtr-1.ams-sar.cistron.net (195.64.64.53) 36 bytes to 195.64.92.136 21.926 ms 22.078 ms 21.081 ms 4 amsterdam11.nl.eqip.net (195.206.67.93) 36 bytes to 195.64.92.136 25.846 ms 23.220 ms 21.835 ms 5 amsterdam51.nl.eqip.net (195.90.65.125) 36 bytes to 195.64.92.136 24.101 ms 21.062 ms 21.538 ms 6 newyork51.us.eqip.net (195.206.65.58) 36 bytes to 195.64.92.136 113.222 ms 122.946 ms 111.780 ms 7 500.POS2-0.GW3.NYC4.ALTER.NET (157.130.22.149) 36 bytes to 195.64.92.136 117.064 ms 114.368 ms 113.437 ms 8 149.at-5-1-0.XR3.NYC4.ALTER.NET (152.63.24.142) 36 bytes to 195.64.92.136 113.810 ms 113.168 ms 112.970 ms 9 0.so-2-0-0.XL1.NYC4.ALTER.NET (152.63.17.29) 36 bytes to 195.64.92.136 100.850 ms 101.415 ms 100.669 ms 10 0.so-1-0-0.TL1.NYC9.ALTER.NET (152.63.23.113) 36 bytes to 195.64.92.136 113.839 ms 115.430 ms 115.572 ms 11 0.so-1-1-0.TL1.SAC1.ALTER.NET (152.63.10.78) 36 bytes to 195.64.92.136 165.259 ms 163.985 ms 163.926 ms 12 0.so-7-0-0.XL1.PAO1.ALTER.NET (152.63.54.133) 36 bytes to 195.64.92.136 167.203 ms 167.796 ms 167.998 ms 13 POS1-0.XR1.PAO1.ALTER.NET (152.63.54.74) 36 bytes to 195.64.92.136 179.395 ms 179.685 ms 185.108 ms 14 189.ATM7-0.GW8.PAO1.ALTER.NET (152.63.52.65) 36 bytes to 195.64.92.136 180.564 ms 203.031 ms 191.929 ms 15 Nokia-gw.customer.alter.net (157.130.200.242) 48 bytes to 195.64.92.136 189.251 ms 181.486 ms 182.755 ms 16 36 bytes from 195.64.64.53 to 195.64.92.136: icmp type 3 (Dest Unreachable) code 1 4: x00430045 8: x000021ef 12: x92a4113d 16: x885c40c3 20: x0d0420c6 24: x35002811 28: x6cd22f00 32: x00000000 Nokia-gw.customer.alter.net (157.130.200.242) 48 bytes to 195.64.92.136 181.655 ms !N 182.497 ms !N 180.552 ms !N Also it doesn't have any IPv6 address, would be nice to have a 6bone box be accessible by IPv6 ;) jeroen@purgatory:~$ traceroute6 www.6bone.net traceroute6 to 6bone.net (3ffe:b00:c18:1::10) from 3ffe:8114:1000::27, 30 hops max, 12 byte packets 1 tunnel-026.ipng.nl 22.377 ms 23.639 ms 22.869 ms 2 intouch.ipv6.viagenie.qc.ca 26.288 ms 27.004 ms 24.433 ms 3 rap.ipv6.viagenie.qc.ca 185.046 ms 183.016 ms 185.224 ms 4 www.6bone.net 184.685 ms 192.68 ms 189.426 ms Maybe we could setup somekind of mirroring service so that the whois database is kept on multiple (1+) hosts so this event doesn't happen, I think many IPv6 enabled sites rely on information from the whois database. IPng.nl for example registers all their users in it (mirrored locally ofcourse) but when a user signs up, he/she/* has to create an entry in the 6bone database first... Hope the box gets it's feet on the ground soon again. Greets, Jeroen From michael@kjorling.com Thu Feb 28 11:26:26 2002 From: michael@kjorling.com (Michael Kjorling) Date: Thu, 28 Feb 2002 12:26:26 +0100 (CET) Subject: whois server unreachable In-Reply-To: <20020228075024.GA15752@bfib.colo.bit.nl> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I can't get to there either. Seems like Nokia-gw.customer.alter.net (157.130.200.242) has a routing problem: > [michael@varg michael]$ traceroute -n whois.6bone.net > traceroute to whois.6bone.net (192.103.19.12), 30 hops max, 38 byte packets > 1 213.88.238.206 5.682 ms 4.589 ms 4.670 ms > ... > 20 152.63.52.77 186.913 ms 183.828 ms 191.933 ms > 21 157.130.200.242 187.227 ms 185.126 ms 318.574 ms > 22 157.130.200.242 374.907 ms !N 186.899 ms !N 208.958 ms !N > [michael@varg michael]$ Also, it would be nice to have a 6bone whois that is reachable over IPv6 as well. (No AAAA or A6 RRs exist at whois.6bone.net, at least.) My IPv4 upstream has AS3246 (route 213.88.128.0/17, Tele1Europe AB, SE) and I have no knowledge or control of their setup, or even our IPv4 border router (213.88.238.206). Michael Kjörling On Feb 28 2002 08:50 +0100, Pim van Pelt wrote: > Dear admins, > > We cannot reach the 6bone whois server from AS8954,AS12859,AS1103. Are > there any known problems with the network connectivity of the > whois.6bone.net server ? > > Is there any means of duplicating this service? I would be interrested > in running a (realtime) copy of the 6bone database at my site for the > Europe region and also in order to help enable a higher availability of > the database, which I actually use quite frequently. > > groet, > Pim - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e ``And indeed people sometimes speak of man's "bestial" cruelty, but this is very unfair and insulting to the beasts: a beast can never be so cruel as a man, so ingeniously, so artistically cruel.'' (Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov') *** Spammers: see http://michael.kjorling.com/spam *** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE8fhPoKqN7/Ypw4z4RAlMNAJ9qjGAZQ/1qICQz9DuDS7/jgQTVkQCglZB7 WQ73/hro/vWYeTGU5buO8wg= =FcNS -----END PGP SIGNATURE----- From randy@ipcenta.de Thu Feb 28 12:15:44 2002 From: randy@ipcenta.de (Andreas 'randy' Weinberger) Date: Thu, 28 Feb 2002 13:15:44 +0100 Subject: whois server unreachable References: <20020228075024.GA15752@bfib.colo.bit.nl> Message-ID: <008801c1c051$a56afa20$22005a0a@baby> ... > We cannot reach the 6bone whois server from AS8954,AS12859,AS1103. Are > there any known problems with the network connectivity of the > whois.6bone.net server ? the same from as 15671, semms like the whois and http server from whois.6bone.net and also http/whois whois.nokia.net are down quite for a while, i would say about 4-6 days? > I would be interrested > in running a (realtime) copy of the 6bone database at my site for the > Europe region and also in order to help enable a higher availability of > the database, which I actually use quite frequently. this whould be kewl ;) > groet, > Pim only my 2 (euro)cents, bye, --------- andreas 'randy' weinberger --------- internet system engineer, php development, sun microsystems workgroup computing expert & digitale videotechnik CompleTel GmbH (http://www.completel.de/) ------- From nicolas.deffayet-extml@ndsoftwaregroup.com Thu Feb 28 12:23:02 2002 From: nicolas.deffayet-extml@ndsoftwaregroup.com (Nicolas DEFFAYET) Date: Thu, 28 Feb 2002 13:23:02 +0100 Subject: whois server unreachable In-Reply-To: <20020228075024.GA15752@bfib.colo.bit.nl> Message-ID: <010e01c1c052$aaf21e50$0103010a@localnet.ndsoftware.net> > -----Original Message----- > From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU] On > Behalf Of Pim van Pelt > Sent: Thursday, February 28, 2002 8:50 AM > To: 6bone@ISI.EDU > Subject: whois server unreachable > > > Dear admins, > > We cannot reach the 6bone whois server from AS8954,AS12859,AS1103. Are > there any known problems with the network connectivity of the > whois.6bone.net server ? > > Is there any means of duplicating this service? I would be interrested > in running a (realtime) copy of the 6bone database at my site for the > Europe region and also in order to help enable a higher > availability of > the database, which I actually use quite frequently. > And run a 6bone whois database available in IPv6, because whois.6bone.net don't have IPv6 address. I think it's a good idea to have a multi whois databases (ARIN,6BONE,RIPE,APNIC) available in IPv6. Regards, Nicolas DEFFAYET From villearc@stealth.net Thu Feb 28 12:52:27 2002 From: villearc@stealth.net (Ville) Date: Thu, 28 Feb 2002 07:52:27 -0500 (EST) Subject: whois server unreachable In-Reply-To: <20020228075024.GA15752@bfib.colo.bit.nl> Message-ID: Pim, On Thu, 28 Feb 2002, Pim van Pelt wrote: > Is there any means of duplicating this service? I would be interrested > in running a (realtime) copy of the 6bone database at my site <...> Approved duplicates are already being ran. The primary WHOIS- server is not the only one available. Then again, if memory serves, the actual list of mirrors does reside on the very same host. :-) OTOH, I cannot help noticing even the mirror-servers *are* currently turning down 6BONE queries. whois.ra.net: "Source 6BONE (6bone) not found." whois.nic.fr: Some person-objects seem to be there, although fresh pTLA's et al do not turn up? Obsoleted 6BONE-wise? Personally, I would just contact the people behind the WHOIS- server(s) directly -- it's not impossible that the fault has gone unnoticed. David is probably the key-person here. Until he reacts, you can, however, just fetch the source for a capable WHOIS-daemon (RIPE+6BONE) and grab the DB dated Feb 25th (last succesful transfer) from: ftp://ftp.stealth.net/pub/mirrors/whois.6bone.net/ ...and run it for yourself. Works wonders. All in all, I would more imagine the number one objective is simply ensuring data-availability and the stability of the WHOIS-primary-- not necessarily immediately aiming for running db-synch with true parallelity et al. As for accessing the DB per modification, instead of utilizing batch-updates - such software more has its flaws in design rather than in implementation. Good guests do not starvate remote-resources with unnecessary per-connection overhead. Good guests commit per batch wherever applicable. :-) > Pim Cheers, -- Ville Network Security/IPv6 Solutions Stealth Communications, Inc. From ccordova@inictel.gob.pe Thu Feb 28 14:35:53 2002 From: ccordova@inictel.gob.pe (Claudia Cordova Yamauchi) Date: Thu, 28 Feb 2002 09:35:53 -0500 Subject: registering an island Message-ID: <200202281440.JAA20067@mail.inictel.gob.pe> Hi people I'm trying to register my ipv6 island from three days ago. From the Viagenie web site, I get the message: Temporary communication failure with whois server. Try later. Is there any other way for register my ipv6 island? Cheers Claudia From fink@es.net Thu Feb 28 16:02:57 2002 From: fink@es.net (Bob Fink) Date: Thu, 28 Feb 2002 08:02:57 -0800 Subject: Nokia primary whois service unreachable Message-ID: <5.1.0.14.0.20020228074914.0272ef38@imap2.es.net> Thanks for the notes on the Nokia primary whois service being unreachable. David Kessens (who is the maintainer of the primary) is travelling out of the country at the moment, but I am trying to get in touch with him so we can get the Nokia primary reachable again. I use the Viagenie query service so hadn't noticed that Nokia was unreachable. However, the Viagenie web i/f for modifying entries in their mirror and the primary appears to be refusing requests, probably because the primary is unreachable. I will get in touch with them to see what the problem. As for IPv6 accessible 6bone registry service, it is certainly time to make that happen. I will pursue this. Anyway, for queries only, go to the Viagenie 6bone registry page at: Thanks, Bob From Yaron.Oppenheim@ecitele.com Thu Feb 28 17:06:43 2002 From: Yaron.Oppenheim@ecitele.com (Yaron.Oppenheim@ecitele.com) Date: Thu, 28 Feb 2002 19:06:43 +0200 Subject: IP V6 overhead Message-ID: Hello, I am new to the forum - so first of all I would like to say Hello. Secondly I wonder if someone can explain to me the following: We are using the IP network for IP Telephony (VoIP) . Currently we are doing it by using IPV4 At IPV4 we are sending packet every 20 ms. The length of the payload is 160 bytes (without compression) and the overhead is 78 bytes (IP, UDP, RTP, L2 & L1). With IPV6 the overhead will be much larger because of the IP address fields. So we will reach a situation where the overhead will be much larger than the payload and the required bandwidth will be increased. How such a problem is solved at IPV6 ? Regards, Yaron Oppenheim From ji@research.att.com Thu Feb 28 17:52:39 2002 From: ji@research.att.com (ji@research.att.com) Date: Thu, 28 Feb 2002 12:52:39 -0500 (EST) Subject: IP V6 overhead Message-ID: <200202281752.MAA22781@bual.research.att.com> Look at RFC 3095 and 3096, and the rohc drafs. From nicolas.deffayet-extml@ndsoftwaregroup.com Thu Feb 28 17:54:55 2002 From: nicolas.deffayet-extml@ndsoftwaregroup.com (Nicolas DEFFAYET) Date: Thu, 28 Feb 2002 18:54:55 +0100 Subject: registering an island In-Reply-To: <200202281440.JAA20067@mail.inictel.gob.pe> Message-ID: <013d01c1c081$07da8480$0103010a@localnet.ndsoftware.net> Hi Claudia, The 6bone database (whois.6bone.net) is down since 25 fev. Try to ping whois.6bone.net (in IPv4), when the host is up, retry on the viagenie's interface. Regards, Nicolas DEFFAYET > -----Original Message----- > From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU] On > Behalf Of Claudia Cordova Yamauchi > Sent: Thursday, February 28, 2002 3:36 PM > To: 6bone@ISI.EDU > Subject: registering an island > > > Hi people > I'm trying to register my ipv6 island from three days ago. > From the Viagenie > web site, I get the message: Temporary communication failure > with whois > server. Try later. > Is there any other way for register my ipv6 island? > Cheers > Claudia > From david@IPRG.nokia.com Thu Feb 28 19:35:39 2002 From: david@IPRG.nokia.com (David Kessens) Date: Thu, 28 Feb 2002 11:35:39 -0800 Subject: Nokia primary whois service unreachable In-Reply-To: <5.1.0.14.0.20020228074914.0272ef38@imap2.es.net>; from fink@es.net on Thu, Feb 28, 2002 at 08:02:57AM -0800 References: <5.1.0.14.0.20020228074914.0272ef38@imap2.es.net> Message-ID: <20020228113539.A2227@iprg.nokia.com> On Thu, Feb 28, 2002 at 08:02:57AM -0800, Bob Fink wrote: > Thanks for the notes on the Nokia primary whois service being unreachable. > > David Kessens (who is the maintainer of the primary) is travelling out of > the country at the moment, but I am trying to get in touch with him so we > can get the Nokia primary reachable again. Bob Fink was able to reach me on my cellphone immediately after he became aware of the problem. I got things working again with some assistance of the local Nokia people. I would like to offer my apologies for this service interruption. It's a volunteer effort but I obviously want to offer a service as reliable as humanly possible. > As for IPv6 accessible 6bone registry service, it is certainly time to make > that happen. I will pursue this. I guess I owe something to the 6bone community now :-). Stay tuned. David K. --- From jeroen@unfix.org Thu Feb 28 20:44:48 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Thu, 28 Feb 2002 21:44:48 +0100 Subject: whois server unreachable In-Reply-To: Message-ID: <001b01c1c098$c3b4e9e0$420d640a@unfix.org> Bingo.... it works again :) I saw a delegation creation email arive in my mailbox... :) jeroen@purgatory:~$ ping whois.6bone.net PING whois.6bone.net (192.103.19.12): 56 data bytes 64 bytes from 192.103.19.12: icmp_seq=0 ttl=238 time=187.417 ms 64 bytes from 192.103.19.12: icmp_seq=1 ttl=238 time=189.585 ms Good.... back to business... Greets, Jeroen From fink@es.net Thu Feb 28 21:41:48 2002 From: fink@es.net (Bob Fink) Date: Thu, 28 Feb 2002 13:41:48 -0800 Subject: 6bone pTLA 3FFE:8350::/28 allocated to NL-BIT6 Message-ID: <5.1.0.14.0.20020228133941.026a2060@imap2.es.net> NL-BIT6 has been allocated pTLA 3FFE:8350::/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: [To create a reverse DNS registration for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to either bmanning@isi.edu or hostmaster@ep.net.] Thanks, Bob From mail@thomas--schaefer.de Thu Feb 28 21:57:24 2002 From: mail@thomas--schaefer.de (Thomas Schaefer) Date: Thu, 28 Feb 2002 22:57:24 +0100 Subject: IP V6 overhead In-Reply-To: References: Message-ID: <200202282247.33146@thomas--schaefer.de> Am Donnerstag, 28. Februar 2002 18:06 schrieben Sie: > Hello, >.... the overhead is 78 bytes (IP, UDP, RTP, L2 > & L1). With IPV6 the overhead will be much larger because of the IP address > fields. > So we will reach a situation where the overhead will be much larger than > the payload and the required bandwidth will be increased. > The header size is only 20 Bytes more (twice of ipv4 header). You are right - for short packets - the ratio payload/wholepacketsize is worse. But in your example: 160/(160+78)=0,67 160/(160+98)=0,62 I think both the new and the old value are not very nice. Regards, Thomas Schäfer