- ipv6-wg - mailman.ripe.net

Request: IPv6 day preparations
by David Kessens 21 Apr '11

21 Apr '11

Hi, I was wondering whether there is anybody on this list who might be willing and/or knows somebody who can speak at the next RIPE meeting regarding ongoing preparations for the IPv6 day in June: http://isoc.org/wp/worldipv6day/ Specifically, are there any people who are for example preparing their customer service department and other parts of the company as opposed to just moving the main website to ipv6. Are there any problems you expect ? Or, other things that deserve attention ? Please respond to: ipv6-wg-chairs(a)ripe.net Thanks, David Kessens ---

1 0

New article on RIPE Labs: Testing Teredo
by Mirjam Kuehne 20 Apr '11

20 Apr '11

Dear colleagues, Please see a new interesting article on RIPE Labs: Testing Teredo by Geoff Huston: http://labs.ripe.net/Members/gih/testing-teredo Kind Regards, Mirjam Kuehne RIPE NCC

1 0

FYI: APNIC has activated their final /8 policy
by Marco Hogewoning 18 Apr '11

18 Apr '11

Dear Colleagues, As you may have already seen on other mailing lists, APNIC, the Regional Internet Registry for the Asian Pacific region, has reached the end of their pool of available IPv4 addresses. As of Friday April 15, they have activated their "final /8" policy, which was decided upon by the APNIC community [1]. This event in itself does not have any effect on the amount of IPv4 addresses which are still available within the RIPE NCC service region. But we would like to remind you that eventually the RIPE community will have to deal with the same situation. We would like to point out that he RIPE community has decided that an LIR must already have IPv6 addresses before they become eligible for their final allocation under the final /8 policy. This requirement is in addition to having a demonstrated need for address space. For more information about this, please refer to section 5.6 of the IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region [2]. We would like to urge the community to start deploying IPv6 as soon as possible if they haven't done so already. This is the only way to support the long-term growth of the Internet and ensure the continuity of their operations. And if you have already deployed IPv6 in your network, please share your experiences for others to learn from. Greetings, The IPv6 working group chairs, Marco, David & Shane [1] http://www.apnic.net/publications/news/2011/final-8 [2] http://www.ripe.net/ripe/docs/ripe-509

1 0

RIPE IPv4 Pool Graph
by Ahmed Abu-Abed 06 Apr '11

06 Apr '11

Greetings, RIPE NCC is now publishing an IPv4 pool graph with weekly updates, and the latest data show five /8 blocks are remaining. More at http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-po… Regards, -Ahmed

1 0

Is there a recommended list for sharing IPv6 deployment experience/woes/etc?
by Niall O'Reilly 29 Mar '11

29 Mar '11

A colleague in the Irish IPv6 TF was asking, and I couldn't think of just the right list. The kind of sharing of operational experience he's looking for doesn't seem to me to fall quite within the scope of the RIPE IPv6 WG list, and certanly not within the IETF v6ops list. I'll be glad to find I'm mistaken, or else to have suggestions ... Thanks in advance. Niall Begin forwarded message: > From: Gavin McCullagh <gavin.mccullagh(a)gcd.ie> > Date: 29 March 2011 12:02:46 GMT+01:00 > To: Irish IPv6 Task Force <ipv6tf(a)listserv.tssg.org> > Subject: [Ipv6tf] spoofed router advertisements > Reply-To: Gavin McCullagh <gavin.mccullagh(a)gcd.ie> > > > Hi folks, > > I realise this isn't a list for practical details of running IPv6, but is > there a list people do recommend? > > For some time now, on and off, we've been noticing bogus IPv6 router > advertisements, presumably from student laptops. [...]

6 6

New on RIPE Labs: 6to4 - Why is it so Bad?
by Mirjam Kuehne 21 Mar '11

21 Mar '11

[apologies for duplicates] Dear colleagues, In an earlier article on RIPE Labs, we showed that a large percentage of 6to4 connections fail. In this new article by Emile Aben, we look at why these connections fail and what can be done about this: http://labs.ripe.net/Members/emileaben/6to4-why-is-it-so-bad Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Re: ipv6-wg -- confirmation of subscription -- request 440625
by Henk Uijterwaal 15 Mar '11

15 Mar '11

confirm 440625

1 0

"Preparing an IPv6 Addressing Plan" - New Manual Published on www.ripe.net
by Nathalie Trenaman 15 Mar '11

15 Mar '11

Dear colleagues, The RIPE NCC has just published "Preparing an IPv6 Addressing Plan", an easy-to-read manual to help End Users effectively distribute large blocks of IPv6 address space over their networks. The document is available for download here: http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6_ad… The manual was written by Sander Steffann and Surfnet. It has been translated from Dutch to English by the RIPE NCC. If you have any feedback about the manual, please send it to: <nathalie(a)ripe.net> Kind Regards, Nathalie Trenaman RIPE NCC Trainer

1 0

Re: [address-policy-wg] IPv6 allocations for 6RD
by Ahmed Abu-Abed 28 Feb '11

28 Feb '11

Greetings, Compared to 6RD, the TSP protocol (RFC 5572) can also rapidly deploy IPv6, needing one /32 allocation while customer site prefixes can be /64, /56 or /48. Reason is TSP doesn't embed the customer's IPv4 address in its IPv6 address as 6RD does. Being a hot topic nowadays, its worth mentioning customer site access gear (CPE) requirements are more relaxed with TSP as it doesn't need the Service Provider IPv4-only access modem to be changed or upgraded. A TSP client can run in a small hardware device (thru an Ethernet interface connection) or a software client in the home network behind the SP modem while enabling all v6 capable nodes with the assigned prefix by automatically establishing a tunnel to the SP TSP tunnel server. Since TSP allows for static prefix assignment and larger prefixes than /64 without wasting v6 space, this would mimic a native deployment more closely. The stateful tunneling could be seen as any other encapsulation in the access, and a few service providers have it running already. In the long term, both 6RD and TSP will give way to reverse tunneling i.e. v4-in-v6, as this is the only way (after IPv4 depletion) for both protocols to co-exist on a host while having a mix of v4-only and dual-stack accessible services/website. Reverse tunneling's current protocols, DS-Lite and DSTM, are very similar to TSP's concept so the same clients & servers supporting TSP can be adapted to support DS-Lite. Unfortunately, until IPv4 disappears from web content, hosts and servers these coexistence mechanisms will be needed. Regards, -Ahmed From: Kurt Smolderen Sent: Monday, February 28, 2011 11:13 AM To: address-policy-wg(a)ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD I strongly support the idea of assigning a smaller prefix to ISPs which are in a state of deploying IPv6 but need to use transitional mechanism for (some of) their customers. Mark has described one of the problems very clear in his email: if an ISP has only a /32 prefix and needs to use all 32 IPv4 bits in the 6rd configuration, only a /64 can be delivered to the home instead of the desired /56 or /48. Needing all 32 bits is for instance the case when an ISP offers internet connectivity to some of its customers via a partnership with another ISP. However, I want to point to an additional problem which appears when an ISP wants to deploy native IPv6 but needs to roll out 6rd (or any other transitional technique) as well. For native IPv6, the ISP will create an IPv6 addressing plan. This will normally include separate prefixes for the ISP's own servers, the ISP's backbone, the ISP's customers etc. For the 6rd domain, the full /32 range is however needed. So at this stage, the ISP has two options: 1) Implement 6rd only 2) Implement native IPv6 only and exclude some customers from being able to use IPv6 (those which would normally be connected through 6rd) I strongly believe we all agree 6rd is only a temporary solution. So I can't imagine we would prefer skipping native IPv6 deployments in favor of IPv6 transitional mechanisms. I also believe we all agree we should enable IPv6 for as much customers as we can, which makes me conclude the second 'option' is not really an option at all... My primary concern is that any ISP - regardless of how small or big it is - can independently of other organizations/ ISPs move forward with IPv6 deployment. RIPE can support this by adapting a policy which - albeit for a limited time span - allows the assignment of a contiguous IPv6 prefix which size does not only depend on the amount of customers the ISP has, but also incorporates the needed technologies to 'IPv6-enable' as much customers as possible. Regards, -Kurt

2 1

Benefits of IPv4 exhaustion
by Shane Kerr 25 Feb '11

25 Feb '11

All, As seen in today's xkcd: http://xkcd.com/865/ Happy Friday everyone! -- Shane

1 0