- ipv6-wg - mailman.ripe.net

RIPE NCC's Online Services Now IPv6 Enabled
by Andrei Robachevsky 24 Dec '08

24 Dec '08

Dear Colleagues, All of the RIPE NCC's major online services are now accessible via IPv6. These services include the web servers, ftp servers, DNS, the LIR Portal and mail system as well as the RIPE Database and all of the RIPE NCC's Information Services - Test Traffic Measurement (TTM) service, the Routing Information Service (RIS), DNS Monitoring (DNSMON) service and Hostcount. The RIPE NCC gradually enabled IPv6 for these services over the course of the last few years. Now that the two remaining services, the LIR Portal and the RIS, are also enabled, the RIPE NCC's entire service portfolio can be accessed using IPv6 as well as IPv4. This successfully completes the plan announced by the RIPE NCC at the RIPE 56 Meeting, held in Berlin in May, 2008 to enable IPv6-only users to access all the services offered by the RIPE NCC. More information about how to request IPv6 addresses from the RIPE NCC can be found at: http://www.ripe.net/info/faq/rs/ipv6.html Regards, Andrei Robachevsky Chief Technical Officer RIPE NCC

4 3

Fwd: questions regarding IPv6
by Anneke Laverman 13 Nov '08

13 Nov '08

Hi there, Can you please help me with the following questions on IPv6? I tried to contact David, but my e-mail was bounced. You'll find this e-mail below. Thanks in advance, Anneke Laverman ---------- Forwarded message ---------- From: Anneke Laverman <amlaverman(a)gmail.com> Date: Tue, Nov 11, 2008 at 1:22 PM Subject: questions regarding IPv6 To: kessens(a)nsn.com Hi David, I have been reading a lot about IPv6 on internet. Then i discovered the RIPE website. There's a lot more for me to read now. I am actually writing an article about IPv6 and i am trying to get a grip. I still have a lot of questions regarding the status of the transition and regarding the costs of implementing IPv6. Can you please help me on that part? Do you perhaps have a presentation that includes costs? I understand that the goal of RIPE regarding IPv6 is that by the end of this year an ipv6-only client is able to use all services offered by the RIPE NCC. I read this in the presentation of Mr Andrei Robachevsky. How large is this transition and what does it cost RIPE? How did Korea and Japan manage to implement IPv6, as i read in computable? Can you please give me some information? Or can you give me the name of the person(s) i need for answering these questions? Thanks a lot! Anneke Laverman

4 5

Agenda for the IPv6 Working Group Meeting RIPE57
by David Kessens 17 Oct '08

17 Oct '08

Please see below for the agenda of the IPv6 wg. I also strongly recommend to check out the plenary presentation agenda when it becomes available: there will be many presentations that will touch on, or even focus on IPv6. See you all in Dubai! David Kessens --- Agenda for the IPv6 Working Group Meeting RIPE57 When: Thursday, 30 October 2008, 11:00 - 12:30 Where: Amal Grand Ballroom, Dubai A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) C. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? 1) AMSIX (Henk Steenman) 2) Observations on IPv6 usage in Sweden (Kurt Erik Lindqvist) 3) input from the audience D. Follow-up: Global IPv6 routing table status (discussion) (Gert Doering) E. IPv6 Peering (Martin Levy) F. IETF report: IPv4 - IPv6 Co-Existence (Jari Arkko) followed up by discussion G. 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 ---

1 0

Call for agenda items for RIPE57
by David Kessens 10 Sep '08

10 Sep '08

Hi, The next RIPE meeting in Dubai is rapidly approaching. We are scheduled to meet in the Main Room, 11:00-12:30, Thu Oct 30, 2008. As usual, it is getting time to get our agenda together. We are interested in technical topics that will help the deployment of IPv6 in the RIPE service region. Your proposals for short or longer topics, without a presentation or with, or just for a discussion are all welcome. Please note that the RIPE 57 Meeting starts on a Sunday and ends on a Thursday to coordinate with the working week in the Middle East. David Kessens ---

1 0

tools for ipv6 allocations
by Raymond Jetten 01 Sep '08

01 Sep '08

Hello everyone, it has been a little bit quiet on this list so i thought i break the silence.. has anyone experiences with commercial tools for ipv6 allocations ? (i mean in this case for a LIR that keeps its ipv6 number bookkeeping) or have you used your own written tools please let me know what you have been using if it is not a good idea to put this issue on the list then please answer me directly (without a copy on the list). Thanks in advance.. (and sorry if this is list-misusing).. Rgds, Raymond

4 3

Fwd: End Users assignments from LACNIC from 2801:0000::/24 with longest prefix length of /48.
by Roque Gagliano 08 Aug '08

08 Aug '08

Dear Friends, LACNIC has just approved IPv6 assignment policies for End Users. These policies will be implemented from September 1st 2008. In order to comply with these new policies, LACNIC will assign from the IPv6 address block 2801:0000::/24 with a longest prefix length of / 48. We kindly request that you update your internal information and filters. Please remember that all resources administrated by LACNIC are listed at: http://www.lacnic.net/sp/registro/ Best Regards, Roque Gagliano - LACNIC

1 0

IPv6 enabled for email to the RIPE NCC
by Henk Uijterwaal 18 Jul '08

18 Jul '08

Dear Colleagues, On Wednesday, 16 July, the RIPE NCC's new mail servers were enabled. As of this date, it is possible to send mail to the RIPE NCC with IPv6 as a transport medium. This setup has been extensively tested but if you see any problems, please send an e-mail to <ops(a)ripe.net> or phone +31 20 535 4444. Kind regards, The RIPE NCC -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Is one of the choices leaving the office open? Alan Greenspan on the next elections

1 0

VS: [ipv6-wg] ipv6 test at ripe56 (not only laptops)
by Petteri Helin 08 May '08

08 May '08

Windows Mobile 6 (HTC Advantage) didn't work, which is not probably big surprise for anybody... :-) I think that WM6 should in theory support IPv6 but haven't heard of anybody actually have it working.... -- -------------------- Petteri Helin petteri.helin(a)tdc.fi ----- Alkuperäinen viesti ----- Lähettäjä: Raymond Jetten <raymond.jetten(a)elisa.fi> Lähetetty: 8. toukokuuta 2008 8:55 Vastaanottaja: ipv6-wg(a)ripe.net Aihe: [ipv6-wg] ipv6 test at ripe56 (not only laptops) Dear all, The other day we tested the ipv6 WLAN at the RIPE56 meeting on Berlin. Apart of the disconecting problem we ''forgot'' to test f.ex mobile phones with WLAN abilities, and all other PDA's with WLAN ability. I thionk it would be interesting to form a list of compatible devices etc and in this way show either where the problems are or which devices already are compatible. F.Ex. my phone a nokia E70 with the latest software, did not work at all with the v6 network, and software engineers in finland told me the mode is switched off by default and would need a software in which this is enabled. (tested with the default browser that comes with the phone and opera mini. i hope it is a good idea to answer to the list, or of this is not wanted please answer to my own address, i will try to publish the findings lateron (will tell you when and where). ************************************************************ Raymond Jetten Phone: +358 3 41024 139 Tietoliikenneasiantuntija Fax: +358 3 41024 199 Elisa Oyj / Verkonhallinta IP/MPLS Mobile: +358 45 6700 139 Hermiankatu 3A raymond.jetten(a)elisa.fi FIN-33720, TAMPERE http://www.elisafi ************************************************************

1 0

ipv6 test at ripe56 (not only laptops)
by Raymond Jetten 08 May '08

08 May '08

Dear all, The other day we tested the ipv6 WLAN at the RIPE56 meeting on Berlin. Apart of the disconecting problem we ''forgot'' to test f.ex mobile phones with WLAN abilities, and all other PDA's with WLAN ability. I thionk it would be interesting to form a list of compatible devices etc and in this way show either where the problems are or which devices already are compatible. F.Ex. my phone a nokia E70 with the latest software, did not work at all with the v6 network, and software engineers in finland told me the mode is switched off by default and would need a software in which this is enabled. (tested with the default browser that comes with the phone and opera mini. i hope it is a good idea to answer to the list, or of this is not wanted please answer to my own address, i will try to publish the findings lateron (will tell you when and where). ************************************************************ Raymond Jetten Phone: +358 3 41024 139 Tietoliikenneasiantuntija Fax: +358 3 41024 199 Elisa Oyj / Verkonhallinta IP/MPLS Mobile: +358 45 6700 139 Hermiankatu 3A raymond.jetten(a)elisa.fi FIN-33720, TAMPERE http://www.elisa.fi ************************************************************

3 2

ipv6 test at ripe56 (not only laptops) /Nokia E51 didnt work either
by Marton.HAJDU＠ec.europa.eu 08 May '08

08 May '08

Hi unfortunatelly, my Nokia E51 (100.34.20, 29.09.2007 RM-244 Nokia E51 02.1) did not work with v6 either. Regards, Marton

1 0

Agenda for ipv6 wg RIPE56
by David Kessens 07 May '08

07 May '08

Our working group is scheduled to meet on: Wed, May 7, 14:00 - 15:30, in Bordeaux Room, Hotel Palace, Berlin Please see below for our agenda. David Kessens --- Agenda for the IPv6 Working Group Meeting RIPE56 When: Wed, May 7, 14:00 - 15:30 Where: Bordeaux Room, Hotel Palace, Berlin A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Quick update from the RIRs regarding ipv6 services - RIPE NCC (Andrei Robachevsky) - APNIC (George Michaelson) C. Experience with ipv6 on the wireless network before, after and during the IPv4 turn-off (James Aldridge, input from the audience) D. Follow-up: - Global IPv6 routing table status (discussion) (Gert Doering) - Problems in the current Global IPv6 Routing System (discussion) (Bernhard Schmidt) E. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? - IPv6 traffic at AMS-IX (Arien Vijn) - (input from the audience) F. IPv6 deployment experience at AMS-IX (Arien Vijn) G. Deploying IPv6 at NETNOD (Kurt Erik Lindqvist) H. Developments/initiatives regarding IPv6 in the RIPE region and beyond - 6DEPLOY IPv6 trainings in Europe and the rest of the RIR regions (Jordi Palet Martinez) - (input from the audience) ... Y. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

2 1

Fwd: [address-policy-wg] Joking follow-up, second round
by Turchanyi Geza 04 May '08

04 May '08

---------- Forwarded message ---------- From: Turchanyi Geza <turchanyi.geza(a)gmail.com> Date: May 4, 2008 12:00 PM Subject: Re: [address-policy-wg] Joking follow-up, second round To: Carlos Friacas <cfriacas(a)fccn.pt> Hello, On 5/2/08, Carlos Friacas <cfriacas(a)fccn.pt> wrote: > On Wed, 30 Apr 2008, Turchanyi Geza wrote: > > > > 3, My suggestion was at RIPE 55 (and in my previous letter): let's do > > something similar in case of IPv6 what we have done with IPv4. "pseudo" > > dynamic IPv6! (Which is rather static, BTW.) > > > > For ISPs i'm assuming it would be easier to use static allocations, > instead of managing pools. Adding records to public databases is something > separate... Please rememeber, that I also suggested a technical solution: calculate the IPv6 addresses (subnet) from the previously allocated IPv4 address of the DSL user! That means: if we are able to allocate IPv4 addresses in "pseudo dynamic" way (wich is rather static), then we will be able to allocate IPv6 networks roughly at the same way. > 4, It is possible to allocate even /48 for every DSL users, even with the > > "pseudo" dynamic IPv6 allocation mechanism, however, why should we do > > it? If > > an "anonym" DSL user could use the same amount of the address space than > > a > > RIPE registered DSL user then nobody will register its address space in > > the > > database! > > > > You're trying to draw a line to distinguish residential users from > enterprises, is that it? No. I try to draw a line between "light" service and "serious" one (Or: between "dummies" and "experts".) > 5, The IPv6 address space is huge, however, if we do not know who is using > > it then we will loose it soon. > > > > We should always be able to link a single IPv6 address to an LIR/ISP... It won't help, unfortunately. How many people live in Holland? How many SIM card (mobile phone contract) exist? Much more, than people... > 6, Therefore my suggestion was amends previous policies (what were fine > > for > > the "experts", knowing what an IP address is and what a subnet is). > > > > > 8, I also would prefer if the "anonym" DSL users would share a visible > > different address space than the registered one. If IANA would reserve a > > prefix (preferably a /16) for the "anonym" DSL (mobile, CATV, etc) > > users, > > then the RIRs could allocate big pools from this prefix to ISPs using > > different allocation criteria than for the "registered" IPv6 networks. > > Different allocation criteria also mean: sparser usage at the beginning. If we allocate an IPv6 subnet to each and every DSL costumer, very few of them will realy use it at the beginning. However, fast IPv6 transition is not possible without this "generosity". The suggested size of the "anonym" pool is depend on the number of costumers: a /36 for very larg ISPs (more than 15 million costumers), a /40 for medium ISPs, a /44 for smaller ISP-s (less than 1 million costumers) Yes, there are ISP-s serving more than 15-16 millions costumers! This is one of the reasons why I suggested the creation of a new type of reusable addresses, the AS-local IPv4 address pool! > Back to the AS-local IPv4 address space concept: > > > > > > > > Private address space have to be unique within a routing domain, > > AS-local > > address space is unique within the given Autonomous System. (A group of > > autonomous Systems might share > > > > even this address space, but this is the exception, and not the rule.) > > > > > > > > I do think that the AS-local address pool can be created as a > > collaborative > > effort. IANA, ISPs can lease address blocks for this pool. This is not > > trading, but still a reallocation! Any reallocation policy should allow > > creation of a common address pool! > > > > > > > > It is easier to allocate "automatic" and "anonym" IPv6 network for DSL > > users > > if we have a > > > > big enough, better routable IPv4 address pool, an AS-local address pool. > > > > > > > > Please read also my proposals: > > > > > > > > > > http://www.ripe.net/ripe/meetings/ripe-55/presentations/turchanyi--two-joke… > > > > > > > > and my presentation: ( > > > > http://www.ripe.net/ripe/meetings/ripe-55/presentations/turchanyi-two-jokes… > > > > > > Best regards, > > > > > > > > Geza > > > > > > > > > > > > > > > > > > > > > > > >

1 0

Joking follow-up, second round
by Turchanyi Geza 30 Apr '08

30 Apr '08

Hi, Many thank for your comments in the first round. I appreciated that most of you read my text and commented only after reading as a whole. Those who listened me at RIPE 55 had been in better position. Let me clarify some details: I fully agree that the final document should not use the term "dummy" and "expert". However, these words emphasize the difference between different class of users. 1, Actually an IP address of a DSL user is not in the RIPE database, expect in the very exceptional case when the DSL user have a fix IPv4 address, may be even a subnet. 2, There are many ways to allocate IPv6 network for DSL users; however, it is hopeless to create database entries for them. The reasons are not only technical, but political. With IPv4 most of the DSL users had pseudo-anonym IPv4 addresses, their contact details had been known only by their ISP (and by the police, eventually), and the ISP is not allowed at all to publish the user data in any open database. 3, My suggestion was at RIPE 55 (and in my previous letter): let's do something similar in case of IPv6 what we have done with IPv4. "pseudo" dynamic IPv6! (Which is rather static, BTW.) 4, It is possible to allocate even /48 for every DSL users, even with the "pseudo" dynamic IPv6 allocation mechanism, however, why should we do it? If an "anonym" DSL user could use the same amount of the address space than a RIPE registered DSL user then nobody will register its address space in the database! 5, The IPv6 address space is huge, however, if we do not know who is using it then we will loose it soon. 6, Therefore my suggestion was amends previous policies (what were fine for the "experts", knowing what an IP address is and what a subnet is). 7, I still propose a common policy: how to distinguish between an "anonym" DSL user and a "registered" one. My proposal is: an "anonym" DSL user should receive a minimum IPv6 allocation. In this case the "minimum" is one subnet (/64) or, if there are automatically usable subnets for special purpose then the minimum size might include those subnets. If a DSL user need more then should fill an address request, and registered. 8, I also would prefer if the "anonym" DSL users would share a visible different address space than the registered one. If IANA would reserve a prefix (preferably a /16) for the "anonym" DSL (mobile, CATV, etc) users, then the RIRs could allocate big pools from this prefix to ISPs using different allocation criteria than for the "registered" IPv6 networks. Back to the AS-local IPv4 address space concept: Private address space have to be unique within a routing domain, AS-local address space is unique within the given Autonomous System. (A group of autonomous Systems might share even this address space, but this is the exception, and not the rule.) I do think that the AS-local address pool can be created as a collaborative effort. IANA, ISPs can lease address blocks for this pool. This is not trading, but still a reallocation! Any reallocation policy should allow creation of a common address pool! It is easier to allocate "automatic" and "anonym" IPv6 network for DSL users if we have a big enough, better routable IPv4 address pool, an AS-local address pool. Please read also my proposals: http://www.ripe.net/ripe/meetings/ripe-55/presentations/turchanyi--two-joke… and my presentation: ( http://www.ripe.net/ripe/meetings/ripe-55/presentations/turchanyi-two-jokes… Many thanks for your attention, Geza

1 0

Joking follow-up
by Turchanyi Geza 30 Apr '08

30 Apr '08

Hi, Is there anyone experienced in creating RIPE policy documents AND ready to help me to create a new one? (Or: two new ones). In the previous RIPE meeting I gave a talk ( http://www.ripe.net/ripe/meetings/ripe-55/presentations/turchanyi-two-jokes…) and attached a copy of a draft-RFC ( http://www.ripe.net/ripe/meetings/ripe-55/presentations/turchanyi--two-joke… ) I realized that some of my ideas relate to policies, other relate to technologies. As there is a separate policy working group now, I try to create a policy document as well – and need some help to formalize and may be finalize, correct my ideas. Highlights: 1, AS-local IPv4 address pool creation and maintenance 2, IPv6 address pool and address allocation for dummies Details1 (AS-local IPv4): The drafts ( http://www.ripe.net/ripe/meetings/ripe-55/presentations/turchanyi--two-joke…) gives more details, please find a short summary below. One of our responses to IPv4 address scarcity was the creation of "IPv4 private address pool" in 1994-1996. However: The scope of private addresses is not defined well; The private address pool size is too small for large ISPs; Network Address Translation should be in use at every routing domain borders. AS-local IPv4 pool should be similar but a little bit different compared to private address pool: Uniquely use in every Autonomous system (or collaborative group of ASs) Different set of IPv4 addresses (different scope!); Mechanism to add and revoke address-blocks by contributors to this pool should be implemented (in order to create a contribution-friendly atmosphere); Network Address Translation should be applied only if the destination address is outside of the originator Autonomous System boundary. The introduction of AS-local addresses would help us not only maintain our present IPv4 service, however, support the IPv4->IPv6 transition. (See below) Details2 - IPv6 address pool and address allocation for dummies: As everybody knows, there are well defined IP address allocation policies for fixed, static networks, like an University campus, or an enterprise network. These sites should have administrative and technical contact persons, the "tech" knows what an IP address is, the "admin" pays the bill, and both person is in the database of the Regional Registry. However, a huge part of the IP address space is used differently: both the "tech" and the "admin" work for the ISP, and the actual costumer of the IP address might not even know that he/she is using an IP address. (is a dummy costumer, only in this respect). This is the typical case in DSL environment today with IPv4. The introduction of IPv6 won't change too much. Shall we treat and regulate the IP address allocation for the "dummies" in the same way as we do it for the "experts"? I do not think so. In fact, we can not. Is there any policy for the "dummies"? I was unable to find it. If you have 30 millions "dummy" DSL (or cable modem, or mobile-phone) users how would you provide IP addresses for them? Of course, global addresses are the best. However, as there are not enough global addresses, some tricks should be applied. Common practice: allocate IP addresses dynamically. (BTW: dynamic allocation also mean pseudo-anonym and temporary allocation.) Dynamic allocation saves addresses considerably. However: If only 50% of the costumers connect at peak time today, tomorrow this may increase to 60%. That means: the need for addresses increased 20% while the costumer base is still the same. Using non-global, reusable IP addresses still does not solve all the problems. 30 millions is much more than the total size of the private address pool. Even if the ISP would assume, that not all users connect to the network at the same time, it might not help for long time as the number of costumer being on-line at peak time might increase. AND: using private addresses also means loosing functions. If your computer has a private address, you can not provide any services outside the private address domain (this stops using a couple of popular games, etc) This restriction is unavoidable consequence of using any kind of reusable addresses. However: the private address domain is very restricted. By using AS-local addresses, we would have a larger routing domain and fewer restrictions.) If we create an AS-local address pool, then it is possible to allocate reusable IP addresses in a more stable manner. This allocation is still a dynamic allocation, however, rather stable AND easy to couple IPv6 allocation with it. However, if we allocate IPv6 networks for every costumer that use dynamic IPv4 allocation today then most of them won't use for a while the IPv6 stuff. AND this IPv6 allocation will be pseudo-anonym, not directly reflected in the RIPE (or other RIRs) database. Therefore I suggest that ISP-s should have a dedicated IPv6 address pool for "dynamic IPv6" allocations and these address pool should be easily recognizable. (This was the reason why I proposed in my talk at RIPE 55, that all "dynamic IPv6" pool should be allocated from an IANA dedicated /16 prefix) The size of the "dynamic IPv6" network should be the minimal one: /64. If there are mechanism that allows automatic use a subnet, than a little bit bigger size might be allowed (max /60), however if /56 or /48 would be allowed than there wont be any more interest to have a RIPE registered network instead a "dynamic" one, therefore my suggestion is to declare in the policy that a "dynamic" IPv6 allocation should be as narrow as possible. OK. Please help me to rewrite the above idea to formulate policies. Thanks, Geza Turchanyi INFO-C

6 7

Call for agenda items and draft agenda for ipv6 wg RIPE56
by David Kessens 24 Apr '08

24 Apr '08

During next RIPE meeting, our working group is scheduled to meet on: Wed, May 7, 14:00 - 15:30, in Bordeaux Room, Hotel Palace, Berlin I have prepared a draft agenda (see below) with the all the usual agenda items. At this point, I would like to invite all of you to propose other agenda items that are relevant for the deployment of ipv6 in the RIPE service region. Note that we care more about the technical content of your topic than the presentation method: very brief topics without presentation slides that just need a brief discussion are just as welcome as longer presentations with slides. I would also like to draw your attention to the following: The RIPE NCC is planning to turn off IPv4 connectivity on the wireless network for the duration of around an hour on the wednesday morning. This will allow us to try out how one could survive on an IPv6 only network and to draw attention to all the issues that still need to be worked out in order to make this work 100% seemless for the rest of the Internet users. In order to help you prepare, in addition to the normal dual stack wireless network, there will be an IPv6 only wireless network available during the whole meeting and the RIPE NCC will provide instruction sheets on how to configure various popular operating systems. Obviously, the participants of the IPv6 working group don't need all this as we are already fully prepared for the coming of IPv6. However, you are very welcome to participate by helping other people to get their setup to work with IPv6 or by submitting reports and bugfixes/workarounds on problems that are discovered when trying this out. The actual operational details about this event will be posted by the RIPE NCC. In addition to our working group session and the ipv6 only event, I would like to encourage you to take a look at the plenary agendas. There are a large number of presentations scheduled that touch directly or indirectly on IPv6. I hope this helps and see you all in Berlin, David Kessens --- Draft agenda for the IPv6 Working Group Meeting RIPE56 When: Wed, May 7, 14:00 - 15:30 Where: Bordeaux Room, Hotel Palace, Berlin A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) C. Experience with ipv6 on the wireless network before, after and during the IPv4 turn-off (RIPE NCC, input from the audience) D. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) E. Follow-up: Global IPv6 routing table status (discussion) (Gert Doering) 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 3

Conference, Internet and Technology 08, invitation
by Vilem Sladek 02 Apr '08

02 Apr '08

Dear Mr., dear Mrs., my name is Vilem Sladek and I work for CZ.NIC (www.nic.cz) in Prague. For May 2008 we prepare the conference Internet and Technology 08, where we would like to present Internet experiences from the World. We would like also introduce more about IPv6, so we would like to invite you to Prague, to present about IPv6 to the Czech community. The conference is planed on 20th of May, will start at 10 a.m. and finished at about 5 p.m. The conference will be divided it to four parts (Domains, Internet Resources, Technologies and Zeitgeist). Your presentation is planed to second block (Internet resources). We are really interested in this topic and would like to introduce it to the Internet community in the Czech Republic. Please, could you send me the information or call me, if you want to know more detail, if you would like to came, if we can do anything for you for welcome you at the conference Internet and Technology 08. Thank you for your interest and will looking forward the answer. Best regards form Prague Vilem Sladek -- Vilém Sládek Communication Specialist CZ.NIC, z.s.p.o. Americka 23, 120 00 Praha 2 Czech Republic T +420 222 745 117 F +420 222 745 112 M +420 739 452 919 www.nic.cz

1 0

What is difference among /32 , /48 and /64 as charge?
by Yavuz Maşlak 08 Feb '08

08 Feb '08

We are a LIR as small class. We want to apply for ipv6. Is there a difference as charge apply for between /32 and /64 ? I mean, a LIR who has large class, when that LIR applies for /32 and has it, What does that LIR cost for that ? Also, While We are a LIR as small; 1- Can we apply for ipv6 /32 ? 2- What is difference among /32 , /48 and /64 as charge? Thanks a lot.

3 2

[anandb@ripe.net: [dns-wg] IANA introduces AAAA record for K-root]
by David Kessens 05 Feb '08

05 Feb '08

----- Forwarded message from Anand Buddhdev <anandb(a)ripe.net> ----- From: Anand Buddhdev <anandb(a)ripe.net> To: dns-wg(a)ripe.net User-Agent: KMail/1.9.5 Subject: [dns-wg] IANA introduces AAAA record for K-root Date: Tue, 5 Feb 2008 15:10:43 +0100 Dear Colleagues, Yesterday, 4 February 2008, at around 17:00 (UTC), IANA introduced AAAA records for six of the root servers in the root server system. One of these servers is k.root-servers.net (2001:7fd::1), which is managed by the RIPE NCC. This change allows the root zone to be queried over IPv6. The K-root IPv6 prefix is currently anycast from the two global nodes, located in Amsterdam and Miami. The introduction of the AAAA records went smoothly, and we are monitoring the query rate and pattern. We are also collecting more detailed information for future analysis. A graph showing the IPv6 query rate for the last 24 hours can be viewed at: http://ripe.net/news/k-root-aaaa-announcement.html More information about AAAA records in the root zone is available at: http://www.iana.org/reports/root-aaaa-announcement.html Regards, -- Anand Buddhdev DNS Services Manager, RIPE NCC ----- End forwarded message -----

1 0

how to generate ipv6 extension headers
by Prasanna kumar .E 23 Jan '08

23 Jan '08

I am into the ipv6 testing these days.I am stuck in between. I want to know how can I generate the ipv6 extension headers(like hopbyhop,encapsulation,etc.,) Thanks and regards, E Prasanna Kumar ============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at <a href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahindra.com/Disclaimer.html</a> externally and <a href="http://tim.techmahindra.com/Disclaimer.html">http://tim.techmahindra.com/Disclaimer.html</a> internally within Tech Mahindra. ============================================================================================================================

2 1

AAAA records to be added for root servers
by Barbara Roseman 07 Jan '08

07 Jan '08

apologies for cross-posting... On 4 February 2008, IANA will add AAAA records for the IPv6 addresses of the four root servers whose operators have requested it. A technical analysis of inserting IPv6 records into the root has been done by a joint working group of ICANN's Root Server System Advisory Committee and Security and Stability Advisory Committee, a report of which can be found at http://www.icann.org/committees/security/ sac018.pdf. Network operators should take whatever steps they feel appropriate to prepare for the inclusion of AAAA records in response to root queries. More information will be posted to the IANA web site during January. Regards, Barbara Roseman IANA General OperationsManager ICANN

3 2

2007 IPv4 Address Use Report
by Iljitsch van Beijnum 02 Jan '08

02 Jan '08

2007 IPv4 Address Use Report In 2007, the number of available IPv4 addresses went down from 1300.65 million to 1122.85 million, a difference of 177.8 million addresses. The number of usable addresses is 3706.65 million, so on January 1, 2007 we were at 64.9% utilization and a year later we're at 69.7%. These figures are derived from the records published on the FTP servers of the five Regional Internet Registries (RIRs): AfriNIC, which gives out address space in Africa, APNIC (Asia-Pacific region), ARIN (North America), LACNIC (Latin American and the Caribbean) and the RIPE NCC (Europe, the former Soviet Union and the Middle East). There are two other ways to interpret the same data. The first is simply add up all the address space with a date indicating that it was given out in 2007. That number is 186.93 million addresses. The third method is to compensate for ARIN's record keeping peculiarities (see this Internet Protocol Journal article). This brings the total for 2007 to no less than 196.77 million, the highest number ever. The second-highest was 1991 with 189 million addresses. The 196.77 million figure is approxmately 19% higher than the 2005 and 2006 numbers, which were largely the same. All numbers only include addresses that are still in use. For the first time in many years, in 2007 one of the old class A blocks was returned to IANA: block 46.0.0.0/8, 16.78 million addresses in size, is now part of the global pool of free address space. This accounts for most of the difference between the 177.8 and 196.77 numbers. The status of the 221 usable blocks of 16.78 million address is now as follows: Delegated to Blocks +/- 2007 Addresses (millions) AfriNIC 2 +1 33.55 APNIC 26 +7 436.21 ARIN 27 452.98 LACNIC 6 +2 100.66 RIPE NCC 26 +4 436.21 Various 49 -1 822.08 End-user 42 -1 704.64 Available 43 -12 721.42 In addition to the 43 unused blocks (721.42 million addresses) that IANA holds, there is additional free space in the form of addresses delegated from IANA to the regional internet registries, but not yet further delegated by the RIR in question to an ISP or end-user. 2006-01-01 2007-01-01 delegated delegated free delegated delegated free TO BY TO BY AfriNIC 16.78 6.39 10.39 33.55 11.97 21.58 APNIC 318.77 297.23 21.54 436.21 366.87 69.34 ARIN 452.98 350.48 102.50 452.98 394.08 58.90 LACNIC 67.11 42.71 24.40 100.66 57.52 43.14 RIPE NCC 369.10 317.62 51.48 436.21 378.35 57.86 Total RIRs 1224.74 1014.43 210.31 1459.61 1208.79 250.82 Various 838.86 671.26 167.60 822.08 671.48 150.60 End-user 721.42 704.64 16.78 704.64 671.09 33.55 Available 922.74 16.78 905.96 721.42 16.78 704.64 Total 3707.76 2407.11 1300.65 3707.75 2568.14 1139.61 This view uncovers two inconsistencies: block 7.0.0.0/8 that is part of the free space according to the IANA IPv4 address space overview shows up as delegated to the US Department of Defense in ARIN's records. Net 14.0.0.0/8 is for the "public data net" (see RFCs 3330 and 1700) so it's not part of the regular delegation system. 43.0.0.0/8 is delegated to "Japan Inet" by IANA. Those delegations used to be registered in ARIN's database but this block was transferred to APNIC in 2007, where it does show up in the whois service, but not as part of the delegated address space in the files on the FTP server. The total of 3707.76 (or 3707.75) million addresses is slightly different from the 3706.65 maximum mentioned earlier because the latter excludes all RFC 1918 private address space, the former still includes 192.168.0.0/16 and 172.16.0.0/12. The size of address blocks given out was increasing until 2005, but now shows a downturn. The table below shows the number of delegations for a certain range of block sizes (equal or higher than the first, lower than the second value). (2005 and earlier values from 2006-01-01 data, 2006 and 2007 values from 2007-01-01 data. No correction for the ARIN accounting method.) 2001 2002 2003 2004 2005 2006 2007 < 1000 474 547 745 1022 1309 1507 1830 1000 - 8000 1176 897 1009 1516 1891 2265 2839 8000 - 64k 868 822 1014 1100 1039 1192 1015 64k - 500k 262 163 215 404 309 419 395 500k - 2M 39 29 46 61 60 57 62 > 2M 5 5 6 7 18 17 24 The increase in large blocks has a very dramatic effect while the small blocks are insignificant, when looking at the millions of addresses involved: 2001 2002 2003 2004 2005 2006 2007 < 1000 0.16 0.18 0.25 0.35 0.44 0.51 0.63 1000 - 8000 4.47 3.23 3.45 4.49 5.07 5.83 6.93 8000 - 64k 12.81 11.35 14.00 15.99 15.46 18.01 15.67 64k - 500k 32.19 20.28 25.51 42.01 34.23 50.86 50.83 500k - 2M 24.64 21.30 31.98 44.63 41.63 46.69 45.50 > 2M 14.68 12.58 12.58 20.97 68.62 52.43 67.37 Despite the strong increase in the number of 2 million+ blocks and the amount of address space given out in these blocks, the average block size has been going down because of the very large growth in the numbers of smaller blocks: Year Blocks Addresses (M) Average block size 2000 2794 78.35 28043 2001 2824 88.95 31497 2002 2463 68.93 27985 2003 3035 87.77 28921 2004 4110 128.45 31252 2005 4626 165.45 35765 2006 5457 174.32 31945 2007 6165 186.92 30320 The 2568.14 million addresses currently in use aren't very evenly distributed over the countries in the world. The current top 15 is: 2007-01-01 2007-01-01 change Country 1 - US 1408.15 M 1366.53 M +3% United States 2 - JP 141.47 M 151.27 M -6% Japan 3 (4) CN 135.31 M 98.02 M +38% China 4 (3) EU 120.35 M 115.83 M +4% Multi-country in Europe 5 - GB 83.50 M 93.91 M -11% United Kingdom 6 - CA 73.20 M 71.32 M +3% Canada 7 - DE 72.46 M 61.59 M +18% Germany 8 - FR 67.79 M 58.23 M +16% France 9 - KR 58.86 M 51.13 M +15% Korea 10 - AU 33.43 M 30.64 M +9% Australia 11 (12) IT 24.04 M 19.14 M +26% Italy 12 (11) BR 23.46 M 19.27 M +22% Brazil 13 (16) MX 21.50 M 16.26 M +32% Mexico 14 (13) ES 20.42 M 18.69 M +9% Spain 15 - NL 19.89 M 18.08 M +10% Netherlands The -6% and -11% figures for the UK and Japan are once again anomalies: the former is the missing 43.0.0.0/8 net and in the latter case, ARIN and RIPE both had a record for 25.0.0.0/8 in the 2007-01-01 data, but this was cleared up in the 2008-01-01 data. Although the US still added more than 40 million new addresses to its immense existing stockpile, its growth was modest percentage-wise and it now holds 55% of the IPv4 address space in use, down from 57%. All of the other countries in the top 15 except for Canada and "EU" saw their address use grow faster than the 7% average. This brings the total for the top 15 excluding the US to 35%, up from 34%. The rest of the world gets the remaining 10%, up from 9%. See http://www.bgpexpert.com/addrspace2007.php for a copy of this report and links to the versions for 2006 and 2005.

1 0

RIPE NCC Makes Record Number of IPv6 Allocations
by Alex Le Heux 14 Dec '07

14 Dec '07

This announcement was posted on the RIPE NCC News & Announcements webpage yesterday: RIPE NCC Makes Record Number of IPv6 Allocations The months of October and November 2007 set new records for the number of IPv6 allocations made in a single month by the RIPE NCC. 24 allocations were made to RIPE NCC members in October, arecord immediately broken by the 31 allocations made in November. The previous peak was 19 allocations in a single month, which was achieved on three separate occasions in 2003, 2004 and 2007. This surge in demand for IPv6 address space follows recent changes in the IPv6 allocation policy, which made it easier to get IPv6 allocations. The increase also comes in the wake of the publication of the RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6. This statement, released immediately after the RIPE 55 meeting in Amsterdam in October, urged all Internet industry stakeholders, including ISPs, governments and regulators, to take steps to foster the accelerating deployment of IPv6. The text of this resolution can be found at: http://www.ripe.net/news/community-statement.html The deployment of IPv6 across the Internet has been a subject of growing global interest, particularly as it relates to the diminishing pool of free IPv4 address space, and the impact that this will have on the ongoing growth and future stability of the Internet. For more information on this, please send an email to <ncc(a)ripe.net>. Best regards, Alex Le Heux Policy Implementation and Coordination, RIPE NCC

14 16

[Fwd: need help with global ipv6 topology measurement]
by Henk Uijterwaal 28 Nov '07

28 Nov '07

-------- Original Message -------- Subject: need help with global ipv6 topology measurement Date: Tue, 27 Nov 2007 15:55:42 -0800 From: k claffy <kc(a)caida.org> To: nanog(a)merit.edu if you have ipv6 connectivity and are willing to volunteer some (low bandwidth) v6 traceroute data to a good cause (== a topology map of observed ipv6 connectivity), please help us out for a few ( estimated < 15) min with: http://www.caida.org/data/how-to/scamper/ipv6-collection-2007/ please share w all your ipv6friends, k -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Is one of the choices leaving the office open? Alan Greenspan on the next elections

1 0

IPv6 policies & BGP announcements
by Clement Cavadore 28 Nov '07

28 Nov '07

Hi, I have a few question regarding IPv6, and policies. I am not LIR, so I cannot get any /32 for my network usage. I got from my LIR a /48 for my internal network needs, and another /48 for another end-user, routed through my network. The two /48 are consecutive, and aggregable as a single /47. - Am I allowed to announce a prefix more specific than my LIR's /32 (originated from my ASN, not the LIR's one) ? - If I can announce a more specific prefix, do I have to announce a couple of /48s, or may I announce a single /47, originated from my AS ? If I can announce the /47, I assume the LIR has to create a route: object ? - Is there any recommendations I'd need to know for such a situation (except becoming LIR, which is not possible for us at the moment) ? Thank you for your help -- Clément Cavadore

5 7

Few questions about IPv6
by Marcin Gondek 15 Nov '07

15 Nov '07

Hello All , I have few question about IPv6 and maybe someone can explain this. Sorry if those information can be found on RIPE page or I'm sending it to wrong mailing list, I'm not able to find it. 1. Do I have to be a LIR to request /32 subnet from RIPE, can be it done by another LIR which will request subnet for me (as its customer)? 2. Do I have to be a LIR to request AS number from RIPE, can be it done by another LIR which will request AS number for me (as its customer)? Thanks in advance. -- Marcin Gondek / Drixter e-utp.net NIP: PL1181589645 REGON: 140584662 Tel. +48602159929 Fax. +48222012418 <mailto:office@e-utp.net> office(a)e-utp.net <http://www.e-utp.net> http://www.e-utp.net

6 9