- ipv6-wg - mailman.ripe.net

Procedural approach for approval of new charter
by David Kessens 18 Oct '09

18 Oct '09

Hi, First of all, a big thank you to Shane for writing the new proposed charter. I propose that we spend until Oct 23 to give feedback to Shane. At that point, we will ask whether Shane can do a revision and I will issue a Last Call when the revision is ready so that we can get a new charter in place as soon as possible. And finally, it is nice to have a new shiny charter, but it is even more important that we as a community actually do something with it. For example, there is nothing that should stop individual participants to do proposals or volunteer for any activities that would bring our new charter (closer) to completion. For example, it would be good to hear how and whether we can do something regarding the issue that Geert Jan brought up about a week ago. David Kessens --- ----- Forwarded message from Shane Kerr <shane(a)time-travellers.org> ----- Date: Fri, 16 Oct 2009 22:36:10 +0200 From: Shane Kerr <shane(a)time-travellers.org> To: ipv6-wg(a)ripe.net Subject: [ipv6-wg] Proposal for new charter All, At the RIPE meeting in Lisbon, I agreed to draft a proposed new charter for the IPv6 working group. Here it is: ---------------------------------------------------------------------- IPv6 is the next-generation IP protocol. The IPv6 working group exists to further IPv6 adoption. The working group activities may be anything useful in helping people deploy IPv6. These activities include: * Outreach * Co-operation * Education The IPv4 Internet will continue for a long time. The IPv6 working group is also concerned with IPv4/IPv6 co-existence. ----------------------------------------------------------------------- Please use this mailing list for discussion. We would like to have a new charter in place before the next RIPE meeting. How this proposed charter was made: I looked at all of the other RIPE charters, and decided I wanted to keep this short and simple. I had a lunch meeting with David Kessens, Denesh Bhabuta, Carlos Friacas, Marco Hogewoning, Bernard Tuy, Lance Wright, and Jan Zorz. We discussed the new charter, although the above text has not been reviewed by them or anyone else. I thank them all! For those interested, here are some thoughts that went into the proposed charter: Background ---------- The current IPv6 working group charter is out-of-date: The IPv6 working group follows the progress of specification and implementation of the new IP version. It coordinates implementations in Europe and is going to create testbeds. It comes from a time when IPv6 was immature; the focus was keeping track of technological advances and working on experimental networks. That time is over, and the IPv6 working group needs an updated charter. Goal ---- The goal of creating a new charter is to do more than simply to update the text. We have almost finished allocating all IPv4 addresses. IPv6 is still only used by a small fraction of network traffic, many devices do not support IPv6 at all, and most organizations have no plans for IPv6 adoption. RIPE is a unique community, and should do what it can to help make the migration to IPv6 as easy as possible. A new charter is just the first step. Commentary ---------- The proposed new charter lists some activities: * Outreach * Co-operation * Education Outreach involves getting people, organisations, and groups to begin or continue IPv6 adoption. This includes vendors, governments, and developers. It also includes groups which are traditionally unrepresented, like gamers or content creators. Outreach means both going to other venues and inviting people from outside the RIPE community to visiting RIPE activities. Co-operation is working within the networking industry and without, to share resources and combine efforts. There are a large number of organisations and projects, and we should work with them whenever possible, so that IPv6 can fit in with their goals. This also includes co-operation with the many IPv6 efforts that exist worldwide. Education means all methods of increasing IPv6 knowledge. Note that the RIPE NCC is not able to do very much in terms of education, since it cannot compete with its members. However, the RIPE IPv6 working group can and should educate. -- Shane ----- End forwarded message ----- David Kessens ---

1 0

Proposal to Remove Routing Requirements from the IPv6 Address Allocation Policy Implemented
by Nathalie Trenaman 08 Oct '09

08 Oct '09

Dear Colleagues, We are pleased to announce that policy proposal 2000-06,"Removing Routing Requirements from the IPv6 Address Allocation Policy", has been implemented. The RIPE NCC is now ready to accept requests for IPv6 address space under the new policy. This proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2009-06.html The updated "IPv6 Address Allocation and Assignment Policy" document is available at: http://www.ripe.net/ripe/docs/ripe-481.html The following FAQ has also been updated to reflect this policy implementation: http://www.ripe.net/info/faq/rs/ipv6.html Regards, Nathalie Trenaman Registration Services RIPE NCC

1 0

Re: [ipv6-wg] On deploying IPv6 for consumers..
by Andy Linton 07 Oct '09

07 Oct '09

I noted Geert Jan de Groot's message on the list about PMTU problems. The following was posted on the NZ v6 list and might be of interest. andy Begin forwarded message: > From: Ben Stasiewicz <ben(a)wand.net.nz> > Date: 6 October 2009 5:24:43 PM > To: ipv6-techsig(a)listserver.internetnz.net.nz > Subject: [Ipv6-techsig] IPv6 PMTUD issues, some data > Reply-To: ben(a)wand.net.nz, ipv6-techsig(a)listserver.internetnz.net.nz > > Hi there, > > I'm a fourth-year Waikato University student who works for WAND in his > spare time. > > Earlier this year Geoff Huston wrote a very interesting article [1] in > which he describes and diagnoses a problem he had downloading an RFC > using IPv6. He determined that it was due to PMTUD failure (probably > caused by ICMPv6 filtering close to the web server) and suggests > lowering the MTU on interfaces used for IPv6 traffic to avoid this > problem. This and the resulting ipv6-techsig discussion [2] > motivated me > to do a university project (supervised by Dr. Matthew Luckie) that > investigates problems with PMTUD in IPv6. It aims to determine the > prevalence of PMTUD failure in IPv6 by running tests to a large number > of IPv6-enabled web servers on the Internet. > > As part of my investigation, I have written a module for scamper [3] > (an > Internet measurement tool created by Matthew) that can be used to > determine whether PMTUD for a given web server is successful. It is > based on the the IPv4 PMTUD test used by tbit [4]. I won't bore you > with > the exact details of the algorithm, but the general idea is: > > Establish a connection to the web server and make an HTTP request > for a > specific object. Do not acknowledge the response. Instead, send an > ICMPv6 Packet Too Big (PTB) message asking it to reduce the size of > its > packets to 1280 bytes. If the web server retransmits the HTTP response > using a smaller packet size, conclude that PMTUD was successful. > Otherwise if the retransmitted response packet is not smaller than the > original, retransmit the PTB message. If after two retransmissions > (three PTB messages) the server still hasn't reduced the size of its > HTTP response packet, conclude that PMTUD failed. > > The test halts if the original response packet is not larger than 1280 > bytes (the MTU specified in the PTB message). I can't specify a MTU > smaller than this because most hosts will ignore an MTU smaller than > 1280 bytes (the IPv6 Minimum Path MTU [5]). > > A test to a particular host will result in one of: > > RESULT_PMTUD_SUCCESS > The server successfully completed PMTUD. A smaller HTTP response > packet > was received from the server after sending it a PTB message. > > RESULT_PMTUD_FAIL > The server failed to complete PMTUD as we did not receive a smaller > response from it. The PTB messages are probably being filtered. > > RESULT_RX_TOOSMALL > The response packet was too small to be able to continue the test. It > must be at least 1281 bytes in size. > > RESULT_RX_NOACK > Did not receive an acknowledgement for the HTTP request. > > RESULT_RX_NODATA > The HTTP request was acknowledged, but no HTTP response was received. > > RESULT_TCP_RST > A TCP reset segment was received before the test could complete. > > RESULT_TCP_ERROR > Unexpected packet received in response to the HTTP request. > > RESULT_TCP_NOCONN > Failed to establish a TCP connection to the web server. > > Test Setup: > > I run the tests from a FreeBSD 7.2 box that sits in the lounge of my > flat. It has IPv6 connectivity using 6to4 and the tunnel interface on > our gateway box has an MTU of 1480 bytes. > > Test Parameters: > > An MSS of 1221 is advertised to avoid the effect of tunnels earlier in > the reverse path as much as possible. For reasons mentioned above, a > 1280 byte MTU is specified in the PTB message. > > Test Input: > > The list of IPv6 web servers was derived from the Alexa Top 1 Million > Websites list [6]. Of these 1 million domains, only 627 had globally > routable IPv6 addresses that could be connected to on port 80 (sad > eh?). > A script searched each of these for a URL to an object that was at > least > 1221 bytes in size. A request for such an object will hopefully result > in a large enough HTTP response packet. > > Test Results: > > Frequency of each result > > 371 PMTUD_SUCCESS > 214 RX_TOOSMALL > 22 RX_NODATA > 13 TCP_NOCONN > 9 PMTUD_FAIL > 5 TCP_RST > 2 RX_NOACK > 1 TCP_ERROR > > > In addition to the outright failures (PMTUD_FAILs), we believe that > the > results RX_NODATA and RX_NOACK also indicate PMTUD failure. They could > result when the server's HTTP response packets are discarded somewhere > along the path for being too big and the server never learns that this > is occurring (and neither do we). The server's response packets are > disappearing into a PMTU black hole. > > A large number of hosts send HTTP response packets that are too small > (RX_TOOSMALL). Some of these could actually indicate PMTUD success in > the presence of 1280 byte tunnels. I will look into this further. > > > Frequency of advertised MSS values > > 458 mss=1440 > 60 mss=1220 > 47 mss=1221 (the remote TCP echoing our advertised MSS) > 33 mss=1420 > 13 mss=1380 > 10 mss=0 (did not receive a SYN from the web server) > 2 mss=8940 > 2 mss=1410 > 2 mss=1300 > 1 mss=65455 > 1 mss=33160 > 1 mss=1460 > 1 mss=1436 > 1 mss=1432 > 1 mss=1416 > 1 mss=1412 > 1 mss=1374 > 1 mss=1370 > 1 mss=1340 > > > The vast majority of hosts advertised a 1440 byte MSS. We suspect that > the 1220 byte MSSs are from hosts that have been explicitly configured > with 1280 byte MTUs and had their PMTUD disabled so as to avoid the > ICMP > filtering problem. > > My current university project is almost complete, but in the Summer I > would like to continue my investigation into IPv6 PMTUD. Can any of > you > recommend another application layer protocol (preferably a simple one > like HTTP) that my PMTUD test could support in the future? Bittorrent > could be a good one (what do you think Nathan?). Is there anything > else > that you would be interested in me finding out? > > Questions and comments are most welcome. > > Cheers > Ben Stasiewicz > > [1] http://cidr-report.org/ispcol/2009-01/mtu6.html > > [2] > http://listserver.internetnz.net.nz/pipermail/ipv6-techsig/2009-February/00… > > [3] http://www.wand.net.nz/scamper/ > > [4] http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps > > [5] http://www.ietf.org/rfc/rfc2460.txt > > [6] http://s3.amazonaws.com/alexa-static/top-1m.csv.zip > _______________________________________________ > IPv6-techsig mailing list > IPv6-techsig(a)listserver.internetnz.net.nz > http://listserver.internetnz.net.nz/mailman/listinfo/ipv6-techsig

1 0

Re: [ipv6-wg] On deploying IPv6 for consumers..
by Nuno Vieira - nfsi 07 Oct '09

07 Oct '09

Hi Geert, These PMTU issues are a bit strange, as, our entire backbone is based on IPv6 native transits and peers, and we are also delivering two dual-stacked uplinks to the RIPE Meeting, with native IPv6 connectivity. I am available to investigate this further, also with RIPE OPS. Feel free to "ping" me at anytime. regards, --- Nuno Vieira nfsi telecom, lda. [Email] nuno.vieira(a)nfsi.pt [Phone] +351 21 114 2315 [Phone] +351 21 142 2300 [Mobile] +351 91 925 5561 [Fax] +351 21 114 2301 [Web] http://www.nfsi.pt/ ----- "Geert Jan de Groot" <GeertJan.deGroot(a)xs4all.nl> wrote: > Hi, > > By monitoring the stream from Lisbon, I can tell the RIPE meeting is > going well and lots of resolution is made towards deployment of > technologies like IPv6, DNSSEC and others. > It's good to see many faces, even though it's been a few years > since I attended a meeting myself. > I hope people are enjoying the meeting. > > On the topic of IPv6 deployment, I'd like to ask the WG on the > following > issue: > Turns out that, when browsing from www.ripe.net to find the URLs > of the Lisbon streams, I seem to run into a PMTU blackhole issue, > and, > IPv6 doesn't deal with these too well. > The only way around it, for me, was to switch IPv6 *OFF*. > (for those curious, it looks like a PMTU blackhole to rosie.ripe.net, > but I don't want to badmouth the RIPE NCC or the meeting crew - read > on!) > > Before you think this is another consumer-enduser, I'd like to > consider > that a few weeks ago, a few volunteers diagnosed a similar problem > with a large public FTP server in the Netherlands. I have tcpdump > logs > of the PMTU packets entering the FTP server box itself, and the TCP > stack > not noticing. Since it's not my box, there is still work-in-progress > to fix this, but it definitely is not a local problem - the PMTU > packets > come from the XS4all IPv6 tunnel broker box! > > My question, to the WG-at-large, is this: I'm just using a > consumer-grade > ADSL connection, with consumer-grade helpdesk access, who is unable > to deal with these issues. When IPv6 is deployed on a larger scale, > problems like these are bound to happen, and, I fear, these problems > happen with Joe Common who cannot diagnose these problems. > > My only recourse, and certainly Joe Common's only recourse, is to > switch IPv6 *OFF*. > That is, umm, incompatible with the IPv6 outreach the RIPE community > is currently doing. > > My questions therefore: > - Should these problems be discovered before large-scale deployment? > - Would it be a good idea to do efforts to pro-actively detect > (and correct) these problems on the infrastructure we have now, > and the infrastructure we're soon deploying? > - What mechanisms do we need to report these issues, so they can be > addressed by people who have both clue and enable/root access to > fix them? > (taking into account the very nasty scaling properties of > "consumer-grade helpdesk support lines" and the quality of the > reports > one gets from Joe Common-style users) > > Again, this message is not to badmouth RIPE NCC, the Lisbon LOC, > XS4all, or anybody else, but just a question on how to deal with > these > issues, as the current mechanisms ("consumer helpdesk") can't cope, > and the recourse ("switch IPv6 off") is probably not what we want. > > Comments? > > Geert Jan

1 0

On deploying IPv6 for consumers..
by Geert Jan de Groot 07 Oct '09

07 Oct '09

Hi, By monitoring the stream from Lisbon, I can tell the RIPE meeting is going well and lots of resolution is made towards deployment of technologies like IPv6, DNSSEC and others. It's good to see many faces, even though it's been a few years since I attended a meeting myself. I hope people are enjoying the meeting. On the topic of IPv6 deployment, I'd like to ask the WG on the following issue: Turns out that, when browsing from www.ripe.net to find the URLs of the Lisbon streams, I seem to run into a PMTU blackhole issue, and, IPv6 doesn't deal with these too well. The only way around it, for me, was to switch IPv6 *OFF*. (for those curious, it looks like a PMTU blackhole to rosie.ripe.net, but I don't want to badmouth the RIPE NCC or the meeting crew - read on!) Before you think this is another consumer-enduser, I'd like to consider that a few weeks ago, a few volunteers diagnosed a similar problem with a large public FTP server in the Netherlands. I have tcpdump logs of the PMTU packets entering the FTP server box itself, and the TCP stack not noticing. Since it's not my box, there is still work-in-progress to fix this, but it definitely is not a local problem - the PMTU packets come from the XS4all IPv6 tunnel broker box! My question, to the WG-at-large, is this: I'm just using a consumer-grade ADSL connection, with consumer-grade helpdesk access, who is unable to deal with these issues. When IPv6 is deployed on a larger scale, problems like these are bound to happen, and, I fear, these problems happen with Joe Common who cannot diagnose these problems. My only recourse, and certainly Joe Common's only recourse, is to switch IPv6 *OFF*. That is, umm, incompatible with the IPv6 outreach the RIPE community is currently doing. My questions therefore: - Should these problems be discovered before large-scale deployment? - Would it be a good idea to do efforts to pro-actively detect (and correct) these problems on the infrastructure we have now, and the infrastructure we're soon deploying? - What mechanisms do we need to report these issues, so they can be addressed by people who have both clue and enable/root access to fix them? (taking into account the very nasty scaling properties of "consumer-grade helpdesk support lines" and the quality of the reports one gets from Joe Common-style users) Again, this message is not to badmouth RIPE NCC, the Lisbon LOC, XS4all, or anybody else, but just a question on how to deal with these issues, as the current mechanisms ("consumer helpdesk") can't cope, and the recourse ("switch IPv6 off") is probably not what we want. Comments? Geert Jan

1 0

A suggestion about IPv6 Training
by Gabriella Paolini 07 Oct '09

07 Oct '09

Just a suggestion about IPv6 training and what we can do for IPv6. Under EU project Euchinagrid we (GARR) organized some tutorial to move grid programmers to a transparent network approach in their codes. http://www.euchinagrid.org/IPv6/IPv6_presentation/Introduction_to_IPv6_prog… This item could seem to be marginal to the network "affairs", but network programming is a fundamental point of contact between network and applications. Now network programming is dramatically IPv4 oriented... we support an evolution to a "protocol free" programming that demands all is possible to stack. Another point that we are trying to support is to change the point of view about the IPv6 introduction in a user network. Usually the focus is on moving the users/customers/clients to access to IPv6 resources . In our last workshop, we said to our users: first point: move all the services to IPv6 (web, mail, and all the other that you have) and after plan the clients connection. The message is: when a large number of IPv6 only users will arrive (and it will happen), they will be able to see your contents. Gabriella -- 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(a)garr.it - http://www.garr.it/

2 1

Agenda for IPv6 wg RIPE (v1)
by David Kessens 29 Sep '09

29 Sep '09

Hi, Please see below for the first version of our working group agenda for RIPE 59. The agenda looks a bit different from usual: as you know, Maarten Botterman did a survey regarding IPv6 deployment and offered to organize a followup panel discussion with realtime input from the public using an online tool. Please contact Maarten Botterman <maarten(a)gnksconsult.com> directly if there are particular followup topics that you believe are useful for the discussion. We are scheduled to meet: Tue Oct 6, 16.00-18.00, Corinthia Hotel, Lisbon, Portugal We very often get a few last minute agenda items that are interesting enough to make it worthwhile to revise our agenda and we still have a little bit of flexibility with our timing so I fully expect that the agenda might still change a little bit. See you all in Lisbon, David Kessens --- Agenda (v1) for IPv6 wg RIPE59 When: Tue Oct 6, 16.00-18.00 Where: Corinthia Hotel, Lisbon, Portugal A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. RIPE NCC IPv6 update (James Aldridge) C. Future of the working group - charter discussion (Shane Kerr, David Kessens, input from the audience) D. Future RIPE network experiments (David Kessens, input from the audience) E. IPv6 Deployment: what are the remaining issues and bottlenecks? (panel discussion with interactive input from the audience, moderator: Maarten Botterman, GNKS Consult) F. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) ... Y. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

2 2

A Modest IPv6-wg Proposal
by Shane Kerr 25 Sep '09

25 Sep '09

All, I checked Geoff Huston's IPv4 estimate again today: http://www.potaroo.net/tools/ipv4/index.html Assuming he's correct, we have 4 more RIPE meetings until IANA runs out of IPv4 addresses: RIPE 59 (2009 Autumn) RIPE 60 (2010 Spring) RIPE 61 (2010 Autumn) RIPE 62 (2011 Spring) And... that's it! IANA is done with IPv4! Then the real fun begins as we enter the RIR IPv4 run-out period. We then have 1 or 2 RIPE meetings until the RIRs run out of IPv4 blocks to hand out: RIPE 63 (2011 Autumn) RIPE 64 (2012 Spring... maybe) So... what is going on in the RIPE IPv6 working group at this critical phase? Since the last RIPE meeting there have been messages from the RIPE NCC about their IPv6ActNow stuff and a survey, and some messages about the minutes. The only thread with any content has been one about IPv6 minimum allocation sizes (thanks Marco!). This is not much. Since this group isn't actually doing anything, I propose we: 1. Shut down this working group after the next RIPE meeting. 2. Move discussion of IPv6 issues to other working groups (since "IPv6 issues" will become "IP issues" very soon anyway). Cheers, -- Shane

18 30

Simulation of the future IPv4 world at RIPE meetings?
by Shane Kerr 25 Sep '09

25 Sep '09

All, Perhaps we should begin preparing ourselves for the future IPv4 world by simulating various levels of IPv4 exhaustion at future RIPE meetings? I can imagine a few stages: 1. We can no longer give public IPv4 addresses to attendees. RFC 1918 for everyone, but with 1:1 mapping to public addresses. 2. The entire meeting gets NAT'ed to a single /24. 3. The entire meeting gets NAT'ed to a single IP address. Of course, this is the easy side. People are already accustomed to living behind NAT with their laptops. (They might be a little more annoyed when Google Maps won't work because there aren't enough ports to handle all the simultaneous open connections.) To be fair, we should also disable IPv4 for access to the meeting itself, as this is the first problem that new entrants to the Internet will have. But this is a huge burden on RIPE NCC staff and remote participants, so this will have to wait. :) -- Shane

7 8

Call for agenda items RIPE59
by David Kessens 09 Sep '09

09 Sep '09

Hi, I would like to hereby solicit your input for agenda items for our working group session for RIPE 59. We are scheduled to meet: Tue Oct 6, 16.00-18.00, Corinthia Hotel, Lisbon, Portugal All items that are of interest for the operational community regarding the deployment of IPv6 will be considered. Whether a proposal is brief or long, with powerpoint or no powerpoint, you have your own presentation or just a suggestion for a presenter, all proposals are welcome. Thanks, David Kessens ---

1 0