From nominations at ripe.net Tue Oct 2 11:30:20 2007 From: nominations at ripe.net (Paul Rendek) Date: Tue, 02 Oct 2007 11:30:20 +0200 Subject: [address-policy-wg] Reminder: ASO Address Council Nominations Message-ID: <47020FAC.5050009@ripe.net> [Apologies for duplicate e-mails.] Dear Colleagues, The 2007 nominations for representatives to the ASO Address Council (RIPE NCC service region) period is now open. The term of Hans Petter Holen, who has served as an Address Council (AC) member for the past three years, will expire on 31 December 2007. One individual from the RIPE NCC service region will be selected to serve on the ASO AC for a term of three years. The elections will take place during the the RIPE Address Policy Working Group session at the RIPE 55 Meeting, held in Amsterdam on 22 - 26 October. Any individual may be nominated, with the exception of staff members of any Regional Internet Registry (RIR). Self-nominations are permitted. How to Nominate ------------------------ For information on how to nominate a candidate, how to send expressions of support and the election process, please see: http://www.ripe.net/info/resource-admin/aso2007/index.html The list of nominated candidates can be found at: http://www.ripe.net/info/resource-admin/aso2007/nominations.html Important Dates -------------------- 19 September: Nomination period opens 15 October: Nomination period closes 15 October: Complete nominations list posted 25 October: Elections take place during the RIPE Address Policy Working Group session at RIPE 55 More Information ----------------------- Information about the RIPE 55 Meeting can be found at: http://www.ripe.net/ripe/meetings/ripe-55/index.html Regards, Paul Rendek Head of External Relations & Communications RIPE NCC From raul at lacnic.net Tue Oct 9 15:21:04 2007 From: raul at lacnic.net (Raul Echeberria) Date: Tue, 09 Oct 2007 10:21:04 -0300 Subject: [address-policy-wg] Proposal for the creation of a working group. Message-ID: <7.0.1.0.1.20071009101848.04568c18@lacnic.net> Dear all: I would like to share with all of you this proposal. Since it is not a policy proposal, I don't know really how to proceed, but I guess that it is enough to send it to the list. I have submitted this proposal to the ARIN Policy list and I will do the same with the other RIRs' poilicy lists. I would appreciate suggestions about how to deal with this idea if it sound interesting. Ra?l ========================================== Proposal for the creation of a cross-regions working group Some proposals have been submitted through some RIR?s policy development process, which focus on the gradual modification of the requirements for receiving IPv4 addresses as the pool of unallocated IPv4 addresses diminishes. Most or all proposals which have been made appear to be incomplete and ineffective if approved in only one region. Therefore, it is proposed the creation of a working group made up by two appropriate respected individuals active in the policy process within each region?s community. These ten individuals would work on one or more joint proposals that could then be processed in every region according to their corresponding policy development processes. The objective of the working group would not be to produce proposals for global policies, but proposals to be sumbitted to every RIRs. The conclusion could be, of course, that the proposals should be different in each region. Since the proposal (if there are any) should go later through each Policy Development Process, there will not be any impact of this proposal in the independence of each region to adopt the poclicies that are considered more convenients. Naturally, the proposals that have already been presented in relation to this issue would be important input for this working group, one possible conclusion being that these proposals contain the best possible policies and should be presented. Without this level of coordination, it will be difficult to obtain proposals to be submitted for discussion in all regions with reasonable chances of success. One member of each RIRs staff would also participate in this working group, in the capacity of observers, so as to provide all the support, advice and information that the group deems necessary. IANA will also be invited to appoint up to two persons to the working group in the same condition of observers. The working schedule would be defined by the group itself, but it should be anticipated that the proposals, in case it is decided they are needed, be presented for their discussion as soon as possible. The following are some of the ideas that have already been presented either formally or informally and that will be available for the consideration of this working group (but not limited to) : ? Increasing the requirements for receiving additional allocations as IANA?s central pool of addresses diminishes. ? Adding to the current requirements the requirement to develop the availability of IPv6 infrastructure. ? Reducing the sizes of the blocks that are allocated as IANA?s central pool of addresses diminishes. ? Including within the gradual increase of restrictions the requirement that when one RIR runs out of addresses the others will automatically be moved to a more conservative phase in order to minimize RIR shopping. =============== From malcolm at linx.net Mon Oct 15 10:59:02 2007 From: malcolm at linx.net (Malcolm Hutty) Date: Mon, 15 Oct 2007 10:59:02 +0200 Subject: [address-policy-wg] RIPE Task Force on Enhanced Cooperation: Call For Volunteers In-Reply-To: <47020FAC.5050009@ripe.net> References: <47020FAC.5050009@ripe.net> Message-ID: <47132BD6.1060801@linx.net> [Apologies for duplicates] Dear Colleagues, At RIPE 54 in May 2007, it was decided to establish a "RIPE Task Force on Enhanced Cooperation". Information on this task force, including motivation, a draft charter and a working plan, is available now at: http://www.ripe.net/ripe/tf/enhanced-cooperation The following mailing list has been set up for the use of the task force: We are looking for volunteers to participate in the task force, and play an active role in achieving the goals set out in the draft charter. This invitation is open to all members of the RIPE community, and it is envisaged that the final task force will include up to 10 people. There will also be a brief presentation on the new task force at RIPE 55 in Amsterdam in October, during the Opening Plenary session. To volunteer, please go to: http://www.ripe.net/mailman/listinfo/ec-tf Anyone wishing to participate should nominate themselves by 9 November 2007. Kind regards, Malcolm Hutty, Chair, RIPE Task Force on Enhanced Cooperation From nominations at ripe.net Mon Oct 15 12:12:23 2007 From: nominations at ripe.net (Paul Rendek) Date: Mon, 15 Oct 2007 12:12:23 +0200 Subject: [address-policy-wg] Closing: ASO AC Elections Nomination Period Message-ID: <47133D07.3010804@ripe.net> [Apologies for duplicate e-mails.] Dear Colleagues, The Address Supporting Organization Address Council (ASO AC) nomination period closes today, 15 October 2007, at 23:00 UTC. One individual from the RIPE community will be selected to serve on the ASO AC for a term of three years. Any individual may be nominated, with the exception of staff members of any Regional Internet Registry (RIR). Self-nominations are permitted. Please note that the date of the elections has been moved. Elections will take place at the RIPE 55 Meeting during the 09:00 Plenary session on *Wednesday, 24 October*. Nominations ----------------- There is still time to nominate candidates and send expressions of support. Please see full details on how to nominate at: http://www.ripe.net/info/resource-admin/aso2007/index.html ASO AC ----------- More details about the ASO AC can be found at: http://aso.icann.org/ RIPE 55 ----------- For details about the RIPE Meeting, please see: http://www.ripe.net/ripe/meetings/ripe-55/index.html If you have any questions about this, please contact nominations at ripe.net. Kind regards, Paul Rendek Head of External Relations & Communication RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From filiz at ripe.net Mon Oct 15 15:44:29 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 15 Oct 2007 15:44:29 +0200 Subject: [address-policy-wg] 2007-07 New Policy Proposal (End Policy for IANA IPv4 Allocations to RIRs) Message-ID: <20071015134429.961AF2F583@herring.ripe.net> PDP Number: 2007-07 End Policy for IANA IPv4 Allocations to RIRs Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. This proposal seeks to provide the solutions to the problems in terms of address management which may arise if no measures are taken for IPv4 address exhaustion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-07.html We encourage you to review this proposal and send your comments to before 12 November 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Mon Oct 15 15:49:39 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 15 Oct 2007 15:49:39 +0200 Subject: [address-policy-wg] 2007-03 Policy Proposal Withdrawn (IPv4 Countdown Policy) Message-ID: <20071015134939.65F9F2F583@herring.ripe.net> PDP Number: 2007-03 IPv4 Countdown Policy Dear Colleagues The proposal 2007-03, IPv4 Countdown Policy has been withdrawn. Authors decided that they want to make a new proposal (see 2007-07, End Policy for IANA IPv4 Allocations to RIRs). You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-03.html Regards Filiz Yilmaz RIPE NCC Policy Development Officer From gert at space.net Tue Oct 16 14:50:51 2007 From: gert at space.net (Gert Doering) Date: Tue, 16 Oct 2007 14:50:51 +0200 Subject: [address-policy-wg] Re: 2nd DRAFT agenda for RIPE 55 APWG meeting In-Reply-To: <20070806142140.GY69215@Space.Net> References: <20070806142140.GY69215@Space.Net> Message-ID: <20071016125051.GA99808@Space.Net> Dear RIPE address policy WG members, since my first proposal, we have been working on the agenda, and here's the next draft for the APWG meeting agenda for the upcoming RIPE meeting (next week in Amsterdam). The main focus is "PI oriented discussions on Wednesday" and "End-of-IPv4 oriented discussions on Thursday". The other things take less space and are fit in between - and could be shuffled around if there are conflicts. Comments welcome, of course. ----------------------------- snip -------------------------------- Wednesday, October 24, 11:00-12:30: - formal stuff 5 min - overview of concluded proposals 15 min * 2006-02 (200-users) -> accepted/implemented * 2006-04 (contact e-mail) -> withdrawn * 2006-06 (IPv4 max. all.period) -> accepted/implemented * 2006-07 (IPv4 AW size) -> accepted/implemented * 2007-02 (anycast DNS) -> withdrawn * 2007-03 (IPv4 countdown policy) -> withdrawn * 2007-04 (ASN policy) -> accepted/at ASO AC - enough time for generic discussion on PI 55 min (IPv4, IPv6, contracts, maybe also covering AS numbers) * feedback from the RIPE NCC board regarding 2007-01 * proposals how to go ahead (Nick Hilliard / RIPE NCC) - Leo Vegoda: a proposal for restructuring of the IPv6 policy 15 min Thursday, October 25, 09:00-10:30: - discussion of all "other" currently-open proposals 15 min * 2005-08 (IPv6 allocation policy) -> problem statement, way ahead? * 2007-05 (ULA central) -> short update - "End of IPv4" session 60 min - 2007-06 (Global Policy for .. Remaining IPv4 ... Space) - 2007-07 (End Policy for IANA IPv4 Allocations...) - proposal from Remco van Mook - proposal from ETNO (presentation in the plenary session) - other new proposals that are not yet in the PDP 10 min - AOB 5 min ----------------------------- snip -------------------------------- Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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 From gert at space.net Tue Oct 16 16:07:23 2007 From: gert at space.net (Gert Doering) Date: Tue, 16 Oct 2007 16:07:23 +0200 Subject: [address-policy-wg] 3rd DRAFT agenda for RIPE 55 APWG meeting In-Reply-To: <20071016125051.GA99808@Space.Net> References: <20070806142140.GY69215@Space.Net> <20071016125051.GA99808@Space.Net> Message-ID: <20071016140723.GP69215@Space.Net> Hi, next round, I forgot a detail - in the "end of IPv4" session, we will have a discussion on whether "RIPE as a community" is willing to formulate an official statement regarding IPv4 depletion, and recommendations to move to IPv6 (as the other LIRs have done it). This was suggested by the NCC, because lots of people are asking for an official voice "from RIPE" and the NCC feels that this should come from the community. Thanks to Paul Rendek for reminding me. Gert Doering, APWG chair. ----------------------------- snip -------------------------------- Wednesday, October 24, 11:00-12:30: - formal stuff 5 min - overview of concluded proposals 15 min * 2006-02 (200-users) -> accepted/implemented * 2006-04 (contact e-mail) -> withdrawn * 2006-06 (IPv4 max. all.period) -> accepted/implemented * 2006-07 (IPv4 AW size) -> accepted/implemented * 2007-02 (anycast DNS) -> withdrawn * 2007-03 (IPv4 countdown policy) -> withdrawn * 2007-04 (ASN policy) -> accepted/at ASO AC - enough time for generic discussion on PI 55 min (IPv4, IPv6, contracts, maybe also covering AS numbers) * feedback from the RIPE NCC board regarding 2007-01 * proposals how to go ahead (Nick Hilliard / RIPE NCC) - Leo Vegoda: a proposal for restructuring of the IPv6 policy 15 min Thursday, October 25, 09:00-10:30: - discussion of all "other" currently-open proposals 15 min * 2005-08 (IPv6 allocation policy) -> problem statement, way ahead? * 2007-05 (ULA central) -> short update - "End of IPv4" session 60 min - 2007-06 (Global Policy for .. Remaining IPv4 ... Space) - 2007-07 (End Policy for IANA IPv4 Allocations...) - proposal from Remco van Mook - proposal from ETNO (presentation in the plenary session) - formulation of an official statement from the RIPE community regarding the end of IPv4, and recommendations for moving towards IPv6. - other new proposals that are not yet in the PDP 10 min - AOB 5 min ----------------------------- snip -------------------------------- Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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 From gert at space.net Wed Oct 17 17:28:54 2007 From: gert at space.net (Gert Doering) Date: Wed, 17 Oct 2007 17:28:54 +0200 Subject: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 Message-ID: <20071017152854.GY69215@Space.Net> Hello Address Policy Working Group, IPv6 Working Group, as announced yesterday on the APWG list, here's the first draft of the "we are going to tell the world what the RIPE community recommends regarding the end of IPv4 / advent of IPv6". The text has been drafted by the RIPE NCC, but the actual recommendation needs to come from "the community", so change whatever you think needs changing. Face-to-face discussion will take place in the APWG and IPv6 WG meeting on Thursday, October 25th. (Short discussion in APWG early morning, time to think about it during the day, final decision in the IPv6 WG meeting on Thursday afternoon). ----------------------- snip ----------------------- DRAFT - RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 RIPE 55: 22 - 26 October 2007 The RIPE community resolves as follows: 1) At current allocation rates, the remaining pool of unallocated IPv4 address space is likely to be allocated within the next two to four years. Although the Internet will continue to function as normal after this point this event will have a significant influence on future network operations as well as IP address management and allocation policies. Therefore we recognise that the widespread deployment of IPv6 will be essential to sustain future growth of the Internet. 2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6. 3) We recognise that the responsibility for creating policies related to the management of critical Internet resources in the RIPE NCC service region rests with the RIPE community and the proven success of the RIPE Policy Development Process (PDP). In recognition of this responsibility, we commit to continue development of effective policies for the responsible management of IPv4 and IPv6 address space. 4) We agree that this situation requires a committed effort from network operators, ISPs and the RIPE community. We urge that the widespread deployment of IPv6 be made a high priority. ----- End forwarded message ----- Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 122119 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 From jordi.palet at consulintel.es Wed Oct 17 18:15:38 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 17 Oct 2007 10:15:38 -0600 Subject: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <20071017152854.GY69215@Space.Net> Message-ID: Hi Gert, Some inputs below in-line. Regards, Jordi > De: Gert Doering > Responder a: > Fecha: Wed, 17 Oct 2007 17:28:54 +0200 > Para: , > Asunto: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion > and Deployment of IPv6 > > Hello Address Policy Working Group, IPv6 Working Group, > > as announced yesterday on the APWG list, here's the first draft of the > "we are going to tell the world what the RIPE community recommends > regarding the end of IPv4 / advent of IPv6". > > The text has been drafted by the RIPE NCC, but the actual recommendation > needs to come from "the community", so change whatever you think needs > changing. > > Face-to-face discussion will take place in the APWG and IPv6 WG meeting > on Thursday, October 25th. (Short discussion in APWG early morning, time > to think about it during the day, final decision in the IPv6 WG meeting on > Thursday afternoon). > > ----------------------- snip ----------------------- > > DRAFT - RIPE Community Resolution on IPv4 Depletion and > Deployment of IPv6 > RIPE 55: 22 - 26 October 2007 > > The RIPE community resolves as follows: > > 1) At current allocation rates, the remaining pool of unallocated > IPv4 address space is likely to be allocated within the next two > to four years. Although the Internet will continue to function as > normal after this point this event will have a significant ... as normal after this point, for those that already have been allocated/assigned IPv4 addresses, ... > influence on future network operations as well as IP address > management and allocation policies. Therefore we recognise that > the widespread deployment of IPv6 will be essential to sustain > future growth of the Internet. > > 2) We urge network operators and Internet Service Providers > (ISPs) to deploy IPv6 across their networks as soon as possible. ... possible, typically by means of incremental steps (depending on each network case, from the core to the access), ... > This deployment must include providing IPv6 access to End Users > and ensuring services are accessible by IPv6. > > 3) We recognise that the responsibility for creating policies > related to the management of critical Internet resources in the > RIPE NCC service region rests with the RIPE community and the > proven success of the RIPE Policy Development Process (PDP). In > recognition of this responsibility, we commit to continue > development of effective policies for the responsible management > of IPv4 and IPv6 address space. > > 4) We agree that this situation requires a committed effort from > network operators, ISPs and the RIPE community. We urge that the > widespread deployment of IPv6 be made a high priority. > > ----- End forwarded message ----- > > Gert Doering > -- APWG chair > -- > Total number of prefixes smaller than registry allocations: 122119 > > 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 > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From florian at frotzler.priv.at Wed Oct 17 17:39:40 2007 From: florian at frotzler.priv.at (Florian Frotzler) Date: Wed, 17 Oct 2007 17:39:40 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <20071017152854.GY69215@Space.Net> References: <20071017152854.GY69215@Space.Net> Message-ID: <001f01c810d3$eee02530$cca06f90$@priv.at> Hi, what about also urging the vendors to fully support IPv6 (like forwarding in hardware, increase functionality, you name it...)? Cheers, Florian -----Urspr?ngliche Nachricht----- Von: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] Im Auftrag von Gert Doering Gesendet: Mittwoch, 17. Oktober 2007 17:29 An: address-policy-wg at ripe.net; ipv6-wg at ripe.net Betreff: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 Hello Address Policy Working Group, IPv6 Working Group, as announced yesterday on the APWG list, here's the first draft of the "we are going to tell the world what the RIPE community recommends regarding the end of IPv4 / advent of IPv6". The text has been drafted by the RIPE NCC, but the actual recommendation needs to come from "the community", so change whatever you think needs changing. Face-to-face discussion will take place in the APWG and IPv6 WG meeting on Thursday, October 25th. (Short discussion in APWG early morning, time to think about it during the day, final decision in the IPv6 WG meeting on Thursday afternoon). ----------------------- snip ----------------------- DRAFT - RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 RIPE 55: 22 - 26 October 2007 The RIPE community resolves as follows: 1) At current allocation rates, the remaining pool of unallocated IPv4 address space is likely to be allocated within the next two to four years. Although the Internet will continue to function as normal after this point this event will have a significant influence on future network operations as well as IP address management and allocation policies. Therefore we recognise that the widespread deployment of IPv6 will be essential to sustain future growth of the Internet. 2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6. 3) We recognise that the responsibility for creating policies related to the management of critical Internet resources in the RIPE NCC service region rests with the RIPE community and the proven success of the RIPE Policy Development Process (PDP). In recognition of this responsibility, we commit to continue development of effective policies for the responsible management of IPv4 and IPv6 address space. 4) We agree that this situation requires a committed effort from network operators, ISPs and the RIPE community. We urge that the widespread deployment of IPv6 be made a high priority. ----- End forwarded message ----- Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 122119 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 From fw at deneb.enyo.de Thu Oct 18 10:57:34 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 18 Oct 2007 10:57:34 +0200 Subject: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <20071017152854.GY69215@Space.Net> (Gert Doering's message of "Wed, 17 Oct 2007 17:28:54 +0200") References: <20071017152854.GY69215@Space.Net> Message-ID: <87r6jsu7ep.fsf@mid.deneb.enyo.de> * Gert Doering: > 2) We urge network operators and Internet Service Providers > (ISPs) to deploy IPv6 across their networks as soon as possible. > This deployment must include providing IPv6 access to End Users > and ensuring services are accessible by IPv6. Shouldn't this paragraph target RIPE members specifically? Or, put differently, why are end users and software vendors excluded? From patrick at vande-walle.eu Thu Oct 18 11:26:09 2007 From: patrick at vande-walle.eu (Patrick Vande Walle) Date: Thu, 18 Oct 2007 11:26:09 +0200 Subject: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <87r6jsu7ep.fsf@mid.deneb.enyo.de> References: <20071017152854.GY69215@Space.Net> <87r6jsu7ep.fsf@mid.deneb.enyo.de> Message-ID: <471726B1.6040003@vande-walle.eu> Florian Weimer wrote: > * Gert Doering: > >> 2) We urge network operators and Internet Service Providers >> (ISPs) to deploy IPv6 across their networks as soon as possible. >> This deployment must include providing IPv6 access to End Users >> and ensuring services are accessible by IPv6. >> > > Shouldn't this paragraph target RIPE members specifically? Or, put > differently, why are end users and software vendors excluded? > Speaking as an end user, which probably does not qualify me as being part of the "RIPE Community": Agree with Florian's comments, and I would add hardware vendors to the list. As long as there are no commodity CPEs supporting IPv6, there is no incentive for ISPs to deploy IPv6 to their end users, especially those targetting the home users. -- Patrick Vande Walle From slz at baycix.de Thu Oct 18 11:49:05 2007 From: slz at baycix.de (Sascha Lenz) Date: Thu, 18 Oct 2007 11:49:05 +0200 Subject: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <471726B1.6040003@vande-walle.eu> References: <20071017152854.GY69215@Space.Net> <87r6jsu7ep.fsf@mid.deneb.enyo.de> <471726B1.6040003@vande-walle.eu> Message-ID: <47172C11.4070104@baycix.de> Hi, Patrick Vande Walle schrieb: > Florian Weimer wrote: >> * Gert Doering: >> >>> 2) We urge network operators and Internet Service Providers >>> (ISPs) to deploy IPv6 across their networks as soon as possible. >>> This deployment must include providing IPv6 access to End Users >>> and ensuring services are accessible by IPv6. >>> >> Shouldn't this paragraph target RIPE members specifically? Or, put >> differently, why are end users and software vendors excluded? >> > Speaking as an end user, which probably does not qualify me as being > part of the "RIPE Community": > > Agree with Florian's comments, and I would add hardware vendors to the > list. As long as there are no commodity CPEs supporting IPv6, there is > no incentive for ISPs to deploy IPv6 to their end users, especially > those targetting the home users. > even though the statement cannot be more than political "blah-blah" without any real outcome :-), i want to join in that the wording SHOULD include at least vendors end end-suer, since they are the biggest problem (point of view: a Consultant). Probably "network operators" is meant to include end-users, but that's not clear enough. And i also see vendors as part of "the community" here, but probably they don't think they are addressed without explicitely mentioning it :-) ISPs won't start deploying IPv6 more widely without end-users requiring it and vendors have a full (as in COMPLETE, WORKING) set of IPv6 capable devices, including SOHO CPEs. ...heck, i already have one upstream explicitely SHUTTING DOWN its IPv6 (testbed) service (Allocation returned) without any production replacement since noone wants to have IPv6 connectivity...yes, big german business/resale ISP ... scary. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== BayCIX GmbH * 84034 Landshut * Wagnergasse 8 Tel: +49 871 925360 * Fax: +49 871 9253629 eMail: technik at baycix.de GF: Thomas Zajac * HR B 4878 (Landshut) From Joao_Damas at isc.org Thu Oct 18 12:49:58 2007 From: Joao_Damas at isc.org (Joao Damas) Date: Thu, 18 Oct 2007 12:49:58 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <001f01c810d3$eee02530$cca06f90$@priv.at> References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> Message-ID: <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> I believe vendors will go where-ever their users show them the money. Create the demand, the offer will show up. Joao On 17 Oct 2007, at 17:39, Florian Frotzler wrote: > Hi, > > what about also urging the vendors to fully support IPv6 (like > forwarding in > hardware, increase functionality, you name it...)? > > Cheers, > Florian > > -----Urspr?ngliche Nachricht----- > Von: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] Im > Auftrag von > Gert Doering > Gesendet: Mittwoch, 17. Oktober 2007 17:29 > An: address-policy-wg at ripe.net; ipv6-wg at ripe.net > Betreff: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 > Depletion and > Deployment of IPv6 > > Hello Address Policy Working Group, IPv6 Working Group, > > as announced yesterday on the APWG list, here's the first draft of the > "we are going to tell the world what the RIPE community recommends > regarding the end of IPv4 / advent of IPv6". > > The text has been drafted by the RIPE NCC, but the actual > recommendation > needs to come from "the community", so change whatever you think needs > changing. > > Face-to-face discussion will take place in the APWG and IPv6 WG > meeting > on Thursday, October 25th. (Short discussion in APWG early > morning, time > to think about it during the day, final decision in the IPv6 WG > meeting on > Thursday afternoon). > > ----------------------- snip ----------------------- > > DRAFT - RIPE Community Resolution on IPv4 Depletion and > Deployment of IPv6 > RIPE 55: 22 - 26 October 2007 > > The RIPE community resolves as follows: > > 1) At current allocation rates, the remaining pool of unallocated > IPv4 address space is likely to be allocated within the next two > to four years. Although the Internet will continue to function as > normal after this point this event will have a significant > influence on future network operations as well as IP address > management and allocation policies. Therefore we recognise that > the widespread deployment of IPv6 will be essential to sustain > future growth of the Internet. > > 2) We urge network operators and Internet Service Providers > (ISPs) to deploy IPv6 across their networks as soon as possible. > This deployment must include providing IPv6 access to End Users > and ensuring services are accessible by IPv6. > > 3) We recognise that the responsibility for creating policies > related to the management of critical Internet resources in the > RIPE NCC service region rests with the RIPE community and the > proven success of the RIPE Policy Development Process (PDP). In > recognition of this responsibility, we commit to continue > development of effective policies for the responsible management > of IPv4 and IPv6 address space. > > 4) We agree that this situation requires a committed effort from > network operators, ISPs and the RIPE community. We urge that the > widespread deployment of IPv6 be made a high priority. > > ----- End forwarded message ----- > > Gert Doering > -- APWG chair > -- > Total number of prefixes smaller than registry allocations: 122119 > > 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 > From tim.streater at dante.org.uk Thu Oct 18 12:31:10 2007 From: tim.streater at dante.org.uk (Tim Streater) Date: Thu, 18 Oct 2007 11:31:10 +0100 Subject: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <47172C11.4070104@baycix.de> References: <20071017152854.GY69215@Space.Net> <87r6jsu7ep.fsf@mid.deneb.enyo.de> <471726B1.6040003@vande-walle.eu> <47172C11.4070104@baycix.de> Message-ID: At 10:49 18/10/2007, Sascha Lenz wrote: >Hi, > >Patrick Vande Walle schrieb: >>Florian Weimer wrote: >>>* Gert Doering: >>> >>>>2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6. >>>> >>>Shouldn't this paragraph target RIPE members specifically? Or, put >>>differently, why are end users and software vendors excluded? >>> >>Speaking as an end user, which probably does not qualify me as being >>part of the "RIPE Community": >>Agree with Florian's comments, and I would add hardware vendors to the >>list. As long as there are no commodity CPEs supporting IPv6, there is >>no incentive for ISPs to deploy IPv6 to their end users, especially >>those targetting the home users. > >even though the statement cannot be more than political "blah-blah" without any real outcome :-), i want to join in that the wording SHOULD include at least vendors end end-suer, since they are the biggest problem (point of view: a Consultant). >Probably "network operators" is meant to include end-users, but that's not clear enough. >And i also see vendors as part of "the community" here, but probably they don't think they are addressed without explicitely mentioning it :-) > >ISPs won't start deploying IPv6 more widely without end-users requiring it and vendors have a full (as in COMPLETE, WORKING) set of IPv6 capable devices, including SOHO CPEs. End users won't require it; they know little about v4 and v6 and only care about their applications working and being able to reach the hosts/sites they want to reach. When some parts of the Internet are only reachable via v6 *that* is when users will want to know why and will kick their ISPs, who will hasten to get their act together and will then kick their upstreams. We have a fully v6-compliant network already - and little traffic. >...heck, i already have one upstream explicitely SHUTTING DOWN its IPv6 (testbed) service (Allocation returned) without any production replacement since noone wants to have IPv6 connectivity...yes, big german business/resale ISP ... scary. -- Tim From iljitsch at muada.com Thu Oct 18 13:11:10 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 18 Oct 2007 13:11:10 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> Message-ID: On 18-okt-2007, at 12:49, Joao Damas wrote: > I believe vendors will go where-ever their users show them the money. > Create the demand, the offer will show up. Same thing for the ISPs. And the content networks. All three of those are in the end paid by the end-user. But the end-user has no idea what IPv6 is and is certainly not going to spend extra money to get it. There is plenty of work to do elsewhere too, but the CPE issue is quickly becoming a significant hurdle. The reason for that is that those tend to run IPv4 NAT which makes easy IPv6 tunneling hard. We really need those boxes to support IPv6 in the near future. However, in order for that to work there must be a clear provisioning model between ISPs and end-users. A good way to do this with IPv6 is with DHCPv6 prefix delegation, but until pretty much everyone agrees it's hard to build a CPE that will do something reasonable with IPv6 out of the box. From nick at inex.ie Thu Oct 18 13:33:39 2007 From: nick at inex.ie (Nick Hilliard) Date: Thu, 18 Oct 2007 12:33:39 +0100 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> Message-ID: <47174493.90506@inex.ie> Iljitsch van Beijnum wrote: > There is plenty of work to do elsewhere too, but the CPE issue is > quickly becoming a significant hurdle. On the contrary, the CPE issue has been a major problem for many years. It's simply one which has been ignored for far too long. > The reason for that is that those > tend to run IPv4 NAT which makes easy IPv6 tunneling hard. We really > need those boxes to support IPv6 in the near future. This all comes down to economics. Adding IPv6 capabilities to CPE access devices costs money, and CPE devices are often chosen purely on the basis of cost alone. Ergo, IPv6 capability is bad for business, if you manufacture CPE boxen. The real problem here is the lifetime of CPE devices. I'm going to estimate a rough half-life of 3 years. This is going to mean an awful lot of CPE access device swapouts to move to teh ipv6 intarweb. Which brings things back to the access ISPs: all access ISPs should be encouraged in the strongest possible terms to deploy devices now which are ipv6 capable, or which can be upgraded to be ipv6 capable. This will put pressure on the manufacturers to introduce v6 boxes to the marketplace because there are almost no low-end units which will do ipv6 out of the box right now. For a laugh, or maybe a cry, check out: http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.netopia.com http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.belkin.com http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.netgear.com http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.2wire.com http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.draytek.com http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.linksys.com http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.zyxel.com read: "heuston, we have a problem" Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From Joao_Damas at isc.org Thu Oct 18 14:13:37 2007 From: Joao_Damas at isc.org (Joao Damas) Date: Thu, 18 Oct 2007 14:13:37 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> Message-ID: On 18 Oct 2007, at 13:11, Iljitsch van Beijnum wrote: > On 18-okt-2007, at 12:49, Joao Damas wrote: > >> I believe vendors will go where-ever their users show them the money. >> Create the demand, the offer will show up. > > Same thing for the ISPs. Nope. If ISPs want to continue getting new customers and there are no new IPv4 addresses available then either trade them with some other party who has them, or they use IPv6. The last option might be more expensive at first but it will go down in price, whereas the cost of the first option is only likely to increase. This will create demand from the ISPs for IPv6 enabled products, though perhaps more in the area of application level gateways than in others. Customers won't care if their ISP gives them v6 or v4 as long as they get the service. > And the content networks. All three of those are in the end paid by > the end-user. But the end-user has no idea what IPv6 is and is > certainly not going to spend extra money to get it. > > There is plenty of work to do elsewhere too, but the CPE issue is > quickly becoming a significant hurdle. The reason for that is that > those tend to run IPv4 NAT which makes easy IPv6 tunneling hard. We > really need those boxes to support IPv6 in the near future. > > However, in order for that to work there must be a clear > provisioning model between ISPs and end-users. A good way to do > this with IPv6 is with DHCPv6 prefix delegation, but until pretty > much everyone agrees it's hard to build a CPE that will do > something reasonable with IPv6 out of the box. > From patrick at vande-walle.eu Thu Oct 18 15:00:56 2007 From: patrick at vande-walle.eu (Patrick Vande Walle) Date: Thu, 18 Oct 2007 15:00:56 +0200 Subject: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> Message-ID: <47175908.30009@vande-walle.eu> Joao Damas wrote: > Nope. If ISPs want to continue getting new customers and there are no > new IPv4 addresses available then either trade them with some other > party who has them, or they use IPv6. ... or use RFC1918 space and NAT their entire SOHO customer base. I am told some ISPs do it already. -- Patrick Vande Walle From fw at deneb.enyo.de Thu Oct 18 15:39:16 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 18 Oct 2007 15:39:16 +0200 Subject: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: (Tim Streater's message of "Thu, 18 Oct 2007 11:31:10 +0100") References: <20071017152854.GY69215@Space.Net> <87r6jsu7ep.fsf@mid.deneb.enyo.de> <471726B1.6040003@vande-walle.eu> <47172C11.4070104@baycix.de> Message-ID: <87ve94mtiz.fsf@mid.deneb.enyo.de> * Tim Streater: > End users won't require it; they know little about v4 and v6 and only > care about their applications working and being able to reach the > hosts/sites they want to reach. Does this reflect your experience with the academic community? (Just curious.) > When some parts of the Internet are only reachable via v6 *that* is > when users will want to know why and will kick their ISPs, who will > hasten to get their act together and will then kick their upstreams. Uh-oh, this reminds me of the Internet2 Detective. 8-/ From tim.streater at dante.org.uk Thu Oct 18 17:34:13 2007 From: tim.streater at dante.org.uk (Tim Streater) Date: Thu, 18 Oct 2007 16:34:13 +0100 Subject: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <87ve94mtiz.fsf@mid.deneb.enyo.de> References: <20071017152854.GY69215@Space.Net> <87r6jsu7ep.fsf@mid.deneb.enyo.de> <471726B1.6040003@vande-walle.eu> <47172C11.4070104@baycix.de> <87ve94mtiz.fsf@mid.deneb.enyo.de> Message-ID: At 14:39 18/10/2007, Florian Weimer wrote: >* Tim Streater: > > > End users won't require it; they know little about v4 and v6 and only > > care about their applications working and being able to reach the > > hosts/sites they want to reach. > >Does this reflect your experience with the academic community? (Just >curious.) End users doing v6 testing or testing apps for v6, will obviously know. We must have a number of those in some NRENs that we serve. We have several NREN customers who consistently generate orders of magnitude more v6 traffic than others. Then you have the generality of network engineers, who should know :-) But end-users in general (academic or not) are unlikely to know, seems to me. -- Tim From jordi.palet at consulintel.es Thu Oct 18 17:33:40 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 18 Oct 2007 09:33:40 -0600 Subject: [ipv6-wg] Re: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <87r6jsu7ep.fsf@mid.deneb.enyo.de> Message-ID: I think it may be better one additional paragraph asking the end users to *request* IPv6 transition or native services to their ISPs and look for an alternative ISP when their actual one is not willing to offer the service. Which this, I'm not asking the ISPs to do native overnight, I know this is not reasonable, but deploying 6to4 and Teredo relays for their users is simple and inexpensive solution and a very good think for both reducing the unnecessary upstream traffic and lowering the RTT when using those transition mechanisms. There is no excuse for an ISP not doing so already and I'm happy to offer my time if somebody don't have the knowledge about how to do so. Regards, Jordi > De: Florian Weimer > Responder a: > Fecha: Thu, 18 Oct 2007 10:57:34 +0200 > Para: Gert Doering > CC: , > Asunto: [ipv6-wg] Re: [address-policy-wg] DRAFT: RIPE Community Resolution on > IPv4 Depletion and Deployment of IPv6 > > * Gert Doering: > >> 2) We urge network operators and Internet Service Providers >> (ISPs) to deploy IPv6 across their networks as soon as possible. >> This deployment must include providing IPv6 access to End Users >> and ensuring services are accessible by IPv6. > > Shouldn't this paragraph target RIPE members specifically? Or, put > differently, why are end users and software vendors excluded? > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Thu Oct 18 17:56:22 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 18 Oct 2007 09:56:22 -0600 Subject: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <471726B1.6040003@vande-walle.eu> Message-ID: Well, I don't agree you're not part of the community. Being subscriber and poster to the mailing is a qualifier for being a member :-) Agree with Florian and you. It is needed to say something to remind vendors that market is already asking for IPv6 support. I don't think they should just wait for the demand to come, because then it will be late. So a warning to them is a good thing. Same for software developers, they should realize that they can take advantage of IPv6 NOW, because even if there are no native access providers yet, transition is available in end-hosts. There is no immediate need for low costs CPEs, of course is good to have, but transition tools in end-hosts already deliver the same, until access providers provide dual stack, then of course, CPEs with allow dual stack on the WAN link are needed. Regards, Jordi > De: Patrick Vande Walle > Responder a: > Fecha: Thu, 18 Oct 2007 11:26:09 +0200 > Para: > CC: > Asunto: Re: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 > Depletion and Deployment of IPv6 > > Florian Weimer wrote: >> * Gert Doering: >> >>> 2) We urge network operators and Internet Service Providers >>> (ISPs) to deploy IPv6 across their networks as soon as possible. >>> This deployment must include providing IPv6 access to End Users >>> and ensuring services are accessible by IPv6. >>> >> >> Shouldn't this paragraph target RIPE members specifically? Or, put >> differently, why are end users and software vendors excluded? >> > Speaking as an end user, which probably does not qualify me as being > part of the "RIPE Community": > > Agree with Florian's comments, and I would add hardware vendors to the > list. As long as there are no commodity CPEs supporting IPv6, there is > no incentive for ISPs to deploy IPv6 to their end users, especially > those targetting the home users. > > -- > Patrick Vande Walle > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Thu Oct 18 18:03:08 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 18 Oct 2007 10:03:08 -0600 Subject: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: Message-ID: End users are every day smarter. They realize that some peer to peer applications, on-lime-gaming, etc., works better some times or in some ISPs, and they end-up guessing that it is because they are able to use IPv6 end-to-end, doing *real* peer-to-peer. And it happens that some ISPs offer transition services that improve that, others not, so end-users end up replacing their ISPs and this is going to be more and more frequent, because this is already happening as more and more people uses Vista. Regarding the comment on the IPv6 traffic. There is a big misconception here, and I can prove it. We developed a tool to measure *REAL* IPv6 traffic, not just *NATIVE*. Because today, it is clear that a very very very low % is native, because almost none of the ISPs offer native IPv6 to the last mile, it is quite obvious. However, the increase on transition (encapsulated) IPv6 traffic is something happening in *ALL* the networks, despite those networks don't have *ANY* IPv6 support. GEANT may offer dual stack, but if the universities don't offer IPv6 to the desktop, then the OSs are using transition mechanisms, without users noticing it ! Regards, Jordi > De: Tim Streater > Responder a: > Fecha: Thu, 18 Oct 2007 11:31:10 +0100 > Para: Sascha Lenz , Address Policy WG > > CC: > Asunto: Re: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 > Depletion and Deployment of IPv6 > > At 10:49 18/10/2007, Sascha Lenz wrote: >> Hi, >> >> Patrick Vande Walle schrieb: >>> Florian Weimer wrote: >>>> * Gert Doering: >>>> >>>>> 2) We urge network operators and Internet Service Providers (ISPs) to >>>>> deploy IPv6 across their networks as soon as possible. This deployment >>>>> must include providing IPv6 access to End Users and ensuring services are >>>>> accessible by IPv6. >>>>> >>>> Shouldn't this paragraph target RIPE members specifically? Or, put >>>> differently, why are end users and software vendors excluded? >>>> >>> Speaking as an end user, which probably does not qualify me as being >>> part of the "RIPE Community": >>> Agree with Florian's comments, and I would add hardware vendors to the >>> list. As long as there are no commodity CPEs supporting IPv6, there is >>> no incentive for ISPs to deploy IPv6 to their end users, especially >>> those targetting the home users. >> >> even though the statement cannot be more than political "blah-blah" without >> any real outcome :-), i want to join in that the wording SHOULD include at >> least vendors end end-suer, since they are the biggest problem (point of >> view: a Consultant). >> Probably "network operators" is meant to include end-users, but that's not >> clear enough. >> And i also see vendors as part of "the community" here, but probably they >> don't think they are addressed without explicitely mentioning it :-) >> >> ISPs won't start deploying IPv6 more widely without end-users requiring it >> and vendors have a full (as in COMPLETE, WORKING) set of IPv6 capable >> devices, including SOHO CPEs. > > End users won't require it; they know little about v4 and v6 and only care > about their applications working and being able to reach the hosts/sites they > want to reach. When some parts of the Internet are only reachable via v6 > *that* is when users will > want to know why and will kick their ISPs, who will hasten to get their act > together and will then kick their upstreams. > > We have a fully v6-compliant network already - and little traffic. > >> ...heck, i already have one upstream explicitely SHUTTING DOWN its IPv6 >> (testbed) service (Allocation returned) without any production replacement >> since noone wants to have IPv6 connectivity...yes, big german business/resale >> ISP ... scary. > > > -- Tim > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From michael.dillon at bt.com Thu Oct 18 18:25:08 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 18 Oct 2007 17:25:08 +0100 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <47174493.90506@inex.ie> References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> Message-ID: > This all comes down to economics. Adding IPv6 capabilities > to CPE access devices costs money, and CPE devices are often > chosen purely on the basis of cost alone. Ergo, IPv6 > capability is bad for business, if you manufacture CPE boxen. IPv6 is a software upgrade. Most of these boxes can be flashed in the field and many of them are based on Linux or BSD, so in most cases it is only a matter of including and testing the IPv6 code that already exists. > The real problem here is the lifetime of CPE devices. I'm > going to estimate a rough half-life of 3 years. This is > going to mean an awful lot of CPE access device swapouts to > move to teh ipv6 intarweb. This means that if we can get manufacturers to include IPv6 during the next 12 months, then in 4 years, half the CPE will support IPv6 through pure attrition. That's not too bad. Once the kit is on the market, this schedule can be speeded up if required. Also, remember that IPv4 doesn't suddenly stop working. You could reasonably expect to leave most existing customers alone and only deal with CPE upgrades for the few that want to upgrade. The CPE manufacturers can move pretty quickly if they see a demand for IPv6. --Michael Dillon From nick at inex.ie Thu Oct 18 20:19:42 2007 From: nick at inex.ie (Nick Hilliard) Date: Thu, 18 Oct 2007 19:19:42 +0100 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> Message-ID: <4717A3BE.7060506@inex.ie> michael.dillon at bt.com wrote: > IPv6 is a software upgrade. Michael, you've got quite the talent for coming up with vacuous sound-bites like this. It is true that if: - you have an CPE device which is designed to be upgraded (lots of early CPE devices weren't) - the CPE device has enough flash and RAM to run ipv6 - there is actually an ipv6 capable image for your CPE device, which assumes that your CPE device is still supported by its manufacturer - this ipv6 upgrade image is stable enough for production use - you are clued in enough to be able to upgrade your CPE device - your ISP can afford the time to support the reconfiguration of your device via its support mechanism, ... then IPv6 is a software upgrade. If any of these is not true, you're way off into uncharted territory. Obviously, it's always going to be possible to buy your way out of this sort of problem, but how are you going to explain this to Joe and Jane Knucklehead who want teh intarweb for their kids' school projects, Jane's IM with her sister in OZ and Joe's late night pr0n sessions, and who have no knowledge whatever in any meaningful sense about what ipv6 is and how it could make their life any better, and that now they have to fork out ?60 for another ADSL modem when their current one works just fine, thank you very much. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From fw at deneb.enyo.de Thu Oct 18 21:26:19 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 18 Oct 2007 21:26:19 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: (michael dillon's message of "Thu, 18 Oct 2007 17:25:08 +0100") References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> Message-ID: <87fy08cjhg.fsf@mid.deneb.enyo.de> * michael dillon: >> This all comes down to economics. Adding IPv6 capabilities >> to CPE access devices costs money, and CPE devices are often >> chosen purely on the basis of cost alone. Ergo, IPv6 >> capability is bad for business, if you manufacture CPE boxen. > > IPv6 is a software upgrade. Including IPsec? Doubt it, some of the CPUs barely manage to run PPPoE. From michael.dillon at bt.com Thu Oct 18 23:33:45 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 18 Oct 2007 22:33:45 +0100 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <4717A3BE.7060506@inex.ie> References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> <4717A3BE.7060506@inex.ie> Message-ID: > It is true that if: > > - you have an CPE device which is designed to be upgraded > (lots of early CPE devices weren't) > - the CPE device has enough flash and RAM to run ipv6 > - there is actually an ipv6 capable image for your CPE > device, which assumes that your CPE device is still supported > by its manufacturer > - this ipv6 upgrade image is stable enough for production use > - you are clued in enough to be able to upgrade your CPE device > - your ISP can afford the time to support the reconfiguration > of your device via its support mechanism, > > ... then IPv6 is a software upgrade. > > If any of these is not true, you're way off into uncharted territory. Uncharted territory? How does "you continue to use IPv4 as before" become uncharted territory. If a customer's network does not support IPv6 for any reason, including CPE, then they just keep on using IPv4 as they always have done. They can still get to IPv6 resources that have installed appropriate adapters such as 6to4 relays or ALGs on the content providers network. When the IPv6 Internet is required to sustain business growth because there are no unused IPv4 addresses available, all the IPv4 network infrastructure will continue to work as it had before. > how are you going to explain > this to Joe and Jane Knucklehead ... what ipv6 is and how > it could make their life any better, and that now they have > to fork out EUR60 for another ADSL modem when their current one > works just fine, thank you very much. It's easier than most engineers think. Ordinary people spend EUR60 every day for things that they find useful, such as a meal in a restaurant, new clothes. Experience has shown that they are not unhappy to pay that much money to replace an Internet gateway as long as it is old and there is some perceived benefit in the new one. Since a new one will support IPv6, is likely to have field-upgradeable software, and probably includes a better firewall and management interface, it will be easy to get them to pay for it. --Michael Dillon From iljitsch at muada.com Fri Oct 19 10:51:32 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 19 Oct 2007 10:51:32 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <87fy08cjhg.fsf@mid.deneb.enyo.de> References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> <87fy08cjhg.fsf@mid.deneb.enyo.de> Message-ID: <1C87EF13-F074-4CC6-A520-531F5015A6B6@muada.com> On 18-okt-2007, at 21:26, Florian Weimer wrote: >> IPv6 is a software upgrade. > Including IPsec? Doubt it, some of the CPUs barely manage to run > PPPoE. Since when are IPv6 routers required to do IPsec processing? From nick at inex.ie Fri Oct 19 11:04:47 2007 From: nick at inex.ie (Nick Hilliard) Date: Fri, 19 Oct 2007 10:04:47 +0100 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <1C87EF13-F074-4CC6-A520-531F5015A6B6@muada.com> References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> <87fy08cjhg.fsf@mid.deneb.enyo.de> <1C87EF13-F074-4CC6-A520-531F5015A6B6@muada.com> Message-ID: <4718732F.3000907@inex.ie> Iljitsch van Beijnum wrote: > Since when are IPv6 routers required to do IPsec processing? December 1995 - please see rfc1883 and rfc2640, section 4: > A full implementation of IPv6 includes implementation of the > following extension headers: > [...] > Authentication > Encapsulating Security Payload > > The first four are specified in this document; the last two are > specified in [RFC-2402] and [RFC-2406], respectively. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From fw at deneb.enyo.de Fri Oct 19 11:24:50 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 19 Oct 2007 11:24:50 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <1C87EF13-F074-4CC6-A520-531F5015A6B6@muada.com> (Iljitsch van Beijnum's message of "Fri, 19 Oct 2007 10:51:32 +0200") References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> <87fy08cjhg.fsf@mid.deneb.enyo.de> <1C87EF13-F074-4CC6-A520-531F5015A6B6@muada.com> Message-ID: <87d4vbjw2l.fsf@mid.deneb.enyo.de> * Iljitsch van Beijnum: > On 18-okt-2007, at 21:26, Florian Weimer wrote: > >>> IPv6 is a software upgrade. > >> Including IPsec? Doubt it, some of the CPUs barely manage to run >> PPPoE. > > Since when are IPv6 routers required to do IPsec processing? RFC 4294, Section 8.1. From iljitsch at muada.com Fri Oct 19 15:30:38 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 19 Oct 2007 15:30:38 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <4718732F.3000907@inex.ie> References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> <87fy08cjhg.fsf@mid.deneb.enyo.de> <1C87EF13-F074-4CC6-A520-531F5015A6B6@muada.com> <4718732F.3000907@inex.ie> Message-ID: On 19-okt-2007, at 11:04, Nick Hilliard wrote: >> Since when are IPv6 routers required to do IPsec processing? > December 1995 - please see rfc1883 and rfc2640, section 4: > >> A full implementation of IPv6 includes implementation of the >> following extension headers: Two can play the RFC quoting game (2460): With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. From gert at space.net Fri Oct 19 18:42:12 2007 From: gert at space.net (Gert Doering) Date: Fri, 19 Oct 2007 18:42:12 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> <87fy08cjhg.fsf@mid.deneb.enyo.de> <1C87EF13-F074-4CC6-A520-531F5015A6B6@muada.com> <4718732F.3000907@inex.ie> Message-ID: <20071019164212.GV69215@Space.Net> Hi, On Fri, Oct 19, 2007 at 03:30:38PM +0200, Iljitsch van Beijnum wrote: > Two can play the RFC quoting game (2460): There's a certain fun value to watch your "I can quote more interesting things from the RFC" game - but: ** can we please try to focus on "do we want to issue this resolution, ** and if yes, which words need changing"? Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 122119 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 From slz at baycix.de Fri Oct 19 20:14:18 2007 From: slz at baycix.de (Sascha Lenz) Date: Fri, 19 Oct 2007 20:14:18 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <20071019164212.GV69215@Space.Net> References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> <87fy08cjhg.fsf@mid.deneb.enyo.de> <1C87EF13-F074-4CC6-A520-531F5015A6B6@muada.com> <4718732F.3000907@inex.ie> <20071019164212.GV69215@Space.Net> Message-ID: <4718F3FA.4040705@baycix.de> Hi, Gert Doering schrieb: > Hi, > > On Fri, Oct 19, 2007 at 03:30:38PM +0200, Iljitsch van Beijnum wrote: >> Two can play the RFC quoting game (2460): > > There's a certain fun value to watch your "I can quote more interesting > things from the RFC" game - but: > > ** can we please try to focus on "do we want to issue this resolution, > ** and if yes, which words need changing"? a) seconded, or this tends to get a "ignored by the sane people" thread like this 240/4 thingy on the NANOG-list... Please discuss that stuff in private or ask RIPE to open an "Advocacy WG" + list.. thanks. b) there aren't that many change-requeensts (nono, no ITIL...) for the wording, are they? Did i miss something in the mess? -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From gert at space.net Sat Oct 20 14:48:19 2007 From: gert at space.net (Gert Doering) Date: Sat, 20 Oct 2007 14:48:19 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <4718F3FA.4040705@baycix.de> References: <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> <87fy08cjhg.fsf@mid.deneb.enyo.de> <1C87EF13-F074-4CC6-A520-531F5015A6B6@muada.com> <4718732F.3000907@inex.ie> <20071019164212.GV69215@Space.Net> <4718F3FA.4040705@baycix.de> Message-ID: <20071020124819.GA69215@Space.Net> Hi, On Fri, Oct 19, 2007 at 08:14:18PM +0200, Sascha Lenz wrote: > b) there aren't that many change-requeensts (nono, no ITIL...) for the > wording, are they? Did i miss something in the mess? As far as I can see, so far, the main point was: - address the vendors anything major I have missed? Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 122119 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 From Shane_Kerr at isc.org Fri Oct 19 09:59:41 2007 From: Shane_Kerr at isc.org (Shane Kerr) Date: Fri, 19 Oct 2007 09:59:41 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <87fy08cjhg.fsf@mid.deneb.enyo.de> References: <20071017152854.GY69215@Space.Net> <001f01c810d3$eee02530$cca06f90$@priv.at> <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> <87fy08cjhg.fsf@mid.deneb.enyo.de> Message-ID: <471863ED.4040206@isc.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Weimer wrote: > * michael dillon: > >>> This all comes down to economics. Adding IPv6 capabilities >>> to CPE access devices costs money, and CPE devices are often >>> chosen purely on the basis of cost alone. Ergo, IPv6 >>> capability is bad for business, if you manufacture CPE boxen. >> IPv6 is a software upgrade. > > Including IPsec? Doubt it, some of the CPUs barely manage to run PPPoE. IPv6 can use without IPsec. Also, you can use IPsec without IPv6. I blame IPv6-advocates for adding "security" to the "feature list" for IPv6, in an attempt to make it more attractive. The only real feature IPv6 adds is more addresses. There are a few simplifications that you can make when you don't have to worry about running out of addresses, and these are part of IPv6. But security (and quality of service) is just as easy in IPv4 as in IPv6. - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGGPtMsfZxBO4kbQRAp0UAKClQGfgNnZgRm3gCkeicErb9idnRwCgkI62 PXBXY5BC8BXBT8mGY/KCT2g= =QUMA -----END PGP SIGNATURE----- From dinckan at gmail.com Sun Oct 21 21:51:56 2007 From: dinckan at gmail.com (=?ISO-8859-1?Q?Ali_Din=E7kan?=) Date: Sun, 21 Oct 2007 22:51:56 +0300 Subject: [address-policy-wg] Question about IP block Misusage Message-ID: <4aca370f0710211251i29f5c27m828f38bbc6e66c2@mail.gmail.com> Hello, I have a question. I am searhing now what happens if an ISP use IP address space that is assigned to another ISP. Is there any technical control eleminate this condition? And what is the legal sanction of this misuse? This might be intentional or unintentional. But ISP that use another ISP's IP address space damage the Internet nature. Thank you for your answer in advance Best regards, Ali Din?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Sun Oct 21 22:29:21 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 21 Oct 2007 22:29:21 +0200 Subject: [address-policy-wg] AW: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: <20071020124819.GA69215@Space.Net> (Gert Doering's message of "Sat, 20 Oct 2007 14:48:19 +0200") References: <8C0E42DF-7EBB-4E44-B619-B847A3E288B7@isc.org> <47174493.90506@inex.ie> <87fy08cjhg.fsf@mid.deneb.enyo.de> <1C87EF13-F074-4CC6-A520-531F5015A6B6@muada.com> <4718732F.3000907@inex.ie> <20071019164212.GV69215@Space.Net> <4718F3FA.4040705@baycix.de> <20071020124819.GA69215@Space.Net> Message-ID: <878x5wciu6.fsf@mid.deneb.enyo.de> * Gert Doering: > Hi, > > On Fri, Oct 19, 2007 at 08:14:18PM +0200, Sascha Lenz wrote: >> b) there aren't that many change-requeensts (nono, no ITIL...) for the >> wording, are they? Did i miss something in the mess? > > As far as I can see, so far, the main point was: > > - address the vendors Or only address RIPE members, which would make more sense IMHO. From chapuis at ip-plus.net Mon Oct 22 11:31:41 2007 From: chapuis at ip-plus.net (Andre Chapuis) Date: Mon, 22 Oct 2007 11:31:41 +0200 Subject: [address-policy-wg] Sub-Allocations for ALLOCATED UNSPECIFIED blocks In-Reply-To: <4aca370f0710211251i29f5c27m828f38bbc6e66c2@mail.gmail.com> References: <4aca370f0710211251i29f5c27m828f38bbc6e66c2@mail.gmail.com> Message-ID: <037d01c8148e$5b1b5a90$00bad90a@corproot.net> Hi WG, We need to register sub-allocations to different entities within our company from address blocks that have the ALLOCATED UNSPECIFIED status. This is curently not allowed and I would like to ask whether this could be changed. Of course there are plenty of ASSIGNED PIs withing these blocks, so there is no chance to migrate the blocks to ALLOCATED PA. Thanks in advance and see you this week Andr? ------------------------------ Andr? Chapuis Swisscom IP-Plus Genfergasse 14 3050 Berne +41 31 342 40 74 chapuis at ip-plus.net CCIE #6023 ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs.cs at schiefner.de Mon Oct 22 12:22:22 2007 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 22 Oct 2007 12:22:22 +0200 Subject: [address-policy-wg] Sub-Allocations for ALLOCATED UNSPECIFIED blocks In-Reply-To: <037d01c8148e$5b1b5a90$00bad90a@corproot.net> References: <4aca370f0710211251i29f5c27m828f38bbc6e66c2@mail.gmail.com> <037d01c8148e$5b1b5a90$00bad90a@corproot.net> Message-ID: <471C79DE.10904@schiefner.de> Andre, Andre Chapuis wrote: > We need to register sub-allocations to different entities within our > company from address blocks that have the ALLOCATED UNSPECIFIED status. > This is curently not allowed and I would like to ask whether this could > be changed. > Of course there are plenty of ASSIGNED PIs withing these blocks, so > there is no chance to migrate the blocks to ALLOCATED PA. I believe the usual way to proceed would be to file a policy change proposal according to: http://www.ripe.net/ripe/policies/index.html and more specific: http://www.ripe.net/ripe/docs/pdp.html for RIPE-411 "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region": http://www.ripe.net/ripe/docs/ripe-411.html Best, Carsten From filiz at ripe.net Tue Oct 23 11:20:28 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 23 Oct 2007 11:20:28 +0200 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) Message-ID: <20071023092028.141B42F583@herring.ripe.net> PDP Number: 2007-08 Enabling Methods for Reallocation of IPv4 Resources Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. This proposal outlines a framework to migrate previously allocated IPv4 resources from one Local Internet Registry (LIR) to another LIR within the RIPE NCC Service Region. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-08.html We encourage you to review this proposal and send your comments to before 20 November 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From andy at nosignal.org Tue Oct 23 11:40:11 2007 From: andy at nosignal.org (Andy Davidson) Date: Tue, 23 Oct 2007 10:40:11 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <20071023092028.141B42F583@herring.ripe.net> References: <20071023092028.141B42F583@herring.ripe.net> Message-ID: On 23 Oct 2007, at 10:20, Filiz Yilmaz wrote: > This proposal outlines a framework to migrate previously allocated > IPv4 resources from one Local Internet Registry (LIR) to another LIR > within the RIPE NCC Service Region. I support this process and feel that it would significantly help keep records up to date when LIRs consolidate, and in other circumstances, which is a good aim - good work Nigel and Remco. However, I think that the NCC hostmasters should be given an input - they should be allowed to delay the transfer to a new LIR if they have concerns about assignment policies of the old LIR have not been accurately followed, or the new LIR has not paid their service fee account up to date. I don't have a suggested wording revision at this stage. Best wishes, Andy Davidson From michael.dillon at bt.com Tue Oct 23 12:16:11 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 23 Oct 2007 11:16:11 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <20071023092028.141B42F583@herring.ripe.net> References: <20071023092028.141B42F583@herring.ripe.net> Message-ID: > http://www.ripe.net/ripe/policies/proposals/2007-08.html In effect, this proposal enables a market for buying and selling IP address blocks. RIPE is a member of the NRO. According to the NRO factsheet: http://www.nro.net/docs/nro-factsheet/nro_technical-sheet.pdf IP addresses are not owned as property. ... When a consumer no longer requires the use of the IP address space, it is returned to the LIR or ISP. It would be very hypocritical if RIPE allowed LIRs to treat address blocks as property between themselves while at the same time forbidding their customers to treat address blocks as property. I wonder if this would be considered a cartel under the EU treaties since the discussions within RIPE are practically invisible to the companies who are customers of LIRs. Do we really want RIPE to move towards pirate capitalism while North America explicitly outlaws such transfers? http://www.arin.net/policy/nrpm.html#eight --Michael Dillon P.S. What is a cartel? It is an illegal secret agreement concluded between competitors who in coordination fix or increase their prices, restrict supply by limiting their sales or their production capacities, and/or divide up their markets or consumers. (quoted from http://ec.europa.eu/comm/competition/cartels/overview/index_en.cfm ) From gert at space.net Tue Oct 23 12:26:02 2007 From: gert at space.net (Gert Doering) Date: Tue, 23 Oct 2007 12:26:02 +0200 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: <20071023092028.141B42F583@herring.ripe.net> Message-ID: <20071023102602.GY34650@Space.Net> Hi, On Tue, Oct 23, 2007 at 11:16:11AM +0100, michael.dillon at bt.com wrote: > > http://www.ripe.net/ripe/policies/proposals/2007-08.html > > In effect, this proposal enables a market for buying and > selling IP address blocks. It is envisioned that this market is going to happen, whether we like it or not, and there is not much we can do against it. But in the case that this *is* going to happen, we would very much prefer to have accurate records on who is holding the address space - and this proposal is trying to build the basis for this. (We already have the means for resource transfers between LIRs, it's part of the "merger and closures" document, but it's not very well-defined in the case of two independent LIRs doing this without any "merger or closure"). Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 122119 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 From iljitsch at muada.com Tue Oct 23 12:45:41 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 23 Oct 2007 12:45:41 +0200 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <20071023102602.GY34650@Space.Net> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> Message-ID: On 23-okt-2007, at 12:26, Gert Doering wrote: > It is envisioned that this market is going to happen, whether we like > it or not, and there is not much we can do against it. > But in the case that this *is* going to happen, we would very much > prefer > to have accurate records on who is holding the address space - and > this > proposal is trying to build the basis for this. Once it becomes possible to sell address space we can kiss any chance of any of the legacy space coming back goodbye. Even the slightest step in this direction can be very harmful. I don't see the need to make things easier for people who do things that they aren't supposed to do. If I "lend" some of my address space to someone else, why should I be spared the inconvencience of being contacted when an issue comes up with the use of that space? Presumably, I remember who I lended the address space to, and if not, it's hard to hide in the routing table. From michael.dillon at bt.com Tue Oct 23 12:53:54 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 23 Oct 2007 11:53:54 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <20071023102602.GY34650@Space.Net> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> Message-ID: > > In effect, this proposal enables a market for buying and selling IP > > address blocks. > > It is envisioned that this market is going to happen, whether > we like it or not, and there is not much we can do against it. Envisaged by who? ICANN and the Number Resource Organization both maintain that IP addresses are not property and therefore they cannot be bought or sold. It does not matter if a few individuals disagree because a few individuals do not control many IP addresses. Most IP addresses have been allocated to publicly traded companies and these companies have an obligation to act in an ethical manner which makes it impossible for these companies to buy or sell IP addresses. > But in the case that this *is* going to happen, we would very > much prefer to have accurate records on who is holding the > address space - and this proposal is trying to build the > basis for this. In the case that selling does happen, and in the case that addresses are transferred for other reasons, ARIN has a policy that covers transfers. Everyone should really read that policy to see how this could be handled without violating the principles maintained by ICANN and the NRO http://www.arin.net/policy/nrpm.html#eight > (We already have the means for resource transfers between > LIRs, it's part of the "merger and closures" document, but > it's not very well-defined in the case of two independent > LIRs doing this without any "merger or closure"). ARIN's policy does try to cover the general situation without being narrowly focussed on corporate mergers. I am not suggesting that RIPE should just copy ARIN, but we need to look at this poloicy proposal in context, and that includes what other RIRs are doing, the basic NRO/ICANN principles, and EU competition law. --Michael Dillon From matthew.ford at bt.com Tue Oct 23 12:49:30 2007 From: matthew.ford at bt.com (matthew.ford at bt.com) Date: Tue, 23 Oct 2007 11:49:30 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <20071023102602.GY34650@Space.Net> Message-ID: Gert, > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf > Of Gert Doering > Sent: 23 October 2007 11:26 > To: Dillon,M,Michael,DMK R > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2007-08 New Policy > Proposal (Enabling Methods for Reallocation of IPv4 Resources) > > Hi, > > On Tue, Oct 23, 2007 at 11:16:11AM +0100, > michael.dillon at bt.com wrote: > > > > http://www.ripe.net/ripe/policies/proposals/2007-08.html > > > > In effect, this proposal enables a market for buying and > > selling IP address blocks. > > It is envisioned that this market is going to happen, > whether we like > it or not, and there is not much we can do against it. That doesn't sound like vision. That sounds like apathy. > But in the case that this *is* going to happen, we > would very much prefer > to have accurate records on who is holding the > address space - and this > proposal is trying to build the basis for this. This proposal enables the market. In the absence of this proposal, you might find the courts are perfectly willing to support RIPE NCC's position as the arbiter of due process, as has already happened in the US for ARIN. > (We already have the means for resource transfers > between LIRs, it's > part of the "merger and closures" document, but it's > not very well-defined > in the case of two independent LIRs doing this > without any "merger or > closure"). Not well-defined for very good reason, I'd suggest. Mat From jordi.palet at consulintel.es Thu Oct 25 11:55:18 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 25 Oct 2007 11:55:18 +0200 Subject: [address-policy-wg] RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 Message-ID: I don't think my comment was well understood today in the session, so I drafted how I think the community resolution should look. See below. English nits should be reviewed, but the main idea is that we start with a short kind of intro of the situation (those points from the original 5 that are generic), staying focus, keeping it short, but at the same time help each "kind of reader" to identify what is the paragraph that is *more* relevant to him. I also added a specific action for policy makers/regulators and one for users. I hope that, as very few people (in the list and session) has provided input on this, we are allowed to participate in the final drafting of the document. Not being a big group is possible to do it, as otherwise, will not really be a community resolution. Regards, Jordi At current allocation rates, the remaining pool of unallocated IPv4 address space is likely to be allocated within the next two to four years. Although the Internet will continue to function as normal after this point, this event will have a significant influence on future network operations as well as IP address management and allocation policies. Therefore we recognise that the widespread deployment of IPv6 will be essential to sustain future growth of the Internet. We recognise that the responsibility for creating policies related to the management of critical Internet resources in the RIPE NCC service region rests with the RIPE community and the proven success of the RIPE Policy Development Process (PDP). In recognition of this responsibility, we commit to continue development of effective policies for the responsible management of IPv4 and IPv6 address space. We agree that this situation requires a committed effort from network operators, ISPs and the RIPE community. We urge that the widespread deployment of IPv6 be made a high priority. In addition to that, other sectors must take their own measures in order to success on this mission: 1) Network operators and Internet Service Providers (ISPs) are called to the urgent deployment of IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6. 2) Vendors (hardware and software) are called to the urgent support of IPv6 support in their products, to make it possible for network operators and Internet Service Providers to provide these services. 3) Regulators and policy makers are called to make sure the relevance of the IPv6 support is considered in all their decisions, including as an immediate condition for public procurements. 4) Users must ensure, when acquiring new services, hardware or software, that it supports IPv6 (natively or by means of transition mechanisms). ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From michael.dillon at bt.com Thu Oct 25 12:07:40 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 25 Oct 2007 11:07:40 +0100 Subject: [address-policy-wg] RE: [ipv6-wg] RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: References: Message-ID: > 1) Network operators and Internet Service Providers (ISPs) > are called to the urgent deployment of IPv6 across their > networks as soon as possible. This deployment must include > providing IPv6 access to End Users and ensuring services are > accessible by IPv6. I would like to see this text explicitly mention both "deployment of IPv6 network access" and "deployment of IPv6 transitional measures". Otherwise, decisionmakers will think that it is sufficient to offer an IPv6 version of their IPv4 access product. That is not too hard to do, but it doesn't deliver what most customers want, which is access to the whole Internet, IPv4 and IPv6. That is where deployment of transitional measures become important, and I would argue, that they are more important right now than deploying IPv6 access services because the transitional measures solve problems that are happening right now with native IPv6 in OS/X and Vista. --Michael Dillon From jordi.palet at consulintel.es Thu Oct 25 12:15:41 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 25 Oct 2007 12:15:41 +0200 Subject: [address-policy-wg] RE: [ipv6-wg] RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: Message-ID: Fully agree, I actually said it last week in one of my previous emails on this ... So probably something like: 1) Network operators and Internet Service Providers (ISPs) are called to the urgent deployment of IPv6 and transitional measures across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6. Regards, Jordi > De: > Responder a: > Fecha: Thu, 25 Oct 2007 11:07:40 +0100 > Para: , > Conversaci?n: [ipv6-wg] RIPE Community Resolution on IPv4 Depletion and > Deployment of IPv6 > Asunto: [address-policy-wg] RE: [ipv6-wg] RIPE Community Resolution on IPv4 > Depletion and Deployment of IPv6 > > >> 1) Network operators and Internet Service Providers (ISPs) >> are called to the urgent deployment of IPv6 across their >> networks as soon as possible. This deployment must include >> providing IPv6 access to End Users and ensuring services are >> accessible by IPv6. > > I would like to see this text explicitly mention both "deployment of > IPv6 network access" and "deployment of IPv6 transitional measures". > Otherwise, decisionmakers will think that it is sufficient to offer an > IPv6 version of their IPv4 access product. That is not too hard to do, > but it doesn't deliver what most customers want, which is access to the > whole Internet, IPv4 and IPv6. That is where deployment of transitional > measures become important, and I would argue, that they are more > important right now than deploying IPv6 access services because the > transitional measures solve problems that are happening right now with > native IPv6 in OS/X and Vista. > > --Michael Dillon > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From ncc at ripe.net Thu Oct 25 14:51:34 2007 From: ncc at ripe.net (Axel Pawlik) Date: Thu, 25 Oct 2007 14:51:34 +0200 Subject: [address-policy-wg] ASO AC Elections: Hans Petter Holen Elected Message-ID: <47209156.4040203@ripe.net> [Apologies for duplicate e-mails.] Dear Colleagues, We are pleased to announce that Hans Petter Holen has been selected by the RIPE community to take the vacant seat on the Address Supporting Organization (ASO) Address Council (AC). He will serve a two-year term. Selection took place during the Plenary session on Wednesday, 24 October 2007, at the RIPE 55 Meeting in Amsterdam. More information about the ASO AC and the selection process can be found at: http://www.ripe.net/info/resource-admin/aso2007/index.html Kind Regards, Axel Pawlik Managing Director RIPE NCC From s.steffann at computel.nl Thu Oct 25 15:30:11 2007 From: s.steffann at computel.nl (Sander Steffann) Date: Thu, 25 Oct 2007 15:30:11 +0200 Subject: [address-policy-wg] RE: [ipv6-wg] RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 In-Reply-To: References: Message-ID: <51289DFA-A92F-4183-ABA7-A823780CBBAE@computel.nl> Hi Michael, Op 25-okt-2007, om 12:07 heeft het volgende geschreven: > >> 1) Network operators and Internet Service Providers (ISPs) >> are called to the urgent deployment of IPv6 across their >> networks as soon as possible. This deployment must include >> providing IPv6 access to End Users and ensuring services are >> accessible by IPv6. > > I would like to see this text explicitly mention both "deployment of > IPv6 network access" and "deployment of IPv6 transitional measures". > Otherwise, decisionmakers will think that it is sufficient to offer an > IPv6 version of their IPv4 access product. That is not too hard to do, > but it doesn't deliver what most customers want, which is access to > the > whole Internet, IPv4 and IPv6. That is where deployment of > transitional > measures become important, and I would argue, that they are more > important right now than deploying IPv6 access services because the > transitional measures solve problems that are happening right now with > native IPv6 in OS/X and Vista. > > --Michael Dillon Thank you for your suggestion. I will include it in the discussion later in the iPv6 working group session. It might be too detailed for the intended audience though. We are targeting decision makers with this text. Thanks for your input! Sander From ncc at ripe.net Thu Oct 25 18:02:37 2007 From: ncc at ripe.net (Axel Pawlik) Date: Thu, 25 Oct 2007 18:02:37 +0200 Subject: [address-policy-wg] ASO AC Elections: Hans Petter Holen Elected - Correction Message-ID: <4720BE1D.2090605@ripe.net> Dear Colleagues, Hans Petter Holen will serve on the Address Supporting Organization (ASO) Address Council (AC) for three years and not two years as stated in the previous e-mail that you received. We apologise for any confusion. Kind regards, Axel Pawlik Managing Director RIPE NCC From michael.dillon at bt.com Fri Oct 26 23:05:56 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 26 Oct 2007 22:05:56 +0100 Subject: [address-policy-wg] Commercial IPv6 firewall support Message-ID: Some people have claimed that they cannot yet sell IPv6 Internet access because there is no IPv6 firewall support. According to this ICANN study: http://www.icann.org/committees/security/sac021.pdf this is not quite true. At least 30% of the 42 vendors surveyed, had IPv6 support. According to this talk many open-source and commercial firewalls supporting IPv6 are available. IPCop is based on Linux m0n0wall is based on FreeBSD pfSense is also based on FreeBSD FWBuilder is a management tool that builds filter setups for several different firewalls. Checkpoint FW1 NGX R65 on SecurePlatform supports IPv6 FortiGate supports IPv6 in FortiOS 3.0 and up. Juniper SSG (formerly Netscreen) supports IPv6 in ScreenOS 6.0 and up. Cisco ASA (formerly PIX) supports IPv6 in version 7.0 and up. I suspect that the people complaining about IPv6 support are partially complaining because they have older hardware that the vendor does not plan to upgrade to IPv6 support until they have all features implemented in their newer products, and partially complaining because their vendor has not implemented some feature which they happen to use. Commercial firewall support may be lagging behind OS and router support, but not by much. And if commercial vendors are not responsive, maybe you should try pricing out an open source solution with a consultant. I believe there is a gap here that startup firewall companies could fill if they understand the enterprise market. --Michael Dillon From nick at inex.ie Sat Oct 27 16:25:41 2007 From: nick at inex.ie (Nick Hilliard) Date: Sat, 27 Oct 2007 15:25:41 +0100 Subject: [address-policy-wg] Commercial IPv6 firewall support In-Reply-To: References: Message-ID: <20071027142541.GA18426@muffin.acquirer.com> > Some people have claimed that they cannot yet sell > IPv6 Internet access because there is no IPv6 firewall > support. According to this ICANN study: > http://www.icann.org/committees/security/sac021.pdf > this is not quite true. At least 30% of the 42 vendors > surveyed, had IPv6 support. There is, of course, "support" and support when talking about any feature, whether ipv6 related or not. As a useful example of what "support" implies, the "support" from one of my firewall vendors includes basic support for ipv6 packet forwarding and filtering, but no support for configuring this from the GUI. And no support for failover / failback on ipv6. And no support for ospfv3. Or DHCPv6. Or v6 support for VPNs. And so on - you get the idea. There are piles more features which just aren't there if you use v6. In fact, I would suggest that there is such a large functionality gap between their ipv4 and ipv6 support right now, that even if they invested heavily between now and the current expected dates for ipv4 exhaustion, I seriously doubt that they would achieve feature parity, not to mind stability parity for these features. I have talked to them about this, and their opinion is that there is no commercial demand for ipv6, and therefore ipv6 feature parity is on the feature roadmap. And indeed, it is difficult for the organisation I work for to demand ipv6 support, when other companies can talk to their vendors with a EUR100m firewall / networking contract going a-begging. I have little doubt that this is the reason that MOP got re-enabled by default on a certain router vendor's products. Them: "We have EUR200m to spend and we want MOP enabled by default". Vendor: "Three bags full, sir". Me: "I want to you spend $50m in development costs to support ipv6, and then i'll buy some low end kit from you" Vendor: Open source solutions tend to fare better in this regard. Lots of people may end up using them in a future ipv6 world, but you're not going to end up seeing F500 companies stampeding to replace their current high-end solutions with m0n0wall installations, just because they have more-or-less parity support for ipv4 and ipv6. There's a more interesting discussion of this of this linked from: http://www.arin.net/meetings/minutes/ARIN_XX/ppm.html See the talk entitled "IPv6 Support Among Commercial Firewalls", by Dave Piscitello. Nick -- Network Ability Ltd. | Technical Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From michael.dillon at bt.com Sun Oct 28 20:35:59 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 28 Oct 2007 19:35:59 -0000 Subject: [address-policy-wg] Commercial IPv6 firewall support In-Reply-To: <20071027142541.GA18426@muffin.acquirer.com> References: <20071027142541.GA18426@muffin.acquirer.com> Message-ID: > There is, of course, "support" and support when talking about > any feature, whether ipv6 related or not. Indeed. By that standard, there just is not the required support to run an IPv4 network using Cisco or Juniper equipment so we might as well all go home now. > There > are piles more features which just aren't there if you use > v6. All the more reason to start using v6 seriously, in testing labs limited release testing with volunteer guinea pigs. IPv6 will not magically grow all the bells and whistles that 15 years of commercial Internet use has given to IPv4. We need to use it, find the problems and escalate them. And we need to do this *BEFORE* IPv4 runs out in two to three years or else a lot of heads will roll. > I seriously doubt > that they would achieve feature parity, not to mind stability > parity for these features. Fortunately, we don't have to run faster than the bear, just faster than the other guy. And we don't have to solve all problems with IPv6, just the ones that we can because IPv4 will still be around. Ideally, we will all be able to adjust things so that we can continue growing the network using IPv6 while all the hardest stuff keeps running on IPv4. > I have talked to them about this, and their opinion is that > there is no commercial demand for ipv6, and therefore ipv6 > feature parity is on the feature roadmap. I believe I said something about a gap in the market that some smart startup companies will fill. It's not just network operators who take a risk by burying their heads in the sand. > Open source solutions tend to fare better in this regard. > Lots of people may end up using them in a future ipv6 world, > but you're not going to end up seeing F500 companies > stampeding to replace their current high-end solutions with > m0n0wall installations, just because they have more-or-less > parity support for ipv4 and ipv6. No, but you will see startups leveraging the advanced state of open source software to create supported products that an F500 company would purchase. --Michael Dillon From president at ukraine.su Sun Oct 28 23:14:38 2007 From: president at ukraine.su (Max Tulyev) Date: Mon, 29 Oct 2007 00:14:38 +0200 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> Message-ID: <472509CE.10202@ukraine.su> What will be later, when there will be no free IPv4 address space? First, the "black market", where companies sell address space each other, but not make changes in RIPE BD. Second (later?), address space as the valuable resource will be sold together with companies it owns, like sometimes it happens with radio frequency licenses. This will mostly happens with PI space. It is really worst than clear market, isn't it? Iljitsch van Beijnum wrote: > On 23-okt-2007, at 12:26, Gert Doering wrote: > >> It is envisioned that this market is going to happen, whether we like >> it or not, and there is not much we can do against it. > >> But in the case that this *is* going to happen, we would very much prefer >> to have accurate records on who is holding the address space - and this >> proposal is trying to build the basis for this. > > Once it becomes possible to sell address space we can kiss any chance of > any of the legacy space coming back goodbye. Even the slightest step in > this direction can be very harmful. > > I don't see the need to make things easier for people who do things that > they aren't supposed to do. If I "lend" some of my address space to > someone else, why should I be spared the inconvencience of being > contacted when an issue comes up with the use of that space? Presumably, > I remember who I lended the address space to, and if not, it's hard to > hide in the routing table. > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From jwkckid1 at ix.netcom.com Mon Oct 29 07:59:48 2007 From: jwkckid1 at ix.netcom.com (jwkckid1 at ix.netcom.com) Date: Mon, 29 Oct 2007 01:59:48 -0500 (GMT-05:00) Subject: [address-policy-wg] Commercial IPv6 firewall support Message-ID: <28319819.1193641188654.JavaMail.root@elwamui-sweet.atl.sa.earthlink.net> Nick and all, Chiming in here as a kinda unusual occurance. I agree with Nicks assessment here unfortunately. Seems across a broad business spectrum a disinterest in IPv6 remains or presists. Given, what I believe to be an accurate essesment by Nick below, it would seem that a more concerted effort to make IPv6 more palatable in very short order is advisable. As to how to accomplish that, I do not know. -----Original Message----- >From: Nick Hilliard >Sent: Oct 27, 2007 9:25 AM >To: michael.dillon at bt.com >Cc: address-policy-wg at ripe.net, ipv6-wg at ripe.net >Subject: Re: [address-policy-wg] Commercial IPv6 firewall support > >> Some people have claimed that they cannot yet sell >> IPv6 Internet access because there is no IPv6 firewall >> support. According to this ICANN study: >> http://www.icann.org/committees/security/sac021.pdf >> this is not quite true. At least 30% of the 42 vendors >> surveyed, had IPv6 support. > >There is, of course, "support" and support when talking about any feature, >whether ipv6 related or not. > >As a useful example of what "support" implies, the "support" from one of my >firewall vendors includes basic support for ipv6 packet forwarding and >filtering, but no support for configuring this from the GUI. And no support >for failover / failback on ipv6. And no support for ospfv3. Or DHCPv6. Or >v6 support for VPNs. And so on - you get the idea. There are piles more >features which just aren't there if you use v6. In fact, I would suggest >that there is such a large functionality gap between their ipv4 and ipv6 >support right now, that even if they invested heavily between now and the >current expected dates for ipv4 exhaustion, I seriously doubt that they >would achieve feature parity, not to mind stability parity for these >features. > >I have talked to them about this, and their opinion is that there is no >commercial demand for ipv6, and therefore ipv6 feature parity is on the >feature roadmap. And indeed, it is difficult for the organisation I work >for to demand ipv6 support, when other companies can talk to their vendors >with a EUR100m firewall / networking contract going a-begging. I have >little doubt that this is the reason that MOP got re-enabled by default on a >certain router vendor's products. > > >Them: "We have EUR200m to spend and we want MOP enabled by default". >Vendor: "Three bags full, sir". > >Me: "I want to you spend $50m in development costs to support ipv6, and > then i'll buy some low end kit from you" >Vendor: > >Open source solutions tend to fare better in this regard. Lots of people >may end up using them in a future ipv6 world, but you're not going to end up >seeing F500 companies stampeding to replace their current high-end solutions >with m0n0wall installations, just because they have more-or-less parity >support for ipv4 and ipv6. > >There's a more interesting discussion of this of this linked from: > >http://www.arin.net/meetings/minutes/ARIN_XX/ppm.html > >See the talk entitled "IPv6 Support Among Commercial Firewalls", by Dave >Piscitello. > >Nick > >-- >Network Ability Ltd. | Technical Operations | Tel: +353 1 6169698 >3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 >Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie > 'Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1 at ix.netcom.com From iljitsch at muada.com Mon Oct 29 14:47:12 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 29 Oct 2007 14:47:12 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <472509CE.10202@ukraine.su> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> Message-ID: <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> On 28 okt 2007, at 23:14, Max Tulyev wrote: > What will be later, when there will be no free IPv4 address space? If you have IPv4 address space, you'll be able to continue using it as before. If you are in need of new address space, your choice is to go hunt for IPv4 space, which will get harder and harder, or upgrade to IPv6, which will become easier and easier. > First, the "black market", where companies sell address space each > other, but not make changes in RIPE BD. > Second (later?), address space as the valuable resource will be sold > together with companies it owns, like sometimes it happens with radio > frequency licenses. This will mostly happens with PI space. > It is really worst than clear market, isn't it? The best solution is NO market and reclaiming address space that is unused. The two main issues that I have with an address market are: 1. unused address space becomes valuable so it won't be returned for free 2. it's unfair that people who got a lot of address space for free (almost always in rich countries) get to make money from it From president at ukraine.su Mon Oct 29 15:10:00 2007 From: president at ukraine.su (Max Tulyev) Date: Mon, 29 Oct 2007 16:10:00 +0200 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> Message-ID: <4725E9B8.9040301@ukraine.su> Iljitsch van Beijnum wrote: > If you are in need of new address space, your choice is to go hunt for > IPv4 space, which will get harder and harder, or upgrade to IPv6, which > will become easier and easier. IPv6 Internet is working even now, but completely useless. Because of there is no resources at all. In my opinion, the concrete goal is make 51% of _resources_ (not users) to be reachable through IPv6 before we run out of IPv4. If it succeeds, other 49% will go with "the majority", if not - IPv6 migration completely fails and something other (NAT, secondary market of IPv4, higher level proxies over non-IP protocols, ...) will be implemented instead. >> First, the "black market", where companies sell address space each >> other, but not make changes in RIPE BD. >> Second (later?), address space as the valuable resource will be sold >> together with companies it owns, like sometimes it happens with radio >> frequency licenses. This will mostly happens with PI space. > >> It is really worst than clear market, isn't it? > > The best solution is NO market and reclaiming address space that is unused. > > The two main issues that I have with an address market are: > > 1. unused address space becomes valuable so it won't be returned for free > > 2. it's unfair that people who got a lot of address space for free > (almost always in rich countries) get to make money from it Do you really believe it can be in the wild? :) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From leo.vegoda at icann.org Mon Oct 29 15:32:26 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 29 Oct 2007 15:32:26 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> Message-ID: <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> On 29 Oct 2007, at 14:47, Iljitsch van Beijnum wrote: [...] > The best solution is NO market and reclaiming address space that is > unused. How much of the currently allocated IPv4 address space do you believe is unused? How much do you think a reclaim programme would cost to run? Regards, Leo From iljitsch at muada.com Mon Oct 29 15:52:12 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 29 Oct 2007 15:52:12 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <4725E9B8.9040301@ukraine.su> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <4725E9B8.9040301@ukraine.su> Message-ID: On 29 okt 2007, at 15:10, Max Tulyev wrote: >> If you are in need of new address space, your choice is to go hunt >> for >> IPv4 space, which will get harder and harder, or upgrade to IPv6, >> which >> will become easier and easier. > IPv6 Internet is working even now, but completely useless. Because of > there is no resources at all. I don't need an IPv4 address to talk to my mail server in order to send this message. (Although the mail server still needs an IPv4 address; RIPE's mailservers are IPv4-only ...) So even though you can't do a search and replace and get rid of IPv4 everywhere today, I'm pretty sure EVERYONE can add more IPv6 than they have now. > In my opinion, the concrete goal is make 51% of _resources_ (not > users) > to be reachable through IPv6 before we run out of IPv4. If it > succeeds, > other 49% will go with "the majority", if not - IPv6 migration > completely fails and something other (NAT, secondary market of IPv4, > higher level proxies over non-IP protocols, ...) will be implemented > instead. I don't think it's a good use of our time to consider the possible failure of IPv6. Adoption will be slow, but the future goes on for a long time, it doesn't have to be fast, we can still get where we need to be eventually as long as we keep going in the right direction. Iljitsch From iljitsch at muada.com Mon Oct 29 16:09:28 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 29 Oct 2007 16:09:28 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <4725F286.5090905@titley.com> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> Message-ID: <18CD699C-F5B7-4F40-97A7-2E862F604066@muada.com> On 29 okt 2007, at 15:47, Nigel Titley wrote: >>> The best solution is NO market and reclaiming address space that >>> is unused. >> How much of the currently allocated IPv4 address space do you >> believe is unused? About half the ~ 40 legacy /8 assignments don't show up in the routing table. >> How much do you think a reclaim programme would cost to run? Don't know; don't care too much. Let the people who want the addresses pay for it. > And we've tried appealing to people's better natures to return > unused space. The result confirmed what most of us thought already: > people mostly don't have better natures. So appeal to something we know they do have. :-) > So the next phase is to encourage them to return addresses into the > pool (and remember, it doesn't matter whether they return via the > RIRs or not, as long as they become usable) by allowing them to > sell, buy or barter. Just you writing this gives them a reason to not return the space. The negative consequences of trading address space outweigh the positive ones. We're going to run out, the only question is if it's going to be a year or two sooner or later, and wheter it's going to be "we're all out" or "you want buy some IPs, I give you real good price, /8 for only $10/IP". Trading something that's in demand but has no supply will lead to hoarding, reducing availability or at the very least making it unpredictable. > IPv4 space has a limited life anyway. Once we hit 51% of traffic > being IPv6 there will be a rapid flip-flop and IPv4 will be dead. A > market in V4 addresses will at least allow network designers to put > a real cost on not switching to IPv6 and may actually result in > business cases being built. This will speed the adoption of IPv6. > This is one of the aims of our proposal I'm against address trading, but there are bad ways to do it and much worse. I suggest that we first come to a world-wide consensus on whether we want to do it. If so, then we can talk about the mechanism. From mpb at melitacable.com Mon Oct 29 16:14:02 2007 From: mpb at melitacable.com (Mark Pace Balzan) Date: Mon, 29 Oct 2007 16:14:02 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <4725E9B8.9040301@ukraine.su> Message-ID: <6A200388CCDEE04485DA0BB2BA064E3102883B07@TANGO.melita.local> > > IPv6 Internet is working even now, but completely useless. Because of > there is no resources at all. > > In my opinion, the concrete goal is make 51% of _resources_ > (not users) > to be reachable through IPv6 before we run out of IPv4. If it > succeeds, > other 49% will go with "the majority", if not - IPv6 migration > completely fails and something other (NAT, secondary market of IPv4, > higher level proxies over non-IP protocols, ...) will be implemented > instead. > my 2c worth: v4 and v6 will co-exist for a while, whether we like it or not, and therefore v4 and v6 stuff will need a way to get to each other depending on the service at hand. So quite frankly, I don't see the real advantage of moving 'content' over to v6 any more than moving 'users'. I believe every operator/network/service/whatever has to make the effort to deploy and connect to the v6 world in their interest. NAT has been here for a while, and I don't view it as v6 failure. Regards Mark From david.conrad at icann.org Mon Oct 29 16:19:29 2007 From: david.conrad at icann.org (David Conrad) Date: Mon, 29 Oct 2007 08:19:29 -0700 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <18CD699C-F5B7-4F40-97A7-2E862F604066@muada.com> Message-ID: >>> How much of the currently allocated IPv4 address space do you >>> believe is unused? > About half the ~ 40 legacy /8 assignments don't show up in the routing > table. Which, of course, means precisely nothing. >>> How much do you think a reclaim programme would cost to run? > Don't know; don't care too much. Let the people who want the addresses > pay for it. I thought you didn't want a market? > Trading something that's in demand but has no supply > will lead to hoarding, reducing availability or at the very least > making it unpredictable. The address space in question is already allocated, hence unavailable. The question is how to incent folks to put their "allocated but unused" address space back into play. Stamping your foot and declaring "markets are bad" isn't likely to be too helpful. Regards, -drc From nigel at titley.com Mon Oct 29 15:47:34 2007 From: nigel at titley.com (Nigel Titley) Date: Mon, 29 Oct 2007 14:47:34 +0000 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> Message-ID: <4725F286.5090905@titley.com> Leo Vegoda wrote: > On 29 Oct 2007, at 14:47, Iljitsch van Beijnum wrote: > > [...] > >> The best solution is NO market and reclaiming address space that is >> unused. > > How much of the currently allocated IPv4 address space do you believe > is unused? How much do you think a reclaim programme would cost to run? And we've tried appealing to people's better natures to return unused space. The result confirmed what most of us thought already: people mostly don't have better natures. So the next phase is to encourage them to return addresses into the pool (and remember, it doesn't matter whether they return via the RIRs or not, as long as they become usable) by allowing them to sell, buy or barter. IPv4 space has a limited life anyway. Once we hit 51% of traffic being IPv6 there will be a rapid flip-flop and IPv4 will be dead. A market in V4 addresses will at least allow network designers to put a real cost on not switching to IPv6 and may actually result in business cases being built. This will speed the adoption of IPv6. This is one of the aims of our proposal Leo has already proved that a (fairly simple) reclamation job takes a lot of time and resource. This is for a /8 that no one much wanted and no one much used. Nigel From michael.dillon at bt.com Mon Oct 29 16:38:37 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 29 Oct 2007 15:38:37 -0000 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: <18CD699C-F5B7-4F40-97A7-2E862F604066@muada.com> Message-ID: > The address space in question is already allocated, hence > unavailable. The question is how to incent folks to put > their "allocated but unused" address space back into play. > Stamping your foot and declaring "markets are bad" > isn't likely to be too helpful. And thinking that you can influence address-holders decision making without pricing an IPv4 at several hundred thousand dollars, is also not likely to be too helpful. Any organization who contemplates selling a block of IPv4 addresses has to conside the reality that it would be an extremely constrained market where the supply is going down and they are not making any new IPv4 addresses. This means that if you do sell, and then discover that you needed those addresses after all, the price to buy them back could be substantially higher than your sale price. In the face of continually rising prices, it is risky to sell any addresses at all, unless you are absolutely certain, at the CEO/board level, that the addresses are not needed, or if the price that you would receive is at least several hundred thousand dollars. This is a recipe for a gold-rush style market followed by liquidity collapse which will have additional knock-on effects in the real markets, i.e. share prices. --Michael Dillon From elmi at 4ever.de Mon Oct 29 16:18:36 2007 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 29 Oct 2007 16:18:36 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <18CD699C-F5B7-4F40-97A7-2E862F604066@muada.com> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> <18CD699C-F5B7-4F40-97A7-2E862F604066@muada.com> Message-ID: <20071029151835.GW66222@ronin.4ever.de> iljitsch at muada.com (Iljitsch van Beijnum) wrote: > >>>The best solution is NO market and reclaiming address space that > >>>is unused. > > >>How much of the currently allocated IPv4 address space do you > >>believe is unused? > > About half the ~ 40 legacy /8 assignments don't show up in the routing > table. Which does not mean these networks are unused and/or reclaimable. (And does not mean otherwise, too) > The negative consequences of trading address space outweigh the > positive ones. Trading address space is going to come, whether we like it or not. If we can get people to use the white market instead of the black market, good. But markets either colour will exist. Of course, if every DFZ-routing party cooperates with the RIRs and/or routing registries, black markets can be counteracted. But you tell me the odds of that happening ;) Yours, Elmar. From michael.dillon at bt.com Mon Oct 29 16:41:23 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 29 Oct 2007 15:41:23 -0000 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <4725F286.5090905@titley.com> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> Message-ID: > And we've tried appealing to people's better natures to > return unused space. The result confirmed what most of us > thought already: people mostly don't have better natures. Then how do you explain the success that IANA have had in recovering address space as reported by Bill Manning and now, Leo Vegoda, over the past 10 years or so? > Leo has already proved that a (fairly simple) reclamation job > takes a lot of time and resource. This is for a /8 that no > one much wanted and no one much used. What proof do you have that this was simple? --Michael Dillon From tim.streater at dante.org.uk Mon Oct 29 17:06:15 2007 From: tim.streater at dante.org.uk (Tim Streater) Date: Mon, 29 Oct 2007 16:06:15 +0000 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <6A200388CCDEE04485DA0BB2BA064E3102883B07@TANGO.melita.loca l> References: <4725E9B8.9040301@ukraine.su> <6A200388CCDEE04485DA0BB2BA064E3102883B07@TANGO.melita.local> Message-ID: At 15:14 29/10/2007, Mark Pace Balzan wrote: > > > > IPv6 Internet is working even now, but completely useless. Because of > > there is no resources at all. > > > > In my opinion, the concrete goal is make 51% of _resources_ > > (not users) > > to be reachable through IPv6 before we run out of IPv4. If it > > succeeds, > > other 49% will go with "the majority", if not - IPv6 migration > > completely fails and something other (NAT, secondary market of IPv4, > > higher level proxies over non-IP protocols, ...) will be implemented > > instead. > > > >my 2c worth: > >v4 and v6 will co-exist for a while, whether we like it or not, and >therefore v4 and v6 stuff will need a way to get to each other depending >on the service at hand. They will co-exist for a long while due to lack of pressure from the users. If v4 really runs out, there will start to be some parts of the Internet that are not accessible to some users. Then they will complain to their ISP and something starts to happen. Then it gets in the mainstream press, at which point you may see a more rapid transition. Plenty of people will however say, why should I bother to get a new xxx box when I can reach all sites I care about. Unless the govts get involved, of course. -- Tim From jordi.palet at consulintel.es Mon Oct 29 17:47:52 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 29 Oct 2007 09:47:52 -0700 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: Message-ID: I think the users will not need to push the ISPs, in general. The fact is that there is much more IPv6 traffic that what we believe, transition traffic, and this will impact the ISPs once they start realizing it, hopefully as soon as possible, so they can take measures, for example, deploying local 6to4 and Teredo relays, so the RTT get lower and IPv6 connectivity improves. Of course, only as a temporary measure until they can provide dual-stack in the access and customers have dual-stack enabled CPEs, possibly with other reasons for replacing them, such as new broadband technologies (more bandwidth, etc.). Here is my talk in the last meeting plenary with the traffic stats ... http://www.ripe.net/ripe/meetings/ripe-55/presentations/palet-v6.pdf Looking for a more global measurement, so I can report a much broader view, but I don't think it will change too much from what I've seen already :-) Regards, Jordi > De: Tim Streater > Responder a: > Fecha: Mon, 29 Oct 2007 16:06:15 +0000 > Para: Mark Pace Balzan , Max Tulyev > , > Asunto: RE: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods > for Reallocation of IPv4 Resources) > > At 15:14 29/10/2007, Mark Pace Balzan wrote: > > >>> >>> IPv6 Internet is working even now, but completely useless. Because of >>> there is no resources at all. >>> >>> In my opinion, the concrete goal is make 51% of _resources_ >>> (not users) >>> to be reachable through IPv6 before we run out of IPv4. If it >>> succeeds, >>> other 49% will go with "the majority", if not - IPv6 migration >>> completely fails and something other (NAT, secondary market of IPv4, >>> higher level proxies over non-IP protocols, ...) will be implemented >>> instead. >>> >> >> my 2c worth: >> >> v4 and v6 will co-exist for a while, whether we like it or not, and >> therefore v4 and v6 stuff will need a way to get to each other depending >> on the service at hand. > > > They will co-exist for a long while due to lack of pressure from the users. If > v4 really runs out, there will start to be some parts of the Internet that are > not accessible to some users. Then they will complain to their ISP and > something starts to > happen. Then it gets in the mainstream press, at which point you may see a > more rapid transition. Plenty of people will however say, why should I bother > to get a new xxx box when I can reach all sites I care about. > > Unless the govts get involved, of course. > > -- Tim > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From matthew.ford at bt.com Mon Oct 29 18:55:39 2007 From: matthew.ford at bt.com (matthew.ford at bt.com) Date: Mon, 29 Oct 2007 17:55:39 -0000 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: Message-ID: Hi Jordi, > Here is my talk in the last meeting plenary with the > traffic stats ... > http://www.ripe.net/ripe/meetings/ripe-55/presentation s/palet-v6.pdf Those slides don't mention what network the stats refer to. Care to share? Cheers, Mat From david.conrad at icann.org Mon Oct 29 19:01:19 2007 From: david.conrad at icann.org (David Conrad) Date: Mon, 29 Oct 2007 11:01:19 -0700 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: Message-ID: Michael, On 10/29/07 8:38 AM, "michael.dillon at bt.com" wrote: >> The address space in question is already allocated, hence >> unavailable. The question is how to incent folks to put >> their "allocated but unused" address space back into play. >> Stamping your foot and declaring "markets are bad" >> isn't likely to be too helpful. > > And thinking that you can influence address-holders decision making > without pricing an IPv4 at several hundred thousand dollars, is also not > likely to be too helpful. The price point at which people are influenced is a bit beyond my psychic abilities to divine. I believe the appropriate phrase here is "what the market will bear". > Any organization who contemplates selling a block of IPv4 addresses has > to conside the reality ... And the appropriate phrase here would be "buyer (and seller) beware". The fact that a black (or grey) market exists would seem to imply there are people who have made the evaluation that it is in their best interests to sell off address space they do not need. Regards, -drc From david.conrad at icann.org Mon Oct 29 19:11:17 2007 From: david.conrad at icann.org (David Conrad) Date: Mon, 29 Oct 2007 11:11:17 -0700 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: Message-ID: On 10/29/07 8:41 AM, "michael.dillon at bt.com" wrote: >> And we've tried appealing to people's better natures to >> return unused space. The result confirmed what most of us >> thought already: people mostly don't have better natures. > > Then how do you explain the success that IANA have had in recovering > address space as reported by Bill Manning and now, Leo Vegoda, over the > past 10 years or so? "low hanging fruit". >> Leo has already proved that a (fairly simple) reclamation job >> takes a lot of time and resource. This is for a /8 that no >> one much wanted and no one much used. > > What proof do you have that this was simple? 14/8 was defined by the IETF to be used to interconnect X.25 networks to the Internet. As you might imagine, the addresses in that /8 weren't in particularly active use. I'll let Leo provide more details if he likes. There may one or two other /8s that IANA or the RIRs might be able to reclaim, but I wouldn't hold my breath... Regards, -drc From jordi.palet at consulintel.es Mon Oct 29 19:16:17 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 29 Oct 2007 11:16:17 -0700 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: Message-ID: Hi Mat, I guess it will be clear when the audio/video is available. I explained in my presentation that this is our own network. We have several services which are dual-stack, but my view is that most of the traffic is peer to peer traffic that is being "attracted" to our network because we offer an open public 6to4 and Teredo relay, in addition to the tunnel broker. This may sound as a biased measurement, but actually I don't think so. If we don't have those relays running, this peer-to-peer traffic will be going thru other relays, right ? So unless there is no any relay ... it means that it is logic to assume that the global traffic may become close to those figures, and I guess this will be more true in the next few months, as more and more folks use Vista (and other IPv6 enabled OSs) which automatically use transition mechanisms, and as much more applications take advantage of that. My intend to confirm this, is to decide how to distribute this measurement tool to several ISPs in each region, and then have a regional and global picture of what is actually happening, in such way that we can extrapolate overall IPv6 traffic. As we are measuring transition and I don't expect that the native one will grow too much unless many ISPs start offering dual stack in the access, it is not required that those ISPs being measured have native support at all. Of course, I don't expect that they will have so much transition traffic unless they offer also 6to4 and Teredo relays, however my guess, is that they will be still having more than what they actually though. Regards, Jordi > De: > Responder a: > Fecha: Mon, 29 Oct 2007 17:55:39 -0000 > Para: > CC: > Conversaci?n: [address-policy-wg] 2007-08 New Policy Proposal (Enabling > Methods for Reallocation of IPv4 Resources) > Asunto: RE: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods > for Reallocation of IPv4 Resources) > > Hi Jordi, > >> Here is my talk in the last meeting plenary with the >> traffic stats ... >> http://www.ripe.net/ripe/meetings/ripe-55/presentation > s/palet-v6.pdf > > Those slides don't mention what network the stats refer to. Care to > share? > > > Cheers, > Mat > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From nigel at titley.com Mon Oct 29 18:23:10 2007 From: nigel at titley.com (Nigel Titley) Date: Mon, 29 Oct 2007 18:23:10 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> Message-ID: <472616FE.4040103@titley.com> michael.dillon at bt.com wrote: >> And we've tried appealing to people's better natures to >> return unused space. The result confirmed what most of us >> thought already: people mostly don't have better natures. >> > > Then how do you explain the success that IANA have had in recovering > address space as reported by Bill Manning and now, Leo Vegoda, over the > past 10 years or so? > > >> Leo has already proved that a (fairly simple) reclamation job >> takes a lot of time and resource. This is for a /8 that no >> one much wanted and no one much used. >> > > What proof do you have that this was simple? Talking to Leo (and I did say "fairly simple"). Nigel From iljitsch at muada.com Mon Oct 29 22:03:34 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 29 Oct 2007 22:03:34 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <20071029151835.GW66222@ronin.4ever.de> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> <18CD699C-F5B7-4F40-97A7-2E862F604066@muada.com> <20071029151835.GW66222@ronin.4ever.de> Message-ID: On 29 okt 2007, at 16:18, Elmar K. Bins wrote: >>>> How much of the currently allocated IPv4 address space do you >>>> believe is unused? >> About half the ~ 40 legacy /8 assignments don't show up in the >> routing >> table. > Which does not mean these networks are unused I think "not present in the routing table" is a good working definiion of "unused". Is it reasonable for people to keep almost half a percent of the IPv4 address space for themselves just so they don't have to renumber into the space specifically set aside for this? > and/or reclaimable. I don't think that is knowable until someone actually tries it. If a market does happen, it will be interesting to see how much of that "unreclaimable" address space appears on that market. >> The negative consequences of trading address space outweigh the >> positive ones. > Trading address space is going to come, whether we like it or not. Murder happens too, despite the fact that most of us don't like it. We do what we can to stop it, not because we think we can eradicate it, but because every incremental reduction is worthwhile. > If we can get people to use the white market instead of the black > market, good. Why? > Of course, if every DFZ-routing party cooperates with the RIRs and/or > routing registries, black markets can be counteracted. But you tell > me the odds of that happening ;) Sometimes all it takes is a filter and some vision. Remember the Sprint prefix length filters? From iljitsch at muada.com Mon Oct 29 22:23:53 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 29 Oct 2007 22:23:53 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: Message-ID: On 29 okt 2007, at 17:47, JORDI PALET MARTINEZ wrote: > The fact is that there is much more IPv6 traffic that what we believe, I'm quickly approaching my posting limit for the day (week?) but I can't resist telling you the following story: I recently found myself somewhere where BitTorrent is severely throttled. Although I can download over HTTP at megabytes per second, BitTorrent downloads wouldn't go faster than 10 kilobytes per second. Turns out that the newest Azureus (BitTorrent application) supports IPv6. Enabled this and lo and behold: I got about 75 peers, 5 of which were IPv6, the rest IPv4. Of the IPv6 peers, one had a regular IPv6 address, the other four 6to4 addresses. Even though the 70 IPv4 peers could only give me 10 kB/s, the 5 IPv6 peers pushed my download well beyond 100 kB/s. So under the right circumstances, a little IPv6 can go a long way. From iljitsch at muada.com Mon Oct 29 22:15:58 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 29 Oct 2007 22:15:58 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: Message-ID: <56E83263-ABCA-4532-A761-BCE3C57F7886@muada.com> On 29 okt 2007, at 16:19, David Conrad wrote: >> About half the ~ 40 legacy /8 assignments don't show up in the >> routing >> table. > Which, of course, means precisely nothing. The value of an IP address is the ability to receive packets from elsewhere addressed to it. Without a presence in a routing table someplace, that doesn't happen so the IP address is of no value. Better give it back so someone else who can instill it with exactly that value in that case... >>>> How much do you think a reclaim programme would cost to run? >> Don't know; don't care too much. Let the people who want the >> addresses >> pay for it. > I thought you didn't want a market? There is no market in passports. Doesn't mean you get it for free. >> Trading something that's in demand but has no supply >> will lead to hoarding, reducing availability or at the very least >> making it unpredictable. > The address space in question is already allocated, hence > unavailable. The > question is how to incent folks to put their "allocated but unused" > address > space back into play. Your assumption is that the value of having more addresses automatically outweighs any negative consequences from having a market. It requires herculian effort to keep the up-and-coming economies happy with the way the internet is currently "run" (if there is such a thing). What is the developing world going to say when they have to pay rich American companies for address space--address space that those companies got for free? What if a slow trickle of expensive IPv4 addresses is just enough to keep people from moving to IPv6, but at the same time stiffling the industry both technically by deeper and deeper layers of NAT and economically because it takes longer and longer and costs more and more to get new IP addresses for new businesses? There are STILL people that refuse to bother implementing IPv6 in their products, making it that much harder for their customers to adopt IPv6 in the next three years that we can reasonably sure about having current levels of IPv4 availability. Anything that these people can use as an excuse to wait even longer is extremely harmful. From iljitsch at muada.com Mon Oct 29 22:18:54 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 29 Oct 2007 22:18:54 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <4725F286.5090905@titley.com> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> Message-ID: On 29 okt 2007, at 15:47, Nigel Titley wrote: > Leo has already proved that a (fairly simple) reclamation job takes > a lot of time and resource. This is for a /8 that no one much wanted > and no one much used. Was that the 14/8 thing? Only 129 individual addresses out of 16777216 where used. Maybe just reclaiming the other 16777087 would have been more efficient. But I'm pretty sure it's too late anyway, just like it's too late to make 240/4 usable. From elmi at 4ever.de Tue Oct 30 09:30:44 2007 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 30 Oct 2007 09:30:44 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> <18CD699C-F5B7-4F40-97A7-2E862F604066@muada.com> <20071029151835.GW66222@ronin.4ever.de> Message-ID: <20071030083044.GA66222@ronin.4ever.de> Goede Iljitsch, iljitsch at muada.com (Iljitsch van Beijnum) wrote: > >Which does not mean these networks are unused > > I think "not present in the routing table" is a good working definiion > of "unused". Your perspective (and mine - I don't like that either!) is only one of many possible ways to look at the thing. > Is it reasonable for people to keep almost half a percent of the IPv4 > address space for themselves just so they don't have to renumber into > the space specifically set aside for this? I think we should refrain from discussing morals here; I believe neither of the people on the list *likes* that there is *legitimately assigned* address space out there that has never been used. > >and/or reclaimable. > I don't think that is knowable until someone actually tries it. Since the space has been assigned and/or allocated according to the regulations then effective, there is no legal (is there any at all?) or justifiable way to force those people to give their space back to a RIR. If they do so of their own account, fine; if you want to take the time and make the effort to go there and talk to the Apples, IBMs and HPs of the world, be my guest; I might even help you, because I see a good cause there. I just say - success will be very very limited, if any amount of address space can be "reclaimed" (talked out of people) at all. > If a market does happen, it will be interesting to see how much of > that "unreclaimable" address space appears on that market. That is an entirely different thing. Those people will discover that they have an *asset* they never thought of. And while their ops, networking and community people will try and prevent this from happening, management will ask them for a technical solution to be able to sell this asset, calculate cost/gain ration and *do it*. > >Trading address space is going to come, whether we like it or not. > > Murder happens too, despite the fact that most of us don't like it. We > do what we can to stop it, not because we think we can eradicate it, > but because every incremental reduction is worthwhile. You don't play nuances, do you? Well; in the "civilised western world", people are very unlikely to commit murder, but people are not very inhibited of trading their asset on a market, be it black or white. So take into account human nature outside of problem regions, and then you have a better picture. > >If we can get people to use the white market instead of the black > >market, good. > > Why? Because white market means RIR control. Sorry I didn't make clear that it meant that for me. > >Of course, if every DFZ-routing party cooperates with the RIRs and/or > >routing registries, black markets can be counteracted. But you tell > >me the odds of that happening ;) > > Sometimes all it takes is a filter and some vision. Remember the > Sprint prefix length filters? Yes. Now convince them. If they see a business case, you might even be successful. Apart from those things happening, getting efficient filtering in place that are controlled by entities we as the community trust, will need a common effort. Sorry to spoil your dreams, Elmar. From elmi at 4ever.de Tue Oct 30 09:35:20 2007 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 30 Oct 2007 09:35:20 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <20071030083044.GA66222@ronin.4ever.de> References: <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> <18CD699C-F5B7-4F40-97A7-2E862F604066@muada.com> <20071029151835.GW66222@ronin.4ever.de> <20071030083044.GA66222@ronin.4ever.de> Message-ID: <20071030083520.GB66222@ronin.4ever.de> elmi at 4ever.de (Elmar K. Bins) wrote: > I think we should refrain from discussing morals here; I believe neither > of the people on the list *likes* that there is *legitimately assigned* > address space out there that has never been used. That should read "used in the open". Sorry. Elmar. From michael.dillon at bt.com Tue Oct 30 11:02:16 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 30 Oct 2007 10:02:16 -0000 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> <18CD699C-F5B7-4F40-97A7-2E862F604066@muada.com> <20071029151835.GW66222@ronin.4ever.de> Message-ID: > I think "not present in the routing table" is a good working > definiion of "unused". Not according to RFC 2050. > If a market does happen, it will be interesting to see how > much of that "unreclaimable" address space appears on that market. Note that most of that address space which does not appear in the global routing table is actually in use on internetworks that, as a matter of policy, do not exchange packets with the public Internet. Since these are internetworks, use of RFC 1918 addressing is not possible, and since the end users of these internetworks are also connected to the public Internet, any reuse of these addresses on the public Internet could disrupt the operation of the hidden internetworks. No matter what direction these IPv4 discussions take, it just reinforces the necessity of getting IPv6 up and running as soon as possible. --Michael Dillon From jarno.lahteenmaki at imate.fi Tue Oct 30 11:02:48 2007 From: jarno.lahteenmaki at imate.fi (=?ISO-8859-1?Q?Jarno_L=E4hteenm=E4ki?=) Date: Tue, 30 Oct 2007 12:02:48 +0200 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> <18CD699C-F5B7-4F40-97A7-2E862F604066@muada.com> <20071029151835.GW66222@ronin.4ever.de> Message-ID: <47270148.3040606@imate.fi> Iljitsch van Beijnum wrote: > I think "not present in the routing table" is a good working definiion > of "unused". I disagree. I know fairly amount of legacy prefices which doesn't show up in the global routing table but are still in use in private inter networks. --> Jarno L?hteenm?ki From cfriacas at fccn.pt Tue Oct 30 14:24:43 2007 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 30 Oct 2007 13:24:43 +0000 (WET) Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <4725F286.5090905@titley.com> References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> Message-ID: On Mon, 29 Oct 2007, Nigel Titley wrote: (...) > buy or barter. IPv4 space has a limited life anyway. Once we hit 51% of > traffic being IPv6 there will be a rapid flip-flop and IPv4 will be dead. A (...) it seems pretty optimistic... and where can this % be measured? :-) cheers, ------------------------------------------------------------------------- Carlos Friac,as See: Wide Area Network Working Group (WAN) www.gigapix.pt FCCN - Fundacao para a Computacao Cientifica Nacional www.ipv6.eu Av. do Brasil, n.101 www.6diss.org 1700-066 Lisboa, Portugal, Europe www.geant2.net Tel: +351 218440100 Fax: +351 218472167 www.fccn.pt ------------------------------------------------------------------------- The end is near........ see http://ipv4.potaroo.net "Internet is just routes (217118/774), naming (billions) and... people!" Aviso de Confidencialidade Esta mensagem e' exclusivamente destinada ao seu destinatario, podendo conter informacao CONFIDENCIAL, cuja divulgacao esta' expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218440100 devendo apagar o seu conteudo de imediato. Warning This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218440100 and delete it immediately. From cfriacas at fccn.pt Tue Oct 30 14:39:38 2007 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 30 Oct 2007 13:39:38 +0000 (WET) Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: Message-ID: On Mon, 29 Oct 2007, Iljitsch van Beijnum wrote: > On 29 okt 2007, at 17:47, JORDI PALET MARTINEZ wrote: > >> The fact is that there is much more IPv6 traffic that what we believe, > > I'm quickly approaching my posting limit for the day (week?) but I can't > resist telling you the following story: > > I recently found myself somewhere where BitTorrent is severely throttled. > Although I can download over HTTP at megabytes per second, BitTorrent > downloads wouldn't go faster than 10 kilobytes per second. > > Turns out that the newest Azureus (BitTorrent application) supports IPv6. > Enabled this and lo and behold: I got about 75 peers, 5 of which were IPv6, > the rest IPv4. Of the IPv6 peers, one had a regular IPv6 address, the other > four 6to4 addresses. Even though the 70 IPv4 peers could only give me 10 > kB/s, the 5 IPv6 peers pushed my download well beyond 100 kB/s. > > So under the right circumstances, a little IPv6 can go a long way. Iljitsch, This matches with the questions i DIDN'T ask Jordi last week: p2p ipv6 traffic? but which applications are generating it? MSN? I was not aware that a "somewhat popular" bittorrent client was doing v6... I remember that some years ago, some people from 6NET and other projects approached the guy which developed the protocol and he sort of refused to cooperate in the effort of making it v6 compatible. Then, afaik some people developed a patch, but of course that didn't reflect into real usage... :-( Cheers, ------------------------------------------------------------------------- Carlos Friac,as See: Wide Area Network Working Group (WAN) www.gigapix.pt FCCN - Fundacao para a Computacao Cientifica Nacional www.ipv6.eu Av. do Brasil, n.101 www.6diss.org 1700-066 Lisboa, Portugal, Europe www.geant2.net Tel: +351 218440100 Fax: +351 218472167 www.fccn.pt ------------------------------------------------------------------------- The end is near........ see http://ipv4.potaroo.net "Internet is just routes (217118/774), naming (billions) and... people!" Aviso de Confidencialidade Esta mensagem e' exclusivamente destinada ao seu destinatario, podendo conter informacao CONFIDENCIAL, cuja divulgacao esta' expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218440100 devendo apagar o seu conteudo de imediato. Warning This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218440100 and delete it immediately. From leo.vegoda at icann.org Tue Oct 30 14:53:10 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 30 Oct 2007 14:53:10 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> Message-ID: <34834002-63E9-4F6C-AB8E-75B3A8DF9172@icann.org> On 29 Oct 2007, at 22:18, Iljitsch van Beijnum wrote: > On 29 okt 2007, at 15:47, Nigel Titley wrote: > >> Leo has already proved that a (fairly simple) reclamation job >> takes a lot of time and resource. This is for a /8 that no one >> much wanted and no one much used. > > Was that the 14/8 thing? Only 129 individual addresses out of > 16777216 where used. Maybe just reclaiming the other 16777087 would > have been more efficient. Nearly, but not quite. It was 984 addresses but your point is valid anyway. Just marking the first /22 as reserved and making the rest of the space available to the RIRs would have been easier but it isn't very neat and tidy and doesn't fit with the policy approved by the five RIR communities. At the moment the main problem with doing what you suggest is that the current global policy for allocating IPv4 space to RIRs requires us to "allocate IPv4 address space to the RIRs in /8 units." 99.99% of a /8 is close but it's not 100%. Frankly, fixing things so that the policy works is probably better than waiting until the end and publicly stating that the policy is inconvenient and so we'll ignore it. Leo From iljitsch at muada.com Tue Oct 30 15:00:59 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 30 Oct 2007 15:00:59 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: Message-ID: <637C5F7D-31B3-43F2-8392-5E3EF9212C67@muada.com> On 30 okt 2007, at 14:39, Carlos Friacas wrote: >> Turns out that the newest Azureus (BitTorrent application) supports >> IPv6. > I was not aware that a "somewhat popular" bittorrent client was > doing v6... > I remember that some years ago, some people from 6NET and other > projects approached the guy which developed the protocol and he sort > of refused to cooperate in the effort of making it v6 compatible. > Then, afaik some people developed a patch, but of course that didn't > reflect into real usage... :-( Hm, the way I understand it is that the original BitTorrent protocol (not the original client, AFAIK) supported IPv6. However, the protocol was later streamlined and IPv6 support dropped, I think by other people. There's also the issue that you must choose one address to tell the tracker, and trackers may have their own opinions about IPv6 addresses. However, these days most BitTorrent clients use dynamic hash tables in addition to a centralized tracker and I believe IPv6 is used for/ through the DHT. From jordi.palet at consulintel.es Tue Oct 30 16:10:49 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 30 Oct 2007 08:10:49 -0700 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: Message-ID: Hi Carlos, Well with the tool we developed (see my Friday presentation), hopefully we will convince a couple of ISPs in every region and we will have in a few months regional and global traffic measurements. Those ISPs don't need to have native IPv6 support, traffic is there anyway ! Regards, Jordi > De: Carlos Friacas > Responder a: > Fecha: Tue, 30 Oct 2007 13:24:43 +0000 (WET) > Para: Nigel Titley > CC: > Asunto: Re: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods > for Reallocation of IPv4 Resources) > > On Mon, 29 Oct 2007, Nigel Titley wrote: > > (...) >> buy or barter. IPv4 space has a limited life anyway. Once we hit 51% of >> traffic being IPv6 there will be a rapid flip-flop and IPv4 will be dead. A > (...) > > it seems pretty optimistic... > > and where can this % be measured? :-) > > > cheers, > > ------------------------------------------------------------------------- > Carlos Friac,as See: > Wide Area Network Working Group (WAN) www.gigapix.pt > FCCN - Fundacao para a Computacao Cientifica Nacional www.ipv6.eu > Av. do Brasil, n.101 www.6diss.org > 1700-066 Lisboa, Portugal, Europe www.geant2.net > Tel: +351 218440100 Fax: +351 218472167 > www.fccn.pt > ------------------------------------------------------------------------- > The end is near........ see http://ipv4.potaroo.net > "Internet is just routes (217118/774), naming (billions) and... people!" > > > Aviso de Confidencialidade > Esta mensagem e' exclusivamente destinada ao seu destinatario, podendo > conter informacao CONFIDENCIAL, cuja divulgacao esta' expressamente > vedada nos termos da lei. Caso tenha recepcionado indevidamente esta > mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta > via ou para o telefone +351 218440100 devendo apagar o seu conteudo > de imediato. > > Warning > This message is intended exclusively for its addressee. > It may contain CONFIDENTIAL information protected by law. If this > message has been received by error, please notify us via e-mail or by > telephone +351 218440100 and delete it immediately. > From jordi.palet at consulintel.es Tue Oct 30 16:22:16 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 30 Oct 2007 08:22:16 -0700 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: Message-ID: And the same is true with many other apps, such as Windows Live, newer versions or on-line games, etc. It is clear that with IPv6 and automatic transition mechanisms, you can avoid intermediate servers and do a real peer-to-peer. No need for developing special code for NAT traversal and other stuff. Other developers are already discovering this and I'm convinced that in less than one year the 51% that you mention in another email will be exceeded ! So again: Please, all ISPs start deploying 6to4 and Teredo relays in your networks until you can provide dual-stack to the access. I'm happy to help on that ! Regards, Jordi > De: Iljitsch van Beijnum > Responder a: > Fecha: Mon, 29 Oct 2007 22:23:53 +0100 > Para: > CC: > Asunto: Re: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods > for Reallocation of IPv4 Resources) > > On 29 okt 2007, at 17:47, JORDI PALET MARTINEZ wrote: > >> The fact is that there is much more IPv6 traffic that what we believe, > > I'm quickly approaching my posting limit for the day (week?) but I > can't resist telling you the following story: > > I recently found myself somewhere where BitTorrent is severely > throttled. Although I can download over HTTP at megabytes per second, > BitTorrent downloads wouldn't go faster than 10 kilobytes per second. > > Turns out that the newest Azureus (BitTorrent application) supports > IPv6. Enabled this and lo and behold: I got about 75 peers, 5 of which > were IPv6, the rest IPv4. Of the IPv6 peers, one had a regular IPv6 > address, the other four 6to4 addresses. Even though the 70 IPv4 peers > could only give me 10 kB/s, the 5 IPv6 peers pushed my download well > beyond 100 kB/s. > > So under the right circumstances, a little IPv6 can go a long way. > From mohacsi at niif.hu Tue Oct 30 20:37:07 2007 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 30 Oct 2007 20:37:07 +0100 (CET) Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <637C5F7D-31B3-43F2-8392-5E3EF9212C67@muada.com> References: <637C5F7D-31B3-43F2-8392-5E3EF9212C67@muada.com> Message-ID: <20071030203040.S98862@mignon.ki.iif.hu> - Bittornado, Azureus, Transmission, BTG, Opera builtin torrent client support IPv6. Have a look: http://www.sixxs.net/tools/tracker/clients/ or http://ipv6.niif.hu/index.php?mn=3&sm=5&lg=en Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Tue, 30 Oct 2007, Iljitsch van Beijnum wrote: > On 30 okt 2007, at 14:39, Carlos Friacas wrote: > >>> Turns out that the newest Azureus (BitTorrent application) supports IPv6. > >> I was not aware that a "somewhat popular" bittorrent client was doing v6... >> I remember that some years ago, some people from 6NET and other projects >> approached the guy which developed the protocol and he sort of refused to >> cooperate in the effort of making it v6 compatible. Then, afaik some people >> developed a patch, but of course that didn't reflect into real usage... :-( > > Hm, the way I understand it is that the original BitTorrent protocol (not the > original client, AFAIK) supported IPv6. However, the protocol was later > streamlined and IPv6 support dropped, I think by other people. There's also > the issue that you must choose one address to tell the tracker, and trackers > may have their own opinions about IPv6 addresses. > > However, these days most BitTorrent clients use dynamic hash tables in > addition to a centralized tracker and I believe IPv6 is used for/through the > DHT. > From cfriacas at fccn.pt Tue Oct 30 21:07:55 2007 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 30 Oct 2007 20:07:55 +0000 (WET) Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: Message-ID: On Tue, 30 Oct 2007, JORDI PALET MARTINEZ wrote: > Hi Carlos, Hi. > Well with the tool we developed (see my Friday presentation), DevelopED? Do you plan to freely share it? > hopefully we > will convince a couple of ISPs in every region and we will have in a few > months regional and global traffic measurements. We've deployed a 6TO4 relay for quite some time, which mostly serves all portuguese ISPs that accept 192.88.99.0/24 from us, but no work about monitoring it has been done so far. :-) > Those ISPs don't need to have native IPv6 support, traffic is there anyway ! I don't really like the first part of your sentence. :-)) > Regards, > Jordi Regards, ------------------------------------------------------------------------- Carlos Friac,as See: Wide Area Network Working Group (WAN) www.gigapix.pt FCCN - Fundacao para a Computacao Cientifica Nacional www.ipv6.eu Av. do Brasil, n.101 www.6diss.org 1700-066 Lisboa, Portugal, Europe www.geant2.net Tel: +351 218440100 Fax: +351 218472167 www.fccn.pt ------------------------------------------------------------------------- The end is near........ see http://ipv4.potaroo.net "Internet is just routes (217118/774), naming (billions) and... people!" Aviso de Confidencialidade Esta mensagem e' exclusivamente destinada ao seu destinatario, podendo conter informacao CONFIDENCIAL, cuja divulgacao esta' expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218440100 devendo apagar o seu conteudo de imediato. Warning This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218440100 and delete it immediately. From cfriacas at fccn.pt Tue Oct 30 21:52:08 2007 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 30 Oct 2007 20:52:08 +0000 (WET) Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: Message-ID: On Tue, 30 Oct 2007, JORDI PALET MARTINEZ wrote: > And the same is true with many other apps, such as Windows Live, newer > versions ...any wireshark/tcpdump data? > or on-line games, etc. ...which? > It is clear that with IPv6 and automatic transition mechanisms, you can > avoid intermediate servers and do a real peer-to-peer. No need for > developing special code for NAT traversal and other stuff. That works if the transition relay: - is geographically near endpoints (hence, a good idea to deploy more...) - isn't lying on badly designed or congested infrastructure. > Other developers are already discovering this and I'm convinced that in less > than one year the 51% that you mention in another email will be exceeded ! One year??? Guiness-Class Optimism!!! ;-) > So again: Please, all ISPs start deploying 6to4 and Teredo relays in your > networks until you can provide dual-stack to the access. I'm happy to help > on that ! > > Regards, > Jordi Regards, Carlos From gih at apnic.net Wed Oct 31 00:04:52 2007 From: gih at apnic.net (Geoff Huston) Date: Wed, 31 Oct 2007 10:04:52 +1100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: <20071023092028.141B42F583@herring.ripe.net> <20071023102602.GY34650@Space.Net> <472509CE.10202@ukraine.su> <9B3962BE-6B2F-4D72-9D12-91294EDEF1AE@muada.com> <6DB9F629-0AFF-4C34-B5E5-601466596CE6@icann.org> <4725F286.5090905@titley.com> Message-ID: <4727B894.9090500@apnic.net> Iljitsch van Beijnum wrote: > On 29 okt 2007, at 15:47, Nigel Titley wrote: > >> Leo has already proved that a (fairly simple) reclamation job takes a >> lot of time and resource. This is for a /8 that no one much wanted and >> no one much used. > > Was that the 14/8 thing? Only 129 individual addresses out of 16777216 > where used. Maybe just reclaiming the other 16777087 would have been > more efficient. > > But I'm pretty sure it's too late anyway, just like it's too late to > make 240/4 usable. > 14/8 is useable - even with an extremely small number of legacy allocations, the address block is useable. There is no OS stack that says "bad address" for 14/8, which is the essential difference between 14/8 and 240/4. Geoff From david.conrad at icann.org Wed Oct 31 02:08:37 2007 From: david.conrad at icann.org (David Conrad) Date: Tue, 30 Oct 2007 18:08:37 -0700 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <56E83263-ABCA-4532-A761-BCE3C57F7886@muada.com> Message-ID: Iljitsch, On 10/29/07 2:15 PM, "Iljitsch van Beijnum" wrote: >>> About half the ~ 40 legacy /8 assignments don't show up in the >>> routing table. >> Which, of course, means precisely nothing. > The value of an IP address is the ability to receive packets from > elsewhere addressed to it. Without a presence in a routing table > someplace, that doesn't happen so the IP address is of no value. The fact that _you_ can't see a routing announcement for a particular prefix does NOT mean the prefix isn't announced somewhere. There are these things called "private networks" and they do interconnect outside of the context of the "public" Internet. >>> Trading something that's in demand but has no supply >>> will lead to hoarding, reducing availability or at the very least >>> making it unpredictable. > >> The address space in question is already allocated, hence unavailable. The >> question is how to incent folks to put their "allocated but unused" address >> space back into play. > > Your assumption is that the value of having more addresses > automatically outweighs any negative consequences from having a > market. Well, no. I'm not actually making that assumption. I make the assumption that markets are going to exist regardless of whether folks stamp their feet and pout about their existence. The fact that long prefixes will undoubtedly be made available could have potential negative implications, no question. However, it would seem best to try to address (pun intended) that issue directly instead of pointlessly trying to address it indirectly by commanding the tide to not come in. > It requires herculian effort to keep the up-and-coming > economies happy with the way the internet is currently "run" (if there > is such a thing). Actually, it doesn't. Your view is somewhat condescending. Folks in developing countries are as involved in the way the Internet is currently "run" (in terms of setting address policy) and are as aware of the issues as are folks in developed countries. > What is the developing world going to say when they > have to pay rich American companies for address space--address space > that those companies got for free? They will be unhappy. Perhaps a bit less unhappy than being told "it is impossible to obtain any additional address space, period", but perhaps not. The reality is that the IPv4 address space is running out and as long as there is continued demand for IPv4 address space, there are going to be people who are able to obtain address space and some who will not, regardless of the mechanisms of redistribution. > What if a slow trickle of expensive IPv4 addresses is just enough to > keep people from moving to IPv6, but at the same time stiffling the > industry both technically by deeper and deeper layers of NAT and > economically because it takes longer and longer and costs more and > more to get new IP addresses for new businesses? I would imagine the increased cost of IPv4 would likely be a major driver towards IPv6 -- it actually gives people a reason to migrate to IPv6 (as opposed to the current situation). > There are STILL people that refuse to bother implementing IPv6 in > their products, And WHY are they not implementing IPv6? Because there is no customer demand. Why is there no customer demand? Because IPv6 provides no technical incentive over IPv4. Since there are no technical incentives, it would seem the next best option is financial incentives. What is your alternative? > making it that much harder for their customers to > adopt IPv6 in the next three years that we can reasonably sure about > having current levels of IPv4 availability. Anything that these people > can use as an excuse to wait even longer is extremely harmful. The cost of obtaining IPv4 will go up, regardless of the mechanism used to obtain address space. The cost of obtaining IPv6 will remain low. This will naturally encourage folks to investigate whether IPv6 can meet their connectivity needs. Regards, -drc From david at sargasso.net Wed Oct 31 02:28:37 2007 From: david at sargasso.net (David Croft) Date: Wed, 31 Oct 2007 02:28:37 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: <56E83263-ABCA-4532-A761-BCE3C57F7886@muada.com> Message-ID: On 31/10/2007, David Conrad wrote: > The fact that _you_ can't see a routing announcement for a particular prefix > does NOT mean the prefix isn't announced somewhere. There are these things > called "private networks" and they do interconnect outside of the context of > the "public" Internet. I'm sorry, I might be missing some enormous point here, but since when were these companies sold IP addresses or given indefinite title to them? If they received them legitimately and they are in active use then they have a responsiblity to keep the contact information up to date, as per their original agreement (presumably... barring some huge historical cock-up). I say, for every prefix not in the routing table, that is not registered under a paid-up LIR or equivalent, send them repeated automated communications and if they fail to respond, *they* have neglected *their* responsibilities and have lost their right to a loan of a finite pubic resource. If they do not keep up with their responsibilities to keep their records up to date, then why should they be treated any different from the gazillion former class Bs that no longer exist? And why should we be concerned about keeping their networks running when they have no concern about the operation of our internet? If we can't distinguish betwen the legitimate class B holders and the Erie Forge and Steels, then why should it be our burden to do so? Why must we pander to the 5% of those guys who even still exist when they refuse to cooperate? David From jeroen at unfix.org Wed Oct 31 02:45:32 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 31 Oct 2007 01:45:32 +0000 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: References: <56E83263-ABCA-4532-A761-BCE3C57F7886@muada.com> Message-ID: <4727DE3C.7090408@spaghetti.zurich.ibm.com> David Croft wrote: > On 31/10/2007, David Conrad wrote: >> The fact that _you_ can't see a routing announcement for a particular prefix >> does NOT mean the prefix isn't announced somewhere. There are these things >> called "private networks" and they do interconnect outside of the context of >> the "public" Internet. > > I'm sorry, I might be missing some enormous point here, but since when > were these companies sold IP addresses or given indefinite title to > them? IP addresses can't be sold (at least under the RIR system), that doesn't mean it doesn't happen. Legacy addresses though where simply 'allocated'. Nothing else. > If they received them legitimately and they are in active use > then they have a responsiblity to keep the contact information up to > date, as per their original agreement (presumably... barring some huge > historical cock-up). They effectively don't have any agreement, they just got them. > I say, for every prefix not in the routing table, that is not > registered under a paid-up LIR or equivalent, send them repeated > automated communications and if they fail to respond, *they* have > neglected *their* responsibilities and have lost their right to a loan > of a finite pubic resource. There is no concept of LIR for those assignments. RIRs and thus also LIRs didn't even exist at that time. Remember that RIPE NCC was the first RIR founded around 1991. Most legacy blocks far predate that. See the following URL and you will easy see that predate it: http://www.iana.org/assignments/ipv4-address-space > If they do not keep up with their responsibilities to keep their > records up to date, then why should they be treated any different from > the gazillion former class Bs that no longer exist? And why should we > be concerned about keeping their networks running when they have no > concern about the operation of our internet? Because those resources (IP addresses in this case) are not only for "The Internet" but more for "Internet Protocol using Networks". > If we can't distinguish betwen the legitimate class B holders and the > Erie Forge and Steels, then why should it be our burden to do so? Why > must we pander to the 5% of those guys who even still exist when they > refuse to cooperate? Do any of those networks really refuse to cooperate? I am fairly sure that during the ERX work most of them got contacted and also correctly responded to inquiries. If they didn't, let the people who did them please speak up in public for which /8's etc nobody responded and then see if those contacts can be found to figure out what/if they are being used or not. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From heldal at eml.cc Wed Oct 31 10:14:31 2007 From: heldal at eml.cc (Per Heldal) Date: Wed, 31 Oct 2007 10:14:31 +0100 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <4727DE3C.7090408@spaghetti.zurich.ibm.com> References: <56E83263-ABCA-4532-A761-BCE3C57F7886@muada.com> <4727DE3C.7090408@spaghetti.zurich.ibm.com> Message-ID: <1193822071.14039.17.camel@obelix.sandbu> On Wed, 2007-10-31 at 01:45 +0000, Jeroen Massar wrote: > David Croft wrote: > Legacy addresses though where simply 'allocated'. Nothing else. > > > If they received them legitimately and they are in active use > > then they have a responsiblity to keep the contact information up to > > date, as per their original agreement (presumably... barring some huge > > historical cock-up). > > They effectively don't have any agreement, they just got them. > > > I say, for every prefix not in the routing table, that is not > > registered under a paid-up LIR or equivalent, send them repeated > > automated communications and if they fail to respond, *they* have > > neglected *their* responsibilities and have lost their right to a loan > > of a finite pubic resource. > > There is no concept of LIR for those assignments. RIRs and thus also > LIRs didn't even exist at that time. Some consider the internet a "virtual society". From that angle it can also be considered fair that the society's laws and regulations to evolve over time. From this perspective legacy-holders have had the opportunity to take part in the process and shouldn't be allowed to ignore it with no consequences. Today it seems much like everyone makes their own rules, or that there are no rules. Either way that is anarchy. What we really need to ask ourselves in the long term is if that is really what we want (considering the perpetual exceptions for legacy-holders that have been suggested in v6 space). //per From jeroen at unfix.org Wed Oct 31 10:28:44 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 31 Oct 2007 09:28:44 +0000 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <1193822071.14039.17.camel@obelix.sandbu> References: <56E83263-ABCA-4532-A761-BCE3C57F7886@muada.com> <4727DE3C.7090408@spaghetti.zurich.ibm.com> <1193822071.14039.17.camel@obelix.sandbu> Message-ID: <47284ACC.1050202@spaghetti.zurich.ibm.com> Per Heldal wrote: > On Wed, 2007-10-31 at 01:45 +0000, Jeroen Massar wrote: > > Some consider the internet a "virtual society". From that angle it can > also be considered fair that the society's laws and regulations to > evolve over time. From this perspective legacy-holders have had the > opportunity to take part in the process and shouldn't be allowed to > ignore it with no consequences. Today it seems much like everyone makes > their own rules, or that there are no rules. Either way that is anarchy. > What we really need to ask ourselves in the long term is if that is > really what we want (considering the perpetual exceptions for > legacy-holders that have been suggested in v6 space). Those 'perpetual exceptions' should of course never happen. Note that the only people/companies/organizations who where arguing for that where the holders of the so-called class B space who simply don't want to contribute back to the RIR process and indeed don't want to be part of the community, they just want everything for free and they think they are special. Fortunately these where only a few loud voices and the RIR community has decided against them. In the ARIN region one can get /48 PI IPv6 which solves their problem. Looking at the IPv6 allocations list quite a number of the 'legacy space holders' have already gone through the LIR process with the RIR in their area and have received an allocation through that way. As such, I think/hope that the rest of them will nicely follow suit and this will not become an issue. Forcing those existing legacy holders to come into the RIR process though is a definitive no-no IMHO. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From tony at tndh.net Tue Oct 30 20:40:44 2007 From: tony at tndh.net (Tony Hain) Date: Tue, 30 Oct 2007 12:40:44 -0700 Subject: [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool. Message-ID: <0ff601c81b2c$c38e4110$4aaac330$@net> Policy Proposal Name: Cooperative distribution of the end of the IPv4 free pool. Author name: Tony Hain email: alh-ietf at tndh.net telephone: +1-425-468-1061 organization: Cisco Systems Proposal Version: 1.0 Submission Date: Oct-30-2007 Proposal type: new Policy term: permanent Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool. Policy statement: At the point when any given RIR is within 30 days of depleting its remaining IPv4 pool, a survey will be taken of the other 4 to determine the remaining time before each of them exhausts their pool (including both member use and recent redistribution allocations to other RIRs). The one with the longest window before exhausting its pool will be designated as the source RIR. The recipient RIR will follow procedures for an LIR in the source RIR region to request a block that is expected to be sufficient for up to 3 months, but is no larger than 1/8th of the source RIR's remaining pool. At the point where no RIR can supply a block that is less than 1/8th of their remaining pool that will sustain the recipient RIR for 30 days, the recipient RIR will collect its requests each week, and forward those individual requests to the source RIR designated that week. Rationale: This policy will establish a mechanism for the Allocation of IPv4 address blocks between RIR's, but will not go into effect until the IANA pool has been depleted. It is really bizarre to watch the maneuvering as the global RIR community grapples with 'fairness' of distributing the last few IANA Reserve /8 blocks. On one level this just appears to be petty sibling rivalry, as people are bickering over who gets the last cookie and whimpering about 'fairness'. At the same time, each RIR is chartered to look after the interests of its membership so it is to be expected that they will each want to get as much as possible to meet the needs of their respective membership. Existing practice requires RIR's to acquire blocks from IANA, which leads to the current round of nonsense about optimal distribution of the remaining pool based on elaborate mathematical models. This globally submitted policy proposal attempts to resolve the issue by shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. This policy would effectively result in each RIR becoming a virtual LIR member of all of the other RIR's for the sole purpose of managing the tail-end of the IPv4 pool. Timetable for implementation: Before 1/1/2009 From randy at psg.com Wed Oct 31 12:12:55 2007 From: randy at psg.com (Randy Bush) Date: Wed, 31 Oct 2007 20:12:55 +0900 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) In-Reply-To: <47284ACC.1050202@spaghetti.zurich.ibm.com> References: <56E83263-ABCA-4532-A761-BCE3C57F7886@muada.com> <4727DE3C.7090408@spaghetti.zurich.ibm.com> <1193822071.14039.17.camel@obelix.sandbu> <47284ACC.1050202@spaghetti.zurich.ibm.com> Message-ID: <47286337.7090706@psg.com> > Note that the only people/companies/organizations who where arguing for > that where the holders of the so-called class B space who simply don't > want to contribute back to the RIR process and indeed don't want to be > part of the community, they just want everything for free and they think > they are special. thank you for the kind characterization. this is an amazingly constructive contribution. randy From niallm-subs at avernus.net Wed Oct 31 13:35:39 2007 From: niallm-subs at avernus.net (Niall Murphy) Date: Wed, 31 Oct 2007 12:35:39 +0000 Subject: [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources) Message-ID: <59849c580710310535j4265bd6pc066ede1e1dfa779@mail.gmail.com> Michael, all, > > The address space in question is already allocated, hence > > unavailable. The question is how to incent folks to put > > their "allocated but unused" address space back into play. > > Stamping your foot and declaring "markets are bad" > > isn't likely to be too helpful. > And thinking that you can influence address-holders decision making > without pricing an IPv4 at several hundred thousand dollars, is also not > likely to be too helpful. I don't think that anyone knows how the pricing is going to work yet, so I'm going to leave aside discussion of your specific figure. Similarly, "an IPv4" (an IPv4 what?) probably needs clarification, but it's not the substantive issue. Notwithstanding the detail of the numbers, which is obviously a crucial detail, I have to take issue with your assertion is that we cannot influence address-holder decision making without setting a price, and setting it high. The fact is, after IPv4 exhaustion we will still need IPv4 addresses. Address holders who have more IPv4 addresses than they will ever use will have a strong incentive to exchange those addresses for money, and IPv4-dependent organisations will have a strong incentive to purchase them. That's going to happen, make no mistake, because as an industry, we are *nowhere near* where we need to be in order to have an IPv6 world by 2010. So, there's already no question of address holders being uninfluenced. They certainly will be by 2010, if they're not already, and such pricing as emerges in a back-door market does not have to be high in order to provoke the release of addresses in an ad-hoc fashion. It's entirely plausible that a steady drip-feed of low-priced prefixes would suit many organisations better than holding on for higher prices (think cashflow, for example). For these and other reasons, there'll be no question of, for example, the RIR system being frustrated in its attempt to influence address-holders because of too low a price. The danger is not the RIR system and is not the market; the danger is the unregulated market, and the chaos of the current post-exhaustion scenario. > Any organization who contemplates selling a block of IPv4 addresses has > to conside the reality that it would be an extremely constrained market > where the supply is going down and they are not making any new IPv4 > addresses. Indeed - that's exactly right, and that's one of the reasons why it's such a powerful incentive to move to IPv6, which is, IIUYC, where we both want to be. But you must also consider that such a market as we proposed is not intended to be *the* solution: it is explicitly not for continually recycling existing prefixes. It is to provide liquidity to the participants for an undefined period until IPv6 is a workable day-to-day alternative to IPv4. So the fact that the market is constrained *doesn't matter* in the long term - we're inventing our way out of scarcity elsewhere. > This means that if you do sell, and then discover that you > needed those addresses after all, the price to buy them back could be > substantially higher than your sale price. In the face of continually > rising prices, it is risky to sell any addresses at all, unless you are > absolutely certain, at the CEO/board level, that the addresses are not > needed, or if the price that you would receive is at least several > hundred thousand dollars. (Again, I'm not going to talk about the figures here, but that's not a central point in your argument.) If I parse what you're saying correctly, you posit that the danger of accidentally selling addresses that it turns out that you'll need will motivate people to stay away from the market, and therefore cause rising prices and liquidity problems. Well, my argument would be that from an economic point of view, organisations are incentivized to only sell what they explicitly don't need. We all know of organisations that have much more spare than they could possibly use, so it's unclear where the original 'dump everything' motivation could come from. Furthermore, the meta-assertion that "a market might have problems" reinforces the fact that the community *must keep transfers where it can see them*. If they are happening out of sight, we have no direction observation or control of the same set of problems. > This is a recipe for a gold-rush style market followed by liquidity > collapse which will have additional knock-on effects in the real > markets, i.e. share prices. If you watch our talk webcast (when RIPE gets around to putting them up) you'll see more details of our argument here, but in brief the dangers of *not* having a realistic plan in place will cause as much damage to stock prices etc as much as leaving things alone will. I'm in sympathy with you on the topic of avoiding gold-rush markets and liquidity collapses, but I think with a bit of careful planning, we'll be able to avoid both. (If only we'd had that careful planning years ago, then we could have saved ourselves a lot of trouble. But now we're in the position of having no wholly good choices, it's only a question of choosing which set of bad effects we want.) Niall From michael.dillon at bt.com Wed Oct 31 16:01:29 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 31 Oct 2007 15:01:29 -0000 Subject: [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool. In-Reply-To: <0ff601c81b2c$c38e4110$4aaac330$@net> References: <0ff601c81b2c$c38e4110$4aaac330$@net> Message-ID: > Policy summary: > This policy will establish a process for RIR-to-RIR > redistribution of the tail-end of the IPv4 pool, taking > effect after the IANA Reserve is exhausted. Each > redistribution Allocation will be triggered by the recipient > RIR depleting its reserve to a 30 day supply, and will result > in up to a 3 month supply being transferred from the RIR with > the longest remaining time before it exhausts its own pool. Finally some sensible discussion about the end-game that does not cause us to reach a crisis sooner, and may extend the overall life of IPv4 by a small amount. It also removes the incentives for companies to create shell companies in other regions to lock up a supply of IPv4 addresses. We should discard all the other silly end-game proposals and do some serious work on making a workable variation of this one. --Michael Dillon From michael.dillon at bt.com Wed Oct 31 17:20:09 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 31 Oct 2007 16:20:09 -0000 Subject: [ppml] [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool. In-Reply-To: <4728A145.90302@ca.afilias.info> References: <0ff601c81b2c$c38e4110$4aaac330$@net> <4728A145.90302@ca.afilias.info> Message-ID: > > We should discard all the other silly end-game proposals > and do some > > serious work on making a workable variation of this one. > > > I would point out that this policy applies *after* the IANA > reserve has been allocated. > > The other policies under discussion apply *before* the > reserve has run out, and concern when and how the final IANA > blocks are allocated to RIRs. > > As such, the two kinds of proposals are orthogonal. Exactly! The policies that apply before the IANA reserve has run out, are silly. This policy, which applies after the IANA reserve has run out, makes some sense and does result in a soft landing. > And, in fact, if both kinds are implemented, the benefit is > greater than if only one or the other were implemented. I disagree. And if Tony Hain's policy were to be implemented, then everything before that is basically meaningless. --Michael Dillon From briand at ca.afilias.info Wed Oct 31 16:37:41 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Wed, 31 Oct 2007 11:37:41 -0400 Subject: [ppml] [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool. In-Reply-To: References: <0ff601c81b2c$c38e4110$4aaac330$@net> Message-ID: <4728A145.90302@ca.afilias.info> michael.dillon at bt.com wrote: >> Policy summary: >> This policy will establish a process for RIR-to-RIR >> redistribution of the tail-end of the IPv4 pool, taking >> effect after the IANA Reserve is exhausted. Each >> redistribution Allocation will be triggered by the recipient >> RIR depleting its reserve to a 30 day supply, and will result >> in up to a 3 month supply being transferred from the RIR with >> the longest remaining time before it exhausts its own pool. >> This does sound interesting, and further helps fine-tune any tail-end disparity that exists following the final IANA allocations. However, I believe the value of this would be weakened by having this policy implemented too frequently, e.g. if the fastest-allocating RIRs need to do this more than once, or if a slow-allocating RIR is "hit" more than once. > Finally some sensible discussion about the end-game that does > not cause us to reach a crisis sooner, and may extend the overall > life of IPv4 by a small amount. It also removes the incentives > for companies to create shell companies in other regions to lock > up a supply of IPv4 addresses. > > We should discard all the other silly end-game proposals and do > some serious work on making a workable variation of this one. > I would point out that this policy applies *after* the IANA reserve has been allocated. The other policies under discussion apply *before* the reserve has run out, and concern when and how the final IANA blocks are allocated to RIRs. As such, the two kinds of proposals are orthogonal. And, in fact, if both kinds are implemented, the benefit is greater than if only one or the other were implemented. As such, I would have to encourage support for both the "pie" proposal, *and* this "cooperative" proposal. Brian From leo.vegoda at icann.org Wed Oct 31 18:06:52 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 31 Oct 2007 18:06:52 +0100 Subject: [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool. In-Reply-To: References: <0ff601c81b2c$c38e4110$4aaac330$@net> Message-ID: <31339337-6D56-4C48-9BAA-2D74BD6D13AA@icann.org> Hi, We'd be grateful if people could stop cc'ing iana at iana.org when posting messages to this discussion as it generates unnecessary tickets in our ticketing system. Many thanks, Leo Vegoda From vincent at kenic.or.ke Wed Oct 31 22:13:38 2007 From: vincent at kenic.or.ke (Vincent Ngundi) Date: Thu, 1 Nov 2007 00:13:38 +0300 Subject: [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool. In-Reply-To: <0ff601c81b2c$c38e4110$4aaac330$@net> References: <0ff601c81b2c$c38e4110$4aaac330$@net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Remarkable foresight! If I read the policy right, do you suggest that we retain the current IANA allocation policy and instead concentrate on life after the depletion of IPv4 in the IANA pool? Regards, - -Vincent On Oct 30, 2007, at 10:40 PM, Tony Hain wrote: > Policy Proposal Name: Cooperative distribution of the end of the > IPv4 > free pool. > > Author name: Tony Hain > email: alh-ietf at tndh.net > telephone: +1-425-468-1061 > organization: Cisco Systems > Proposal Version: 1.0 > Submission Date: Oct-30-2007 > Proposal type: new > Policy term: permanent > > Policy summary: > This policy will establish a process for RIR-to-RIR redistribution > of the > tail-end of the IPv4 pool, taking effect after the IANA Reserve is > exhausted. Each redistribution Allocation will be triggered by the > recipient > RIR depleting its reserve to a 30 day supply, and will result in up > to a 3 > month supply being transferred from the RIR with the longest > remaining time > before it exhausts its own pool. > > Policy statement: > At the point when any given RIR is within 30 days of depleting its > remaining > IPv4 pool, a survey will be taken of the other 4 to determine the > remaining > time before each of them exhausts their pool (including both member > use and > recent redistribution allocations to other RIRs). The one with the > longest > window before exhausting its pool will be designated as the source > RIR. The > recipient RIR will follow procedures for an LIR in the source RIR > region to > request a block that is expected to be sufficient for up to 3 > months, but is > no larger than 1/8th of the source RIR's remaining pool. At the > point where > no RIR can supply a block that is less than 1/8th of their > remaining pool > that will sustain the recipient RIR for 30 days, the recipient RIR > will > collect its requests each week, and forward those individual > requests to the > source RIR designated that week. > > Rationale: > This policy will establish a mechanism for the Allocation of IPv4 > address > blocks between RIR's, but will not go into effect until the IANA > pool has > been depleted. > > It is really bizarre to watch the maneuvering as the global RIR > community > grapples with 'fairness' of distributing the last few IANA Reserve /8 > blocks. On one level this just appears to be petty sibling rivalry, as > people are bickering over who gets the last cookie and whimpering > about > 'fairness'. At the same time, each RIR is chartered to look after the > interests of its membership so it is to be expected that they will > each want > to get as much as possible to meet the needs of their respective > membership. > Existing practice requires RIR's to acquire blocks from IANA, which > leads to > the current round of nonsense about optimal distribution of the > remaining > pool based on elaborate mathematical models. > > This globally submitted policy proposal attempts to resolve the > issue by > shifting to an RIR-to-RIR Allocation model after the IANA pool is > depleted. > This policy would effectively result in each RIR becoming a virtual > LIR > member of all of the other RIR's for the sole purpose of managing the > tail-end of the IPv4 pool. > > Timetable for implementation: Before 1/1/2009 > > > - -- KeNIC - The Kenya Network Information Center http://www.kenic.or.ke -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHKPAChPC3Z8cZxdsRAsbpAJ9QCtMgO6fbPhg5pHtjJzWVt8kf+QCgqu70 77KKjoP4KqBpGKQ59JE0NV8= =k/EN -----END PGP SIGNATURE-----