From spz at serpens.de Wed Apr 1 06:58:03 2009 From: spz at serpens.de (S.P.Zeidler) Date: Wed, 1 Apr 2009 06:58:03 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: References: <20090331170015.GF17392@serpens.de> Message-ID: <20090401045802.GJ17392@serpens.de> Hi, Thus wrote Leo Vegoda (leo.vegoda at icann.org): > On 31/03/2009 10:00, "S.P.Zeidler" wrote: > > [...] > > > Traditionally, in the RIPE region (not counting historical PI from before > > PA was invented), the way to get PI space in v4 is to get an AS first > > (or mostly, to get an AS and the PI space to route with it as a bundle). > > I recall networks qualifying for exactly as much IPv4 PI space as they would > qualify for PA space without a multi-homing requirement. So very small > networks might well only get a /29 of PI space. > > This high granularity of PI assignments was a possibly a disincentive to an > excessive number of requests. Or it might have encouraged people to inflate > the interface count to something more than 128, ensuring a /24 assignment. Even back when I was an active LIR hostmaster (1998-2001 roughly) it was more theoretically possible than practical to get PI without the reason 'multihoming' being in evidence. I somehow doubt that changed into the direction of easier availability :) And I distinctly remember a case with a PI request where the 3 year plans would have been covered by a /25, but the argument of routability yielded the customer a /24 (after some extended complaining at the responsible hostmaster @RIPE, granted). > In any case, it looks like the number of PI assignments exceeded the number > of PA allocations back in 2003: > > http://ripe.net/ripe/meetings/ripe-54/presentations/RIPE_NCC_Statistics.pdf > (slide 9) If that really is all the requestor will need, it does save address space. > I note that RIPE policy proposal 2006-05 would set the minimum assignment > size to /24 in some multi-homing cases. On the other hand, things seem to be > changing in a way that assigns a higher ongoing cost to PI assignments, > which might balance out the equation somewhat. It would certainly remove the "pay once, own forever" lure of PI space over a PA allocation that currently is in effect. regards, spz -- spz at serpens.de (S.P.Zeidler) From pekkas at netcore.fi Wed Apr 1 08:25:04 2009 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 1 Apr 2009 09:25:04 +0300 (EEST) Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <20090331173447.GH17392@serpens.de> References: <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <49D1E61E.1050405@airwire.ie> <20090331.134428.238903156.he@uninett.no> <20090331173447.GH17392@serpens.de> Message-ID: On Tue, 31 Mar 2009, S.P.Zeidler wrote: > I kind of like Gerds filter :-) > I like even more tightly tailored filters even better, btw, and think they > ought to be used more. :) I like it too and use it with some modifications. Too bad its Juniper implementation is broken (it's rejecting lots of APNIC prefixes) due to differences in how Cisco vs Juniper implement more-specific matching with route filters. -- 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 mohacsi at niif.hu Wed Apr 1 11:03:52 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 1 Apr 2009 11:03:52 +0200 (CEST) Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <4013b2300903310933g35ee6425sf7a6bb202a291e1f@mail.gmail.com> References: <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090331064744.GE17392@serpens.de> <68DDA1C1-8BA6-4B17-BF44-DD391AC94DB0@cisco.com> <3B90ACB6-DF09-4FC7-8542-FAA3506FE70B@sackheads.org> <4013b2300903310520r7dfb94cco53fba11dc9ca471f@mail.gmail.com> <49D20CFA.2030101@spaghetti.zurich.ibm.com> <4013b2300903310543k72afb5fdge7ef8d3256e6eae4@mail.gmail.com> <4013b2300903310726u7937f4a1wfda69b460e3bed60@mail.gmail.com> <4013b2300903310933g35ee6425sf7a6bb202a291e1f@mail.gmail.com> Message-ID: On Tue, 31 Mar 2009, Pierfrancesco Caci wrote: > On Tue, Mar 31, 2009 at 16:52, Mohacsi Janos wrote: > >> okay it seems to me, that shim6 is a good candidate for your problem with >> some extension allowing specifing amount of outgoing traffic going on >> paralel links. > > And incoming. Eyeball-prevalent networks will need to do more TE on > the incoming traffic. You can't always expect the other side to be > fully cooperative, unfortunately. This is a contractual or administrative issue. If your provider wants you you as a customer, they have to serve you: provide knobs to able to tune your traffic patterns. > > > > -- > Pierfrancesco Caci, ik5pvx > From nick-lists at netability.ie Wed Apr 1 11:22:12 2009 From: nick-lists at netability.ie (Nick Hilliard) Date: Wed, 01 Apr 2009 10:22:12 +0100 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <20090401045802.GJ17392@serpens.de> References: <20090331170015.GF17392@serpens.de> <20090401045802.GJ17392@serpens.de> Message-ID: <49D33244.8010606@netability.ie> On 01/04/2009 05:58, S.P.Zeidler wrote: > It would certainly remove the "pay once, own forever" lure of PI space over > a PA allocation that currently is in effect. That lure is now gone, as of March 1 this year. Nick From jeroen at unfix.org Wed Apr 1 13:47:34 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 01 Apr 2009 13:47:34 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: References: <20070430152601.GA30632@data.fire-world.de> <20070430153017.GU73965@Space.Net>

<5.1.0.14.2.20090326072714.0527d188@efes.iucc.ac.il> <922f6670903260851y777c3763l813cefa324c493cd@mail.gmail.com> <1238086514.1619.21.camel@enterprise.ims-firmen.de> <922f6670903261034q1a93d7bn5cc2e85c9df901e8@mail.gmail.com> <20090326182907.GQ28050@virtual.bogons.net> <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> Message-ID: <60F02E89-BFB3-4111-8D80-7915141C75AF@ed.ac.uk> Pardon me while I delurk. On 27 Mar 2009, at 14:01, Benny Amorsen wrote: > You could have added extra, optional fields to the IP header, > containing > extra source or destination IP addresses. NAT devices would then move > the original IP address into the new src ip address header and put the > NAT-address into the src ip address. If the host at the remote end > understood the extra header, it would copy it into the extra dst ip > address header of the return packet, and the NAT would know where to > send the packet without connection tracking. This mechanism would also > make it possible to directly address hosts behind NAT. If a particular > host doesn't understand the new header fields, it should simply ignore > it, and the NAT then has to handle the packet using connection > tracking. It's called loose source routing and it's been in IPv4 since time began. It's a security nightmare which is why it's not used (and why the PIP proposal for what became IPv6 wasn't developed). It was a great debugging tool in more innocent times. Sam Sam Wilson Network Team, IT Infrastructure Information Services, The University of Edinburgh Edinburgh, Scotland, UK -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From maho at nic.dtag.de Fri Apr 3 12:55:58 2009 From: maho at nic.dtag.de (Martin Horneffer) Date: Fri, 3 Apr 2009 12:55:58 +0200 Subject: Biggest mistake for IPv6: It's not backwards compatible, developers admit In-Reply-To: <49D1E61E.1050405@airwire.ie> References: <49CBCA45.3090309@dougbarton.us> <46A2DD1223D7BF47B61799AFFBA8AD8902B0E873@PRDCG4EXVW01-1.OSS.PRD> <722CE239-6772-46A3-930D-A8CF148A24A4@cisco.com> <2e8c64260903271921hcf5d175pe6d30240a0334504@mail.gmail.com> <08718392-25BA-482B-AB44-3564318DA1BC@cisco.com> <481B6DEB-72A9-4358-A1A3-E945E175A992@cisco.com> <20090331064744.GE17392@serpens.de> <49D1E61E.1050405@airwire.ie> Message-ID: <20090403105558.GD14224@nic.dtag.de> On Tue, Mar 31, 2009 at 10:45:02AM +0100, Martin List-Petersen wrote: > S.P.Zeidler wrote: > > I don't see that following, at least not with a sane PI assignment policy. > > PI space being available does not mean that there would be no more PA at all. > > > Which means spacing, so that if an increase is needed, the prefix is > increased, but not a second one allocated. > > > > What I -do- see following is that an entity can be/have an autonomous system > > without being an ISP (and without needing a /32), many of them being > > autonomous systems already in v4, and not willing to give up their routing > > independence to add v6. > > > I agree entirely here. > > > > Also, most ASs would only announce one prefix instead of the zoo most > > keep today. > > And on this one two. We'll have one prefix per AS (more or less). That > will be less prefixes than are announced today for the current > autonomous systems. > > The only problem is, that we're also allocating 4-byte ASN's now which > gives potential for a bigger routing table than the one we have. > On the other side, that's just progression for you and would have > happened anyhow, IPv6 or not. > > Sl?n, > Martin List-Petersen > -- > Airwire - Ag Nascadh Pobail an Iarthair > http://www.airwire.ie > Phone: 091-865 968 -- Dr. Martin Horneffer -- maho at nic.dtag.de Deutsche Telekom AG, T-Com Zentrale, T142-7 48152 M?nster, Hammer Str. 216-226 Tel.: 0251-7985-208 From u at netbeisser.de Fri Apr 3 22:26:16 2009 From: u at netbeisser.de (Stefan Kuttler) Date: Fri, 3 Apr 2009 22:26:16 +0200 Subject: IPv6 Nat Message-ID: <20090403202616.GA7836@netbeisser.de> Hello IPv6-Ops, what are your thoughts on this? http://tools.ietf.org/html/draft-iab-ipv6-nat-00 I would have thought that one has overcome NAT already. Benfits from IPv4 NAT the ISPs will not want to give up: * masking arbitrary nets * oerhm ... Best Regards Stefan -- Stefan Kuttler ( B.O.F.H. ) | u (at) netbeisser.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090403/e2ef95f7/attachment.bin From dr at cluenet.de Fri Apr 3 23:34:38 2009 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 3 Apr 2009 23:34:38 +0200 Subject: IPv6 Nat In-Reply-To: <20090403202616.GA7836@netbeisser.de> References: <20090403202616.GA7836@netbeisser.de> Message-ID: <20090403213438.GA6441@srv03.cluenet.de> On Fri, Apr 03, 2009 at 10:26:16PM +0200, Stefan Kuttler wrote: > what are your thoughts on this? > > http://tools.ietf.org/html/draft-iab-ipv6-nat-00 I would like to remind the fellow list members to stick to OPERATIONAL content on THIS list here. We have a lot of actual operational folks here which I don't want to see fleeing because of the 297856th re-hash of certain philosophical topics. Discussing operational aspects of NAT is fine, but please keep it at that. Thanks. :-) To give this post at least some on-topic value: $ dig tools.ietf.org AAAA +short 2a01:3f0:0:31:214:22ff:fe21:bb 2001:1890:1112:1:214:22ff:fe1f:1e54 First being an instance within netnod.se, the second one hosted within AT&T AS7018. Connectivity from 2001:1440::/32 AS8469 to the netnod.se instance is fine, but to the AT&T instance is broken. Traces die at the first AT&T router, so I guess AS7018 doesn't have a working route back to 2001:1440::/32 AS8469. If anyone of AT&T hopefully reading this list could check that please... There IS a BGP route to 2001:1440::/32 seen by AS7018 as evidence at GRH (grh.sixxs.net) shows: Network Next Hop Metric LocPrf Weight Path * 2001:1440::/32 2001:1888::2 0 6435 7018 3549 13237 8469 i So might as well being 3549 discarding the traffic. 13237 should be fine as otherwise 8469 would have more widespread IPv6 problems. :) Folks can check connectivity to 2001:1440::/32 by pinging e.g. www.cluenet.de. Happy to take any troubleshooting off-list. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From thedarkone at list.ru Sat Apr 4 10:24:53 2009 From: thedarkone at list.ru (The Dark One) Date: Sat, 04 Apr 2009 12:24:53 +0400 Subject: European Community and IPv6 Message-ID: Experts, I am very interested in any form of support from EC to the deployment of IPv6. Any useful information that you can share? Thanks. From jordi.palet at consulintel.es Sat Apr 4 10:41:54 2009 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 04 Apr 2009 10:41:54 +0200 Subject: European Community and IPv6 In-Reply-To: Message-ID: Hi, We offer training and support, including e-learning thru the 6DEPLOY project, co-funded by the EC. http://www.6deploy.eu/ Regards, Jordi > From: The Dark One > Reply-To: The Dark One > Date: Sat, 04 Apr 2009 12:24:53 +0400 > To: > Subject: European Community and IPv6 > > Experts, > I am very interested in any form of support from EC to the deployment of IPv6. > Any useful information that you can share? > > Thanks. > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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 ericlklein.ipv6 at gmail.com Sat Apr 4 17:06:39 2009 From: ericlklein.ipv6 at gmail.com (Eric Klein) Date: Sat, 4 Apr 2009 17:06:39 +0200 Subject: IPv6 Nat In-Reply-To: <20090403202616.GA7836@netbeisser.de> References: <20090403202616.GA7836@netbeisser.de> Message-ID: <18d24aa20904040806m5edffe2fxd12c65ec35030888@mail.gmail.com> The proper place for this is in the mailing list nat66 at ietf.org where all aspects of NAT in IPv6 were consolidated last year. Eric On Fri, Apr 3, 2009 at 22:26, Stefan Kuttler wrote: > > Hello IPv6-Ops, > > what are your thoughts on this? > > http://tools.ietf.org/html/draft-iab-ipv6-nat-00 > > I would have thought that one has overcome NAT already. > Benfits from IPv4 NAT the ISPs will not want to give up: > > * masking arbitrary nets > * oerhm ... > > > Best Regards > Stefan > > -- > Stefan Kuttler ( B.O.F.H. ) | u (at) netbeisser.de > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090404/b3ea98b1/attachment.html From gabriella.paolini at garr.it Sat Apr 4 17:10:26 2009 From: gabriella.paolini at garr.it (Gabriella Paolini) Date: Sat, 04 Apr 2009 17:10:26 +0200 Subject: European Community and IPv6 In-Reply-To: References: Message-ID: <49D77862.1050909@garr.it> My 2cents: from OGF25/EGEE UF, EC slides about IPv6 Action Plan http://www.ogf.org/OGF25/materials/1503/action-plan-ipv6.pdf and the link to the Action Plan http://ec.europa.eu/information_society/policy/ipv6/docs/european_day/communication_final_27052008_en.pdf ciao, Gabriella -------- Original Message -------- Subject: European Community and IPv6 From: The Dark One To: ipv6-ops at lists.cluenet.de Date: sabato 4 aprile 2009 10.24.53 > Experts, > I am very interested in any form of support from EC to the deployment of IPv6. > Any useful information that you can share? > > Thanks. > > -- Gabriella Paolini _________________ GARR Italian National Research and Education Network Via dei Tizii, 6 - 00185 Rome direct: +39 06 4962 2507 mobile: +39 334 6533 252 gabriella.paolini at garr.it - http://www.garr.it/ From berni at birkenwald.de Tue Apr 7 13:23:42 2009 From: berni at birkenwald.de (Bernhard Schmidt) Date: Tue, 7 Apr 2009 13:23:42 +0200 Subject: IPv6 and Jumbo Frames Message-ID: <20090407132342.0ba63ce4@lxbsc02> Hello everyone, we're just about to get a second 10GE connection to the german NREN and are considering to use Jumbo frames on this link (around 9000 Bytes). Does anyone have any experience how "jumbo-safe" the current IPv6 networks are (read: how many networks break pMTU-discovery but at least do 1500 bytes through the whole path)? Bernhard From wmaton at ryouko.imsb.nrc.ca Tue Apr 7 16:02:13 2009 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Tue, 7 Apr 2009 10:02:13 -0400 (EDT) Subject: IPv6 and Jumbo Frames In-Reply-To: <20090407132342.0ba63ce4@lxbsc02> References: <20090407132342.0ba63ce4@lxbsc02> Message-ID: On Tue, 7 Apr 2009, Bernhard Schmidt wrote: > Does anyone have any experience how "jumbo-safe" the current IPv6 > networks are (read: how many networks break pMTU-discovery but at least > do 1500 bytes through the whole path)? Sounds like a nice little project to map the extent of this. I can only imagine what happens when the jumbo finds its way to tunnels of doom. I uppose one could try the method Joe St. Sauver outlined in his slides way back on jumbo frames with Internet 2 and his survey of various vendors. wfms From dr at cluenet.de Tue Apr 7 16:02:26 2009 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 7 Apr 2009 16:02:26 +0200 Subject: IPv6 Nat In-Reply-To: <20090403213438.GA6441@srv03.cluenet.de> References: <20090403202616.GA7836@netbeisser.de> <20090403213438.GA6441@srv03.cluenet.de> Message-ID: <20090407140226.GA2399@srv03.cluenet.de> On Fri, Apr 03, 2009 at 11:34:38PM +0200, Daniel Roesen wrote: > Connectivity from 2001:1440::/32 AS8469 to the netnod.se instance is > fine, but to the AT&T instance is broken. FYI, this has been resolved by the "guilty" player. :) I'd be happy if they'd chime in and share some operational insight about this problem. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jabley at hopcount.ca Tue Apr 7 16:55:33 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 7 Apr 2009 10:55:33 -0400 Subject: IPv6 and Jumbo Frames In-Reply-To: <20090407132342.0ba63ce4@lxbsc02> References: <20090407132342.0ba63ce4@lxbsc02> Message-ID: <28F8F430-CC7B-45B7-BE94-014D8A7CE500@hopcount.ca> On 7-Apr-2009, at 07:23, Bernhard Schmidt wrote: > we're just about to get a second 10GE connection to the german NREN > and > are considering to use Jumbo frames on this link (around 9000 Bytes). > > Does anyone have any experience how "jumbo-safe" the current IPv6 > networks are (read: how many networks break pMTU-discovery but at > least > do 1500 bytes through the whole path)? I have never had problems with 1280-byte MTU (proto-41-in-IP tunnel) or 1492-byte MTU (PPPoE) links. This suggests to me that PMTUd tends to work in the v6 Internet. That's not very scientific though :-) Joe From spowell at gblx.net Wed Apr 15 17:13:51 2009 From: spowell at gblx.net (Steve Powell) Date: Wed, 15 Apr 2009 15:13:51 +0000 Subject: Juniper IPv6 enhancements in new code Message-ID: <20090415151351.GC16509@gblx.net> Greetings. It was suggested that I pass this along to the list. I will include the PR's for those with Juniper service agreements. If your running IPv6 over a GRE tunnel built on a service PIC, if a packet comes in that is too large for the physical media, a too big message is not sent to the source. PR 397334 is commited to being fixed in various flavors of 9.X and the latest release of 8.5R. Code should be out by mid May. Also for those interested in 9.5, there is an enhancement where the router will use metric2 data for determining best announcement. Code should have been released yesterday. I just have not had a chance to look at it. No PR to look at as this Enjoy. stevep From wmaton at ryouko.imsb.nrc.ca Thu Apr 23 21:48:20 2009 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Thu, 23 Apr 2009 15:48:20 -0400 (EDT) Subject: RFC3068 participants, where are you? Message-ID: Hi all, Jeroen Massar posted a nice method to list known RFC3068 operators by just doing "whois -h whois.ripe.net RFC3068-MNT" on the NANOG mailing list today. That covers off operators in Europe, but has anyone come across one that also lists the ones around the rest of the world? Or am I thinking this is yet another nice research project for someone to go off and discover and list these? Thanks, wfms From pekkas at netcore.fi Thu Apr 23 21:57:19 2009 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 23 Apr 2009 22:57:19 +0300 (EEST) Subject: RFC3068 participants, where are you? In-Reply-To: References: Message-ID: On Thu, 23 Apr 2009, William F. Maton Sotomayor wrote: > Jeroen Massar posted a nice method to list known RFC3068 operators by > just doing "whois -h whois.ripe.net RFC3068-MNT" on the NANOG mailing list > today. That covers off operators in Europe, but has anyone come across one > that also lists the ones around the rest of the world? Or am I thinking this > is yet another nice research project for someone to go off and discover and > list these? To some degree, this has already been done in Malone's "Counting 6to4 relay routers" paper from 2006: http://portal.acm.org/citation.cfm?id=1111322.1111340 -- 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 andree at toonk.nl Thu Apr 23 22:21:10 2009 From: andree at toonk.nl (Andree Toonk) Date: Thu, 23 Apr 2009 13:21:10 -0700 Subject: RFC3068 participants, where are you? In-Reply-To: References: Message-ID: <49F0CDB6.2080405@toonk.nl> Hi, .-- My secret spy satellite informs me that at 4/23/09 12:48 PM William F. Maton Sotomayor wrote: > Jeroen Massar posted a nice method to list known RFC3068 operators > by just doing "whois -h whois.ripe.net RFC3068-MNT" on the NANOG mailing > list today. That covers off operators in Europe, but has anyone come > across one that also lists the ones around the rest of the world? Or am > I thinking this is yet another nice research project for someone to go > off and discover and list these? One way of listing listing all 6to4 & teredo operators is by looking at the BGP announcements for those prefixes. BGPmon.net keeps a list of active (and historical) 6to4 and Teredo operators: http://www.bgpmon.net/6to4.php http://www.bgpmon.net/teredo.php http://bgpmon.net/blog/?p=108 Cheers, Andree From martin at airwire.ie Thu Apr 23 22:24:49 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Thu, 23 Apr 2009 21:24:49 +0100 Subject: RFC3068 participants, where are you? In-Reply-To: <49F0CDB6.2080405@toonk.nl> References: <49F0CDB6.2080405@toonk.nl> Message-ID: <49F0CE91.2020609@airwire.ie> Andree Toonk wrote: > Hi, > > .-- My secret spy satellite informs me that at 4/23/09 12:48 PM William > F. Maton Sotomayor wrote: > >> Jeroen Massar posted a nice method to list known RFC3068 operators >> by just doing "whois -h whois.ripe.net RFC3068-MNT" on the NANOG >> mailing list today. That covers off operators in Europe, but has >> anyone come across one that also lists the ones around the rest of the >> world? Or am I thinking this is yet another nice research project for >> someone to go off and discover and list these? > > One way of listing listing all 6to4 & teredo operators is by looking at > the BGP announcements for those prefixes. > > BGPmon.net keeps a list of active (and historical) 6to4 and Teredo > operators: > > http://www.bgpmon.net/6to4.php > http://www.bgpmon.net/teredo.php > http://bgpmon.net/blog/?p=108 You could also use the SixXS GRH project looking glass at http://www.sixxs.net/tools/grh/lg/ looking for 2002::/16 and 2001::/32 Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From steve at ibctech.ca Fri Apr 24 02:13:10 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 23 Apr 2009 20:13:10 -0400 Subject: RFC3068 participants, where are you? In-Reply-To: References: Message-ID: <49F10416.6060708@ibctech.ca> William F. Maton Sotomayor wrote: > > Hi all, > > Jeroen Massar posted a nice method to list known RFC3068 operators > by just doing "whois -h whois.ripe.net RFC3068-MNT" on the NANOG mailing > list today. That covers off operators in Europe, but has anyone come > across one that also lists the ones around the rest of the world? Or am > I thinking this is yet another nice research project for someone to go > off and discover and list these? I would personally prefer a research project that involved developing a list of tier1 (or equivalent) providers in each core area who provide v6 natively. I'm still kissing the feet of a few very kind net ops who allow me to advertise my space over v4 tunnels. If I could buy transit for v6, I'd be pushing v6 from my enabled PE to awaiting CE in a heartbeat. Steve ps. I'm one hop from TorIX, and have my foot in the door for colo. If you are reading this and are near/in the TorIX, please contact me. From sabt at sabt.net Fri Apr 24 15:48:31 2009 From: sabt at sabt.net (Sebastian Abt) Date: Fri, 24 Apr 2009 15:48:31 +0200 Subject: Cisco, IPv6, Multilink PPP Message-ID: <20090424134831.GP1116@sephina.sabt.net> Hi there, has anyone on this list been running IPv6 on multilink PPP bundles with Cisco? We're currently observing problems with IPv6CP negotiation in this specific configuration. Haven't investigated thourogly myself yet due to time constraints, hence I'm wondering if anybody has been running this setup and might have some pointers (working code release, "special" tricks and the like...). best regards, sebastian -- SABT-RIPE PGPKEY-D008DA9C From Ken.Mix at clearfly.net Fri Apr 24 16:05:37 2009 From: Ken.Mix at clearfly.net (Ken Mix) Date: Fri, 24 Apr 2009 08:05:37 -0600 Subject: Cisco, IPv6, Multilink PPP In-Reply-To: <20090424134831.GP1116@sephina.sabt.net> References: <20090424134831.GP1116@sephina.sabt.net> Message-ID: <10FB8CDC4B3B784AACD5C45FCB395A215DBF6BC0@xenon.corp.clearfly.net> Hello, I haven't had any issues up to 12.4(20)T. Sample MLPPP ATM (bonded DSL config): interface Multilink1 description To Clearfly (MLPPP) ip address 208.88.XXX.YYY 255.255.255.252 ip nat outside no ip virtual-reassembly ipv6 address 2607:F3D0:X:YYY::X/124 ppp multilink ppp multilink links minimum 1 ppp multilink interleave ppp multilink group 1 service-policy output voip ! interface ATM0/0/0 description To Clearfly (406458XXXX) no ip address no atm ilmi-keepalive dsl operating-mode auto pvc 0/32 encapsulation aal5snap protocol ppp Virtual-Template1 ! ! interface ATM0/1/0 description To Clearfly (406458XXXX) no ip address no atm ilmi-keepalive dsl operating-mode auto pvc 0/32 encapsulation aal5snap protocol ppp Virtual-Template1 ! interface Virtual-Template1 no ip address ppp multilink ppp multilink group 1 Relevant "show int mu1": Encapsulation PPP, LCP Open, multilink Open Listen: CDPCP Open: IPCP, IPV6CP, loopback not set I have a virtually identical configurations for bonded T1s (minus the virtual-template). Regards, Ken -----Original Message----- From: ipv6-ops-bounces+ken.mix=clearfly.net at lists.cluenet.de [mailto:ipv6-ops-bounces+ken.mix=clearfly.net at lists.cluenet.de] On Behalf Of Sebastian Abt Sent: Friday, April 24, 2009 7:49 AM To: ipv6-ops at lists.cluenet.de Subject: Cisco, IPv6, Multilink PPP Hi there, has anyone on this list been running IPv6 on multilink PPP bundles with Cisco? We're currently observing problems with IPv6CP negotiation in this specific configuration. Haven't investigated thourogly myself yet due to time constraints, hence I'm wondering if anybody has been running this setup and might have some pointers (working code release, "special" tricks and the like...). best regards, sebastian -- SABT-RIPE PGPKEY-D008DA9C From chaz at chaz6.com Sat Apr 25 18:26:30 2009 From: chaz at chaz6.com (Chris Hills) Date: Sat, 25 Apr 2009 18:26:30 +0200 Subject: IPv6 net diagnostic tools - pointers please In-Reply-To: <20090203193139.GA25822@redoubt.spodhuis.org> References: <20090203193139.GA25822@redoubt.spodhuis.org> Message-ID: On 03/02/09 20:31, Phil Pennock wrote: > Anyone have any pointers for network diagnostic tools which are useful > for IPv6, please? An IPv6 traceroute tool that supports dns loc for a geographical representation is available at http://www.freestone.net/traceroute/traceroute.php So far my experience is that few providers currently publish these records for their routers. From ccaputo at alt.net Wed Apr 29 05:08:00 2009 From: ccaputo at alt.net (Chris Caputo) Date: Wed, 29 Apr 2009 03:08:00 +0000 (UTC) Subject: linux source address selection solution Message-ID: Here's a little linux tip. Hopefully it is of use to others. Apologies if obvious. Recent linux kernels follow RFC 3484 "Default Address Selection for Internet Protocol version 6 (IPv6)". In the case of a tie (ie., source address not decided by destination subnet or other mechanisms), if you have multiple IPv6 addresses on an interface, linux tends to use the last address added. I prefer to have my source v6 address not be dependent on addition order, but rather be more deterministic. A way to do so is to set "preferred_lft" to zero, while "valid_lft" is non-zero or "forever". Doing so results in the source address being marked as deprecated, which means it won't be used if there are alternatives on the interface, or a loopback address if not. Loopback address is great for routers connected to exchange points because it means you can deprecate your v6 exchange point address on the physical interface and use a loopback as the source for any v6 connections. (no more broken registry queries due to unrouted exchange point address space!) To experiment with this try on addresses you don't want to be selected as a source: ip addr change dev preferred_lft 0 "ip -6 addr" should now show the address as being deprecated and non-deprecated address(es) will be favored. To revert do "preferred_lft forever" instead. On Gentoo I found that the network startup scripts did not like the "_lft" in "preferred_lft". Fortunately "ip addr add" allows you to drop that and just use "preferred 0", ala: config_eth0=( "10.1.1.1/24" "2001:0db8::1/64" "10.1.1.2/24" "2001:0db8::2/64 preferred 0" ) Cheers, Chris From ccaputo at alt.net Wed Apr 29 05:21:58 2009 From: ccaputo at alt.net (Chris Caputo) Date: Wed, 29 Apr 2009 03:21:58 +0000 (UTC) Subject: linux source address selection solution In-Reply-To: References: Message-ID: One last thing - addresses marked as deprecated are still perfectly usable for receiving packets or for manually being specified as a source. (ie. ping6 -I ) They just aren't included in the source address selection algorithm. Chris On Wed, 29 Apr 2009, Chris Caputo wrote: > Here's a little linux tip. Hopefully it is of use to others. Apologies > if obvious. > > Recent linux kernels follow RFC 3484 "Default Address Selection for > Internet Protocol version 6 (IPv6)". > > In the case of a tie (ie., source address not decided by destination > subnet or other mechanisms), if you have multiple IPv6 addresses on an > interface, linux tends to use the last address added. > > I prefer to have my source v6 address not be dependent on addition order, > but rather be more deterministic. > > A way to do so is to set "preferred_lft" to zero, while "valid_lft" is > non-zero or "forever". Doing so results in the source address being > marked as deprecated, which means it won't be used if there are > alternatives on the interface, or a loopback address if not. > > Loopback address is great for routers connected to exchange points because > it means you can deprecate your v6 exchange point address on the physical > interface and use a loopback as the source for any v6 connections. (no > more broken registry queries due to unrouted exchange point address > space!) > > To experiment with this try on addresses you don't want to be selected as > a source: > > ip addr change dev preferred_lft 0 > > "ip -6 addr" should now show the address as being deprecated and > non-deprecated address(es) will be favored. To revert do "preferred_lft > forever" instead. > > On Gentoo I found that the network startup scripts did not like the "_lft" > in "preferred_lft". Fortunately "ip addr add" allows you to drop that and > just use "preferred 0", ala: > > config_eth0=( > "10.1.1.1/24" "2001:0db8::1/64" > "10.1.1.2/24" "2001:0db8::2/64 preferred 0" > ) > > Cheers, > Chris From tom at f-i-ts.net Thu Apr 30 13:47:52 2009 From: tom at f-i-ts.net (Tom) Date: Thu, 30 Apr 2009 13:47:52 +0200 Subject: 6to4 nat question Message-ID: <20090430114752.GA72196@f-i-ts.net> Hello, I've got an ipv6 nat problem, perhaps someone here on the list might have an idea what's wrong with my configuration: We operate our own AS including ipv6. Now I wanted to provide a "carrier grade" ipv4 => ipv6 nat gateway for our whole ipv4 network (a /19). This is the relevant configuration on the 7200 router: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! interface Loopback0 ipv6 address 2A02:C00:FFFA::16/128 ! interface Loopback1 ip address 212.34.78.1 255.255.255.0 ipv6 nat ! interface Tunnel2 no ip address ipv6 address 2A02:C00:FFFF::5/126 ipv6 enable ipv6 nat tunnel source 212.114.207.18 tunnel destination 78.46.*.* tunnel mode ipv6ip ! ipv6 nat v6v4 source list v6v4global pool v6pool ipv6 nat v6v4 pool v6pool 212.34.78.9 212.34.78.14 prefix-length 29 ipv6 nat prefix 2A02:C00:0:FFFF:FFFF::/96 v4-mapped v6v4global ! ipv6 access-list v6v4global sequence 20 permit ipv6 any 2A02:C00:0:FFFF:FFFF::/96 permit ipv6 2A02:C00:0:FFFF:FFFF::/96 any ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >From a linux server outside our AS using a tunnel (Tunnel2 on the backbone router), which has the ipv6 address 2A02:C00:FFFF::6 I can reach our ipv6 net, eg: % ping6 2A02:C00:FFFA::16 PING 2A02:C00:FFFA::16(2a02:c00:fffa::16) 56 data bytes 64 bytes from 2a02:c00:fffa::16: icmp_seq=1 ttl=64 time=2.34 ms 64 bytes from 2a02:c00:fffa::16: icmp_seq=2 ttl=64 time=1.84 ms --- 2A02:C00:FFFA::16 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 1.844/2.094/2.345/0.254 ms But if I want to reach an ipv6-mapped destination within our net I get no response from the nat router: % ping6 2a02:c00:0:ffff:ffff:0:d422:41ba PING 2a02:c00:0:ffff:ffff:0:d422:41ba(2a02:c00:0:ffff:ffff:0:d422:41ba) 56 data bytes --- 2a02:c00:0:ffff:ffff:0:d422:41ba ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3002ms The address 2a02:c00:0:ffff:ffff:0:d422:41ba is the mapped ipv4 address 212.34.65.186. On that router I receive the natted icmp packet and it sends a response, which also can be seen on the nat router: Apr 30 11:25:48: ICMP: echo reply rcvd, src 212.34.65.186, dst 212.34.78.9 I also see, that the nat router natted correctly the packet: Apr 30 11:11:42: IPv6 NAT: ipv6nat_find_entry_v4tov6: ref_count = 1, usecount = 0, flags = 260, rt_flags = 0, more_flags = 0 Apr 30 11:11:42: IPv6 NAT: icmp src (2A02:C00:FFFF::6) -> (212.34.78.9), dst (2A02:C00:0:FFFF:FFFF:0:D422:41BA) -> (212.34.65.186) Apr 30 11:11:42: IPv6 NAT:v4tov6 entry not found And 'sh ipv6 nat translations' shows the nat session: icmp 212.34.78.9,64005 2A02:C00:FFFF::6,64005 212.34.65.186,64005 2A02:C00:0:FFFF:FFFF:0:D422:41BA,64005 But it didn't nat the answer packet back to ipv6. Has anyone an idea what's wrong? regards, Tom From steve at ibctech.ca Thu Apr 30 15:01:25 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 30 Apr 2009 09:01:25 -0400 Subject: 6to4 nat question In-Reply-To: <20090430114752.GA72196@f-i-ts.net> References: <20090430114752.GA72196@f-i-ts.net> Message-ID: <49F9A125.6080605@ibctech.ca> Tom wrote: > Hello, > > I've got an ipv6 nat problem, perhaps someone here on the list > might have an idea what's wrong with my configuration: > > We operate our own AS including ipv6. Now I wanted to provide > a "carrier grade" ipv4 => ipv6 nat gateway for our whole ipv4 network > (a /19). > > This is the relevant configuration on the 7200 router: > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > ! > interface Loopback0 > ipv6 address 2A02:C00:FFFA::16/128 > ! > interface Loopback1 > ip address 212.34.78.1 255.255.255.0 > ipv6 nat > ! > interface Tunnel2 > no ip address > ipv6 address 2A02:C00:FFFF::5/126 > ipv6 enable > ipv6 nat > tunnel source 212.114.207.18 > tunnel destination 78.46.*.* > tunnel mode ipv6ip > ! > ipv6 nat v6v4 source list v6v4global pool v6pool > ipv6 nat v6v4 pool v6pool 212.34.78.9 212.34.78.14 prefix-length 29 > ipv6 nat prefix 2A02:C00:0:FFFF:FFFF::/96 v4-mapped v6v4global > ! > ipv6 access-list v6v4global > sequence 20 permit ipv6 any 2A02:C00:0:FFFF:FFFF::/96 > permit ipv6 2A02:C00:0:FFFF:FFFF::/96 any > ! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > >>From a linux server outside our AS using a tunnel (Tunnel2 on the > backbone router), which has the ipv6 address 2A02:C00:FFFF::6 > I can reach our ipv6 net, eg: > > % ping6 2A02:C00:FFFA::16 > PING 2A02:C00:FFFA::16(2a02:c00:fffa::16) 56 data bytes > 64 bytes from 2a02:c00:fffa::16: icmp_seq=1 ttl=64 time=2.34 ms > 64 bytes from 2a02:c00:fffa::16: icmp_seq=2 ttl=64 time=1.84 ms > > --- 2A02:C00:FFFA::16 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1002ms > rtt min/avg/max/mdev = 1.844/2.094/2.345/0.254 ms > > But if I want to reach an ipv6-mapped destination within our net > I get no response from the nat router: > > % ping6 2a02:c00:0:ffff:ffff:0:d422:41ba > PING 2a02:c00:0:ffff:ffff:0:d422:41ba(2a02:c00:0:ffff:ffff:0:d422:41ba) 56 data bytes > > --- 2a02:c00:0:ffff:ffff:0:d422:41ba ping statistics --- > 4 packets transmitted, 0 received, 100% packet loss, time 3002ms > > The address 2a02:c00:0:ffff:ffff:0:d422:41ba is the mapped ipv4 > address 212.34.65.186. On that router I receive the natted icmp packet > and it sends a response, which also can be seen on the nat router: > > Apr 30 11:25:48: ICMP: echo reply rcvd, src 212.34.65.186, dst 212.34.78.9 > > I also see, that the nat router natted correctly the packet: > > Apr 30 11:11:42: IPv6 NAT: ipv6nat_find_entry_v4tov6: > ref_count = 1, > usecount = 0, flags = 260, rt_flags = 0, > more_flags = 0 > Apr 30 11:11:42: IPv6 NAT: icmp src (2A02:C00:FFFF::6) -> (212.34.78.9), > dst (2A02:C00:0:FFFF:FFFF:0:D422:41BA) -> (212.34.65.186) > Apr 30 11:11:42: IPv6 NAT:v4tov6 entry not found > > And 'sh ipv6 nat translations' shows the nat session: > > icmp 212.34.78.9,64005 2A02:C00:FFFF::6,64005 > 212.34.65.186,64005 2A02:C00:0:FFFF:FFFF:0:D422:41BA,64005 > > > But it didn't nat the answer packet back to ipv6. Run a: # tcpdump -n -i ethX ip6 ...on the Linux box that you are expecting to see the return packet on. Perhaps it does receive the response, but drops it before passing it up to the ping application for some reason. Steve From berni at birkenwald.de Thu Apr 30 15:13:06 2009 From: berni at birkenwald.de (Bernhard Schmidt) Date: Thu, 30 Apr 2009 15:13:06 +0200 Subject: 6to4 nat question In-Reply-To: <20090430114752.GA72196@f-i-ts.net> References: <20090430114752.GA72196@f-i-ts.net> Message-ID: <49F9A3E2.6000905@birkenwald.de> Hi Tom, > We operate our own AS including ipv6. Now I wanted to provide > a "carrier grade" ipv4 => ipv6 nat gateway for our whole ipv4 network > (a /19). [...] > But it didn't nat the answer packet back to ipv6. What software version are you using? I had success with a very similar configuration on 12.4(15)T6 (2821), but it did not work after an upgrade to 12.4(20)T. Also even with 12.4(15)T, I occasionally had to reload the system after changing NAT-PT settings before it started working. Other lessons learned with that software version are IPv4 and IPv6 must not be on the same interface and overloading the IPv4 NAT pool didn't work. Also, in the line > ipv6 nat prefix 2A02:C00:0:FFFF:FFFF::/96 v4-mapped v6v4global I'm referencing a non-existing IPv6 access-list after v4-mapped, I'm not exactly sure why but since it is called "NOTCONFIGURED" in my config I assume I had a reason for it :-) Bernhard From tom at f-i-ts.net Thu Apr 30 16:42:21 2009 From: tom at f-i-ts.net (Tom) Date: Thu, 30 Apr 2009 16:42:21 +0200 Subject: 6to4 nat question In-Reply-To: <49F9A125.6080605@ibctech.ca> References: <20090430114752.GA72196@f-i-ts.net> <49F9A125.6080605@ibctech.ca> Message-ID: <20090430144221.GB72196@f-i-ts.net> On Thu, Apr 30, 2009 at 09:01:25AM -0400, Steve Bertrand wrote: > Run a: > > # tcpdump -n -i ethX ip6 > > ...on the Linux box that you are expecting to see the return packet on. > Perhaps it does receive the response, but drops it before passing it up > to the ping application for some reason. Yes I did that, there are no responses coming in: 16:32:09.167005 IP6 2a02:c00:ffff::6 > 2a02:c00:0:ffff:ffff:0:d422:41ba: ICMP6, echo request, seq 1, length 64 16:32:10.170351 IP6 2a02:c00:ffff::6 > 2a02:c00:0:ffff:ffff:0:d422:41ba: ICMP6, echo request, seq 2, length 64 16:32:11.170328 IP6 2a02:c00:ffff::6 > 2a02:c00:0:ffff:ffff:0:d422:41ba: ICMP6, echo request, seq 3, length 64 > What software version are you using? 12.4(15)T1 > Also even with 12.4(15)T, I occasionally had to reload the > system after changing NAT-PT settings before it started working. um, I might try that (maybe tonite) > I'm referencing a non-existing IPv6 access-list after v4-mapped, I'm not > exactly sure why but since it is called "NOTCONFIGURED" in my config I > assume I had a reason for it :-) I also read this somewhere on the web and already tried it with no success. By the way, the debug output in my last post was incomplete, here it is again, now complete: Apr 30 14:30:07: IPv6 NAT: icmp src (2A02:C00:FFFF::6) -> (212.34.78.9), dst (2A02:C00:0:FFFF:FFFF:0:D422:41BA) -> (212.34.65.186) Apr 30 14:30:08: IPv6 NAT: ipv6nat_find_entry_v4tov6: ref_count = 1, usecount = 0, flags = 2, rt_flags = 0, more_flags = 0 Apr 30 14:30:07: IPv6 NAT:v4tov6 entry not found Apr 30 14:30:08: IPv6 NAT: Dropping v6tov4 packet So, the router drops it, for whatever reason. regards, Tom