- ipv6-wg - mailman.ripe.net

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