- ipv6-wg - mailman.ripe.net

2009 IPv4 Address Use Report
by Iljitsch van Beijnum 01 Jan '10

01 Jan '10

[ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. Web version for the monospace font impaired and with some links: http://www.bgpexpert.com/addrspace2009.php ] 2009 IPv4 Address Use Report As of January first, 2010, the number of unused IPv4 addresses is 722.18 million. On January 1, 2009, this was 925.58 million. So in 2009, 203.4 million addresses were used up. This is the first time since the introduction of CIDR in 1993 that the number of addresses used in a year has topped 200 million. With 3706.65 million usable addresses, 80.5% of the available IPv4 addresses are now in some kind of use, up from 75.3% a year ago. So the depletion of the IPv4 address reserves is continuing in much the same way as in previous years: Date Addresses free Used up 2006-01-01 1468.61 M 2007-01-01 1300.65 M 167.96 M 2008-01-01 1122.85 M 177.80 M (with return of 16.78 M to IANA) 2009-01-01 925.58 M 197.27 M 2010-01-01 722.18 M 203.40 M These figures are derived from from the Internet Assigned Numbers Authority's IANA IPv4 Address Space Registry page and 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). The IANA list shows the status of all 256 blocks of 16777216 addresses identified by the first 8-bit number in the IPv4 address. http://www.bgpexpert.com/ianaglobalpool.php is a graphical representation of the IANA global pool (updated weekly). The RIR data indicates how much address space the RIRs have delegated to internet service providers (and sometimes end-users). The changes over the course of 2009 are as follows: Delegated Blocks +/- 2009 Addresses Used Available to/status (in millions) AfriNIC 2 33.55 14.89 18.66 APNIC 34 +4 570.42 540.36 30.06 ARIN 31 520.09 486.58 33.51 LACNIC 6 100.66 79.77 20.89 RIPE NCC 30 +4 503.32 450.11 53.21 RIRs subtotal 103 +8 1728.05 1571.71 156.34 LEGACY 92 1543.50 1413.88 129.62 UNALLOCATED 26 -8 436.21 436.21 Totals 221 3707.76 2985.59 722.17 The RIRs requested an unusually small number of /8s from IANA: only eight. As a result, APNIC is well below the nine months working inventory threshold, so it should be getting no less than six additional /8s soon to get back to 18 months working inventory. Similarly, ARIN should be getting five additional /8s soon. This would bring us to 15 /8s remaining in the IANA global pool, and should allow for regular operation for about the rest of the year. Then in early 2011, the next round of delegations will have to happen, which may or may not hit the magic fifth-to-last /8, after which the remaining four will be given to the other four RIRs and then each RIR will run out of IPv4 space at its own pace. The total number of available addresses is slightly higher than the previously mentioned figure at 3707.76 million because the table above includes 172.16.0.0/12 and 192.168.0.0/16, which are set aside for private use. Networks 0.0.0.0/8 and 127.0.0.0/8 aren't usable because of special uses and 10.0.0.0/8 is also set aside for private use. 224 - 239 are multicast addresses, and 240 - 255 is class E, which is "reserved for future use". The 2985 million addresses currently in use aren't very evenly distributed over the countries in the world. The current top 15 is: 2010-01-01 2009-01-01 increase Country 1 - US 1495.13 M 1458.21 M 2.3% United States 2 - CN 232.45 M 181.80 M 27.9% China 3 - JP 177.15 M 151.56 M 16.9% Japan 4 - EU 149.48 M 120.29 M 24.3% Multi-country in Europe 5 (6) DE 86.51 M 81.75 M 5.8% Germany 6 (9) KR 77.77 M 66.82 M 16.4% Korea 7 - CA 76.96 M 74.49 M 3.3% Canada 8 - FR 75.54 M 68.04 M 11.0% France 9 (5) GB 74.18 M 86.31 M -14.1% United Kingdom 10 - AU 39.77 M 36.26 M 9.7% Australia 11 - BR 33.95 M 29.75 M 14.1% Brazil 12 - IT 33.50 M 29.64 M 13.0% Italy 13 (14) RU 28.47 M 23.18 M 22.8% Russia 14 (13) TW 27.10 M 24.01 M 12.9% Taiwan 15 (17) NL 22.84 M 21.67 M 5.4% Netherlands The reduction in address use by the UK is because net 51.0.0.0/8 is now registered as country "EU" rather than "GB". In 2008, the United States was the biggest user of new address space with 50 million new addresses put into use. China was second with 46.50 million. In 2009, they swapped places: China used up 50.65 million addresses and the US a mere 36.92 million. The US now holds 50.1% of the IPv4 address space in use, down from 52.4% last year. The total for the top 15 excluding the US is now 38%, up from 35.8%. The rest of the world gets the remaining 12%, up from 11.8%. The size of address blocks given out was increasing until 2005, and then started decreasing. 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). 2003 2004 2005 2006 2007 2008 2009 < 1000 745 1022 1309 1507 1830 1896 1747 1000 - 8000 1009 1516 1891 2265 2839 3235 3185 8000 - 64k 1014 1100 1039 1192 1015 1129 1169 64k - 500k 215 404 309 419 395 410 403 500k - 2M 46 61 60 57 62 82 70 > 2M 6 7 18 17 24 18 21 In millions of addresses: 2003 2004 2005 2006 2007 2008 2009 < 1000 0.25 0.35 0.44 0.51 0.63 0.65 0.59 1000 - 8000 3.45 4.49 5.07 5.83 6.93 7.75 7.55 8000 - 64k 14.00 15.99 15.46 18.01 15.67 17.40 18.01 64k - 500k 25.51 42.01 34.23 50.86 50.83 52.58 50.50 500k - 2M 31.98 44.63 41.63 46.69 45.50 57.41 49.28 > 2M 12.58 20.97 68.62 52.43 67.37 54.00 54.12 Numbers of delegations and their average size: 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 2008 6770 189.79 28035 2009 6595 180.06 27302 (The numbers of addresses given out are lower here because ARIN often attributes the delegation of new addresses to a previous year, this view doesn't correct for that.)

1 0

2009-08 Implementation: IPv6 PI Assignments for LIRs
by Nathalie Trenaman 10 Dec '09

10 Dec '09

[Apologies for duplicate emails] Dear Colleagues, We are pleased to announce that RIPE Policy Proposal 2009-08,"IPv6 Provider Independent (PI) Assignments for LIRs", 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-08.html The updated "IPv6 Address Allocation and Assignment Policy" document is available at: http://www.ripe.net/ripe/docs/ipv6-policies.html The following document has also been updated to reflect this policy implementation: http://ripe.net/ripe/docs/ipv6-pi-support.html Regards, Nathalie Trenaman Registration Services RIPE NCC

1 0

Last Call: New IPv6 working group charter (20091213)
by David Kessens 07 Dec '09

07 Dec '09

All, We have reached the point where it is time to do a Last Call on the latest revision of the new proposed ipv6 working group charter as attached below and posted to the mailing list earlier today. We have gone from determining the generic direction to fine tuning the language for final publication. As Shane mentioned in his previous mail it looks like we have reached the point where further changes are not going to provide for a much improved outcome. Please speak up on or before 20091213 to voice your support for the new charter, or alternatively a statement why we need to consider further changes with suggestions of what these changes should entail. I have already started to keep track of people who stated their support before the official Last Call started, but after Shane's final version was posted, so there is no need to do so again. Just in case we do find very minor issues like a spelling error, I will correct them without issuing a new Last Call. Barring any other negative comments that preclude me from declaring a rough consensus, I will ask the RIPE NCC to post the new charter on the website after the Last Call has passed. I hope this helps, David Kessens --- New proposed charter for the IPv6 working group: ----------------------------------------------------------------------- IPv6 is the next generation IP protocol. The IPv6 working group exists to promote IPv6 adoption. The working group activities may be anything useful in helping people to deploy IPv6, and to manage IPv4/IPv6 co-existence. These activities include: * Outreach * Education * Sharing deployment experiences * Discussing and fixing operational issues The working group will cooperate with operators and others, both inside and outside the networking industry, to share resources and combine efforts. -----------------------------------------------------------------------

8 7

Proposal for new charter: Version 3
by Shane Kerr 02 Dec '09

02 Dec '09

All, I have tried to incorporate additional comments in this version of the charter. I don't plan on producing any more versions - we can debate each word forever, but I think we have reached the point of diminishing returns. If we have consensus, then we can consider ourselves rechartered! Otherwise someone else can work thorough the text again (or start over from scratch). ----------------------------------------------------------------------- IPv6 is the next generation IP protocol. The IPv6 working group exists to promote IPv6 adoption. The working group activities may be anything useful in helping people to deploy IPv6, and to manage IPv4/IPv6 co-existence. These activities include: * Outreach * Education * Sharing deployment experiences * Discussing and fixing operational issues The working group will cooperate with operators and others, both inside and outside the networking industry, to share resources and combine efforts. ----------------------------------------------------------------------- Differences: -IPv6 is the next-generation IP protocol. The IPv6 working group exists +IPv6 is the next generation IP protocol. The IPv6 working group exists De-hyphenating. Or dehyphenating, if you prefer. ;) -* Discussing operational issues +* Discussing and fixing operational issues I don't see any harm in mentioning that we'll try to fix operational issues in addition to discussing them. -The working group will co-operate within the networking industry and -without, to share resources and combine efforts. +The working group will cooperate with operators and others, both +inside and outside the networking industry, to share resources and +combine efforts. More hyphen fixups. Clarifying that the "networking industry" does not just mean operators. Remove the clumsy "within/without" text that apparently only made sense to me. -- Shane

9 8

RE: [address-policy-wg] IPv6 allocations for 6RD
by Remco van Mook 27 Nov '09

27 Nov '09

Michael key words here are 'average' and 'generous'. Perhaps you should try to read first. Same goes for your statement of counting addresses. In cases like these, I think orders of magnitude are more interesting than narrowly defined numbers. 4 million is roughly 0.1% of the IPv4 pool. Since I think the AVERAGE ISP is probably smaller than that (either in customer count or allocated space), giving all of them 32 bits (or the full IPv4 space) PLUS 4-8 bits of network space (not host space!) for their 6rd plan sounds wasteful to me. The 6rd draft has prefix compression for a reason. Sparse number spaces for expansion and automation are fine. Very sparse number spaces you know from the outset will never be filled or usable for other purposes, are not. That is why deploying multiple instances of 6rd in order to benefit from prefix compression to collapse that required number space without losing functionality sounds like the right direction for me. Remco (and if we decide that a /24 is a better standard to hand out to LIRs than a /32, I can predict today that somebody will come up with a very clever reason to say that /16s are probably even better. Repeat until bored - or out of space.) -----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of michael.dillon(a)bt.com Sent: vrijdag 27 november 2009 11:04 To: address-policy-wg(a)ripe.net; ipv6-wg(a)ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD > Fair enough, I'll bite. Given 2^32(or 4 billion) IPv4 > addresses, and say, 4 million IP's allocated to the average > ISP (I'm being generous > here) there's your 0.1%. The rest of the space will go unused > since we're using 32 bits to identify these sparse blocks in > the v4->v6 translation. Not counting customer /56s, 48s, /60s > or whatever. But customers, and /56s are the essential things to count. Again, you just throw in the number 4 million without explaining where it comes from. IPv4 ISPs come in all sizes with one /24 allocation and some with many allocations of sizes ranging from /17 to /12. Counting IP addresses in IPv6 makes no sense. The addressing hierarchy of IPv6 is designed to have large blocks of unused and unusable addresses. This is both to allow for expansion without changing the network architecture, and to allow for automated address assignment functions which rely on large sparse number spaces to avoid collisions. --Michael Dillon This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.

2 1

Proposal for new charter: Version 2
by Shane Kerr 24 Nov '09

24 Nov '09

All, I've tried to combine all of the input and comments and produce a version of the text which hopefully includes all suggestions. Hopefully it is not too long: ----------------------------------------------------------------------- IPv6 is the next-generation IP protocol. The IPv6 working group exists to promote IPv6 adoption. The working group activities may be anything useful in helping people to deploy IPv6, and to manage IPv4/IPv6 co-existence. These activities include: * Outreach * Education * Sharing deployment experiences * Discussing operational issues The working group will co-operate within the networking industry and without, to share resources and combine efforts. ----------------------------------------------------------------------- Changes: * The 2nd paragraph was updated as per Sander's input. * I took David's point and removed "co-operation" as a activity, since as he indicated it is quite vague without the explanation. Instead I added the sentence at the end there. The idea is to make sure that we note that we have a goal of not duplicating work, but rather use the good stuff that other IPv6 and non-IPv6 organizations have done. If this doesn't make sense in the charter, we can of course leave it out. * I added David's activity about sharing deployment experiences - it seems to make sense. * I added a slightly modified activity based on David's last new one. His was "propose solutions for operational issues". I would rather see this as a more general discussion of operational issues - presumably solutions will be proposed where appropriate. If we want to focus on solutions, then we can revert to David's idea about proposing solutions. I think we are very close, and hopefully people are happy with this one. I don't have any objection to further modifications, although I am looking forward to moving past the rechartering and getting to some planning of what to do with the new-found working group super-powers! :) -- Shane

13 14

Announcement: RIPE NCC Training Courses
by Training Mailbox 10 Nov '09

10 Nov '09

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List & Registration https://lirportal.ripe.net/lirportal/training/course-list.html If you have any questions, please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

1 0

Happy Birthday Internet !! The first Internet connection
by Marc Manthey 29 Oct '09

29 Oct '09

happy birthday to Charley Kline and Leonard Kleinrock, who made this possible "The first message over the internet was send 29 october 1969" http://macbroadcast.org/index.php?q=node/34 greetings marc -- Les enfants teribbles - research / deployment Marc Manthey- Vogelsangerstrasse 97 50823 Köln - Germany Geo: 50.945554, 6.920293 PGP/GnuPG: 0x1ac02f3296b12b4d Tel.:0049-221-29891489 Mobil:0049-1577-3329231 project : http://opencu.org.uk blog: http://macbroadcast.org Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months.

1 0

Proposal for new charter
by Shane Kerr 28 Oct '09

28 Oct '09

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

19 37

Publication of default assignment sizes for end-user network ?
by Marco Hogewoning 28 Oct '09

28 Oct '09

Fellow WG members, This is something that seems to be lingering around for some time now and from talking to various people seems that there is some basic need for a system for this. I understand the IPv6-WG may not be the correct place to solve the issue, however I do think this is a nice platform to try and see if we can work out what the actual need is for that and hopefully this can result in some draft proposal that can be taken to the appropriate working group or even to another body for the actual implementation. As per RIPE-481 section 5.5 there is no need to register assignments of a /48 or longer into the public RIR/NIR database, as long it's registered by the LIR and that data is accessible by the RIR. Now this does not forbid you to register individual assignments into the public database, but doing so poses various problems. Not only the sheer number of assignments can be a problem, but also keeping that registration up-to-date will have serious impact on your day to day operations and especially with residential users there might be privacy issues as well. From an IR perspective this all makes sense and seems like reasonable behavior and I'm not intending of changing this. From what I see in the emerging deployments is that there are quite some differences between various operators on what the default assignment size to end users is and even in the same operator the actual size assigned might vary in between the various products from anywhere between a /128 to establish a link up to the full /48 possible. Together with these emerging deployments and this is primarily focussed on eyeballs but it may also apply to hosting as well, there seems to become a need to establish things like GEO-IP services but also blacklists for, as an example, email. Within IPv4 these kind of services can pretty much be done with a resolution of the full 32 bits registering individual IP addresses and still end up with a manageable list. With IPv6 emerging this situation changes, as most as not all customers will receive at least a /64 it seems natural to do some form of aggregation and I already can think of 2 reasons why: - Doing it on the full /128 will have the risks the lists become too big and maintaining and distributing them becomes impossible - Within the /64 it's fairly easy to switch addresses or to simply select multiple, so for instance a virus can use an almost unlimited number of source addresses to do evil. Naturally this has already led to aggregation, people working on collecting this data and generating these blacklists and also get-up services have invented there own scheme, some of them register individual /64's, others seem to have or start using a model where presence of X numbers of individual /64 blocks will lead to automatic aggregation and the next 'natural' boundary for that is /48. This in itself can lead to issues for instance when you assign /56 to a customer premises and somebody decides to aggregate he may as well block 256 house holds and not the one doing evil. Now talking with people the problem seems big enough that it needs fixing, in fact we may as well fix it before it goes wrong. Now I realize there are various way how to attack this and various platforms or community bodies to address this. At this point in time the RIR seems a reasonable place and what I'm trying with this post is see if there is some consensus about the fact this is a problem worth fixing and hopefully together and as a WG we can generate some output by for instance writing a draft proposal and bring it to other working groups or standardization bodies. So about the solution, one of the things I'm thinking about is asking the database group to implement an additional and optional attribute for inet6num which can hold the standard assignment size used for this block. So for instance I can put an object there saying 2001:980:1000::/36 is used for residential DSL assignments and default assignment size is /48 and that 2001:980:2000::/36 is used for hosting purposes and assignment size is a /64. That way people can find out about and aggregate their lists or even abuse complaints according to boundaries set by the operator and they no longer have to guess and potentially harm themselves or other users because there educate guess was of by 8 bits. This is only one possible solution, I also heard a voice saying we could try and solve this in DNS and it might be taken to IETF others suggested that instead of the database this should be published as a machine parseable list on a static URL. Now I'm perfectly happy to write that proposal, in fact some of it is already done. So is this worth going after, did I miss something here, can you provide arguments supporting this or against this approach and what sort of solution would you like. Looking forward to your comments either on this list or privately, especially from people who are in the business of data collection/ publishing. While we work on the new charter let's together try and proof this WG still is capable of producing something usefull :) Grtx, Marco Hogewoning (Both operator and concerned citizen)

2 2

Re: Proposal for new charter
by Geert Jan de Groot 25 Oct '09

25 Oct '09

> The working group activities may be anything useful in helping people > deploy IPv6. These activities include: > * Outreach > * Co-operation > * Education I also would like to propose to add "handle early deployment experiences" or wording to that effect - as I reported yesterday, the PMTU-thing reported on the list during the RIPE meeting. We're at the beginning of large-scale deployment and I believe that we cannot accept the "if something doesn't work, just switch off the IPv6 stack" approach people currently have to take, and I have a few reasons to believe my problem is not unique. We're testing new technology, building a new network - making support work for large-scale consumer-grade deployment is one of the next challenges we face, I think. Geert Jan

6 5

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

19 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 08 Oct '09

08 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 10 Sep '09

10 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

Re: ipv6-wg digest, Vol 1 #413 - 3 msgs
by Turchanyi Geza 08 Sep '09

08 Sep '09

Hi, for your MPLS backbone you still could reserve a few IPv4 addresses to use. The first place where you won't have enough addresses will be at your costumer's side. (All ISP has more costumers than backbone routers) Do you know while the Broadband Forum has no clear ideas even now how to support IPv6? This is a bit more important question, I think... Best, Geza On 9/8/09, ipv6-wg-request(a)ripe.net <ipv6-wg-request(a)ripe.net> wrote: > Send ipv6-wg mailing list submissions to > ipv6-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/ipv6-wg > or, via email, send a message with subject or body 'help' to > ipv6-wg-request(a)ripe.net > > You can reach the person managing the list at > ipv6-wg-admin(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ipv6-wg digest..." > > > Today's Topics: > > 1. Re: Re: LDP over Ipv6 (Isacco Fontana) > 2. Re: Re: LDP over Ipv6 (Gert Doering) > 3. Re: Re: LDP over Ipv6 (Mark Tinka) > > --__--__-- > > Message: 1 > Date: Mon, 07 Sep 2009 17:36:13 +0200 > From: Isacco Fontana <isacco.fontana(a)trentinonetwork.it> > To: mtinka(a)globaltransit.net > CC: ipv6-wg(a)ripe.net > Subject: Re: [ipv6-wg] Re: LDP over Ipv6 > > This is a multi-part message in MIME format. > --------------010708050001040605090703 > Content-Type: text/plain; charset=ISO-8859-15; format=flowed > Content-Transfer-Encoding: quoted-printable > > Do you think we can start discussion with big vendors (Cisco/Juniper) ? > > Mark Tinka ha scritto: >> On Monday 07 September 2009 05:06:47 am Isacco Fontana=20 >> wrote: >> >> =20 >>> I think this (LPD over ipv6) is not a customer >>> (isp/carrier) demand but a real problem when RIRs stop to >>> allocate ipv4 addresses. How ISP/Carriers can build a new >>> mpls backbone If big vendor not support the IPv6 over >>> LDP and isp can't make request for new ipv4 blocks ? >>> =20 >> >> Given how much money vendors are making from MPLS, it might=20 >> be safe to say they'll have support for it when v4 runs out.=20 >> The only question is which customer will be big enough for=20 >> them to get it in there :-). >> >> My main concern is, given how much traffic is being carried=20 >> by MPLS today (for better or worse), the earlier vendors put=20 >> out native support for it in v6, the quicker bugs can be=20 >> worked out. Even if support became available today, I'd=20 >> probably feel safer not deploying it at least 3 releases=20 >> from when it's launched, looking at the current state of v6=20 >> debug (or lack thereof) for folk that have deployed it. >> >> Cheers, >> >> Mark. >> =20 > > > --=20 > > Ing. Isacco Fontana > > Trentino Network s.r.l. > A socio Unico > > Direzione Servizi > Responsabile Area Ingegneria di Rete > > Via Gilli, 2 - 38100 TRENTO > Tel (+39) 0461.020200 > Fax (+39) 0461.020201 > > -------------------------------------------------------------------------= > ------------------------------------------------------- > > Cap. Soc. sottoscritto =A4 7.573.248,00 i.v. - REG. IMP. C.F. e P. IVA 0= > 1904880224 E-mail: sede(a)trentinonetwork.it > Societ=E0 soggetta a direzione e controllo da parte della Provincia Auton= > oma di Trento. C.F. e P. IVA 00337460224 > > -------------------------------------------------------------------------= > ------------------------------------------------------- > > > --------------010708050001040605090703 > Content-Type: text/html; charset=ISO-8859-15 > Content-Transfer-Encoding: quoted-printable > > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > <html> > <head> > <meta content=3D"text/html;charset=3DISO-8859-15" > http-equiv=3D"Content-Type"> > </head> > <body bgcolor=3D"#ffffff" text=3D"#000000"> > Do you think we can start discussion with big vendors (Cisco/Juniper) ?<b= > r> > <br> > Mark Tinka ha scritto: > <blockquote cite=3D"mid:200909071256.17702.mtinka@globaltransit.net" > type=3D"cite"> > <pre wrap=3D"">On Monday 07 September 2009 05:06:47 am Isacco Fontana=20 > wrote: > > </pre> > <blockquote type=3D"cite"> > <pre wrap=3D"">I think this (LPD over ipv6) is not a customer > (isp/carrier) demand but a real problem when RIRs stop to > allocate ipv4 addresses. How ISP/Carriers can build a new > mpls backbone If big vendor not support the IPv6 over > LDP and isp can't make request for new ipv4 blocks ? > </pre> > </blockquote> > <pre wrap=3D""> > Given how much money vendors are making from MPLS, it might=20 > be safe to say they'll have support for it when v4 runs out.=20 > The only question is which customer will be big enough for=20 > them to get it in there :-). > > My main concern is, given how much traffic is being carried=20 > by MPLS today (for better or worse), the earlier vendors put=20 > out native support for it in v6, the quicker bugs can be=20 > worked out. Even if support became available today, I'd=20 > probably feel safer not deploying it at least 3 releases=20 > from when it's launched, looking at the current state of v6=20 > debug (or lack thereof) for folk that have deployed it. > > Cheers, > > Mark. > </pre> > </blockquote> > <br> > <br> > <pre class=3D"moz-signature" cols=3D"72">--=20 > > Ing. Isacco Fontana > > Trentino Network s.r.l. > A socio Unico > > Direzione Servizi > Responsabile Area Ingegneria di Rete > > Via Gilli, 2 - 38100 TRENTO > Tel (+39) 0461.020200 > Fax (+39) 0461.020201 > > -------------------------------------------------------------------------= > ------------------------------------------------------- > > Cap. Soc. sottoscritto =A4 7.573.248,00 i.v. - REG. IMP. C.F. e P. IVA 0= > 1904880224 E-mail: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:s= > ede(a)trentinonetwork.it">sede(a)trentinonetwork.it</a> > Societ=E0 soggetta a direzione e controllo da parte della Provincia Auton= > oma di Trento. C.F. e P. IVA 00337460224 > > -------------------------------------------------------------------------= > -------------------------------------------------------</pre> > </body> > </html> > > --------------010708050001040605090703-- > > > --__--__-- > > Message: 2 > Date: Mon, 7 Sep 2009 17:39:12 +0200 > From: Gert Doering <gert(a)space.net> > To: Isacco Fontana <isacco.fontana(a)trentinonetwork.it> > Cc: mtinka(a)globaltransit.net, ipv6-wg(a)ripe.net > Subject: Re: [ipv6-wg] Re: LDP over Ipv6 > > Hi, > > On Mon, Sep 07, 2009 at 05:36:13PM +0200, Isacco Fontana wrote: >> Do you think we can start discussion with big vendors (Cisco/Juniper) ? > > Of course. Go to your vendor, tell him "we are not going to buy your > gear if you are not shipping LDP-over-IPv6"! > > If you're waving with enough money, they might even listen. But as long > as everybody is just grumbling to himself, the vendors might truthfully > say "noone has asked yet". > > Gert > -- > Total number of prefixes smaller than registry allocations: 128645 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > > --__--__-- > > Message: 3 > From: Mark Tinka <mtinka(a)globaltransit.net> > Reply-To: mtinka(a)globaltransit.net > Organization: Global Transit International > To: Isacco Fontana <isacco.fontana(a)trentinonetwork.it> > Subject: Re: [ipv6-wg] Re: LDP over Ipv6 > Date: Tue, 8 Sep 2009 09:08:11 +0800 > Cc: ipv6-wg(a)ripe.net > > --nextPart1744977.BctdEMcGiX > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > On Monday 07 September 2009 11:36:13 pm Isacco Fontana=20 > wrote: > >> Do you think we can start discussion with big vendors >> (Cisco/Juniper) ? > > Gert is right, the more we "collectively" speak to our=20 > vendors, the quicker they will likely implement the=20 > technology (it's not new, it's already been documented). > > =46or instance, I've been pushing Cisco and Juniper for an=20 > MPLS control plane for v6 for nearly 2 years now, but this=20 > isn't enough. Vendors tend to listen if: > > a) there is a collective. > > or > > b) as Gert and myself have already mentioned, you're waving > wads of cash their way. > > Cheers, > > Mark. > > --nextPart1744977.BctdEMcGiX > Content-Type: application/pgp-signature; name=signature.asc > Content-Description: This is a digitally signed message part. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > > iQIcBAABAgAGBQJKpa57AAoJEGcZuYTeKm+GhrgQAKRZt6scEjKCuwXqcJizc4AX > bv5D27EYduzotX1POj1PM/VCQmt/PunMZJ9V0BIyYiNKu2k7tR+x7+Ki/kM0GrvZ > Bhj2vyXyXCOx41DFfL8Qrj3htJolNTj5cLbuxSq/F5NmgD2XsqxtbOd+orGLu4Ch > BzJG1/Rf+sotzobSVmrOB+47LCNrAbXYLH2MseFFw/JeMQUK+7XOX7gqx8V5qtjs > Sm8ovQEoYvguelW79mZxwH35SeGZO44m2SJnJxX8o21GG+jiN6PY1q3haJO10ycN > dg7ZKic2r9g9h40T6ajeCCI5zgGXRUzrXJ9eXCaAbaxJfuKt/dOzdYBDwCkldYmo > 9sFQKkNmTzV/4uPDlrxPPfLEtlQUdcXqQVdjeWqoGPOdrLCZlV+GrpjZKBB5Qm9H > pR7TnxP8e1YVk4s+SqCW0f09PRn0Z+LJOonYyRHN9266WduNRfMcm+MNomRkeIlN > fNl9aDAPer2tzrxbLTbUN+fPMNZJy32FwLuoumkQ80ts9q1/YVweb5pODPwlrBEk > 4lxQusghMw8Kx9CXk2TaZ9MzOFr7KXrOa+j6r+RBBjhIJDDrQcj96LVnBmfV4Mn2 > z1DuK4SzOF1NuCVgy3tJzSybYneJpf1bkB5gIL50nngBlnjV36CWSEyObjdxUE4n > dED+kJlqDSaPTMwobLp3 > =xvej > -----END PGP SIGNATURE----- > > --nextPart1744977.BctdEMcGiX-- > > > > > End of ipv6-wg Digest >

1 0

IPv6 Deployment Monitoring Survey Closed
by Paul Rendek 15 Jul '09

15 Jul '09

[Apologies for duplicates] Dear Colleagues, The IPv6 Deployment Monitoring Survey, conducted by TNO and GNKS Consult in cooperation with the RIPE NCC and sponsored by the European Commission, has now closed. More than 600 members of the RIPE community responded to the survey, which aims to collect data on the current and future use of IPv6 throughout the RIPE NCC service region. We wish to thank those from the community who took the time to complete the survey. The results of the IPv6 Deployment Monitoring Survey will be presented and discussed at RIPE 59 which takes place in Lisbon, Portugal from 5-9 October. More information and registration details are available at: http://ripe59.ripe.net/ The results of this survey will also be published on IPv6 Act Now website at: http://www.ipv6actnow.org If you have any questions about the survey or the results, please contact <ncc(a)ripe.net>. Regards, Paul Rendek Head of External Relations and Communications RIPE NCC

1 0

Mimimum allocation sizes
by Marco Hogewoning 11 Jul '09

11 Jul '09

Hi there, Quick question which google can't seem to find an answer, can anybody tell where I can find a list of IPv6 blocks managed by the different registries and what the minimum allocation size is. I'm specifically looking for those blocks which contain allocations smaller then a /32. I've traced down RIPE and ARIN, but the other three seem to be hard to find. TIA, MarcoH

7 7

IPv6 Deployment Monitoring Survey: Deadline Extended!
by Paul Rendek 06 Jul '09

06 Jul '09

[Apologies for duplicates] Dear Colleagues, The deadline for responding to the IPv6 Deployment Monitoring Survey has been extended to Friday, 10 July 2009. This survey is being conducted by TNO and GNKS Consult, working with the RIPE NCC and sponsored by the European Commission. The aim is to collect data on the current and future use of IPv6 throughout the RIPE NCC service region, and all members of the RIPE community are encouraged to participate. You can access the survey at: http://is-nri.com/take/?i=150597&h=1GwWe3dXXMcPrRrOw5s2yg The survey is composed of 16 questions and can be completed in 10-15 minutes. Results will be presented and discussed at RIPE 59 and published on IPv6 Act Now: http://ipv6actnow.org Please note that all data will be kept confidential at all times, and will only be disclosed on an aggregated level. For more information on the IPv6 Deployment Monitoring Survey, please see: http://www.ripe.net/news/ipv6-deployment-monitoring-survey.html We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to <info(a)gnksconsult.com>. Regards, Paul Rendek Head of External Relations and Communications RIPE NCC

1 0

Last Call: IPv6 Working Group Minutes RIPE 58
by David Kessens 30 Jun '09

30 Jun '09

Hi, I just received the draft minutes of our working group session during RIPE 58. I would appreciate if you could take a look at them. Please send requests for correction directly to me and Susannah and we will make sure they will get included in the final version. The minutes will be declared final by Friday July 10 if no comments are received that require another last call. A big thanks to Vesna for the detailed and high quality minutes! David Kessens --- IPv6 Working Group Minutes, RIPE58 Date: Tue, May 5, 2009, 16:00-18:00 Chair: David Kessens <david.kessens(a)nsn.com> Minutes: Vesna Manojlovic, RIPE NCC Jabber monitor: Fergal Cunningham, RIPE NCC Transcript available at: http://ripe.net/ripe/meetings/ripe-58/steno-transcripts.php?steno=Main-0905… Webcast available at: rtsp://qtstreamer.ripe.net/ripe-58/ipv6-wg.mov A. Administrative Stuff David Kessens (WG chair) went through the agenda: http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2009/msg00009.html B. Developments/Initiatives Regarding IPv6 in the RIPE Region and Beyond B1: IPv6 peering BoF Paul Hoogsteder, Breedband Delft (community network) Paul announced that an informal session between old and new IPv6 peers would take place on Wednesday, 16:00 near the cloakroom. B2: Rumy Kanis, RIPE NCC, Training manager Rumy made a brief announcement that the RIPE NCC Training Department is busy recording testimonials from people in the community who have hands-on experience deploying IPv6. She asked if anyone is interested in being filmed and interviewed about their experiences with IPv6, they should contact training(a)ripe.net C. RIPE NCC IPv6 update http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/er-ipv6-rip… Erik Romijn, Information Services Erik announced that all of the RIPE NCC's external services have been available over IPv6 since January 2009. Lorenzo Colitti (Google) mentioned that one service does not support IPv6 - the socks proxy. It's internal only though. Erik said that he was only referring to public services. Patrik Falstrom asked if ROSIE (the RIPE Meeting website) counts as a non-external service? Erik responded that all ROSIE content can be accessed over IPv6 through the www.ripe.net web page, so you can actually see everything on ROSIE without having IPv4. Mohsen Souissi, AFNIC, asked how do you think you can motivate the operators managing the reverse delegations for IPv6 to get the transfer active for you so that your Hostcount++ will work in IPv6? Do you have any strategy to get it better than zero? Erik said that the first step is to get a zone transfer from a TLD. Mohsen said that the first step is reverse delegation. Andrei Robachevski, RIPE NCC, said that, for IPv6, we do not reverse DNS. We have to do this for IPv4. Because we can't transfer all the forward zones, we are just numerating all reverse zones. We can't do the same for IPv6 because IPv6 reverse DNS is big and sparse. So, the real problem here is that we have difficulty in actually transferring forward zones and therefore, we have difficulty counting IPv6 addresses there. He continued that the RIPE NCC's strategy is to convince operators to open the Access Control Lists (ACLs) for RIPE NCC IP addresses the zones can be transferred. For those operators who have some privacy issues or other considerations, we have developed a do-it-yourself kit to give to ccTLD operators. This software will count the hosts, anonymise the data and ship data back to us. An attendee asked that, since this is related to forward DNS, do you think it's a good idea to contact ccTLDs? Andrei responded that the RIPE NCC is using this idea but it's not 100% successful. David Kessens asked if there was an explanation for the huge number AAAA requests? Anand Buddhdev (RIPE NCC). Those quad-A queries are anomalous. They originate from broken versions of BIND. We suspect somebody is abusing them to send queries to the root. Gert Doering asked what about the RIPE NCC's internal network and the workstations? Macs are v6 capable. Are you keeping it on, between people working there and your internal services, or are you afraid of that? Erik said that on the RIPE NCC's wireless network, IPv6 is switched on and there are no problems. Gert said that that was his experience too: it just works. D. Google IPv6 update Lorenzo Colitti, Google Lorenzo explained that public IPv4 address space is going to go away. There is a business case for IPv6 because the alternatives are expensive. There is also an opportunity here - there is going to be a large pool of devices that will only be accessible and able to access using IPv6. If you are a content provider, then you might want to talk to them which means you need to have IPv6. It took google about a year-and-a-half to go from zero to being able to serve most services over IPv6. And we keep adding new ones. And with a very, very small team - just a handful of people. He continued, saying that if you are an exchange point operator or if you are an ISP, please do not charge separately for IPv6. Please absorb this cost in other ways because charging separately will hinder adoption and users and traffic can appear overnight. Extra data - measuring IPv6 query requests over IPv6: 0.25% of the total is over IPv6. 0.10% is over native, or not tunneled, IPv6. 2/3 is the proportion of requests that we serve as Google over IPv6. So two thirds of native IPv6 Internet appears to be enrolled in "Google over IPv6" program. Mat Ford (ISOC) commented that the "Google over IPv6 program" does not scale. He asked at which number of your users who would be affected by not being able to reach www.google.com over IPv6 do you say "I don't care"? Lorenzo answered that he did not don't but the magic number seems to be 10%. It depends on how situation evolves. We need to see better data on the "brokeness". It's hard to measure. Kostas Zorbadelos (OTC Greece) asked do you use the same load-balancing mechanism in IPv6 for IPv4. Lorenzo answered that Google tries to use the same infrastructure for both IPv4 & IPv6. The load-balancers are the same. Deploying separate hardware for IPv6 is not a good idea. Jasper Wonnink (fix6.net, via Jabber)asked when will the Google bot start crawling over IPv6? When there is AAAA available? Lorenzo stated that Google is working on this. CK Claffy said that he objected to Lorenzo's statement "Just because we can't see the traffic, that doesn't mean that IPv6 is not really happening". As a scientist, the traffic is the only measure that IPv6 is really being used. He said he knows how hard it is to measure the traffic and to get the traffic numbers but we should not be believing PowerPoint slides. This has has led us into a global telecommunications crisis, because we believed in numbers like "traffic is doubling every 90 days". That's a global example of how important is it to get traffic numbers, and what happens if you don't. He continued that the EU is going to conduct a survey. He said he wanted to make it clear that a survey is a substitute for the truth. It's not actual data. Lorenzo responded that CK was correct. He said that what he meant was do not expect smooth growth of IPv6 traffic. We are moving traffic from IPv4 to IPv6 because the user stacks, all else being equal, will prefer IPv6 to IPv4. KC said that he thought it would be good if Lorenzo's graph about IPv6 traffic had a Y axis with numbers and labels so that I could tell it wasn't going from 0 to 0.002. Lorenzo noted this. Gil Mason (Altna, via Jabber) asked how Google defines production quality? When is a network good enough to to be allowed to connect to Google over IPv6? Lorenzo responded that when we have a good connectivity and when the network is well supported. We like to see that the infrastructure is common, so that we don't get IPv6-specific failures. Randy Bush (IIJ) said that measurable spikes can be seen, as large customers change something - the way DNS resolves, client roll-outs, gateway services etc. He continued that it depends on what kind of electronic microscope you are using. There's very little traffic. Google's measurements are as useful as any other I've seen. Lorenzo said that 0.2% is coming over IPv6. There are daily patterns, not only spikes. KC added that there are no *numbers* in this data. we need to acknowledge what is the limitation of the data we are making available and what data we would need to answer the question for real. Lorenzo answered that client penetration is also a reasonable measure, or at least a measure we want to track. Mohsen Souissi said congratulations but the presentation is not serving the community because, if taken out of context, it does not make clear that this is just one of the measurements tools, and that you do not see all the traffic, nor other servers that get deployed every day. Lorenzo: These numbers only reflect IPv6 clients connected to our web site. Jasper asked if Google would roll out IPv6 for www.youtube and when? Lorenzo said that Google was working on all services but there are limitations in the hardware developer's time. It will come at some point. E. 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) Martin J. Levy,n Hurricane Electric http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/hurricane-6… Martin explained that real traffic numbers are available in my slides from the Google IPv6 conference. He continued that in his network, they do not have the same customer base on IPv4 and IPv6. Our stats about IPv6 can not be compared with IPv4. I want to show 6to4 and Teredo traffic. 6to4 is not a bad protocol. Teredo is a horrible protocol. On our backbone, we introduced several 6to4 relays, and localizing traffic made a big difference. It peaks at 20 Megabit. On Teredo, we were seeing hundreds of megs of Teredo traffic moving around. We deployed a Teredo service over the whole network, from 3 to 13, geographically dispersed. We were peaking around 150 megabits. Now we have 200-300 Megs of predominantly end user to end user traffic. The easiest way to get rid of the Teredo, is to enable IPv6. It may be a great measure of how many people want to access v6 but don't have it. An attendee asked how can we get rid of the horrible Teredo protocol? Martin answered that running stable relays will get us though this transition period. Randy Bush (IJJ) said that the optimist thinks the glass is half full; the pessimist thinks the glass is half empty. The engineer knows the glass is too big. Martin answered the majority. We had to run 6to4 on every Teredo relay, on the same box, or next to each other. An attendee commented that he does that with a dedicated connection between them. F. Global IPv6 routing table status http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/v6-routing-… Gert Doering Gert gave the routing table report. He asked are we growing fast enough? and said no, we are not. David Kessens said that the advantage is that we have time to talk about that issue at the next meeting. H. Overview of ISOC's current activity with regard to IPv6 deployment http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/isoc-ipv6.p… Matt Ford, ISOC I. Proposed EU IPv6 survey http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/proposed-eu… Maarten Botterman GNKS Consult Maarten explained that there was a commitment from the government to help make this happen, but for them to know what to do, they need to know where they can help the best. He said that the European Commission has contracted TNO to carry out deployment monitoring activity. There will be a survey conducted in June. He said that a draft survey is available for feedback. The results on an aggregate level will be public, and will be used for information to the European Commission on their policy preparation. Please contact maarten @ gnksconsult.com for more information. Mohsen Souissi (AFNIC) asked if there is any initiative to harmonise all those various measurements to have common understanding about what do we measure, what the methodology is etc? The tool was published at the last RIPE meeting. There may be many others. I feel frustrated, because there is no overall picture about who measures what. Maarten agreed. Leo Vegoda (ICANN) asked if Maarten meant RIPE NCC members only, or the 15,000 other organisations that have resources from RIPE NCC, but are not members? Maarten responded that he also meant non-members; anyone in the RIPE community. Leo said the RIPE Community are not the only people who are operating networks in Europe. Will you take a list from ARIN too? Maarten said no, the scope of this survey is limited. David Kessens made a few final comments: we are an operators' group, a technical forum, but it's also important to make sure that policy makers, decision makers and governments are well informed about the challenges that we are going to face in the next few years regarding this IPv4 exhaustion. He added that this is one of those projects that can contribute tremendously there, because it's basically an interface between those two worlds. So, I would very much like to encourage people to fill out the survey. -------------------------

1 0

IPv6 Deployment Monitoring Survey Reminder
by Paul Rendek 30 Jun '09

30 Jun '09

[Apologies for duplicates] Dear Colleagues, This is a reminder that the IPv6 Deployment Monitoring Survey is online, and we encourage all members of the RIPE community to participate. The final date for submitting a response is Friday, 3 July 2009. You can access the survey at: http://is-nri.com/take/?i=150597&h=1GwWe3dXXMcPrRrOw5s2yg The survey is being conducted by TNO and GNKS Consult, working with the RIPE NCC and sponsored by the European Commission. The aim of the survey is to collect data on the current and future use of IPv6 throughout the RIPE NCC service region. The survey is composed of 16 questions and can be completed in 10-15 minutes. Results will be presented and discussed at RIPE 59 and published on IPv6 Act Now: http://ipv6actnow.org For more information on the IPv6 Deployment Monitoring Survey, please see: http://www.ripe.net/news/ipv6-deployment-monitoring-survey.html We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to <info(a)gnksconsult.com >. Regards, Paul Rendek Head of External Relations and Communications RIPE NCC

1 0

IPv6 Deployment Monitoring Survey Now Underway!
by Paul Rendek 19 Jun '09

19 Jun '09

[Apologies for duplicates] Dear Colleagues, As announced at RIPE 58, TNO and GNKS Consult are working with the RIPE NCC to conduct a survey, sponsored by the European Commission, on the current and future use of IPv6 throughout the RIPE NCC service region. The IPv6 Deployment Monitoring Survey is now online, and we encourage all members of the RIPE community to participate: http://is-nri.com/take/?i=150597&h=1GwWe3dXXMcPrRrOw5s2yg The purpose of the survey is to better understand where the community is moving, and what can be done to ensure the Internet community is ready for the widespread adoption of IPv6. The survey was developed in consultation with members of the RIPE community, and is inspired by the 2008 survey conducted by ARIN and CAIDA in North America. It is sponsored by the European Commission, which has actively supported the adoption of IPv6, in the interests of innovation and the continuing competitiveness of European industry. We encourage all organisations in the RIPE NCC service region to participate in this survey, which we hope will establish a comprehensive view of present IPv6 penetration and future plans for IPv6 deployment. By making the survey design similar to the ARIN/CAIDA survey, we hope that the results will contribute to a better global picture of current and future IPv6 deployment. The survey is composed of 16 questions and can be completed in 10-15 minutes. For those without IPv6 allocations or assignments, or who have not yet deployed IPv6, the questions will be fewer in number. The survey will close on 3 July 2009. Results of the IPv6 Deployment Monitoring Survey will be presented and discussed at RIPE 59, which will be held 5-9 October in Lisbon, Portugal. Results will also be published on IPv6 Act Now: http://ipv6actnow.org Please provide your name and contact information on the survey form if you wish to receive the draft survey analysis when available. Please also indicate whether you are willing to share additional data with the TNO and GNKS Consult IPv6 Deployment Monitoring team. We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to <info(a)gnksconsult.com >. Regards, Paul Rendek Head of External Relations and Communications RIPE NCC

5 5

IPv6 testimonial with Randy Bush
by Rumy Kanis 15 Jun '09

15 Jun '09

Dear colleagues, As part of our IPv6 training project, that consists of face to face training and on-line learning modules and testimonials, we are proud to announce the next in our series of interviews. Randy Bush from IIJ discusses IPv6 deployment: http://www.youtube.com/watch?v=Qh3i6lDqWBM&feature=channel So far, we have interviewed 22 people from the community about their experiences and are very busy editing all the video material. In the coming months, you will be able to enjoy the rest of the interviews here: http://www.youtube.com/user/RIPENCC These interviews will also be published on our e-learning page and on our IPv6 Act Now website: http://ripe.net/training/e-learning/ http://www.ipv6actnow.org/ Kind regards, Rumy Kanis Training Manager RIPE NCC

1 0

IPv6 testimonial with Andy Davidson
by Rumy Kanis 28 May '09

28 May '09

Dear colleagues, As part of our IPv6 training project, that consists of face to face training and on-line learning modules and testimonials, I am proud to announce the first in a series of interviews. Andy Davidson of NetSumo ISP Consultancy discusses the IPv6 deployment they have done for their customers and themselves: http://www.youtube.com/watch?v=QCcigLJJbvU So far, we have interviewed 22 people from the community about their experiences and are very busy editing all the video material. In the coming months, you will be able to enjoy the rest of the interviews here: http://www.youtube.com/user/RIPENCC These interviews will also be published on our e-learning page and on our IPv6 Act Now website: http://ripe.net/training/e-learning/ http://www.ipv6actnow.org/ Kind regards, Rumy Kanis Training Manager RIPE NCC

1 0

Website Launch: www.IPv6ActNow.org
by Paul Rendek 26 May '09

26 May '09

[Apologies for duplicate emails.] Dear Colleagues, The RIPE NCC is pleased to announce the launch of the IPv6 Act Now! website. www.IPv6ActNow.org is a one stop website that explains IPv6 in terms that everyone can understand and provides a variety of useful information aimed at promoting the global adoption of IPv6. The site is for anyone with an interest in IPv6, including network engineers, company directors, law enforcement agencies, government representatives and civil society. The site content is regularly updated and includes: - Education, advice and opinions from the experts - Latest IPv6-related news stories - Videos and articles from Internet community leaders - Current IPv4 exhaustion and IPv6 uptake statistics - The RIPE community's statement on IPv6 deployment, including a list of organisations supporting this statement - Information on community-developed IPv6 distribution policies - Useful links to other sources of information about IPv6 - A forum for everyone to share experiences, ask questions and find answers The site also includes contributions from other Regional Internet Registries (RIRs) and industry partners. We invite you to take a look around the site. We hope that you find it useful. If you have and comments or suggestions about IPv6ActNow!, please contact us at <ipv6actnow(a)ripe.net>. Regards, Paul Rendek Head of External Relations and Communication RIPE NCC

12 19

Agenda for ipv6 wg RIPE58
by David Kessens 05 May '09

05 May '09

Please see below for our agenda. During the next RIPE meeting, our working group is scheduled to meet: Tue, May 5, 2009, 16:00-18:00 in the Krasnapolsky Hotel in Amsterdam. See you later today! David Kessens --- Agenda for the IPv6 Working Group Meeting RIPE58 When: Tue, May 5, 2009, 16:00-18:00 Where: Krasnapolsky Hotel in Amsterdam A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) - Paul Hoogsteder, IPv6 peering BoF C. RIPE NCC IPv6 update diving a bit more into things outside of the NCC network itself, but also some of the measurements we have from our services (Erik Romijn) D. Google IPv6 update (Lorenzo Colitti) E. 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) - Martin J. Levy F. Global IPv6 routing table status (Gert Doering) G. Discussion: deaggration of /32 prefixes, recent discussion on address policy working group The RIPE IPv6 allocation policy says in section '5. Policies for Allocations and Assignments': "b) advertise the allocation that they will receive as a single prefix if the prefix is to be used on the Internet" (input from the audience, input to address policy working group) H. Overview of ISOC's current activity with regard to IPv6 deployment. (Matthew Ford) I. Proposed EU IPv6 survey (Maarten Botterman, GNKS Consult) ... Y. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

1 0

Draft agenda (v1) for ipv6 wg RIPE58
by David Kessens 28 Apr '09

28 Apr '09

During the next RIPE meeting, our working group is scheduled to meet: Tue, May 5, 2009, 16:00-18:00 in the Krasnapolsky Hotel in Amsterdam. I have prepared a first draft version of the agenda. As usual, there will be quite a bit of attention to IPv6 in the plenary sessions as well and the talks about IPv6 DSL deployments should be especially interesting. David Kessens --- Draft Agenda (v1) for the IPv6 Working Group Meeting RIPE58 When: Tue, May 5, 2009, 16:00-18:00 Where: Krasnapolsky Hotel in Amsterdam A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. RIPE NCC IPv6 update diving a bit more into things outside of the NCC network itself, but also some of the measurements we have from our services (Erik Romijn) C. Google IPv6 update (Lorenzo Colitti) 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. Global IPv6 routing table status (Gert Doering) F. Discussion: deaggration of /32 prefixes, recent discussion on address policy working group (input from the audience, input to address policy working group) G. Overview of ISOC's current activity with regard to IPv6 deployment. (Matthew Ford) H. Proposed EU IPv6 survey (speaker to be determined, TNO) I. 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 topics RIPE 58
by David Kessens 15 Apr '09

15 Apr '09

The next RIPE meeting, RIPE 58, is fast approaching. This means that it is getting time to compose an agenda for our working group that is scheduled to meet on Tuesday, May 5, 2009, 16:00-18:00 in the Krasnapolsky Hotel in Amsterdam. Please let me know if you have any suggestions for agenda topics: very brief or longer topics, offers for a presentation or just a suggestion for a discussion topic are all welcome as long as they are interesting technical topics that will help with the deployment of IPv6 in the RIPE region. Thanks, David Kessens ---

1 0

IPv6 questions regarding ripe and address ranges
by Peeters, Ralph 17 Mar '09

17 Mar '09

Hello, My name is Ralph and i'm researching the options for IPv6 within my company. From previous contact with the ripe i've understood that there are 3 ways to get IPv6 ranges: - ISP assigned, i don't like this option because of renumbering issues when transferring to a different ISP - Ripe member, this way my organisation will become a member and can request own adresses based upon need - PI assigned, coming (hopefully) this year My company has several locations on several continents, which raises the following questions: -If we would become a ripe member, how would we deal with IPv6 range requests outside the ripe "juristiction", like in north america? -It is my understanding that the ripe member policy assigns /32sh and no /48sh which, from my standpoint, seems a bit unnecessary because there will be equal number of routing entries because we will require one range per location no matter the prefix. From what i've learned so far this could basically result in a /32 for a 100-user location which cannot be the goal, even though i might be stuck in IPv4 ways. - Isn't it possible to get a /32 and allow us to divide it between our sites with /48sh (and allowing them to advertise /48sh globally)? Sincerely, Ralph Peeters This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

4 5

2008 IPv4 Address Use Report
by Iljitsch van Beijnum 01 Jan '09

01 Jan '09

[ (Non-cross)posted to IETF discussions, NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. Web version for the monospace font impaired and with some links: http://www.bgpexpert.com/addrspace2008.php ] 2008 IPv4 Address Use Report As of January first, 2009, the number of unused IPv4 addresses is 925.58 million. On January 1, 2008, it was 1122.85 million. So in 2008, 197.27 million addresses were used up. With 3706.65 million usable addresses, this means that 75.3% of the available IPv4 addresses are in some kind of use, up from 69.7% a year ago. So the depletion of the IPv4 address reserves is continuing in much the same way as in previous years: Date Addresses free Used up 2006-01-01 1468.61 M 2007-01-01 1300.65 M 167.96 M 2008-01-01 1122.85 M 177.80 M (with return of 16.78 M to IANA) 2009-01-01 925.58 M 197.27 M These figures are derived from from the Internet Assigned Numbers Authority's IPv4 Global Unicast Address Assignments page and 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). The IANA list shows the status of all 256 blocks of 16777216 addresses identified by the first 8-bit number in the IPv4 address. (Note that the file is in a somewhat different format than in previous years.) The RIR data indicates how much address space the RIRs have delegated to internet service providers (and sometimes end-users). Delegated Blocks +/- 2008 Addresses Used Available to/status (in millions) AfriNIC 2 33.55 9.18 24.37 APNIC 30 +4 503.32 454.36 48.96 ARIN 31 +4 520.09 446.06 74.03 LACNIC 6 100.66 68.88 31.78 RIPE NCC 26 436.21 423.65 12.56 LEGACY 92 +1 1543.50 1363.29 180.21 UNALLOCATED 34 -9 570.43 570.43 Totals 221 3707.76 2765.42 942.34 The difference between the 942.34 million free addresses here and 925.58 million earlier is explained by the fact that the 43.0.0.0/8 legacy block shows up as delegated in the IANA list, but not in the APNIC delegation records. In previous years, 7.0.0.0/8 didn't show up in the IANA records but it did in the ARIN records. This has now been fixed, hence the increase in legacy delegations. No legacy blocks were returned to IANA in 2008. The total number of available addresses is slightly higher than the previously mentioned figure at 3707.76 million because the table above includes 172.16.0.0/12 and 192.168.0.0/16, which are set aside for private use. Networks 0.0.0.0/8 and 127.0.0.0/8 aren't usable because of special uses and 10.0.0.0/8 is also set aside for private use. 224 - 239 are multicast addresses, and 240 - 255 is class E, which is "reserved" for future use. If the class E space could be used, it would increase the available address space by 268 million addresses. The past two years, this has been a topic of hot debate in the IETF and elsewhere. The problem is that almost all operating systems need modification to be able to use class E addresses, and a good part of the installed base of devices connected to the internet must be considered unupgradable. The 2781.07 million addresses currently in use aren't very evenly distributed over the countries in the world. The current top 15 is: 2009-01-01 2008-01-01 increase Country 1 - US 1458.21 M 1408.15 M 4% United States 2 (3) CN 181.80 M 135.31 M 34% China 3 (2) JP 151.56 M 141.47 M 7% Japan 4 - EU 120.29 M 120.35 M 0% Multi-country in Europe 5 - GB 86.31 M 83.50 M 3% United Kingdom 6 (7) DE 81.75 M 72.46 M 13% Germany 7 (6) CA 74.49 M 73.20 M 2% Canada 8 - FR 68.04 M 67.79 M 0% France 9 - KR 66.82 M 58.86 M 14% Korea 10 - AU 36.26 M 33.43 M 8% Australia 11 (12) BR 29.75 M 23.46 M 27% Brazil 12 (11) IT 29.64 M 24.04 M 23% Italy 13 (16) TW 24.01 M 19.83 M 21% Taiwan 14 (18) RU 23.18 M 17.01 M 36% Russia 15 (14) ES 21.67 M 20.42 M 6% Spain In 2008, the United States was again the biggest user of new address space with no less than 50 million addresses added to the 1.4 billion they already had at the beginning of the year. China is a close second with 46.50 million new addresses. There is no clear trend in the growth percentages. A few countries like France and the UK show very modest growth, while other countries with a large installed base like Germany and Korea saw double digit growth percentages. And in addition to China, Brazil, Taiwan and Russia, but also Italy, are catching up. The US now holds 52.4% of the IPv4 address space in use. The total for the top 15 excluding the US is 35.8%. The rest of the world gets the remaining 327.23 million addresses, or 11.8%. 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). 2002 2003 2004 2005 2006 2007 2008 < 1000 547 745 1022 1309 1507 1830 1896 1000 - 8000 897 1009 1516 1891 2265 2839 3235 8000 - 64k 822 1014 1100 1039 1192 1015 1129 64k - 500k 163 215 404 309 419 395 410 500k - 2M 29 46 61 60 57 62 82 > 2M 5 6 7 18 17 24 18 In millions of addresses: 2002 2003 2004 2005 2006 2007 2008 < 1000 0.18 0.25 0.35 0.44 0.51 0.63 0.65 1000 - 8000 3.23 3.45 4.49 5.07 5.83 6.93 7.75 8000 - 64k 11.35 14.00 15.99 15.46 18.01 15.67 17.40 64k - 500k 20.28 25.51 42.01 34.23 50.86 50.83 52.58 500k - 2M 21.30 31.98 44.63 41.63 46.69 45.50 57.41 > 2M 12.58 12.58 20.97 68.62 52.43 67.37 54.00 The growth in the smallest and largest categories has been curtailed, but this growth now seems to happen in the second smallest and second largest categories, so the total effect isn't all that different, as indicated by the number of addresses given out per request/delegation: 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 2008 6770 189.79 28035 (The numbers of addresses given out are lower here because ARIN often attributes the delegation of new addresses to a previous year, this view doesn't correct for that.)

1 0

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