From L at bnmnetworks.net Wed May 5 18:30:06 2004 From: L at bnmnetworks.net (Scott Nelson) Date: Wed May 5 18:31:25 2004 Subject: [6bone] US based IPv6 Tunnel providers In-Reply-To: <40858D8C.9020802@fpsn.net> Message-ID: Your local ISP that you have a leased line with may be able to help but, other than that, I don't see a lot of them either. Mine ( UUnet ) as part of the service I have with them, give me a dedicated tunnel. This one is pretty good ( but in Canada ): http://www.freenet6.net/ Hope this helps. :-) Scotty On Tuesday, Apr 20, 2004, at 16:52 US/Eastern, Colin Faber wrote: > Hi folks, > > I'm wondering if any of you know of or operate any US based tunnels. > Currently I'm using HE.NET's service however recently I've been having > MAJOR problems and am now looking for an alternative. This is because > HE.NET's service has become unreliable for IPv6 technology > development. > > If anyone has any suggestions or recommendations I would love to hear > from you. > > > Thanks. > > -- > Colin Faber > FPSN.Net Development staff > email: cfaber@fpsn.net > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From cinnion at ka8zrt.com Wed May 5 18:58:20 2004 From: cinnion at ka8zrt.com (Douglas Wade Needham) Date: Wed May 5 18:59:18 2004 Subject: [6bone] US based IPv6 Tunnel providers In-Reply-To: References: <40858D8C.9020802@fpsn.net> Message-ID: <20040506015820.GB11878@pell.home.ka8zrt.com> If you have Covad, don't bother asking. 8( They are not even talking about v6 in their long term plans from what I have gotten from their upper level techs. - Doug Quoting Scott Nelson (L@bnmnetworks.net): > Your local ISP that you have a leased line with may be able to help > but, other than that, I don't see a lot of them either. > Mine ( UUnet ) as part of the service I have with them, give me a > dedicated tunnel. > > This one is pretty good ( but in Canada ): > http://www.freenet6.net/ > > Hope this helps. :-) > > Scotty > > > On Tuesday, Apr 20, 2004, at 16:52 US/Eastern, Colin Faber wrote: > > >Hi folks, > > > >I'm wondering if any of you know of or operate any US based tunnels. > >Currently I'm using HE.NET's service however recently I've been having > >MAJOR problems and am now looking for an alternative. This is because > >HE.NET's service has become unreliable for IPv6 technology > development. > > > >If anyone has any suggestions or recommendations I would love to hear > >from you. > > > > > >Thanks. > > > >-- > >Colin Faber > >FPSN.Net Development staff > >email: cfaber@fpsn.net > > > >_______________________________________________ > >6bone mailing list > >6bone@mailman.isi.edu > >http://mailman.isi.edu/mailman/listinfo/6bone > > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone -- Douglas Wade Needham - KA8ZRT UN*X Consultant & UW/BSD kernel programmer Email: cinnion @ ka8zrt . com http://cinnion.ka8zrt.com Disclaimer: My opinions are my own. Since I don't want them, why should my employer, or anybody else for that matter! From hansolofalcon at worldnet.att.net Wed May 5 19:20:36 2004 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Wed May 5 19:20:19 2004 Subject: [6bone] US based IPv6 Tunnel providers In-Reply-To: <20040506015820.GB11878@pell.home.ka8zrt.com> Message-ID: <001901c43310$b8878900$6401a8c0@who5> Hello from Gregg C Levine I agree. That's what I have, through AT&T. Both techs won't even acknowledge the existence of IPv6. It's a foreign technology to them. In fact they don't even have, or understand the need for an NTP server. In fact they don't support Linux, and barely support Macs. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."? Obi-Wan Kenobi > -----Original Message----- > From: 6bone-bounces@mailman.isi.edu [mailto:6bone-bounces@mailman.isi.edu] > On Behalf Of Douglas Wade Needham > Sent: Wednesday, May 05, 2004 9:58 PM > To: 6bone@mailman.isi.edu > Subject: Re: [6bone] US based IPv6 Tunnel providers > > If you have Covad, don't bother asking. 8( They are not even talking > about v6 in their long term plans from what I have gotten from their > upper level techs. > > - Doug > > Quoting Scott Nelson (L@bnmnetworks.net): > > Your local ISP that you have a leased line with may be able to help > > but, other than that, I don't see a lot of them either. > > Mine ( UUnet ) as part of the service I have with them, give me a > > dedicated tunnel. > > > > This one is pretty good ( but in Canada ): > > http://www.freenet6.net/ > > > > Hope this helps. :-) > > > > Scotty > > > > > > On Tuesday, Apr 20, 2004, at 16:52 US/Eastern, Colin Faber wrote: > > > > >Hi folks, > > > > > >I'm wondering if any of you know of or operate any US based tunnels. > > >Currently I'm using HE.NET's service however recently I've been having > > >MAJOR problems and am now looking for an alternative. This is because > > >HE.NET's service has become unreliable for IPv6 technology > development. > > > > > >If anyone has any suggestions or recommendations I would love to hear > > >from you. > > > > > > > > >Thanks. > > > > > >-- > > >Colin Faber > > >FPSN.Net Development staff > > >email: cfaber@fpsn.net > > > > > >_______________________________________________ > > >6bone mailing list > > >6bone@mailman.isi.edu > > >http://mailman.isi.edu/mailman/listinfo/6bone > > > > > > > _______________________________________________ > > 6bone mailing list > > 6bone@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/6bone > > -- > Douglas Wade Needham - KA8ZRT UN*X Consultant & UW/BSD kernel > programmer > Email: cinnion @ ka8zrt . com http://cinnion.ka8zrt.com > Disclaimer: My opinions are my own. Since I don't want them, why > should my employer, or anybody else for that matter! > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone From ipng at uni-muenster.de Thu May 6 01:45:40 2004 From: ipng at uni-muenster.de (Christian Schild) Date: Thu May 6 01:46:20 2004 Subject: [6bone] 3.f.f.e.ip6.int. delagations removed? Message-ID: <1083833140.2108.478.camel@lemy.ipv6.uni-muenster.de> Dear all, it looks like that since a few days ago the delegation for 4.0.e.f.f.3.ip6.int. to our name server is gone. Is there a reason why? I'd like to help repairing that as quick as possible. Checking the e.f.f.3.ip6.int. zone it is pretty empty compared to the number of valid 6bone prefixes? Was there some cleanup lately? So long, Christian -- JOIN - IP Version 6 in the WiN Christian Schild A DFN project Westfaelische Wilhelms-Universitaet Muenster http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung Team: join@uni-muenster.de Roentgenstrasse 9-13 Priv: schild@uni-muenster.de D-48149 Muenster / Germany GPG-/PGP-Key-ID: 6EBFA081 Fon: +49 251 83 31638, fax: +49 251 83 31653 From jeroen at unfix.org Thu May 6 06:30:51 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Thu May 6 06:32:22 2004 Subject: [6bone] 3.f.f.e.ip6.int. delagations removed? In-Reply-To: <1083833140.2108.478.camel@lemy.ipv6.uni-muenster.de> References: <1083833140.2108.478.camel@lemy.ipv6.uni-muenster.de> Message-ID: <1083850251.2382.1418.camel@segesta.zurich.ibm.com> On Thu, 2004-05-06 at 10:45, Christian Schild wrote: > Dear all, > > it looks like that since a few days ago the delegation for > 4.0.e.f.f.3.ip6.int. to our name server is gone. Is there a reason why? > I'd like to help repairing that as quick as possible. > > Checking the e.f.f.3.ip6.int. zone it is pretty empty compared to the > number of valid 6bone prefixes? Was there some cleanup lately? Cool, finally some movement! ;) I hope that this means that ip6.arpa is getting deployed for the 6bone. But that part of ip6.arpa still +trace's to the icann (butIwont) department. Therefor it is bad, hope they bring up ip6.arpa soon now. Tech details btw: int. 172800 IN NS NS.ISI.EDU. int. 172800 IN NS NS0.JA.NET. int. 172800 IN NS NS1.CS.UCL.AC.UK. int. 172800 IN NS NS.UU.NET. int. 172800 IN NS NS.ICANN.ORG. ;; Received 261 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 115 ms (Hoping that these are at least in sync) These are out of sync: NS0.JA.NET / NS.ISI.EDU / : ip6.int. 10384 IN NS z.ip6.int. ip6.int. 10384 IN NS ns3.nic.fr. ip6.int. 10384 IN NS flag.ep.net. ip6.int. 10384 IN NS y.ip6.int. NS1.CS.UCL.AC.UK / NS.UU.NET / NS.ICANN.ORG: ip6.int. 86400 IN NS y.ip6.int. ip6.int. 86400 IN NS z.ip6.int. ip6.int. 86400 IN NS ns3.nic.fr. ip6.int. 86400 IN NS flag.ep.net. ip6.int. 86400 IN NS imag.imag.fr. ip6.int. 86400 IN NS munnari.oz.au. But none of those carry ip6.int but some have the SOA: ip6.int. 86400 IN SOA z.ip6.int. hostmaster.ep.net. 1925902 10800 900 604800 129600 Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part Url : http://mailman.isi.edu/pipermail/6bone/attachments/20040506/1590908a/attachment.bin From pasky at xs26.net Thu May 6 07:32:53 2004 From: pasky at xs26.net (Petr Baudis) Date: Thu May 6 07:33:19 2004 Subject: [6bone] 3.f.f.e.ip6.int. delagations removed? In-Reply-To: <1083850251.2382.1418.camel@segesta.zurich.ibm.com> References: <1083833140.2108.478.camel@lemy.ipv6.uni-muenster.de> <1083850251.2382.1418.camel@segesta.zurich.ibm.com> Message-ID: <20040506143253.GO31404@pasky.ji.cz> Dear diary, on Thu, May 06, 2004 at 03:30:51PM CEST, I got a letter, where Jeroen Massar told me, that... > On Thu, 2004-05-06 at 10:45, Christian Schild wrote: > > Dear all, > > > > it looks like that since a few days ago the delegation for > > 4.0.e.f.f.3.ip6.int. to our name server is gone. Is there a reason why? > > I'd like to help repairing that as quick as possible. > > > > Checking the e.f.f.3.ip6.int. zone it is pretty empty compared to the > > number of valid 6bone prefixes? Was there some cleanup lately? > > Cool, finally some movement! ;) [ip6.arpa hopes] Is there? Well, I for one still see no e.f.f.3.ip6.arpa. delegation :-(. And our (3ffe:80e0::/28) delegation disappeared from ip6.int. as well, but it looks it reappeared right now. I asked Bob Fink about what's up yesterday but got no reply yet (perhaps because I should've probably got in touch with Bill Manning instead). BTW, we (XS26) are not "production v6" people but we were asking about e.f.f.3.ip6.arpa. for ages, especially on RIPE mailing lists etc. We've only pretty much given up after things didn't move a single bit for about 1.5 years... Kind regards, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ The rest is silence. -- Hamlet, V.2 From jeroen at unfix.org Thu May 6 07:55:17 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Thu May 6 07:57:21 2004 Subject: [6bone] 3.f.f.e.ip6.int. delagations removed? In-Reply-To: <20040506143253.GO31404@pasky.ji.cz> References: <1083833140.2108.478.camel@lemy.ipv6.uni-muenster.de> <1083850251.2382.1418.camel@segesta.zurich.ibm.com> <20040506143253.GO31404@pasky.ji.cz> Message-ID: <1083855317.2382.1536.camel@segesta.zurich.ibm.com> On Thu, 2004-05-06 at 16:32, Petr Baudis wrote: > Dear diary, on Thu, May 06, 2004 at 03:30:51PM CEST, I got a letter, > where Jeroen Massar told me, that... > > On Thu, 2004-05-06 at 10:45, Christian Schild wrote: > > > Dear all, > > > > > > it looks like that since a few days ago the delegation for > > > 4.0.e.f.f.3.ip6.int. to our name server is gone. Is there a reason why? > > > I'd like to help repairing that as quick as possible. > > > > > > Checking the e.f.f.3.ip6.int. zone it is pretty empty compared to the > > > number of valid 6bone prefixes? Was there some cleanup lately? > > > > Cool, finally some movement! ;) > [ip6.arpa hopes] > > Is there? Well, I for one still see no e.f.f.3.ip6.arpa. delegation :-(. > And our (3ffe:80e0::/28) delegation disappeared from ip6.int. as well, > but it looks it reappeared right now. I asked Bob Fink about what's up > yesterday but got no reply yet (perhaps because I should've probably got > in touch with Bill Manning instead). If you query z.ip6.int directly it works indeed. z.ip6.int: e.f.f.3.ip6.int. 6400 IN SOA dot.ep.net. hostmaster.ep.net. 2002091315 900 900 4800 9600 flag.ep.net: e.f.f.3.ip6.int. 6400 IN SOA dot.ep.net. hostmaster.ep.net. 2002091315 900 900 4800 9600 y.ipt.int doesn't know of anything imag.imag.fr: e.f.f.3.ip6.int. 6400 IN SOA dot.ep.net. hostmaster.ep.net. 2002091315 900 900 4800 9600 and on ns3.nic.fr, suddenly we see hexago suddenly with a new serial: e.f.f.3.ip6.int. 259200 IN SOA sonata.hexago.com. postmaster.hexago.com. 2004043002 10800 900 259200 86400 BUT: 1.1.8.e.f.f.3.ip6.int. 259200 IN NS ns1.ipng.nl. 1.1.8.e.f.f.3.ip6.int. 259200 IN NS ns2.ipng.nl. 1.1.8.e.f.f.3.ip6.int. 259200 IN NS ns3.ipng.nl. That is from a *old* zonefile, it had been changed to ns1/2/3.sixxs.net about a year ago, if it isn't more. Not that it matters much as that prefix will be taken out of use and returned per 6/6/2004 when IPng.nl will be laid next to the roses. One *COOL* thing here though: $ dig @sonata.hexago.com e.f.f.3.ip6.arpa $ dig @sonata.hexago.com e.f.f.3.ip6.arpa soa ; <<>> DiG 9.2.4rc2 <<>> @sonata.hexago.com e.f.f.3.ip6.arpa soa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51575 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3 ;; QUESTION SECTION: ;e.f.f.3.ip6.arpa. IN SOA ;; ANSWER SECTION: e.f.f.3.ip6.arpa. 259200 IN SOA sonata.hexago.com. postmaster.hexago.com. 2004043002 10800 900 259200 86400 ;; AUTHORITY SECTION: e.f.f.3.ip6.arpa. 259200 IN NS ns3.nic.fr. e.f.f.3.ip6.arpa. 259200 IN NS flag.ep.net. e.f.f.3.ip6.arpa. 259200 IN NS imag.imag.fr. e.f.f.3.ip6.arpa. 259200 IN NS sonata.hexago.com. ;; ADDITIONAL SECTION: imag.imag.fr. 6404 IN A 129.88.30.1 sonata.hexago.com. 259200 IN A 209.71.226.2 sonata.hexago.com. 259200 IN AAAA 2001:5c0:0:1::2 Joy joy... Hexago is going to run ip6.arpa for 6bone!!! ;) Now they'll just have to kick ICANN, but they probably won't. Also: ;; ANSWER SECTION: e.f.f.3.ip6.arpa. 259200 IN NS sonata.hexago.com. e.f.f.3.ip6.arpa. 259200 IN NS ns3.nic.fr. e.f.f.3.ip6.arpa. 259200 IN NS flag.ep.net. e.f.f.3.ip6.arpa. 259200 IN NS imag.imag.fr. Also good to see that there are both US and European boxes there. They might want to add a box in the APNIC region, maybe APNIC can help them out there? The connection to Hexago seems flay though: jeroen@purgatory:~$ traceroute6 2001:5c0:0:1::2 traceroute to 2001:5c0:0:1::2 (2001:5c0:0:1::2) from 2001:7b8:300:0:290:27ff:fe24:c19f, 30 hops max, 16 byte packets 1 gw-1.ede-01.nl.sixxs.net (2001:7b8:2ff::1) 32.611 ms 11.677 ms 12.514 ms 2 sixxs-gw.ipv6.network.bit.nl (2001:7b8:3:4f:290:6900:4fc6:d81f) 11.959 ms 14.168 ms 14.931 ms 3 jun1.sara.ipv6.network.bit.nl (2001:7b8::205:8500:120:7c1f) 13.186 ms 13.347 ms 13.308 ms 4 nikhef.ams-ix.ipv6.intouch.net (2001:7f8:1::a500:8954:1) 69.685 ms 45.262 ms 38.101 ms 5 tu-0.viagenie.mlpsca01.us.b6.verio.net (2001:418:0:4000::26) 170.824 ms 145.213 ms 163.389 ms 6 * * * 7 * * * Tracing to 6bone, which is supposed to also be hosted by Hexago, traces correctly over Viagenie (also Hexago, or was it... argh politics)... $ dig @ns3.nic.fr 1.1.8.e.f.f.3.ip6.arpa ns ; <<>> DiG 9.2.4rc2 <<>> @ns3.nic.fr 1.1.8.e.f.f.3.ip6.arpa ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56623 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.1.8.e.f.f.3.ip6.arpa. IN NS ;; AUTHORITY SECTION: 1.1.8.e.f.f.3.ip6.arpa. 259200 IN NS ns1.ipng.nl. 1.1.8.e.f.f.3.ip6.arpa. 259200 IN NS ns2.ipng.nl. 1.1.8.e.f.f.3.ip6.arpa. 259200 IN NS ns3.ipng.nl. Thus they *are* working on it, would have been nice if they told us so though (and if they had used a recent zone file etc...) Notez bien that nic.fr is also the box hosting .fr/.nl and various others. And the best thing: they have a very anxious IPv6 person who will make sure that IPv6 will stay working. > BTW, we (XS26) are not "production v6" people but we were asking about > e.f.f.3.ip6.arpa. for ages, especially on RIPE mailing lists etc. We've > only pretty much given up after things didn't move a single bit for > about 1.5 years... RIPE has no business with 6bone, except maybe for the fact that David is the RIPE IPv6 wg chair and runs the whois service. But the relation ends there... Complaining should be done here, but alas, not much response or updates :( Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part Url : http://mailman.isi.edu/pipermail/6bone/attachments/20040506/47c6dd5f/attachment.bin From pasky at xs26.net Thu May 6 08:32:02 2004 From: pasky at xs26.net (Petr Baudis) Date: Thu May 6 08:32:20 2004 Subject: [6bone] 3.f.f.e.ip6.int. delagations removed? In-Reply-To: <1083855317.2382.1536.camel@segesta.zurich.ibm.com> References: <1083833140.2108.478.camel@lemy.ipv6.uni-muenster.de> <1083850251.2382.1418.camel@segesta.zurich.ibm.com> <20040506143253.GO31404@pasky.ji.cz> <1083855317.2382.1536.camel@segesta.zurich.ibm.com> Message-ID: <20040506153202.GQ31404@pasky.ji.cz> Dear diary, on Thu, May 06, 2004 at 04:55:17PM CEST, I got a letter, where Jeroen Massar told me, that... > On Thu, 2004-05-06 at 16:32, Petr Baudis wrote: > > Dear diary, on Thu, May 06, 2004 at 03:30:51PM CEST, I got a letter, > > where Jeroen Massar told me, that... > > > On Thu, 2004-05-06 at 10:45, Christian Schild wrote: > > > > Dear all, > > > > > > > > it looks like that since a few days ago the delegation for > > > > 4.0.e.f.f.3.ip6.int. to our name server is gone. Is there a reason why? > > > > I'd like to help repairing that as quick as possible. > > > > > > > > Checking the e.f.f.3.ip6.int. zone it is pretty empty compared to the > > > > number of valid 6bone prefixes? Was there some cleanup lately? > > > > > > Cool, finally some movement! ;) > > [ip6.arpa hopes] > > > > Is there? Well, I for one still see no e.f.f.3.ip6.arpa. delegation :-(. ..snip.. > ;; AUTHORITY SECTION: > 1.1.8.e.f.f.3.ip6.arpa. 259200 IN NS ns1.ipng.nl. > 1.1.8.e.f.f.3.ip6.arpa. 259200 IN NS ns2.ipng.nl. > 1.1.8.e.f.f.3.ip6.arpa. 259200 IN NS ns3.ipng.nl. > > Thus they *are* working on it, would have been nice if they told us so > though (and if they had used a recent zone file etc...) > > Notez bien that nic.fr is also the box hosting .fr/.nl and various > others. And the best thing: they have a very anxious IPv6 person who > will make sure that IPv6 will stay working. Cool! It's great that something seems to be happening in the backstage... ;-) > > BTW, we (XS26) are not "production v6" people but we were asking about > > e.f.f.3.ip6.arpa. for ages, especially on RIPE mailing lists etc. We've > > only pretty much given up after things didn't move a single bit for > > about 1.5 years... > > RIPE has no business with 6bone, except maybe for the fact that David is > the RIPE IPv6 wg chair and runs the whois service. But the relation ends > there... > > Complaining should be done here, but alas, not much response or updates > :( Well at that time RIPE was supposed to run the 6BONE reverse delegations (and cooperate with B.M. on that, which didn't work out), I was told by some relevant people to complain at RIPE's. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ The rest is silence. -- Hamlet, V.2 From ipng at uni-muenster.de Thu May 6 08:32:47 2004 From: ipng at uni-muenster.de (Christian Schild) Date: Thu May 6 08:34:19 2004 Subject: [6bone] 3.f.f.e.ip6.int. delagations removed? In-Reply-To: <1083855317.2382.1536.camel@segesta.zurich.ibm.com> References: <1083833140.2108.478.camel@lemy.ipv6.uni-muenster.de> <1083850251.2382.1418.camel@segesta.zurich.ibm.com> <20040506143253.GO31404@pasky.ji.cz> <1083855317.2382.1536.camel@segesta.zurich.ibm.com> Message-ID: <1083857566.2108.638.camel@lemy.ipv6.uni-muenster.de> FYI, the ip6.int. table seems to be complete again (4.0.e.f.f.3.ip6.int. is in it again), while ip6.arpa. now carries the limited table ip6.int. had this morning. Guess we have to wait a little bit more :) Christian (starting to edit/add zonefiles :)) Am Do, den 06.05.2004 schrieb Jeroen Massar um 16:55: > On Thu, 2004-05-06 at 16:32, Petr Baudis wrote: > > Dear diary, on Thu, May 06, 2004 at 03:30:51PM CEST, I got a letter, > > where Jeroen Massar told me, that... > > > On Thu, 2004-05-06 at 10:45, Christian Schild wrote: > > > > Dear all, > > > > > > > > it looks like that since a few days ago the delegation for > > > > 4.0.e.f.f.3.ip6.int. to our name server is gone. Is there a reason why? > > > > I'd like to help repairing that as quick as possible. > > > > > > > > Checking the e.f.f.3.ip6.int. zone it is pretty empty compared to the > > > > number of valid 6bone prefixes? Was there some cleanup lately? > > > > > > Cool, finally some movement! ;) > > [ip6.arpa hopes] > > > > Is there? Well, I for one still see no e.f.f.3.ip6.arpa. delegation :-(. > > And our (3ffe:80e0::/28) delegation disappeared from ip6.int. as well, > > but it looks it reappeared right now. I asked Bob Fink about what's up > > yesterday but got no reply yet (perhaps because I should've probably got > > in touch with Bill Manning instead). -- JOIN - IP Version 6 in the WiN Christian Schild A DFN project Westfaelische Wilhelms-Universitaet Muenster http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung Team: join@uni-muenster.de Roentgenstrasse 9-13 Priv: schild@uni-muenster.de D-48149 Muenster / Germany GPG-/PGP-Key-ID: 6EBFA081 Fon: +49 251 83 31638, fax: +49 251 83 31653 From frederick.lefebvre at hexago.com Thu May 6 11:05:28 2004 From: frederick.lefebvre at hexago.com (Frederick Lefebvre) Date: Thu May 6 11:06:34 2004 Subject: [6bone] e.f.f.3.ip6.[int|arpa] update Message-ID: <58980000.1083866728@hades.hexago.com> All, As many persons noticed, we are in the final steps in the deployment of the e.f.f.3.ip6.arpa zone. In fact, it should be operational in a few days, as soon as the servers are properly registered (Bob is taking care of that). In a bid to integrate both the int and arpa zones, the e.f.f.3.ip6.int will be served by the same servers. The way the delegations are managed, is that the zone file is generated every day from the content of the 6Bone registry. So, to setup the reverse delegation for a 6Bone pTLA you need to add at least one 'rev-srv' entry to you inet6num object. This can be done on the 6Bone registry web interface at http://eng.hexago.com/6bone/registry/index.shtml. An official announcement will be made when everything is operational. In the meantime, we will have to live with an inconsistent e.f.f.3.ip6.int zone. Feel free to report any problems to support@eng.hexago.com. Regards, Frederick Lefebvre -- System and Network administrator Hexago Inc. (418)266-5533 ------------------------------------------------ http://www.freenet6.net : Free IPv6 Connectivity ------------------------------------------------ From jeroen at unfix.org Thu May 6 11:28:34 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Thu May 6 11:30:31 2004 Subject: [6bone] e.f.f.3.ip6.[int|arpa] update In-Reply-To: <58980000.1083866728@hades.hexago.com> References: <58980000.1083866728@hades.hexago.com> Message-ID: <1083868114.9049.15.camel@segesta.zurich.ibm.com> On Thu, 2004-05-06 at 20:05, Frederick Lefebvre wrote: > All, > > As many persons noticed, we are in the final steps in the deployment of the > e.f.f.3.ip6.arpa zone. In fact, it should be operational in a few days, as > soon as the servers are properly registered (Bob is taking care of that). > In a bid to integrate both the int and arpa zones, the e.f.f.3.ip6.int will > be served by the same servers. The way the delegations are managed, is > that the zone file is generated every day from the content of the 6Bone > registry. So, to setup the reverse delegation for a 6Bone pTLA you need to > add at least one 'rev-srv' entry to you inet6num object. This can be done > on the 6Bone registry web interface at > http://eng.hexago.com/6bone/registry/index.shtml. > > An official announcement will be made when everything is operational. In > the meantime, we will have to live with an inconsistent e.f.f.3.ip6.int > zone. Feel free to report any problems to support@eng.hexago.com. Well that is one very good thing to hear. About the 'rev-srv' entry, I do hope that is *only* for the pTLA's and not for every random zone below them ? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part Url : http://mailman.isi.edu/pipermail/6bone/attachments/20040506/aa72aff5/attachment.bin From L at bnmnetworks.net Thu May 6 12:23:18 2004 From: L at bnmnetworks.net (Scott Nelson) Date: Thu May 6 12:24:38 2004 Subject: [6bone] US based IPv6 Tunnel providers In-Reply-To: <20040506015820.GB11878@pell.home.ka8zrt.com> Message-ID: You are correct, as Covad uses Level3 as their backbone provider and L3 doesn't have any plans, at least immediately to do IPv6. I should have been more specific and said "Leased line" ISP or business class ISP. I dunno, maybe only UUnet offers at this point since 6Bone test nets are going away. http://www.ietf.org/rfc/rfc3701.txt?number=3701 HE.net does seem to be flaky lately. Maybe since they are offering IPv6 as a service now, the free stuff is going by the wayside. Scotty On Wednesday, May 5, 2004, at 21:58 US/Eastern, Douglas Wade Needham wrote: > If you have Covad, don't bother asking. 8( They are not even talking > about v6 in their long term plans from what I have gotten from their > upper level techs. > > - Doug > > Quoting Scott Nelson (L@bnmnetworks.net): >> Your local ISP that you have a leased line with may be able to help >> but, other than that, I don't see a lot of them either. >> Mine ( UUnet ) as part of the service I have with them, give me a >> dedicated tunnel. >> >> This one is pretty good ( but in Canada ): >> http://www.freenet6.net/ >> >> Hope this helps. :-) >> >> Scotty >> >> >> On Tuesday, Apr 20, 2004, at 16:52 US/Eastern, Colin Faber wrote: >> >>> Hi folks, >>> >>> I'm wondering if any of you know of or operate any US based tunnels. >>> Currently I'm using HE.NET's service however recently I've been >>> having >>> MAJOR problems and am now looking for an alternative. This is because >>> HE.NET's service has become unreliable for IPv6 technology > >>> development. >>> >>> If anyone has any suggestions or recommendations I would love to hear >>> from you. >>> >>> >>> Thanks. >>> >>> -- >>> Colin Faber >>> FPSN.Net Development staff >>> email: cfaber@fpsn.net >>> >>> _______________________________________________ >>> 6bone mailing list >>> 6bone@mailman.isi.edu >>> http://mailman.isi.edu/mailman/listinfo/6bone >>> >> >> _______________________________________________ >> 6bone mailing list >> 6bone@mailman.isi.edu >> http://mailman.isi.edu/mailman/listinfo/6bone > > -- > Douglas Wade Needham - KA8ZRT UN*X Consultant & UW/BSD kernel > programmer > Email: cinnion @ ka8zrt . com http://cinnion.ka8zrt.com > Disclaimer: My opinions are my own. Since I don't want them, why > should my employer, or anybody else for that matter! > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From gert at space.net Fri May 7 05:49:39 2004 From: gert at space.net (Gert Doering) Date: Fri May 7 05:50:25 2004 Subject: [6bone] US based IPv6 Tunnel providers In-Reply-To: References: <20040506015820.GB11878@pell.home.ka8zrt.com> Message-ID: <20040507124939.GC13090@Space.Net> Hi, On Thu, May 06, 2004 at 03:23:18PM -0400, Scott Nelson wrote: > You are correct, as Covad uses Level3 as their backbone provider and L3 > doesn't have any plans, at least immediately to do IPv6. > > I should have been more specific and said "Leased line" ISP or business > class ISP. NTT/Verio is offering business class IPv6 for their customers. http://www.verio.net/access/ipv6.cfm (Note that we're not related in any way to Verio, but I point this out because I appreciate the fact that they do invest in IPv6, instead of following the pack "nobody else is doing this yet!") Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From iljitsch at muada.com Sun May 9 07:42:27 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun May 9 07:43:27 2004 Subject: [6bone] Request: two 6bone pTLAs Message-ID: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> Now that I have your attention... For some time, I've been unhappy with the progress (or rather, lack thereof) in the area of DNS resolver discovery/configuration in IPv6. I've been advocating the well-known address (WKA) approach, as setting up DNS resolvers at well-known addresses doesn't require changes to existing implementations, and thus provides instant relief to those of us who want to experiment with running IPv6 in environments where having a way to automatically determine IPv6 DNS resolver addresses is important. Now obviously it would be possible to write a draft, try to get it published as an RFC and so on. But it's unlikely this will get consensus, and it's going to take a long time until such an RFC is published if it does. So what I'd like to do is put the final days (ok, years) of the 6bone to good use, and simply start a public resolver service using 6bone addresses. The idea is to use two addresses, that are then anycast, not unlike what's happening with the IPv4 root DNS servers. Note that this type of anycasting is different from regular IPv6 anycasting. Rather, the address block that contains the address(es) in question is sourced in BGP in different places at the same time. Anyone who wants to can then run an anycast instance, either public or private, just as with 6to4 relays. In order to be able to do this, it's important that the address blocks are big enough so that most people don't filter them. There must be at least two so that a problem with a specific instance of the address doesn't make the service unavailable. Additionally, it's possible that these well-known addresses find their way into software distributions and keep receiving lots of traffic for a long time. In order to avoid collateral damage in this case, it's a good idea to use two pTLAs for just this purpose and nothing else. These pTLAs can then be removed from BGP if and when the well-known addresses create operational problems. Even though new pTLAs aren't supposed to be given out anymore, I think this is a very useful experiment that fits well with the purpose of the 6bone, so an exception would be in order. Also, since the 6bone will be shut down in two years, this is the perfect opportunity to experiment with WKAs in IPv6 without having to fear long-lasting ill effects. From pim at ipng.nl Sun May 9 10:32:22 2004 From: pim at ipng.nl (Pim van Pelt) Date: Sun May 9 10:33:27 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> Message-ID: <20040509173222.GA11850@bfib.colo.bit.nl> Hi Iljitsch, | So what I'd like to do is put the final days (ok, years) of the 6bone | to good use, and simply start a public resolver service using 6bone | addresses. The idea is to use two addresses, that are then anycast, not | unlike what's happening with the IPv4 root DNS servers. Note that this | type of anycasting is different from regular IPv6 anycasting. Rather, | the address block that contains the address(es) in question is sourced | in BGP in different places at the same time. Anyone who wants to can | then run an anycast instance, either public or private, just as with | 6to4 relays. I support this, and would be interrested in running an anycast node from the AMS-IX/DE-CIX, providing you do the paperwork involved with prefix allocation. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From haesu at towardex.com Sun May 9 11:36:15 2004 From: haesu at towardex.com (James) Date: Sun May 9 11:58:27 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <20040509173222.GA11850@bfib.colo.bit.nl> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> <20040509173222.GA11850@bfib.colo.bit.nl> Message-ID: <20040509183615.GA22793@scylla.towardex.com> > | So what I'd like to do is put the final days (ok, years) of the 6bone > | to good use, and simply start a public resolver service using 6bone > | addresses. The idea is to use two addresses, that are then anycast, not > | unlike what's happening with the IPv4 root DNS servers. Note that this > | type of anycasting is different from regular IPv6 anycasting. Rather, > | the address block that contains the address(es) in question is sourced > | in BGP in different places at the same time. Anyone who wants to can > | then run an anycast instance, either public or private, just as with > | 6to4 relays. I support this as well. I am also willing to run an anycast node as well if this pTLA is approved. -J > I support this, and would be interrested in running an anycast node from > the AMS-IX/DE-CIX, providing you do the paperwork involved with prefix > allocation. > > groet, > Pim > -- > ---------- - - - - -+- - - - - ---------- > Pim van Pelt Email: pim@ipng.nl > http://www.ipng.nl/ IPv6 Deployment > ----------------------------------------------- > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From liman at autonomica.se Sun May 9 12:16:16 2004 From: liman at autonomica.se (Lars-Johan Liman) Date: Sun May 9 12:17:28 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> Message-ID: <22u0ype7i7.fsf@aptop.autonomica.net> iljitsch@muada.com: > Now that I have your attention... > For some time, I've been unhappy with the progress (or rather, lack > thereof) in the area of DNS resolver discovery/configuration in IPv6. > I've been advocating the well-known address (WKA) approach, as setting > up DNS resolvers at well-known addresses doesn't require changes to > existing implementations, and thus provides instant relief to those of > us who want to experiment with running IPv6 in environments where > having a way to automatically determine IPv6 DNS resolver addresses is > important. > ... Iljitsch, While I recognize that automagically finding resolvers can be quite important, I think that WKAs have already been proven to be not a dead end, but a velodrome from which you cannot escape, and where you just have to pedal faster and faster. There have, as you know, been a number of proposals on how to discover a suitable resolver, and I will make my voice heard against any solution that, by necltect, lack of understanding, disrespect, and/or pure stupidity, automagically will inject traffic into a third party's systems in a non-deterministic way. My strong feeling is that: 1) A client system shouldn't spew packets (DNS or other) on any other host, without local configuration to make it do so - preferrably through a local configurations service such as DHCP. This can be done within my own network or by my ISP, but the point is that it's a configuration that is local, and that can be adjusted as needed with reasonably short notice; and that an active measure is taken to make something happen. I really dislike a system where I or my ISP can be forced into starting an anycast instance just to balance the traffic and make sure that the service to the "local" clients is up to standard. Things shouldn't be turned "on" by default on the Internet, they should be turned "off". Otherwise you stand the risk of ending up like Windows, where every bell and whistle is turned on by default - open for each and every cracker to take advantage of. Automagically having them turned "on" also puts you in an awkward position from a legal standpoint: E.g., in court: Party1: "You keep bombarding me with traffic!" Party2: "I haven't turned on anything such, so it can't be my fault!" 2) Locking these well known addresses into systems is likely to cement the use of 6bone addressees in a way that we *REALLY* don't want to. How long did it take to wiggle out of the official use of net 10.0.0.0/8? 3) I think it opens up a Pandora's box of security issues that I, for one, don't want to touch even with my thickest gloves. (Regardless of the fact that DNSSEC (which *still* isn't operational - *that's* something for you!) is designed to be able to cope with mischievous resolvers.) 4) Comparing it to the anycast system that some of the root name servers (i.root-servers.net for one), is highly inapropriate, because in the root-ns case, all of the anycast instances are manages by the same operational entity, which gives a very good overview of traffic patterns and service levels. The system can be dynamically balanced to function well. This is not case when you have an anycast system where anyone can put in their service. A comparison with the AS112 system to service reverse mapping for the RFC 1918 address space would be more apropriate, but would still be limping, since the data is non-existing, and the whole point of that project is to return "NXDOMAIN", not active data. DHCP is the way to go. It's there, it works, it's been proven to fit into really small appliances. YMMV. Cheers, /Liman #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman@autonomica.se # Senior Systems Specialist ! HTTP : //www.autonomica.se/ # Autonomica AB, Stockholm ! Voice : +46 8 - 615 85 72 #---------------------------------------------------------------------- From iljitsch at muada.com Sun May 9 14:01:43 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun May 9 14:02:28 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <22u0ype7i7.fsf@aptop.autonomica.net> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> <22u0ype7i7.fsf@aptop.autonomica.net> Message-ID: <133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com> On 9-mei-04, at 21:16, Lars-Johan Liman wrote: > While I recognize that automagically finding resolvers can be quite > important, I think that WKAs have already been proven to be not a dead > end, but a velodrome from which you cannot escape, and where you just > have to pedal faster and faster. Do you have any pointers for this? > 1) A client system shouldn't spew packets (DNS or other) on any other > host, without local configuration to make it do so - preferrably > through a local configurations service such as DHCP. Why do you feel so strongly about this? I would be perfectly fine with stipulating that these addresses shouldn't be hardcoded by vendors, but rather specifically configured by end-users or their system administrators. Since these addresses will disappear in 2 years, hardcoding them would be counterproductive anyway. > I really dislike a system where I or my ISP can be forced into > starting an anycast instance just to balance the traffic and make > sure that the service to the "local" clients is up to standard. I don't see how you would be forced to start an anycast service. And if you were so forced, this means there is no uptake of a "real" DNS resolver discovery mechanism, so the alternative would be that users either have no resolvers, or have to find them manually. Both seem infinitely worse than any inconvenience caused by the well-known addresses. > Things shouldn't be turned "on" by default on the Internet, they > should be turned "off". Otherwise you stand the risk of ending up > like Windows, where every bell and whistle is turned on by default > - open for each and every cracker to take advantage > of. Automagically having them turned "on" also puts you in an > awkward position from a legal standpoint: > E.g., in court: > Party1: "You keep bombarding me with traffic!" > Party2: "I haven't turned on anything such, so it can't be my > fault!" I'm sorry, I don't find this argument convincing. > 2) Locking these well known addresses into systems is likely to cement > the use of 6bone addressees in a way that we *REALLY* don't want > to. 3ffe::/16 is going to be ususable anyway for years to come because of stray configuration that has to be cleaned up. And it's not like we're running out of IPv6 address space any time soon... > 3) I think it opens up a Pandora's box of security issues that I, for > one, don't want to touch even with my thickest gloves. Like what? > DHCP is the way to go. It's there, it works, it's been proven to fit > into really small appliances. Do you REALLY want to get into this on this list? Even if for the sake of argument it would be a good idea to run DHCP everywhere (which it isn't), then we still have the problem that some significant operating systems currently don't support it don't allow the user to add such support easily. Please understand that this is an experiment. It won't break the internet. From jorgen at hovland.cx Sun May 9 17:03:31 2004 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Sun May 9 17:04:28 2004 Subject: [6bone] Request: two 6bone pTLAs References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com><22u0ype7i7.fsf@aptop.autonomica.net> <133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com> Message-ID: <001b01c43622$3becf730$1b29b3d5@jjobbpc> ----- Original Message ----- From: "Iljitsch van Beijnum" To: "Lars-Johan Liman" Cc: <6bone@mailman.isi.edu> Sent: Sunday, May 09, 2004 10:01 PM Subject: Re: [6bone] Request: two 6bone pTLAs > On 9-mei-04, at 21:16, Lars-Johan Liman wrote: > > I would be perfectly fine with stipulating that these addresses > shouldn't be hardcoded by vendors, but rather specifically configured > by end-users or their system administrators. Since these addresses will > disappear in 2 years, hardcoding them would be counterproductive > anyway. > > > I really dislike a system where I or my ISP can be forced into > > starting an anycast instance just to balance the traffic and make > > sure that the service to the "local" clients is up to standard. > > I don't see how you would be forced to start an anycast service. And if > you were so forced, this means there is no uptake of a "real" DNS > resolver discovery mechanism, so the alternative would be that users > either have no resolvers, or have to find them manually. Both seem > infinitely worse than any inconvenience caused by the well-known > addresses. If you hardcode 1 nameserver address you need to setup anycast if you want to use a secondary backup nameserver - unless you hardcode 2 nameserver ip addresses of course. Then what about 3 or 8? What about WINS ? What about bootp servers ? What about dhcp + mac-filtering and static ips (not static mac)? Why should I expect less features with IPv6 than with IPv4? I am sure you can hardcode anything. Do you really believe in that we should hardcode addresses just because your router advertisement daemon doesn't scale? > > > Things shouldn't be turned "on" by default on the Internet, they > > should be turned "off". Otherwise you stand the risk of ending up > > like Windows, where every bell and whistle is turned on by default > > - open for each and every cracker to take advantage > > of. Automagically having them turned "on" also puts you in an > > awkward position from a legal standpoint: > > > E.g., in court: > > > Party1: "You keep bombarding me with traffic!" > > Party2: "I haven't turned on anything such, so it can't be my > > fault!" > > I'm sorry, I don't find this argument convincing. To the contrary, I find this very convincing. DNS is an important service on the internet - but it is certainly not mandatory for every single networked system on earth. > > > DHCP is the way to go. It's there, it works, it's been proven to fit > > into really small appliances. > > Do you REALLY want to get into this on this list? I must say that I agree with Mr Liman on this. DHCP works today and I don't see why the concept shouldn't work tomorrow. > > Even if for the sake of argument it would be a good idea to run DHCP > everywhere (which it isn't), then we still have the problem that some > significant operating systems currently don't support it don't allow > the user to add such support easily. You can say the same thing about router advertisement. From gert at space.net Mon May 10 08:56:51 2004 From: gert at space.net (Gert Doering) Date: Mon May 10 08:58:43 2004 Subject: [6bone] /20 allocated - update your BGP filters! Message-ID: <20040510155651.GA13854@Space.Net> Hi, the first IPv6 /20 allocation ever has been made today: inet6num: 2001:2000::/20 netname: EU-TELIANET-20040510 org: ORG-TIC2-RIPE descr: PROVIDER Local Registry descr: TeliaSonera AB country: EU and this means that "if you have been following my filtering recommendations, this network will not be accepted right now" (the current filters had a minimum accepted prefix length of a /24). I have updated the prefix filter recommendation page: http://www.space.net/~gert/RIPE/ipv6-filters.html and urge you to check whether your filters are prepared for these large prefixes. (There is a /23 upcoming, and rumors speak of a /19 being requested "real soon now"). TODO: the "strict" filter could do some grouping for different IPv6 allocation ranges, but this is dangerous today, as we don't know how future allocations will look like. Note: ICANN just doesn't get it. They have not allocated a reasonable prefix size to RIPE (like a /8), not even a /19, but "a big chunk of 14 sucessive /23s, summing up to a /20+/21+/22" - see the list at http://www.iana.org/assignments/ipv6-tla-assignments Gert Doering -- RIPE Address Policy WG Co-Chair, keeper of the IPv6 filter list -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From liman at autonomica.se Mon May 10 14:46:31 2004 From: liman at autonomica.se (Lars-Johan Liman) Date: Mon May 10 14:48:43 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> <22u0ype7i7.fsf@aptop.autonomica.net> <133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com> Message-ID: <22vfj4c5vs.fsf@aptop.autonomica.net> liman@autonomica.se: >> While I recognize that automagically finding resolvers can be quite >> important, I think that WKAs have already been proven to be not a dead >> end, but a velodrome from which you cannot escape, and where you just >> have to pedal faster and faster. iljitsch@muada.com: > Do you have any pointers for this? The one pointer I have and extrapolate from, is the story I was told about the appliance vendor that hardcoded IP-addresses to NTP servers at some university in ROM code in ther boxes. (Note ROM, so that it *CANNOT* be updated, even if the owner of the appliance was made aware of the problem, and had the necessary competence to do something about it.) >> 1) A client system shouldn't spew packets (DNS or other) on any other >> host, without local configuration to make it do so - preferrably >> through a local configurations service such as DHCP. > Why do you feel so strongly about this? Because I know that systems are put in the hands of people that know *NOTHING* about how they behave, and in no way have what it takes to foresee the effect in large systems. You cannot seriously mean that if I put up a server on the 'net, that I must be prepared to handle any amount of traffic that is generated not by people at will (surfers and crackers), but by the sheer fact that a software vendor decided that my box was a suitable target just because his random number generator happened to generate my IP address when he coded the crap. A box should remain silent, until you configure it to talk. Or, as I'm told the Irish say, in a proverb: "A man should refrain from talking, unless he can improve on silence." :-) (Exact wording modified by my bad memory.) > I would be perfectly fine with stipulating that these addresses > shouldn't be hardcoded by vendors, but rather specifically configured > by end-users or their system administrators. Since these addresses > will disappear in 2 years, hardcoding them would be counterproductive > anyway. That's a good step in the right direction, but there are two points where we probably have different opinions: a) You cannot stipulate anything on the 'net - especially not regarding operational practices. Hence someone *WILL* hardcode them - probably because its cheaper, and they want to use their money for marketing purposes instead, and because of that the product will sell really well, and "another university will have to shut down their NTP servers" (if you get my point). b) Because of a) (and quite possibly other similar problems), there will be a substantial market pressure to keep the 6bone addresses going *FAR* longer than for the coming 2 years. User: "Remind me again - what's *REALLY* the point of removing useful address space, that is uniquely distributed? I have invested heavily in this. You can't make me turn off these systems! It will ruin me! And if that happens, I will sue your butts off!" ... and when that happens in a US court, the outcome is given ... If the 6bone addresses are really taken out from the general IPv6 network infrastructure in two years time, I'll by you a beer. >> I really dislike a system where I or my ISP can be forced into >> starting an anycast instance just to balance the traffic and make >> sure that the service to the "local" clients is up to standard. > I don't see how you would be forced to start an anycast service. And > if you were so forced, this means there is no uptake of a "real" DNS > resolver discovery mechanism, so the alternative would be that users > either have no resolvers, or have to find them manually. Both seem > infinitely worse than any inconvenience caused by the well-known > addresses. Umm, I realize that I didn't use enough detail in my description. Suppose the following situation: ISP1 has contract with user that includes certain quality of service (in the general sense) clauses with regards to DNS. Users uses systems with DNS clients that use WKA, and not what the ISP1 tells them with DHCP. In order to fulfill its commitments, the ISP1 then has to start a DNS service on these WKA:s, because if they don't, the DNS packets will dissapear like turbo charged mosquitos towards the nearest lamp, um sorry, nearest WKA DNS server, which - by pure chance - happens to be operated by ISP2 (ISP1's fiercest competitor), which, of course, has a suitable filter for queries coming from ISP1, to which delay is added, and, just for fun, a certain amount of random malfunction. And - if ISP1 *does* start a service on the WKAs, they will have to jump through a few loops to make sure that just the right customers (a.k.a. they paying ones) reach their servers, so that they don't get hit when ISP2 turn theirs off, since they just realized that the DNS service comes for free at ISP1, if you just turn off your routing. Now, if the client took the DNS-data in DHCP, ISP1 could tell them which servers to use, and that would be the end of it. >> Things shouldn't be turned "on" by default on the Internet, they >> should be turned "off". Otherwise you stand the risk of ending up >> like Windows, where every bell and whistle is turned on by default >> - open for each and every cracker to take advantage >> of. Automagically having them turned "on" also puts you in an >> awkward position from a legal standpoint: >> E.g., in court: >> Party1: "You keep bombarding me with traffic!" >> Party2: "I haven't turned on anything such, so it can't be my >> fault!" > I'm sorry, I don't find this argument convincing. >From a legal standpoint, I find it important that the actions performed by a computer can be traced back to an individual who can be held responsible for them. I'm worried about the scenario where a person buys a computer, hooks it up to the 'net, and leaves it. "I didn't do anything, so it cannot be my fault!". The software vendor will say: "We didn't put the computer there, so it cannot be our fault!". Who's right? Who's fault is it? >> 2) Locking these well known addresses into systems is likely to cement >> the use of 6bone addressees in a way that we *REALLY* don't want >> to. > 3ffe::/16 is going to be ususable anyway for years to come because of > stray configuration that has to be cleaned up. And it's not like we're > running out of IPv6 address space any time soon... You'll be surprised. In the early days of the Internet, they weren't running short of addresses any time soon either, because they hade the *HUGE* address space of 8 bits! (IPv1 - I think.) And who would ever consider a computer network with *256* computers in it?! Inconcievable! To start with, the address space has been cut down to ~5.5E-20 of what it could be, since someone decided to waste the lower 64 bits on something that already unique! On top of that - what's killing IPv4 space is not the number of computers, but how the prefixes have been distributed, which has lead to both address depletion and routing table growth. Now, they're tossing out /20s in IPv6 land. That's pretty big chunks. Far bigger than the old /8s (class As), and their are mathematically exactly as many /20s in v6 land as there are in v4 land ... >> 3) I think it opens up a Pandora's box of security issues that I, for >> one, don't want to touch even with my thickest gloves. > Like what? Like me trusting the DNS answers from a resolver I have no relation with what so ever, and cannot even deterministically predict the topological location of. And - more important - the WKAs become very obvious targets for (e.g.) DDoS attacks. If the addresses are hard coded into the end nodes, it's *VERY* hard to get away from that situation. You *have* to maintain the service on exactly those addresses, and the your enemies will keep bombarding exactly those addresses. (BTW, this problem is already very real with existing WKA servers.) >> DHCP is the way to go. It's there, it works, it's been proven to fit >> into really small appliances. > Do you REALLY want to get into this on this list? I'm not quite sure. :-) But it seems to be too late for me to back out. :-) :-) > Even if for the sake of argument it would be a good idea to run DHCP > everywhere (which it isn't), Like where? :-) > then we still have the problem that some significant operating > systems currently don't support it don't allow the user to add such > support easily. That argument isn't convincing to *me*. :-) If the user is unhappy with the operating system, switch to another one. The market is full of them. Or, put pressure on the vendor to implement it. I will gladly list at least 4 operating systems, all of which run on a multitude of platforms (from palmtops to mainframes) and implement DHCP. And all of them are free. > Please understand that this is an experiment. It won't break the > internet. I agree that my arguments are geared more towards a general WKA scenario, than towards your specific proposal of using 6bone space for an experiment, but I think one has to deal with the principals, and not only with the details. Suppose your proposed experiment turns out to be a commercial success. What do you say to "your" users when the day comes to shut down 6bone? "Sorry, guys, the party is over."? No, I guess not. So you have to look at the future now already. How do you plan to migrate from a successful 6bone experiment to production in "real" IPv6 space? What about expansion: how many WKA prefixes do we expect in the long run and how do you deal with growth rate? If it can be used for DNS, others will find other applications for the technology, and one has to look into scaling problems. What happens when you do this to other services? Taking my example from above: How many services will ISP1 have to start on WKAs to fulfill all of its obligations towards the customer? Anycast is a two-edged sword. Using it as a means to work around the problems with the operating systems you mention could be the least senseless way to do it, but only if done on a local scale. The thing that scares me is the WKA part. I simply don't want that kind of implicit trust relationship between non-consenting partners. It worked when the Internet was a few thousand university hosts. It's not really feasible in a system where businesses turning over billions of dollars hinge on the function and non-function of servers that you cannot control. The DNS of today has bits of that, and I don't see it as good. There is, e.g., lots of legitimate concern about how to handle the situation with the root name servers, their respective operators, and their responsibilities. I want to move away from that uncertainty, although I don't know how to yet. This doesn't seem to be the right way. Cheers, /Liman From iljitsch at muada.com Tue May 11 03:27:32 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue May 11 03:28:52 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <22vfj4c5vs.fsf@aptop.autonomica.net> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> <22u0ype7i7.fsf@aptop.autonomica.net> <133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com> <22vfj4c5vs.fsf@aptop.autonomica.net> Message-ID: On 10-mei-04, at 23:46, Lars-Johan Liman wrote: >> Do you have any pointers for this? > The one pointer I have and extrapolate from, is the story I was told > about the appliance vendor that hardcoded IP-addresses to NTP servers > at some university in ROM code in ther boxes. (Note ROM, so that it > *CANNOT* be updated, even if the owner of the appliance was made aware > of the problem, and had the necessary competence to do something about > it.) This issue is completely orthogonal to what we're discussing here. Obviously hardcoding (emphasis on HARD) an address without consent from the people using that address is very bad. However, the whole point of this request is to set aside two prefixes especially for this purpose. If for some unfortunate reason the traffic to these addresses gets out of hand, the prefixes can be removed from the global routing table, no harm, no foul. >>> 1) A client system shouldn't spew packets (DNS or other) on any other >>> host, without local configuration to make it do so - preferrably >>> through a local configurations service such as DHCP. >> Why do you feel so strongly about this? > Because I know that systems are put in the hands of people that know > *NOTHING* about how they behave, and in no way have what it takes to > foresee the effect in large systems. Hence the need for controlled experimentation. >> I would be perfectly fine with stipulating that these addresses >> shouldn't be hardcoded by vendors, but rather specifically configured >> by end-users or their system administrators. Since these addresses >> will disappear in 2 years, hardcoding them would be counterproductive >> anyway. > That's a good step in the right direction, but there are two points > where we probably have different opinions: > a) You cannot stipulate anything on the 'net - especially not > regarding operational practices. Hence someone *WILL* hardcode them > - probably because its cheaper, and they want to use their money > for marketing purposes instead, and because of that the product > will sell really well, and "another university will have to shut > down their NTP servers" (if you get my point). If this happens, that will be a valuable, if unfortunate, lesson learned from the experiment. > b) Because of a) (and quite possibly other similar problems), there > will be a substantial market pressure to keep the 6bone addresses > going *FAR* longer than for the coming 2 years. There will be some pressure, sure. Nothing we can't press back against, though. Remember that these are values that the user can change herself, so any problems created here are non-fatal. Also, I would probably agree with you if the people that see no problem in clicking on .exe attachments were all using this. But for better or for worse, IPv6 deployment isn't quite that far yet. > If the 6bone addresses are really taken out from the general IPv6 > network infrastructure in two years time, I'll by you a beer. I don't like beer - but in this case I'll drink it. :-) >> I don't see how you would be forced to start an anycast service. > Umm, I realize that I didn't use enough detail in my description. > Suppose the following situation: > ISP1 has contract with user that includes certain quality of service > (in the general sense) clauses with regards to DNS. Users uses systems > with DNS clients that use WKA, and not what the ISP1 tells them with > DHCP. In order to fulfill its commitments, the ISP1 then has to start > a DNS service on these WKA:s, because if they don't, the DNS packets > will dissapear like turbo charged mosquitos towards the nearest lamp, > um sorry, nearest WKA DNS server, I really don't see the problem here. If you want to deliver a certain quality of service, obviously customers only get to complain if they actually use YOUR service. And if customers can't use DHCP (which is likely, I don't talk DHCP in v4 with my ISP either) then it's probably a lot easier for you to run a local WKA instance rather than distribute resolver addresses the oldfashioned way. >>> 3) I think it opens up a Pandora's box of security issues that I, for >>> one, don't want to touch even with my thickest gloves. >> Like what? > Like me trusting the DNS answers from a resolver I have no relation > with what so ever, and cannot even deterministically predict the > topological location of. This is immaterial. Either you run a DNS resolver and you know and control pretty much everything, or you don't and you don't. Which kind of address this resolver happens to have doesn't come into play here. > And - more important - the WKAs become very obvious targets for (e.g.) > DDoS attacks. If there are enough people running WKA instances this won't be a problem. > (BTW, this problem is already very real with existing WKA servers.) Like what? >>> DHCP is the way to go. It's there, it works, it's been proven to fit >>> into really small appliances. >> Do you REALLY want to get into this on this list? > I'm not quite sure. :-) But it seems to be too late for me to back > out. :-) :-) The reason I don't like DHCPv6 is that I don't want to run more services than necessary. I already have to run a router advertisement service, so it's a much better idea to have resolver addresses in there than add an extra service with all the potential for security problems that running services in general entails. >> then we still have the problem that some significant operating >> systems currently don't support it don't allow the user to add such >> support easily. > That argument isn't convincing to *me*. :-) > If the user is unhappy with the operating system, switch to another > one. Guess what, no operating system is perfect. All in all I'm happy with the one I use most, and I'm not about to give up the advantages it has just because YOU don't like well known addresses and think I should be running DHCPv6. > The market is full of them. Or, put pressure on the vendor to > implement it. I will gladly list at least 4 operating systems, all of > which run on a multitude of platforms (from palmtops to mainframes) > and implement DHCP. And all of them are free. Here you go. You feel that a portable, free OS is superior to one that's closely tuned to the hardware and is supported by paying users. I don't. >> Please understand that this is an experiment. It won't break the >> internet. > I agree that my arguments are geared more towards a general WKA > scenario, than towards your specific proposal of using 6bone space for > an experiment, but I think one has to deal with the principals, and > not only with the details. > Suppose your proposed experiment turns out to be a commercial > success. What do you say to "your" users when the day comes to shut > down 6bone? "Sorry, guys, the party is over."? No, I guess not. So you > have to look at the future now already. If this all works well then obviously the next step is thinking about permanent WKAs. Or hopefully there will be a widely implemented alternative by then, so permanent WKAs aren't needed. > How do you plan to migrate from a successful 6bone experiment to > production in "real" IPv6 space? Publish the new addresses, wait a while, remove the old ones. Same as all use of 6bone address space. > What about expansion: how many WKA prefixes do we expect in the long > run and how do you deal with growth rate? If it can be used for DNS, > others will find other applications for the technology, and one has to > look into scaling problems. What happens when you do this to other > services? Tell them to use well known NAMES instead. Which is exactly the way in which DNS resolvers are unique: you need to know their addresses rather than their names. From pasky at xs26.net Tue May 11 23:55:38 2004 From: pasky at xs26.net (Petr Baudis) Date: Tue May 11 23:56:35 2004 Subject: [6bone] Re: Request: two 6bone pTLAs In-Reply-To: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> Message-ID: <20040512065538.GQ31404@pasky.ji.cz> Dear diary, on Sun, May 09, 2004 at 04:42:27PM CEST, I got a letter, where Iljitsch van Beijnum told me, that... > Now obviously it would be possible to write a draft, try to get it > published as an RFC and so on. But it's unlikely this will get > consensus, and it's going to take a long time until such an RFC is > published if it does. I believe such a thing should be backed up at least by an I-D which is *about* to get a consensus. And allocating 6BONE prefixes for this sounds like a semi-official preliminary approval for such a policy so it should definitively aim for a consensus. An I-D would give this some formal backing as well as well summing up the arguments you have for such a thing. I for one don't find your current arguments very convincing. Could you be more specific about where exactly do you need to use such WKAs? And why an "experimental" stage would be useful for such a thing at all? Kind regards, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ The rest is silence. -- Hamlet, V.2 From pekkas at netcore.fi Wed May 12 02:08:01 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Wed May 12 02:08:34 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> Message-ID: On Sun, 9 May 2004, Iljitsch van Beijnum wrote: > Even though new pTLAs aren't supposed to be given out anymore, I think > this is a very useful experiment that fits well with the purpose of the > 6bone, so an exception would be in order. Also, since the 6bone will be > shut down in two years, this is the perfect opportunity to experiment > with WKAs in IPv6 without having to fear long-lasting ill effects. I have to oppose this for the simple logic: 1) we want to kill 6bone as soon as possible 2) for these prefixes to be useful, they have to implemented 3) withdrawing implementations takes a long time. So, giving out 6bone pTLAs would probably just lead to continuation of the 6bone mess. There is already a better process in place for something like this -- for example the experimental allocations: http://www.ripe.net/ripe/docs/ipv6policy.html#experiment-assignments -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From bob at thefinks.com Wed May 12 08:17:14 2004 From: bob at thefinks.com (Bob Fink) Date: Wed May 12 08:21:36 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> Message-ID: <6.1.0.6.2.20040512081050.01f77878@mail.addr.com> 6bone Folk, At 02:08 AM 5/12/2004, Pekka Savola wrote: >On Sun, 9 May 2004, Iljitsch van Beijnum wrote: > > Even though new pTLAs aren't supposed to be given out anymore, I think > > this is a very useful experiment that fits well with the purpose of the > > 6bone, so an exception would be in order. Also, since the 6bone will be > > shut down in two years, this is the perfect opportunity to experiment > > with WKAs in IPv6 without having to fear long-lasting ill effects. > >I have to oppose this for the simple logic: > 1) we want to kill 6bone as soon as possible > 2) for these prefixes to be useful, they have to implemented > 3) withdrawing implementations takes a long time. > >So, giving out 6bone pTLAs would probably just lead to continuation of >the 6bone mess. > >There is already a better process in place for something like this -- >for example the experimental allocations: >http://www.ripe.net/ripe/docs/ipv6policy.html#experiment-assignments I agree with Pekka. Also, given the process already gone through to draw up a 6bone community accepted phaseout plan, which was strongly supported by the IETF community with the approval of RFC 3701, no new 6bone 3FFE pTLA's can be allocated. I've enclosed the relevant part of RFC 3701 here: >2. 6bone Phaseout Plan > > To provide for the continuing useful operation of the 6bone, to the > extent that IETF consensus judges it to be useful, 6bone top level > address prefixes known as pseudo TLA's (pTLAs) MAY continue to be > allocated until January 1, 2004. > > Thus after the pTLA allocation cutoff date January 1, 2004, it is > REQUIRED that no new 6bone 3FFE pTLAs be allocated. > > To provide for sufficient planning time for 6bone participants to > convert to production IPv6 address prefixes, all 6bone prefixes > allocated by the cutoff time specified above, except for allocations > withdrawn as a matter of 6bone operating procedures, SHALL remain > valid until June 6, 2006. > > Thus after the 6bone phaseout date June 6, 2006, it is the intent > that no 6bone 3FFE prefixes, of any size/length, be used on the > Internet in any form. Network operators may filter 3FFE prefixes on > their borders to ensure these prefixes are not misused. > > > >Fink & Hinden Informational [Page 3] > >RFC 3701 6bone Phaseout Plan March 2004 > > > It should be noted that this RFC does not intend to imply that a > 6bone prefix holder, whether at the pTLA top level or lower, should > seek a production IPv6 address prefix at any specific level. It may > be entirely reasonable for a 6bone prefix holder to seek a higher > level, or a lower level, IPv6 prefix as their specific needs dictate. Thanks, Bob From paul at clubi.ie Wed May 12 10:36:45 2004 From: paul at clubi.ie (Paul Jakma) Date: Wed May 12 10:37:54 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <001b01c43622$3becf730$1b29b3d5@jjobbpc> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com><22u0ype7i7.fsf@aptop.autonomica.net> <133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com> <001b01c43622$3becf730$1b29b3d5@jjobbpc> Message-ID: On Mon, 10 May 2004, J?rgen Hovland wrote: > Why should I expect less features with IPv6 than with IPv4? I am > sure you can hardcode anything. I dont think Iljitsch is advocating that it not be possible to manually configure your resolver. > should hardcode addresses just because your router advertisement > daemon doesn't scale? RA does one thing, does it well. Resolver server addresses, etc, are outside its scope. > To the contrary, I find this very convincing. DNS is an important > service on the internet - but it is certainly not mandatory for > every single networked system on earth. I dont think Iljitsch is advocating that DNS be mandatory for all systems. I think he's asking to expirement with having a well-known address for recursive DNS service, so that hosts which _want_ to resolve addresses can use (by prior knowledge) an address which is guaranteed to work, while obviously still retaining ability to manually configure in resolver addresses. Imaginary configurability of implementation issues should have no bearing on whether a WKA for recursive DNS service is a good idea or not. > I must say that I agree with Mr Liman on this. DHCP works today and I don't > see why the concept shouldn't work tomorrow. Not everyone wants to run a DHCP client. Directing traffic for a WKA address to a suitable DNS server(s) would be far easier. I support Iljitsch's idea to try this as an experiment. I disagree that it requires two pTLAs. My feeling is that there should absolutely _NOT_ be any public DNS recursive service offered at the WKA because of the security implications of a widely used public recursive DNS service. Even as an experimental address, it should not be public, because of the risk of it becoming widely used. The WKA should be confined internally to organisations, as a convenience, should they wish to make use of it. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: Indifference will certainly be the downfall of mankind, but who cares? From jorgen at hovland.cx Wed May 12 12:15:26 2004 From: jorgen at hovland.cx (=?utf-8?Q?J=C3=B8rgen_Hovland?=) Date: Wed May 12 12:16:40 2004 Subject: [6bone] Request: two 6bone pTLAs References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com><22u0ype7i7.fsf@aptop.autonomica.net><133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com><001b01c43622$3becf730$1b29b3d5@jjobbpc> Message-ID: <009e01c43855$7e44a4e0$1b29b3d5@jjobbpc> ----- Original Message ----- From: "Paul Jakma" To: "J?rgen Hovland" Cc: <6bone@mailman.isi.edu>; "Lars-Johan Liman" Sent: Wednesday, May 12, 2004 6:36 PM Subject: Re: [6bone] Request: two 6bone pTLAs > On Mon, 10 May 2004, J?rgen Hovland wrote: > > RA does one thing, does it well. Resolver server addresses, etc, are > outside its scope. Yes, and that's the problem with it. > > > To the contrary, I find this very convincing. DNS is an important > > service on the internet - but it is certainly not mandatory for > > every single networked system on earth. > > I dont think Iljitsch is advocating that DNS be mandatory for all > systems. I think he's asking to expirement with having a well-known > address for recursive DNS service, so that hosts which _want_ to > resolve addresses can use (by prior knowledge) an address which is > guaranteed to work, while obviously still retaining ability to > manually configure in resolver addresses. > > Imaginary configurability of implementation issues should have no > bearing on whether a WKA for recursive DNS service is a good idea or > not. > > > I must say that I agree with Mr Liman on this. DHCP works today and I don't > > see why the concept shouldn't work tomorrow. > > Not everyone wants to run a DHCP client. > > Directing traffic for a WKA address to a suitable DNS server(s) would > be far easier. You still need to actually _know_ if the network use WKA or not. Determing that manually or by probing is not an acceptable solution. If you want WKA to work automaticly, you would need a way to advertise on the network that "we use WKA here", like RA. Doing that for all services cause N times amount of noise which could perhaps be done better dhcp style. It would be better to use something that could advertise the whole package (ntp, proxy, wins, bootp, nntp, smtp etc) maybe even depending on who you are (eg mac). Something like dhcp. Well, at least that's what I think. > > I support Iljitsch's idea to try this as an experiment. > > I disagree that it requires two pTLAs. My feeling is that there > should absolutely _NOT_ be any public DNS recursive service offered > at the WKA because of the security implications of a widely used > public recursive DNS service. Even as an experimental address, it > should not be public, because of the risk of it becoming widely used. > > The WKA should be confined internally to organisations, as a > convenience, should they wish to make use of it. Seconded. Joergen Hovland From paul at clubi.ie Wed May 12 13:44:49 2004 From: paul at clubi.ie (Paul Jakma) Date: Wed May 12 13:45:50 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <009e01c43855$7e44a4e0$1b29b3d5@jjobbpc> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com><22u0ype7i7.fsf@aptop.autonomica.net><133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com><001b01c43622$3becf730$1b29b3d5@jjobbpc> <009e01c43855$7e44a4e0$1b29b3d5@jjobbpc> Message-ID: On Wed, 12 May 2004, J?rgen Hovland wrote: > Yes, and that's the problem with it. There's little point in reinventing DHCP. > You still need to actually _know_ if the network use WKA or not. > Determing that manually or by probing is not an acceptable > solution. If you want WKA to work automaticly, you would need a way > to advertise on the network that "we use WKA here", This is arguable, and precisely something an experiment with such addresses could establish. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: Washington, D.C: Fifty square miles almost completely surrounded by reality. From jordi.palet at consulintel.es Wed May 12 17:16:13 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed May 12 17:18:07 2004 Subject: [6bone] RIRs and IPv6 Message-ID: <0b0e01c4387f$8302b010$7000000a@consulintel.es> FYI Regional Internet Registries, IPv6 Task Forces and IPv6 Forum Pledge Cooperative Support of Global IPv6 Deployment http://www.ist-ipv6.org/modules.php?op=modload&name=News&file=article&sid=547 TeliaSonera receives /20, the bigger IPv6 block up to now http://www.ist-ipv6.org/modules.php?op=modload&name=News&file=article&sid=546 Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From iljitsch at muada.com Thu May 13 03:06:12 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu May 13 03:06:45 2004 Subject: [6bone] Re: Request: two 6bone pTLAs In-Reply-To: <20040512065538.GQ31404@pasky.ji.cz> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> <20040512065538.GQ31404@pasky.ji.cz> Message-ID: <29B674E0-A4C5-11D8-B6DD-000A95CD987A@muada.com> On 12-mei-04, at 8:55, Petr Baudis wrote: > I believe such a thing should be backed up at least by an I-D which is > *about* to get a consensus. This is just not going to happen, just look at the attitude of the pro-DHCP crowd. From iljitsch at muada.com Thu May 13 03:14:06 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu May 13 03:14:45 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: References: Message-ID: <44616FE8-A4C6-11D8-B6DD-000A95CD987A@muada.com> On 12-mei-04, at 11:08, Pekka Savola wrote: > I have to oppose this for the simple logic: > 1) we want to kill 6bone as soon as possible We want to kill it off 6/6/6. That's two years from now. > 2) for these prefixes to be useful, they have to implemented Just configured. This can happen in five minutes. No code required. > 3) withdrawing implementations takes a long time. This is something that's only going to be used by a very small number of people: those who run IPv6-only at least some of the time and roam between different IPv6 network, OR people who specificially want to participate in the experiment. When the WKAs are removed, these people will no longer be able to resolve names so they'll reconfigure their systems fairly quickly. Obviously there will be some stray traffic for a long time, but this will be fairly insignificant in the grand scheme of things. Note that the value of these WKAs is that they are available everywhere, so as soon as the 6bone becomes unroutable in many parts of the network people will move away from the WKAs. > So, giving out 6bone pTLAs would probably just lead to continuation of > the 6bone mess. > There is already a better process in place for something like this -- > for example the experimental allocations: > http://www.ripe.net/ripe/docs/ipv6policy.html#experiment-assignments 6bone "mess" will have to be cleaned up (or left to be cooled off for a long time) anyway, this won't add a whole lot to this. On the other hand, doing this in RIR space creates a new mess that will probably be permanent. So using RIR space for just this experiment would be a mistake. From iljitsch at muada.com Thu May 13 03:21:00 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu May 13 03:21:50 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <6.1.0.6.2.20040512081050.01f77878@mail.addr.com> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> <6.1.0.6.2.20040512081050.01f77878@mail.addr.com> Message-ID: <3B113673-A4C7-11D8-B6DD-000A95CD987A@muada.com> On 12-mei-04, at 17:17, Bob Fink wrote: > Also, given the process already gone through to draw up a 6bone > community accepted phaseout plan, which was strongly supported by the > IETF community with the approval of RFC 3701, no new 6bone 3FFE pTLA's > can be allocated. I've enclosed the relevant part of RFC 3701 here: [...] >> Thus after the pTLA allocation cutoff date January 1, 2004, it is >> REQUIRED that no new 6bone 3FFE pTLAs be allocated. If you guys feel it's important to stick to this, then the obvious conclusion is that we'll have to use existing 6bone pTLAs for this. (Use of RFC 2119 terminology in informational RFCs in inappropriate, BTW.) Within a few days, I'll send out a message three or so relevant mailinglists asking people who are about to return their pTLAs to make them available for this purpose instead. From iljitsch at muada.com Thu May 13 03:43:04 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu May 13 03:44:01 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <009e01c43855$7e44a4e0$1b29b3d5@jjobbpc> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com><22u0ype7i7.fsf@aptop.autonomica.net><133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com><001b01c43622$3becf730$1b29b3d5@jjobbpc> <009e01c43855$7e44a4e0$1b29b3d5@jjobbpc> Message-ID: <504F233E-A4CA-11D8-B6DD-000A95CD987A@muada.com> On 12-mei-04, at 21:15, J?rgen Hovland wrote: >> Not everyone wants to run a DHCP client. >> Directing traffic for a WKA address to a suitable DNS server(s) would >> be far easier. > You still need to actually _know_ if the network use WKA or not. > Determing > that manually or by probing is not an acceptable solution. If you want > WKA > to work automaticly, you would need a way to advertise on the network > that > "we use WKA here", like RA. No, that's not the way it works. The well-known addresses would be available for everyone everywhere, so any type of advertising or probing is unnecessary. If the local network runs one or more anycast instances, then the requests will be handled locally. If not, the requests will find their way to a more remote anycast instance. So as long as there is connectivity to the IPv6 internet, the WKAs work. > It would be better > to use something that could advertise the whole package (ntp, proxy, > wins, > bootp, nntp, smtp etc) maybe even depending on who you are (eg mac). > Something like dhcp. Well, at least that's what I think. I just got a new cable internet connection to my home, and I'm not about to use the cable ISP's ntp, proxy, wins, nntp and smtp servers. (And what's bootp again? Did we use that in the '80s?) So I'm certainly not going to switch services whenever I hook up my notebook somewhere for a few hours. I'm sure some people will, but this is not something everyone needs. A DNS resolver on the other hand, is. Additionally, it's going to be YEARS before OSes and applications are going to be able to configure themselves with all of the above using DHCPv6 (if it ever happens). Paul wrote: >> I disagree that it requires two pTLAs. My feeling is that there >> should absolutely _NOT_ be any public DNS recursive service offered >> at the WKA because of the security implications of a widely used >> public recursive DNS service. Are you afraid people are going to run malicious DNS resolvers? That's an interesting problem. However, note that any ISP already gets to do this and much worse. >> Even as an experimental address, it >> should not be public, because of the risk of it becoming widely used. >> The WKA should be confined internally to organisations, as a >> convenience, should they wish to make use of it. So what exactly would be the purpose of having them? What I want is to be able to open up my laptop, have it autoconfigure an IPv6 address and just use the IPv6 internet without having to think about it. This is only going to work if the WKAs are reachable everywhere. An alternative to globally reachable WKAs would be site-local WKAs. I think Microsoft even uses those already. But waiting for the whole world to implement those isn't very attractive and then there is the whole site-local problem [sorry about using up so much bandwidth, btw] From jeroen at unfix.org Thu May 13 04:43:14 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Thu May 13 04:44:46 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <504F233E-A4CA-11D8-B6DD-000A95CD987A@muada.com> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> <22u0ype7i7.fsf@aptop.autonomica.net> <133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com> <001b01c43622$3becf730$1b29b3d5@jjobbpc> <009e01c43855$7e44a4e0$1b29b3d5@jjobbpc> <504F233E-A4CA-11D8-B6DD-000A95CD987A@muada.com> Message-ID: <1084448586.2409.2772.camel@segesta.zurich.ibm.com> On Thu, 2004-05-13 at 12:43, Iljitsch van Beijnum wrote: > On 12-mei-04, at 21:15, J?rgen Hovland wrote: > > >> Not everyone wants to run a DHCP client. Of which I am one of them. Also sticking a lot of options into DHCP makes applications depend on DHCP and there simply is not DHCP everywhere, we do have routing everywhere :) > >> Directing traffic for a WKA address to a suitable DNS server(s) would > >> be far easier. It indeed is. > > You still need to actually _know_ if the network use WKA or not. > > Determing > > that manually or by probing is not an acceptable solution. If you want > > WKA > > to work automaticly, you would need a way to advertise on the network > > that > > "we use WKA here", like RA. > > No, that's not the way it works. The well-known addresses would be > available for everyone everywhere, so any type of advertising or > probing is unnecessary. > > If the local network runs one or more anycast instances, then the > requests will be handled locally. If not, the requests will find their > way to a more remote anycast instance. So as long as there is > connectivity to the IPv6 internet, the WKAs work. I agree fully with you and I also see that this really something I would like to have. Though I would either not directly use DNS but a small udp challenge/response which could return multiple responses directing to these DNS servers and maybe even some more information, like standaard services (outgoing smtp etc) in the local network depending on how much information is given to the server responding to the request. > >> The WKA should be confined internally to organisations, as a > >> convenience, should they wish to make use of it. An organisation can announce/route the prefix used by these DNS or other discovery servers them selves and that issue is solved. > So what exactly would be the purpose of having them? What I want is to > be able to open up my laptop, have it autoconfigure an IPv6 address and > just use the IPv6 internet without having to think about it. This is > only going to work if the WKAs are reachable everywhere. Indeed and this doesn't work with DHCP as DHCP isn't available everywhere and when we need to add it to RA's and every other method there will be umpteen ways to do this while one solution could suffice. > An alternative to globally reachable WKAs would be site-local WKAs. I > think Microsoft even uses those already. But waiting for the whole > world to implement those isn't very attractive and then there is the > whole site-local problem The 'ipconfig /all' indeed shows fec0::53 or something addresses but, as far as I know, no Windows IPv6 implementation can do IPv6 transported DNS queries. Also as site-local is on the way out, this is no option. Next to that this will also make the availability dependant on the locally available services, thus if there still was a 'site local' something then it would have to be configured everywhere, while now only the ISP's or the organisations wanting to have a convienience for their users would need to set this up. > [sorry about using up so much bandwidth, btw] Useful discussions are no waste of bandwidth ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part Url : http://mailman.isi.edu/pipermail/6bone/attachments/20040513/bf4d4a2d/attachment.bin From paul at clubi.ie Fri May 14 16:19:28 2004 From: paul at clubi.ie (Paul Jakma) Date: Fri May 14 16:20:57 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <504F233E-A4CA-11D8-B6DD-000A95CD987A@muada.com> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com><22u0ype7i7.fsf@aptop.autonomica.net><133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com><001b01c43622$3becf730$1b29b3d5@jjobbpc> <009e01c43855$7e44a4e0$1b29b3d5@jjobbpc> <504F233E-A4CA-11D8-B6DD-000A95CD987A@muada.com> Message-ID: On Thu, 13 May 2004, Iljitsch van Beijnum wrote: > Paul wrote: > > > > I disagree that it requires two pTLAs. My feeling is that there > > > should absolutely _NOT_ be any public DNS recursive service offered > > > at the WKA because of the security implications of a widely used > > > public recursive DNS service. > > Are you afraid people are going to run malicious DNS resolvers? > > That's an interesting problem. However, note that any ISP already > gets to do this and much worse. No, a public recursive DNS service would be very susceptible to DNS poison attacks, both the easy attack by handing out deliberately poisoned additional info on unrelated queries (though BIND no longer accepts unrelated additional info, so not a huge problem, AFAIK), and the other problem whereby if this public recursive DNS service were tricked, if only just for an instant, to query an evil DNS server it would presumably cache the result and hand it out to clients for a period thereafter. I'm not a DNS expert, I strongly suggest you seek advice on the risks of public recursive service from someone who is. (esp as you seek to investigate making such service global infrastructure). > So what exactly would be the purpose of having them? What I want is > to be able to open up my laptop, have it autoconfigure an IPv6 > address and just use the IPv6 internet without having to think > about it. This is only going to work if the WKAs are reachable > everywhere. They still can be. Each ISP, or other organisation controlling a network, can route the WKA to an appropriate DNS server. Exact same as with 6to4, the address is global, but site dependent. > An alternative to globally reachable WKAs would be site-local WKAs. Site local's are deprecated arent they? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: In Tennessee, it is illegal to shoot any game other than whales from a moving automobile. From paul at clubi.ie Fri May 14 16:24:09 2004 From: paul at clubi.ie (Paul Jakma) Date: Fri May 14 16:24:50 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <1084448586.2409.2772.camel@segesta.zurich.ibm.com> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com> <22u0ype7i7.fsf@aptop.autonomica.net> <133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com> <001b01c43622$3becf730$1b29b3d5@jjobbpc> <009e01c43855$7e44a4e0$1b29b3d5@jjobbpc> <504F233E-A4CA-11D8-B6DD-000A95CD987A@muada.com> <1084448586.2409.2772.camel@segesta.zurich.ibm.com> Message-ID: Hi Jeroen, On Thu, 13 May 2004, Jeroen Massar wrote: > On Thu, 2004-05-13 at 12:43, Iljitsch van Beijnum wrote: > > On 12-mei-04, at 21:15, J?rgen Hovland wrote: [ you snipped attribution line for me, but quoted me btw ;) ] > > >> The WKA should be confined internally to organisations, as a > > >> convenience, should they wish to make use of it. > > An organisation can announce/route the prefix used by these DNS or other > discovery servers them selves and that issue is solved. Sure, IFF DNS experts dont see a security problem with public recursive service. (my inexpert understanding is there potentially are). If not, I would strongly disagree with any proposal which seeks to introduce fundamentally insecure infrastructure for default usage for the sake of convenience. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: Parts that positively cannot be assembled in improper order will be. From iljitsch at muada.com Sun May 16 15:05:05 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun May 16 15:05:52 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com><22u0ype7i7.fsf@aptop.autonomica.net><133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com><001b01c43622$3becf730$1b29b3d5@jjobbpc> <009e01c43855$7e44a4e0$1b29b3d5@jjobbpc> <504F233E-A4CA-11D8-B6DD-000A95CD987A@muada.com> Message-ID: <16744C04-A785-11D8-AC18-000A95CD987A@muada.com> On 15-mei-04, at 1:19, Paul Jakma wrote: >> Are you afraid people are going to run malicious DNS resolvers? >> That's an interesting problem. However, note that any ISP already >> gets to do this and much worse. > No, a public recursive DNS service would be very susceptible to DNS > poison attacks, both the easy attack by handing out deliberately > poisoned additional info on unrelated queries Why would this be a problem for WKA resolvers more than for any other resolvers, and: > (though BIND no longer > accepts unrelated additional info, so not a huge problem, AFAIK), [...] > I'm not a DNS expert, I strongly suggest you seek advice on the risks > of public recursive service from someone who is. (esp as you seek to > investigate making such service global infrastructure). No need. You are at the mercy of the person running the resolver for anything that doesn't use strong authentication (such as SSL, IPsec and SSH, if used correctly). But then, regardless of the faint outcries of people who chose to be "security experts", this is pretty much a fact of life for most types of communication. If you want to be absolutely secure, you're going to have to expended a lot of time and money into that and be prepared to give up lots of stuff that can't be made secure (either inherently or in practice). [Use WKA resolvers only privately] >> So what exactly would be the purpose of having them? > They still can be. Each ISP, or other organisation controlling a > network, can route the WKA to an appropriate DNS server. Exact same > as with 6to4, the address is global, but site dependent. 6to4 is a perfect example of what I want to do with WKA DNS resolvers: there are some people who run a global service (which you apparently didn't notice) but people also get to install their own private relays if they so choose. (That's for the part from the regular IPv6 internet towards 6to4 addresses, the other way around fully depends on public relays or non-well known ones.) >> An alternative to globally reachable WKAs would be site-local WKAs. > Site local's are deprecated arent they? Don't you watch horror movies? The monster always comes back after being killed the first time. :-) From paul at clubi.ie Sun May 16 15:25:08 2004 From: paul at clubi.ie (Paul Jakma) Date: Sun May 16 15:25:52 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <16744C04-A785-11D8-AC18-000A95CD987A@muada.com> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com><22u0ype7i7.fsf@aptop.autonomica.net><133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com><001b01c43622$3becf730$1b29b3d5@jjobbpc> <009e01c43855$7e44a4e0$1b29b3d5@jjobbpc> <504F233E-A4CA-11D8-B6DD-000A95CD987A@muada.com> <16744C04-A785-11D8-AC18-000A95CD987A@muada.com> Message-ID: On Mon, 17 May 2004, Iljitsch van Beijnum wrote: > Why would this be a problem for WKA resolvers more than for any > other resolvers, and: It is not a problem in the resolvers (if you mean WKA using clients). It is a problem in the DNS infrastructure. > No need. You are at the mercy of the person running the resolver > for anything that doesn't use strong authentication (such as SSL, > IPsec and SSH, if used correctly). There is currently no globally deployable security infrastructure for DNS. Damage at the moment is limited though, because recursive service at the moment is usually only provided to a small subset of "clients" - not the whole internet. Eg, the risk to $ISP is limited to evil clients of $ISP, not to the whole internet. A WKA public recursive DNS server would: - be open to poisoning by $EVIL-CLIENTs on the whole internet - the target audience of non-evil clients which would use this service and hence potentially be given poisoned DNS replies would be potentially the whole internet. NB: Please ask DNS experts about DNS poison attacks. > types of communication. If you want to be absolutely secure, you're > going to have to expended a lot of time and money into that and be > prepared to give up lots of stuff that can't be made secure (either > inherently or in practice). Well, the answer, allegedly, one day, is DNSSec and to have the root zones signed and trust established from that point down. But that will be a while. Until that day comes, I strongly feel that we should not mandate DNS resolvers to potentially fall back to a very exploitable public service. > 6to4 is a perfect example of what I want to do with WKA DNS > resolvers: Yes, I understand. The mechanics of the routing may be similar, however the security implications are quite different. The public recursive DNS servers located at WKA will be caching lookups. If you can poison records cached by this public service, then all other clients querying it will get the poisoned records. I feel that, unless there is reassurance from DNS gurus that poisoning would not be a problem, there should _not_ be a public service offering this. > > Site local's are deprecated arent they? > > Don't you watch horror movies? The monster always comes back after being > killed the first time. :-) :) regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: "Zaphod grinned two manic grins, sauntered over to the bar and bought most of it." - Zaphod in paradise. From iljitsch at muada.com Mon May 17 03:37:32 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon May 17 03:37:52 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com><22u0ype7i7.fsf@aptop.autonomica.net><133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com><001b01c43622$3becf730$1b29b3d5@jjobbpc> <009e01c43855$7e44a4e0$1b29b3d5@jjobbpc> <504F233E-A4CA-11D8-B6DD-000A95CD987A@muada.com> <16744C04-A785-11D8-AC18-000A95CD987A@muada.com> Message-ID: <33E22836-A7EE-11D8-AC18-000A95CD987A@muada.com> On 17-mei-04, at 0:25, Paul Jakma wrote: > Damage at the moment is limited though, because recursive service at > the moment is usually only provided to a small subset of "clients" - > not the whole internet. Eg, the risk to $ISP is limited to evil > clients of $ISP, not to the whole internet. A WKA public recursive > DNS server would: > - be open to poisoning by $EVIL-CLIENTs on the whole internet > - the target audience of non-evil clients which would use this > service and hence potentially be given poisoned DNS replies would be > potentially the whole internet. I'll skip over the point that anycasting limits all of this to a subset of the whole internet. In 1997, Alternic did some of this poisoning. They were quite successful at poisoning caches all over the place rather than just at their own ISP. It's not very hard to get someone to ask for some DNS data for which you are authorative. This is especially easy with email, and sometimes just visiting a web site is enough. Anyone who is still vulnerable to this 7 years after the Alternic shennanigans is probably better of typing in addresses anyway. > Well, the answer, allegedly, one day, is DNSSec and to have the root > zones signed and trust established from that point down. But that > will be a while. Until that day comes, I strongly feel that we should > not mandate DNS resolvers to potentially fall back to a very > exploitable public service. Nobody is forcing anyone to USE this service. Any and all risks are only assumed by those who choose to use the service. As such, there is no reason not to run it just because it may be insecure. We *know* SMTP is insecure and still it's available all over the place. >> 6to4 is a perfect example of what I want to do with WKA DNS >> resolvers: > Yes, I understand. The mechanics of the routing may be similar, > however the security implications are quite different. Yes, they are much worse for 6to4 because a malicious relay gets to see ALL traffic and launch man in the middle attacks. > I feel that, unless there is reassurance from DNS gurus that > poisoning would not be a problem, there should _not_ be a public > service offering this. I don't think my name is on the DNS guru list but I'm pretty sure this isn't an issue. From paul at clubi.ie Mon May 17 04:03:29 2004 From: paul at clubi.ie (Paul Jakma) Date: Mon May 17 04:03:55 2004 Subject: [6bone] Request: two 6bone pTLAs In-Reply-To: <33E22836-A7EE-11D8-AC18-000A95CD987A@muada.com> References: <17606D8B-A1C7-11D8-BE01-000A95CD987A@muada.com><22u0ype7i7.fsf@aptop.autonomica.net><133AB8D0-A1FC-11D8-BE01-000A95CD987A@muada.com><001b01c43622$3becf730$1b29b3d5@jjobbpc> <009e01c43855$7e44a4e0$1b29b3d5@jjobbpc> <504F233E-A4CA-11D8-B6DD-000A95CD987A@muada.com> <16744C04-A785-11D8-AC18-000A95CD987A@muada.com> <33E22836-A7EE-11D8-AC18-000A95CD987A@muada.com> Message-ID: On Mon, 17 May 2004, Iljitsch van Beijnum wrote: > I'll skip over the point that anycasting limits all of this to a > subset of the whole internet. In 1997, Alternic did some of this > poisoning. Yes, indeed - it was 1996 though i think. > They were quite successful at poisoning caches all over the place > rather than just at their own ISP. Right, but the hole alternic used is long closed. So they made use of a trivial hole and poisoned a significant number of nameservers. > It's not very hard to get someone to ask for some DNS data for > which you are authorative. This is especially easy with email, and > sometimes just visiting a web site is enough. Indeed. But if you truly authorative and we've arrived at your DNS server via appropriate delegation, there's no reason not to believe your answer. And BIND discards additional answers for which a server is not authorative. > Nobody is forcing anyone to USE this service. Any and all risks are > only assumed by those who choose to use the service. As such, there > is no reason not to run it just because it may be insecure. We > *know* SMTP is insecure and still it's available all over the > place. "ah, but XYZ is insecure" is not an excuse to introduce another service with security problems. Forcing to use the service: No, nobody would be forced to, but the WKA would not be as useful otherwise. How does a client who wants to use the WKA, but is security sensitive and does not want to use a global service discriminate between a locally routed WKA and the global one. At least, at a minimum, introduce 2 of them, the second address being one which must never be advertised globally. > Yes, they are much worse for 6to4 because a malicious relay gets to > see ALL traffic and launch man in the middle attacks. Well, the DNS WKA would have this problem too. But we're not discussing that problem, we're discussing cache poisoning - which 6to4 doesnt have. > I don't think my name is on the DNS guru list but I'm pretty sure > this isn't an issue. Sorry, I'd rather hear "this isnt an issue" from someone who /is/. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: Zombie processess detected, machine is haunted. From wildfire at progsoc.uts.edu.au Wed May 19 18:36:57 2004 From: wildfire at progsoc.uts.edu.au (Anand Kumria) Date: Wed May 19 18:38:07 2004 Subject: [6bone] e.f.f.3.ip6.[int|arpa] update In-Reply-To: <58980000.1083866728@hades.hexago.com> References: <58980000.1083866728@hades.hexago.com> Message-ID: <20040520013657.GI1665@yeenoghu.progsoc.uts.edu.au> About 14 days ago, May 06, 2004 at 02:05:28PM -0400, Frederick Lefebvre wrote: > All, > > As many persons noticed, we are in the final steps in the deployment of the > e.f.f.3.ip6.arpa zone. In fact, it should be operational in a few days, as So, how goes it? > soon as the servers are properly registered (Bob is taking care of that). Have they been registered? Anand -- `` All actions take place in time by the interweaving of the forces of Nature; but the man lost in selfish delusion thinks that he himself is the actor.'' Lord Krishna to Arjuna in _The Bhagavad Gita_ From ajs at labs.mot.com Fri May 21 13:20:16 2004 From: ajs at labs.mot.com (Aron J. Silverton) Date: Fri May 21 13:21:24 2004 Subject: [6bone] Return of 3ffe:4002::/32 by Motorola Labs Message-ID: <85D7282E4579D811A6DD00D0B781E33D0109B359@il02exm14.corp.mot.com> Hello all, Motorola Labs is returning the pTLA 3ffe:4002::/32 to the pool. On behalf of Motorola Labs, I thank you for allowing us the opportunity to have taken part in the 6Bone community as a pTLA holder. Our entries in the 6Bone registry will be deleted and/or updated by this afternoon. Please contact me directly if I miss something or with any other comments. Thank you, Aron J. Silverton Senior Staff Research Engineer Motorola Labs, Networks and Infrastructure Research Motorola, Inc. Telephone: 847-576-8747 Fax: 847-576-3240 mailto:Aron.J.Silverton@motorola.com From raeburn at MIT.EDU Fri May 21 13:56:39 2004 From: raeburn at MIT.EDU (Ken Raeburn) Date: Fri May 21 13:57:24 2004 Subject: [6bone] VBNS/MCI contact? Message-ID: Hi. Does someone have a current address for a 6bone contact at VBNS? (Maybe it's someone on this list?) The 6bone registry lists a couple addresses that don't work any more: 550 5.1.2 mci.net email domain is no longer valid.: ipv6@mci.net Ken From bob at thefinks.com Fri May 21 14:12:28 2004 From: bob at thefinks.com (Bob Fink) Date: Fri May 21 14:13:18 2004 Subject: [6bone] Return of 3ffe:4002::/32 by Motorola Labs In-Reply-To: <85D7282E4579D811A6DD00D0B781E33D0109B359@il02exm14.corp.mo t.com> References: <85D7282E4579D811A6DD00D0B781E33D0109B359@il02exm14.corp.mot.com> Message-ID: <6.1.0.6.2.20040521141141.01f0c938@mail.addr.com> Aron, At 01:20 PM 5/21/2004, Aron J. Silverton wrote: >Hello all, > >Motorola Labs is returning the pTLA 3ffe:4002::/32 to the pool. On behalf >of Motorola Labs, I thank you for allowing us the opportunity to have taken >part in the 6Bone community as a pTLA holder. > >Our entries in the 6Bone registry will be deleted and/or updated by this >afternoon. Please contact me directly if I miss something or with any other >comments. Thanks for returning this. I will update the pTLA records to show this. Bob From dan at reeder.name Thu May 27 05:52:28 2004 From: dan at reeder.name (Dan) Date: Thu May 27 04:54:30 2004 Subject: [6bone] {Filename?} Re: Thanks :) Message-ID: An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/6bone/attachments/20040527/67ef13d1/attachment.html -------------- next part -------------- This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "You_will_answer_to_me.hta" has an unusual filename and could possibly be infected with a virus. As a precaution, the attachment has been quarantined. Virus scanner report for Thu May 27 04:52:41 2004: MailScanner: HTML archives are very dangerous in email (You_will_answer_to_me.hta) Quarantine location on `hostname`: /var/spool/quarantine/20040527/i4RBqWH23171 If you were expecting the attachment and would like to receive it, please forward this e-mail to action@isi.edu for assistance. If this is urgent, please call Action at x88289 after forwarding the message. Thank you, IPC Computing Services From L at bnmnetworks.net Sun May 30 14:09:15 2004 From: L at bnmnetworks.net (Scott Nelson) Date: Sun May 30 14:10:32 2004 Subject: [6bone] VBNS/MCI contact? In-Reply-To: Message-ID: <9B6AFEDE-B27D-11D8-B04C-00039315F180@bnmnetworks.net> Send me the info. I have the contacts number but don't want to post on NG. I'll forward your e-mail(s) to them. r/s Scotty On Friday, May 21, 2004, at 16:56 US/Eastern, Ken Raeburn wrote: > Hi. Does someone have a current address for a 6bone contact at VBNS? > (Maybe it's someone on this list?) The 6bone registry lists a couple > addresses that don't work any more: > > 550 5.1.2 mci.net email domain is no longer valid.: ipv6@mci.net > > Ken > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From cfaber at fpsn.net Mon May 31 12:46:08 2004 From: cfaber at fpsn.net (Colin Faber) Date: Mon May 31 12:47:33 2004 Subject: [6bone] e.f.f.3.ip6.[int|arpa] update In-Reply-To: <20040520013657.GI1665@yeenoghu.progsoc.uts.edu.au> References: <58980000.1083866728@hades.hexago.com> <20040520013657.GI1665@yeenoghu.progsoc.uts.edu.au> Message-ID: <40BB8B80.1060807@fpsn.net> About 11 days ago, May 19, 2004 at 11:36:57 +1000 Anand Kumria wrote: >About 14 days ago, May 06, 2004 at 02:05:28PM -0400, Frederick Lefebvre wrote: > > > >>All, >> >>As many persons noticed, we are in the final steps in the deployment of the >>e.f.f.3.ip6.arpa zone. In fact, it should be operational in a few days, as >> >> > >So, how goes it? > > > Still waiting.. Has hexago proceeded any further with the roll out of e.f.f.3.ip6.arpa or has this been a dead issue? >>soon as the servers are properly registered (Bob is taking care of that). >> >> > >Have they been registered? > >Anand > > > Bob, have you properly registered the servers yet? -- Colin Faber FPSN.Net Development staff email: cfaber@fpsn.net From bob at thefinks.com Mon May 31 16:16:48 2004 From: bob at thefinks.com (Bob Fink) Date: Mon May 31 16:18:34 2004 Subject: [6bone] e.f.f.3.ip6.[int|arpa] update In-Reply-To: <40BB8B80.1060807@fpsn.net> References: <58980000.1083866728@hades.hexago.com> <20040520013657.GI1665@yeenoghu.progsoc.uts.edu.au> <40BB8B80.1060807@fpsn.net> Message-ID: <6.1.0.6.2.20040531153902.02058ec0@mail.addr.com> Colin, At 12:46 PM 5/31/2004, Colin Faber wrote: >About 11 days ago, May 19, 2004 at 11:36:57 +1000 Anand Kumria wrote: > >>About 14 days ago, May 06, 2004 at 02:05:28PM -0400, Frederick Lefebvre >>wrote: >> >> >> >>>All, >>> >>>As many persons noticed, we are in the final steps in the deployment of >>>the e.f.f.3.ip6.arpa zone. In fact, it should be operational in a few >>>days, as >> >>So, how goes it? >> >> >Still waiting.. Has hexago proceeded any further with the roll out >of e.f.f.3.ip6.arpa or has this been a dead issue? > >>>soon as the servers are properly registered (Bob is taking care of that). >>> >> >>Have they been registered? >> >>Anand >> >> >Bob, have you properly registered the servers yet? Hexago and I are waiting for the registration of the servers, which is in Leslie Daigle's (IAB Chair) hands at the moment. I just asked for another status report. Bob From raeburn at MIT.EDU Mon May 31 16:41:42 2004 From: raeburn at MIT.EDU (Ken Raeburn) Date: Mon May 31 16:42:33 2004 Subject: [6bone] VBNS/MCI contact? In-Reply-To: <9B6AFEDE-B27D-11D8-B04C-00039315F180@bnmnetworks.net> References: <9B6AFEDE-B27D-11D8-B04C-00039315F180@bnmnetworks.net> Message-ID: <1193BA9F-B35C-11D8-AF5F-000A95909EE2@mit.edu> On May 30, 2004, at 17:09, Scott Nelson wrote: > Send me the info. > I have the contacts number but don't want to post on NG. > I'll forward your e-mail(s) to them. Thanks for the offer. The MCI contact has already gotten in touch with me, and has said that the registry data should be corrected soon. Ken