From sander at steffann.nl Sun Jul 5 11:12:51 2009 From: sander at steffann.nl (Sander Steffann) Date: Sun, 5 Jul 2009 11:12:51 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 Message-ID: Hello WG, I want to continue the discussion about the Final /8 proposals (2008-06 and 2009-04). The responses to my last question ("Do we (this working group) want to put IPv6 related requirements in the policy?") were 100% negative: We don't want IPv6 related requirements in the Final /8 policy. The next question is about the amount of addresses someone can get from the Final /8. I think we have a number of options here: a) Everyone gets one (and only one) fixed size block, as described in 2008-06 b) All requests are downscaled by a certain factor, as described in 2009-04 c) We place a limit on the amount of addresses that can be requested per time slot (year?) I think it is important to think about new companies. They will very probably require some IPv4 address space during the transition from IPv4 to IPv6. I think the whole community will be in a lot of trouble if we make a policy that makes it impossible for new entrants to participate in a dual-stack world. Once we have discussed this basic issue I'll steer the discussion back to the other differences between the proposals. Please keep the discussion on this topic for now. Thank you, Sander Steffann APWG co-chair From Andreas at Schachtner.eu Sun Jul 5 12:19:48 2009 From: Andreas at Schachtner.eu (Andreas Schachtner) Date: Sun, 05 Jul 2009 12:19:48 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: Message-ID: <20090705101948.CB1175B0D1@linux.local> Hello, > The next question is about the amount of addresses someone can get > from the Final /8. I think we have a number of options here: > a) Everyone gets one (and only one) fixed size block, as described in > 2008-06 IMHO, the "one size fits all" approach doesn't seem the right way to go. The rationale in the original proposal was clearly directed towards IPv6 deployment and maintaining interconnection to the IPv4 world in this szenario. Even if I think, this is a sensible approach, we agreed 100%, that we don't want IPv6 related requirements in this proposal (and let me add, neither explicit nor implicit). > b) All requests are downscaled by a certain factor, as described in > 2009-04 This sounds sensible to me. A downsscaling factor of 64 will give enough address space to stay in the allocation business for some (small "some) years. Newcomers are not discriminated, as it seems easier to me for a newcomer to deploy multiplexing techniques than for an established operator with a large legacy network. So the goal to keep newcomers in the game is achieved as well (and reinforced by the proposed argument (d) below). > c) We place a limit on the amount of addresses that can be requested > per time slot (year?) and/or (d) upon further allocation requests, the LIR has to demonstrate IP use under the downscaling paradigm (e.g., some kind of multiplexing technology is deployed for the last allocation). Regards, Andreas -- -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From info at streamservice.nl Sun Jul 5 12:52:52 2009 From: info at streamservice.nl (Stream Service) Date: Sun, 5 Jul 2009 12:52:52 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: Message-ID: <001101c9fd5e$bf0ec860$3d2c5920$@nl> Hello, If you ask me; the requests should be processed like now, with 3 differences: - IF someone/a company has IPv4 address space already they need to prove that they use it in the right way (1 IP/VPS or 2 IP/server or 1 IP/NIC or 1 IP/SSL certificate for example sounds reasonable for me). If this is not the case (they use more IPv4 addresses for this) the new allocation will be refused. - Someone/a company without IPv4 address space already should get only a /24 or a /23, after they have proven to use this correctly (see above) they could request another range. - The biggest range someone can get with any new request should be limited to a /22. Requests should be processed at a first-come-first-serve base (where possible) if you ask me. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Sander Steffann Sent: zondag 5 juli 2009 11:13 To: Address Policy Working Group Subject: [address-policy-wg] The final /8 policy proposals, part 2 Hello WG, I want to continue the discussion about the Final /8 proposals (2008-06 and 2009-04). The responses to my last question ("Do we (this working group) want to put IPv6 related requirements in the policy?") were 100% negative: We don't want IPv6 related requirements in the Final /8 policy. The next question is about the amount of addresses someone can get from the Final /8. I think we have a number of options here: a) Everyone gets one (and only one) fixed size block, as described in 2008-06 b) All requests are downscaled by a certain factor, as described in 2009-04 c) We place a limit on the amount of addresses that can be requested per time slot (year?) I think it is important to think about new companies. They will very probably require some IPv4 address space during the transition from IPv4 to IPv6. I think the whole community will be in a lot of trouble if we make a policy that makes it impossible for new entrants to participate in a dual-stack world. Once we have discussed this basic issue I'll steer the discussion back to the other differences between the proposals. Please keep the discussion on this topic for now. Thank you, Sander Steffann APWG co-chair From david.freedman at uk.clara.net Sun Jul 5 13:42:45 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Sun, 5 Jul 2009 12:42:45 +0100 Subject: [address-policy-wg] The final /8 policy proposals, part 2 References: <001101c9fd5e$bf0ec860$3d2c5920$@nl> Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B0D7D47@EXVS01.claranet.local> Am quite up for capping the request size, if a newcomer comes along and wants a big bunch of v4 addresses then they are obviously not transitioning and not the sort of people that we want to be wasting the remaining v4 address space on. The only edge case I can think of here is when $company has address space from $provider and $provider tells them to get lost and they find they have to fend for themselves. Do people think that this will become a problem? people ditching v4 only customers in order to get address space back (i.e making them IPv4 homeless?)? Dave. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: address-policy-wg-admin at ripe.net on behalf of Stream Service Sent: Sun 7/5/2009 11:52 To: 'Address Policy Working Group' Subject: RE: [address-policy-wg] The final /8 policy proposals, part 2 Hello, If you ask me; the requests should be processed like now, with 3 differences: - IF someone/a company has IPv4 address space already they need to prove that they use it in the right way (1 IP/VPS or 2 IP/server or 1 IP/NIC or 1 IP/SSL certificate for example sounds reasonable for me). If this is not the case (they use more IPv4 addresses for this) the new allocation will be refused. - Someone/a company without IPv4 address space already should get only a /24 or a /23, after they have proven to use this correctly (see above) they could request another range. - The biggest range someone can get with any new request should be limited to a /22. Requests should be processed at a first-come-first-serve base (where possible) if you ask me. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Sander Steffann Sent: zondag 5 juli 2009 11:13 To: Address Policy Working Group Subject: [address-policy-wg] The final /8 policy proposals, part 2 Hello WG, I want to continue the discussion about the Final /8 proposals (2008-06 and 2009-04). The responses to my last question ("Do we (this working group) want to put IPv6 related requirements in the policy?") were 100% negative: We don't want IPv6 related requirements in the Final /8 policy. The next question is about the amount of addresses someone can get from the Final /8. I think we have a number of options here: a) Everyone gets one (and only one) fixed size block, as described in 2008-06 b) All requests are downscaled by a certain factor, as described in 2009-04 c) We place a limit on the amount of addresses that can be requested per time slot (year?) I think it is important to think about new companies. They will very probably require some IPv4 address space during the transition from IPv4 to IPv6. I think the whole community will be in a lot of trouble if we make a policy that makes it impossible for new entrants to participate in a dual-stack world. Once we have discussed this basic issue I'll steer the discussion back to the other differences between the proposals. Please keep the discussion on this topic for now. Thank you, Sander Steffann APWG co-chair -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at streamservice.nl Sun Jul 5 13:48:29 2009 From: info at streamservice.nl (Stream Service) Date: Sun, 05 Jul 2009 13:48:29 +0200 Subject: [#MLT-583232]: RE: [address-policy-wg] The final /8 policy proposals, part 2 Message-ID: David Freedman, Uw ticket is ontvangen en een medewerker zal het ticket bekijken en beantwoorden. Hieronder staan de details van dit ticket. Zorg er a.u.b. voor dat het Ticket ID altijd in het onderwerp van deze email blijft staan. Ticket ID: MLT-583232 Onderwerp:RE: [address-policy-wg] The final /8 policy proposals, part 2 Department: Stream Service (Algemeen) Priority: Low Status: Open U kunt hier klikken om de status van ons antwoord op het Ticket online te bekijken.http://support.streamservice.nl/index.php?_m=tickets&_a=viewticket&ticketid=17027 Wij horen het graag als we u nog ergens anders mee van dienst kunnen zijn, Stream Service (Algemeen) info at streamservice.nl Tel : +31 (0)53-7112711 Fax : +31 (0)53-7112716 Stream Service is een handelsnaam van SinnerG BV From gert at space.net Sun Jul 5 18:41:17 2009 From: gert at space.net (Gert Doering) Date: Sun, 5 Jul 2009 18:41:17 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <20090705101948.CB1175B0D1@linux.local> References: <20090705101948.CB1175B0D1@linux.local> Message-ID: <20090705164117.GB26102@Space.Net> Hi, On Sun, Jul 05, 2009 at 12:19:48PM +0200, Andreas Schachtner wrote: > > b) All requests are downscaled by a certain factor, as described in > > 2009-04 > > This sounds sensible to me. A downsscaling factor of 64 will give enough > address space to stay in the allocation business for some (small "some) years. How exactly would "downscaling" work? A company demonstrates need for (say) a /19, and they get 8192/64 = a /25 - while a newcomer demonstrates the need for a /24, and gets a /30... So if we go that way, quite some thought needs to go into implementation details. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From pk at DENIC.DE Sun Jul 5 18:56:29 2009 From: pk at DENIC.DE (Peter Koch) Date: Sun, 5 Jul 2009 18:56:29 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <20090705164117.GB26102@Space.Net> References: <20090705101948.CB1175B0D1@linux.local> <20090705164117.GB26102@Space.Net> Message-ID: <20090705165629.GB23558@x27.adm.denic.de> On Sun, Jul 05, 2009 at 06:41:17PM +0200, Gert Doering wrote: > So if we go that way, quite some thought needs to go into implementation > details. before diving into these or before selecting different options, shouldn't the overall goals of, say, "fairness" and "sustainability" be broken down into a tangible set of criteria against which the solutions could be evaluated? This would also ease the assessment of potential subversion tactics. -Peter From randy at psg.com Mon Jul 6 00:16:43 2009 From: randy at psg.com (Randy Bush) Date: Mon, 06 Jul 2009 07:16:43 +0900 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: Message-ID: Sander Steffann > a) Everyone gets one (and only one) fixed size block, as described in > 2008-06 apnic chose this path, i believe for the following reason you state: > I think it is important to think about new companies. They will very > probably require some IPv4 address space during the transition from > IPv4 to IPv6. I think the whole community will be in a lot of trouble > if we make a policy that makes it impossible for new entrants to > participate in a dual-stack world. Andreas Schachtner wrote: > IMHO, the "one size fits all" approach doesn't seem the right way to > go. you're right, of course. but the problem is, nothing will fit all. we are out of ipv4 space. concepts such as meeting needs of existing players are now pretty much irrelevant. randy From jwkckid1 at ix.netcom.com Mon Jul 6 00:22:36 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Sun, 05 Jul 2009 15:22:36 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 References: <20090705101948.CB1175B0D1@linux.local> Message-ID: <4A5127A9.10578C74@ix.netcom.com> Andreas and all, I agree, the one-size-fits-all approach is a fools errand. Andreas Schachtner wrote: > Hello, > > > The next question is about the amount of addresses someone can get > > from the Final /8. I think we have a number of options here: > > a) Everyone gets one (and only one) fixed size block, as described in > > 2008-06 > > IMHO, the "one size fits all" approach doesn't seem the right way to go. The > rationale in the original proposal was clearly directed towards IPv6 > deployment and maintaining interconnection to the IPv4 world in this szenario. > Even if I think, this is a sensible approach, we agreed 100%, that we don't > want IPv6 related requirements in this proposal (and let me add, neither > explicit nor implicit). > > > b) All requests are downscaled by a certain factor, as described in > > 2009-04 > > This sounds sensible to me. A downsscaling factor of 64 will give enough > address space to stay in the allocation business for some (small "some) years. > > Newcomers are not discriminated, as it seems easier to me for a newcomer to > deploy multiplexing techniques than for an established operator with a large > legacy network. So the goal to keep newcomers in the game is achieved as well > (and reinforced by the proposed argument (d) below). > > > c) We place a limit on the amount of addresses that can be requested > > per time slot (year?) > > and/or > > (d) upon further allocation requests, the LIR has to demonstrate IP use under > the downscaling paradigm (e.g., some kind of multiplexing technology is > deployed for the last allocation). > > Regards, > Andreas > -- > > -- > Andreas Schachtner > > afs Holding GmbH > communication technologies & solutions > http://afs-com.de/ > > Geschaeftsfuehrer Andreas Schachtner > HRB 15448, Amtsgericht Dortmund > > ------------------------------------------------------------------------ > Part 1.2Type: application/pgp-signature Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From jwkckid1 at ix.netcom.com Mon Jul 6 00:37:49 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Sun, 05 Jul 2009 15:37:49 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 References: Message-ID: <4A512B3D.8B9E2589@ix.netcom.com> Randy and all, How far and how much effort has been exercised by the RIR's in reclaiming unused IPv4 addresses so far? I haven't seen much activity in this area of late, and in fact no activity/effort in this area. Seems to me that there is an awful lot of assinged but unused IPv4 address space that could/should be reclaimed for re-allocation to more needy or yet to be known entities. Randy Bush wrote: > Sander Steffann > > a) Everyone gets one (and only one) fixed size block, as described in > > 2008-06 > > apnic chose this path, i believe for the following reason you state: > > > I think it is important to think about new companies. They will very > > probably require some IPv4 address space during the transition from > > IPv4 to IPv6. I think the whole community will be in a lot of trouble > > if we make a policy that makes it impossible for new entrants to > > participate in a dual-stack world. > > Andreas Schachtner wrote: > > IMHO, the "one size fits all" approach doesn't seem the right way to > > go. > > you're right, of course. but the problem is, nothing will fit all. we > are out of ipv4 space. concepts such as meeting needs of existing > players are now pretty much irrelevant. > > randy Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From mueller at syr.edu Sun Jul 5 18:04:21 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 5 Jul 2009 12:04:21 -0400 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <20090705100003.22200.63618.Mailman@postboy.ripe.net> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > > I think it is important to think about new companies. They will very > probably require some IPv4 address space during the transition from > IPv4 to IPv6. I think the whole community will be in a lot of trouble > if we make a policy that makes it impossible for new entrants to > participate in a dual-stack world. > A legitimate concern. But: 1. address transfers might make it possible for them to acquire v4 addresses 2. by "new companies" do you mean "companies with no prior allocations" or literally just "new companies." The two categories overlap but are not the same. If you create a category of [new/no prior assignments] companies and the address shortage becomes severe, can you foresee ways of gaming that definition to acquire privileged access to addresses? e.g., can an incumbent ISP create a wholly-owned subsidiary (which might in fact be a legitimate "new entrant" into a market by some economically-relevant definitions) and qualify as a "new company"? From heldal at eml.cc Mon Jul 6 10:07:33 2009 From: heldal at eml.cc (Per Heldal) Date: Mon, 06 Jul 2009 10:07:33 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: Message-ID: <1246867653.10778.46.camel@obelix> On Sun, 2009-07-05 at 11:12 +0200, Sander Steffann wrote: > Hello WG, > > I want to continue the discussion about the Final /8 proposals > (2008-06 and 2009-04). The responses to my last question ("Do we (this > working group) want to put IPv6 related requirements in the policy?") > were 100% negative: We don't want IPv6 related requirements in the > Final /8 policy. I think APNIC has got it mostly right. To reserve some space for transition-services is the only suggestion I've seen that can have a lasting effect throughout the transition period. Everything else has been/is about skewing the balance to change who gets most out of the remaining chunks. Keep it simple. One single fixed-size block for each new registrant that qualify for or already has a v6 block, and no prior v4 allocation. A whole /8 for might be more than necessary for this though. How many /20 - /22 -size allocations does RIPE-NCC make each year where the registrant has no prior allocation? The intention of such a policy is IMHO primarily to protect new innovative players from abuse (extortion) by the V4 powerhouses. Once established they should seek expansion elsewhere (v6) or compete for the same resources as everyone else. One-size-fits all is therefore appropriate, as it would be near impossible for the NCC to differentiate. //per From fweimer at bfk.de Mon Jul 6 10:36:05 2009 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 06 Jul 2009 08:36:05 +0000 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <001101c9fd5e$bf0ec860$3d2c5920$@nl> (Stream Service's message of "Sun\, 5 Jul 2009 12\:52\:52 +0200") References: <001101c9fd5e$bf0ec860$3d2c5920$@nl> Message-ID: <82skhai4y2.fsf@mid.bfk.de> * Stream Service: > - IF someone/a company has IPv4 address space already they need to prove > that they use it in the right way (1 IP/VPS or 2 IP/server or 1 IP/NIC or 1 > IP/SSL certificate for example sounds reasonable for me). With current Internet standards, you need at least 4 IPv4 addresses per host if you want to implement full IP layer separation. Proprietary solutions can reduce that to 1 IPv4 address per host, but there's no IETF or IEEE standard for it, and the technology is not universally available. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From info at streamservice.nl Mon Jul 6 10:41:51 2009 From: info at streamservice.nl (Stream Service) Date: Mon, 06 Jul 2009 10:41:51 +0200 Subject: [#KKA-100534]: Re: [address-policy-wg] The final /8 policy proposals, part 2 Message-ID: Florian Weimer, Uw ticket is ontvangen en een medewerker zal het ticket bekijken en beantwoorden. Hieronder staan de details van dit ticket. Zorg er a.u.b. voor dat het Ticket ID altijd in het onderwerp van deze email blijft staan. Ticket ID: KKA-100534 Onderwerp:Re: [address-policy-wg] The final /8 policy proposals, part 2 Department: Stream Service (Algemeen) Priority: Low Status: Open U kunt hier klikken om de status van ons antwoord op het Ticket online te bekijken.http://support.streamservice.nl/index.php?_m=tickets&_a=viewticket&ticketid=17057 Wij horen het graag als we u nog ergens anders mee van dienst kunnen zijn, Stream Service (Algemeen) info at streamservice.nl Tel : +31 (0)53-7112711 Fax : +31 (0)53-7112716 Stream Service is een handelsnaam van SinnerG BV From sander at steffann.nl Mon Jul 6 11:45:59 2009 From: sander at steffann.nl (Sander Steffann) Date: Mon, 6 Jul 2009 11:45:59 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <1246867653.10778.46.camel@obelix> References: <1246867653.10778.46.camel@obelix> Message-ID: Hello, > Keep it simple. One single fixed-size block for each new registrant > that > qualify for or already has a v6 block, and no prior v4 allocation. > > A whole /8 for might be more than necessary for this though. Maybe we can reserve a certain amount of address space for this. A whole /8 might indeed be too much. The RIPE NCC seems to grow with about 700 new LIRs each year. If we want to have at least enough for the first 5 years we need 3500 blocks of address space. Let's round that up to 4096. If we use a fixed allocation size of /22 we will need to reserve a /10. That leaves 3/4 of the final /8 for the existing LIRs. The numbers are a bit arbitrary, but it sounds reasonable to me... Sander PS: not speaking as a working group chair From noreply at ripe.net Mon Jul 6 12:58:34 2009 From: noreply at ripe.net (Paul Rendek) Date: Mon, 06 Jul 2009 12:58:34 +0200 Subject: [address-policy-wg] IPv6 Deployment Monitoring Survey: Deadline Extended! Message-ID: <4A51D8DA.5010909@ripe.net> [Apologies for duplicates] Dear Colleagues, The deadline for responding to the IPv6 Deployment Monitoring Survey has been extended to Friday, 10 July 2009. This survey is being conducted by TNO and GNKS Consult, working with the RIPE NCC and sponsored by the European Commission. The aim is to collect data on the current and future use of IPv6 throughout the RIPE NCC service region, and all members of the RIPE community are encouraged to participate. You can access the survey at: http://is-nri.com/take/?i=150597&h=1GwWe3dXXMcPrRrOw5s2yg The survey is composed of 16 questions and can be completed in 10-15 minutes. Results will be presented and discussed at RIPE 59 and published on IPv6 Act Now: http://ipv6actnow.org Please note that all data will be kept confidential at all times, and will only be disclosed on an aggregated level. For more information on the IPv6 Deployment Monitoring Survey, please see: http://www.ripe.net/news/ipv6-deployment-monitoring-survey.html We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to . Regards, Paul Rendek Head of External Relations and Communications RIPE NCC From marcoh at marcoh.net Mon Jul 6 17:46:48 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 6 Jul 2009 17:46:48 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Jul 5, 2009, at 6:04 PM, Milton L Mueller wrote: > > >> -----Original Message----- >> >> I think it is important to think about new companies. They will very >> probably require some IPv4 address space during the transition from >> IPv4 to IPv6. I think the whole community will be in a lot of trouble >> if we make a policy that makes it impossible for new entrants to >> participate in a dual-stack world. >> > > A legitimate concern. But: > > 1. address transfers might make it possible for them to acquire v4 > addresses Transfers from whom ? The /24 they are going to get for 1,000,000,000,000,000 dollar from an "old company" ? MarcoH From marcoh at marcoh.net Mon Jul 6 19:54:18 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 6 Jul 2009 19:54:18 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A96@SUEX07-MBX-04.ad.syr.edu> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D77B220A96@SUEX07-MBX-04.ad.syr.edu> Message-ID: <621AD5EE-36B1-4B05-9EAE-A1A21DCBB7A2@marcoh.net> Hi Milton, Rhetorical question ? Haven't got a clue on what current prises are for /24 on the black market. But we all know that not any amount of money will create more addresses as we currently have, so why not 1,000,000,000,000,000 dollar. Whould Rembrandt have realized "Portrait of a Lady Aged 62" would ever be sold for almost 20 million pounds, when he faced her to make a first draft ? Grtx, Marco On Jul 6, 2009, at 6:26 PM, Milton L Mueller wrote: > Any evidence that v4 addresses in /24 quantity have traded for such > sums? > > Milton Mueller > Professor, Syracuse University School of Information Studies > XS4All Professor, Delft University of Technology > ------------------------------ > Internet Governance Project: > http://internetgovernance.org > > >> -----Original Message----- >> From: Marco Hogewoning [mailto:marcoh at marcoh.net] >> Sent: Monday, July 06, 2009 11:47 AM >> To: Milton L Mueller >> Cc: address-policy-wg at ripe.net >> Subject: Re: [address-policy-wg] The final /8 policy proposals, >> part 2 >> >> >> On Jul 5, 2009, at 6:04 PM, Milton L Mueller wrote: >> >>> >>> >>>> -----Original Message----- >>>> >>>> I think it is important to think about new companies. They >> will very >>>> probably require some IPv4 address space during the transition from >>>> IPv4 to IPv6. I think the whole community will be in a lot >> of trouble >>>> if we make a policy that makes it impossible for new entrants to >>>> participate in a dual-stack world. >>>> >>> >>> A legitimate concern. But: >>> >>> 1. address transfers might make it possible for them to acquire v4 >>> addresses >> >> Transfers from whom ? The /24 they are going to get for >> 1,000,000,000,000,000 dollar from an "old company" ? >> >> MarcoH >> >> MarcoH From drc at virtualized.org Mon Jul 6 20:14:03 2009 From: drc at virtualized.org (David Conrad) Date: Mon, 6 Jul 2009 11:14:03 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <621AD5EE-36B1-4B05-9EAE-A1A21DCBB7A2@marcoh.net> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D77B220A96@SUEX07-MBX-04.ad.syr.edu> <621AD5EE-36B1-4B05-9EAE-A1A21DCBB7A2@marcoh.net> Message-ID: <77AB6C3A-6065-4CDA-9934-3FB0B2ACBAAE@virtualized.org> Marco, On Jul 6, 2009, at 10:54 AM, Marco Hogewoning wrote: > Haven't got a clue on what current prises are for /24 on the black > market. I've seen prices ranging from US $ to US $, but that was some time ago. > But we all know that not any amount of money will create more > addresses as we currently have, so why not 1,000,000,000,000,000 > dollar. It isn't about creating more addresses. It is about using the existing addresses more efficiently. Given the widespread availability of NAT, how many addresses does the average organization actually need? Two (one for their NAT gateway, one for their publicly available services)? Particularly if they have a financial incentive to use address space more efficiently? Regards, -drc From marcoh at marcoh.net Mon Jul 6 20:20:22 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 6 Jul 2009 20:20:22 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <77AB6C3A-6065-4CDA-9934-3FB0B2ACBAAE@virtualized.org> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D77B220A96@SUEX07-MBX-04.ad.syr.edu> <621AD5EE-36B1-4B05-9EAE-A1A21DCBB7A2@marcoh.net> <77AB6C3A-6065-4CDA-9934-3FB0B2ACBAAE@virtualized.org> Message-ID: On Jul 6, 2009, at 8:14 PM, David Conrad wrote: > Marco, > > On Jul 6, 2009, at 10:54 AM, Marco Hogewoning wrote: >> Haven't got a clue on what current prises are for /24 on the black >> market. > > I've seen prices ranging from US $ to US $, > but that was some time ago. > >> But we all know that not any amount of money will create more >> addresses as we currently have, so why not 1,000,000,000,000,000 >> dollar. > > It isn't about creating more addresses. It is about using the > existing addresses more efficiently. Given the widespread > availability of NAT, how many addresses does the average > organization actually need? Two (one for their NAT gateway, one for > their publicly available services)? Particularly if they have a > financial incentive to use address space more efficiently? > Being more efficient is only the start. In the end is 7 billion people vs less then 4 billion addresses. Rhere simply ain't a way around it, face it and deploy IPv6 or somewhere somebody will pay these prices (or more likely start a war). MarcoH From mark at streamservice.nl Mon Jul 6 20:34:05 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Mon, 6 Jul 2009 20:34:05 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D77B220A96@SUEX07-MBX-04.ad.syr.edu> <621AD5EE-36B1-4B05-9EAE-A1A21DCBB7A2@marcoh.net> <77AB6C3A-6065-4CDA-9934-3FB0B2ACBAAE@virtualized.org> Message-ID: <006b01c9fe68$57c741e0$0755c5a0$@nl> Also note that it is very well possible that there will be business takeovers just for the IP addresses in the future. That is not really unlikely with these prices (as soon as it is cheaper to buy a company than to buy their address space someone will buy the company probably). Greets, Mark -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Marco Hogewoning Sent: maandag 6 juli 2009 20:20 To: David Conrad Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] The final /8 policy proposals, part 2 On Jul 6, 2009, at 8:14 PM, David Conrad wrote: > Marco, > > On Jul 6, 2009, at 10:54 AM, Marco Hogewoning wrote: >> Haven't got a clue on what current prises are for /24 on the black >> market. > > I've seen prices ranging from US $ to US $, > but that was some time ago. > >> But we all know that not any amount of money will create more >> addresses as we currently have, so why not 1,000,000,000,000,000 >> dollar. > > It isn't about creating more addresses. It is about using the > existing addresses more efficiently. Given the widespread > availability of NAT, how many addresses does the average > organization actually need? Two (one for their NAT gateway, one for > their publicly available services)? Particularly if they have a > financial incentive to use address space more efficiently? > Being more efficient is only the start. In the end is 7 billion people vs less then 4 billion addresses. Rhere simply ain't a way around it, face it and deploy IPv6 or somewhere somebody will pay these prices (or more likely start a war). MarcoH From leo.vegoda at icann.org Mon Jul 6 20:57:06 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 6 Jul 2009 11:57:06 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: Message-ID: On 06/07/2009 2:45, "Sander Steffann" wrote: [...] >> A whole /8 for might be more than necessary for this though. > > Maybe we can reserve a certain amount of address space for this. A > whole /8 might indeed be too much. The RIPE NCC seems to grow with > about 700 new LIRs each year. If we want to have at least enough for > the first 5 years we need 3500 blocks of address space. Let's round > that up to 4096. If we use a fixed allocation size of /22 we will need > to reserve a /10. That leaves 3/4 of the final /8 for the existing LIRs. I think it is also important to take account of non-member registrations. As I understand it, the RIPE NCC has been making more PI assignments than allocations for a good four or five years. If address space is only available to LIRs (members) then anyone who previously would have settled for a little bit of PI would need to become a member. The reserved space would be used up faster than a projection based on new member allocations alone would suggest. It would be helpful if RIPE NCC staff could provide statistics showing the number and size distribution of PI assignments over the last five years. It would also be good to know how much of the address space currently set aside for PI assignments remains available. Regards, Leo Vegoda From drc at virtualized.org Mon Jul 6 21:28:48 2009 From: drc at virtualized.org (David Conrad) Date: Mon, 6 Jul 2009 12:28:48 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D77B220A96@SUEX07-MBX-04.ad.syr.edu> <621AD5EE-36B1-4B05-9EAE-A1A21DCBB7A2@marcoh.net> <77AB6C3A-6065-4CDA-9934-3FB0B2ACBAAE@virtualized.org> Message-ID: Marco, On Jul 6, 2009, at 11:20 AM, Marco Hogewoning wrote: > Being more efficient is only the start. In the end is 7 billion > people vs less then 4 billion addresses. Two answers: - Number of people is mostly irrelevant. How many addresses does someone who doesn't have electricity or a telephone need? - An IPv4 market is likely a temporary situation until IPv6 is deployed. > Rhere simply ain't a way around it, face it and deploy IPv6 or > somewhere somebody will pay these prices (or more likely start a war). Deploying IPv6 is not free. Which costs less, buying IPv4 address space (black market or no) or deploying IPv6? Which brings more benefit given the state of the IPv6 Internet? Regards, -drc From mohta at necom830.hpcl.titech.ac.jp Mon Jul 6 23:35:59 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 07 Jul 2009 06:35:59 +0900 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <77AB6C3A-6065-4CDA-9934-3FB0B2ACBAAE@virtualized.org> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D77B220A96@SUEX07-MBX-04.ad.syr.edu> <621AD5EE-36B1-4B05-9EAE-A1A21DCBB7A2@marcoh.net> <77AB6C3A-6065-4CDA-9934-3FB0B2ACBAAE@virtualized.org> Message-ID: <4A526E3F.4080707@necom830.hpcl.titech.ac.jp> David Conrad wrote: >> But we all know that not any amount of money will create more >> addresses as we currently have, so why not 1,000,000,000,000,000 dollar. > It isn't about creating more addresses. It is about using the existing > addresses more efficiently. Given the widespread availability of NAT, > how many addresses does the average organization actually need? Two > (one for their NAT gateway, one for their publicly available > services)? Particularly if they have a financial incentive to > use address space more efficiently? Assuming NAT financially mandated for new comers, it is not fair not to assume (or mandate) NAT for people currently requesting addresses. So, we should reduce allocated address block size a lot well before we start using the final /8. For example, if NAT reduces address requirement 1/256, an ISP having 65536 customers should be allocated just /24 or maybe /25 but not /16. If we do so now, IPv4 addresses will last almost forever, especially if we start allocating class E in the future before the final /8 (among classes A, B and C) is exhausted. Population does count, though very roughly. That is, though 4 billion may not be enough for requests from 7 billion people, 4 billion should be enough if the number of request is reduced 1/256. Masataka Ohta From randy at psg.com Tue Jul 7 00:41:31 2009 From: randy at psg.com (Randy Bush) Date: Tue, 07 Jul 2009 07:41:31 +0900 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> Message-ID: > Transfers from whom ? The /24 they are going to get for > 1,000,000,000,000,000 dollar from an "old company" ? is this the arin list, which is all about fantasy, black helicopters, and bullshit? randy From nick at inex.ie Tue Jul 7 00:53:45 2009 From: nick at inex.ie (Nick Hilliard) Date: Mon, 06 Jul 2009 23:53:45 +0100 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4A528079.1030905@inex.ie> On 06/07/2009 23:41, Randy Bush wrote: > is this the arin list, which is all about fantasy, black helicopters, > and bullshit? No, this is the european list and we're all frightfully sensible over here. Not a single black helicopter in sight. Must be something they put in the water. I ought to inject content at this point, but the topic is perilously close to a committee discussion on potential future deck-chair arrangements. So, instead I'd like to give a "me too" to Peter Koch's contribution: On 05/07/2009 17:56, Peter Koch wrote: > before diving into these or before selecting different options, shouldn't > the overall goals of, say, "fairness" and "sustainability" be broken down > into a tangible set of criteria against which the solutions could be evaluated? > This would also ease the assessment of potential subversion tactics. We have already asked the important question "what are we trying to do?", to which "find a fair solution for doling out the last /8". As Peter and others have suggested, we cannot hope to find this "fairness" ideal unless we have a yardstick with which to measure it. Nick From marcoh at marcoh.net Tue Jul 7 01:03:25 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 7 Jul 2009 01:03:25 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <1246867653.10778.46.camel@obelix> References: <1246867653.10778.46.camel@obelix> Message-ID: On Jul 6, 2009, at 10:07 AM, Per Heldal wrote: > On Sun, 2009-07-05 at 11:12 +0200, Sander Steffann wrote: >> Hello WG, >> >> I want to continue the discussion about the Final /8 proposals >> (2008-06 and 2009-04). The responses to my last question ("Do we >> (this >> working group) want to put IPv6 related requirements in the policy?") >> were 100% negative: We don't want IPv6 related requirements in the >> Final /8 policy. > > I think APNIC has got it mostly right. To reserve some space for > transition-services is the only suggestion I've seen that can have a > lasting effect throughout the transition period. Everything else has > been/is about skewing the balance to change who gets most out of the > remaining chunks. > > Keep it simple. One single fixed-size block for each new registrant > that > qualify for or already has a v6 block, and no prior v4 allocation. > > A whole /8 for might be more than necessary for this though. How > many /20 - /22 -size allocations does RIPE-NCC make each year where > the > registrant has no prior allocation? > > The intention of such a policy is IMHO primarily to protect new > innovative players from abuse (extortion) by the V4 powerhouses. Once > established they should seek expansion elsewhere (v6) or compete for > the > same resources as everyone else. One-size-fits all is therefore > appropriate, as it would be near impossible for the NCC to > differentiate. This more or less makes sense, you might define these blocks as "PI" to circumvent the whole membership discussion and wether or not a reciver of such block should need to be PI. MarcoH From marcoh at marcoh.net Tue Jul 7 01:10:36 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 7 Jul 2009 01:10:36 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> Message-ID: <6058CA9C-002D-43D6-B79D-14707A0F6C80@marcoh.net> On Jul 7, 2009, at 12:41 AM, Randy Bush wrote: >> Transfers from whom ? The /24 they are going to get for >> 1,000,000,000,000,000 dollar from an "old company" ? > > is this the arin list, which is all about fantasy, black helicopters, > and bullshit? Let me be more clear. I personally don't think address transfers will save the world, sharing is difficult for most people, let alone if the resource in question is getting more and more scarce. Maybe it's just me, but transfers with or without money will probably not meet any of the fairness requirements we might come up with and I do think for the sake of it all we might want to try and keep it a level playing field as long as we can to prevent the worst case scenario of a netsplit. MarcoH From scottleibrand at gmail.com Tue Jul 7 01:18:20 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 06 Jul 2009 16:18:20 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <6058CA9C-002D-43D6-B79D-14707A0F6C80@marcoh.net> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <6058CA9C-002D-43D6-B79D-14707A0F6C80@marcoh.net> Message-ID: <4A52863C.7080708@gmail.com> Marco Hogewoning wrote: > > Let me be more clear. I personally don't think address transfers will > save the world, sharing is difficult for most people, let alone if the > resource in question is getting more and more scarce. > > Maybe it's just me, but transfers with or without money will probably > not meet any of the fairness requirements we might come up with and I > do think for the sake of it all we might want to try and keep it a > level playing field as long as we can to prevent the worst case > scenario of a netsplit. What do you think the important fairness requirements are? Is it sufficient to make sure that every network with IPv6 PI space can also get a small IPv4 PI block with which to talk to the IPv4 Internet? If so, I think that's pretty straightforward: reserve a /9 or /10 and give out a maximum of /22 or so, one block per multihomed org. Or do you think we need to attempt to make larger blocks available on some sort of justified need basis? If so, how do you propose to ration the space to meet your fairness requirements? -Scott From randy at psg.com Tue Jul 7 01:33:35 2009 From: randy at psg.com (Randy Bush) Date: Tue, 07 Jul 2009 08:33:35 +0900 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <6058CA9C-002D-43D6-B79D-14707A0F6C80@marcoh.net> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <6058CA9C-002D-43D6-B79D-14707A0F6C80@marcoh.net> Message-ID: >>> Transfers from whom ? The /24 they are going to get for >>> 1,000,000,000,000,000 dollar from an "old company" ? >> is this the arin list ... > Let me be more clear. I personally don't think address transfers will > save the world, sharing is difficult for most people, let alone if the > resource in question is getting more and more scarce. i doubt many people think transfers will save the ipv4 internet, let alone the world. imiho, they are a small thing that can be done to make dealing with the self-inflited disaster a bit more flexible. and making them easy and open will improve the quality of our registration data. > Maybe it's just me, but transfers with or without money will probably > not meet any of the fairness requirements we might come up with and I > do think for the sake of it all we might want to try and keep it a > level playing field as long as we can to prevent the worst case > scenario of a netsplit. perhaps it is my bad memory, but i have not heard anyone say that transfer will be particularly fair. i believe the proposals under discussion are meant to address that. i was particularly objection to your hyperbole on the likely price of a /24. randy From marcoh at marcoh.net Tue Jul 7 02:08:00 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 7 Jul 2009 02:08:00 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <6058CA9C-002D-43D6-B79D-14707A0F6C80@marcoh.net> Message-ID: <5AF3F57E-72B0-47F6-A4C5-737512B2E7C7@marcoh.net> On Jul 7, 2009, at 1:33 AM, Randy Bush wrote: >>>> Transfers from whom ? The /24 they are going to get for >>>> 1,000,000,000,000,000 dollar from an "old company" ? >>> is this the arin list ... > >> Let me be more clear. I personally don't think address transfers will >> save the world, sharing is difficult for most people, let alone if >> the >> resource in question is getting more and more scarce. > > i doubt many people think transfers will save the ipv4 internet, let > alone the world. imiho, they are a small thing that can be done to > make > dealing with the self-inflited disaster a bit more flexible. and > making > them easy and open will improve the quality of our registration data. Absolutely true, if they do take place it should be clear what's transfered and under what conditions. But I don't think there will be much addresses to be transferred as a start. > >> Maybe it's just me, but transfers with or without money will probably >> not meet any of the fairness requirements we might come up with and I >> do think for the sake of it all we might want to try and keep it a >> level playing field as long as we can to prevent the worst case >> scenario of a netsplit. > > perhaps it is my bad memory, but i have not heard anyone say that > transfer will be particularly fair. i believe the proposals under > discussion are meant to address that. > > i was particularly objection to your hyperbole on the likely price > of a > /24. The number of zero's I put in might be a bit big. On the other hand anything can happen, tulip bulbs once also cost a fortune. MarcoH From marcoh at marcoh.net Tue Jul 7 02:12:36 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 7 Jul 2009 02:12:36 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <4A52863C.7080708@gmail.com> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <6058CA9C-002D-43D6-B79D-14707A0F6C80@marcoh.net> <4A52863C.7080708@gmail.com> Message-ID: <6D61C205-277B-4D9C-83FD-001CFD2B1387@marcoh.net> On Jul 7, 2009, at 1:18 AM, Scott Leibrand wrote: > Marco Hogewoning wrote: >> >> Let me be more clear. I personally don't think address transfers >> will save the world, sharing is difficult for most people, let >> alone if the resource in question is getting more and more scarce. >> >> Maybe it's just me, but transfers with or without money will >> probably not meet any of the fairness requirements we might come up >> with and I do think for the sake of it all we might want to try and >> keep it a level playing field as long as we can to prevent the >> worst case scenario of a netsplit. > > What do you think the important fairness requirements are? > > Is it sufficient to make sure that every network with IPv6 PI space > can also get a small IPv4 PI block with which to talk to the IPv4 > Internet? If so, I think that's pretty straightforward: reserve a / > 9 or /10 and give out a maximum of /22 or so, one block per > multihomed org. > > Or do you think we need to attempt to make larger blocks available > on some sort of justified need basis? If so, how do you propose to > ration the space to meet your fairness requirements? I'm thinking about the first option. Give any applicant who can justify the need a small specific block to maintain enough infrastrcture to be reachable from "the other side", think about nameservers, MX hosts and such. Given the potientially huge numbers I don't think we can cater for an access infrastructure, for those you have to go NAT and deploy IPv6. MarcoH From jwkckid1 at ix.netcom.com Tue Jul 7 04:31:56 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Mon, 06 Jul 2009 19:31:56 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4A52B39C.3456473A@ix.netcom.com> Randy and all, I guess so? Seems that BS swirls around ARIN still much the same as it does ICANN. So what else is new? Randy Bush wrote: > > Transfers from whom ? The /24 they are going to get for > > 1,000,000,000,000,000 dollar from an "old company" ? > > is this the arin list, which is all about fantasy, black helicopters, > and bullshit? > > randy Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From jwkckid1 at ix.netcom.com Tue Jul 7 04:34:29 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Mon, 06 Jul 2009 19:34:29 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> Message-ID: <4A52B434.D7CAF418@ix.netcom.com> Nick and all, Good final point Nick! So as I ask two days ago now, how is the reclamation effort going for all those IPv4's that are allocated but not used or likely to be use by those they were allocated to? Nick Hilliard wrote: > On 06/07/2009 23:41, Randy Bush wrote: > > is this the arin list, which is all about fantasy, black helicopters, > > and bullshit? > > No, this is the european list and we're all frightfully sensible over here. > Not a single black helicopter in sight. Must be something they put in > the water. > > I ought to inject content at this point, but the topic is perilously close > to a committee discussion on potential future deck-chair arrangements. So, > instead I'd like to give a "me too" to Peter Koch's contribution: > > On 05/07/2009 17:56, Peter Koch wrote: > > before diving into these or before selecting different options, shouldn't > > the overall goals of, say, "fairness" and "sustainability" be broken down > > into a tangible set of criteria against which the solutions could be evaluated? > > This would also ease the assessment of potential subversion tactics. > > We have already asked the important question "what are we trying to do?", > to which "find a fair solution for doling out the last /8". > > As Peter and others have suggested, we cannot hope to find this "fairness" > ideal unless we have a yardstick with which to measure it. > > Nick Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From mueller at syr.edu Mon Jul 6 18:26:38 2009 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 6 Jul 2009 12:26:38 -0400 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> Message-ID: <75822E125BCB994F8446858C4B19F0D77B220A96@SUEX07-MBX-04.ad.syr.edu> Any evidence that v4 addresses in /24 quantity have traded for such sums? Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org > -----Original Message----- > From: Marco Hogewoning [mailto:marcoh at marcoh.net] > Sent: Monday, July 06, 2009 11:47 AM > To: Milton L Mueller > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] The final /8 policy proposals, part 2 > > > On Jul 5, 2009, at 6:04 PM, Milton L Mueller wrote: > > > > > > >> -----Original Message----- > >> > >> I think it is important to think about new companies. They > will very > >> probably require some IPv4 address space during the transition from > >> IPv4 to IPv6. I think the whole community will be in a lot > of trouble > >> if we make a policy that makes it impossible for new entrants to > >> participate in a dual-stack world. > >> > > > > A legitimate concern. But: > > > > 1. address transfers might make it possible for them to acquire v4 > > addresses > > Transfers from whom ? The /24 they are going to get for > 1,000,000,000,000,000 dollar from an "old company" ? > > MarcoH > > From bmanning at vacation.karoshi.com Tue Jul 7 05:25:28 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 7 Jul 2009 03:25:28 +0000 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <6058CA9C-002D-43D6-B79D-14707A0F6C80@marcoh.net> Message-ID: <20090707032528.GB21644@vacation.karoshi.com.> On Tue, Jul 07, 2009 at 08:33:35AM +0900, Randy Bush wrote: > > perhaps it is my bad memory, but i have not heard anyone say that > transfer will be particularly fair. > > randy i suspect that for a valid transfer, both (presuming only two, for the purposes of this discussion) parties will consider it fair. no doubt there will be some other party who finds the situation intolerable and will involke the Robert Mugabe-like policies of exapropriation in the name of universal good. fairness is often in the eye/routing table/wallet of the beholder. --bill From Andreas at Schachtner.eu Tue Jul 7 12:49:27 2009 From: Andreas at Schachtner.eu (Andreas Schachtner) Date: Tue, 07 Jul 2009 12:49:27 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <20090705164117.GB26102@Space.Net> References: <20090705101948.CB1175B0D1@linux.local> <20090705164117.GB26102@Space.Net> Message-ID: <20090707104927.6F4B25B132@linux.local> ... > How exactly would "downscaling" work? A company demonstrates need for (say) > a /19, and they get 8192/64 = a /25 - while a newcomer demonstrates the > need for a /24, and gets a /30... Aehem, a fixed threshold to give them a reasonable IPv4 footprint would do. But this is a quick answer, again. Proper engineering is needed, not to end in dead ends. > > So if we go that way, quite some thought needs to go into implementation > details. Definitely. Regards, Andreas I agree with Peters comment, to think about "fairness" and "sustainability". But the latter, IHMO contradicts with Randy's comment, that IPv4 has no future (to which I agree also). In the first of Sander's questions, there were no one favouring IPv6 requirements with IPv4 allocations, so that's out of scope right now, UNLESS we're reopening that topic again (which I won't do). What's left over, is to look into the "fairness", which is achieved partly, that I request and monitor, that everybody still requesting IPv4 plays by the rules: For allowing "sustainability" for a couple of years, everybody has to deploy multiplexing techniques for newly allocated adress ranges. [This might introduce IPv6 requirements through a backdoos, as deploying multiplexing techniques may prove as expensive as migrating to IPv6, or even more.] > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 128645 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > -- -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From Andreas at Schachtner.eu Tue Jul 7 12:49:53 2009 From: Andreas at Schachtner.eu (Andreas Schachtner) Date: Tue, 07 Jul 2009 12:49:53 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <20090705165629.GB23558@x27.adm.denic.de> References: <20090705101948.CB1175B0D1@linux.local> <20090705164117.GB26102@Space.Net> <20090705165629.GB23558@x27.adm.denic.de> Message-ID: <20090707104953.C019B5B132@linux.local> Hi Peter, ... > before diving into these or before selecting different options, shouldn't > the overall goals of, say, "fairness" and "sustainability" be broken down > into a tangible set of criteria against which the solutions could be evaluated? > This would also ease the assessment of potential subversion tactics. I agree with your comment, to think about "fairness" and "sustainability". But the latter, IHMO contradicts with Randy's comment, that IPv4 has no future (to which I agree also). In the first of Sander's questions, there were no one favouring IPv6 requirements with IPv4 allocations, so that's out of scope right now, UNLESS we're reopening that topic again (which I won't do). What's left over, is to look into the "fairness", which is achieved partly, that I request and monitor, that everybody still requesting IPv4 plays by the rules: For allowing some "sustainability" for a couple of years, everybody has to deploy multiplexing techniques for newly allocated adress ranges. [This might introduce IPv6 requirements through a backdoos, as deploying multiplexing techniques may prove as expensive as migrating to IPv6, or even more.] Regards, Andreas -- -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From gert at space.net Wed Jul 8 10:37:28 2009 From: gert at space.net (Gert Doering) Date: Wed, 8 Jul 2009 10:37:28 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <4A52B434.D7CAF418@ix.netcom.com> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> Message-ID: <20090708083728.GS26102@Space.Net> Hi, On Mon, Jul 06, 2009 at 07:34:29PM -0700, Jeffrey A. Williams wrote: > Good final point Nick! So as I ask two days ago now, how is > the reclamation effort going for all those IPv4's that are allocated > but not used or likely to be use by those they were allocated to? Please stick to the topic of *this* discussion. Even with reclamation efforts, eventually we will reach the last /8, and *this* discussion is only covering the rules for the last /8. If you want to discuss reclamation efforts and policies, please open a new thread with a new subject. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From mohta at necom830.hpcl.titech.ac.jp Wed Jul 8 15:46:36 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 08 Jul 2009 22:46:36 +0900 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <20090708083728.GS26102@Space.Net> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> Message-ID: <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> Gert Doering wrote: > Please stick to the topic of *this* discussion. Even with reclamation > efforts, eventually we will reach the last /8, Why? Assuming reduction of address space consumption by mandating NAT, I can't understand how the last /8 could be reached before IPv4 will be replaced by something not likely to be IPv6. Could you elaborate? > and *this* discussion is > only covering the rules for the last /8. I don't think it off topic to discuss whether there will be the last /8 or not. It is a fair counter argument against a policy proposal on the last /8 to say there won't be the last /8. Masataka Ohta From remco.vanmook at eu.equinix.com Wed Jul 8 16:11:13 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Wed, 08 Jul 2009 16:11:13 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> Message-ID: (cut down on the CC list) Dear Masataka, Would you please enlighten us by sharing how this scheme would work ? I?m intrigued. Given the current rate of consumption I don?t see how we could possibly not hit the last /8. If you think the single act of mandating NAT will make the rate of IPv4 consumption stop on a dime it would have happened long ago and at the same time would not change the non-technical aspects of the problem at all. Regardless of how exactly you do it, adding NAT (or any other form of complexity) inevitably adds cost. LIRs on the whole are strongly cost-driven, especially in the current financial climate; investing in more kit than strictly required is a no-sell business case. Just using up more IPv4 is cheaper in the short run than any other alternative, so it will be the preferred way for a lot of people. Can we please have the discussion about what to do with the last /8 at the risk of not ever needing the bit of policy that comes out of it? The least thing it does is showing the outside world that we, as a community, care. Best, Remco On 08-07-09 15:46, "Masataka Ohta" wrote: > Gert Doering wrote: > >> > Please stick to the topic of *this* discussion. Even with reclamation >> > efforts, eventually we will reach the last /8, > > Why? > > Assuming reduction of address space consumption by mandating NAT, > I can't understand how the last /8 could be reached before IPv4 > will be replaced by something not likely to be IPv6. > > Could you elaborate? > >> > and *this* discussion is >> > only covering the rules for the last /8. > > I don't think it off topic to discuss whether there will be the > last /8 or not. > > It is a fair counter argument against a policy proposal on the > last /8 to say there won't be the last /8. > > Masataka Ohta > > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexlh at ripe.net Wed Jul 8 16:43:43 2009 From: alexlh at ripe.net (Alex Le Heux) Date: Wed, 8 Jul 2009 16:43:43 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: Message-ID: My draft... On Jul 6, 2009, at 20:57, Leo Vegoda wrote: [...] > It would be helpful if RIPE NCC staff could provide statistics > showing the > number and size distribution of PI assignments over the last five > years. It > would also be good to know how much of the address space currently > set aside > for PI assignments remains available. Dear Leo, IPv4 PI Number of assignments size 2004 2005 2006 2007 2008 2009 /16 0 0 1 0 0 2 /17 2 0 1 1 0 0 /18 3 1 2 3 10 2 /19 12 3 7 4 12 10 /20 23 25 28 23 44 23 /21 54 51 56 89 100 52 /22 236 260 260 260 399 192 /23 359 384 463 776 571 244 /24 551 724 895 972 1046 440 /25 11 9 22 8 8 6 /26 7 7 6 0 5 1 /27 7 4 8 8 7 2 /28 0 0 8 0 1 0 /29 0 2 1 0 8 0 total 1265 1470 1758 2151 2211 974 Note: Both /16 assignments in 2009 are temporary assignments that will be returned before the end of the year. IPv4 PI Assignment size year total IPs 2004 986400 2005 897744 2006 1153800 2007 1305312 2008 1617520 2009 881536 IPv4 Allocation numbers and sizes year number total size 2004 1001 37838336 2005 1143 57196544 2006 1213 59731968 2007 1333 62085120 2008 1649 44496896 2009 844 24535040 To put these numbers in perspective: The RIPE NCC assigns more PI prefixes than we allocate as PA, while the number of IPs assigned as PI is around 3% of the total that we assign or allocate. The RIPE NCC does not set aside address space for PI assignments larger than the current minimum allocation size, a /21, because these assignments can be made from any of our IANA allocations. We do mark some free blocks with a minimum allocation size of less than a /21 as usable for smaller PI assignments. This list is periodically reviewed and currently contains a bit over a /11 of address space. If you have any questions about these numbers, please do not hesitate to ask. Best regards, Alex Le Heux RIPE NCC From alexlh at ripe.net Wed Jul 8 16:46:38 2009 From: alexlh at ripe.net (Alex Le Heux) Date: Wed, 8 Jul 2009 16:46:38 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: Message-ID: <693CD55D-8AC7-4702-B5B1-F067C2292507@ripe.net> On Jul 8, 2009, at 16:43, Alex Le Heux wrote: > My draft... This email was not the draft, it is the final version. Apologies for the confusion. Alex Le Heux RIPE NCC > On Jul 6, 2009, at 20:57, Leo Vegoda wrote: > > [...] > >> It would be helpful if RIPE NCC staff could provide statistics >> showing the >> number and size distribution of PI assignments over the last five >> years. It >> would also be good to know how much of the address space currently >> set aside >> for PI assignments remains available. > > Dear Leo, > > IPv4 PI Number of assignments > > size 2004 2005 2006 2007 2008 2009 > /16 0 0 1 0 0 2 > /17 2 0 1 1 0 0 > /18 3 1 2 3 10 2 > /19 12 3 7 4 12 10 > /20 23 25 28 23 44 23 > /21 54 51 56 89 100 52 > /22 236 260 260 260 399 192 > /23 359 384 463 776 571 244 > /24 551 724 895 972 1046 440 > /25 11 9 22 8 8 6 > /26 7 7 6 0 5 1 > /27 7 4 8 8 7 2 > /28 0 0 8 0 1 0 > /29 0 2 1 0 8 0 > total 1265 1470 1758 2151 2211 974 > > Note: Both /16 assignments in 2009 are temporary assignments that will > be returned before the end of the year. > > IPv4 PI Assignment size > > year total IPs > > 2004 986400 > 2005 897744 > 2006 1153800 > 2007 1305312 > 2008 1617520 > 2009 881536 > > IPv4 Allocation numbers and sizes > > year number total size > > 2004 1001 37838336 > 2005 1143 57196544 > 2006 1213 59731968 > 2007 1333 62085120 > 2008 1649 44496896 > 2009 844 24535040 > > To put these numbers in perspective: The RIPE NCC assigns more > PI prefixes than we allocate as PA, while the number of IPs assigned > as PI is around 3% of the total that we assign or allocate. > > The RIPE NCC does not set aside address space for PI assignments > larger than the current minimum allocation size, a /21, because these > assignments can be made from any of our IANA allocations. We do mark > some free blocks with a minimum allocation size of less than a /21 as > usable for smaller PI assignments. This list is periodically reviewed > and currently contains a bit over a /11 of address space. > > If you have any questions about these numbers, please do not hesitate > to ask. > > Best regards, > > Alex Le Heux > RIPE NCC > Best regards, Alex Le Heux RIPE NCC IP Resource Analyst From mohta at necom830.hpcl.titech.ac.jp Wed Jul 8 16:47:16 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 08 Jul 2009 23:47:16 +0900 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: Message-ID: <4A54B174.5040802@necom830.hpcl.titech.ac.jp> Remco van Mook wrote: Note that inappropriate characters in my environment is automatically converted to question marks. > Dear Masataka, > > Would you please enlighten us by sharing how this scheme would work ? I'm saying the scheme should work. > I?m > intrigued. Given the current rate of consumption I don?t see how we could > possibly not hit the last /8. If you think the single act of mandating NAT > will make the rate of IPv4 consumption stop on a dime it would have happened > long ago and at the same time would not change the non-technical aspects of > the problem at all. The current rate is the rate without NAT mandated. With mandated NAT, ISPs have difficulty to authorize their address requests unless the amount of the requests reduced by NAT. If NAT is mandated before the final /8 (among classes A, B and C), we have much time to support unicast class E, which further delay the final /8. > Regardless of how exactly you do it, adding NAT (or any > other form of complexity) inevitably adds cost. LIRs on the whole are > strongly cost-driven, especially in the current financial climate; investing > in more kit than strictly required is a no-sell business case. Considering the so much delayed deployment of IPv6, when we start allocating the final /8, addition of NAT is inevitable, especially because buying already allocated space will cost a lot. Moreover, adding IPv6 costs a lot more than adding NAT, even when IPv6 is not popular and used by few customers, which is partly why IPv6 is not and will not be deployed very quickly. > Just using up more IPv4 is cheaper in the short run than any other > alternative, so it will be the preferred way for a lot of people. And, it is not fair for those people requesting IPv4 in the future. > Can we please have the discussion about what to do with the last /8 at the > risk of not ever needing the bit of policy that comes out of it? The best thing we can do with the last /8 is to prevent the occurrence of it. Masataka Ohta From leo.vegoda at icann.org Wed Jul 8 17:40:17 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 8 Jul 2009 08:40:17 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: Message-ID: Hi Alex, Thank you for these numbers. I think they are very useful. On 08/07/2009 7:43, "Alex Le Heux" wrote: > size 2004 2005 2006 2007 2008 2009 > /16 0 0 1 0 0 2 > /17 2 0 1 1 0 0 > /18 3 1 2 3 10 2 > /19 12 3 7 4 12 10 > /20 23 25 28 23 44 23 > /21 54 51 56 89 100 52 > /22 236 260 260 260 399 192 This suggests to me that if the default allocation from a reserved prefix is a /22, as suggested earlier, then we should assume that there will be at least an extra 300-400 prefixes used per year just from people who will request PI and maybe add some more onto that from people who would have been happy with a PA assignment but won't be able to get it. I think reserving a /10 to be cut into /22s would underestimate demand for the space. I doubt it would last anywhere near five years. We should probably consider whether we reserve more space or divide whatever we reserve into longer prefixes, maybe /24s. Regards, Leo Vegoda From mark at streamservice.nl Wed Jul 8 18:55:43 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Wed, 8 Jul 2009 18:55:43 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: Message-ID: <009001c9ffec$ee6ceb10$cb46c130$@nl> Hello Alex, So if I understand correctly a new LIR will get at least a /21 range (IPv4)? Maybe this should be reduced to a /24 or /23 when we reach the last /8 range. Regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Alex Le Heux Sent: woensdag 8 juli 2009 16:44 To: Leo Vegoda Cc: Address Policy Working Group Subject: Re: [address-policy-wg] The final /8 policy proposals, part 2 My draft... On Jul 6, 2009, at 20:57, Leo Vegoda wrote: [...] > It would be helpful if RIPE NCC staff could provide statistics > showing the > number and size distribution of PI assignments over the last five > years. It > would also be good to know how much of the address space currently > set aside > for PI assignments remains available. Dear Leo, IPv4 PI Number of assignments size 2004 2005 2006 2007 2008 2009 /16 0 0 1 0 0 2 /17 2 0 1 1 0 0 /18 3 1 2 3 10 2 /19 12 3 7 4 12 10 /20 23 25 28 23 44 23 /21 54 51 56 89 100 52 /22 236 260 260 260 399 192 /23 359 384 463 776 571 244 /24 551 724 895 972 1046 440 /25 11 9 22 8 8 6 /26 7 7 6 0 5 1 /27 7 4 8 8 7 2 /28 0 0 8 0 1 0 /29 0 2 1 0 8 0 total 1265 1470 1758 2151 2211 974 Note: Both /16 assignments in 2009 are temporary assignments that will be returned before the end of the year. IPv4 PI Assignment size year total IPs 2004 986400 2005 897744 2006 1153800 2007 1305312 2008 1617520 2009 881536 IPv4 Allocation numbers and sizes year number total size 2004 1001 37838336 2005 1143 57196544 2006 1213 59731968 2007 1333 62085120 2008 1649 44496896 2009 844 24535040 To put these numbers in perspective: The RIPE NCC assigns more PI prefixes than we allocate as PA, while the number of IPs assigned as PI is around 3% of the total that we assign or allocate. The RIPE NCC does not set aside address space for PI assignments larger than the current minimum allocation size, a /21, because these assignments can be made from any of our IANA allocations. We do mark some free blocks with a minimum allocation size of less than a /21 as usable for smaller PI assignments. This list is periodically reviewed and currently contains a bit over a /11 of address space. If you have any questions about these numbers, please do not hesitate to ask. Best regards, Alex Le Heux RIPE NCC From gert at space.net Wed Jul 8 22:53:49 2009 From: gert at space.net (Gert Doering) Date: Wed, 8 Jul 2009 22:53:49 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> Message-ID: <20090708205349.GD26102@Space.Net> Hi, On Wed, Jul 08, 2009 at 10:46:36PM +0900, Masataka Ohta wrote: > Gert Doering wrote: > > > Please stick to the topic of *this* discussion. Even with reclamation > > efforts, eventually we will reach the last /8, > > Why? > > Assuming reduction of address space consumption by mandating NAT, > I can't understand how the last /8 could be reached before IPv4 > will be replaced by something not likely to be IPv6. > > Could you elaborate? There is no mandate to use NAT in the RIPE region (and I think that this is a good thing, as NAT might be useful, but overall it takes away freedom from the Internet users, and this shouldn't be forced on anybody). If the RIPE community wants to force NAT on people, well, they can of course change the policy. But in the policy as it is now, there is nothing that can force NAT on anybody. Given this, and given the growth of Internet in less-developed regions, yes, it is very likely that we'll reach the last /8. And soon. > > and *this* discussion is > > only covering the rules for the last /8. > > I don't think it off topic to discuss whether there will be the > last /8 or not. By decree of the WG chair it is off-topic *in this discussion thread*. It is not off-topic on the list per se, but to keep some semblance of structure, *this* thread needs to focus on a very specific question. > It is a fair counter argument against a policy proposal on the > last /8 to say there won't be the last /8. Yes. But this specific discussion thread is about a very specific aspect of the proposal. Since we have different last-/8-Proposals on the table, we're trying to merge them into a common proposal, which you can then be opposed to. But please do this in a new discussion thread with a new Subject: line. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From jwkckid1 at ix.netcom.com Wed Jul 8 23:31:17 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Wed, 08 Jul 2009 14:31:17 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> Message-ID: <4A551025.EDA8AE6F@ix.netcom.com> Gert and all, Nice bit of deflection/pigionholing I must say. But yes the subject line is with finding a consensus policy, however that consensus if such exists, is measured, for determining what is now questionably perceived to be the last /8. So far I prefer Leo's earlier suggestions as such at least provides for the possibility of some future recovery of unused IPv4 addresses in a round about way. Gert Doering wrote: > Hi, > > On Wed, Jul 08, 2009 at 10:46:36PM +0900, Masataka Ohta wrote: > > Gert Doering wrote: > > > > > Please stick to the topic of *this* discussion. Even with reclamation > > > efforts, eventually we will reach the last /8, > > > > Why? > > > > Assuming reduction of address space consumption by mandating NAT, > > I can't understand how the last /8 could be reached before IPv4 > > will be replaced by something not likely to be IPv6. > > > > Could you elaborate? > > There is no mandate to use NAT in the RIPE region (and I think that this > is a good thing, as NAT might be useful, but overall it takes away freedom > from the Internet users, and this shouldn't be forced on anybody). > > If the RIPE community wants to force NAT on people, well, they can of > course change the policy. But in the policy as it is now, there is > nothing that can force NAT on anybody. Given this, and given the > growth of Internet in less-developed regions, yes, it is very likely > that we'll reach the last /8. And soon. > > > > and *this* discussion is > > > only covering the rules for the last /8. > > > > I don't think it off topic to discuss whether there will be the > > last /8 or not. > > By decree of the WG chair it is off-topic *in this discussion thread*. > > It is not off-topic on the list per se, but to keep some semblance of > structure, *this* thread needs to focus on a very specific question. > > > It is a fair counter argument against a policy proposal on the > > last /8 to say there won't be the last /8. > > Yes. But this specific discussion thread is about a very specific aspect > of the proposal. Since we have different last-/8-Proposals on the table, > we're trying to merge them into a common proposal, which you can then be > opposed to. > > But please do this in a new discussion thread with a new Subject: line. > > Gert Doering > -- APWG chair > -- > Total number of prefixes smaller than registry allocations: 128645 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > ------------------------------------------------------------------------ > Part 1.2Type: application/pgp-signature Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From mohta at necom830.hpcl.titech.ac.jp Thu Jul 9 00:39:20 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 09 Jul 2009 07:39:20 +0900 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <20090708205349.GD26102@Space.Net> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> Message-ID: <4A552018.9030407@necom830.hpcl.titech.ac.jp> Gert Doering wrote: >>>Even with reclamation >>>efforts, eventually we will reach the last /8, Assuming your point above is on topic, I don't think so. > There is no mandate to use NAT in the RIPE region (and I think that this > is a good thing, as NAT might be useful, but overall it takes away freedom > from the Internet users, and this shouldn't be forced on anybody). OK. I'll come back later after finishing a proposal of "end to end NAT", which has end to end transparency to be able to support ftp port command, SCTP, IPsec, DNS reverse look up, multicast, mobility and so on. > If the RIPE community wants to force NAT on people, well, they can of > course change the policy. As DRC wrote: : It isn't about creating more addresses. It is about using the existing : addresses more efficiently. Given the widespread availability of NAT, : how many addresses does the average organization actually need? Two : (one for their NAT gateway, one for their publicly available : services)? Particularly if they have a financial incentive to : use address space more efficiently? I think use of NAT in the future is inevitable and want fairness between policies today and in the future. Masataka Ohta From trejrco at gmail.com Thu Jul 9 01:23:06 2009 From: trejrco at gmail.com (trejrco at gmail.com) Date: Wed, 8 Jul 2009 23:23:06 +0000 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net><4A54A33C.9060401@necom830.hpcl.titech.ac.jp> Message-ID: <2024553563-1247095317-cardhu_decombobulator_blackberry.rim.net-280337554-@bxe1082.bisx.prod.on.blackberry> "It is a fair counter argument against a policy proposal on the last /8 to say there won't be the last /8." Really? IMHO these are two very different conversations - one is an "if", the other is a "when". In a case like this - as long as it is possible, it is worth being prepared for ... (And prolonging IPv4 will probably just delay its successor (IPv6 or not) even longer, meaning we would still have a last /8 discussion - just later on ... And that is assuming such a delaying-policy was even feasible/successful) FWLIW - I also disagree WRT IPv6 not being the successor to IPv4, but that is _also_ a separate conversation ... /TJ Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Masataka Ohta Date: Wed, 08 Jul 2009 22:46:36 To: Gert Doering Cc: Jeffrey A. Williams; Nick Hilliard; Randy Bush; Marco Hogewoning; Milton L Mueller; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] The final /8 policy proposals, part 2 Gert Doering wrote: > Please stick to the topic of *this* discussion. Even with reclamation > efforts, eventually we will reach the last /8, Why? Assuming reduction of address space consumption by mandating NAT, I can't understand how the last /8 could be reached before IPv4 will be replaced by something not likely to be IPv6. Could you elaborate? > and *this* discussion is > only covering the rules for the last /8. I don't think it off topic to discuss whether there will be the last /8 or not. It is a fair counter argument against a policy proposal on the last /8 to say there won't be the last /8. Masataka Ohta From jwkckid1 at ix.netcom.com Thu Jul 9 03:51:51 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Wed, 08 Jul 2009 18:51:51 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> Message-ID: <4A554D37.CF79A42C@ix.netcom.com> Masataka sama and all, I agree that NAT's are inevitable and are also a means by which the more efficient use of IP addresses can ( should? ) be realized. Masataka Ohta wrote: > Gert Doering wrote: > > >>>Even with reclamation > >>>efforts, eventually we will reach the last /8, > > Assuming your point above is on topic, I don't think so. > > > There is no mandate to use NAT in the RIPE region (and I think that this > > is a good thing, as NAT might be useful, but overall it takes away freedom > > from the Internet users, and this shouldn't be forced on anybody). > > OK. > > I'll come back later after finishing a proposal of "end to end NAT", > which has end to end transparency to be able to support ftp port > command, SCTP, IPsec, DNS reverse look up, multicast, mobility and > so on. > > > If the RIPE community wants to force NAT on people, well, they can of > > course change the policy. > > As DRC wrote: > > : It isn't about creating more addresses. It is about using the existing > : addresses more efficiently. Given the widespread availability of NAT, > : how many addresses does the average organization actually need? Two > : (one for their NAT gateway, one for their publicly available > : services)? Particularly if they have a financial incentive to > : use address space more efficiently? > > I think use of NAT in the future is inevitable and want fairness > between policies today and in the future. > > Masataka Ohta Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From jwkckid1 at ix.netcom.com Thu Jul 9 03:55:42 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Wed, 08 Jul 2009 18:55:42 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net><4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <2024553563-1247095317-cardhu_decombobulator_blackberry.rim.net-280337554-@bxe1082.bisx.prod.on.blackberry> Message-ID: <4A554E1D.CF2B2597@ix.netcom.com> TJ and all, I disagree that IPv6 will be/is/should be the only successor to IPv4. trejrco at gmail.com wrote: > "It is a fair counter argument against a policy proposal on the last /8 to say there won't be the last /8." > > Really? IMHO these are two very different conversations - one is an "if", the other is a "when". In a case like this - as long as it is possible, it is worth being prepared for ... > > (And prolonging IPv4 will probably just delay its successor (IPv6 or not) even longer, meaning we would still have a last /8 discussion - just later on ... And that is assuming such a delaying-policy was even feasible/successful) > > FWLIW - I also disagree WRT IPv6 not being the successor to IPv4, but that is _also_ a separate conversation ... > > /TJ > > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Masataka Ohta > > Date: Wed, 08 Jul 2009 22:46:36 > To: Gert Doering > Cc: Jeffrey A. Williams; Nick Hilliard; Randy Bush; Marco Hogewoning; Milton L Mueller; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] The final /8 policy proposals, part 2 > > Gert Doering wrote: > > > Please stick to the topic of *this* discussion. Even with reclamation > > efforts, eventually we will reach the last /8, > > Why? > > Assuming reduction of address space consumption by mandating NAT, > I can't understand how the last /8 could be reached before IPv4 > will be replaced by something not likely to be IPv6. > > Could you elaborate? > > > and *this* discussion is > > only covering the rules for the last /8. > > I don't think it off topic to discuss whether there will be the > last /8 or not. > > It is a fair counter argument against a policy proposal on the > last /8 to say there won't be the last /8. > > Masataka Ohta Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From trejrco at gmail.com Thu Jul 9 04:21:28 2009 From: trejrco at gmail.com (TJ) Date: Wed, 8 Jul 2009 22:21:28 -0400 Subject: [address-policy-wg] The final /8 policy proposals, part 2 ... veering onto a different (but realted topic) ... In-Reply-To: <4A554E1D.CF2B2597@ix.netcom.com> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net><4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <2024553563-1247095317-cardhu_decombobulator_blackberry.rim.net-280337554-@bxe1082.bisx.prod.on.blackberry> <4A554E1D.CF2B2597@ix.netcom.com> Message-ID: <00d301ca003b$ff207c70$fd617550$@com> Well, to be fair - while I _do_ believe IPv6 is the best available /feasible answer - I never said it was the only possible (part of the) answer. (IMHO - IPv6 addresses (pun intended) one of the primary problems IPv4 is facing, and provides several other areas of advancement ... so why wouldn't it be the successor to IPv4? (Above and beyond those, it has been deployed in the real world and proven to work - and is being actively (if not quite aggressively) deployed by many others)) /TJ >-----Original Message----- >From: Jeffrey A. Williams [mailto:jwkckid1 at ix.netcom.com] >Sent: Wednesday, July 08, 2009 9:56 PM >To: trejrco at gmail.com >Cc: address-policy-wg at ripe.net >Subject: Re: [address-policy-wg] The final /8 policy proposals, part 2 > >TJ and all, > > I disagree that IPv6 will be/is/should be the only successor to IPv4. > >trejrco at gmail.com wrote: > >> "It is a fair counter argument against a policy proposal on the last /8 to >say there won't be the last /8." >> >> Really? IMHO these are two very different conversations - one is an "if", >the other is a "when". In a case like this - as long as it is possible, it is >worth being prepared for ... >> >> (And prolonging IPv4 will probably just delay its successor (IPv6 or >> not) even longer, meaning we would still have a last /8 discussion - >> just later on ... And that is assuming such a delaying-policy was even >> feasible/successful) >> >> FWLIW - I also disagree WRT IPv6 not being the successor to IPv4, but that is >_also_ a separate conversation ... >> >> /TJ >> >> Sent from my Verizon Wireless BlackBerry >> >> -----Original Message----- >> From: Masataka Ohta >> >> Date: Wed, 08 Jul 2009 22:46:36 >> To: Gert Doering >> Cc: Jeffrey A. Williams; Nick >> Hilliard; Randy Bush; Marco >> Hogewoning; Milton L Mueller; >> address-policy-wg at ripe.net >> Subject: Re: [address-policy-wg] The final /8 policy proposals, part 2 >> >> Gert Doering wrote: >> >> > Please stick to the topic of *this* discussion. Even with >> > reclamation efforts, eventually we will reach the last /8, >> >> Why? >> >> Assuming reduction of address space consumption by mandating NAT, I >> can't understand how the last /8 could be reached before IPv4 will be >> replaced by something not likely to be IPv6. >> >> Could you elaborate? >> >> > and *this* discussion is >> > only covering the rules for the last /8. >> >> I don't think it off topic to discuss whether there will be the last >> /8 or not. >> >> It is a fair counter argument against a policy proposal on the last /8 >> to say there won't be the last /8. >> >> Masataka Ohta > >Regards, > >Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) >"Obedience of the law is the greatest freedom" - > Abraham Lincoln >"YES WE CAN!" Barack ( Berry ) Obama > >"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 My >Phone: 214-244-4827 From jwkckid1 at ix.netcom.com Thu Jul 9 05:38:25 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Wed, 08 Jul 2009 20:38:25 -0700 Subject: [address-policy-wg] The final /8 policy proposals, part 2 ... veering onto a different (but realted topic) ... References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net><4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <2024553563-1247095317-cardhu_decombobulator_blackberry.rim.net-280337554-@bxe1082.bisx.prod.on.blackberry> <4A554E1D.CF2B2597@ix.netcom.com> <00d301ca003b$ff207c70$fd617550$@com> Message-ID: <4A556630.E4EE9BC7@ix.netcom.com> TJ and all, I assume that there will be one or likely more than one successor ti IPv4 naturally. My previous point in part was that there is/will/should/ or could be more than one. My understanding was that there was or is only one. Such is/may not be true. My other implied point was that IPv4 is likely to be around for some time to come regardless of any replacement and that perhaps some reclamation is still in order so that there is not only a final /8. That is all... TJ wrote: > Well, to be fair - while I _do_ believe IPv6 is the best available /feasible > answer - I never said it was the only possible (part of the) answer. > > (IMHO - IPv6 addresses (pun intended) one of the primary problems IPv4 is > facing, and provides several other areas of advancement ... so why wouldn't > it be the successor to IPv4? (Above and beyond those, it has been deployed > in the real world and proven to work - and is being actively (if not quite > aggressively) deployed by many others)) > > /TJ > > >-----Original Message----- > >From: Jeffrey A. Williams [mailto:jwkckid1 at ix.netcom.com] > >Sent: Wednesday, July 08, 2009 9:56 PM > >To: trejrco at gmail.com > >Cc: address-policy-wg at ripe.net > >Subject: Re: [address-policy-wg] The final /8 policy proposals, part 2 > > > >TJ and all, > > > > I disagree that IPv6 will be/is/should be the only successor to IPv4. > > > >trejrco at gmail.com wrote: > > > >> "It is a fair counter argument against a policy proposal on the last /8 > to > >say there won't be the last /8." > >> > >> Really? IMHO these are two very different conversations - one is an > "if", > >the other is a "when". In a case like this - as long as it is possible, it > is > >worth being prepared for ... > >> > >> (And prolonging IPv4 will probably just delay its successor (IPv6 or > >> not) even longer, meaning we would still have a last /8 discussion - > >> just later on ... And that is assuming such a delaying-policy was even > >> feasible/successful) > >> > >> FWLIW - I also disagree WRT IPv6 not being the successor to IPv4, but > that is > >_also_ a separate conversation ... > >> > >> /TJ > >> > >> Sent from my Verizon Wireless BlackBerry > >> > >> -----Original Message----- > >> From: Masataka Ohta > >> > >> Date: Wed, 08 Jul 2009 22:46:36 > >> To: Gert Doering > >> Cc: Jeffrey A. Williams; Nick > >> Hilliard; Randy Bush; Marco > >> Hogewoning; Milton L Mueller; > >> address-policy-wg at ripe.net > >> Subject: Re: [address-policy-wg] The final /8 policy proposals, part 2 > >> > >> Gert Doering wrote: > >> > >> > Please stick to the topic of *this* discussion. Even with > >> > reclamation efforts, eventually we will reach the last /8, > >> > >> Why? > >> > >> Assuming reduction of address space consumption by mandating NAT, I > >> can't understand how the last /8 could be reached before IPv4 will be > >> replaced by something not likely to be IPv6. > >> > >> Could you elaborate? > >> > >> > and *this* discussion is > >> > only covering the rules for the last /8. > >> > >> I don't think it off topic to discuss whether there will be the last > >> /8 or not. > >> > >> It is a fair counter argument against a policy proposal on the last /8 > >> to say there won't be the last /8. > >> > >> Masataka Ohta > > > Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From alexlh at ripe.net Thu Jul 9 10:00:20 2009 From: alexlh at ripe.net (Alex Le Heux) Date: Thu, 9 Jul 2009 10:00:20 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <009001c9ffec$ee6ceb10$cb46c130$@nl> References: <009001c9ffec$ee6ceb10$cb46c130$@nl> Message-ID: Dear Mark, > So if I understand correctly a new LIR will get at least a /21 range > (IPv4)? > > Maybe this should be reduced to a /24 or /23 when we reach the last /8 > range. This is correct: The minimum allocation size is a /21, as described in the IPv4 Address Policy: 5.1 First Allocation The RIPE NCC?s minimum allocation size is /21. Best regards, Alex Le Heux RIPE NCC From ms at man-da.de Thu Jul 9 10:42:25 2009 From: ms at man-da.de (Marcus Stoegbauer) Date: Thu, 09 Jul 2009 10:42:25 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <4A554E1D.CF2B2597@ix.netcom.com> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net><4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <2024553563-1247095317-cardhu_decombobulator_blackberry.rim.net-280337554-@bxe1082.bisx.prod.on.blackberry> <4A554E1D.CF2B2597@ix.netcom.com> Message-ID: <4A55AD71.4030309@man-da.de> Jeffrey A. Williams wrote: > TJ and all, > > I disagree that IPv6 will be/is/should be the only successor to IPv4. I disagree with you disagreeing, and I'm doing it while sitting on a pony wearing a helmet. That being said, IPv6 is not the point of the discussion in this thread where the topic is "How shall we proceed with the final /8", so could you please open a new thread for philosophic discussions on the state of the internets? Thanks a lot, Marcus -- man-da.de GmbH, AS8365 Phone: +49 6151 16-6956 Petersenstr. 30 Fax: +49 6151 16-3050 D-64287 Darmstadt e-mail: ms at man-da.de Gesch?ftsf?hrer Marcus St?gbauer AG Darmstadt, HRB 94 84 From heldal at eml.cc Thu Jul 9 18:41:36 2009 From: heldal at eml.cc (Per Heldal) Date: Thu, 09 Jul 2009 18:41:36 +0200 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: References: Message-ID: <1247157696.20053.17.camel@obelix> On Wed, 2009-07-08 at 16:43 +0200, Alex Le Heux wrote: > IPv4 PI Number of assignments > > size 2004 2005 2006 2007 2008 2009 > /16 0 0 1 0 0 2 > /17 2 0 1 1 0 0 > /18 3 1 2 3 10 2 > /19 12 3 7 4 12 10 > /20 23 25 28 23 44 23 > /21 54 51 56 89 100 52 > /22 236 260 260 260 399 192 > /23 359 384 463 776 571 244 > /24 551 724 895 972 1046 440 > /25 11 9 22 8 8 6 > /26 7 7 6 0 5 1 > /27 7 4 8 8 7 2 > /28 0 0 8 0 1 0 > /29 0 2 1 0 8 0 > total 1265 1470 1758 2151 2211 974 > Do you have the data to split these numbers across two tables, one with 1st assignment to new registrants and one with extensions? //per From alexlh at ripe.net Fri Jul 10 10:11:56 2009 From: alexlh at ripe.net (Alex Le Heux) Date: Fri, 10 Jul 2009 09:11:56 +0100 Subject: [address-policy-wg] The final /8 policy proposals, part 2 In-Reply-To: <1247157696.20053.17.camel@obelix> References: <1247157696.20053.17.camel@obelix> Message-ID: <1D6014F2-D637-4CDB-9CCA-CB74B4906CF0@ripe.net> Dear Per, On Jul 9, 2009, at 17:41, Per Heldal wrote: > On Wed, 2009-07-08 at 16:43 +0200, Alex Le Heux wrote: > >> IPv4 PI Number of assignments >> >> size 2004 2005 2006 2007 2008 2009 >> /16 0 0 1 0 0 2 >> /17 2 0 1 1 0 0 >> /18 3 1 2 3 10 2 >> /19 12 3 7 4 12 10 >> /20 23 25 28 23 44 23 >> /21 54 51 56 89 100 52 >> /22 236 260 260 260 399 192 >> /23 359 384 463 776 571 244 >> /24 551 724 895 972 1046 440 >> /25 11 9 22 8 8 6 >> /26 7 7 6 0 5 1 >> /27 7 4 8 8 7 2 >> /28 0 0 8 0 1 0 >> /29 0 2 1 0 8 0 >> total 1265 1470 1758 2151 2211 974 >> > > Do you have the data to split these numbers across two tables, one > with > 1st assignment to new registrants and one with extensions? As this table concerns PI space, the vast majority of holders have only a single assignment. Therefore almost all of these concern new registrants. Best regards, Alex Le Heux RIPE NCC From mark at streamservice.nl Mon Jul 13 15:04:08 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Mon, 13 Jul 2009 15:04:08 +0200 Subject: [address-policy-wg] IPv6 PI In-Reply-To: References: <009001c9ffec$ee6ceb10$cb46c130$@nl> Message-ID: <00e201ca03ba$690cd710$3b268530$@nl> Hello, We are looking on getting an IPv6 PI range. But we want to use it for the same services we are running in the IPv4 world. Could you say if it is allowed under IPv6 PI (some say yes, some say no and if you ask me it should be: yes, of course it is allowed). The things we want to use IPv6 PI for: - dedicated servers (servers are owned by us) - co located servers (servers are owned by clients) - VPN (we have a few clients that use it, per VPN client at least 1 IP) - VPS guests (per VPS guest at least 1 IP) - https (per host an IP) And if it is not allowed: what would happen if we do it and someone discovers it. Thanks in advance for the answers. With kind regards, Mark Scholten From michiel at klaver.it Mon Jul 13 15:16:59 2009 From: michiel at klaver.it (Michiel Klaver) Date: Mon, 13 Jul 2009 15:16:59 +0200 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <00e201ca03ba$690cd710$3b268530$@nl> References: <009001c9ffec$ee6ceb10$cb46c130$@nl> <00e201ca03ba$690cd710$3b268530$@nl> Message-ID: <4A5B33CB.6060706@klaver.it> Dear Mark, We recently submitted PI request tickets to ripe for IPv4 and IPv6 with excactly the same details. The IPv4 request got assigned, the IPv6 rejected due to the difference in the policies regarding VPN connections (internet access). ----- Original message ----- > The PI IPv6 assignment cannot be further assigned to other organisations. > http://www.ripe.net/ripe/docs/ripe-472.html#_8._IPv6_Provider > > The definition of what an Infrastructure Assignment is is different when comparing v6 and v4 policies. It is currently being discussed to align both policies. Op 13-7-2009 15:04, Stream Service || Mark Scholten schreef: > Hello, > > We are looking on getting an IPv6 PI range. But we want to use it for the > same services we are running in the IPv4 world. Could you say if it is > allowed under IPv6 PI (some say yes, some say no and if you ask me it should > be: yes, of course it is allowed). > > The things we want to use IPv6 PI for: > - dedicated servers (servers are owned by us) > - co located servers (servers are owned by clients) > - VPN (we have a few clients that use it, per VPN client at least 1 IP) > - VPS guests (per VPS guest at least 1 IP) > - https (per host an IP) > > And if it is not allowed: what would happen if we do it and someone > discovers it. > > Thanks in advance for the answers. > > With kind regards, > > Mark Scholten > From remco.vanmook at eu.equinix.com Mon Jul 13 15:26:26 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Mon, 13 Jul 2009 15:26:26 +0200 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <00e201ca03ba$690cd710$3b268530$@nl> Message-ID: Dear Mark, Rule #1 of breaking the rules: don?t get caught. That said, if you do break the rules and get caught, the standard applies that you get tarred and feathered and have to sing a lullaby during the next RIPE plenary session. But seriously ? what kind of response were you expecting? Best, Remco On 13-07-09 15:04, "Stream Service || Mark Scholten" wrote: > Hello, > > We are looking on getting an IPv6 PI range. But we want to use it for the > same services we are running in the IPv4 world. Could you say if it is > allowed under IPv6 PI (some say yes, some say no and if you ask me it should > be: yes, of course it is allowed). > > The things we want to use IPv6 PI for: > - dedicated servers (servers are owned by us) > - co located servers (servers are owned by clients) > - VPN (we have a few clients that use it, per VPN client at least 1 IP) > - VPS guests (per VPS guest at least 1 IP) > - https (per host an IP) > > And if it is not allowed: what would happen if we do it and someone > discovers it. > > Thanks in advance for the answers. > > With kind regards, > > Mark Scholten > > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen at unfix.org Mon Jul 13 15:35:17 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 13 Jul 2009 15:35:17 +0200 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <00e201ca03ba$690cd710$3b268530$@nl> References: <009001c9ffec$ee6ceb10$cb46c130$@nl> <00e201ca03ba$690cd710$3b268530$@nl> Message-ID: <4A5B3815.5030303@spaghetti.zurich.ibm.com> Stream Service || Mark Scholten wrote: > Hello, > > We are looking on getting an IPv6 PI range. But we want to use it for the > same services we are running in the IPv4 world. Could you say if it is > allowed under IPv6 PI (some say yes, some say no and if you ask me it should > be: yes, of course it is allowed). > > The things we want to use IPv6 PI for: > - dedicated servers (servers are owned by us) > - co located servers (servers are owned by clients) > - VPN (we have a few clients that use it, per VPN client at least 1 IP) > - VPS guests (per VPS guest at least 1 IP) > - https (per host an IP) Thus exactly how much address space where you thinking for this? Don't forget the HD ratio of course. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From rhe at nosc.ja.net Mon Jul 13 15:47:08 2009 From: rhe at nosc.ja.net (Rob Evans) Date: Mon, 13 Jul 2009 14:47:08 +0100 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <00e201ca03ba$690cd710$3b268530$@nl> References: <009001c9ffec$ee6ceb10$cb46c130$@nl> <00e201ca03ba$690cd710$3b268530$@nl> Message-ID: <4A5B3ADC.7070809@nosc.ja.net> Hi, > We are looking on getting an IPv6 PI range. But we want to use it for the > same services we are running in the IPv4 world. Could you say if it is > allowed under IPv6 PI (some say yes, some say no and if you ask me it should > be: yes, of course it is allowed). Have you tried asking the RIPE resource analysts? Are you an LIR? Is there a reason you can't apply for your own PA /32 instead of getting a PI /48? Cheers, Rob -- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From mark at streamservice.nl Mon Jul 13 18:05:57 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Mon, 13 Jul 2009 18:05:57 +0200 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <4A5B3ADC.7070809@nosc.ja.net> References: <009001c9ffec$ee6ceb10$cb46c130$@nl> <00e201ca03ba$690cd710$3b268530$@nl> <4A5B3ADC.7070809@nosc.ja.net> Message-ID: <00fa01ca03d3$ceb01730$6c104590$@nl> Hello, We are not a LIR and currently there is also no plan at this moment to become a LIR in the near future. I mainly want to know if it is allowed, if it is not allowed we will not give clients IPv6 space and if they want it we forward them to also request an IPv6 PI range. With kind regards and thank for the fast answers, Mark Scholten -----Original Message----- From: Rob Evans [mailto:rhe at nosc.ja.net] Sent: maandag 13 juli 2009 15:47 To: Stream Service || Mark Scholten Cc: 'Address Policy Working Group' Subject: Re: [address-policy-wg] IPv6 PI Hi, > We are looking on getting an IPv6 PI range. But we want to use it for the > same services we are running in the IPv4 world. Could you say if it is > allowed under IPv6 PI (some say yes, some say no and if you ask me it should > be: yes, of course it is allowed). Have you tried asking the RIPE resource analysts? Are you an LIR? Is there a reason you can't apply for your own PA /32 instead of getting a PI /48? Cheers, Rob -- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From leo.vegoda at icann.org Mon Jul 13 18:24:34 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 13 Jul 2009 09:24:34 -0700 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <00fa01ca03d3$ceb01730$6c104590$@nl> Message-ID: On 13/07/2009 9:05, "Stream Service || Mark Scholten" wrote: > Hello, > > We are not a LIR and currently there is also no plan at this moment to > become a LIR in the near future. I mainly want to know if it is allowed, if > it is not allowed we will not give clients IPv6 space and if they want it we > forward them to also request an IPv6 PI range. The policy governing IPv6 PI assignments is published here: http://www.ripe.net/ripe/docs/ripe-472.html#_8._IPv6_Provider Other than not being an LIR, you need to demonstrate that you will be multi-homed and able to sign the contract. Regards, Leo From jwkckid1 at ix.netcom.com Mon Jul 13 23:32:40 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Mon, 13 Jul 2009 14:32:40 -0700 Subject: [address-policy-wg] IPv6 PI References: <009001c9ffec$ee6ceb10$cb46c130$@nl> <00e201ca03ba$690cd710$3b268530$@nl> <4A5B33CB.6060706@klaver.it> Message-ID: <4A5BA7F8.EDABCDF4@ix.netcom.com> Michiel and all, That seems terribly odd. Michiel Klaver wrote: > Dear Mark, > > We recently submitted PI request tickets to ripe for IPv4 and IPv6 with > excactly the same details. The IPv4 request got assigned, the IPv6 > rejected due to the difference in the policies regarding VPN connections > (internet access). > > ----- Original message ----- > > The PI IPv6 assignment cannot be further assigned to other organisations. > > http://www.ripe.net/ripe/docs/ripe-472.html#_8._IPv6_Provider > > > > The definition of what an Infrastructure Assignment is is different when comparing v6 and v4 policies. It is currently being discussed to align both policies. > > Op 13-7-2009 15:04, Stream Service || Mark Scholten schreef: > > Hello, > > > > We are looking on getting an IPv6 PI range. But we want to use it for the > > same services we are running in the IPv4 world. Could you say if it is > > allowed under IPv6 PI (some say yes, some say no and if you ask me it should > > be: yes, of course it is allowed). > > > > The things we want to use IPv6 PI for: > > - dedicated servers (servers are owned by us) > > - co located servers (servers are owned by clients) > > - VPN (we have a few clients that use it, per VPN client at least 1 IP) > > - VPS guests (per VPS guest at least 1 IP) > > - https (per host an IP) > > > > And if it is not allowed: what would happen if we do it and someone > > discovers it. > > > > Thanks in advance for the answers. > > > > With kind regards, > > > > Mark Scholten > > Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From mark at streamservice.nl Tue Jul 14 13:42:25 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Tue, 14 Jul 2009 13:42:25 +0200 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <4A5BA7F8.EDABCDF4@ix.netcom.com> References: <009001c9ffec$ee6ceb10$cb46c130$@nl> <00e201ca03ba$690cd710$3b268530$@nl> <4A5B33CB.6060706@klaver.it> <4A5BA7F8.EDABCDF4@ix.netcom.com> Message-ID: <011601ca0478$29209bf0$7b61d3d0$@nl> Hello, Are there people here that say that a small change of the current policy is a problem? The change would be that the list I did mention earlier is a valid reason to get a IPv6 PI range. If no one is saying that it is a problem at this moment to create a formal proposal to change it (or a new proposal based on the current one) I would like to create it the coming week. The target of the change will be to make it a little bit easier to get IPv6 PI for organizations, so more organizations could start offering their services on IPv6 (PA isn't enough for many organizations if they are not the LIR). With kind regards, Mark Scholten -----Original Message----- From: Jeffrey A. Williams [mailto:jwkckid1 at ix.netcom.com] Sent: maandag 13 juli 2009 23:33 To: michiel at klaver.it Cc: Stream Service || Mark Scholten; 'Address Policy Working Group' Subject: Re: [address-policy-wg] IPv6 PI Michiel and all, That seems terribly odd. Michiel Klaver wrote: > Dear Mark, > > We recently submitted PI request tickets to ripe for IPv4 and IPv6 with > excactly the same details. The IPv4 request got assigned, the IPv6 > rejected due to the difference in the policies regarding VPN connections > (internet access). > > ----- Original message ----- > > The PI IPv6 assignment cannot be further assigned to other organisations. > > http://www.ripe.net/ripe/docs/ripe-472.html#_8._IPv6_Provider > > > > The definition of what an Infrastructure Assignment is is different when comparing v6 and v4 policies. It is currently being discussed to align both policies. > > Op 13-7-2009 15:04, Stream Service || Mark Scholten schreef: > > Hello, > > > > We are looking on getting an IPv6 PI range. But we want to use it for the > > same services we are running in the IPv4 world. Could you say if it is > > allowed under IPv6 PI (some say yes, some say no and if you ask me it should > > be: yes, of course it is allowed). > > > > The things we want to use IPv6 PI for: > > - dedicated servers (servers are owned by us) > > - co located servers (servers are owned by clients) > > - VPN (we have a few clients that use it, per VPN client at least 1 IP) > > - VPS guests (per VPS guest at least 1 IP) > > - https (per host an IP) > > > > And if it is not allowed: what would happen if we do it and someone > > discovers it. > > > > Thanks in advance for the answers. > > > > With kind regards, > > > > Mark Scholten > > Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From jeroen at unfix.org Tue Jul 14 14:36:13 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 14 Jul 2009 14:36:13 +0200 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <011601ca0478$29209bf0$7b61d3d0$@nl> References: <009001c9ffec$ee6ceb10$cb46c130$@nl> <00e201ca03ba$690cd710$3b268530$@nl> <4A5B33CB.6060706@klaver.it> <4A5BA7F8.EDABCDF4@ix.netcom.com> <011601ca0478$29209bf0$7b61d3d0$@nl> Message-ID: <4A5C7BBD.4030208@spaghetti.zurich.ibm.com> Stream Service || Mark Scholten wrote: > Hello, > > Are there people here that say that a small change of the current policy is > a problem? There are always people who will say that change is a problem. > The change would be that the list I did mention earlier is a > valid reason to get a IPv6 PI range. You gave a "list", quoting back from that email: > - dedicated servers (servers are owned by us) > - co located servers (servers are owned by clients) > - VPN (we have a few clients that use it, per VPN client at least 1) > - VPS guests (per VPS guest at least 1 IP) > - https (per host an IP) How many addresses and prefixes are you talking about? How is routing arranged for these, are the in different ASNs etc? I don't see how that "list" would suddenly make you qualify for "PI" especially as there are no details at all, just that you have some hosts somewhere. "HTTPS" seems to always be a great target for claiming you need an extra IP address, but why can't you host that in PA space? DNS can be updated quite easily and voila host moved. > If no one is saying that it is a problem at this moment to create a formal > proposal to change it (or a new proposal based on the current one) I would > like to create it the coming week. The target of the change will be to make > it a little bit easier to get IPv6 PI for organizations, so more > organizations could start offering their services on IPv6 (PA isn't enough > for many organizations if they are not the LIR). And why and how don't they qualify for the current IPv6-PI rules? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From marcoh at marcoh.net Tue Jul 14 14:37:39 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 14 Jul 2009 14:37:39 +0200 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <011601ca0478$29209bf0$7b61d3d0$@nl> References: <009001c9ffec$ee6ceb10$cb46c130$@nl> <00e201ca03ba$690cd710$3b268530$@nl> <4A5B33CB.6060706@klaver.it> <4A5BA7F8.EDABCDF4@ix.netcom.com> <011601ca0478$29209bf0$7b61d3d0$@nl> Message-ID: <69AB6CE8-4504-4406-B73C-C08F0E1C7427@marcoh.net> On Jul 14, 2009, at 1:42 PM, Stream Service || Mark Scholten wrote: > Hello, > > Are there people here that say that a small change of the current > policy is > a problem? The change would be that the list I did mention earlier > is a > valid reason to get a IPv6 PI range. > > If no one is saying that it is a problem at this moment to create a > formal > proposal to change it (or a new proposal based on the current one) I > would > like to create it the coming week. The target of the change will be > to make > it a little bit easier to get IPv6 PI for organizations, so more > organizations could start offering their services on IPv6 (PA isn't > enough > for many organizations if they are not the LIR). > > With kind regards, > > Mark Scholten What change are you thinking of ? If it goes in the direction to allow sub-assingment (in any way shape or form) from within a PI block I wouldn't support it. And to answer your question, I guess that there will always be some objection to change...it's in people's nature. MarcoH From mark at streamservice.nl Tue Jul 14 15:33:34 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Tue, 14 Jul 2009 15:33:34 +0200 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <69AB6CE8-4504-4406-B73C-C08F0E1C7427@marcoh.net> References: <009001c9ffec$ee6ceb10$cb46c130$@nl> <00e201ca03ba$690cd710$3b268530$@nl> <4A5B33CB.6060706@klaver.it> <4A5BA7F8.EDABCDF4@ix.netcom.com> <011601ca0478$29209bf0$7b61d3d0$@nl> <69AB6CE8-4504-4406-B73C-C08F0E1C7427@marcoh.net> Message-ID: <012c01ca0487$afe46f40$0fad4dc0$@nl> I was thinking to change it that way that is will allow (in the policy) that this are also valid claims to get a IPv6 PI range and when you need an extra range you will be able to get it when you meet the earlier mentioned ratio. De-aggregation is not something that I would add (if not yet specified in the current policy). Sub allocations to clients without changing it in the RIPE database should be possible if you ask me. This way it would be possible (if you follow the policy) that it can be used for small sub-assignments to co location and/or VPN users (please note it wouldn't be registered in the RIPE database, it is the same as some current IPv4 networks use IPv4 PI address space). Some networks aren't currently a LIR, so they can't get an IPv6 PA range (if I am correct) and with this change in policy it should reduce the number of IPv6 PI request (else we would need to request a IPv6 PI range per VPN connection and/or per co location client). Regards, Mark -----Original Message----- From: Marco Hogewoning [mailto:marcoh at marcoh.net] Sent: dinsdag 14 juli 2009 14:38 To: Stream Service || Mark Scholten Cc: 'Address Policy Working Group' Subject: Re: [address-policy-wg] IPv6 PI On Jul 14, 2009, at 1:42 PM, Stream Service || Mark Scholten wrote: > Hello, > > Are there people here that say that a small change of the current > policy is > a problem? The change would be that the list I did mention earlier > is a > valid reason to get a IPv6 PI range. > > If no one is saying that it is a problem at this moment to create a > formal > proposal to change it (or a new proposal based on the current one) I > would > like to create it the coming week. The target of the change will be > to make > it a little bit easier to get IPv6 PI for organizations, so more > organizations could start offering their services on IPv6 (PA isn't > enough > for many organizations if they are not the LIR). > > With kind regards, > > Mark Scholten What change are you thinking of ? If it goes in the direction to allow sub-assingment (in any way shape or form) from within a PI block I wouldn't support it. And to answer your question, I guess that there will always be some objection to change...it's in people's nature. MarcoH From mark at streamservice.nl Tue Jul 14 15:54:44 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Tue, 14 Jul 2009 15:54:44 +0200 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <4A5C7BBD.4030208@spaghetti.zurich.ibm.com> References: <009001c9ffec$ee6ceb10$cb46c130$@nl> <00e201ca03ba$690cd710$3b268530$@nl> <4A5B33CB.6060706@klaver.it> <4A5BA7F8.EDABCDF4@ix.netcom.com> <011601ca0478$29209bf0$7b61d3d0$@nl> <4A5C7BBD.4030208@spaghetti.zurich.ibm.com> Message-ID: <012d01ca048a$a4f9c230$eeed4690$@nl> It shouldn't be the only reason to get IPv6 PI, it should be combined with a different routing policy or the usage ratio should be high enough to get another IPv6 PI range (unlikely in most cases). HTTPS - 1 IP per SSL certificate should be enough (and with IPv6 you get many IPs with a /48). Sometimes PA isn't enough (for example someone uses uplinks from 2 networks to create their own network but isn't a LIR). It may also be because changing it in the future is not nice (read: if you have many servers with different configurations an IP change makes changing networks almost impossible!). It is (or was) possible to get IPv4 PI with (almost) the same argumentation and to move those organizations to IPv6 it might be required to offer it in the IPv6 PI policy. Just changing DNS is with advanced configurations never enough to change a host. Also when servers have to be moved DNS is normally not fast enough with changing (because many DNS resolvers don't follow the TTL you did set). I didn't say they don't qualify in the current policy. I asked IF they qualify yet or not. This is because some people say yes they qualify and some others say they don't qualify. Some people say that it is not allowed to use a single IP for a VPN you or client uses and others say feel free to use 65k IPv6 addresses for that. Some people say it is not allowed to offer co location clients (they have the same routing policy) 2 IPv6 addresses if you only have IPv6 PI and others say give them 65k IPv6 addresses per server or per client. Because of the many times we moved between networks in the past we always prefer PI above PA. With IPv6 it is even more important to not change IP addresses (because of the many IP addresses you will probably use after sometime). Regards, Mark -----Original Message----- From: Jeroen Massar [mailto:jeroen at unfix.org] Sent: dinsdag 14 juli 2009 14:36 To: Stream Service || Mark Scholten Cc: 'Address Policy Working Group' Subject: Re: [address-policy-wg] IPv6 PI Stream Service || Mark Scholten wrote: > Hello, > > Are there people here that say that a small change of the current > policy is a problem? There are always people who will say that change is a problem. > The change would be that the list I did mention earlier is a valid > reason to get a IPv6 PI range. You gave a "list", quoting back from that email: > - dedicated servers (servers are owned by us) > - co located servers (servers are owned by clients) > - VPN (we have a few clients that use it, per VPN client at least 1) > - VPS guests (per VPS guest at least 1 IP) > - https (per host an IP) How many addresses and prefixes are you talking about? How is routing arranged for these, are the in different ASNs etc? I don't see how that "list" would suddenly make you qualify for "PI" especially as there are no details at all, just that you have some hosts somewhere. "HTTPS" seems to always be a great target for claiming you need an extra IP address, but why can't you host that in PA space? DNS can be updated quite easily and voila host moved. > If no one is saying that it is a problem at this moment to create a > formal proposal to change it (or a new proposal based on the current > one) I would like to create it the coming week. The target of the > change will be to make it a little bit easier to get IPv6 PI for > organizations, so more organizations could start offering their > services on IPv6 (PA isn't enough for many organizations if they are not the LIR). And why and how don't they qualify for the current IPv6-PI rules? Greets, Jeroen From Niall.oReilly at ucd.ie Wed Jul 15 11:45:47 2009 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 15 Jul 2009 10:45:47 +0100 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <012d01ca048a$a4f9c230$eeed4690$@nl> References: <009001c9ffec$ee6ceb10$cb46c130$@nl> <00e201ca03ba$690cd710$3b268530$@nl> <4A5B33CB.6060706@klaver.it> <4A5BA7F8.EDABCDF4@ix.netcom.com> <011601ca0478$29209bf0$7b61d3d0$@nl> <4A5C7BBD.4030208@spaghetti.zurich.ibm.com> <012d01ca048a$a4f9c230$eeed4690$@nl> Message-ID: <4A5DA54B.6050105@ucd.ie> Stream Service || Mark Scholten wrote: > I didn't say they don't qualify in the current policy. I asked IF they > qualify yet or not. This is because some people say yes they qualify and > some others say they don't qualify. IM[...]HO, as long as this uncertainty exists, which is an uncertainty as to whether there is a problem, it will be impossible to make a convincing case for a policy proposal, for the simple reason that any such proposal would not address a known problem. You say that "some people say" one thing or another. You can test what the current policy allows by making a request through your chosen LIR to the RIPE NCC. Then, when you have an answer and (in case of refusal) an explanation, you'll be in a position to state any problem that you believe exists. IHTH VBR, mvg, etc, Niall O'Reilly From jeroen at easyhosting.nl Wed Jul 15 14:02:10 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Wed, 15 Jul 2009 14:02:10 +0200 Subject: [address-policy-wg] Complaint: Overly complicated when requesting PI space Message-ID: <4A5DC542.4050908@easyhosting.nl> Hello Members, I'd like to state a complaint toward overly complicated issues with requesting PI space as a LIR for a customer. Situation: I have a customer who's purchased a router and wants his own IP space+AS number to start multihoming. Since he's pretty new to routing and policies of RIPE and managing the database to keep things going, we as LIR offered him to do this for him at the startup phase. Currently he'll be hosting several services from within our PA ranges and will start growing his new resources in the PI space he wants. After filling in the request forms, his AS got approved pending the PI /24 range assignment. And that's been a process that's currently becoming something ridiculous. Initially I got some return questions on how the subnets would be sliced up, what would be used for management of the routers, if IP's are being assigned statically or dynamically, how much IP's a customer would use and if PA space is being returned. Questions (except for the 'how much IP's will a customer use') I can understand and all answered. Then in a follow-up I got asked what the montly growth is, who's administratively responsible for the IP's and how they're going to be used on the servers. Then in a next follow up I got pointed to using PA space either from us or a different provider or that the customer should become LIR himself since we as LIR cannot sub-allocate PI space. (something that's not intended in the first place at all, we just administer it on a contract base until he understands procedures) And then after explaining that we will only help the customer on contract base and not sub-allocate anything, another follow-up comes that no customer can use more then 1 or 2 IP's and once again a question on how many servers are involved here. And that's where I'm at now. I've been trying to request PI space for our customer since last friday, and in my opinion there's too much meddling into internal business by RIPE here and this is taking a ridiculous amount of time and communication. As a LIR we hand out IP space responsibly to our customers, for a good technical and administrative reason we have a customer who wants his own PI assignment and I'm asking him questions about his business that lean towards a company secret. In my opinion RIPE has absolutely no business in asking how many customers and/or servers someone has and stating that a customer can not use >2 IP's in that PI space (what if someone has *gasp* 3 SSL websites ?, I cannot imagine that happening.., ever). Also neither we or our customer has a crystal ball to see in the future, so sure I can tell the amount of customer growth I'll be expecting or HOPING to see, but come on. I know IPv4 space must be handed out responsibly, but this is seriously going too far, especially for a LIR. Supposedly I cannot give a routing-reason for requesting PI space, but part of that IS important on why I'm requesting it. It's really not desirable for us AND for my customer to chop out a part of my PA space and announce in smaller chunks from his own AS on the same exchange points we're on and this customer is NOT at the stage yet to become a full LIR himself. -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From Woeber at CC.UniVie.ac.at Wed Jul 15 14:45:32 2009 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 15 Jul 2009 12:45:32 +0000 Subject: [address-policy-wg] IPv6 PI In-Reply-To: <012d01ca048a$a4f9c230$eeed4690$@nl> References: <009001c9ffec$ee6ceb10$cb46c130$@nl> <00e201ca03ba$690cd710$3b268530$@nl> <4A5B33CB.6060706@klaver.it> <4A5BA7F8.EDABCDF4@ix.netcom.com> <011601ca0478$29209bf0$7b61d3d0$@nl> <4A5C7BBD.4030208@spaghetti.zurich.ibm.com> <012d01ca048a$a4f9c230$eeed4690$@nl> Message-ID: <4A5DCF6C.9050301@CC.UniVie.ac.at> Mark, could you remind me of the reasons why you (think you) cannot (or do not want to) play along with "everyone else" and become an LIR to get your own PA space? Looking at the recently distributed draft charging scheme for 2010 the financial aspects should not be that different (unless you find some LIR that offers you a free ride :-) for getting PI assigned, for whatever reason). Wilfried Stream Service || Mark Scholten wrote: > It shouldn't be the only reason to get IPv6 PI, it should be combined with a > different routing policy or the usage ratio should be high enough to get > another IPv6 PI range (unlikely in most cases). > > HTTPS - 1 IP per SSL certificate should be enough (and with IPv6 you get > many IPs with a /48). > > Sometimes PA isn't enough (for example someone uses uplinks from 2 networks > to create their own network but isn't a LIR). It may also be because > changing it in the future is not nice (read: if you have many servers with > different configurations an IP change makes changing networks almost > impossible!). It is (or was) possible to get IPv4 PI with (almost) the same > argumentation and to move those organizations to IPv6 it might be required > to offer it in the IPv6 PI policy. > > Just changing DNS is with advanced configurations never enough to change a > host. Also when servers have to be moved DNS is normally not fast enough > with changing (because many DNS resolvers don't follow the TTL you did set). > > I didn't say they don't qualify in the current policy. I asked IF they > qualify yet or not. This is because some people say yes they qualify and > some others say they don't qualify. > > Some people say that it is not allowed to use a single IP for a VPN you or > client uses and others say feel free to use 65k IPv6 addresses for that. > Some people say it is not allowed to offer co location clients (they have > the same routing policy) 2 IPv6 addresses if you only have IPv6 PI and > others say give them 65k IPv6 addresses per server or per client. > > Because of the many times we moved between networks in the past we always > prefer PI above PA. With IPv6 it is even more important to not change IP > addresses (because of the many IP addresses you will probably use after > sometime). > > Regards, Mark > > -----Original Message----- > From: Jeroen Massar [mailto:jeroen at unfix.org] > Sent: dinsdag 14 juli 2009 14:36 > To: Stream Service || Mark Scholten > Cc: 'Address Policy Working Group' > Subject: Re: [address-policy-wg] IPv6 PI > > Stream Service || Mark Scholten wrote: > >>Hello, >> >>Are there people here that say that a small change of the current >>policy is a problem? > > > There are always people who will say that change is a problem. > > >>The change would be that the list I did mention earlier is a valid >>reason to get a IPv6 PI range. > > > You gave a "list", quoting back from that email: > > >>- dedicated servers (servers are owned by us) >>- co located servers (servers are owned by clients) >>- VPN (we have a few clients that use it, per VPN client at least 1) >>- VPS guests (per VPS guest at least 1 IP) >>- https (per host an IP) > > > How many addresses and prefixes are you talking about? How is routing > arranged for these, are the in different ASNs etc? > > I don't see how that "list" would suddenly make you qualify for "PI" > especially as there are no details at all, just that you have some hosts > somewhere. > > "HTTPS" seems to always be a great target for claiming you need an extra IP > address, but why can't you host that in PA space? DNS can be updated quite > easily and voila host moved. > > >>If no one is saying that it is a problem at this moment to create a >>formal proposal to change it (or a new proposal based on the current >>one) I would like to create it the coming week. The target of the >>change will be to make it a little bit easier to get IPv6 PI for >>organizations, so more organizations could start offering their >>services on IPv6 (PA isn't enough for many organizations if they are not > > the LIR). > > And why and how don't they qualify for the current IPv6-PI rules? > > Greets, > Jeroen > > > From Woeber at CC.UniVie.ac.at Wed Jul 15 15:03:48 2009 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 15 Jul 2009 13:03:48 +0000 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <4A5DC542.4050908@easyhosting.nl> References: <4A5DC542.4050908@easyhosting.nl> Message-ID: <4A5DD3B4.8020804@CC.UniVie.ac.at> Hi Jeroen, 2 quick comments: regarding the supposedly irresponsible questions and - how I read between your lines, thus I may be wrong! - your feeling or impression of limited technical expertise of the hostmaster involved; I'd suggest that you try to escalate the ticket up the tree within the NCC. 2ndly, my feeling is that it would be more straightforward (and easier to live within the procedures) to have your customer establish its own LIR from the very beginning, with your team supplying the expertise and help to do so. I myself are in the game of cleaning up some PI stuff, within the new policy, and to get those resources moved to the LIRs which have been established in the meantime. My 2 centavos, Wilfried Jeroen Wunnink wrote: > Hello Members, > > I'd like to state a complaint toward overly complicated issues with > requesting PI space as a LIR for a customer. > > Situation: I have a customer who's purchased a router and wants his own > IP space+AS number to start multihoming. Since he's pretty new to > routing and policies of RIPE and managing the database to keep things > going, we as LIR offered him to do this for him at the startup phase. > Currently he'll be hosting several services from within our PA ranges > and will start growing his new resources in the PI space he wants. > > After filling in the request forms, his AS got approved pending the PI > /24 range assignment. And that's been a process that's currently > becoming something ridiculous. > > Initially I got some return questions on how the subnets would be sliced > up, what would be used for management of the routers, if IP's are being > assigned statically or dynamically, how much IP's a customer would use > and if PA space is being returned. Questions (except for the 'how much > IP's will a customer use') I can understand and all answered. > > Then in a follow-up I got asked what the montly growth is, who's > administratively responsible for the IP's and how they're going to be > used on the servers. > > Then in a next follow up I got pointed to using PA space either from us > or a different provider or that the customer should become LIR himself > since we as LIR cannot sub-allocate PI space. (something that's not > intended in the first place at all, we just administer it on a contract > base until he understands procedures) > > And then after explaining that we will only help the customer on > contract base and not sub-allocate anything, another follow-up comes > that no customer can use more then 1 or 2 IP's and once again a question > on how many servers are involved here. > > And that's where I'm at now. I've been trying to request PI space for > our customer since last friday, and in my opinion there's too much > meddling into internal business by RIPE here and this is taking a > ridiculous amount of time and communication. > > As a LIR we hand out IP space responsibly to our customers, for a good > technical and administrative reason we have a customer who wants his own > PI assignment and I'm asking him questions about his business that lean > towards a company secret. In my opinion RIPE has absolutely no business > in asking how many customers and/or servers someone has and stating that > a customer can not use >2 IP's in that PI space (what if someone has > *gasp* 3 SSL websites ?, I cannot imagine that happening.., ever). > > Also neither we or our customer has a crystal ball to see in the future, > so sure I can tell the amount of customer growth I'll be expecting or > HOPING to see, but come on. > > I know IPv4 space must be handed out responsibly, but this is seriously > going too far, especially for a LIR. Supposedly I cannot give a > routing-reason for requesting PI space, but part of that IS important on > why I'm requesting it. It's really not desirable for us AND for my > customer to chop out a part of my PA space and announce in smaller > chunks from his own AS on the same exchange points we're on and this > customer is NOT at the stage yet to become a full LIR himself. > > From jeroen at easyhosting.nl Wed Jul 15 15:18:15 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Wed, 15 Jul 2009 15:18:15 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <4A5DD3B4.8020804@CC.UniVie.ac.at> References: <4A5DC542.4050908@easyhosting.nl> <4A5DD3B4.8020804@CC.UniVie.ac.at> Message-ID: <4A5DD717.9060109@easyhosting.nl> Hi Wilfried, No it's not intended to be an impression of limited technical expertise of the hostmaster, nor any other personal grudge against him. I know he's following policy on how address space needs to be handed out and he's doing his job on that, and that's where my problem seems to be, the overly harsh policy for PI allocations. I've upped this question to some other Dutch network operators/LIR's and it seems we're not alone in this issue and that it's overly hard and difficult to request PI resources. Yes of course he can become a LIR, but that's a lot more expensive for him. Our customer is trying to start his own network and if he can start doing some of the routing himself. Using a PI based IP and AS for that is more desirable then becoming a full blown LIR at this point. If his routing attempt turns out on nothing we can return the AS and PI or route the PI space for him through our equipment. Wilfried Woeber, UniVie/ACOnet wrote: > Hi Jeroen, > > 2 quick comments: regarding the supposedly irresponsible questions > and - how I read between your lines, thus I may be wrong! - your feeling > or impression of limited technical expertise of the hostmaster involved; > I'd suggest that you try to escalate the ticket up the tree within the NCC. > > 2ndly, my feeling is that it would be more straightforward (and easier to > live within the procedures) to have your customer establish its own LIR from > the very beginning, with your team supplying the expertise and help to do so. > > I myself are in the game of cleaning up some PI stuff, within the new policy, > and to get those resources moved to the LIRs which have been established in > the meantime. > > My 2 centavos, > Wilfried > > Jeroen Wunnink wrote: > > >> Hello Members, >> >> I'd like to state a complaint toward overly complicated issues with >> requesting PI space as a LIR for a customer. >> >> Situation: I have a customer who's purchased a router and wants his own >> IP space+AS number to start multihoming. Since he's pretty new to >> routing and policies of RIPE and managing the database to keep things >> going, we as LIR offered him to do this for him at the startup phase. >> Currently he'll be hosting several services from within our PA ranges >> and will start growing his new resources in the PI space he wants. >> >> After filling in the request forms, his AS got approved pending the PI >> /24 range assignment. And that's been a process that's currently >> becoming something ridiculous. >> >> Initially I got some return questions on how the subnets would be sliced >> up, what would be used for management of the routers, if IP's are being >> assigned statically or dynamically, how much IP's a customer would use >> and if PA space is being returned. Questions (except for the 'how much >> IP's will a customer use') I can understand and all answered. >> >> Then in a follow-up I got asked what the montly growth is, who's >> administratively responsible for the IP's and how they're going to be >> used on the servers. >> >> Then in a next follow up I got pointed to using PA space either from us >> or a different provider or that the customer should become LIR himself >> since we as LIR cannot sub-allocate PI space. (something that's not >> intended in the first place at all, we just administer it on a contract >> base until he understands procedures) >> >> And then after explaining that we will only help the customer on >> contract base and not sub-allocate anything, another follow-up comes >> that no customer can use more then 1 or 2 IP's and once again a question >> on how many servers are involved here. >> >> And that's where I'm at now. I've been trying to request PI space for >> our customer since last friday, and in my opinion there's too much >> meddling into internal business by RIPE here and this is taking a >> ridiculous amount of time and communication. >> >> As a LIR we hand out IP space responsibly to our customers, for a good >> technical and administrative reason we have a customer who wants his own >> PI assignment and I'm asking him questions about his business that lean >> towards a company secret. In my opinion RIPE has absolutely no business >> in asking how many customers and/or servers someone has and stating that >> a customer can not use >2 IP's in that PI space (what if someone has >> *gasp* 3 SSL websites ?, I cannot imagine that happening.., ever). >> >> Also neither we or our customer has a crystal ball to see in the future, >> so sure I can tell the amount of customer growth I'll be expecting or >> HOPING to see, but come on. >> >> I know IPv4 space must be handed out responsibly, but this is seriously >> going too far, especially for a LIR. Supposedly I cannot give a >> routing-reason for requesting PI space, but part of that IS important on >> why I'm requesting it. It's really not desirable for us AND for my >> customer to chop out a part of my PA space and announce in smaller >> chunks from his own AS on the same exchange points we're on and this >> customer is NOT at the stage yet to become a full LIR himself. >> >> >> > > -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From jeroen at unfix.org Wed Jul 15 16:00:42 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 15 Jul 2009 16:00:42 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <4A5DD717.9060109@easyhosting.nl> References: <4A5DC542.4050908@easyhosting.nl> <4A5DD3B4.8020804@CC.UniVie.ac.at> <4A5DD717.9060109@easyhosting.nl> Message-ID: <4A5DE10A.2080300@spaghetti.zurich.ibm.com> Jeroen Wunnink wrote: [..] > Yes of course he can become a LIR, but that's a lot more expensive for > him. Our customer is trying to start his own network and if he can start > doing some of the routing himself. http://www.ripe.net/membership/billing/procedure.html Extra Small: 1300 EUR / year So, he is able to buy routing kit, hookups to IXs,, tansit and those things, but a LIR fee of 1300 EUR is too much? :) Drink a few less beers every week and you have that together. Sorry to say, but thinking of it from an ops perspective I do hope that this customer also has a correctly working abuse desk and people who are monitoring this network gear. (which means they have to caugh up for people and other resources there too which far exceeds those little fees). Because if they don't they are just another nuisance on the Internet.... (not that money should stop people from being able to use it mind you) Greets, Jeroen (okay, another 2k signup... but what is the deal, you can barely buy 1 proper 1U box for that total amount) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From fweimer at bfk.de Wed Jul 15 16:21:37 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 15 Jul 2009 14:21:37 +0000 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <4A5DD717.9060109@easyhosting.nl> (Jeroen Wunnink's message of "Wed\, 15 Jul 2009 15\:18\:15 +0200") References: <4A5DC542.4050908@easyhosting.nl> <4A5DD3B4.8020804@CC.UniVie.ac.at> <4A5DD717.9060109@easyhosting.nl> Message-ID: <8263duc9hq.fsf@mid.bfk.de> * Jeroen Wunnink: > Yes of course he can become a LIR, but that's a lot more expensive for > him. How does that change anything? For PA space, he'd have to demonstrate a need for a /21, not just for a /24, which is more difficult. I used to think that you'd get your initial assignment with basically no questions asked because you can't run an ISP without addresses and it's difficult to predict address space requirements without any experience, but this isn't the case. Of course, the net effect is that RIPE receives rather optimistic business plans because new LIRs need to somehow fullfil the minimum size requirements posed by RIPE NCC, or your LIR status is totally pointless. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From ncc at ripe.net Wed Jul 15 16:19:29 2009 From: ncc at ripe.net (Paul Rendek) Date: Wed, 15 Jul 2009 16:19:29 +0200 Subject: [address-policy-wg] IPv6 Deployment Monitoring Survey Closed Message-ID: <5662A7F6-AFA0-4C56-B735-64AED90FA043@ripe.net> [Apologies for duplicates] Dear Colleagues, The IPv6 Deployment Monitoring Survey, conducted by TNO and GNKS Consult in cooperation with the RIPE NCC and sponsored by the European Commission, has now closed. More than 600 members of the RIPE community responded to the survey, which aims to collect data on the current and future use of IPv6 throughout the RIPE NCC service region. We wish to thank those from the community who took the time to complete the survey. The results of the IPv6 Deployment Monitoring Survey will be presented and discussed at RIPE 59 which takes place in Lisbon, Portugal from 5-9 October. More information and registration details are available at: http://ripe59.ripe.net/ The results of this survey will also be published on IPv6 Act Now website at: http://www.ipv6actnow.org If you have any questions about the survey or the results, please contact . Regards, Paul Rendek Head of External Relations and Communications RIPE NCC From gert at space.net Wed Jul 15 16:40:14 2009 From: gert at space.net (Gert Doering) Date: Wed, 15 Jul 2009 16:40:14 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <8263duc9hq.fsf@mid.bfk.de> References: <4A5DC542.4050908@easyhosting.nl> <4A5DD3B4.8020804@CC.UniVie.ac.at> <4A5DD717.9060109@easyhosting.nl> <8263duc9hq.fsf@mid.bfk.de> Message-ID: <20090715144014.GS26102@Space.Net> Hi, On Wed, Jul 15, 2009 at 02:21:37PM +0000, Florian Weimer wrote: > * Jeroen Wunnink: > > > Yes of course he can become a LIR, but that's a lot more expensive for > > him. > > How does that change anything? For PA space, he'd have to demonstrate > a need for a /21, not just for a /24, which is more difficult. As a LIR, to receive PA space, all you need to document is the wish to assign addresses to your customers (or to your infrastructure). "Demonstrate need for the whole initial PA allocation" is a thing we had in the policy for a while, but got rid of that about 5 years ago (because all it did was "make startup ISPs go for multiple PI instead"). Please do not post outdated policy information. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From fweimer at bfk.de Wed Jul 15 17:15:40 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 15 Jul 2009 15:15:40 +0000 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <20090715144014.GS26102@Space.Net> (Gert Doering's message of "Wed\, 15 Jul 2009 16\:40\:14 +0200") References: <4A5DC542.4050908@easyhosting.nl> <4A5DD3B4.8020804@CC.UniVie.ac.at> <4A5DD717.9060109@easyhosting.nl> <8263duc9hq.fsf@mid.bfk.de> <20090715144014.GS26102@Space.Net> Message-ID: <82y6qqasf7.fsf@mid.bfk.de> * Gert Doering: > As a LIR, to receive PA space, all you need to document is the wish to > assign addresses to your customers (or to your infrastructure). > > "Demonstrate need for the whole initial PA allocation" is a thing we had > in the policy for a while, but got rid of that about 5 years ago (because > all it did was "make startup ISPs go for multiple PI instead"). > > Please do not post outdated policy information. Gert, perhaps it will surprise you, but we've turned LIR only very recently. 8-) My comment wasn't about policy, but about policy as implemented by RIPE NCC. I was as surprised as you apparently are---the information available to us before gaining LIR status and requesting initial assignment did not document any minimum size requirement or growth expectations for LIRs. (Thanks for confirming that, by the way.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From laura at ripe.net Wed Jul 15 17:57:40 2009 From: laura at ripe.net (Laura Cobley) Date: Wed, 15 Jul 2009 17:57:40 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <4A5DC542.4050908@easyhosting.nl> References: <4A5DC542.4050908@easyhosting.nl> Message-ID: <4A5DFC74.4030504@ripe.net> Dear Jeroen, Florian and all, The RIPE NCC has an internal escalation procedure for handling concerns about the way your request has been handled. You can ask for any request to be escalated by sending an email to hostmaster at ripe.net and quoting the relevant NCC# ticket number. Your request will then be reviewed and assessed by senior staff. If your concern is of a more serious nature, please refer to the RIPE NCC's Conflict Arbitration Procedure available online at: http://www.ripe.net/ripe/docs/arbitration.html Regards, Laura Cobley RIPE NCC Registration Services Jeroen Wunnink wrote: > Hello Members, > > I'd like to state a complaint toward overly complicated issues with > requesting PI space as a LIR for a customer. > > Situation: I have a customer who's purchased a router and wants his own > IP space+AS number to start multihoming. Since he's pretty new to > routing and policies of RIPE and managing the database to keep things > going, we as LIR offered him to do this for him at the startup phase. > Currently he'll be hosting several services from within our PA ranges > and will start growing his new resources in the PI space he wants. > > After filling in the request forms, his AS got approved pending the PI > /24 range assignment. And that's been a process that's currently > becoming something ridiculous. > > Initially I got some return questions on how the subnets would be sliced > up, what would be used for management of the routers, if IP's are being > assigned statically or dynamically, how much IP's a customer would use > and if PA space is being returned. Questions (except for the 'how much > IP's will a customer use') I can understand and all answered. > > Then in a follow-up I got asked what the montly growth is, who's > administratively responsible for the IP's and how they're going to be > used on the servers. > > Then in a next follow up I got pointed to using PA space either from us > or a different provider or that the customer should become LIR himself > since we as LIR cannot sub-allocate PI space. (something that's not > intended in the first place at all, we just administer it on a contract > base until he understands procedures) > > And then after explaining that we will only help the customer on > contract base and not sub-allocate anything, another follow-up comes > that no customer can use more then 1 or 2 IP's and once again a question > on how many servers are involved here. > > And that's where I'm at now. I've been trying to request PI space for > our customer since last friday, and in my opinion there's too much > meddling into internal business by RIPE here and this is taking a > ridiculous amount of time and communication. > > As a LIR we hand out IP space responsibly to our customers, for a good > technical and administrative reason we have a customer who wants his own > PI assignment and I'm asking him questions about his business that lean > towards a company secret. In my opinion RIPE has absolutely no business > in asking how many customers and/or servers someone has and stating that > a customer can not use >2 IP's in that PI space (what if someone has > *gasp* 3 SSL websites ?, I cannot imagine that happening.., ever). > > Also neither we or our customer has a crystal ball to see in the future, > so sure I can tell the amount of customer growth I'll be expecting or > HOPING to see, but come on. > > I know IPv4 space must be handed out responsibly, but this is seriously > going too far, especially for a LIR. Supposedly I cannot give a > routing-reason for requesting PI space, but part of that IS important on > why I'm requesting it. It's really not desirable for us AND for my > customer to chop out a part of my PA space and announce in smaller > chunks from his own AS on the same exchange points we're on and this > customer is NOT at the stage yet to become a full LIR himself. > > From president at ukraine.su Wed Jul 15 19:54:25 2009 From: president at ukraine.su (Max Tulyev) Date: Wed, 15 Jul 2009 20:54:25 +0300 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <4A5DC542.4050908@easyhosting.nl> References: <4A5DC542.4050908@easyhosting.nl> Message-ID: <4A5E17D1.9010406@ukraine.su> Hello Jeroen, I see questions from NCC hostmaster you said were correct and adequate to the policy. I can understand why each question you said was asked. If you have no experience in PI/AS delegation, you can ask companies (like we are ;) ) specializing on this topic, and they can prepare the good request and deal with hostmasters' bueracracy. The only question is why they approve the AS request before PI one. Did you list your PA space in the AS request in prefix: field? Jeroen Wunnink wrote: > Hello Members, > > I'd like to state a complaint toward overly complicated issues with > requesting PI space as a LIR for a customer. > > Situation: I have a customer who's purchased a router and wants his own > IP space+AS number to start multihoming. Since he's pretty new to > routing and policies of RIPE and managing the database to keep things > going, we as LIR offered him to do this for him at the startup phase. > Currently he'll be hosting several services from within our PA ranges > and will start growing his new resources in the PI space he wants. > > After filling in the request forms, his AS got approved pending the PI > /24 range assignment. And that's been a process that's currently > becoming something ridiculous. > > Initially I got some return questions on how the subnets would be sliced > up, what would be used for management of the routers, if IP's are being > assigned statically or dynamically, how much IP's a customer would use > and if PA space is being returned. Questions (except for the 'how much > IP's will a customer use') I can understand and all answered. > > Then in a follow-up I got asked what the montly growth is, who's > administratively responsible for the IP's and how they're going to be > used on the servers. > > Then in a next follow up I got pointed to using PA space either from us > or a different provider or that the customer should become LIR himself > since we as LIR cannot sub-allocate PI space. (something that's not > intended in the first place at all, we just administer it on a contract > base until he understands procedures) > > And then after explaining that we will only help the customer on > contract base and not sub-allocate anything, another follow-up comes > that no customer can use more then 1 or 2 IP's and once again a question > on how many servers are involved here. > > And that's where I'm at now. I've been trying to request PI space for > our customer since last friday, and in my opinion there's too much > meddling into internal business by RIPE here and this is taking a > ridiculous amount of time and communication. > > As a LIR we hand out IP space responsibly to our customers, for a good > technical and administrative reason we have a customer who wants his own > PI assignment and I'm asking him questions about his business that lean > towards a company secret. In my opinion RIPE has absolutely no business > in asking how many customers and/or servers someone has and stating that > a customer can not use >2 IP's in that PI space (what if someone has > *gasp* 3 SSL websites ?, I cannot imagine that happening.., ever). > > Also neither we or our customer has a crystal ball to see in the future, > so sure I can tell the amount of customer growth I'll be expecting or > HOPING to see, but come on. > > I know IPv4 space must be handed out responsibly, but this is seriously > going too far, especially for a LIR. Supposedly I cannot give a > routing-reason for requesting PI space, but part of that IS important on > why I'm requesting it. It's really not desirable for us AND for my > customer to chop out a part of my PA space and announce in smaller > chunks from his own AS on the same exchange points we're on and this > customer is NOT at the stage yet to become a full LIR himself. > > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From jeroen at easyhosting.nl Thu Jul 16 10:00:32 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Thu, 16 Jul 2009 10:00:32 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <4A5DFC74.4030504@ripe.net> References: <4A5DC542.4050908@easyhosting.nl> <4A5DFC74.4030504@ripe.net> Message-ID: <4A5EDE20.1080609@easyhosting.nl> Hi Laura, Thanks, I already got into a discussion with Alex Le Heux, the policy implementation coordinator. My initial mail is meant to open a bit of a discussion on questions asked for PI allocations, mainly because I had to pull customer and growth statistics from my own customer that were none of my business to be honest. The situation is so, that we're a fairly large hosting and colocation provider, not the biggest by far but we come a long way in the dutch market. We have several smaller customers that rent a bunch of 19" racks but are usually in the same market as we are. So when a customer becomes bigger, we try and help and give some pointers to for example start routing themselves. We have very good relations with our customers, but once I have to pull detailed growth and customer statistics from our customers, it gets kinda awkward. Because these really aren't any of my (or RIPE's for that matter) business. I'm all for responsible allocation of resources, but it should really stop at asking expected growth for IP space and how subnets are to be allocated. I got pointed to the rule 'A customer cannot hold more then 2 IP addresses in the PI space', what's up with that ? This means that a customer with three SSL webshops and three IP's isn't allowed host his server in that PI range ? Also an eyebrow raiser : 'Your customer should become LIR himself'. So now I'd have to make up a story to justify a /21 for him (which he doesn't need yet) rather then a /24 + AS, which is the bare minimum to start routing on the internet ? I know it's all policy to hand out resources as good and honestly as possible, but (and this opinion is shared by more Dutch network operators I spoke with today) requesting PI space feels like pulling teeth and takes up far too much time like this. Laura Cobley wrote: > Dear Jeroen, Florian and all, > > The RIPE NCC has an internal escalation procedure for handling > concerns about the way your request has been handled. You can ask for > any request to be escalated by sending an email to hostmaster at ripe.net > and quoting the relevant NCC# ticket number. Your request will then be > reviewed and assessed by senior staff. > > If your concern is of a more serious nature, please refer to the RIPE > NCC's Conflict Arbitration Procedure available online at: > http://www.ripe.net/ripe/docs/arbitration.html > > Regards, > > Laura Cobley > RIPE NCC Registration Services > > > Jeroen Wunnink wrote: >> Hello Members, >> >> I'd like to state a complaint toward overly complicated issues with >> requesting PI space as a LIR for a customer. >> >> Situation: I have a customer who's purchased a router and wants his >> own IP space+AS number to start multihoming. Since he's pretty new to >> routing and policies of RIPE and managing the database to keep things >> going, we as LIR offered him to do this for him at the startup phase. >> Currently he'll be hosting several services from within our PA ranges >> and will start growing his new resources in the PI space he wants. >> >> After filling in the request forms, his AS got approved pending the >> PI /24 range assignment. And that's been a process that's currently >> becoming something ridiculous. >> >> Initially I got some return questions on how the subnets would be >> sliced up, what would be used for management of the routers, if IP's >> are being assigned statically or dynamically, how much IP's a >> customer would use and if PA space is being returned. Questions >> (except for the 'how much IP's will a customer use') I can understand >> and all answered. >> >> Then in a follow-up I got asked what the montly growth is, who's >> administratively responsible for the IP's and how they're going to be >> used on the servers. >> >> Then in a next follow up I got pointed to using PA space either from >> us or a different provider or that the customer should become LIR >> himself since we as LIR cannot sub-allocate PI space. (something >> that's not intended in the first place at all, we just administer it >> on a contract base until he understands procedures) >> >> And then after explaining that we will only help the customer on >> contract base and not sub-allocate anything, another follow-up comes >> that no customer can use more then 1 or 2 IP's and once again a >> question on how many servers are involved here. >> >> And that's where I'm at now. I've been trying to request PI space for >> our customer since last friday, and in my opinion there's too much >> meddling into internal business by RIPE here and this is taking a >> ridiculous amount of time and communication. >> >> As a LIR we hand out IP space responsibly to our customers, for a >> good technical and administrative reason we have a customer who wants >> his own PI assignment and I'm asking him questions about his business >> that lean towards a company secret. In my opinion RIPE has absolutely >> no business in asking how many customers and/or servers someone has >> and stating that a customer can not use >2 IP's in that PI space >> (what if someone has *gasp* 3 SSL websites ?, I cannot imagine that >> happening.., ever). >> >> Also neither we or our customer has a crystal ball to see in the >> future, so sure I can tell the amount of customer growth I'll be >> expecting or HOPING to see, but come on. >> >> I know IPv4 space must be handed out responsibly, but this is >> seriously going too far, especially for a LIR. Supposedly I cannot >> give a routing-reason for requesting PI space, but part of that IS >> important on why I'm requesting it. It's really not desirable for us >> AND for my customer to chop out a part of my PA space and announce in >> smaller chunks from his own AS on the same exchange points we're on >> and this customer is NOT at the stage yet to become a full LIR himself. >> >> -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From slz at baycix.de Thu Jul 16 10:26:38 2009 From: slz at baycix.de (Sascha Lenz) Date: Thu, 16 Jul 2009 10:26:38 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <4A5EDE20.1080609@easyhosting.nl> References: <4A5DC542.4050908@easyhosting.nl> <4A5DFC74.4030504@ripe.net> <4A5EDE20.1080609@easyhosting.nl> Message-ID: <4A5EE43E.2090105@baycix.de> Hi, Jeroen Wunnink schrieb: [...] > Also an eyebrow raiser : 'Your customer should become LIR himself'. > So now I'd have to make up a story to justify a /21 for him (which he > doesn't need yet) rather then a /24 + AS, which is the bare minimum to > start routing on the internet ? [...] you don't need to justify anything to get your /21 Allocation if you become a LIR. It's an ALLOCATION, not an ASSIGNMENT. Don't always mix those two up, totally different things. It's way more simple than requesting PI Assignments if you are a an ISP/Provider yourself. LIR with PA Allocations == Provider/ISPs Customer with PI Assignments == Endusers, not distributing IP space to 3rd parties If your customer is not an enduser but got customers themselves, they should become LIR on their own behalf. I actually don't see the problem. But of course things can be changed, the policy process is open. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From Keith.Nolan at premiereglobal.ie Thu Jul 16 11:48:05 2009 From: Keith.Nolan at premiereglobal.ie (Nolan, Keith) Date: Thu, 16 Jul 2009 10:48:05 +0100 Subject: [address-policy-wg] PA Assignment questions Message-ID: <92C3E3DCDFBEC944AD871B8041E89EA502465460@iesem04.Europe.premconf.com> Address Policy Working Group, I'm working for a company who decided to become a LIR as we have a requirement for Large amounts of IP Space. We are not assigning IP Space to our customers as all the IP Space is used for our own infrastructure. We have been provided with a PA Allocation, however we are having issues getting PA Assignments approved by RIPE NCC. We applied for PA Assignments in /24 blocks so that we could multi-home using BGP from all of our production sites and some of our more critical offices These sites don't have a shared Network connecting them (except for the Internet) We are using the "allowas-in" command so that we don't need an AS Number from each non-connected site. (As the RIPE NCC wouldn't approve our application for multiple AS Numbers) The request of PA Assignments is getting rejected because 1. We can't aggregate the IP Space (RIPE NCC wants us to advertise our entire PA Space and not break it into smaller networks as we require) 2. The IP Space required in some of the sites is less than a /24 (However we need /24 networks as our Transit providers filter IP Space smaller than /24) The suggestion from RIPE NCC was to apply for smaller Assignments from the PA Space and to take each of them from a separate /24 range, and to create a /24 route object for each separate /24 Space, or to apply for PI Space for each location as PI Space was more in-line with what we are trying to achieve. While this will work, I have an issue with RIPE NCC providing a work around, and I believe the policy should allow for a LIR to use the PA Allocation in the best manner to conserve IP Space and to not have "Available" networks in PA Space which can never be assigned and to not waste PI space by not allowing a LIR use the Allocated PA Space for its own Infrastructure. Thanks Keith Keith Nolan Director of Network and IT Operations, EMEA Premiere Global Services Tel: +353 (0) 23 88 32103 Mob: +353 (0) 86 919 8149 Fax: +353 (0) 23 88 36101 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 7787 bytes Desc: image001.jpg URL: From slz at baycix.de Thu Jul 16 12:01:42 2009 From: slz at baycix.de (Sascha Lenz) Date: Thu, 16 Jul 2009 12:01:42 +0200 Subject: [address-policy-wg] PA Assignment questions In-Reply-To: <92C3E3DCDFBEC944AD871B8041E89EA502465460@iesem04.Europe.premconf.com> References: <92C3E3DCDFBEC944AD871B8041E89EA502465460@iesem04.Europe.premconf.com> Message-ID: <4A5EFA86.9080601@baycix.de> Hi, Nolan, Keith schrieb: [...] > The suggestion from RIPE NCC was to apply for smaller Assignments from > the PA Space and to take each of them from a separate /24 range, and to > create a /24 route object for each separate /24 Space, or to apply for > PI Space for each location as PI Space was more in-line with what we are > trying to achieve. > > > > While this will work, I have an issue with RIPE NCC providing a work > around, and I believe the policy should allow for a LIR to use the PA > Allocation in the best manner to conserve IP Space and to not have > ?Available? networks in PA Space which can never be assigned and to not > waste PI space by not allowing a LIR use the Allocated PA Space for its > own Infrastructure. sorry, i don't really understand where the problem with RIPEs suggestions is? Does it matter if /25 of a /24 is assigned or the whole /24 for conservation purposes?! If you don't need the full /24, it's wasted in any way? Or did i get you wrong? And please, sorry, PA == Provider AGGREGATED. If you don't aggregate, you will run into problems like LIR Allocation Size filters in some places anyways. You just set this up the wrong way. Seems like you designed something without understanding all the implications? Also, PI or PA is only a policy thing, what's the waste in using PI over PA? Nothing, a PI /24 is a /24 like a PA /24 is ... Again, sorry, i don't understand your problem. RIPEs suggestion is perfectly valid. Using PI instead of PA will even safe you the hassle with connectivity issues you will get announcing /24s out of a PA block with minimun allocation size like /21 - you will get filtered by some networks. Get your design right might be the best solution (no offencement!). What you want to do is actually the workaround, not RIPEs solution. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From joao at bondis.org Thu Jul 16 12:08:36 2009 From: joao at bondis.org (=?WINDOWS-1252?Q?Jo=E3o_Damas?=) Date: Thu, 16 Jul 2009 12:08:36 +0200 Subject: [address-policy-wg] PA Assignment questions In-Reply-To: <4A5EFA86.9080601@baycix.de> References: <92C3E3DCDFBEC944AD871B8041E89EA502465460@iesem04.Europe.premconf.com> <4A5EFA86.9080601@baycix.de> Message-ID: <3A80B942-F3F8-4B08-B3E7-84BE30D5AA5C@bondis.org> On 16 Jul 2009, at 12:01, Sascha Lenz wrote: > > And please, sorry, PA == Provider AGGREGATED. just a minor point, it is Provider AGGREGATABLE, not AGGREGATED. It describes a possibility not a fact. If I understand the original mail correctly, the requester was trying to do the right thing, that is, after following the "become an LIR" mantra and gettting the address space as requested, the LIR is now being told they can't assign the addresses they got and must instead get more address space in order to split it (?!?!?!). If this is so (I am not sure it is, it is just how I read the mail) it seems to be counterintuitive to say the least, counterproductive towards conservation if correctly interpreted. Joao From Keith.Nolan at premiereglobal.ie Thu Jul 16 12:40:55 2009 From: Keith.Nolan at premiereglobal.ie (Nolan, Keith) Date: Thu, 16 Jul 2009 11:40:55 +0100 Subject: [address-policy-wg] PA Assignment questions In-Reply-To: <3A80B942-F3F8-4B08-B3E7-84BE30D5AA5C@bondis.org> References: <92C3E3DCDFBEC944AD871B8041E89EA502465460@iesem04.Europe.premconf.com> <4A5EFA86.9080601@baycix.de> <3A80B942-F3F8-4B08-B3E7-84BE30D5AA5C@bondis.org> Message-ID: <92C3E3DCDFBEC944AD871B8041E89EA502465495@iesem04.Europe.premconf.com> I don't have an issue with the answer RIPE NCC provided to me, as it allows me to achieve my required Network design and was following RIPE Policy. On the RIPE.net page there is a statement about why you may want to become a LIR "If your organisation needs a large amount of IPv4, IPv6 and AS Numbers, routable blocks of address space and/or makes assignments to End Users or customers" This statement describes my company, therefore we became a LIR. When you become a LIR a PA Allocation is provided automatically. The issue I have is as a LIR I have a PA Allocation, the Allocation has enough IP Space to allow me implement my design, however I'm being suggested to use PI Space instead of the PA Space due to the type of design I'm using, and this will cause some of my PA Space to be wasted and is counter to the policy of IP Space conservation. The workaround which RIPE NCC provided (create /25 or /26 inetnum's but have them all in separate /24 networks and create a /24 route object) will work within the assignments they have already approved, so I can move forward. However I think this workaround shouldn't be required and since I need /24 networks for routing, I should be allowed to create inetnum's for the /24 networks. And as this is a policy wg, I believed it was a good place to ask this type of question. Thanks Keith From ncc at ripe.net Thu Jul 16 12:34:17 2009 From: ncc at ripe.net (Scott Donald) Date: Thu, 16 Jul 2009 12:34:17 +0200 Subject: [address-policy-wg] Anycasting Assignments for TLDs and Tier 0/1 ENUM Implemented Message-ID: [Apologies for duplicates] Dear Colleagues, We are pleased to announce that the RIPE NCC has implemented the accepted policy proposal 2008-05, "Anycasting Assignments for TLDs and Tier 0/1 ENUM". This allows Tier 0/1 ENUM operators to receive IPv4 and IPv6 anycasting assignments and increases the number of anycasting prefixes that can be assigned to an operator from one to a maximum of four assignments. The request form and supporting notes are available from the RIPE Document Store at: http://www.ripe.net/ripe/docs/requestforms.html If you have any questions regarding this, please contact . Regards, Scott Donald Registration Services, RIPE NCC From Keith.Nolan at premiereglobal.ie Thu Jul 16 13:10:15 2009 From: Keith.Nolan at premiereglobal.ie (Nolan, Keith) Date: Thu, 16 Jul 2009 12:10:15 +0100 Subject: [address-policy-wg] PA Assignment questions In-Reply-To: <92C3E3DCDFBEC944AD871B8041E89EA502465495@iesem04.Europe.premconf.com> References: <92C3E3DCDFBEC944AD871B8041E89EA502465460@iesem04.Europe.premconf.com> <4A5EFA86.9080601@baycix.de> <3A80B942-F3F8-4B08-B3E7-84BE30D5AA5C@bondis.org> <92C3E3DCDFBEC944AD871B8041E89EA502465495@iesem04.Europe.premconf.com> Message-ID: <92C3E3DCDFBEC944AD871B8041E89EA50246549E@iesem04.Europe.premconf.com> The other issue with suggesting that we use PI Space instead of PA Space where we will not be in a position to aggregate is the PI Assignment which would be approved would be less than a /24 (as we don't need 128 addresses for Multi-homed BGP Peering), therefore wouldn't be routable on the Internet (Policy proposal 2006-05 refers to this issue and suggests the smallest PI Space should be /24) So the only way to implement Multi-Home BGP Routing from Multiple locations which don't need a full /24 network is to become a LIR and create smaller /25 or /26 inetnum's with larger /24 route objects from your PA Space. And since this is a workaround, just like a company stretching the truth about their IP requirements when applying for a PI Space to get a full /24, surely a LIR should be allowed to create inetnum's for a /24 when they also need to create a /24 route object. Keith -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Nolan, Keith Sent: 16 July 2009 11:41 To: Jo?o Damas; Sascha Lenz Cc: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] PA Assignment questions I don't have an issue with the answer RIPE NCC provided to me, as it allows me to achieve my required Network design and was following RIPE Policy. On the RIPE.net page there is a statement about why you may want to become a LIR "If your organisation needs a large amount of IPv4, IPv6 and AS Numbers, routable blocks of address space and/or makes assignments to End Users or customers" This statement describes my company, therefore we became a LIR. When you become a LIR a PA Allocation is provided automatically. The issue I have is as a LIR I have a PA Allocation, the Allocation has enough IP Space to allow me implement my design, however I'm being suggested to use PI Space instead of the PA Space due to the type of design I'm using, and this will cause some of my PA Space to be wasted and is counter to the policy of IP Space conservation. The workaround which RIPE NCC provided (create /25 or /26 inetnum's but have them all in separate /24 networks and create a /24 route object) will work within the assignments they have already approved, so I can move forward. However I think this workaround shouldn't be required and since I need /24 networks for routing, I should be allowed to create inetnum's for the /24 networks. And as this is a policy wg, I believed it was a good place to ask this type of question. Thanks Keith From slz at baycix.de Thu Jul 16 13:24:55 2009 From: slz at baycix.de (Sascha Lenz) Date: Thu, 16 Jul 2009 13:24:55 +0200 Subject: [address-policy-wg] PA Assignment questions In-Reply-To: <92C3E3DCDFBEC944AD871B8041E89EA50246549E@iesem04.Europe.premconf.com> References: <92C3E3DCDFBEC944AD871B8041E89EA502465460@iesem04.Europe.premconf.com> <4A5EFA86.9080601@baycix.de> <3A80B942-F3F8-4B08-B3E7-84BE30D5AA5C@bondis.org> <92C3E3DCDFBEC944AD871B8041E89EA502465495@iesem04.Europe.premconf.com> <92C3E3DCDFBEC944AD871B8041E89EA50246549E@iesem04.Europe.premconf.com> Message-ID: <4A5F0E07.7070809@baycix.de> Nolan, Keith schrieb: > The other issue with suggesting that we use PI Space instead of PA Space where we will not be in a position to aggregate is the PI Assignment which would be approved would be less than a /24 (as we don't need 128 addresses for Multi-homed BGP Peering), therefore wouldn't be routable on the Internet (Policy proposal 2006-05 refers to this issue and suggests the smallest PI Space should be /24) > > > So the only way to implement Multi-Home BGP Routing from Multiple locations which don't need a full /24 network is to become a LIR and create smaller /25 or /26 inetnum's with larger /24 route objects from your PA Space. And since this is a workaround, just like a company stretching the truth about their IP requirements when applying for a PI Space to get a full /24, surely a LIR should be allowed to create inetnum's for a /24 when they also need to create a /24 route object. [...] please have a look at http://www.ripe.net/ripe/policies/proposals/2006-05.html and the discussions on the ap-wg list (i think) about it in the mailinglist archive if you don't read the list on a regular basis. It's partially about your problem here. It is indeed considered a problem by some other people, too. Although the current thinking by most involved in the policy process seems to be that it's weired that you need PI space and your own routing policy for two or three boxes (or so) in the first place. In any ways, it's probably still a design problem. Why did you design a network with multiple locations and no connection between them as a normal network architect would do? It's probably none of our business here how you design your network, but that is considered a fail anyways :-) If you really have independent locations, you need independent ressources, multiple LIRs probably or multiple PI Assignments. It's a really bad habbit to slit up PA Allocations and might not work out for you in all cases, you need workarounds like Tunnels between the locations and a site announcing the aggregate so you don't run into the PA Filters ... and so on ... But again, i don't really see the problem, i'm afraid. Probably some other people on the list can. P.S.: Don't think too much about address conservation. It's overrated, we have IPv6 now :-) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From filiz at ripe.net Thu Jul 16 13:41:16 2009 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 16 Jul 2009 13:41:16 +0200 Subject: [address-policy-wg] 2009-07 Moved to Review Phase (Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries) Message-ID: <20090716114116.10BEC2F583@herring.ripe.net> PDP Number: 2009-07 Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries Dear Colleagues, We have published a draft document for the proposal described in 2009-07 as well as the impact analysis that was conducted for this proposal. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-07.html and the draft document at: http://www.ripe.net/ripe/draft-documents/ripe-416-draft-2009-07.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 13 August 2009. Regards, Filiz Yilmaz Policy Development Manager RIPE NCC From filiz at ripe.net Thu Jul 16 13:51:06 2009 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 16 Jul 2009 13:51:06 +0200 Subject: [address-policy-wg] 2009-08 New Draft Document Published (IPv6 Provider Independent (PI) Assignments for LIRs) Message-ID: <20090716115106.CCA8E2F583@herring.ripe.net> PDP Number: 2009-08 IPv6 Provider Independent (PI) Assignments for LIRs Dear Colleagues, The text of the policy proposal 2009-08 has been revised based on the community feedback. We have published the new version (version 2.0) today. The draft document for the proposal has also been published as well as the impact analysis that was conducted for this proposal. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-08.html and the draft document at: http://www.ripe.net/ripe/draft-documents/ripe-472-draft2009-08.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 13 August 2009. Regards, Filiz Yilmaz Policy Development Manager RIPE NCC From dogwallah at gmail.com Thu Jul 16 14:25:45 2009 From: dogwallah at gmail.com (McTim) Date: Thu, 16 Jul 2009 10:25:45 -0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <4A5EDE20.1080609@easyhosting.nl> References: <4A5DC542.4050908@easyhosting.nl> <4A5DFC74.4030504@ripe.net> <4A5EDE20.1080609@easyhosting.nl> Message-ID: On Thu, Jul 16, 2009 at 6:00 AM, Jeroen Wunnink wrote: > We have very good relations with our customers, but once I have to pull > detailed growth and customer statistics from our customers, it gets kinda > awkward. Because these really aren't any of my (or RIPE's for that matter) > business. I'm not sure that's your call to make. I'm all for responsible allocation of resources, but it should > really stop at asking expected growth for IP space and how subnets are to be > allocated. > > I got pointed to the rule 'A customer cannot hold more then 2 IP addresses > in the PI space', what's up with that ? IIRC it's more of a guideline than a "rule" Rules are in the policy document where it says: "PI space cannot be re-assigned or further assigned to other parties." So if you are indeed assigning adresses to your customers, you need PA space. I'm sure that the competent professionals at the NCC have pointed you to http://ripe.net/ripe/docs/ripe-471.html#9 already. This means that a customer with > three SSL webshops and three IP's isn't allowed host his server in that PI > range ? A customer is't "allowed" to do anything with your PI space. You are however allowed to use it to support your business. If I were you, I'd follow the advice of the NCC staff. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From jeroen at easyhosting.nl Thu Jul 16 14:46:05 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Thu, 16 Jul 2009 14:46:05 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: References: <4A5DC542.4050908@easyhosting.nl> <4A5DFC74.4030504@ripe.net> <4A5EDE20.1080609@easyhosting.nl> Message-ID: <4A5F210D.1020200@easyhosting.nl> No it indeed isn't my call to make, which is why I opened a discussion here on the policy workgroup list. The current policy is in my opinion a bit too intrusive and time consuming, and I wanted to see if that opinion is shared by more people. And if the two IP's are a guideline, why did the hostmaster give me, i quote: If customers are allowed to manage how more than 4 IP addresses are used on this network, then PI addressing space cannot be used. Please confirm that even after the customer's network has been expanded in the future, they will not be allowed to administrate more than a /30. And it's not my PI space/resource (that's not even possible as a LIR), It's been requested by us as a LIR on behalf of the customer on his name and own ORG object. McTim wrote: > On Thu, Jul 16, 2009 at 6:00 AM, Jeroen Wunnink wrote: > > >> We have very good relations with our customers, but once I have to pull >> detailed growth and customer statistics from our customers, it gets kinda >> awkward. Because these really aren't any of my (or RIPE's for that matter) >> business. >> > > I'm not sure that's your call to make. > > I'm all for responsible allocation of resources, but it should > >> really stop at asking expected growth for IP space and how subnets are to be >> allocated. >> >> I got pointed to the rule 'A customer cannot hold more then 2 IP addresses >> in the PI space', what's up with that ? >> > > IIRC it's more of a guideline than a "rule" Rules are in the policy > document where it says: > > "PI space cannot be re-assigned or further assigned to other parties." > > So if you are indeed assigning adresses to your customers, you need PA > space. I'm sure that the competent professionals at the NCC have > pointed you to http://ripe.net/ripe/docs/ripe-471.html#9 already. > > This means that a customer with > >> three SSL webshops and three IP's isn't allowed host his server in that PI >> range ? >> > > A customer is't "allowed" to do anything with your PI space. You are > however allowed to use it to support your business. If I were you, > I'd follow the advice of the NCC staff. > > -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From dmitry at volia.net Thu Jul 16 14:46:54 2009 From: dmitry at volia.net (Dmitry Kiselev) Date: Thu, 16 Jul 2009 15:46:54 +0300 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: References: <4A5DC542.4050908@easyhosting.nl> <4A5DFC74.4030504@ripe.net> <4A5EDE20.1080609@easyhosting.nl> Message-ID: <20090716124654.GW1406@f17.dmitry.net> On Thu, Jul 16, 2009 at 10:25:45AM -0200, McTim wrote: > On Thu, Jul 16, 2009 at 6:00 AM, Jeroen Wunnink wrote: > > > We have very good relations with our customers, but once I have to pull > > detailed growth and customer statistics from our customers, it gets kinda > > awkward. Because these really aren't any of my (or RIPE's for that matter) > > business. > > I'm not sure that's your call to make. > > I'm all for responsible allocation of resources, but it should > > really stop at asking expected growth for IP space and how subnets are to be > > allocated. > > > > I got pointed to the rule 'A customer cannot hold more then 2 IP addresses > > in the PI space', what's up with that ? > > IIRC it's more of a guideline than a "rule" Rules are in the policy > document where it says: > > "PI space cannot be re-assigned or further assigned to other parties." > > So if you are indeed assigning adresses to your customers, you need PA > space. I'm sure that the competent professionals at the NCC have > pointed you to http://ripe.net/ripe/docs/ripe-471.html#9 already. It is not the case. According to http://www.ripe.net/ripe/docs/ripe-471.html#62 single IP assigned to End User "considered part of the service provider's infrastructure". Moreover, if service provider assign several IPs to the same End User and these IPs could not be aggregated (covered with common netmask) they are still considered SP infrastructure. Where I wrong? -- Dmitry Kiselev From mark at streamservice.nl Thu Jul 16 14:58:43 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Thu, 16 Jul 2009 14:58:43 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <4A5F210D.1020200@easyhosting.nl> References: <4A5DC542.4050908@easyhosting.nl> <4A5DFC74.4030504@ripe.net> <4A5EDE20.1080609@easyhosting.nl> <4A5F210D.1020200@easyhosting.nl> Message-ID: <016801ca0615$266518c0$732f4a40$@nl> If you ask me it should be allowed to use PI space for clients (and give clients the option to use/maintain more than a /30 (IPv4)). It is also in my opinion not to RIPE (community or the NCC) to ask that information. The should ask for general usage, how much would be used for clients for example. How many clients a company has shouldn't be important to get PI. Regards, Mark -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jeroen Wunnink Sent: donderdag 16 juli 2009 14:46 To: McTim Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space No it indeed isn't my call to make, which is why I opened a discussion here on the policy workgroup list. The current policy is in my opinion a bit too intrusive and time consuming, and I wanted to see if that opinion is shared by more people. And if the two IP's are a guideline, why did the hostmaster give me, i quote: If customers are allowed to manage how more than 4 IP addresses are used on this network, then PI addressing space cannot be used. Please confirm that even after the customer's network has been expanded in the future, they will not be allowed to administrate more than a /30. And it's not my PI space/resource (that's not even possible as a LIR), It's been requested by us as a LIR on behalf of the customer on his name and own ORG object. McTim wrote: > On Thu, Jul 16, 2009 at 6:00 AM, Jeroen Wunnink wrote: > > >> We have very good relations with our customers, but once I have to pull >> detailed growth and customer statistics from our customers, it gets kinda >> awkward. Because these really aren't any of my (or RIPE's for that matter) >> business. >> > > I'm not sure that's your call to make. > > I'm all for responsible allocation of resources, but it should > >> really stop at asking expected growth for IP space and how subnets are to be >> allocated. >> >> I got pointed to the rule 'A customer cannot hold more then 2 IP addresses >> in the PI space', what's up with that ? >> > > IIRC it's more of a guideline than a "rule" Rules are in the policy > document where it says: > > "PI space cannot be re-assigned or further assigned to other parties." > > So if you are indeed assigning adresses to your customers, you need PA > space. I'm sure that the competent professionals at the NCC have > pointed you to http://ripe.net/ripe/docs/ripe-471.html#9 already. > > This means that a customer with > >> three SSL webshops and three IP's isn't allowed host his server in that PI >> range ? >> > > A customer is't "allowed" to do anything with your PI space. You are > however allowed to use it to support your business. If I were you, > I'd follow the advice of the NCC staff. > > -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From slz at baycix.de Thu Jul 16 15:04:57 2009 From: slz at baycix.de (Sascha Lenz) Date: Thu, 16 Jul 2009 15:04:57 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Complaint: Overly complicated when requesting PI space In-Reply-To: <016801ca0615$266518c0$732f4a40$@nl> References: <4A5DC542.4050908@easyhosting.nl> <4A5DFC74.4030504@ripe.net> <4A5EDE20.1080609@easyhosting.nl> <4A5F210D.1020200@easyhosting.nl> <016801ca0615$266518c0$732f4a40$@nl> Message-ID: <4A5F2579.9030705@baycix.de> Hi, Stream Service || Mark Scholten schrieb: > If you ask me it should be allowed to use PI space for clients (and give > clients the option to use/maintain more than a /30 (IPv4)). It is also in my > opinion not to RIPE (community or the NCC) to ask that information. The > should ask for general usage, how much would be used for clients for > example. How many clients a company has shouldn't be important to get PI. [...] again - Assignments are made to End-Users. If you are not an End-User, you need to become LIR and get an Allocation from which you can assign to End-Users. If you have an Assigment, it's for YOU, and YOU only, not any 3rd parties. This is a basic concept for ages. It's very simple. What is so hard to understand there and where is your problem with that? -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From mohta at necom830.hpcl.titech.ac.jp Thu Jul 16 15:46:15 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 16 Jul 2009 22:46:15 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <4A552018.9030407@necom830.hpcl.titech.ac.jp> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> Message-ID: <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> Masataka Ohta wrote: > Gert Doering wrote: >>There is no mandate to use NAT in the RIPE region (and I think that this >>is a good thing, as NAT might be useful, but overall it takes away freedom >>from the Internet users, and this shouldn't be forced on anybody). > I'll come back later after finishing a proposal of "end to end NAT", > which has end to end transparency to be able to support ftp port > command, SCTP, IPsec, DNS reverse look up, multicast, mobility and > so on. I have written an Internet Draft to explain end to end NAT. http://tools.ietf.org/html/draft-ohta-e2e-nat-00 You can see the only reason to deploy IPv6 to keep the freedom of end to end transparency is now non-exsitent. So, to keep IPv4 until we are ready with something much better than IPv6, why not mandate some form of NAT, legacy, end to end or whatever. Masataka Ohta PS First thing we should do is to make initial PA allocation /24 and reduce the number of IP addresses allocated to an end user by 1/256 or so. From garry at nethinks.com Thu Jul 16 16:16:36 2009 From: garry at nethinks.com (Garry Glendown) Date: Thu, 16 Jul 2009 16:16:36 +0200 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> References: <20090705100003.22200.63618.Mailman@postboy.ripe.net> <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> Message-ID: <4A5F3644.5010003@nethinks.com> Masataka Ohta wrote: > I have written an Internet Draft to explain end to end NAT. > http://tools.ietf.org/html/draft-ohta-e2e-nat-00 > > You can see the only reason to deploy IPv6 to keep the freedom of > end to end transparency is now non-exsitent. > > So, to keep IPv4 until we are ready with something much better > than IPv6, why not mandate some form of NAT, legacy, end to > end or whatever. > > Masataka Ohta > > PS > > First thing we should do is to make initial PA allocation /24 and > reduce the number of IP addresses allocated to an end user by > 1/256 or so. > Please say you don't really mean this and it's just a joke you're playing on the Internet community ... NAT has been a kludge from the beginning, and now you try to "fix" the low availability of IPv6-capable hardware (which is finally starting to pick up a bit) by implementing yet another, even worse kludge? And what's that, "ready with something much better than IPv6"? Heck, it took much too long for working v6-equipement already, with even large vendors not having implemented it completely and reliably ... you mean to tell folks now to flush 10+ years of work down the drain, just because you have the "miracle cure" against (temporary) IPv4 shortage, and we now have another 10-20 years until we _REALLY_ run out of IPs? (please check on the time it usually takes standards committees to pass something like a new protocol, e.g. how long it took to get IPv6 standardized ...) Also, I don't see where your E2E really fixes reachability issues that current NAT has. Sure, it may fix the multiple-port problems of current NAT (which is already fixed by decent firewalls) Apart from that, your draft requires changes in both the gateways AND the applications --- do you honestly believe that _that_ can be implemented decently before IPv4 exhaustion? But maybe I'm just too stupid to see the genius behind your proposal ... -garry From gert at space.net Thu Jul 16 16:17:38 2009 From: gert at space.net (Gert Doering) Date: Thu, 16 Jul 2009 16:17:38 +0200 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> References: <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> Message-ID: <20090716141738.GG26102@Space.Net> Hi, On Thu, Jul 16, 2009 at 10:46:15PM +0900, Masataka Ohta wrote: > > I'll come back later after finishing a proposal of "end to end NAT", > > which has end to end transparency to be able to support ftp port > > command, SCTP, IPsec, DNS reverse look up, multicast, mobility and > > so on. > > I have written an Internet Draft to explain end to end NAT. > > http://tools.ietf.org/html/draft-ohta-e2e-nat-00 > > You can see the only reason to deploy IPv6 to keep the freedom of > end to end transparency is now non-exsitent. Given that all currently available operating systems fully support IPv6, and none of them support the modifications necessary to "help the NAT gateway", I can't see how this would be a step forward. But this is far out of scope for RIPE APWG anyway - if there is consensus in the IETF that *this* is the way forward, then it's time for us to amend policies for this. Right now, it's a personal draft and one personal opionion. regard, Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From fweimer at bfk.de Thu Jul 16 16:26:32 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 16 Jul 2009 14:26:32 +0000 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <20090716141738.GG26102@Space.Net> (Gert Doering's message of "Thu\, 16 Jul 2009 16\:17\:38 +0200") References: <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> Message-ID: <82zlb44sbr.fsf@mid.bfk.de> * Gert Doering: > Given that all currently available operating systems fully support IPv6, Nit: "Full support" is neither generally available nor necessary. IPv6 support levels are typically sufficient, although usually not RFC-conforming (just like IPv4, where we've learnt not to enable certain protocol features). > and none of them support the modifications necessary to "help the NAT > gateway", I can't see how this would be a step forward. > > But this is far out of scope for RIPE APWG anyway Is it? RIPE could promote 6to4 adoption (similary to what is done for ENUM). Perhaps it's more of a topic for the IPv6 WG, but I don't think this is IETF or ICANN material. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mohta at necom830.hpcl.titech.ac.jp Thu Jul 16 16:59:02 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 16 Jul 2009 23:59:02 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <20090716141738.GG26102@Space.Net> References: <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> Message-ID: <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> Gert Doering wrote: >> http://tools.ietf.org/html/draft-ohta-e2e-nat-00 >> >>You can see the only reason to deploy IPv6 to keep the freedom of >>end to end transparency is now non-exsitent. > Given that all currently available operating systems fully support IPv6, The reality is that there is no one with meaningful operational experience of IPv6. Worse, people trying to deploy IPv6 are now recommending to use NAT between 4 and 6. So, our choise is to operate 4 and NAT or to operate 4, 6 and NAT > and none of them support the modifications necessary to "help the NAT > gateway", I can't see how this would be a step forward. Read the draft. It is implemented and working on NETBSD5.0. > But this is far out of scope for RIPE APWG anyway - if there is consensus > in the IETF that *this* is the way forward, then it's time for us to > amend policies for this. Right now, it's a personal draft and one > personal opionion. In my previous mail, I wrote: why not mandate some form of NAT, legacy, end to end or whatever. So, though end to end NAT give you freedom, which was your reason for IPv6, you may use other forms of NAT some of which has been deployed for more than 10 years. Masataka Ohta From gert at space.net Thu Jul 16 17:02:45 2009 From: gert at space.net (Gert Doering) Date: Thu, 16 Jul 2009 17:02:45 +0200 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <82zlb44sbr.fsf@mid.bfk.de> References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <82zlb44sbr.fsf@mid.bfk.de> Message-ID: <20090716150245.GH26102@Space.Net> Hi, On Thu, Jul 16, 2009 at 02:26:32PM +0000, Florian Weimer wrote: > > and none of them support the modifications necessary to "help the NAT > > gateway", I can't see how this would be a step forward. > > > > But this is far out of scope for RIPE APWG anyway > > Is it? Yes. > RIPE could promote 6to4 adoption (similary to what is done for ENUM). > Perhaps it's more of a topic for the IPv6 WG, but I don't think this > is IETF or ICANN material. This is a technical draft. RIPE hands out IP addresses according to need, and "need" is somewhat defined in the framework of IETF technology. As long as there is no IETF consensus on this sort of NAT (and implementations are widely available!), it makes no sense for policy to be adapted to it. (It's *especially* off-topic for the IPv6 WG, as this is purely about "not using IPv6 but sticking with IPv4 NAT for ever"). Maybe you misread the draft document? Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From gert at space.net Thu Jul 16 17:08:22 2009 From: gert at space.net (Gert Doering) Date: Thu, 16 Jul 2009 17:08:22 +0200 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> Message-ID: <20090716150822.GI26102@Space.Net> Hi, On Thu, Jul 16, 2009 at 11:59:02PM +0900, Masataka Ohta wrote: > Gert Doering wrote: > > >> http://tools.ietf.org/html/draft-ohta-e2e-nat-00 > >> > >>You can see the only reason to deploy IPv6 to keep the freedom of > >>end to end transparency is now non-exsitent. > > > Given that all currently available operating systems fully support IPv6, > > The reality is that there is no one with meaningful operational > experience of IPv6. This assumption is completely unfounded, and quite obviously wrong (I know at least one counter-example). [..] > > and none of them support the modifications necessary to "help the NAT > > gateway", I can't see how this would be a step forward. > Read the draft. It is implemented and working on NETBSD5.0. It's not committed - and even if it was, the amount of NetBSD machines out there is not relevant for home user deployments, where IPv4 shortage hits first. Come back when Microsoft has implemented this, and it's operational relevant enough that it's time to start discussing its impact on address policy. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From jeroen at easyhosting.nl Thu Jul 16 17:17:19 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Thu, 16 Jul 2009 17:17:19 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 Message-ID: <4A5F447F.2060408@easyhosting.nl> Members, I'd like to re-open the discussion for http://www.ripe.net/ripe/policies/proposals/2006-05.html which is still pending approval. In the current IPv4 address policy, routability on the internet is not a factor that is allowed to be taken into account when a PI space is requested. Yet anything smaller then a /24 is pretty much useless since most providers filter anything below /24 out. -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From mohta at necom830.hpcl.titech.ac.jp Thu Jul 16 17:50:49 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 17 Jul 2009 00:50:49 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <20090716150822.GI26102@Space.Net> References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> <20090716150822.GI26102@Space.Net> Message-ID: <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> Gert Doering wrote: >>The reality is that there is no one with meaningful operational >>experience of IPv6. > This assumption is completely unfounded, and quite obviously wrong > (I know at least one counter-example). The foundation is that there is no IPv6 network with meaningful scale. So, there can be no meaningful operational experience gained. >>>and none of them support the modifications necessary to "help the NAT >>>gateway", I can't see how this would be a step forward. >>Read the draft. It is implemented and working on NETBSD5.0. > It's not committed - and even if it was, the amount of NetBSD machines > out there is not relevant for home user deployments, where IPv4 shortage > hits first. Come back when Microsoft has implemented this, and it's As for windows, DLL replacement should be more than enough for which Microsoft involvement is not necessary (and is not likely for XP :-) > operational relevant enough that it's time to start discussing its > impact on address policy. Then, given the current operational status of IPv6, it's not yet time to start discussing IPv6 impact on IPv4 address policy. So, we must keep using IPv4 and accept NAT, legacy, end to end or whatever. Note again that I am talking about on address policy with NAT in general, including but not limited to end to end one. FYI, the following ID is one of the latest attempt to deploy IPv6: Prefix NAT: Host based IPv6 translation http://tools.ietf.org/html/draft-huang-pnat-host-ipv6-00 which is a lot more complex and a lot less transparent than end to end NAT and requires 4, 6 and NAT. Interestingly enough, as you can see from the title, it requires host software upgrade too. Do you like it? Or, can you show some realistic operational transition plan to IPv6? Masataka Ohta PS I have no intention to standardize end to end NAT in IETF only to waste yet another 10 years. From slz at baycix.de Thu Jul 16 18:00:56 2009 From: slz at baycix.de (Sascha Lenz) Date: Thu, 16 Jul 2009 18:00:56 +0200 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> <20090716150822.GI26102@Space.Net> <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> Message-ID: <4A5F4EB8.20600@baycix.de> Hi, Masataka Ohta schrieb: [...not quoting the meaningless stuff for a reason...] waering all my hats as private internet citizen, network operator for my own network, network architect for a non-commerial organisation supporting new technologies, LIR, ISP, and IT Consultant for big to large customers, i hearby state that i ... a) have operational IPv6 networks for 6 years now b) don't like NAT c) don't need NAT d) don't use NAT e) don't sell NAT if not a requirement by a customer f) don't see a reason to conserve IPv4 space g) don't see a reason not to migrate to IPv6 h) don't see a reason to handle the last IPv4 /8 any different and add more complexity policy-wise here i) don't support any more complex NAT setup than we already have in the wild now j) ..get bored by this now and stop here even though i might come up with more points ...just my 0.02EUR [yes i know, this is a destructive, polemic statement, but it fits the tone of the original suggestion somehow...] -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From mohta at necom830.hpcl.titech.ac.jp Thu Jul 16 18:02:54 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 17 Jul 2009 01:02:54 +0900 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <4A5F447F.2060408@easyhosting.nl> References: <4A5F447F.2060408@easyhosting.nl> Message-ID: <4A5F4F2E.80606@necom830.hpcl.titech.ac.jp> Jeroen Wunnink wrote: > In the current IPv4 address policy, routability on the internet is not a > factor that is allowed to be taken into account when a PI space is > requested. Yet anything smaller then a /24 is pretty much useless since > most providers filter anything below /24 out. I think minimum PA allocation should, instead, be /24. Then, ISPs assigning /26 (or /28, maybe) to their customers will start actively exchanging /26. Of course, the number of routing table entries will further explode, but it will so with IPv6. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Thu Jul 16 20:51:06 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 17 Jul 2009 03:51:06 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <4A5F4EB8.20600@baycix.de> References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> <20090716150822.GI26102@Space.Net> <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> <4A5F4EB8.20600@baycix.de> Message-ID: <4A5F769A.2040303@necom830.hpcl.titech.ac.jp> Sascha Lenz wrote: > waering all my hats as private internet citizen, network operator for my own network, network architect for a non-commerial organisation supporting new technologies, LIR, ISP, and IT Consultant for big to large customers, i hearby state that i ... To be a good internet citizen, you should read Saltzer's paper on end to end argument. > a) have operational IPv6 networks for 6 years now How many end users do you have? > b) don't like NAT I don't like legacy NAT too because it is not complete nor correct. A direct consequence of the end to end argument is: NAT can completely and correctly be implemented only with the knowledge and help of the end hosts behind a NAT gateway. which is not the case with legacy NAT. > f) don't see a reason to conserve IPv4 space > g) don't see a reason not to migrate to IPv6 The problem, here, is that there is no path to migrate to IPv6. Or, do you still believe dual stack approach work? > i) don't support any more complex NAT setup than we already have in the > wild now Fully agreed. Keep It Simple, Stupid. How do you think about proposals from people desperately working to deploy IPv6 to have complex and stateful NAT between 4 and 6? Masataka Ohta From davidm at futureinquestion.net Thu Jul 16 21:08:35 2009 From: davidm at futureinquestion.net (David Monosov) Date: Thu, 16 Jul 2009 21:08:35 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <4A5F3EE9.1070603@ripe.net> References: <4A5F3EE9.1070603@ripe.net> Message-ID: <4A5F7AB3.1020700@futureinquestion.net> Dear ncc-services-wg, address-policy-wg, >From the document: [...] 4.2 Violation of RIPE Policy, Law or Contract The RIPE NCC will de-register the independent Internet number resources in case of a fundamental breach of contract by the End User, supported by a Dutch court order; or Violation of Law by the End User, supported by a Dutch court order; or violation of RIPE Policy by the End User. [...] IANAL, so please forgive me if this course of inquiry is completely misguided, but does this not explicitly put the validity of resource assignments in the hands of Dutch courts and Dutch prosecutors? RIPE NCC, as an organization domiciled in the Netherlands would at all times have to comply with valid court orders. However, prior to the existence of a direct contractual relationship with end users and this policy, RIPE NCC merely served as a custodian for a database. Challenging the contents of this database would have been a legal adventure. With the introduction of complete contractual chain through RIPE NCC, a LIR, and the end user, combined with this formal explicit policy to which the end user and the LIR must agree - isn't there a potential loophole being created for an enterprising litigant to impose Dutch legislation where it is might be favorable to their cause on foreign end users? Certainly, if this interpretation isn't overly naive, such a loophole was not the intention of policy 2007-01. Has the RIPE NCC received any legal counseling on this matter, and would it be willing to publish the opinion they were provided with? -- Respectfully yours, David Monosov Andrea Cima wrote: > [Apologies for duplicate emails] > > Dear Colleagues, > > The RIPE NCC has published a new RIPE NCC procedural document: > ripe-475, "Independent Internet Number Resources  Contractual > Relationship Changes between sponsoring LIR and End User" > > This document describes the steps to be taken when there are changes in > the contractual relationship between the End User of independent > Internet number resources and the sponsoring Local Internet Registry > (LIR). It also describes the scenarios in which the RIPE NCC may > de-register independent Internet number resources and what happens to > those resources once they are de-registered. > > The new document is available at: > http://www.ripe.net/ripe/docs/ripe-475.html > > Kind regards, > > Andrea Cima > RIPE NCC From sander at steffann.nl Thu Jul 16 22:01:09 2009 From: sander at steffann.nl (Sander Steffann) Date: Thu, 16 Jul 2009 22:01:09 +0200 Subject: [address-policy-wg] Re: Complaint: Overly complicated when requesting PI space In-Reply-To: <016801ca0615$266518c0$732f4a40$@nl> References: <4A5DC542.4050908@easyhosting.nl> <4A5DFC74.4030504@ripe.net> <4A5EDE20.1080609@easyhosting.nl> <4A5F210D.1020200@easyhosting.nl> <016801ca0615$266518c0$732f4a40$@nl> Message-ID: Hello Mark, > If you ask me it should be allowed to use PI space for clients (and > give > clients the option to use/maintain more than a /30 (IPv4)). PI policy explicitly states that PI space can not be re-assigned or further assigned to other parties. See http://www.ripe.net/ripe/docs/ripe-471.html#9 . Any organisation that needs address space for its customers must use PA space. The definition of an LIR is that it assigns address space to its customers. PI space is (per definition) only to be used by the company that requested it itself. > It is also in my > opinion not to RIPE (community or the NCC) to ask that information. > The > should ask for general usage, how much would be used for clients for > example. How many clients a company has shouldn't be important to > get PI. In this case it doesn't matter. That the company needs address space for *any* customers indicates that PI space is not appropriate and PA space should be used. The company uses address space for customers and therefore must become an LIR. I think it is now time to stop this discussion, at least on the address policy mailing list. This discussion is not leading to a viable policy proposal. Thanks, Sander Steffann APWG co-chair From sander at steffann.nl Thu Jul 16 22:20:14 2009 From: sander at steffann.nl (Sander Steffann) Date: Thu, 16 Jul 2009 22:20:14 +0200 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <4A5F769A.2040303@necom830.hpcl.titech.ac.jp> References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> <20090716150822.GI26102@Space.Net> <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> <4A5F4EB8.20600@baycix.de> <4A5F769A.2040303@necom830.hpcl.titech.ac.jp> Message-ID: Hello Masataka, The document you sent to this list is only a draft. The chances of getting end to end NAT globally deployed before the IPv4 address space runs out are very close to zero, as it needs changes in hosts and gateways. Also remember that we make policy for all uses of IP addresses, not just end user networks that have/get/need a limited amount of public addresses. These policies also apply to datacenters where servers are hosted. There are many examples where you can not put those servers behind a NAT box. Mandating NAT in the way you have stated in your messages is therefore not possible. We are not going to change address policy in the whole RIPE region because of a draft document that only covers a part of what addresses are used for. For some people/companies this might be a very interesting subject, but please end this discussion on the address policy mailing list. Thank you, Sander Steffann APWG co-chair From marcoh at marcoh.net Thu Jul 16 23:33:06 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 16 Jul 2009 23:33:06 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <4A5F447F.2060408@easyhosting.nl> References: <4A5F447F.2060408@easyhosting.nl> Message-ID: <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> I've ran across a couple of networks who filter on /23, in fact I did it myself for a while while we were waiting for an upgrade. So the /24 is just as arbitrary as any other range. I ain't gonna see this one fly, what people will accept for routing as their business and shouldn't influence allocation or assignment policy. In fact during last meeting there was quite some debate about the fact all references to routing and/or filtering policy should be removed from address policy documents. RIPE and or RIPE NCC will never guarantee routabillity for any address range, adjusting the policy to allow a /24 just to get passed some filters implies you get routed. This is a bad proposal, completely going into the wrong direction and I won't support it, it should have been dropped years ago instead of keeping it sleeping. Grtx, MarcoH On Jul 16, 2009, at 5:17 PM, Jeroen Wunnink wrote: > Members, > > I'd like to re-open the discussion for http://www.ripe.net/ripe/policies/proposals/2006-05.html > which is still pending approval. > > In the current IPv4 address policy, routability on the internet is > not a factor that is allowed to be taken into account when a PI > space is requested. Yet anything smaller then a /24 is pretty much > useless since most providers filter anything below /24 out. > > -- > > Met vriendelijke groet, > > Jeroen Wunnink, > EasyHosting B.V. Systeembeheerder > systeembeheer at easyhosting.nl > > telefoon:+31 (035) 6285455 Postbus 48 > fax: +31 (035) 6838242 3755 ZG Eemnes > > http://www.easyhosting.nl > http://www.easycolocate.nl > > From mohta at necom830.hpcl.titech.ac.jp Fri Jul 17 00:56:19 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 17 Jul 2009 07:56:19 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> <20090716150822.GI26102@Space.Net> <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> <4A5F4EB8.20600@baycix.de> <4A5F769A.2040303@necom830.hpcl.titech.ac.jp> Message-ID: <4A5FB013.2010308@necom830.hpcl.titech.ac.jp> Sander Steffann wrote: > Hello Masataka, Hello. To summarize the discussion, my points are: IPv6 will not be deployed soon NAT is inevitable NAT can be harmless and I have seen no counter argument for the first two points. > The document you sent to this list is only a draft. For IPv6 deployment, there are abandoned RFCs, which means being an RFC does not mean anything, and new drafts with NAT are coming, some of which needs changes in hosts. > The chances of > getting end to end NAT globally deployed before the IPv4 address space > runs out are very close to zero, That's not my proposal, I just say "Mandating NAT", including legacy NAT, though those who want to make NAT end to end transparent may use end to end NAT or similar technologies. I heard that UPnP is supporting transparent TCP (only TCP), which seems to be, as transparent as end to end NAT, of course with host modifications. Instead, your statement mean > The chances of > getting IPv6 globally deployed before the IPv4 address space > runs out are very close to zero, or, considering technical quality of IPv6 specification, exactly zero, which means we must use IPv4 NAT. My proposal gives a way to make NAT harmless. > Also remember that we make policy for all uses of IP > addresses, not just end user networks that have/get/need a limited > amount of public addresses. These policies also apply to datacenters > where servers are hosted. There are many examples where you can not put > those servers behind a NAT box. Mandating NAT in the way you have > stated in your messages is therefore not possible. What's the rational for data centers not to reduce amount of IP address consumption by not accepting virtual servers when IPv4 address is becoming scares and IPv6 is not ready? > We are not going to change address policy in the whole RIPE region > because of a draft document that only covers a part of what addresses > are used for. See above on the consequence of your reasoning that IPv6 will not be deployed soon and NAT is inevitable, which, so far, has nothing to do with my draft. Masataka Ohta From randy at psg.com Fri Jul 17 01:04:29 2009 From: randy at psg.com (Randy Bush) Date: Fri, 17 Jul 2009 08:04:29 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <82zlb44sbr.fsf@mid.bfk.de> References: <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <82zlb44sbr.fsf@mid.bfk.de> Message-ID: >> Given that all currently available operating systems fully support IPv6, > Nit: "Full support" is neither generally available nor necessary. > IPv6 support levels are typically sufficient you're kidding, right? randy From randy at psg.com Fri Jul 17 01:09:45 2009 From: randy at psg.com (Randy Bush) Date: Fri, 17 Jul 2009 08:09:45 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> References: <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> Message-ID: ohta-san, > http://tools.ietf.org/html/draft-ohta-e2e-nat-00 while i find the draft interesting, i fear it is a bit glib. some comments from folk in our research community: to quote > For dynamic E2ENAT, a NAT gateway and end hosts must somehow > communicate, details of which is not discussed in this memo. i.e. "magic happens here" > NAT gateways may be nested. That is, a public interface of an internal > NAT gateway may be connected to a private network of an external NAT > gateway. Port numbers allocated by the external NAT gateway to the > internal NAT gateway will be further divided" this is e2e? randy From sander at steffann.nl Fri Jul 17 01:09:17 2009 From: sander at steffann.nl (Sander Steffann) Date: Fri, 17 Jul 2009 01:09:17 +0200 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <4A5FB013.2010308@necom830.hpcl.titech.ac.jp> References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> <20090716150822.GI26102@Space.Net> <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> <4A5F4EB8.20600@baycix.de> <4A5F769A.2040303@necom830.hpcl.titech.ac.jp> <4A5FB013.2010308@necom830.hpcl.titech.ac.jp> Message-ID: <78B3A8A0-78F3-494D-A3F2-A290222C1F11@steffann.nl> Hello Masataka, > What's the rational for data centers not to reduce amount of IP > address consumption by not accepting virtual servers when IPv4 > address is becoming scares and IPv6 is not ready? That is not reality. NAT can't be used in all situations and IPv6 is being deployed by both small companies and large ISPs. And we are certainly not going to forbid things like the usage of virtual servers. Again: Please stop this discussion. Sander From randy at psg.com Fri Jul 17 01:19:02 2009 From: randy at psg.com (Randy Bush) Date: Fri, 17 Jul 2009 08:19:02 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <4A5F4EB8.20600@baycix.de> References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> <20090716150822.GI26102@Space.Net> <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> <4A5F4EB8.20600@baycix.de> Message-ID: > c) don't need NAT given o ipv6 is address incompatible on the wire with ipv4 o during the transition, if it happens, we want to keep one internet, how do you do this with out 4/6 nats? randy From mohta at necom830.hpcl.titech.ac.jp Fri Jul 17 04:22:17 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 17 Jul 2009 11:22:17 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: References: <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> Message-ID: <4A5FE059.3030906@necom830.hpcl.titech.ac.jp> Randy Bush wrote: Hi, I'm told you are doing similar thing and start reading A+P. > while i find the draft interesting, i fear it is a bit glib. > some comments from folk in our research community: > to quote Thank you very much. >>For dynamic E2ENAT, a NAT gateway and end hosts must somehow >>communicate, details of which is not discussed in this memo. > i.e. "magic happens here" I haven't specified the protocol yet, merely because we have not yet implemented dynamic E2ENAT. Static E2ENAT is enough for ISPs, thus, RIPE. But, the scenario will be as follows: 1) An end host receives GW's (private?) address and (UDP?) port number to be used for dynamic NAT maybe with a supported version numbers through DHCP, PPP, UPnP etc. if there are multiple GWs, all the addresses and the port numbers are given 2) The end host (from in_pcb.c) request a port to GW The request may be retried several times after exponential time out (0.1, 0.2, 0.4, 0.8 and 1.6 second with random perturbation?) Three way handshaking may be used here to prevent DoS with a private network. If there are multiple GWs, the end host get a port number from a GW and try to reserve it with other GWs. If it fails, new port number will be tried. 3) The end host periodically (every 5 seconds with small negative random perturbasion?) send GW update messages of set of port numbers being active (even if there is no packet currently flowing on the active port) 4) GW will cancel port assignment if no update is received for a long time (30 seconds?) 5) GW recover from crash listen for update messages before starting operation port assignment may contain cookie to secure update messages Where is the magic? Note that: Depending on how port numbers are shared, there are static and dynamic E2ENAT or combinations of them. That is, an end host requiring a static port will use static E2ENAT, while the host may use dynamic E2ENAT for other purposes. >>NAT gateways may be nested. That is, a public interface of an internal >>NAT gateway may be connected to a private network of an external NAT >>gateway. Port numbers allocated by the external NAT gateway to the >>internal NAT gateway will be further divided" > this is e2e? Yes. End hosts behind an inner GW still use the shared public address. A destination address of a packet to the shared public address will be translated as follows: 1) At the source, the shared public address 2) On outer GW, a private address of outer private network assigned to the inner GW 3) Upon entry to inner GW, the shared public address 4) Before exiting from inner GW, a private address of inner private network assigned to an end host. 5) On the end host, the shared public address Steps 3) and 4) may be merged for optimization. Note that outgoing packets are not translated, because they already have source address of the shared public address. Masataka Ohta PS For detailed discussions on E2ENAT, a mailing list is provided: e2enat-en at mobile-broadband.org To join, send e2enat-en-ctl at mobile-broadband.org subscribe Your-Last-Name Your-First-Name Or, redirect me to some other mailing list. From mohta at necom830.hpcl.titech.ac.jp Fri Jul 17 04:38:49 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 17 Jul 2009 11:38:49 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <78B3A8A0-78F3-494D-A3F2-A290222C1F11@steffann.nl> References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> <20090716150822.GI26102@Space.Net> <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> <4A5F4EB8.20600@baycix.de> <4A5F769A.2040303@necom830.hpcl.titech.ac.jp> <4A5FB013.2010308@necom830.hpcl.titech.ac.jp> <78B3A8A0-78F3-494D-A3F2-A290222C1F11@steffann.nl> Message-ID: <4A5FE439.9050904@necom830.hpcl.titech.ac.jp> Sander Steffann wrote: > And we are > certainly not going to forbid things like the usage of virtual servers. I'm rather encouraging, or even trying to mandate, the use of virtual servers to share an address and a port by many entities. Masataka Ohta From trejrco at gmail.com Fri Jul 17 05:02:56 2009 From: trejrco at gmail.com (TJ) Date: Thu, 16 Jul 2009 23:02:56 -0400 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <4A5FB013.2010308@necom830.hpcl.titech.ac.jp> References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> <20090716150822.GI26102@Space.Net> <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> <4A5F4EB8.20600@baycix.de> <4A5F769A.2040303@necom830.hpcl.titech.ac.jp> <4A5FB013.2010308@necom830.hpcl.titech.ac.jp> Message-ID: <00a901ca068b$15cba990$4162fcb0$@com> "IPv6 will not be deployed soon" Brusque manner aside, I would be curious to know how you define "deployed". Is it alive, in production networks today? Yes. Are there _many_ organizations moving towards that goal? Yes. Obviously, it is not as widely deployed as IPv4 - but why should a current failing of our industry as a whole (getting IPv6 more available, sooner) encourage the yet-more-widespread use of a previous failing (loss of addresses as meaningful, unique identifiers)? Is some form of NAT going to be required - probably yes, but that is an unfortunate side-effect of the "current failing" I mentioned ... rather than being a noble goal unto itself. (For what it is worth - I have no problem with the idea of bringing some form of end-to-end'edness into NAT - whatever the mechanism, as long as it can be readily supported and doesn't pose any overwhelming security concerns of its own. I do, however, have a problem with it being forced down a network's throat. You imply that you have seen counter-arguments to "NAT can be harmless" - care to share?) /TJ >-----Original Message----- >From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- >admin at ripe.net] On Behalf Of Masataka Ohta >Sent: Thursday, July 16, 2009 6:56 PM >To: Sander Steffann >Cc: Sascha Lenz; address-policy-wg at ripe.net >Subject: Re: [address-policy-wg] Mandating NAT toward the final /8 > >Sander Steffann wrote: > >> Hello Masataka, > >Hello. To summarize the discussion, my points are: > > IPv6 will not be deployed soon > > NAT is inevitable > > NAT can be harmless > >and I have seen no counter argument for the first two points. > >> The document you sent to this list is only a draft. > >For IPv6 deployment, there are abandoned RFCs, which means being an RFC does >not mean anything, and new drafts with NAT are coming, some of which needs >changes in hosts. > >> The chances of >> getting end to end NAT globally deployed before the IPv4 address space >> runs out are very close to zero, > >That's not my proposal, I just say "Mandating NAT", including legacy NAT, >though those who want to make NAT end to end transparent may use end to end NAT >or similar technologies. > >I heard that UPnP is supporting transparent TCP (only TCP), which seems to be, >as transparent as end to end NAT, of course with host modifications. > >Instead, your statement mean > >> The chances of >> getting IPv6 globally deployed before the IPv4 address space runs out >> are very close to zero, > >or, considering technical quality of IPv6 specification, exactly zero, which >means we must use IPv4 NAT. > >My proposal gives a way to make NAT harmless. > >> Also remember that we make policy for all uses of IP addresses, not >> just end user networks that have/get/need a limited amount of public >> addresses. These policies also apply to datacenters where servers are >> hosted. There are many examples where you can not put those servers >> behind a NAT box. Mandating NAT in the way you have stated in your >> messages is therefore not possible. > >What's the rational for data centers not to reduce amount of IP address >consumption by not accepting virtual servers when IPv4 address is becoming >scares and IPv6 is not ready? > >> We are not going to change address policy in the whole RIPE region >> because of a draft document that only covers a part of what addresses >> are used for. > >See above on the consequence of your reasoning that IPv6 will not be deployed >soon and NAT is inevitable, which, so far, has nothing to do with my draft. > > Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Fri Jul 17 05:51:36 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 17 Jul 2009 12:51:36 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <00a901ca068b$15cba990$4162fcb0$@com> References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> <20090716150822.GI26102@Space.Net> <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> <4A5F4EB8.20600@baycix.de> <4A5F769A.2040303@necom830.hpcl.titech.ac.jp> <4A5FB013.2010308@necom830.hpcl.titech.ac.jp> <00a901ca068b$15cba990$4162fcb0$@com> Message-ID: <4A5FF548.30601@necom830.hpcl.titech.ac.jp> TJ wrote: > "IPv6 will not be deployed soon" > > Brusque manner aside, I would be curious to know how you define "deployed". > Is it alive, in production networks today? Yes. > Are there _many_ organizations moving towards that goal? Yes. A problem is that the answers have been "Yes." for these 10 years. > encourage the yet-more-widespread use of a previous failing (loss of > addresses as meaningful, unique identifiers)? Problem of NAT is not there. Remembering a raw IPv4 address and a port number is human, while remembering a raw IPv6 address is divine, which may be the true reason why IPv6 is not really deployed at all. :-) Masataka Ohta From bgp2 at linuxadmin.org Fri Jul 17 08:41:00 2009 From: bgp2 at linuxadmin.org (Greg) Date: Fri, 17 Jul 2009 09:41:00 +0300 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> Message-ID: <20090717064109.E7A766A017@postboy.ripe.net> It's not a bad proposal - there was a great discussion before. Arin has implemented this in their IP policy and it's been working great FOR YEARS. No wonder why we have moved two clients to Arin IP space (infrastructure end) because we were unable to meet Ripe policy requirements. You cannot get a /24 for anycast from Ripe if you cannot meet IP usage requirements, except if you are a ctld (they call it "critical infrastructure" - I don't). Why you didn't oppose "Anycasting Assignments for TLDs and Tier 0/1 ENUM" policy that allows ctld operators now to use 4x /24 for DNS anycast? It just got accepted... If you are filtering /24 routes you are filtering out "critical internet infrastructure"... hehe ;) Greg At 00:33 2009.07.17.?, you wrote: >I've ran across a couple of networks who filter on /23, in fact I did >it myself for a while while we were waiting for an upgrade. So the /24 >is just as arbitrary as any other range. > >I ain't gonna see this one fly, what people will accept for routing as >their business and shouldn't influence allocation or assignment >policy. In fact during last meeting there was quite some debate about >the fact all references to routing and/or filtering policy should be >removed from address policy documents. > >RIPE and or RIPE NCC will never guarantee routabillity for any address >range, adjusting the policy to allow a /24 just to get passed some >filters implies you get routed. > >This is a bad proposal, completely going into the wrong direction and >I won't support it, it should have been dropped years ago instead of >keeping it sleeping. > >Grtx, > >MarcoH > >On Jul 16, 2009, at 5:17 PM, Jeroen Wunnink wrote: > >>Members, >> >>I'd like to re-open the discussion for >>http://www.ripe.net/ripe/policies/proposals/2006-05.html >>which is still pending approval. >> >>In the current IPv4 address policy, routability on the internet is >>not a factor that is allowed to be taken into account when a PI >>space is requested. Yet anything smaller then a /24 is pretty much >>useless since most providers filter anything below /24 out. >> >>-- >> >>Met vriendelijke groet, >> >>Jeroen Wunnink, >>EasyHosting B.V. Systeembeheerder >>systeembeheer at easyhosting.nl >> >>telefoon:+31 (035) 6285455 Postbus 48 >>fax: +31 (035) 6838242 3755 ZG Eemnes >> >>http://www.easyhosting.nl >>http://www.easycolocate.nl >> From fweimer at bfk.de Fri Jul 17 10:06:18 2009 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 17 Jul 2009 08:06:18 +0000 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: (Randy Bush's message of "Fri\, 17 Jul 2009 08\:04\:29 +0900") References: <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <82zlb44sbr.fsf@mid.bfk.de> Message-ID: <82ws67zqbp.fsf@mid.bfk.de> * Randy Bush: >>> Given that all currently available operating systems fully support IPv6, >> Nit: "Full support" is neither generally available nor necessary. >> IPv6 support levels are typically sufficient > > you're kidding, right? The joke is in RFC 4294 (sections 4.5.4 and 8 in particular). "Full support" of IPv6 requires conformance to RFC 4294, but some of its requirements are quite ridiculous, so real-world implementations typically chose saner defaults. Obviously, I think this is a good thing, but the result is a system which doesn't fully support IPv6 as specified. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From slz at baycix.de Fri Jul 17 10:12:40 2009 From: slz at baycix.de (Sascha Lenz) Date: Fri, 17 Jul 2009 10:12:40 +0200 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> <20090716150822.GI26102@Space.Net> <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> <4A5F4EB8.20600@baycix.de> Message-ID: <4A603278.6020406@baycix.de> Hi Randy, Randy Bush schrieb: >> c) don't need NAT > > given > o ipv6 is address incompatible on the wire with ipv4 > o during the transition, if it happens, we want to keep one internet, > > how do you do this with out 4/6 nats? i'm sorry, as i tried to point out at the bottom of my the original response, this whole rant wasn't really meant 100% serious. Of course i'm aware that such things as 6to4 etc. might be called "NAT" too and might be needed indeed :-) It's just not the point of this thread, don't want to complicate it now. I think the more important thing is to show that there is little to no support for his specific approach (i hope). I just summed up some of my own point of views and exagerrated a little as a stylistic device. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From mohta at necom830.hpcl.titech.ac.jp Fri Jul 17 10:38:40 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 17 Jul 2009 17:38:40 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <82ws67zqbp.fsf@mid.bfk.de> References: <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <82zlb44sbr.fsf@mid.bfk.de> <82ws67zqbp.fsf@mid.bfk.de> Message-ID: <4A603890.7060307@necom830.hpcl.titech.ac.jp> Florian Weimer wrote: > The joke is in RFC 4294 (sections 4.5.4 and 8 in particular). My favorite joke of IPv6 is in RFC4443: (e) An ICMPv6 error message MUST NOT be originated as a result of receiving the following: (e.3) A packet destined to an IPv6 multicast address. (There are two exceptions to this rule: (1) the Packet Too Big Message (Section 3.2) to allow Path MTU discovery to work for IPv6 multicast, and (2) the Parameter Problem Message, Code 2 You can send a 1500B packet with a forged source address of DDoS target to a multicast group with huge number of receivers using PPPoE at their last hops. As for feedback, I warned IPv6 WG about the problem, twice. Some sane people will completely disable and filter out "Packet Too Big Message"s including those against unicast packets. And there should be other jokes not all of which is recognized by operators. Masataka Ohta From gert at space.net Fri Jul 17 10:41:50 2009 From: gert at space.net (Gert Doering) Date: Fri, 17 Jul 2009 10:41:50 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090717064109.E7A766A017@postboy.ripe.net> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <20090717064109.E7A766A017@postboy.ripe.net> Message-ID: <20090717084150.GR26102@Space.Net> Hi, On Fri, Jul 17, 2009 at 09:41:00AM +0300, Greg wrote: > It's not a bad proposal - there was a great discussion before. Having "great discussions" doesn't necessarily make it a *good* proposal either. The amount of discussions and mixed feedback we have seen tells me that we have no consenus yet to go forward with this proposal (not even "very rough"). I have on my TODO list to go through the PI numbers that Alex has posted and try to figure out how "real" this percieved problem is *today*, and then we can go forward with less emotional and more educated discussion. regards, Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From mohta at necom830.hpcl.titech.ac.jp Fri Jul 17 10:49:28 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 17 Jul 2009 17:49:28 +0900 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <4A603278.6020406@baycix.de> References: <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <4A5F4036.5040109@necom830.hpcl.titech.ac.jp> <20090716150822.GI26102@Space.Net> <4A5F4C59.4030700@necom830.hpcl.titech.ac.jp> <4A5F4EB8.20600@baycix.de> <4A603278.6020406@baycix.de> Message-ID: <4A603B18.3060103@necom830.hpcl.titech.ac.jp> Sascha Lenz wrote: >>> c) don't need NAT > Of course i'm aware that such things as 6to4 etc. might be called "NAT" too and might be needed indeed :-) > It's just not the point of this thread, don't want to complicate it now. I'm afraid it's you who wrote: >>> b) don't like NAT >>> c) don't need NAT >>> d) don't use NAT > I think the more important thing is to show that there is little to no > support for his specific approach (i hope). My apprach is to accept NAT, including legacy ones. Note that, as is described in the ID, end to end NAT can and will be upper compatible to legacy NAT with ISP and user opt-in. If both GW and an end host deploy end to end NAT, the host can enjoy full end to end transparency. Otherwise, the host is as if it is behind legacy NAT. Masataka Ohta From Keith.Nolan at premiereglobal.ie Fri Jul 17 13:05:26 2009 From: Keith.Nolan at premiereglobal.ie (Nolan, Keith) Date: Fri, 17 Jul 2009 12:05:26 +0100 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090717084150.GR26102@Space.Net> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <20090717064109.E7A766A017@postboy.ripe.net> <20090717084150.GR26102@Space.Net> Message-ID: <92C3E3DCDFBEC944AD871B8041E89EA502465627@iesem04.Europe.premconf.com> I believe the proposal has great merit and needs further discussion, and is directly related to my email on the 12th July. "The other issue with suggesting that we use PI Space instead of PA Space where we will not be in a position to aggregate is the PI Assignment which would be approved would be less than a /24 (as we don't need 128 addresses for Multi-homed BGP Peering), therefore wouldn't be routable on the Internet (Policy proposal 2006-05 refers to this issue and suggests the smallest PI Space should be /24) So the only way to implement Multi-Homed BGP Routing from Multiple locations which don't need a full /24 network is to become a LIR and create smaller /25 or /26 inetnum's with larger /24 route objects from your PA Space. And since this is a workaround, just like a company stretching the truth about their IP requirements when applying for a PI Space to get a full /24, surely a LIR should be allowed to create inetnum's for a /24 when they also need to create a /24 route object." And while all transits may not route a /24 IP Range, the Tier1 transits we are paying for transit do route /24 networks, but are filtering anything smaller. Keith -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Gert Doering Sent: 17 July 2009 09:42 To: Greg Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 Hi, On Fri, Jul 17, 2009 at 09:41:00AM +0300, Greg wrote: > It's not a bad proposal - there was a great discussion before. Having "great discussions" doesn't necessarily make it a *good* proposal either. The amount of discussions and mixed feedback we have seen tells me that we have no consenus yet to go forward with this proposal (not even "very rough"). I have on my TODO list to go through the PI numbers that Alex has posted and try to figure out how "real" this percieved problem is *today*, and then we can go forward with less emotional and more educated discussion. regards, Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From mark at streamservice.nl Fri Jul 17 13:48:01 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Fri, 17 Jul 2009 13:48:01 +0200 Subject: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space In-Reply-To: References: <4A5DC542.4050908@easyhosting.nl> <4A5DFC74.4030504@ripe.net> <4A5EDE20.1080609@easyhosting.nl> <4A5F210D.1020200@easyhosting.nl> <016801ca0615$266518c0$732f4a40$@nl> Message-ID: <000a01ca06d4$701024a0$50306de0$@nl> Hello Sander, Thank you for the clear reply. If I combine this with other things on the mailing list in the last 3 weeks I agree with you that it is better to request a /21 range (you get it when you become a LIR) compared to a /24 (PI) if you just need a /24. This is clearly the best way to conserve IPv4 address space. With kind regards, Mark Scholten -----Original Message----- From: Sander Steffann [mailto:sander at steffann.nl] Sent: donderdag 16 juli 2009 22:01 To: Stream Service || Mark Scholten Cc: address-policy-wg at ripe.net Subject: Re: Complaint: Overly complicated when requesting PI space Hello Mark, > If you ask me it should be allowed to use PI space for clients (and > give > clients the option to use/maintain more than a /30 (IPv4)). PI policy explicitly states that PI space can not be re-assigned or further assigned to other parties. See http://www.ripe.net/ripe/docs/ripe-471.html#9 . Any organisation that needs address space for its customers must use PA space. The definition of an LIR is that it assigns address space to its customers. PI space is (per definition) only to be used by the company that requested it itself. > It is also in my > opinion not to RIPE (community or the NCC) to ask that information. > The > should ask for general usage, how much would be used for clients for > example. How many clients a company has shouldn't be important to > get PI. In this case it doesn't matter. That the company needs address space for *any* customers indicates that PI space is not appropriate and PA space should be used. The company uses address space for customers and therefore must become an LIR. I think it is now time to stop this discussion, at least on the address policy mailing list. This discussion is not leading to a viable policy proposal. Thanks, Sander Steffann APWG co-chair From remco.vanmook at eu.equinix.com Fri Jul 17 13:54:20 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Fri, 17 Jul 2009 13:54:20 +0200 Subject: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space In-Reply-To: <000a01ca06d4$701024a0$50306de0$@nl> Message-ID: Hi Mark, It is heartening to see that your drive to conservation of IPv4 space alone is pushing you to put all this effort in to get PI space. I?m sure we can suggest a policy change approved that would set the standard initial allocation to /21 but allow for smaller allocations up to /24 if specifically requested by the new LIR. Best, Remco On 17-07-09 13:48, "Stream Service || Mark Scholten" wrote: > Hello Sander, > > Thank you for the clear reply. If I combine this with other things on the > mailing list in the last 3 weeks I agree with you that it is better to > request a /21 range (you get it when you become a LIR) compared to a /24 > (PI) if you just need a /24. This is clearly the best way to conserve IPv4 > address space. > > With kind regards, > > Mark Scholten > > -----Original Message----- > From: Sander Steffann [mailto:sander at steffann.nl] > Sent: donderdag 16 juli 2009 22:01 > To: Stream Service || Mark Scholten > Cc: address-policy-wg at ripe.net > Subject: Re: Complaint: Overly complicated when requesting PI space > > Hello Mark, > >> > If you ask me it should be allowed to use PI space for clients (and >> > give >> > clients the option to use/maintain more than a /30 (IPv4)). > > PI policy explicitly states that PI space can not be re-assigned or > further assigned to other parties. See > http://www.ripe.net/ripe/docs/ripe-471.html#9 > . Any organisation that needs address space for its customers must use > PA space. The definition of an LIR is that it assigns address space to > its customers. PI space is (per definition) only to be used by the > company that requested it itself. > >> > It is also in my >> > opinion not to RIPE (community or the NCC) to ask that information. >> > The >> > should ask for general usage, how much would be used for clients for >> > example. How many clients a company has shouldn't be important to >> > get PI. > > In this case it doesn't matter. That the company needs address space > for *any* customers indicates that PI space is not appropriate and PA > space should be used. The company uses address space for customers and > therefore must become an LIR. > > I think it is now time to stop this discussion, at least on the > address policy mailing list. This discussion is not leading to a > viable policy proposal. > > Thanks, > Sander Steffann > APWG co-chair > > > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. -------------- next part -------------- An HTML attachment was scrubbed... URL: From slz at baycix.de Fri Jul 17 14:02:15 2009 From: slz at baycix.de (Sascha Lenz) Date: Fri, 17 Jul 2009 14:02:15 +0200 Subject: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space In-Reply-To: References: Message-ID: <4A606847.3040105@baycix.de> Hi, Remco van Mook schrieb: > > Hi Mark, > > It is heartening to see that your drive to conservation of IPv4 space > alone is pushing you to put all this effort in to get PI space. I?m sure > we can suggest a policy change approved that would set the standard > initial allocation to /21 but allow for smaller allocations up to /24 if > specifically requested by the new LIR. [...] ... apart from the fact that i don't think the whole community agrees that we need any form of IPv4 conservation anyways :-) ... i think this would be the apropriate step here, yes. I would support a more "floating" (first) allocation policy, because even that i think that we don't need to conserve IPv4 space too much, i also don't think that we need to waste it either if there are other simple options like what you suggest (smaller Allocation on request or so). -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From Woeber at CC.UniVie.ac.at Fri Jul 17 15:27:25 2009 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 17 Jul 2009 13:27:25 +0000 Subject: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space In-Reply-To: <4A606847.3040105@baycix.de> References: <4A606847.3040105@baycix.de> Message-ID: <4A607C3D.1080609@CC.UniVie.ac.at> Sascha Lenz wrote: [...] > I would support a more "floating" (first) allocation policy, because > even that i think that we don't need to conserve IPv4 space too much, i > also don't think that we need to waste it either if there are other > simple options like what you suggest (smaller Allocation on request or so). While it may be an intersting idea in light of conservation, there's a good operational reason why all the LIR Allocations are of equal (minimum) size: filtering on prefix length. :-) Wilfried. From niels=apwg at bakker.net Fri Jul 17 18:45:04 2009 From: niels=apwg at bakker.net (Niels Bakker) Date: Fri, 17 Jul 2009 18:45:04 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <92C3E3DCDFBEC944AD871B8041E89EA502465627@iesem04.Europe.premconf.com> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <20090717064109.E7A766A017@postboy.ripe.net> <20090717084150.GR26102@Space.Net> <92C3E3DCDFBEC944AD871B8041E89EA502465627@iesem04.Europe.premconf.com> Message-ID: <20090717164504.GG19797@burnout.tpb.net> * Keith.Nolan at premiereglobal.ie (Nolan, Keith) [Fri 17 Jul 2009, 13:06 CEST]: >I believe the proposal has great merit and needs further discussion, and >is directly related to my email on the 12th July. > > >"The other issue with suggesting that we use PI Space instead of PA >Space where we will not be in a position to aggregate is the PI >Assignment which would be approved would be less than a /24 (as we don't >need 128 addresses for Multi-homed BGP Peering), therefore wouldn't be >routable on the Internet (Policy proposal 2006-05 refers to this issue >and suggests the smallest PI Space should be /24) So the only way to >implement Multi-Homed BGP Routing from Multiple locations which don't >need a full /24 network is to become a LIR and create smaller /25 or /26 >inetnum's with larger /24 route objects from your PA Space. And since >this is a workaround, just like a company stretching the truth about >their IP requirements when applying for a PI Space to get a full /24, >surely a LIR should be allowed to create inetnum's for a /24 when they >also need to create a /24 route object." > >And while all transits may not route a /24 IP Range, the Tier1 transits >we are paying for transit do route /24 networks, but are filtering >anything smaller. The RIPE NCC hands out addresses based on a need for addresses, not on a need to satisfy other parties' policies. This is a good thing and it should stay that way. -- Niels. -- zo weten we nog steeds niet of de steganosaurus wel echt bestaan heeft From randy at psg.com Fri Jul 17 19:48:44 2009 From: randy at psg.com (Randy Bush) Date: Fri, 17 Jul 2009 10:48:44 -0700 Subject: [address-policy-wg] Mandating NAT toward the final /8 In-Reply-To: <82ws67zqbp.fsf@mid.bfk.de> References: <75822E125BCB994F8446858C4B19F0D77B1A8509@SUEX07-MBX-04.ad.syr.edu> <4A528079.1030905@inex.ie> <4A52B434.D7CAF418@ix.netcom.com> <20090708083728.GS26102@Space.Net> <4A54A33C.9060401@necom830.hpcl.titech.ac.jp> <20090708205349.GD26102@Space.Net> <4A552018.9030407@necom830.hpcl.titech.ac.jp> <4A5F2F27.4040005@necom830.hpcl.titech.ac.jp> <20090716141738.GG26102@Space.Net> <82zlb44sbr.fsf@mid.bfk.de> <82ws67zqbp.fsf@mid.bfk.de> Message-ID: >>>> Given that all currently available operating systems fully support IPv6, >>> Nit: "Full support" is neither generally available nor necessary. >>> IPv6 support levels are typically sufficient > > you're kidding, right? > The joke is in RFC 4294 (sections 4.5.4 and 8 in particular). no. the joke is macosx, winxp, ... the normal human being plugging them into an ipv6 network is not gonna get usable connectivity. randy From mueller at syr.edu Mon Jul 20 10:38:56 2009 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 20 Jul 2009 04:38:56 -0400 Subject: [address-policy-wg] Spectrum and IP address reservations Message-ID: <75822E125BCB994F8446858C4B19F0D77B233EF6@SUEX07-MBX-04.ad.syr.edu> I forward information about a study conducted by NERA on spectrum auctions. Not directly applicable to IP addresses, but has some relevance to current discussions about attempts to reserve resources for new entrants vs. incumbents. Bear in mind, of course, that the study was produced by Telus, an incumbent operator, and discount for that; the point is that we need to pay attention to the economic reasoning underlying the finding; which is that policies designed to "help" competitors can have unintended consequences that may encourage conslidation and higher prices. ________________________________ Dear ITS Colleague, As you know, Industry Canada completed Canada?s advanced wireless services (AWS) spectrum auction in July 2008. A recent study that NERA conducted for the Canadian telecommunications company TELUS analyzed the auction, and found that it may have been distorted by the insertion of incompatible regulatory goals into the auction process. NERA?s analysis showed that while the auction generated higher revenues than expected, the most important reason for this was due to arbitrage opportunities in the auction design generated by the regulator?s decision to set-aside 44 percent of the available spectrum for ?entrants? which, as defined, were as all qualified bidders except the three largest incumbent mobile operators. As evidenced in the UK 3G and other 3G auctions in the early 2000s, the resulting inflated spectrum prices can negatively affect competition as investors tend to sell their holdings when earnings decrease and/or debt ratings drop. In severe cases, it can lead to market exit or market consolidation, all of which has a direct effect on competition. Our report urges regulators to carefully balance the costs and benefits of regulatory intervention, and includes suggestions for avoiding the problems in future auctions that we identified in the Canadian case. The report is available for free upon request at: www.nera.com . [snip] _______________________________ Christian Dippon Vice President NERA Economic Consulting One Front Street, Suite 2600 San Francisco, CA 94111 Tel: 1-415-291-1044, Fax: 1-415-291-1020 Mobile: 415-810-9246 Christian.Dippon at NERA.com www.nera.com www.telecomeconomics.com _______________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From Keith.Nolan at premiereglobal.ie Mon Jul 20 11:19:58 2009 From: Keith.Nolan at premiereglobal.ie (Nolan, Keith) Date: Mon, 20 Jul 2009 10:19:58 +0100 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090717164504.GG19797@burnout.tpb.net> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <20090717064109.E7A766A017@postboy.ripe.net> <20090717084150.GR26102@Space.Net> <92C3E3DCDFBEC944AD871B8041E89EA502465627@iesem04.Europe.premconf.com> <20090717164504.GG19797@burnout.tpb.net> Message-ID: <92C3E3DCDFBEC944AD871B8041E89EA50246572F@iesem04.Europe.premconf.com> On the RIPE Website regarding the Ripe Community "RIPE (R?seaux IP Europ?ens) is a collaborative forum open to all parties interested in wide area IP networks. The objective of RIPE is to ensure the administrative and technical co-ordination necessary to enable the operation of the Internet within the RIPE region." I believe the RIPE community has a requirement to set policy to ensure the IP's which RIPE NCC handout based on need, meet the administrative and technical requirements to be usable on the internet, and if that means a /24 is the smallest IPv4 space which can't be aggregated is allowed to be handed out, due to standard industry practice of filtering anything smaller than a /24 or if it means we influence standard practice to have smaller IPv4 space not filtered and increasing the size of the routing tables, I think we need to provide RIPE NCC with clear guidelines to help them meet the communities objective. Keith -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Niels Bakker Sent: 17 July 2009 17:45 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 * Keith.Nolan at premiereglobal.ie (Nolan, Keith) [Fri 17 Jul 2009, 13:06 CEST]: >I believe the proposal has great merit and needs further discussion, and >is directly related to my email on the 12th July. > > >"The other issue with suggesting that we use PI Space instead of PA >Space where we will not be in a position to aggregate is the PI >Assignment which would be approved would be less than a /24 (as we don't >need 128 addresses for Multi-homed BGP Peering), therefore wouldn't be >routable on the Internet (Policy proposal 2006-05 refers to this issue >and suggests the smallest PI Space should be /24) So the only way to >implement Multi-Homed BGP Routing from Multiple locations which don't >need a full /24 network is to become a LIR and create smaller /25 or /26 >inetnum's with larger /24 route objects from your PA Space. And since >this is a workaround, just like a company stretching the truth about >their IP requirements when applying for a PI Space to get a full /24, >surely a LIR should be allowed to create inetnum's for a /24 when they >also need to create a /24 route object." > >And while all transits may not route a /24 IP Range, the Tier1 transits >we are paying for transit do route /24 networks, but are filtering >anything smaller. The RIPE NCC hands out addresses based on a need for addresses, not on a need to satisfy other parties' policies. This is a good thing and it should stay that way. -- Niels. -- zo weten we nog steeds niet of de steganosaurus wel echt bestaan heeft From tvest at eyeconomics.com Mon Jul 20 13:28:19 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Mon, 20 Jul 2009 07:28:19 -0400 Subject: [address-policy-wg] Spectrum and IP address reservations Message-ID: On Jul 20, 2009, at 4:38 AM, Milton L Mueller wrote: > I forward information about a study conducted by NERA on spectrum > auctions. > Not directly applicable to IP addresses, but has some relevance to > current discussions about attempts to reserve resources for new > entrants vs. incumbents. Bear in mind, of course, that the study was > produced by Telus, an incumbent operator, and discount for that; the > point is that we need to pay attention to the economic reasoning > underlying the finding; which is that policies designed to "help" > competitors can have unintended consequences that may encourage > conslidation and higher prices. Hi Milton, Clarifying question: what are you referring to exactly by "policies designed to 'help' competitors," and why are you choosing to reduce the question of routing and addressing system openness to this one narrow dimension? I (among others) have written a lot about the importances of keeping the door open for "new entrants," but not all new entrants are "competitors" -- nor is competition the only reason for incumbent service providers (and everybody else) to regard such openness as a critical institutional priority. To illustrate, I've never heard anyone claim that the *only* reason why it was a good idea to move from NCP addressing to classful IP was to enable competition. Ditto, the move from classful IP to CIDR; then as before, the prospect of continuous competition (including competition by emerging new entrants) was just one of many reasons to support the preservation of addressing and routing system openness. I'm assuming that whatever you find persuasive in this NERA document would not also implicate those past policy choices, because I don't think you'd find much sympathy for the idea that the "unintended consequences" of those decisions were/are so bad that they outweigh they *intended* consequences (i.e., a future with max. 256 independent addressing and routing system participants). Since most of the subscribers to these lists are not economists, it would be helpful if you could briefly summarize the "underlying economic reasoning" that you find particularly compelling in this study. If it was less onerous, I'd also request that you clarify what you regard to be the right way to balance intended vs. unintended policy choices, and "historically/experientially informed" vs. "idealized, theoretically informed" expectations about the future -- but perhaps a sentence or two of clarification on the NERA "reasoning" would suffice. Thanks, TV From drc at virtualized.org Mon Jul 20 19:49:17 2009 From: drc at virtualized.org (David Conrad) Date: Mon, 20 Jul 2009 10:49:17 -0700 Subject: [address-policy-wg] Spectrum and IP address reservations In-Reply-To: References: Message-ID: <89555A95-DD99-48B5-8E0F-9A8B83D69FA6@virtualized.org> Tom, On Jul 20, 2009, at 4:28 AM, tvest at eyeconomics.com wrote: > To illustrate, I've never heard anyone claim that the *only* reason > why it was a good idea to move from NCP addressing to classful IP > was to enable competition. I would be quite surprised if any of the participants in that transition even considered competition as a reason. > Ditto, the move from classful IP to CIDR; then as before, the > prospect of continuous competition (including competition by > emerging new entrants) was just one of many reasons to support the > preservation of addressing and routing system openness. Err, a bit too much revisionism here. I don't recall anyone suggesting "continuous competition" as a reason for moving from classfull to CIDR. In fact, CIDR was often and loudly criticized for constraining competition due to the implied provider lock in. As far as I remember, people pushing the transition were primarily interested in keeping their routers from falling over. CIDR was merely a short term hack to deal with the proliferation of class Cs being allocated since class Bs were running out. After all, IPng was going to be the savior of all things routing. I suppose you could argue that keeping the Internet working meant there could be competition, but that's stretching things a bit far IMHO. Regards, -drc From tvest at eyeconomics.com Mon Jul 20 20:53:51 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Mon, 20 Jul 2009 14:53:51 -0400 Subject: [address-policy-wg] Spectrum and IP address reservations In-Reply-To: <89555A95-DD99-48B5-8E0F-9A8B83D69FA6@virtualized.org> References: <89555A95-DD99-48B5-8E0F-9A8B83D69FA6@virtualized.org> Message-ID: On Jul 20, 2009, at 1:49 PM, David Conrad wrote: > Tom, > > On Jul 20, 2009, at 4:28 AM, tvest at eyeconomics.com wrote: >> To illustrate, I've never heard anyone claim that the *only* reason >> why it was a good idea to move from NCP addressing to classful IP >> was to enable competition. > > I would be quite surprised if any of the participants in that > transition even considered competition as a reason. > >> Ditto, the move from classful IP to CIDR; then as before, the >> prospect of continuous competition (including competition by >> emerging new entrants) was just one of many reasons to support the >> preservation of addressing and routing system openness. > > Err, a bit too much revisionism here. > > I don't recall anyone suggesting "continuous competition" as a > reason for moving from classfull to CIDR. In fact, CIDR was often > and loudly criticized for constraining competition due to the > implied provider lock in. As far as I remember, people pushing the > transition were primarily interested in keeping their routers from > falling over. CIDR was merely a short term hack to deal with the > proliferation of class Cs being allocated since class Bs were > running out. After all, IPng was going to be the savior of all > things routing. > > I suppose you could argue that keeping the Internet working meant > there could be competition, but that's stretching things a bit far > IMHO. Hi David, Thanks for the response. I actually agree -- probably should have written that competition was never more than one of many reasons that someone (anyone) *might have* supported those earlier transitions. That said, if you look back at my original response you'll note that I was actually arguing *against* transition rationales based narrowly on "competition" questions. The alternative that I proposed was transition to preserve the "openness of the internet addressing and routing system," especially to new entrants. I think that the majority of reasons for supporting the previous transitions (i.e., previous impositions of new technical requirements on incumbent network operators), as well as for supporting IPv6, would fit neatly under this rubric. And while your own description of the past circumstances didn't use those specific terms, I believe that the phenomena of "proliferation of class Cs being allocated" and "class Bs running out" that you referred to were both driven in part by demand from initial allocation seekers, a.k.a. "new entrants" -- i.e., we agree on this point. Of course, during any given duration the majority of newly allocated/ assigned IP addresses are probably going to "incumbents" (subsequent allocation seekers), but that's consistent with patterns of growth in every other industry, i.e., it's basically a demographic of statistical artifact of cumulative growth processes (granted, one that can be influenced by various policies). The important distinction, at least until now, is that the growth/IP addressing demand of incumbents was not incompatible with the continued openness of the addressing and routing system to non-incumbents/new entrants. And of course, I wouldn't have expected these sorts of arguments to figure prominently in IETF et al. meetings and discussion back in the 1980s-1990s. In the main, we're not a bunch of economists and policy makers by profession -- and even those of us who are generally know better than to phrase our technology and policy advocacy in such alien and unsympathetic terms... most of us anyway. However, even if "openness of the internet addressing and routing system" was never the most popular/resonant rallying cry for specific technology changes, that doesn't mean that this general idea wasn't an important motivator or an influential part of the unspoken context. And even if that sounds implausible too, it still doesn't mean that the *fact* that such openness was preserved, intentionally or otherwise, didn't play an important role in the success of the system to date. Although the verdict of history is never truly final, to me industry openness looks a lot like a universal correlate (i.e., a necessary if not sufficient cause) behind the durability of industry self-governance. If that turns out to be true, then there could be a lot more at stake in the current transition tussle than just the fate of the IP address registries. Regards, TV From lear at cisco.com Tue Jul 21 11:04:48 2009 From: lear at cisco.com (Eliot Lear) Date: Tue, 21 Jul 2009 11:04:48 +0200 Subject: [address-policy-wg] Spectrum and IP address reservations In-Reply-To: References: <89555A95-DD99-48B5-8E0F-9A8B83D69FA6@virtualized.org> Message-ID: <4A6584B0.5060808@cisco.com> Hi Tom, > Thanks for the response. I actually agree -- probably should have > written that competition was never more than one of many reasons that > someone (anyone) *might have* supported those earlier transitions. > That said, if you look back at my original response you'll note that I > was actually arguing *against* transition rationales based narrowly on > "competition" questions. The alternative that I proposed was > transition to preserve the "openness of the internet addressing and > routing system," especially to new entrants. Sure! I particularly like the idea, for instance, of using LISP or other similar technology to enable end systems to move within the topology without having to pollute the global BGP table. But I do feel a Hal Varien moment coming on: are incentives aligned for the right things to happen? If not, can they be so aligned? Our earlier work pointed out that there is a limit to the efficacy of RIR policies. So what tools do we really have? Again, returning to the LISP example, it's a technology advance that is a potential Over-The-Top play that could align interests (not that I've done the analysis, but that's my off-the-cuff thought, something to be wary about). > I think that the majority of reasons for supporting the previous > transitions (i.e., previous impositions of new technical requirements > on incumbent network operators), as well as for supporting IPv6, would > fit neatly under this rubric. And while your own description of the > past circumstances didn't use those specific terms, I believe that the > phenomena of "proliferation of class Cs being allocated" and "class Bs > running out" that you referred to were both driven in part by demand > from initial allocation seekers, a.k.a. "new entrants" -- i.e., we > agree on this point. > > Of course, during any given duration the majority of newly > allocated/assigned IP addresses are probably going to "incumbents" > (subsequent allocation seekers), but that's consistent with patterns > of growth in every other industry, i.e., it's basically a demographic > of statistical artifact of cumulative growth processes (granted, one > that can be influenced by various policies). The important > distinction, at least until now, is that the growth/IP addressing > demand of incumbents was not incompatible with the continued openness > of the addressing and routing system to non-incumbents/new entrants. > > And of course, I wouldn't have expected these sorts of arguments to > figure prominently in IETF et al. meetings and discussion back in the > 1980s-1990s. In the main, we're not a bunch of economists and policy > makers by profession -- and even those of us who are generally know > better than to phrase our technology and policy advocacy in such alien > and unsympathetic terms... most of us anyway. Well but as you know there were some discussions along these lines in the CIDRD/BGPD working groups. However, there are limits as to how far those discussions can reasonably go in that forum. One thing I would draw your attention to was a paper in this year's WEIS conference by Richard Clayton that contains an economic analysis of SHIM6. His parting question from his presentation was whether RFCs should contain Economics Considerations sections. > However, even if "openness of the internet addressing and routing > system" was never the most popular/resonant rallying cry for specific > technology changes, that doesn't mean that this general idea wasn't an > important motivator or an influential part of the unspoken context. > And even if that sounds implausible too, it still doesn't mean that > the *fact* that such openness was preserved, intentionally or > otherwise, didn't play an important role in the success of the system > to date. Although the verdict of history is never truly final, to me > industry openness looks a lot like a universal correlate (i.e., a > necessary if not sufficient cause) behind the durability of industry > self-governance. If that turns out to be true, then there could be a > lot more at stake in the current transition tussle than just the fate > of the IP address registries. I don't think anyone can deny that openness was an important motivator for Internet technologies. We merely need to look at all of the OTHER protocols that have gone by the wayside to see that it is so. But I think what we saw was that Opennness was something to be capitalized upon by one group of vendors, to entice customers, and to disrupt certain market players. It certainly was not regulated. And indeed if we look at security and authentication technology, the desire to play King of the Mountain has IMHO long stalled improvements in consumer authentication. Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane at time-travellers.org Tue Jul 21 13:44:08 2009 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 21 Jul 2009 13:44:08 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <4A5F7AB3.1020700@futureinquestion.net> References: <4A5F3EE9.1070603@ripe.net> <4A5F7AB3.1020700@futureinquestion.net> Message-ID: <1248176648.4763.3345.camel@shane-asus-laptop> David, On Thu, 2009-07-16 at 21:08 +0200, David Monosov wrote: > Dear ncc-services-wg, address-policy-wg, > > From the document: > > [...] > > 4.2 Violation of RIPE Policy, Law or Contract > > The RIPE NCC will de-register the independent Internet number resources in case > of a fundamental breach of contract by the End User, supported by a Dutch court > order; or > > Violation of Law by the End User, supported by a Dutch court order; or violation > of RIPE Policy by the End User. > > [...] > > IANAL, so please forgive me if this course of inquiry is completely misguided, > but does this not explicitly put the validity of resource assignments in the > hands of Dutch courts and Dutch prosecutors? > > RIPE NCC, as an organization domiciled in the Netherlands would at all times > have to comply with valid court orders. However, prior to the existence of a > direct contractual relationship with end users and this policy, RIPE NCC merely > served as a custodian for a database. Challenging the contents of this database > would have been a legal adventure. > > With the introduction of complete contractual chain through RIPE NCC, a LIR, and > the end user, combined with this formal explicit policy to which the end user > and the LIR must agree - isn't there a potential loophole being created for an > enterprising litigant to impose Dutch legislation where it is might be favorable > to their cause on foreign end users? > > Certainly, if this interpretation isn't overly naive, such a loophole was not > the intention of policy 2007-01. Has the RIPE NCC received any legal counseling > on this matter, and would it be willing to publish the opinion they were > provided with? All that this says is that the RIPE NCC is bound by Dutch law, which was always the case, with or without a contract. Someone could always take the RIPE NCC to court, in the Netherlands or in any other jurisdiction on the planet that will accept the case. Remember, the point of this endeavor is to identify who is responsible for any given assignment. This should result in less legal pain, not more. -- Shane From shane at time-travellers.org Tue Jul 21 13:44:08 2009 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 21 Jul 2009 13:44:08 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <4A5F7AB3.1020700@futureinquestion.net> References: <4A5F3EE9.1070603@ripe.net> <4A5F7AB3.1020700@futureinquestion.net> Message-ID: <1248176648.4763.3345.camel@shane-asus-laptop> David, On Thu, 2009-07-16 at 21:08 +0200, David Monosov wrote: > Dear ncc-services-wg, address-policy-wg, > > From the document: > > [...] > > 4.2 Violation of RIPE Policy, Law or Contract > > The RIPE NCC will de-register the independent Internet number resources in case > of a fundamental breach of contract by the End User, supported by a Dutch court > order; or > > Violation of Law by the End User, supported by a Dutch court order; or violation > of RIPE Policy by the End User. > > [...] > > IANAL, so please forgive me if this course of inquiry is completely misguided, > but does this not explicitly put the validity of resource assignments in the > hands of Dutch courts and Dutch prosecutors? > > RIPE NCC, as an organization domiciled in the Netherlands would at all times > have to comply with valid court orders. However, prior to the existence of a > direct contractual relationship with end users and this policy, RIPE NCC merely > served as a custodian for a database. Challenging the contents of this database > would have been a legal adventure. > > With the introduction of complete contractual chain through RIPE NCC, a LIR, and > the end user, combined with this formal explicit policy to which the end user > and the LIR must agree - isn't there a potential loophole being created for an > enterprising litigant to impose Dutch legislation where it is might be favorable > to their cause on foreign end users? > > Certainly, if this interpretation isn't overly naive, such a loophole was not > the intention of policy 2007-01. Has the RIPE NCC received any legal counseling > on this matter, and would it be willing to publish the opinion they were > provided with? All that this says is that the RIPE NCC is bound by Dutch law, which was always the case, with or without a contract. Someone could always take the RIPE NCC to court, in the Netherlands or in any other jurisdiction on the planet that will accept the case. Remember, the point of this endeavor is to identify who is responsible for any given assignment. This should result in less legal pain, not more. -- Shane From tvest at eyeconomics.com Tue Jul 21 22:28:00 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Tue, 21 Jul 2009 16:28:00 -0400 Subject: [address-policy-wg] Spectrum and IP address reservations In-Reply-To: <4A6584B0.5060808@cisco.com> References: <89555A95-DD99-48B5-8E0F-9A8B83D69FA6@virtualized.org> <4A6584B0.5060808@cisco.com> Message-ID: <1F6404CD-A0B2-42D4-A849-ED5E9F9D89E5@eyeconomics.com> On Jul 21, 2009, at 5:04 AM, Eliot Lear wrote: > Hi Tom, > >> Thanks for the response. I actually agree -- probably should have >> written that competition was never more than one of many reasons >> that someone (anyone) *might have* supported those earlier >> transitions. That said, if you look back at my original response >> you'll note that I was actually arguing *against* transition >> rationales based narrowly on "competition" questions. The >> alternative that I proposed was transition to preserve the >> "openness of the internet addressing and routing system," >> especially to new entrants. > > Sure! I particularly like the idea, for instance, of using LISP or > other similar technology to enable end systems to move within the > topology without having to pollute the global BGP table. But I do > feel a Hal Varien moment coming on: are incentives aligned for the > right things to happen? Hi Eliot, [note well: what follows represents personal opinion** only] Thanks for (re) injecting these questions. On the "Hal question," I interpret the current state of affairs as as a weak indicator that incentives are on balance (i.e., far from perfectly) aligned. That said, I would never have allowed myself to get stuck in this rather uncomfortable position if I believed that that balance of incentives were actually aligned toward a sustainable outcome. > If not, can they be so aligned? Our earlier work pointed out that > there is a limit to the efficacy of RIR policies. So what tools do > we really have? Incentive alignment might qualify as a "normal" engineering challenge under other circumstances. In this case the task is abnormally complicated by (a) the apparent absence of strong internal consensus** or other means of identifying the common goal, and also by (b) the absence of half of the engineering tool box (i.e., all carrots, no sticks -- and while our carrots may be very nutritious, no one has ever accused them of being irresistibly delicious). Ideally, our unique community decision making (aka consensus-seeking) mechanism would provide a means for overcoming these challenges, by providing a forum where contending views on both policy means and policy ends are exposed to cross-examination. However, in this case, I have a feeling** that only one side of the debate is actually being presented openly. If we were to take the decreasing frequency of open, public objections to IPv6 transition/integration as a de facto indication of support for such a move (which seems to be a common feature of the consensus-seeking process, at least toward the end stages of policy development), my guess is that we'd probably expect the transition to be much further long, and to be happening at a much faster, and at a more rapidly accelerating pace than available evidence would seem to suggest. So, am I just fundamentally wrong on some point of fact or interpretation, or it is possible that some unknown share of the apparently widespread non-objection (i.e., the proverbial "dogs that don't bark") actually reflect some (equally unknown) number of unannounced decisions in favor of non-transition? I don't even pretend to know the answer. But my doubts have prompted me to take what seems to be the most institutionally appropriate action -- to capitalize on the one good (and perhaps unique) "tool" that we do possess, i.e., to use our community deliberative mechanisms to try to present a positive case *for* a timely and orderly transition. Though I may be lacking in the skills required to wield them effectively, for now they remain the best (maybe only) tools that I have at my disposal. > Again, returning to the LISP example, it's a technology advance that > is a potential Over-The-Top play that could align interests (not > that I've done the analysis, but that's my off-the-cuff thought, > something to be wary about). I think that this possibility merits much more thorough and systematic consideration. My (quite possibly under-informed) impression is that widespread adoption of LISP might improve matters substantially in several ways, e.g., (1) by providing the majority of origin-only/self- service routing providers with an opportunity to economize by vacating the DFZ, (2) by reducing the likely ongoing demand for DFZ participation (and al that that implies in terms of RIB/FIB scalability) by permanently eliminating such participation as an involuntary requirement for self-service routing providers, and (3) by reducing the impediments to renumbering, which hypothetically might contribute to the absolute volume of transferable IPv4 resources available to aspiring new entrants in the post-IPv4 exhaustion era. If this is not too far off, then (assuming LISP succeeds on all of the above counts) I might still be curious about the (extent of the) dynamic aspects of LISP's scalability advantages (e.g., how much of the expected DFZ gains derive from the one-time payoff arising from the voluntarily exit of non-transit providers, and how much/ for how long would the remaining uncommitted DNZ capacity be likely to remain "open" to future new entrants?). Also, even if LISP ultimately succeeds in making 99% of current IPv4 assignments technically unnecessary, I would not expect that fact to automatically/inevitably or dramatically alter the "scarcity premium" that IPv4 will likely command in any future in which IPv4 remains non- substitutable for any critical industry functions or roles, and protocol resource numbers are (re)distributed exclusively through market mechanisms. Recall that back in the late 1990s, very few people actually new that 99+% of even the initial lit capacity across all of the segments of all of the recently deployed optical systems was completely idle. Prices didn't start to take their substantial (!) downward turn, and corresponding "productive capacity utilization" rates didn't start to really explode until the actual facts surrounding those supply condition were inadvertently revealed a few years later, in the course of a few unanticipated distressed asset sales, legal investigations, etc. In general I think that the assumption that there is any automatic or inevitable or guaranteed relationship of any meaningful and reliable kind between supply and demand has been largely discredited by history. Markets often work quite well, and (perhaps) well-designed and competently tended markets tend to work even more-better-more-often (?). But I think that the era when anyone can assume that the mere coincidence of some supply and some associated demand automatically guarantees the emergence of the best of possible worlds over any timeframe relevant to human beings has now passed into the history books. More specifically, in this context I think that the tendency to assume that market mechanisms would infallibly convert the fact/existence/ supply of additional loose (de-assignable, transferable, etc.) IPv4 into the enduring condition of greater openness to aspiring new entrants is based on the widespread (mis)perception of individual IPv4 addresses and prefixes as "things" (assets, commodities, etc.), when in fact they actually represent something more like discrete instances of a "generalized privilege" or "license" (as in "creative license" even more than "driver's license"). If/when future technology advances provide a /32 owner the same kind of "generalized privilege" that today is limited to those holding a /24 or more, then I would fully expect the "privilege adjusted" cost to remain constant, if not appreciate. As long as IPv4 remains non-substitutable for any critical and/or commercially attractive aspect of content or routing service provision, that "privilege adjusted" price is only likely to continue appreciating ad infinitum. >> I think that the majority of reasons for supporting the previous >> transitions (i.e., previous impositions of new technical >> requirements on incumbent network operators), as well as for >> supporting IPv6, would fit neatly under this rubric. And while your >> own description of the past circumstances didn't use those specific >> terms, I believe that the phenomena of "proliferation of class Cs >> being allocated" and "class Bs running out" that you referred to >> were both driven in part by demand from initial allocation seekers, >> a.k.a. "new entrants" -- i.e., we agree on this point. >> >> Of course, during any given duration the majority of newly >> allocated/assigned IP addresses are probably going to >> "incumbents" (subsequent allocation seekers), but that's consistent >> with patterns of growth in every other industry, i.e., it's >> basically a demographic of statistical artifact of cumulative >> growth processes (granted, one that can be influenced by various >> policies). The important distinction, at least until now, is that >> the growth/IP addressing demand of incumbents was not incompatible >> with the continued openness of the addressing and routing system to >> non-incumbents/new entrants. >> >> And of course, I wouldn't have expected these sorts of arguments to >> figure prominently in IETF et al. meetings and discussion back in >> the 1980s-1990s. In the main, we're not a bunch of economists and >> policy makers by profession -- and even those of us who are >> generally know better than to phrase our technology and policy >> advocacy in such alien and unsympathetic terms... most of us anyway. > > Well but as you know there were some discussions along these lines > in the CIDRD/BGPD working groups. However, there are limits as to > how far those discussions can reasonably go in that forum. Of course you are right. But as noted above, I know of no better options at the moment. > One thing I would draw your attention to was a paper in this year's > WEIS conference by Richard Clayton that contains an economic > analysis of SHIM6. His parting question from his presentation was > whether RFCs should contain Economics Considerations sections. This sounds very interesting, although I'm not sure that it would be easy (or even possible) to subject an Economics Considerations section to IETF-style quality and relevance-preserving mechanisms -- and I'm even more uncertain whether an Economics Considerations section that lacked such vetting processes would be likely to net out positive in terms of fog lifted, questions answered, etc. As the ongoing TV-MM dialogue should make abundantly clear, achieving consensus on economic fundamentals, or the validity of different methodologies, or the relative value of different knowledge bases or experiential inputs, etc. makes IETF or RIR decision making look like the ultimate paragons of both decorum and efficiency. That said, I do think it would be well worth exploring. >> However, even if "openness of the internet addressing and routing >> system" was never the most popular/resonant rallying cry for >> specific technology changes, that doesn't mean that this general >> idea wasn't an important motivator or an influential part of the >> unspoken context. And even if that sounds implausible too, it still >> doesn't mean that the *fact* that such openness was preserved, >> intentionally or otherwise, didn't play an important role in the >> success of the system to date. Although the verdict of history is >> never truly final, to me industry openness looks a lot like a >> universal correlate (i.e., a necessary if not sufficient cause) >> behind the durability of industry self-governance. If that turns >> out to be true, then there could be a lot more at stake in the >> current transition tussle than just the fate of the IP address >> registries. > > I don't think anyone can deny that openness was an important > motivator for Internet technologies. We merely need to look at all > of the OTHER protocols that have gone by the wayside to see that it > is so. But I think what we saw was that Opennness was something to > be capitalized upon by one group of vendors, to entice customers, > and to disrupt certain market players. It certainly was not > regulated. I agree entirely -- which is why I've been trying to articulate an *evolutionary* understanding of the relationship so far between industry self-governance and rapid Internet adoption, growth, and development. I have never claimed, nor do I subscribe to the view that the ongoing, conscious, active pursuit of openness as a top priority among industry direct stakeholders is responsible for the Internet's great success. Rather, I'm suggesting that the generally welcome but largely accidental/unintentional preservation of industry openness throughout previous system-wide technology transitions and continuous rapid growth probably represents a major (i.e., almost certainly necessary if not entirely sufficient) reason why this world-spanning critical infrastructure continues to be entrusted to (mostly civilian, mostly private sector) full-time technologists who occasionally take a few days off to serve as volunteer lay economists and policy makers. IMO**, those present at various critical moments accidentally succeeded (perhaps with the occasional assistance of a unusual conjunction of "selective incentives and joint products"*) in creating a very durable, relatively adaptable, effectively self-maintaining industry coordination mechanism. So far those who came along thereafter seem to have done a reasonably good job of keeping it running, and headed in what seems to be a generally benign direction. (Needles to say, there's always room for improvement) I don't think that anyone has the power to recreate the kind of circumstances that give rise to this incredibly fortunate albeit accidental/unintentional evolutionary outcome. But one could argue that, for every system/organism or whatever that survives long enough, there inevitably comes a time when self-awareness coupled with the freedom to act replaces (or at least substantially complements) the blind mechanism of evolution in determining what happens next. Becoming aware (or being reminded) of the fact of evolution and its possible impacts will not relieve anyone of the important choices that will be made, one way or another, in the very near future. But I do believe that it might contribute (even if very marginally and indirectly) to better decisions. > And indeed if we look at security and authentication technology, the > desire to play King of the Mountain has IMHO long stalled > improvements in consumer authentication. Even though I'm not clear on the specific context, your frustration comes through loud and clear. I think that the quest to develop a perfectly open, self-encapsulated/externally unencumbered, and self- maintaining identification/reputation technology has been with us for a long time. Maybe when (if) we come up with one, it won't create any new complications that are equivalent to the current sources of frustration with external authority-based authentication systems (which have also been with us forever). I can already think of a couple of plausible candidates, but I always love surprises ;-) Regards, TV From tvest at eyeconomics.com Wed Jul 22 09:21:53 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Wed, 22 Jul 2009 03:21:53 -0400 Subject: [address-policy-wg] Spectrum and IP address reservations Message-ID: <57479C98-FB6C-4D25-831A-3948F18CFD76@eyeconomics.com> On Jul 21, 2009, at 5:04 AM, Eliot Lear wrote: > Hi Tom, > >> Thanks for the response. I actually agree -- probably should have >> written that competition was never more than one of many reasons >> that someone (anyone) *might have* supported those earlier >> transitions. That said, if you look back at my original response >> you'll note that I was actually arguing *against* transition >> rationales based narrowly on "competition" questions. The >> alternative that I proposed was transition to preserve the >> "openness of the internet addressing and routing system," >> especially to new entrants. > > Sure! I particularly like the idea, for instance, of using LISP or > other similar technology to enable end systems to move within the > topology without having to pollute the global BGP table. But I do > feel a Hal Varien moment coming on: are incentives aligned for the > right things to happen? Hi Eliot, [note well: what follows represents personal opinion** only] Thanks for (re) injecting these questions. On the "Hal question," I interpret the current state of affairs as as a weak indicator that incentives are on balance (i.e., far from perfectly) aligned. That said, I would never have allowed myself to get stuck in this rather uncomfortable position if I believed that that balance of incentives were actually aligned toward a sustainable outcome. > If not, can they be so aligned? Our earlier work pointed out that > there is a limit to the efficacy of RIR policies. So what tools do > we really have? Incentive alignment might qualify as a "normal" engineering challenge under other circumstances. In this case the task is abnormally complicated by (a) the apparent absence of strong internal consensus** or other means of identifying the common goal, and also by (b) the absence of half of the engineering tool box (i.e., all carrots, no sticks -- and while our carrots may be very nutritious, no one has ever accused them of being irresistibly delicious). Ideally, our unique community decision making (aka consensus-seeking) mechanism would provide a means for overcoming these challenges, by providing a forum where contending views on both policy means and policy ends are exposed to cross-examination. However, in this case, I have a feeling** that only one side of the debate is actually being presented openly. If we were to take the decreasing frequency of open, public objections to IPv6 transition/integration as a de facto indication of support for such a move (which seems to be a common feature of the consensus-seeking process, at least toward the end stages of policy development), my guess is that we'd probably expect the transition to be much further long, and to be happening at a much faster, and at a more rapidly accelerating pace than available evidence would seem to suggest. So, am I just fundamentally wrong on some point of fact or interpretation, or it is possible that some unknown share of the apparently widespread non-objection (i.e., the proverbial "dogs that don't bark") actually reflect some (equally unknown) number of unannounced decisions in favor of non-transition? I don't even pretend to know the answer. But my doubts have prompted me to take what seems to be the most institutionally appropriate action -- to capitalize on the one good (and perhaps unique) "tool" that we do possess, i.e., to use our community deliberative mechanisms to try to present a positive case *for* a timely and orderly transition. Though I may be lacking in the skills required to wield them effectively, for now they remain the best (maybe only) tools that I have at my disposal. > Again, returning to the LISP example, it's a technology advance that > is a potential Over-The-Top play that could align interests (not > that I've done the analysis, but that's my off-the-cuff thought, > something to be wary about). I think that this possibility merits much more thorough and systematic consideration. My (quite possibly under-informed) impression is that widespread adoption of LISP might improve matters substantially in several ways, e.g., (1) by providing the majority of origin-only/self- service routing providers with an opportunity to economize by vacating the DFZ, (2) by reducing the likely ongoing demand for DFZ participation (and al that that implies in terms of RIB/FIB scalability) by permanently eliminating such participation as an involuntary requirement for self-service routing providers, and (3) by reducing the impediments to renumbering, which hypothetically might contribute to the absolute volume of transferable IPv4 resources available to aspiring new entrants in the post-IPv4 exhaustion era. If this is not too far off, then (assuming LISP succeeds on all of the above counts) I might still be curious about the (extent of the) dynamic aspects of LISP's scalability advantages (e.g., how much of the expected DFZ gains derive from the one-time payoff arising from the voluntarily exit of non-transit providers, and how much/ for how long would the remaining uncommitted DNZ capacity be likely to remain "open" to future new entrants?). Also, even if LISP ultimately succeeds in making 99% of current IPv4 assignments technically unnecessary, I would not expect that fact to automatically/inevitably or dramatically alter the "scarcity premium" that IPv4 will likely command in any future in which IPv4 remains non- substitutable for any critical industry functions or roles, and protocol resource numbers are (re)distributed exclusively through market mechanisms. Recall that back in the late 1990s, very few people actually new that 99+% of even the initial lit capacity across all of the segments of all of the recently deployed optical systems was completely idle. Prices didn't start to take their substantial (!) downward turn, and corresponding "productive capacity utilization" rates didn't start to really explode until the actual facts surrounding those supply condition were inadvertently revealed a few years later, in the course of a few unanticipated distressed asset sales, legal investigations, etc. In general I think that the assumption that there is any automatic or inevitable or guaranteed relationship of any meaningful and reliable kind between supply and demand has been largely discredited by history. Markets often work quite well, and (perhaps) well-designed and competently tended markets tend to work even more-better-more-often (?). But I think that the era when anyone can assume that the mere coincidence of some supply and some associated demand automatically guarantees the emergence of the best of possible worlds over any timeframe relevant to human beings has now passed into the history books. More specifically, in this context I think that the tendency to assume that market mechanisms would infallibly convert the fact/existence/ supply of additional loose (de-assignable, transferable, etc.) IPv4 into the enduring condition of greater openness to aspiring new entrants is based on the widespread (mis)perception of individual IPv4 addresses and prefixes as "things" (assets, commodities, etc.), when in fact they actually represent something more like discrete instances of a "generalized privilege" or "license" (as in "creative license" even more than "driver's license"). If/when future technology advances provide a /32 owner the same kind of "generalized privilege" that today is limited to those holding a /24 or more, then I would fully expect the "privilege adjusted" cost to remain constant, if not appreciate. As long as IPv4 remains non-substitutable for any critical and/or commercially attractive aspect of content or routing service provision, that "privilege adjusted" price is only likely to continue appreciating ad infinitum. >> I think that the majority of reasons for supporting the previous >> transitions (i.e., previous impositions of new technical >> requirements on incumbent network operators), as well as for >> supporting IPv6, would fit neatly under this rubric. And while your >> own description of the past circumstances didn't use those specific >> terms, I believe that the phenomena of "proliferation of class Cs >> being allocated" and "class Bs running out" that you referred to >> were both driven in part by demand from initial allocation seekers, >> a.k.a. "new entrants" -- i.e., we agree on this point. >> >> Of course, during any given duration the majority of newly >> allocated/assigned IP addresses are probably going to >> "incumbents" (subsequent allocation seekers), but that's consistent >> with patterns of growth in every other industry, i.e., it's >> basically a demographic of statistical artifact of cumulative >> growth processes (granted, one that can be influenced by various >> policies). The important distinction, at least until now, is that >> the growth/IP addressing demand of incumbents was not incompatible >> with the continued openness of the addressing and routing system to >> non-incumbents/new entrants. >> >> And of course, I wouldn't have expected these sorts of arguments to >> figure prominently in IETF et al. meetings and discussion back in >> the 1980s-1990s. In the main, we're not a bunch of economists and >> policy makers by profession -- and even those of us who are >> generally know better than to phrase our technology and policy >> advocacy in such alien and unsympathetic terms... most of us anyway. > > Well but as you know there were some discussions along these lines > in the CIDRD/BGPD working groups. However, there are limits as to > how far those discussions can reasonably go in that forum. Of course you are right. But as noted above, I know of no better options at the moment. > One thing I would draw your attention to was a paper in this year's > WEIS conference by Richard Clayton that contains an economic > analysis of SHIM6. His parting question from his presentation was > whether RFCs should contain Economics Considerations sections. This sounds very interesting, although I'm not sure that it would be easy (or even possible) to subject an Economics Considerations section to IETF-style quality and relevance-preserving mechanisms -- and I'm even more uncertain whether an Economics Considerations section that lacked such vetting processes would be likely to net out positive in terms of fog lifted, questions answered, etc. As the ongoing TV-MM dialogue should make abundantly clear, achieving consensus on economic fundamentals, or the validity of different methodologies, or the relative value of different knowledge bases or experiential inputs, etc. makes IETF or RIR decision making look like the ultimate paragons of both decorum and efficiency. That said, I do think it would be well worth exploring. >> However, even if "openness of the internet addressing and routing >> system" was never the most popular/resonant rallying cry for >> specific technology changes, that doesn't mean that this general >> idea wasn't an important motivator or an influential part of the >> unspoken context. And even if that sounds implausible too, it still >> doesn't mean that the *fact* that such openness was preserved, >> intentionally or otherwise, didn't play an important role in the >> success of the system to date. Although the verdict of history is >> never truly final, to me industry openness looks a lot like a >> universal correlate (i.e., a necessary if not sufficient cause) >> behind the durability of industry self-governance. If that turns >> out to be true, then there could be a lot more at stake in the >> current transition tussle than just the fate of the IP address >> registries. > > I don't think anyone can deny that openness was an important > motivator for Internet technologies. We merely need to look at all > of the OTHER protocols that have gone by the wayside to see that it > is so. But I think what we saw was that Opennness was something to > be capitalized upon by one group of vendors, to entice customers, > and to disrupt certain market players. It certainly was not > regulated. I agree entirely -- which is why I've been trying to articulate an *evolutionary* understanding of the relationship so far between industry self-governance and rapid Internet adoption, growth, and development. I have never claimed, nor do I subscribe to the view that an ongoing, conscious, active pursuit of openness as a top priority by industry direct stakeholders is responsible for the Internet's great success. Rather, I'm suggesting that the generally welcome but largely accidental/unintentional preservation of industry openness throughout previous system-wide technology transitions and continuous rapid growth probably represents a major (i.e., almost certainly necessary if not entirely sufficient) reason why this world-spanning critical infrastructure continues to be entrusted to (mostly civilian, mostly private sector) full-time technologists who occasionally take a few days off to serve as volunteer lay economists and policy makers. IMO**, those present at various critical moments accidentally succeeded -- perhaps with the occasional assistance of an unusual conjunction of "selective incentives and joint products" [[1]] -- in creating a very durable, relatively adaptable, effectively self- maintaining industry coordination mechanism. So far, those who came along thereafter seem to have done a reasonably good job of keeping it running, and headed in what seems to be a generally benign direction. (Needles to say, there's always room for improvement) I don't think that anyone has the power to recreate the kind of circumstances that give rise to this incredibly fortunate albeit accidental/unintentional evolutionary outcome. But one could argue that, for every system/organism or whatever that survives long enough, there inevitably comes a time when self-awareness coupled with the freedom to act replaces (or at least substantially complements) the blind mechanism of evolution in determining what happens next. Becoming aware (or being reminded) of the fact of evolution and its possible impacts will not relieve anyone of the important choices that will be made, one way or another, in the very near future. But I do believe that it might contribute (even if very marginally and indirectly) to better decisions. > And indeed if we look at security and authentication technology, the > desire to play King of the Mountain has IMHO long stalled > improvements in consumer authentication. Even though I'm not clear on the specific context, your frustration comes through loud and clear. I think that the quest to develop a perfectly open, self-encapsulated/externally unencumbered, and self- maintaining identification/reputation technology has been with us for a long time. Maybe when (if) we come up with one, it won't create any new complications that are equivalent to the current sources of frustration with external authority-based authentication systems (which have also been with us forever). I can already think of a couple of plausible candidates, but then that's my job -- even so, I always love surprises ;-) Regards, TV [personal opinion only] [[1]] The "joint products" model is an explanatory device that economists have used in some cases to describe how public goods like "industry openness" are sometimes produced more or less accidentally. It has been used, for example, to explain some historical episodes in which bankers in decentralized monetary systems -- basically countries where individual privately owned banks were at liberty to print their own currencies as they saw fit, which tended to be quite extremely volatile -- voluntarily adopted a standardized, national currency and "industry self-governance" model with some binding rules (e.g., capital reserve requirements, money printing restrictions) that implicitly limited their commercial freedom. The basic idea is that in some cases, the individual industry players themselves are confronted with some new opportunity to realize a substantial private benefit, but only if they cooperate in some specific way (e.g., in this case the adoption of a single national currency) that has the collateral effect producing some non-private "meta-good," like a national economy where individuals and businesses don't have to worry very much about whether their money will just stop working (i.e., their private/ nonstandard banknotes cease to be accepted by merchants), or their bank-deposited savings will suddenly disappear without warning. From remco.vanmook at eu.equinix.com Wed Jul 22 10:19:26 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Wed, 22 Jul 2009 10:19:26 +0200 Subject: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) In-Reply-To: Message-ID: [resent after it got filtered] Dear all, So here goes. This is what I think that policy should look like. Any comments before I formally submit it? Best, Remco Number: (assigned by the RIPE NCC) Policy Proposal Name: ?Allow smaller initial allocations Author: name: Remco van Mook email: remco.vanmook at eu.equinix.com organisation: Equinix Proposal Version: 0.1 Submission Date:?July 17, 2009 Suggested RIPE WG for discussion and publication:?Address Policy Proposal Type: modify Policy Term: Permanent Summary of proposal:?Allow new LIRs to get a smaller initial allocation than the standard at their specific request Policy text: Current (if modify): 5.1 First Allocation The RIPE NCC?s minimum allocation size is /21. New: 5.1 First Allocation The RIPE NCC?s minimum allocation size is /21. Consequently, the initial allocation size is /21. However, at the explicit request of the member, a smaller initial allocation up to a /24 can be made. In those cases, the RIPE NCC shall not make efforts to keep adjacent address space available for possible future allocation requests. Rationale: Arguments supporting the proposal Potential LIRs are currently forced to request PI space if they do not require a /21 of address space and want to contribute to the conservation of available global IPv4 resources. This policy change removes that obstacle and reduces the amount of requests for PI space for that purpose. The text looks a bit awkward because this is the only place where the minimum allocation size is specified and I wanted to keep that in - the minimum now being a general rule instead of a hard limit. Arguments opposing the proposal This policy change arguably increases fragmentation. On the other side, PI space assignments are made regardless of the minimum allocation size so the chances of actually increasing fragmentation are minimal. People do filtering based on minimum allocation sizes (I've not seen it in real life but that's the ever-returning argument) but that can be avoided using the ranges normally used for assigning PI for undersized allocations. On 17-07-09 14:02, "Sascha Lenz" wrote: > Hi, > > Remco van Mook schrieb: >> >> Hi Mark, >> >> It is heartening to see that your drive to conservation of IPv4 space >> alone is pushing you to put all this effort in to get PI space. I?m sure >> we can suggest a policy change approved that would set the standard >> initial allocation to /21 but allow for smaller allocations up to /24 if >> specifically requested by the new LIR. > > [...] > > ... apart from the fact that i don't think the whole community agrees > that we need any form of IPv4 conservation anyways :-) ... i think this > would be the apropriate step here, yes. > > I would support a more "floating" (first) allocation policy, because > even that i think that we don't need to conserve IPv4 space too much, i > also don't think that we need to waste it either if there are other > simple options like what you suggest (smaller Allocation on request or so). > > > -- > ======================================================================== > = Sascha Lenz SLZ-RIPE slz at baycix.de = > = Network Design & Operations = > = BayCIX GmbH, Landshut * PGP public Key on demand * = > ======================================================================== > > ------ End of Forwarded Message This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. From gert at space.net Wed Jul 22 10:28:14 2009 From: gert at space.net (Gert Doering) Date: Wed, 22 Jul 2009 10:28:14 +0200 Subject: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) In-Reply-To: References: Message-ID: <20090722082814.GX8076@Space.Net> Hi, On Wed, Jul 22, 2009 at 10:19:26AM +0200, Remco van Mook wrote: > So here goes. This is what I think that policy should look like. Any > comments before I formally submit it? Do we *really* need this? The network that started this topic ("we have 10 locations that need a /24 each") is not your typical *LIR* in the first place, and might really be better suited with PI /24s - as that's what they are doing: connecting "independent locations" to the Internet. They are not doing LIR business. A *LIR* needs a reasonable amount of address space, so I really fail to see why someone would want a /24 PA instead of a /24 PI... (which costs less, and has the same impact on the routing table). Operationally, the "/24 PA" would come from the same blocks as /24 PI anyway (minimum allocation size, etc.)... If you're convinced that this really is a good thing, by all means go ahead (and I won't oppose), I'm just afraid that this is a waste of "policy making brain power", solving a not really existing problem... Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From andy at nosignal.org Wed Jul 22 10:30:35 2009 From: andy at nosignal.org (Andy Davidson) Date: Wed, 22 Jul 2009 09:30:35 +0100 Subject: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) In-Reply-To: References: Message-ID: On 22 Jul 2009, at 09:19, Remco van Mook wrote: > The RIPE NCC?s minimum allocation size is /21. Consequently, the > initial > allocation size is /21. However, at the explicit request of the > member, a > smaller initial allocation up to a /24 can be made. In those cases, > the RIPE > NCC shall not make efforts to keep adjacent address space available > for > possible future allocation requests. First thoughts - No opposed to this at all, but please make the smaller allocations from a new /8 so that existing minimum allocation size documentation/filters do not need to be updated. Because we know that a lot of the time they wont be. :-) Andy -- Regards, Andy Davidson +44 (0)20 7993 1700 www.netsumo.com NetSumo Ltd, Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC /* Opinions are my own and & may not constitute policy of any org I work for */ From jeroen at easyhosting.nl Wed Jul 22 10:44:07 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Wed, 22 Jul 2009 10:44:07 +0200 Subject: [address-policy-wg] Re: DRAFT: policy to allow smaller initial allocations In-Reply-To: <20090722082814.GX8076@Space.Net> References: <20090722082814.GX8076@Space.Net> Message-ID: <4A66D157.7030401@easyhosting.nl> I beleive the discussion that also started this was due to RIPE being very strict and overly complicated (in my opinion) about PI assignments. (even the first /24+AS) RIPE suggests a lot of: 'Customer should become LIR himself', even if he doesn't need the /21 in the forseeable future. I think your definition of a LIR is something else then RIPE defines it as. Nevertheless, I do agree with your definition of a LIR and I'd rather see the PI assignments being handled in < /21 allocations, and most definately in another (easier, less time consuming) way when a LIR requests one on behalf of a customer. Gert Doering wrote: > Hi, > > On Wed, Jul 22, 2009 at 10:19:26AM +0200, Remco van Mook wrote: > >> So here goes. This is what I think that policy should look like. Any >> comments before I formally submit it? >> > > Do we *really* need this? > > The network that started this topic ("we have 10 locations that need a > /24 each") is not your typical *LIR* in the first place, and might really > be better suited with PI /24s - as that's what they are doing: connecting > "independent locations" to the Internet. They are not doing LIR business. > > A *LIR* needs a reasonable amount of address space, so I really fail to > see why someone would want a /24 PA instead of a /24 PI... (which costs > less, and has the same impact on the routing table). > > > Operationally, the "/24 PA" would come from the same blocks as /24 PI > anyway (minimum allocation size, etc.)... > > > If you're convinced that this really is a good thing, by all means go > ahead (and I won't oppose), I'm just afraid that this is a waste of > "policy making brain power", solving a not really existing problem... > > Gert Doering > -- APWG chair > -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From dmitry at volia.net Wed Jul 22 10:48:56 2009 From: dmitry at volia.net (Dmitry Kiselev) Date: Wed, 22 Jul 2009 11:48:56 +0300 Subject: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) In-Reply-To: <20090722082814.GX8076@Space.Net> References: <20090722082814.GX8076@Space.Net> Message-ID: <20090722084856.GM1385@f17.dmitry.net> Hello! On Wed, Jul 22, 2009 at 10:28:14AM +0200, Gert Doering wrote: > On Wed, Jul 22, 2009 at 10:19:26AM +0200, Remco van Mook wrote: > > So here goes. This is what I think that policy should look like. Any > > comments before I formally submit it? > > Do we *really* need this? Yes, we need this. I support this proposition. > The network that started this topic ("we have 10 locations that need a > /24 each") is not your typical *LIR* in the first place, and might really > be better suited with PI /24s - as that's what they are doing: connecting > "independent locations" to the Internet. They are not doing LIR business. > > A *LIR* needs a reasonable amount of address space, so I really fail to > see why someone would want a /24 PA instead of a /24 PI... (which costs > less, and has the same impact on the routing table). PI does not allow end user assignments in it. In my opinion it is good reason for allow /24 allocations. > Operationally, the "/24 PA" would come from the same blocks as /24 PI > anyway (minimum allocation size, etc.)... > > > If you're convinced that this really is a good thing, by all means go > ahead (and I won't oppose), I'm just afraid that this is a waste of > "policy making brain power", solving a not really existing problem... -- Dmitry Kiselev From gert at space.net Wed Jul 22 11:07:47 2009 From: gert at space.net (Gert Doering) Date: Wed, 22 Jul 2009 11:07:47 +0200 Subject: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) In-Reply-To: <20090722084856.GM1385@f17.dmitry.net> References: <20090722082814.GX8076@Space.Net> <20090722084856.GM1385@f17.dmitry.net> Message-ID: <20090722090747.GZ8076@Space.Net> Hi, On Wed, Jul 22, 2009 at 11:48:56AM +0300, Dmitry Kiselev wrote: > > The network that started this topic ("we have 10 locations that need a > > /24 each") is not your typical *LIR* in the first place, and might really > > be better suited with PI /24s - as that's what they are doing: connecting > > "independent locations" to the Internet. They are not doing LIR business. > > > > A *LIR* needs a reasonable amount of address space, so I really fail to > > see why someone would want a /24 PA instead of a /24 PI... (which costs > > less, and has the same impact on the routing table). > > PI does not allow end user assignments in it. In my opinion it is > good reason for allow /24 allocations. Well. I can't really see a scenario where I would assign addresses to end users and would be happy with a /24 allocation - our end users get assignments up to a /23 from us... I think one of the focal points here is the question on whether 'giving a hosted web server an IP address' is 'assigning address space to end users'. The boundary cases ("the customer has a virtual web presence and not even a dedicated IP address" and "the customer is running their own web farm and the ISP routes a /24 towards their firewall") are pretty clear - but there is lots of space for different way to do web server hosting in between (managed servers, rented servers, real servers, vmware entities, vserver/jailed virtual servers, ...) The IPv4 PI policy currently defines the transfer networks between an ISP network and an access customer as "part of the ISP infrastructure" - so if you give /32s to DSL end customers, you could run your whole ISP on a PI block (but you can't give one of these customers a /30 to use behind their router). Which is a bit funny indeed. People have argued to remove the PA/PI distinction. I don't think that this is the right way (due to the fact that PA allocations necessarily need to be more liberal than PI assignments), but maybe we need to loosen up PI rules a bit, as in: "Using addresses from a PI block to number other parties' devices is permitted as long as these devices are connected to the same network, documentation about the usage can be presented to the RIPE NCC, and full responsibility for the addresses (abuse handling etc) is done by the PI holder". (After all, one of the reasons why we document end user assignments in a public database is to be able to contact a person feeling responsible for troubleshooting and abuse handling) "same network" is important to make it crystal clear that "get a chunk of PI and sell off smaller bits to 3rd parties connecting at random to other ISPs" is not the desired intention. Now come and flame me :-) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From david.freedman at uk.clara.net Wed Jul 22 11:09:32 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 22 Jul 2009 10:09:32 +0100 Subject: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) References: <20090722082814.GX8076@Space.Net> <20090722084856.GM1385@f17.dmitry.net> <20090722090747.GZ8076@Space.Net> Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B0D7E12@EXVS01.claranet.local> Agree, i've always treated such requests from PI Applicants as valid "infrastructure" purpose, NCC have always agreed, surely this is a non-issue? ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: address-policy-wg-admin at ripe.net on behalf of Gert Doering Sent: Wed 7/22/2009 10:07 To: Dmitry Kiselev Cc: Gert Doering; Remco van Mook; Address Policy Working Group Subject: Re: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) Hi, On Wed, Jul 22, 2009 at 11:48:56AM +0300, Dmitry Kiselev wrote: > > The network that started this topic ("we have 10 locations that need a > > /24 each") is not your typical *LIR* in the first place, and might really > > be better suited with PI /24s - as that's what they are doing: connecting > > "independent locations" to the Internet. They are not doing LIR business. > > > > A *LIR* needs a reasonable amount of address space, so I really fail to > > see why someone would want a /24 PA instead of a /24 PI... (which costs > > less, and has the same impact on the routing table). > > PI does not allow end user assignments in it. In my opinion it is > good reason for allow /24 allocations. Well. I can't really see a scenario where I would assign addresses to end users and would be happy with a /24 allocation - our end users get assignments up to a /23 from us... I think one of the focal points here is the question on whether 'giving a hosted web server an IP address' is 'assigning address space to end users'. The boundary cases ("the customer has a virtual web presence and not even a dedicated IP address" and "the customer is running their own web farm and the ISP routes a /24 towards their firewall") are pretty clear - but there is lots of space for different way to do web server hosting in between (managed servers, rented servers, real servers, vmware entities, vserver/jailed virtual servers, ...) The IPv4 PI policy currently defines the transfer networks between an ISP network and an access customer as "part of the ISP infrastructure" - so if you give /32s to DSL end customers, you could run your whole ISP on a PI block (but you can't give one of these customers a /30 to use behind their router). Which is a bit funny indeed. People have argued to remove the PA/PI distinction. I don't think that this is the right way (due to the fact that PA allocations necessarily need to be more liberal than PI assignments), but maybe we need to loosen up PI rules a bit, as in: "Using addresses from a PI block to number other parties' devices is permitted as long as these devices are connected to the same network, documentation about the usage can be presented to the RIPE NCC, and full responsibility for the addresses (abuse handling etc) is done by the PI holder". (After all, one of the reasons why we document end user assignments in a public database is to be able to contact a person feeling responsible for troubleshooting and abuse handling) "same network" is important to make it crystal clear that "get a chunk of PI and sell off smaller bits to 3rd parties connecting at random to other ISPs" is not the desired intention. Now come and flame me :-) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Jul 22 11:16:05 2009 From: gert at space.net (Gert Doering) Date: Wed, 22 Jul 2009 11:16:05 +0200 Subject: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) In-Reply-To: <7B8B0D6F623C3A40A0D0A80A66756E2B0D7E12@EXVS01.claranet.local> References: <20090722082814.GX8076@Space.Net> <20090722084856.GM1385@f17.dmitry.net> <20090722090747.GZ8076@Space.Net> <7B8B0D6F623C3A40A0D0A80A66756E2B0D7E12@EXVS01.claranet.local> Message-ID: <20090722091604.GA8076@Space.Net> Hi, On Wed, Jul 22, 2009 at 10:09:32AM +0100, David Freedman wrote: > Agree, i've always treated such requests from PI Applicants as valid "infrastructure" purpose, > NCC have always agreed, surely this is a non-issue? Well, the question came up on this list (on whether "web server hosting" would be a valid purpose for IPv6 PI), and it seem that other people had issues requesting IPv4 PI for customers that do "web server hosting". So at least some clarification might be helpful, if only to help the hostmasters (IPRAs) to cause less irritation due to different interpretations on both sides... Maybe we can get a few words from the NCC on how PI requests are evaluated in the context of "we want to run web servers in that space" today? Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From david.freedman at uk.clara.net Wed Jul 22 11:40:11 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 22 Jul 2009 10:40:11 +0100 Subject: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) References: <20090722082814.GX8076@Space.Net> <20090722084856.GM1385@f17.dmitry.net> <20090722090747.GZ8076@Space.Net> <7B8B0D6F623C3A40A0D0A80A66756E2B0D7E12@EXVS01.claranet.local> <20090722091604.GA8076@Space.Net> Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B0D7E14@EXVS01.claranet.local> >Well, the question came up on this list (on whether "web server hosting" >would be a valid purpose for IPv6 PI), and it seem that other people had >issues requesting IPv4 PI for customers that do "web server hosting". Sure, I mean the way I see it, it isn't an allocation to an end user, as the assignment holder yourself you are allowing the customer to use your infrastructure addresses and as such you have full responsibility for them. Since we don't live in a (well) adopted RFC2616/RFC3546 world, each customer with an SSL cert needs to use one of your addresses for this purpose, this to me is a valid reason for needing an assignment of $size based on your usage expectations and growth model. Would like to think that I have been involved in numerous PI applications over the years (even recently) where this has been used as a justification and not a single IPRA has had an objection when this is stated clearly and shown to be the case. I think I would like to see the original application wording. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: Wed 7/22/2009 10:16 To: David Freedman Cc: Gert Doering; Dmitry Kiselev; Remco van Mook; Address Policy Working Group Subject: Re: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) Hi, On Wed, Jul 22, 2009 at 10:09:32AM +0100, David Freedman wrote: > Agree, i've always treated such requests from PI Applicants as valid "infrastructure" purpose, > NCC have always agreed, surely this is a non-issue? Well, the question came up on this list (on whether "web server hosting" would be a valid purpose for IPv6 PI), and it seem that other people had issues requesting IPv4 PI for customers that do "web server hosting". So at least some clarification might be helpful, if only to help the hostmasters (IPRAs) to cause less irritation due to different interpretations on both sides... Maybe we can get a few words from the NCC on how PI requests are evaluated in the context of "we want to run web servers in that space" today? Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry at volia.net Wed Jul 22 13:18:40 2009 From: dmitry at volia.net (Dmitry Kiselev) Date: Wed, 22 Jul 2009 14:18:40 +0300 Subject: DRAFT: policy to allow smaller initial allocations (was: Re: [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space) In-Reply-To: <20090722090747.GZ8076@Space.Net> References: <20090722082814.GX8076@Space.Net> <20090722084856.GM1385@f17.dmitry.net> <20090722090747.GZ8076@Space.Net> Message-ID: <20090722111840.GN1385@f17.dmitry.net> Hello! On Wed, Jul 22, 2009 at 11:07:47AM +0200, Gert Doering wrote: > > > The network that started this topic ("we have 10 locations that need a > > > /24 each") is not your typical *LIR* in the first place, and might really > > > be better suited with PI /24s - as that's what they are doing: connecting > > > "independent locations" to the Internet. They are not doing LIR business. > > > > > > A *LIR* needs a reasonable amount of address space, so I really fail to > > > see why someone would want a /24 PA instead of a /24 PI... (which costs > > > less, and has the same impact on the routing table). > > > > PI does not allow end user assignments in it. In my opinion it is > > good reason for allow /24 allocations. > > Well. I can't really see a scenario where I would assign addresses to > end users and would be happy with a /24 allocation - our end users get > assignments up to a /23 from us... Keeping in mind IPv4 runout I see no reasons why we should force LIR to receive more address space then he need/requested. I think it is no matter why LIR need such tiny block, he is free to run own network as he want. May be we should add an extra text to this proposal which will require renumbering if additional allocation is requested and all allocations size below some threshold. It should prevent unnecessary GRT grow. If /21 limitation shifts to /24, NCC IPRAs will get additional option to force PI applicant become a member. It is negative impact of proposal, I think. -- Dmitry Kiselev From ms at man-da.de Wed Jul 22 14:14:54 2009 From: ms at man-da.de (Marcus Stoegbauer) Date: Wed, 22 Jul 2009 14:14:54 +0200 Subject: [address-policy-wg] Re: DRAFT: policy to allow smaller initial allocations In-Reply-To: <20090722090747.GZ8076@Space.Net> References: <20090722082814.GX8076@Space.Net> <20090722084856.GM1385@f17.dmitry.net> <20090722090747.GZ8076@Space.Net> Message-ID: <4A6702BE.9000604@man-da.de> Gert Doering wrote: > I think one of the focal points here is the question on whether 'giving > a hosted web server an IP address' is 'assigning address space to end > users'. Yep, I agree. I usually don't come across those cases in my line of work either, but in the cases I read about in the last couple of weeks it were usually hosting providers with physically independent hosting locations that needed addresses to assign to their customers (who, maybe for redundancy reasons, want two servers with a small subnet in two locations). This case isn't covered by the current PI policy and so the problems began. Your idea: > People have argued to remove the PA/PI distinction. I don't think that > this is the right way (due to the fact that PA allocations necessarily need > to be more liberal than PI assignments), but maybe we need to loosen up > PI rules a bit, as in: > > "Using addresses from a PI block to number other parties' devices is > permitted as long as these devices are connected to the same network, > documentation about the usage can be presented to the RIPE NCC, and > full responsibility for the addresses (abuse handling etc) is done by > the PI holder". seems very reasonably to me (modulo some inaccuracies due to human language), I think this is the way to go forward regarding this problem. Marcus -- man-da.de GmbH, AS8365 Phone: +49 6151 16-6956 Petersenstr. 30 Fax: +49 6151 16-3050 D-64287 Darmstadt e-mail: ms at man-da.de Gesch?ftsf?hrer Marcus St?gbauer AG Darmstadt, HRB 94 84 From michael.dillon at bt.com Wed Jul 22 17:18:00 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 22 Jul 2009 16:18:00 +0100 Subject: [address-policy-wg] Offer to buy IP address block (was Spectrum and IP address reservations) In-Reply-To: <1F6404CD-A0B2-42D4-A849-ED5E9F9D89E5@eyeconomics.com> Message-ID: <28E139F46D45AF49A31950F88C497458024922EB@E03MVZ2-UKDY.domain1.systemhost.net> > More specifically, in this context I think that the tendency > to assume that market mechanisms would infallibly convert the > fact/existence/ supply of additional loose (de-assignable, > transferable, etc.) IPv4 into the enduring condition of > greater openness to aspiring new entrants is based on the > widespread (mis)perception of individual IPv4 addresses and > prefixes as "things" (assets, commodities, etc.), when in > fact they actually represent something more like discrete > instances of a "generalized privilege" or "license" (as in > "creative license" > even more than "driver's license"). The minimum ARIN allocation to a new ISP is currently a /20. Someone recently offered an American ISP 6 figures for a /20 block that was acquired as part of a corporate acquisition. The ISP declined the offer and returned the block to ARIN. This could mean that the value of a /20 on the open market is 100,000 USD. Since a /20 has 16 /24 equivalents in it, that would place the value of a /24 at 6250 USD. According to in the first 6 months of 2009, ARIN issued 99,285 /24 equivalents to ISPs. That means that ARIN issued 620,531,250 USD worth of IP addresses. Over the course of 2009 we can expect some 1.2 billion dollars worth of IPv4 addresses to be allocated to ISPs, or $103 million per month. Where is the industry going to find 1.2 billion dollars to sustain growth of the network after IPv4 runout? And where is a new entrant going to find $100,000 to buy their first allocation, assuming that the price doesn't rise even higher when the free alternative no longer exists? Will the prices in Europe be any different than in America? Why? --Michael Dillon P.S. note that there are more predictable costs to an ISP in deploying either carrier-grade NAT or transitioning to IPv6. How will this impact IP address block prices and why? From unread at ripe.net Wed Jul 22 17:28:12 2009 From: unread at ripe.net (Axel Pawlik) Date: Wed, 22 Jul 2009 17:28:12 +0200 Subject: [address-policy-wg] NRO NC Call for Nominations Message-ID: <4A67300C.60200@ripe.net> [Apologies for duplicate emails] Dear Colleagues, This is a call for nominations from the RIPE NCC service region to fill one vacant seat on the Number Resource Organization (NRO) Number council (NC). The term of Dave Wilson, who was elected to the NRO NC in January 2007, ends on 31 December 2009. The election to the NRO NC seat will take place during a Plenary session at the RIPE 59 Meeting to be held in Lisbon, Portugal from 5-9 October 2009. All members of the Internet community who are present at the Plenary session may vote in the election. The deadline for nominations is 9 September 2009. Any individual residing within the RIPE NCC service region is eligible for nomination, except Regional Internet Registry (RIR) staff members. Self-nominations are permitted. Please send your nominations to by 23:00 UTC on 9 September 2009. All confirmed nominations will be listed on the RIPE NCC website by 11 September 2009. All nominees may submit a written statement in support of their nomination for publication on the RIPE NCC website. Other individuals may express support for nominated individuals by sending an e-mail to . Expressions of support will also be published on the RIPE NCC website. To find out more about the NRO NC and the election process, please see: http://www.ripe.net/info/resource-admin/nro2009/ Regards, Axel Pawlik Managing Director RIPE NCC From jim at rfc1035.com Wed Jul 22 18:32:36 2009 From: jim at rfc1035.com (Jim Reid) Date: Wed, 22 Jul 2009 17:32:36 +0100 Subject: [address-policy-wg] The price of address space In-Reply-To: <28E139F46D45AF49A31950F88C497458024922EB@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458024922EB@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <51AA4CA9-122E-4E58-A05D-D3AF5023885B@rfc1035.com> On 22 Jul 2009, at 16:18, wrote: > Where is the industry going to find 1.2 billion dollars to sustain > growth of the network after IPv4 runout? And where is a new entrant > going to find $100,000 to buy their first allocation, assuming that > the price doesn't rise even higher when the free alternative no > longer exists? I'm reminded of the late 90's .com joke/business model about how to becomea multi-billionaire: Set up a company with 100Bn shares. Sell one share to yourself for $5. Congratulations! Your company is now worth $500Bn. So exchange your company's paper for a medium-sized country. To be serious, I think it's unwise to extrapolate from your anecdote about someone offering a six figure sum for a /20. Or to use that as the basis for a valuation of the allocated and/or yet-to-be-allocated IPv4 address space. For one thing, who could possibly know for sure if the figure you quoted that was offered recently will be the going rate for a /20 after the IPv4 run-out? If someone can do that, please provide me with the winning numbers for next week's lottery.... :-) If we assume there will be a market in IPv4 after the run-out, we should expect the usual laws of supply and demand will mean there's some sort of price equilibrium in the market. The market price will be what someone's prepared to pay and what someone is willing to sell for. That price will flunctuate and depend on too many imponderables and variables that can't easily be controlled or predicted today. Just like any predictions for the prices of shares or exchange rates or commoditiies N years in the future. If IPv4 costs too much -- say because demand exceeds supply -- other solutions will emerge and be adopted. For instance more use of NAT and ALG (if these turn out to be cheaper than buying a /20 or whatever). Or, radical thought, there is more uptake of IPv6 because these addresses cost next to nothing at the RIR. The point I'm making is that it doesn't seem sensible or even possible to predict what these prices might be post run-out. Or worry too much about that. Or to invent policies which somehow influence or control those prices. [That might well have the look and feel of a cartel.] It would be an interesting academic exercise for economists to model the impact of various pricing scenarios though I'm not sure how useful that would be in practice. That said, it would be nice to have some sort of idea of the price points where the trade-offs between buying IPv4 or using more NAT/ALG or deploying IPv6 start to get fuzzy. Any market that develops should be self-correcting. So if the going rate for IPv4 address space is too expensive, there will be other options. This has obvious parallels with everyday activity. For instance, if the cost of heating my home gets too costly, I can look for a better paying job; or find a cheaper supplier; or turn down the thermostat; or wear warmer clothing; or improve the insulation; or install a more efficient boiler; or reduce the hours that the heating is on; or some combination of these. Is there some reason to assume comparable dynamics won't apply to IPv4 post run-out? From michael.dillon at bt.com Wed Jul 22 23:50:03 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 22 Jul 2009 22:50:03 +0100 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <51AA4CA9-122E-4E58-A05D-D3AF5023885B@rfc1035.com> Message-ID: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> > To be serious, I think it's unwise to extrapolate from your > anecdote about someone offering a six figure sum for a /20. Not at all. In several years of discussion of IP address markets, this is the first time that I have seen someone put an actual dollar value on an address block. Granted, it was an offered amount that did not result in a sale, but it is the best data point that I have seen so far. > For one thing, who could possibly know > for sure if the figure you quoted that was offered recently > will be the going rate for a /20 after the IPv4 run-out? I think that we all realise that in a real market, prices go up and down with every transaction. So, given that someone is willing to offer 100,000 USD for a /20 today, when there are free alternatives at the RIR, what do you think the going rate will be after the free alternative is gone? > If we assume there will be a market in IPv4 after the > run-out, we should expect the usual laws of supply and demand > will mean there's some sort of price equilibrium in the > market. Equilibrium? When I learned basic economics, scarcity caused prices to rise. After IPv4 runout, every block sold just makes IPv4 addresses scarcer which means that there will be no equilibrium, just increases until nobody can afford to pay the price. I would expect that to be a stairstep increase because everyone knows that addresses are scarcer and scarcer as time goes on. Then the whole thing comes crashing down when IPv6 gathers enough momentum and people start releasing large amounts of IPv4 addresses. > Just like > any predictions for the prices of shares or exchange rates or > commodities N years in the future. You may not be able to predict exact prices, but you can do pretty good at predicting minimum and maximum prices relative to a hard currency, i.e. ounces of gold or barrels of crude, or Big Macs. > For instance more use of NAT and ALG > (if these turn out to be cheaper than buying a /20 or > whatever). How cheap do IPv4 addresses need to be to make it worthwhile for an equipment vendor to buy up addresses today to drive up the price and make it worthwhile for the market to buy carrier grade NAT boxes? > The point I'm making is that it doesn't seem sensible or even > possible to predict what these prices might be post run-out. We could prohibit 3rd part transfers and only allow returns to the RIR in which case we can confidently predict that the price will be zero. In any case, it is very sensible to do these types of scenario analysis as part of the policymaking process. > Or to invent policies which > somehow influence or control those prices. [That might well > have the look and feel of a cartel.] We have a cartel today and the price is zero. It's been like that for many years now and nobody is complaining or investigating the RIRs. > It would be an > interesting academic exercise for economists to model the > impact of various pricing scenarios though I'm not sure how > useful that would be in practice. That said, it would be nice > to have some sort of idea of the price points where the > trade-offs between buying > IPv4 or using more NAT/ALG or deploying IPv6 start to get fuzzy. I agree on that. Where are all the economics grad students? --Michael Dillon P.S. My position is that IPv6 is the answer and post runout, most larger ISPs should be able to satisfy growth of IPv4 in one area of their business by migrating lower margin services onto pure IPv6 in order to free the IPv4 addresses for the sluggish corporates who are willing to pay a higher margin for service using legacy technology. Note that an economist might well consider this to be a market alternative because money is exchanged in return for IPv4 network services with IPv4 addresses bundled in. From michael.dillon at bt.com Thu Jul 23 00:35:50 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 22 Jul 2009 23:35:50 +0100 Subject: [address-policy-wg] RE: [arin-ppml] Offer to buy IP address block (was Spectrum and IP address reservations) In-Reply-To: <443de7ad0907221500v33162ba2x6294d6ee52d2c742@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C497458024924D0@E03MVZ2-UKDY.domain1.systemhost.net> > > Someone recently offered an American ISP 6 figures for a /20 block > > that was acquired as part of a corporate acquisition. > > The ISP declined the offer and returned the block to ARIN. > > > > This could mean that the value of a /20 on the open market > is 100,000 > > USD. Since a /20 has 16 /24 equivalents in it, that would place the > > value of a /24 at 6250 USD. > > http://xkcd.com/605/ Not terribly relevant to IPv4 addresses. > > According to > > > > in the first 6 months of 2009, ARIN issued 99,285 /24 > equivalents to > > ISPs. That means that ARIN issued 620,531,250 USD worth of IP > > addresses. Over the course of 2009 we can expect some > > 1.2 billion dollars worth of IPv4 addresses to be allocated > to ISPs, > > or $103 million per month. > > > > Where is the industry going to find 1.2 billion dollars to sustain > > growth of the network after IPv4 runout? And where is a new entrant > > going to find $100,000 to buy their first allocation, assuming that > > the price doesn't rise even higher when the free > alternative no longer > > exists? I just learned that 6 figures actually referred to 185,000 USD so multiply all my above figures by 1.85. That brings the value of ARIN's annual ISP allocations to 2.2 billion USD. Another organization made an offer to use the address range for spamming, without transfering ownership, and their offer amounts to about 1/25th of the above one which would make ARIN's annual ISP allocations worth only 48 million USD and a /20 would cost approximately 4000 USD. So there you have two actual price offers showing a substantial range of values. Someone with actual economical statistics experience may be able to suggest a likely distribution of prices over this price range and come up with a more likely value of ARIN's annual ISP allocations. --Michael Dillon From jwkckid1 at ix.netcom.com Thu Jul 23 05:18:26 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Wed, 22 Jul 2009 20:18:26 -0700 Subject: [address-policy-wg] RE: The price of address space References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4A67D682.388A16DB@ix.netcom.com> Michael and all, The problem with your argument is that there really isn't a scarcity of IPv4 address space. The problem is that not enough has been done to reclaim unused IPv4 address space what was questionably allocated many years ago now. That is an RIR problem that seems to be one that they don't want to address or deal with. As such "Scalping" of IPv4 addresses has commenced and will get worse over time. The other solution is to implement IPv6 which is a good one, but seems also that that effort is and has been less than successful for various reasons. As such, it is rather convincing that the IANA and ICANN has failed to be good stuarts or their responsibilities accordingly. michael.dillon at bt.com wrote: > > To be serious, I think it's unwise to extrapolate from your > > anecdote about someone offering a six figure sum for a /20. > > Not at all. In several years of discussion of IP address markets, > this is the first time that I have seen someone put an actual > dollar value on an address block. Granted, it was an offered > amount that did not result in a sale, but it is the best data > point that I have seen so far. > > > For one thing, who could possibly know > > for sure if the figure you quoted that was offered recently > > will be the going rate for a /20 after the IPv4 run-out? > > I think that we all realise that in a real market, prices go > up and down with every transaction. So, given that someone is > willing to offer 100,000 USD for a /20 today, when there are > free alternatives at the RIR, what do you think the going rate > will be after the free alternative is gone? > > > If we assume there will be a market in IPv4 after the > > run-out, we should expect the usual laws of supply and demand > > will mean there's some sort of price equilibrium in the > > market. > > Equilibrium? When I learned basic economics, scarcity caused > prices to rise. After IPv4 runout, every block sold just makes > IPv4 addresses scarcer which means that there will be no equilibrium, > just increases until nobody can afford to pay the price. I would > expect that to be a stairstep increase because everyone knows that > addresses are scarcer and scarcer as time goes on. > > Then the whole thing comes crashing down when IPv6 gathers enough > momentum and people start releasing large amounts of IPv4 addresses. > > > Just like > > any predictions for the prices of shares or exchange rates or > > commodities N years in the future. > > You may not be able to predict exact prices, but you can do pretty good > at predicting minimum and maximum prices relative to a hard currency, > i.e. ounces of gold or barrels of crude, or Big Macs. > > > For instance more use of NAT and ALG > > (if these turn out to be cheaper than buying a /20 or > > whatever). > > How cheap do IPv4 addresses need to be to make it worthwhile for an > equipment vendor to buy up addresses today to drive up the price and > make it worthwhile for the market to buy carrier grade NAT boxes? > > > The point I'm making is that it doesn't seem sensible or even > > possible to predict what these prices might be post run-out. > > We could prohibit 3rd part transfers and only allow returns to > the RIR in which case we can confidently predict that the price > will be zero. In any case, it is very sensible to do these types > of scenario analysis as part of the policymaking process. > > > Or to invent policies which > > somehow influence or control those prices. [That might well > > have the look and feel of a cartel.] > > We have a cartel today and the price is zero. It's been like > that for many years now and nobody is complaining or investigating > the RIRs. > > > It would be an > > interesting academic exercise for economists to model the > > impact of various pricing scenarios though I'm not sure how > > useful that would be in practice. That said, it would be nice > > to have some sort of idea of the price points where the > > trade-offs between buying > > IPv4 or using more NAT/ALG or deploying IPv6 start to get fuzzy. > > I agree on that. Where are all the economics grad students? > > --Michael Dillon > > P.S. My position is that IPv6 is the answer and post runout, most > larger ISPs should be able to satisfy growth of IPv4 in one area > of their business by migrating lower margin services onto pure IPv6 > in order to free the IPv4 addresses for the sluggish corporates who > are willing to pay a higher margin for service using legacy technology. > Note that an economist might well consider this to be a market > alternative > because money is exchanged in return for IPv4 network services with > IPv4 addresses bundled in. Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From drc at virtualized.org Thu Jul 23 04:07:54 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 22 Jul 2009 19:07:54 -0700 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <6389FA79-E91C-494D-BB8A-B37A431C9A89@virtualized.org> Michael, On Jul 22, 2009, at 2:50 PM, wrote: > Equilibrium? When I learned basic economics, scarcity caused > prices to rise. After IPv4 runout, every block sold just makes > IPv4 addresses scarcer which means that there will be no equilibrium, > just increases until nobody can afford to pay the price. Which is an equilibrium. Not that this would occur, of course. You seem to believe there is no constraint on the price of IPv4 addresses. This is silly. If you are an enterprise, how many public IPv4 addresses do you really need? How many of your machines could be renumbered at some cost into RFC 1918 space and put behind a NAT? If you are an ISP, how many addresses do you give your customers by default? How many do they really need? How much internal infrastructure is numbered in public IPv4 that could be renumbered into RFC 1918 space (or better yet, renumbered into IPv6) if you could somehow find someone to pay for it? As the cost of IPv4 goes up, there will be increasing incentives to make more efficient use of the address space. People will consolidate their address holdings, putting their allocated-but-unused IPv4 address onto the market. Since this is increasing the supply of usable IPv4 addresses, this will tend to drive the price down. > Then the whole thing comes crashing down when IPv6 gathers enough > momentum and people start releasing large amounts of IPv4 addresses. And you don't believe the anticipation of IPv6 deployment would have a depressive effect on an IPv4 market? > We could prohibit 3rd part transfers How? Given a choice between turning customers away or paying (say) $100,000 for a legacy /16, what do you think most ISPs would choose? > We have a cartel today and the price is zero. No it isn't. RIR membership is not free and the real costs are hidden in bureaucracy. The whole reason a black market exists is because some people believe those costs are too high. > It's been like > that for many years now and nobody is complaining or investigating > the RIRs. People do complain, but that's not really relevant. We're dealing with a fundamental shift in the environment. The RIRs were created during a period of resource abundance. It should be obvious by now that the policies created in that environment aren't particular applicable to an environment of resource scarcity. As for investigations, they may come later, depending on what the RIRs do in the future. Hint: some folks don't look highly on cartels that block free competitive markets (for good or ill). Regards, -drc From jwkckid1 at ix.netcom.com Thu Jul 23 08:35:21 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Wed, 22 Jul 2009 23:35:21 -0700 Subject: [address-policy-wg] RE: The price of address space References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <6389FA79-E91C-494D-BB8A-B37A431C9A89@virtualized.org> Message-ID: <4A6804A9.E181714A@ix.netcom.com> David and all, Good comments and thoughts here. Indeed the RIR were created in a time of abundance and even than much discussion was ongoing about too liberal of a allocation policy. Those arguments and proposals for being conservative than were not well received very well. Now the price is being paid and pain felt accordingly. Still, recovery of IPv4 excess allocations or unused allocations is possible all be it perhaps difficult, buy the RIR's. Seems though that motivation in doing so by the RIR's is very low if such exists at all any more. Such is a shame. If this is not done or resumed, a black market for IPv4 address space will/is likely to flourish. That would/is not a healthy thing IMHO... David Conrad wrote: > Michael, > > On Jul 22, 2009, at 2:50 PM, > wrote: > > Equilibrium? When I learned basic economics, scarcity caused > > prices to rise. After IPv4 runout, every block sold just makes > > IPv4 addresses scarcer which means that there will be no equilibrium, > > > just increases until nobody can afford to pay the price. > > Which is an equilibrium. Not that this would occur, of course. You > seem to believe there is no constraint on the price of IPv4 > addresses. This is silly. > > If you are an enterprise, how many public IPv4 addresses do you really > need? How many of your machines could be renumbered at some cost into > RFC 1918 space and put behind a NAT? If you are an ISP, how many > addresses do you give your customers by default? How many do they > really need? How much internal infrastructure is numbered in public > IPv4 that could be renumbered into RFC 1918 space (or better yet, > renumbered into IPv6) if you could somehow find someone to pay for it? > > As the cost of IPv4 goes up, there will be increasing incentives to > make more efficient use of the address space. People will consolidate > their address holdings, putting their allocated-but-unused IPv4 > address onto the market. Since this is increasing the supply of > usable IPv4 addresses, this will tend to drive the price down. > > > Then the whole thing comes crashing down when IPv6 gathers enough > > momentum and people start releasing large amounts of IPv4 addresses. > > And you don't believe the anticipation of IPv6 deployment would have a > depressive effect on an IPv4 market? > > > We could prohibit 3rd part transfers > > How? Given a choice between turning customers away or paying (say) > $100,000 for a legacy /16, what do you think most ISPs would choose? > > > We have a cartel today and the price is zero. > > No it isn't. RIR membership is not free and the real costs are hidden > in bureaucracy. The whole reason a black market exists is because > some people believe those costs are too high. > > > It's been like > > that for many years now and nobody is complaining or investigating > > the RIRs. > > People do complain, but that's not really relevant. We're dealing > with a fundamental shift in the environment. The RIRs were created > during a period of resource abundance. It should be obvious by now > that the policies created in that environment aren't particular > applicable to an environment of resource scarcity. As for > investigations, they may come later, depending on what the RIRs do in > the future. Hint: some folks don't look highly on cartels that block > free competitive markets (for good or ill). > > Regards, > -drc Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From cgrundemann at gmail.com Thu Jul 23 00:00:14 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 22 Jul 2009 16:00:14 -0600 Subject: [address-policy-wg] Re: [arin-ppml] Offer to buy IP address block (was Spectrum and IP address reservations) In-Reply-To: <28E139F46D45AF49A31950F88C497458024922EB@E03MVZ2-UKDY.domain1.systemhost.net> References: <1F6404CD-A0B2-42D4-A849-ED5E9F9D89E5@eyeconomics.com> <28E139F46D45AF49A31950F88C497458024922EB@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <443de7ad0907221500v33162ba2x6294d6ee52d2c742@mail.gmail.com> On Wed, Jul 22, 2009 at 09:18, wrote: > >> More specifically, in this context I think that the tendency >> to assume that market mechanisms would infallibly convert the >> fact/existence/ supply of additional loose (de-assignable, >> transferable, etc.) IPv4 into the enduring condition of >> greater openness to aspiring new entrants is based on the >> widespread (mis)perception of individual IPv4 addresses and >> prefixes as "things" (assets, commodities, etc.), when in >> fact they actually represent something more like discrete >> instances of a "generalized ?privilege" ?or "license" (as in >> "creative license" >> even more than "driver's license"). > > The minimum ARIN allocation to a new ISP is currently a /20. > Someone recently offered an American ISP 6 figures for a > /20 block that was acquired as part of a corporate acquisition. > The ISP declined the offer and returned the block to ARIN. > > This could mean that the value of a /20 on the open market is > 100,000 USD. Since a /20 has 16 /24 equivalents in it, that would > place the value of a /24 at 6250 USD. http://xkcd.com/605/ > According to > > in the first 6 months of 2009, ARIN issued 99,285 /24 equivalents > to ISPs. That means that ARIN issued 620,531,250 USD worth > of IP addresses. Over the course of 2009 we can expect some > 1.2 billion dollars worth of IPv4 addresses to be allocated > to ISPs, or $103 million per month. > > Where is the industry going to find 1.2 billion dollars to sustain > growth of the network after IPv4 runout? And where is a new entrant > going to find $100,000 to buy their first allocation, assuming that > the price doesn't rise even higher when the free alternative no > longer exists? > > Will the prices in Europe be any different than in America? > Why? > > --Michael Dillon > > P.S. note that there are more predictable costs to an ISP > in deploying either carrier-grade NAT or transitioning to IPv6. > How will this impact IP address block prices and why? > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Chris Grundemann weblog.chrisgrundemann.com www.twitter.com/chrisgrundemann www.coisoc.org From jwkckid1 at ix.netcom.com Thu Jul 23 12:16:43 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Thu, 23 Jul 2009 03:16:43 -0700 Subject: [address-policy-wg] Re: [arin-ppml] Offer to buy IP address block (was Spectrum and IPaddress reservations) References: <1F6404CD-A0B2-42D4-A849-ED5E9F9D89E5@eyeconomics.com> <28E139F46D45AF49A31950F88C497458024922EB@E03MVZ2-UKDY.domain1.systemhost.net> <443de7ad0907221500v33162ba2x6294d6ee52d2c742@mail.gmail.com> Message-ID: <4A68388B.C9BB60F@ix.netcom.com> Chris and all, Well in respect to your "Funny" link. Thank god I won't have a similar number of wives anytime soon! >;) Chris Grundemann wrote: > On Wed, Jul 22, 2009 at 09:18, wrote: > > > >> More specifically, in this context I think that the tendency > >> to assume that market mechanisms would infallibly convert the > >> fact/existence/ supply of additional loose (de-assignable, > >> transferable, etc.) IPv4 into the enduring condition of > >> greater openness to aspiring new entrants is based on the > >> widespread (mis)perception of individual IPv4 addresses and > >> prefixes as "things" (assets, commodities, etc.), when in > >> fact they actually represent something more like discrete > >> instances of a "generalized privilege" or "license" (as in > >> "creative license" > >> even more than "driver's license"). > > > > The minimum ARIN allocation to a new ISP is currently a /20. > > Someone recently offered an American ISP 6 figures for a > > /20 block that was acquired as part of a corporate acquisition. > > The ISP declined the offer and returned the block to ARIN. > > > > This could mean that the value of a /20 on the open market is > > 100,000 USD. Since a /20 has 16 /24 equivalents in it, that would > > place the value of a /24 at 6250 USD. > > http://xkcd.com/605/ > > > According to > > > > in the first 6 months of 2009, ARIN issued 99,285 /24 equivalents > > to ISPs. That means that ARIN issued 620,531,250 USD worth > > of IP addresses. Over the course of 2009 we can expect some > > 1.2 billion dollars worth of IPv4 addresses to be allocated > > to ISPs, or $103 million per month. > > > > Where is the industry going to find 1.2 billion dollars to sustain > > growth of the network after IPv4 runout? And where is a new entrant > > going to find $100,000 to buy their first allocation, assuming that > > the price doesn't rise even higher when the free alternative no > > longer exists? > > > > Will the prices in Europe be any different than in America? > > Why? > > > > --Michael Dillon > > > > P.S. note that there are more predictable costs to an ISP > > in deploying either carrier-grade NAT or transitioning to IPv6. > > How will this impact IP address block prices and why? > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > -- > Chris Grundemann > weblog.chrisgrundemann.com > www.twitter.com/chrisgrundemann > www.coisoc.org Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From Jose.Abreu at sibs.pt Thu Jul 23 10:21:21 2009 From: Jose.Abreu at sibs.pt (=?GB2312?B?Sm9zqKYgQWJyZXU=?=) Date: Thu, 23 Jul 2009 09:21:21 +0100 Subject: [address-policy-wg] Re: [arin-ppml] Offer to buy IP address block (was Spectrum and IPaddress reservations) In-Reply-To: <4A68388B.C9BB60F@ix.netcom.com> References: <1F6404CD-A0B2-42D4-A849-ED5E9F9D89E5@eyeconomics.com> <28E139F46D45AF49A31950F88C497458024922EB@E03MVZ2-UKDY.domain1.systemhost.net> <443de7ad0907221500v33162ba2x6294d6ee52d2c742@mail.gmail.com> <4A68388B.C9BB60F@ix.netcom.com> Message-ID: Would it be possible to remove my email address from this list? Thank you. Best regards Jos? Paulo Abreu Technical Infrastructure Department Communications and Networks Management SIBS: forward payment solutions ? 25 years moving forward Rua Soeiro Pereira Gomes, Lote 1 ? 1649-031 Lisboa ? Portugal Phone: (+351) 217 813 224 ? Fax: (+351) 217 918 820 www.sibs.pt -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jeffrey A. Williams Sent: quinta-feira, 23 de Julho de 2009 11:17 To: Chris Grundemann Cc: michael.dillon at bt.com; address-policy-wg at ripe.net; ppml at arin.net Subject: Re: [address-policy-wg] Re: [arin-ppml] Offer to buy IP address block (was Spectrum and IPaddress reservations) Chris and all, Well in respect to your "Funny" link. Thank god I won't have a similar number of wives anytime soon! >;) Chris Grundemann wrote: > On Wed, Jul 22, 2009 at 09:18, wrote: > > > >> More specifically, in this context I think that the tendency > >> to assume that market mechanisms would infallibly convert the > >> fact/existence/ supply of additional loose (de-assignable, > >> transferable, etc.) IPv4 into the enduring condition of > >> greater openness to aspiring new entrants is based on the > >> widespread (mis)perception of individual IPv4 addresses and > >> prefixes as "things" (assets, commodities, etc.), when in > >> fact they actually represent something more like discrete > >> instances of a "generalized privilege" or "license" (as in > >> "creative license" > >> even more than "driver's license"). > > > > The minimum ARIN allocation to a new ISP is currently a /20. > > Someone recently offered an American ISP 6 figures for a > > /20 block that was acquired as part of a corporate acquisition. > > The ISP declined the offer and returned the block to ARIN. > > > > This could mean that the value of a /20 on the open market is > > 100,000 USD. Since a /20 has 16 /24 equivalents in it, that would > > place the value of a /24 at 6250 USD. > > http://xkcd.com/605/ > > > According to > > > > in the first 6 months of 2009, ARIN issued 99,285 /24 equivalents > > to ISPs. That means that ARIN issued 620,531,250 USD worth > > of IP addresses. Over the course of 2009 we can expect some > > 1.2 billion dollars worth of IPv4 addresses to be allocated > > to ISPs, or $103 million per month. > > > > Where is the industry going to find 1.2 billion dollars to sustain > > growth of the network after IPv4 runout? And where is a new entrant > > going to find $100,000 to buy their first allocation, assuming that > > the price doesn't rise even higher when the free alternative no > > longer exists? > > > > Will the prices in Europe be any different than in America? > > Why? > > > > --Michael Dillon > > > > P.S. note that there are more predictable costs to an ISP > > in deploying either carrier-grade NAT or transitioning to IPv6. > > How will this impact IP address block prices and why? > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > -- > Chris Grundemann > weblog.chrisgrundemann.com > www.twitter.com/chrisgrundemann > www.coisoc.org Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 AVISO. A mensagem e eventuais anexos s?o suscept?veis de conter informa??o sujeita a sigilo profissional, ao regime legal de protec??o de dados pessoais, de direitos de autor ou outro, pelo que a sua divulga??o depende de autoriza??o do remetente. As opini?es emitidas n?o vinculam necessariamente a SIBS. No caso desta mensagem ser recebida com erro ou por destinat?rios indevidos, solicita-se a sua destrui??o e subsequente aviso para postmaster at sibs.pt. A mensagem foi filtrada por um detector de v?rus, pelo que o remetente e a empresa n?o se responsabilizam por danos provocados por terceiros no sistema de informa??o do destinat?rio. WARNING. The message or attachments, if any, may be subject to professional confidentiality, personal data protection, copyright or other legal disclosure restrictions, and, therefore, access by anyone else is subject to the senders? authorization. Any views expressed do not necessarily reflect those of SIBS. If you are not te intended addressee or have received this e-mail in error, please delete it and notify postmaster at sibs.pt. A virus checker sweeps outgoing e-mail. Therefore, neither the sender nor the company accept any responsibility or liability whatsoever for any adverse effects on your systems or data arising from intercepted, corrupted or virus-infected e-mail. From jim at rfc1035.com Thu Jul 23 11:11:03 2009 From: jim at rfc1035.com (Jim Reid) Date: Thu, 23 Jul 2009 10:11:03 +0100 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <2C4A4EB5-DC61-4F77-B992-4394016AA328@rfc1035.com> On 22 Jul 2009, at 22:50, wrote: > I think that we all realise that in a real market, prices go > up and down with every transaction. So, given that someone is > willing to offer 100,000 USD for a /20 today, when there are > free alternatives at the RIR, what do you think the going rate > will be after the free alternative is gone? I have no idea. And neither does anyone else. As I said earlier there are too many unknowns and assumptions to make any meaningful predictions here. If all other parameters remained unchanged from today, it would be reasonable to expect the going rate for that /20 will be higher in a post run-out world. But the parameters will almost certainly be different by then. Any market in IPv4 could have a glut of ERX space depressing prices, IPv6 may be more attractive because the world's CPE and routers implement it, NAT is cheaper/better then than it is today, X.25 makes a comeback, the Internet's Next Big Thing is IPv6-only, RIR transfer policies change, ISPs and telcos dispose of zillions of unwanted IPv4 space because they've switched to IPv6, etc, etc. And if/when there is a mass uptake of IPv6, IPv4 space will become as valuable as VHS tape: impossible to even give away. All I'd be prepared to predict is that /20 in a post run-out world could be worth somewhere between zero and a few billion dollars. I'm not even sure what the margin of error on that estimate might be. >> If we assume there will be a market in IPv4 after the >> run-out, we should expect the usual laws of supply and demand >> will mean there's some sort of price equilibrium in the >> market. > > Equilibrium? When I learned basic economics, scarcity caused > prices to rise. IIUC "equilibrium" has a specific meaning in economics: when buyers and sellers agree on a price. This is independent of the availability of what's being traded. If there's a glut of some commodity and nobody's buying, the price is too high. The same holds if the commodity is scarce and no-one's buying. Buyers are of course usually prepared to pay more for something that's in short supply. That doesn't mean they will pay the seller's asking price regardless. Or that the price of a scarce resource can only increase: how much is a LaserDisc player worth today? > You may not be able to predict exact prices, but you can do pretty > good > at predicting minimum and maximum prices relative to a hard currency, > i.e. ounces of gold or barrels of crude, or Big Macs. That might hold for some conditions in a mature market. I'm doubtful it applies to something as immature and unstable as today's barely established trading in IPv4 space. If we can even call this "trading". That activity doesn't (yet) have the same roles, characteristics and legal frameworks found in (say) a commodities exchange or futures market. > How cheap do IPv4 addresses need to be to make it worthwhile for an > equipment vendor to buy up addresses today to drive up the price and > make it worthwhile for the market to buy carrier grade NAT boxes? I don't accept your starting premise, but let's play along. Apart from the attention of competition authorities, it would be a very, very risky business strategy to try and corner the world's IPv4 space. For one thing that empire could be eliminated overnight by the availability of "free" IPv6 addresses, particularly if the cost of deploying IPv6 was less than buying IPv4 from the monopolist who gobbled up the v4 space. And if the price of this vendor's NAT solutions were artificially high to capitalise on the distorted expense of IPv4, that leaves plenty of room for their competitors to undercut them. > We have a cartel today and the price is zero. It's been like that > for many years now and nobody is complaining or investigating the > RIRs. It would be unwise to assume that will always be the case. Especially when the availability of IPv4 gets the attention of regulators and politicians. Or if the RIRs have some sort of involvement in a market in address space: a clearing house for transactions or whatever. Once an open market develops, the concept of IP addresses as property will follow and that will surely attract attention from governments and competition authorities. > I agree on that. Where are all the economics grad students? Given the current state of the financial sector, I expect most of them will have McJobs in somwhere like a coffee shop or fast food outlet. :-) > P.S. My position is that IPv6 is the answer I agree wholeheartedly. My personal opinion is to leave the IPv4 policies as they are. Any changes will be like re-arranging the deckchairs on the Titanic. And will look bad to the outside world when they finally wake up to the imminent exhaustion of IPv4 space. We should stop worrying about IPv4 or speculating about what a future market in IPv4 might look like. [Though an open question is what the role of the RIRs might be in that market.] IMO, it's best to concentrate on IPv6 deployment and getting on with that migration. From ingrid at ripe.net Thu Jul 23 11:36:09 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Thu, 23 Jul 2009 11:36:09 +0200 Subject: [address-policy-wg] 2009-06 New Draft Document Published (Removing Routing Requirements from the IPv6 Address Allocation Policy) Message-ID: <20090723093609.B04372F583@herring.ripe.net> PDP Number: 2009-06 Removing Routing Requirements from the IPv6 Address Allocation Policy Dear Colleagues The draft document for the proposal described in 2009-06 has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-06.html and the draft document at: http://www.ripe.net/ripe/draft-documents/2009-06-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 20 August 2009. Regards Ingrid Wijte Policy Development Officer From bmanning at vacation.karoshi.com Thu Jul 23 11:51:44 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 23 Jul 2009 09:51:44 +0000 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <2C4A4EB5-DC61-4F77-B992-4394016AA328@rfc1035.com> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <2C4A4EB5-DC61-4F77-B992-4394016AA328@rfc1035.com> Message-ID: <20090723095144.GA10019@vacation.karoshi.com.> > etc. And if/when there is a mass uptake of IPv6, IPv4 space will > become as valuable as VHS tape: impossible to even give away. and one of my 80's bands just released their latest on 8track... no MP3, no LP, no CD... an 8track. I hate them. > that the price of a scarce resource can only increase: how much is a > LaserDisc player worth today? depends on how badly I need to watch the ChuckJones pre-estate fight, can't get anywhere else but the laser-disk version of BugsBunny. > >at predicting minimum and maximum prices relative to a hard currency, > >i.e. ounces of gold or barrels of crude, or Big Macs. BigMacs are only hard if left out for 6years.. takes that long for the bun to toughen up. > >P.S. My position is that IPv6 is the answer > > I agree wholeheartedly. My personal opinion is to leave the IPv4 > policies as they are. Any changes will be like re-arranging the > deckchairs on the Titanic. And will look bad to the outside world when > they finally wake up to the imminent exhaustion of IPv4 space. We > should stop worrying about IPv4 or speculating about what a future > market in IPv4 might look like. [Though an open question is what the > role of the RIRs might be in that market.] IMO, it's best to > concentrate on IPv6 deployment and getting on with that migration. pragmatically, there is a genuine need to retain IPv4 for the forseeable future - at least until significant software replacement is done. Too much depends on an IPv4 like thing (AAA, radius, SYSLOG, SNMP, etc) to expect wholesale abandonment of v4 in the next - say - 5-10 years. v4 just won't be wasted on endsystems :) (and Jim, you use of technologies that have been OBE'd in the commodity space was a joyful trip down memory lane.... ) --bill From bmanning at vacation.karoshi.com Thu Jul 23 12:52:23 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 23 Jul 2009 10:52:23 +0000 Subject: [address-policy-wg] long term useful life expectancy for IPv4 Message-ID: <20090723105223.GA10554@vacation.karoshi.com.> would like to move the discussion to: http://www.longbets.org/about seems like a better place to hold this debate than policy fora. --bill From jim at reptiles.org Thu Jul 23 13:18:12 2009 From: jim at reptiles.org (Jim Mercer) Date: Thu, 23 Jul 2009 07:18:12 -0400 Subject: [address-policy-wg] Re: [arin-ppml] Offer to buy IP address block (was Spectrum and IP address reservations) In-Reply-To: <28E139F46D45AF49A31950F88C497458024924D0@E03MVZ2-UKDY.domain1.systemhost.net> References: <443de7ad0907221500v33162ba2x6294d6ee52d2c742@mail.gmail.com> <28E139F46D45AF49A31950F88C497458024924D0@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20090723111812.GA68894@reptiles.org> On Wed, Jul 22, 2009 at 11:35:50PM +0100, michael.dillon at bt.com wrote: > > > Someone recently offered an American ISP 6 figures for a /20 block > > > that was acquired as part of a corporate acquisition. > > > The ISP declined the offer and returned the block to ARIN. > > > > > > This could mean that the value of a /20 on the open market > > is 100,000 > > > USD. Since a /20 has 16 /24 equivalents in it, that would place the > > > value of a /24 at 6250 USD. > > > > http://xkcd.com/605/ > > Not terribly relevant to IPv4 addresses. hugely relevant, as the extrapolation above is based on way, way, way too few datapoints/samples. > So there you have two actual price offers showing a substantial > range of values. Someone with actual economical statistics experience > may be able to suggest a likely distribution of prices over this > price range and come up with a more likely value of ARIN's annual > ISP allocations. the first example was a price offered by a company that obviously had way too much surplus cash around, and apparently didn't qualify for their own block. the second example (spammers looking to rent a block) is a bit of a stretch as well. -- Jim Mercer jim at reptiles.org +971 55 410-5633 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From lear at cisco.com Thu Jul 23 13:26:59 2009 From: lear at cisco.com (Eliot Lear) Date: Thu, 23 Jul 2009 13:26:59 +0200 Subject: [address-policy-wg] Re: [arin-ppml] The price of address space In-Reply-To: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4A684903.60009@cisco.com> On 7/22/09 11:50 PM, michael.dillon at bt.com wrote: > How cheap do IPv4 addresses need to be to make it worthwhile for an > equipment vendor to buy up addresses today to drive up the price and > make it worthwhile for the market to buy carrier grade NAT boxes? > If you attend next week's IETF in Sweden, you will see quite a number of Cisco employees involved in nearly every aspect of IPv6, including transition technologies. We are there because we continue to believe that there is no Plan B(*), that IPv6 is the best way for the Internet to grow. We are also there because many of our service provider customers are in agreement. What we all seem to recognize is that there is a challenging transition period coming, and that it will have to be carefully managed by vendors, service providers, and large enterprises. Eliot (*) One could argue that we are still cooking Plan A. For those who attend IETF, there is a draft, for instance, that looks at improving both TCP and DNS timers to ease transition. This builds on work that Stuart Cheshire presented some time ago. From jwkckid1 at ix.netcom.com Thu Jul 23 15:48:06 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Thu, 23 Jul 2009 06:48:06 -0700 Subject: [address-policy-wg] RE: The price of address space References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <2C4A4EB5-DC61-4F77-B992-4394016AA328@rfc1035.com> <20090723095144.GA10019@vacation.karoshi.com.> Message-ID: <4A686A15.230858AB@ix.netcom.com> Bill and all, FWIW, I agree that IPv4 is going to be around for at least 5 years longer. I love 8Tracks BTW. >;) So if you need a good 8Track player, or recorder for that matter, I have several of each still new in the box! I also have three 8Track dubbers... I'll consider a trade for a /24 IPv4 for either one of the new in the box 8track player or even one of the 8track dubbers. Seems a fair trade to me. Antiques in new condition ain't cheap! >:) bmanning at vacation.karoshi.com wrote: > > etc. And if/when there is a mass uptake of IPv6, IPv4 space will > > become as valuable as VHS tape: impossible to even give away. > > and one of my 80's bands just released their latest > on 8track... no MP3, no LP, no CD... an 8track. I hate them. > > > that the price of a scarce resource can only increase: how much is a > > LaserDisc player worth today? > > depends on how badly I need to watch the ChuckJones pre-estate > fight, can't get anywhere else but the laser-disk version of > BugsBunny. > > > >at predicting minimum and maximum prices relative to a hard currency, > > >i.e. ounces of gold or barrels of crude, or Big Macs. > > BigMacs are only hard if left out for 6years.. takes that long > for the bun to toughen up. > > > >P.S. My position is that IPv6 is the answer > > > > I agree wholeheartedly. My personal opinion is to leave the IPv4 > > policies as they are. Any changes will be like re-arranging the > > deckchairs on the Titanic. And will look bad to the outside world when > > they finally wake up to the imminent exhaustion of IPv4 space. We > > should stop worrying about IPv4 or speculating about what a future > > market in IPv4 might look like. [Though an open question is what the > > role of the RIRs might be in that market.] IMO, it's best to > > concentrate on IPv6 deployment and getting on with that migration. > > pragmatically, there is a genuine need to retain IPv4 > for the forseeable future - at least until significant > software replacement is done. Too much depends on an IPv4 > like thing (AAA, radius, SYSLOG, SNMP, etc) to expect > wholesale abandonment of v4 in the next - say - 5-10 years. > > v4 just won't be wasted on endsystems :) > > (and Jim, you use of technologies that have been OBE'd in the commodity > space was a joyful trip down memory lane.... ) > > --bill Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From tvest at eyeconomics.com Thu Jul 23 14:14:41 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 23 Jul 2009 08:14:41 -0400 Subject: [address-policy-wg] The price of address space In-Reply-To: <51AA4CA9-122E-4E58-A05D-D3AF5023885B@rfc1035.com> References: <28E139F46D45AF49A31950F88C497458024922EB@E03MVZ2-UKDY.domain1.systemhost.net> <51AA4CA9-122E-4E58-A05D-D3AF5023885B@rfc1035.com> Message-ID: <06FAA8D0-8571-4E15-A56A-9AC61F85052B@eyeconomics.com> On Jul 22, 2009, at 12:32 PM, Jim Reid wrote: > On 22 Jul 2009, at 16:18, > wrote: > >> Where is the industry going to find 1.2 billion dollars to sustain >> growth of the network after IPv4 runout? And where is a new entrant >> going to find $100,000 to buy their first allocation, assuming that >> the price doesn't rise even higher when the free alternative no >> longer exists? > > I'm reminded of the late 90's .com joke/business model about how to > becomea multi-billionaire: Set up a company with 100Bn shares. Sell > one share to yourself for $5. Congratulations! Your company is now > worth $500Bn. So exchange your company's paper for a medium-sized > country. > > To be serious, I think it's unwise to extrapolate from your anecdote > about someone offering a six figure sum for a /20. Or to use that as > the basis for a valuation of the allocated and/or yet-to-be- > allocated IPv4 address space. For one thing, who could possibly know > for sure if the figure you quoted that was offered recently will be > the going rate for a /20 after the IPv4 run-out? If someone can do > that, please provide me with the winning numbers for next week's > lottery.... :-) > > If we assume there will be a market in IPv4 after the run-out, we > should expect the usual laws of supply and demand will mean there's > some sort of price equilibrium in the market. Hi Jim, I'd have to say that that depends a lot on what you mean by "equilibrium." In principle, in an IPv4 transfer market that has some aspiring buyers and some aspiring sellers sellers, some transfer transactions may occur, and any average of the sum of prices paid that you find meaningful (e.g., price per /32, or any other prefix size of interest) could be described as the equilibrium price at that point in time. In practice, however, that's a entirely "academic," if not utterly meaningless statement. In the absence of a mandatory central clearing house for all transfer transactions, the only "information" on prevailing prices that will be available to anyone -- buyers or sellers -- will be whatever whispered rumors you can pick up in the halls of the next ops or IETF or policy meeting. Of course all transfer transactions will inevitably be covered under NDA, and so the only parties who might hypothetically have an incentive to share information (i.e., shell-shocked buyers) will be officially unable to do so. So there will be an equilibrium price, but it will be about as accessible to you and I -- or to any aspiring buyer or seller -- as the last digit of pi (or about as knowable as it is today, in the shadow market that some have alleged already exists). But even setting aside the problem of pervasive information asymmetries, there are several reasons to assume that the likely equilibrium price might be higher than you expect. First of all, know that at almost every point in time (until something very dramatic changes), most if not all potential IPv4 sellers are very likely to maintain a steep "reservation price" for IPv4; those that don't absolutely require a high minimum will be cleaned out as quickly as they enter the market -- by buyers who will act this way, if they're willing to sell at all. Second, any sign of substantial ongoing demand for IPv4 transfers among established, IPv4-based operators is likely to have a perverse effect on the minimum reservation prices of any remaining potential IPv4 sellers. Consider: today some operators express confidence in an imminent future of relatively transparent IPv6-based inter-domain routing -- i.e., one in which they will not suffer commercially if they can only offer IPv6 to their new and still-growing customers. That confidence is (necessarily) founded on the assumption that most if not all other operators will either be making their customers and resources accessible via IPv6 (one way or another), or else will be exiting the market. What will happen to that confidence if/when those IPv6- oriented pioneers observe that some of their peers are willing to pay a high price for any surplus IPv4 that they'd be willing to sell? How many of then will assume that the aspiring buyers are all suckers who are doomed to failure because of their apparent unwilling to incorporate IPv6 promptly? Alternately, how many will begin to wonder whether they should raise their reservation prices even higher -- either because the demand is there, or because their certainty in that IPv6-based future is marginally undermined? How many would decide to withhold their salable IPv4 altogether, at least until the future becomes a little less cloudy...? And of course, if there are even a small number of speculators in the market, these doubts are likely to be greatly amplified. A speculator doesn't care about which addressing format is better for customers, because they don't have any. For a speculator, the relative merits of IPv6 actually represent a threat, because the more compelling those merits are, the less profitable / less durable their IPv4 brokerage business is likely to be. If enough speculators are able to participate in the market, their preferences could have a big impact on which addressing standard(s) -- if any -- will be operationally or commercially viable in the future. And there is no barrier to deter speculators from entering the market, other than the willingness of service-operating IPv4 buyers and sellers to altruistically refuse to deal with them (i.e., even when they make the best offers). Granted, these observations reflect the kind of situation we're facing today, when very few resources are attached to the Internet with any form of IPv6, and very very few (if any) of those that are IPv6- attached are reachable from any other routing domain via any means that is not absolutely dependent on IPv4. People often point to this caveat by way of implying how different it will be when IPv6 is more widely deployed -- seemingly without noticing that such statements are tautological. Things will be different when they are different, no doubt -- but how will we get from here to there? Who's going to lead that charge so that others can make such statements with semantic content > 0 ? I have heard quite a few current operators -- by definition, all IPv4 holders -- suggest that post-IPv4 allocation-era new entrants will be the primary drivers for this transition. But from what we know from the allocation records and the routing table, etc., a nontrivial share of people saying (thinking?) this today must be among the vast majority of operators that do not currently offering native IPv6 routing services. Perhaps there is no contradiction, and people are saying/thinking such things because, today, they fully expect to offer some form of IPv6 as soon as that must-have-IPv6 demand grows. However, when that time does arrive, will prospective upstream providers have an incentive to offer native IPv6 routing -- i.e., the kind that would provide the IPv6-only newbie with the same kind of status that they themselves enjoy (where the lines between customer vs. peer vs. provider status are dictated by size and contract, not by inheritance or privileged access to a closed, proprietary technology)? Or, will the incumbent incentives favor offering the kind of IPv6 routing service that makes it substantially more difficult, if not structurally impossible, for the new entrant to organically transition into inter-domain peer or routing service provider roles as growth and other circumstances permit today? If private commercial incentives favor the latter in many/most cases, is competition from other, more IPv6-friendly routing services providers likely to be sufficient to ultimately tip the balance in favor of substitutability of IPv4 and IPv6 in inter-domain routing? It's anyone's guess, but I think some insight might be gleaned by talking to, for example, tier-two and smaller providers in Latin America and Africa that were operating before the establishment of LACNIC and AfriNIC -- i.e., in a times/places when new entrants had little or no choice but to obtain address resources as well as routing services from an incumbent commercial operator. > The point I'm making is that it doesn't seem sensible or even > possible to predict what these prices might be post run-out. Or > worry too much about that. Or to invent policies which somehow > influence or control those prices. [That might well have the look > and feel of a cartel.] It would be an interesting academic exercise > for economists to model the impact of various pricing scenarios > though I'm not sure how useful that would be in practice. That said, > it would be nice to have some sort of idea of the price points where > the trade-offs between buying IPv4 or using more NAT/ALG or > deploying IPv6 start to get fuzzy. I agree wholeheartedly that quantitative models that seek to predict point-specific IPv4 transfers prices are not constructive -- if only because no one who really could use such information is likely to trust them, no matter how accurate they might actually be. That said, I think that the application of a little common sense plus industry experience/know-how to the basic question can take one a long way toward understanding what kinds of outcomes are marginally more vs. less likely, and perhaps which are quite unlikely. > Any market that develops should be self-correcting. That is axiomatically true, but then there are some self-corrections that may not be appealing to all stakeholders. For those who are indifferent to the question of whether or not the inevitable correction will result in a future in which the IPv4/IPv6 distinction disappears, and how (e.g., because IPv6 becomes a viable substitute for IPv4, or because IPv4 lock-in makes it a permanent mandatory requirement for any aspiring routing services provider), there is a lot less to worry about. Others might want to give it some thought. TV From filiz at ripe.net Thu Jul 23 14:19:29 2009 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 23 Jul 2009 14:19:29 +0200 Subject: [address-policy-wg] 2009-02 Proposal Accepted (Allocating/Assigning Resources to the RIPE NCC) Message-ID: <20090723121929.647B12F59D@herring.ripe.net> PDP Number: 2009-02 Allocating/Assigning Resources to the RIPE NCC Dear Colleagues, Consensus has been reached, and the proposal described in 2009-02 has been accepted by the RIPE community. A new RIPE policy document, "Allocating/Assigning Resources to the RIPE NCC", is now published and can be found at: http://www.ripe.net/ripe/docs/ripe-476.html The proposal is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2009-02.html Thank you for your input. Regards, Filiz Yilmaz Policy Development Manager RIPE NCC From mohta at necom830.hpcl.titech.ac.jp Thu Jul 23 23:33:32 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 24 Jul 2009 06:33:32 +0900 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <6389FA79-E91C-494D-BB8A-B37A431C9A89@virtualized.org> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <6389FA79-E91C-494D-BB8A-B37A431C9A89@virtualized.org> Message-ID: <4A68D72C.2010004@necom830.hpcl.titech.ac.jp> David Conrad wrote: > As the cost of IPv4 goes up, there will be increasing incentives to > make more efficient use of the address space. Technically speaking , so true. Today, it is not neccesary to deploy IPv6 at all. > People will consolidate > their address holdings, putting their allocated-but-unused IPv4 address > onto the market. Since this is increasing the supply of usable IPv4 > addresses, this will tend to drive the price down. Not at all. Unless NICs reduce supply to a demand, enforcing the deployment of "more efficient use of the address space", LIRs will keep consuming the same amount of addresses, because, there is no economical drive for them to do otherwise and big economical drive to do so. That is, "more efficient use of the address space" may cost more and because "more efficient use of the address space" may be deployed after IPv4 addresses are exhausted, which means the LIRs can sell part of its address space, now not necessary for them, at very high price. > And you don't believe the anticipation of IPv6 deployment would have a > depressive effect on an IPv4 market? There would have been an effect, if most people had believed that IPv6 transition would have been completed long before IPv4 address exhaustion. Masataka Ohta From trejrco at gmail.com Fri Jul 24 00:09:57 2009 From: trejrco at gmail.com (trejrco at gmail.com) Date: Thu, 23 Jul 2009 22:09:57 +0000 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A68D72C.2010004@necom830.hpcl.titech.ac.jp> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <6389FA79-E91C-494D-BB8A-B37A431C9A89@virtualized.org><4A68D72C.2010004@necom830.hpcl.titech.ac.jp> Message-ID: <1858615964-1248386987-cardhu_decombobulator_blackberry.rim.net-1828180993-@bxe1082.bisx.prod.on.blackberry> I continue to be amazed at statements like: "Today, it is not necessary to deploy IPv6 at all." So, you firmly believe that everyone deploying (or preparing to deploy) IPv6 today is ... What, wasting time? Wrong? Stupid? Or, perhaps just (way?) ahead of the curve? As In not necessary now - but will be some day? Obviously, I continue to respectfully disagree it isn't needed - and am doing what I can to help environments get IPv6 deployed :). /TJ Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Masataka Ohta Date: Fri, 24 Jul 2009 06:33:32 To: David Conrad Cc: ; Subject: Re: [address-policy-wg] RE: The price of address space David Conrad wrote: > As the cost of IPv4 goes up, there will be increasing incentives to > make more efficient use of the address space. Technically speaking , so true. Today, it is not neccesary to deploy IPv6 at all. > People will consolidate > their address holdings, putting their allocated-but-unused IPv4 address > onto the market. Since this is increasing the supply of usable IPv4 > addresses, this will tend to drive the price down. Not at all. Unless NICs reduce supply to a demand, enforcing the deployment of "more efficient use of the address space", LIRs will keep consuming the same amount of addresses, because, there is no economical drive for them to do otherwise and big economical drive to do so. That is, "more efficient use of the address space" may cost more and because "more efficient use of the address space" may be deployed after IPv4 addresses are exhausted, which means the LIRs can sell part of its address space, now not necessary for them, at very high price. > And you don't believe the anticipation of IPv6 deployment would have a > depressive effect on an IPv4 market? There would have been an effect, if most people had believed that IPv6 transition would have been completed long before IPv4 address exhaustion. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Fri Jul 24 00:26:06 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 24 Jul 2009 07:26:06 +0900 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <1858615964-1248386987-cardhu_decombobulator_blackberry.rim.net-1828180993-@bxe1082.bisx.prod.on.blackberry> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <6389FA79-E91C-494D-BB8A-B37A431C9A89@virtualized.org><4A68D72C.2010004@necom830.hpcl.titech.ac.jp> <1858615964-1248386987-cardhu_decombobulator_blackberry.rim.net-1828180993-@bxe1082.bisx.prod.on.blackberry> Message-ID: <4A68E37E.70601@necom830.hpcl.titech.ac.jp> trejrco at gmail.com wrote: > I continue to be amazed at statements like: > "Today, it is not necessary to deploy IPv6 at all." > > So, you firmly believe that everyone deploying (or preparing to > deploy) IPv6 today is ... What, wasting time? Wrong? Stupid? As I said: > Technically speaking , so true. > Today, it is not neccesary to deploy IPv6 at all. valid counter arguments to me should have technical content. Masataka Ohta From nick at inex.ie Fri Jul 24 00:28:44 2009 From: nick at inex.ie (Nick Hilliard) Date: Thu, 23 Jul 2009 23:28:44 +0100 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <1858615964-1248386987-cardhu_decombobulator_blackberry.rim.net-1828180993-@bxe1082.bisx.prod.on.blackberry> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <6389FA79-E91C-494D-BB8A-B37A431C9A89@virtualized.org><4A68D72C.2010004@necom830.hpcl.titech.ac.jp> <1858615964-1248386987-cardhu_decombobulator_blackberry.rim.net-1828180993-@bxe1082.bisx.prod.on.blackberry> Message-ID: <4A68E41C.8030304@inex.ie> On 23/07/2009 23:09, trejrco at gmail.com wrote: > I continue to be amazed at statements like: > "Today, it is not necessary to deploy IPv6 at all." You shouldn't be. To understand why, you need to look at how much money businesses currently make on provisioning ipv4 services and compare that against how much money they make from provisioning ipv6 services. Or to turn the question around, can you build a useful internet business right now which is entirely ipv6 free? We need to appreciate that outside hobbyists and usenet news, deliberate ipv6 data transport is still tiny. This may change in a scenario of ipv4 address scarcity, but as most companies have not given any consideration whatever to how their business models will cope with ipv4 address scarcity, the question of ipv6 is still largely irrelevant to them. Nick From trejrco at gmail.com Fri Jul 24 00:48:57 2009 From: trejrco at gmail.com (trejrco at gmail.com) Date: Thu, 23 Jul 2009 22:48:57 +0000 Subject: [address-policy-wg] RE: The price of address space Message-ID: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> That doesn't answer what you believe about all those deploying v6, for whatever reasons they are deploying it ... (Reasons that vary from environment to environment) If you want me to start listing the technical merits of IPv6 I would first point you to a plethora of sources - working groups, RFCs, whitepapers, new product lines and modes of communication, etc. - are you really asking for a single email to encompass 10+ years of work by hundreds+ people? ((I can (and do!) talk about IPv6 for a week at a time and am still time-constrained to present all of the how's, why's, and what's of IPv6 ... The majority of this time is presenting IPv6 things which are technically better than their IPv4 analogs)) FWIW, I would also include entire conversations about how NAT is not a panacea, and already breaks / limits application capabilities, carries 'costs' of it's own (both literal $, packet/forwarding overhead, security), etc. Again - not a single aspect that can readily be presented in a single email (feel free to ref. BEHAVE, for example) Again - I am not opposed to efforts to make NAT more transparent / functional ... PMP, ALD, UPnP, perhaps e2e, etc. - however I see none of these as a replacement for IPv6, nor any other aspect of IPv6 that is a deal-breaker. Imperfections that perhaps need to be mitigated (whether that is a protocol or an implementation 'fix' remains to be seen) - but nothing preventing me (or anyone else) from using v6 today (or, even more common - belated vendor support - ugh). /TJ ------Original Message------ From: Masataka Ohta To: TJ Evans Cc: address-policy-wg-admin at ripe.net Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] RE: The price of address space Sent: Jul 23, 2009 18:26 trejrco at gmail.com wrote: > I continue to be amazed at statements like: > "Today, it is not necessary to deploy IPv6 at all." > > So, you firmly believe that everyone deploying (or preparing to > deploy) IPv6 today is ... What, wasting time? Wrong? Stupid? As I said: > Technically speaking , so true. > Today, it is not neccesary to deploy IPv6 at all. valid counter arguments to me should have technical content. Masataka Ohta Sent from my Verizon Wireless BlackBerry From trejrco at gmail.com Fri Jul 24 00:58:39 2009 From: trejrco at gmail.com (trejrco at gmail.com) Date: Thu, 23 Jul 2009 22:58:39 +0000 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A68E41C.8030304@inex.ie> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <6389FA79-E91C-494D-BB8A-B37A431C9A89@virtualized.org><4A68D72C.2010004@necom830.hpcl.titech.ac.jp> <1858615964-1248386987-cardhu_decombobulator_blackberry.rim.net-1828180993-@bxe1082.bisx.prod.on.blackberry><4A68E41C.8030304@inex.ie> Message-ID: <390290370-1248389912-cardhu_decombobulator_blackberry.rim.net-1960909626-@bxe1082.bisx.prod.on.blackberry> Perhaps I am taking a longer view - but any business should be following some sort of 3|5|7 year planning model ... And I just don't see a model where, within those time-frames, an Internet based business - or one with any real web-centric operations (online presence, consuming or providing services - or have clients/business partners who do) - can afford to ignore IPv6. So, does anyone NEED IPv6 deployed in their network TODAY ... Perhaps not. But if they haven't started the process (or at the very least evaluated the impacts of doing|not doing so!), and fall into the above category(ies), they are being short-sighted and perhaps even negligent. ((Still IMHO)) /TJ Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Nick Hilliard Date: Thu, 23 Jul 2009 23:28:44 To: Subject: Re: [address-policy-wg] RE: The price of address space On 23/07/2009 23:09, trejrco at gmail.com wrote: > I continue to be amazed at statements like: > "Today, it is not necessary to deploy IPv6 at all." You shouldn't be. To understand why, you need to look at how much money businesses currently make on provisioning ipv4 services and compare that against how much money they make from provisioning ipv6 services. Or to turn the question around, can you build a useful internet business right now which is entirely ipv6 free? We need to appreciate that outside hobbyists and usenet news, deliberate ipv6 data transport is still tiny. This may change in a scenario of ipv4 address scarcity, but as most companies have not given any consideration whatever to how their business models will cope with ipv4 address scarcity, the question of ipv6 is still largely irrelevant to them. Nick From mohta at necom830.hpcl.titech.ac.jp Fri Jul 24 01:33:06 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 24 Jul 2009 08:33:06 +0900 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <390290370-1248389912-cardhu_decombobulator_blackberry.rim.net-1960909626-@bxe1082.bisx.prod.on.blackberry> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <6389FA79-E91C-494D-BB8A-B37A431C9A89@virtualized.org><4A68D72C.2010004@necom830.hpcl.titech.ac.jp> <1858615964-1248386987-cardhu_decombobulator_blackberry.rim.net-1828180993-@bxe1082.bisx.prod.on.blackberry><4A68E41C.8030304@inex.ie> <390290370-1248389912-cardhu_decombobulator_blackberry.rim.net-1960909626-@bxe1082.bisx.prod.on.blackberry> Message-ID: <4A68F332.7000609@necom830.hpcl.titech.ac.jp> trejrco at gmail.com wrote: > Perhaps I am taking a longer view - but any business should be > following some sort of 3|5|7 year planning model ... You should have a longer retrospective view on what has been happening since 7*2 years ago when IPv6 was standardized. > So, does anyone NEED IPv6 deployed in their network TODAY ... > Perhaps not. But if they haven't started the process (or at > the very least evaluated the impacts of doing|not doing so!), > and fall into the above category(ies), they are being short-sighted > and perhaps even negligent. ((Still IMHO)) Why, do you think, that arguments similar to yours were popular 15 years ago but not now? What, do you think, have happened to those who followed the arguments 15 years ago? Masataka Ohta From trejrco at gmail.com Fri Jul 24 02:22:49 2009 From: trejrco at gmail.com (TJ) Date: Thu, 23 Jul 2009 20:22:49 -0400 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A68F332.7000609@necom830.hpcl.titech.ac.jp> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <6389FA79-E91C-494D-BB8A-B37A431C9A89@virtualized.org><4A68D72C.2010004@necom830.hpcl.titech.ac.jp> <1858615964-1248386987-cardhu_decombobulator_blackberry.rim.net-1828180993-@bxe1082.bisx.prod.on.blackberry><4A68E41C.8030304@inex.ie> <390290370-1248389912-cardhu_decombobulator_blackberry.rim.net-1960909626-@bxe1082.bisx.prod.on.blackberry> <4A68F332.7000609@necom830.hpcl.titech.ac.jp> Message-ID: <006b01ca0bf4$e0f663d0$a2e32b70$@com> >> Perhaps I am taking a longer view - but any business should be >> following some sort of 3|5|7 year planning model ... > >You should have a longer retrospective view on what has been happening since >7*2 years ago when IPv6 was standardized. I do ... and have seen many "This is the year of IPv6" style statements, which is not what I am saying. And again, I am not saying IPv6 was perfect. Are you saying you don't think anything relevant has changed in the last decade? Sorry, but I wholeheartedly disagree - I see that quite a bit has changed WRT IPv6. The protocol itself has been tweaked, the implementations of the protocol have evolved, the deployment guidelines for both and the understanding of all three of those things has been escalating rapidly over the last ~couple-few years ... >> So, does anyone NEED IPv6 deployed in their network TODAY ... >> Perhaps not. But if they haven't started the process (or at the very >> least evaluated the impacts of doing|not doing so!), and fall into the >> above category(ies), they are being short-sighted and perhaps even >> negligent. ((Still IMHO)) > >Why, do you think, that arguments similar to yours were popular >15 years ago but not now? (Asnwering what I think you meant to ask ...) Things hadn't progressed on some fronts (and degraded in others) to the point they are at now. As with any other fundamental change, it takes time to reach a threshold (a "tipping point", if you will). Are there still certain failures in how this whole deployment (or some would say, lack thereof) has transpired? Sure. Are there a few things that could have been done different (some would say, better)? Sure. Are any of those deal-breakers? IMHO, nope. In fact, "the perfect is the enemy of the good" - inaction due to certain failings is often worse than the alternative. >What, do you think, have happened to those who followed the arguments 15 years >ago? I believe that is something of a strawman. Naturally, if they were banking solely on an all_IPv6_only_IPv6 world they are most likely no longer around. I am not arguing for anyone to punt IPv4 completely, for quite some time anyway. BUT there are quite a few organizations that have been preparing for, and some actually running native IPv6, for several+ years ... and I firmly believe they will find themselves far more prepared for the time when we reach that "tipping point", and thus in a strategically beneficial position. /TJ PS - I ask again, what is your opinion of all of these organizations that are actively pursuing IPv6 deployments, encouraging environments to do so, etc. ... ? From mohta at necom830.hpcl.titech.ac.jp Fri Jul 24 03:19:18 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 24 Jul 2009 10:19:18 +0900 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <006b01ca0bf4$e0f663d0$a2e32b70$@com> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <6389FA79-E91C-494D-BB8A-B37A431C9A89@virtualized.org><4A68D72C.2010004@necom830.hpcl.titech.ac.jp> <1858615964-1248386987-cardhu_decombobulator_blackberry.rim.net-1828180993-@bxe1082.bisx.prod.on.blackberry><4A68E41C.8030304@inex.ie> <390290370-1248389912-cardhu_decombobulator_blackberry.rim.net-1960909626-@bxe1082.bisx.prod.on.blackberry> <4A68F332.7000609@necom830.hpcl.titech.ac.jp> <006b01ca0bf4$e0f663d0$a2e32b70$@com> Message-ID: <4A690C16.700@necom830.hpcl.titech.ac.jp> TJ wrote: > I do ... and have seen many "This is the year of IPv6" style statements, > which is not what I am saying. > Sorry, but I wholeheartedly disagree - I see that quite a bit has changed > WRT IPv6. > The protocol itself has been tweaked, the implementations of the protocol > have evolved, the deployment guidelines for both and the understanding of > all three of those things has been escalating rapidly over the last > ~couple-few years ... So obviously, you are saying "This is the year of IPv6". If you could have had a longer retrospective view, you could have noticed that your reasoning has been repeated so many times. Masataka Ohta From jwkckid1 at ix.netcom.com Fri Jul 24 05:30:20 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Thu, 23 Jul 2009 20:30:20 -0700 Subject: [address-policy-wg] RE: The price of address space References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <6389FA79-E91C-494D-BB8A-B37A431C9A89@virtualized.org><4A68D72C.2010004@necom830.hpcl.titech.ac.jp> <1858615964-1248386987-cardhu_decombobulator_blackberry.rim.net-1828180993-@bxe1082.bisx.prod.on.blackberry> Message-ID: <4A692ACC.338A73DE@ix.netcom.com> TJ and all, I for one see IPv6 as an essential. But it remains to be well received as was originally hoped for reasons already stated even if those reasons are short sighted. But, IPv6 IMO is only one step in progression that can be sidestepped with IPv8, which we have been steadily rolling out for several years now ever so slowly but deliberately. And of course IPv8 is much easier to implement, requires no application modification, and far cheaper than IPv6. Yet we continue to believe and support IPv6's eventual implementation even if for only to point up that it's expense makes IPv8 far more attractive. trejrco at gmail.com wrote: > I continue to be amazed at statements like: > "Today, it is not necessary to deploy IPv6 at all." > > So, you firmly believe that everyone deploying (or preparing to deploy) IPv6 today is ... What, wasting time? Wrong? Stupid? > > Or, perhaps just (way?) ahead of the curve? As In not necessary now - but will be some day? > > Obviously, I continue to respectfully disagree it isn't needed - and am doing what I can to help environments get IPv6 deployed :). > > /TJ > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Masataka Ohta > > Date: Fri, 24 Jul 2009 06:33:32 > To: David Conrad > Cc: ; > Subject: Re: [address-policy-wg] RE: The price of address space > > David Conrad wrote: > > > As the cost of IPv4 goes up, there will be increasing incentives to > > make more efficient use of the address space. > > Technically speaking , so true. > > Today, it is not neccesary to deploy IPv6 at all. > > > People will consolidate > > their address holdings, putting their allocated-but-unused IPv4 address > > onto the market. Since this is increasing the supply of usable IPv4 > > addresses, this will tend to drive the price down. > > Not at all. > > Unless NICs reduce supply to a demand, enforcing the deployment of > "more efficient use of the address space", LIRs will keep consuming > the same amount of addresses, because, there is no economical > drive for them to do otherwise and big economical drive to do so. > > That is, "more efficient use of the address space" may cost more > and because "more efficient use of the address space" may be > deployed after IPv4 addresses are exhausted, which means the LIRs > can sell part of its address space, now not necessary for them, > at very high price. > > > And you don't believe the anticipation of IPv6 deployment would have a > > depressive effect on an IPv4 market? > > There would have been an effect, if most people had believed that > IPv6 transition would have been completed long before IPv4 address > exhaustion. > > Masataka Ohta Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From trejrco at gmail.com Fri Jul 24 03:47:04 2009 From: trejrco at gmail.com (trejrco at gmail.com) Date: Fri, 24 Jul 2009 01:47:04 +0000 Subject: [address-policy-wg] RE: The price of address space Message-ID: <3126508-1248400034-cardhu_decombobulator_blackberry.rim.net-164440825-@bxe1082.bisx.prod.on.blackberry> And obviously you are missing my point. I am hardly saying "This is the year"... I do not think there will a single year that will define / be defined by what boils down to the deployment of better plumbing. Was there ever a "year of www", "year of SMTP", etc.? I think you misunderstand - I do have a fairly long view here, but believe that circumstances have changed | are changing. I could say the same thing about denial, but that leads us down a very non-productive path. Probably best to agree to disagree at this point ... /TJ (Although I am still interested in your (or anyone else's, for that matter) opinion of those deploying / planning to deploy / etc. IPv6 ... ) ------Original Message------ From: Masataka Ohta To: TJ Evans Cc: address-policy-wg-admin at ripe.net Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] RE: The price of address space Sent: Jul 23, 2009 21:19 TJ wrote: > I do ... and have seen many "This is the year of IPv6" style statements, > which is not what I am saying. > Sorry, but I wholeheartedly disagree - I see that quite a bit has changed > WRT IPv6. > The protocol itself has been tweaked, the implementations of the protocol > have evolved, the deployment guidelines for both and the understanding of > all three of those things has been escalating rapidly over the last > ~couple-few years ... So obviously, you are saying "This is the year of IPv6". If you could have had a longer retrospective view, you could have noticed that your reasoning has been repeated so many times. Masataka Ohta Sent from my Verizon Wireless BlackBerry From tedm at ipinc.net Fri Jul 24 00:24:55 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 23 Jul 2009 15:24:55 -0700 Subject: [address-policy-wg] Re: [arin-ppml] The price of address space In-Reply-To: <4A684903.60009@cisco.com> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <4A684903.60009@cisco.com> Message-ID: <4A68E337.7010802@ipinc.net> Eliot Lear wrote: > On 7/22/09 11:50 PM, michael.dillon at bt.com wrote: >> How cheap do IPv4 addresses need to be to make it worthwhile for an >> equipment vendor to buy up addresses today to drive up the price and >> make it worthwhile for the market to buy carrier grade NAT boxes? >> > > If you attend next week's IETF in Sweden, you will see quite a number of > Cisco employees involved in nearly every aspect of IPv6, including > transition technologies. We are there because we continue to believe > that there is no Plan B(*), that IPv6 is the best way for the Internet > to grow. Tell your coworkers that until Linksys-owned-by-Cisco gear gets IPv6 buttons in it, IPv6 ain't a real thing to any org under 50 employees. The RVS4000 is a good first step - now, let's extend that code to the rest of the Linksys product line. You don't want to be embarrassed by DD-WRT, after all, do you? Ted From ptimmins at clearrate.com Fri Jul 24 01:31:31 2009 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Thu, 23 Jul 2009 19:31:31 -0400 Subject: [address-policy-wg] RE: [arin-ppml] The price of address space In-Reply-To: <4A68E337.7010802@ipinc.net> References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net><4A684903.60009@cisco.com> <4A68E337.7010802@ipinc.net> Message-ID: And while you're at it, have them update the Sipura-owned-by-Linksys-owned-by-Cisco gear too, as those often contain routers too, and IPv6 support will end a lot of NAT headaches. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Thursday, July 23, 2009 6:25 PM To: Eliot Lear Cc: ppml at arin.net; address-policy-wg at ripe.net Subject: Re: [arin-ppml] The price of address space Eliot Lear wrote: > On 7/22/09 11:50 PM, michael.dillon at bt.com wrote: >> How cheap do IPv4 addresses need to be to make it worthwhile for an >> equipment vendor to buy up addresses today to drive up the price and >> make it worthwhile for the market to buy carrier grade NAT boxes? >> > > If you attend next week's IETF in Sweden, you will see quite a number of > Cisco employees involved in nearly every aspect of IPv6, including > transition technologies. We are there because we continue to believe > that there is no Plan B(*), that IPv6 is the best way for the Internet > to grow. Tell your coworkers that until Linksys-owned-by-Cisco gear gets IPv6 buttons in it, IPv6 ain't a real thing to any org under 50 employees. The RVS4000 is a good first step - now, let's extend that code to the rest of the Linksys product line. You don't want to be embarrassed by DD-WRT, after all, do you? Ted _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From jeroen at unfix.org Fri Jul 24 10:10:47 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 24 Jul 2009 10:10:47 +0200 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> Message-ID: <4A696C87.2090305@spaghetti.zurich.ibm.com> [I wonder where the policy discussion went....] [also, please fix your mailer, 200 column lines don't fit on most peoples displays...] trejrco at gmail.com wrote: > That doesn't answer what you believe about all those deploying v6, for > whatever reasons they are deploying it ... (Reasons that vary from environment to environment) > > > If you want me to start listing the technical merits of IPv6 I would first > point you to a plethora of sources - working groups, RFCs, whitepapers, new > product lines and modes of communication, etc. - are you really asking for > a single email to encompass 10+ years of work by hundreds+ people? Yes, please, please point me to all that information, because there are not so many 'merits', especially technical. And if you claim there are then either I am missing something really big, or you are just preaching what you don't understand. Try coming up with 5 one-liner points where IPv6 > IPv4. I'll give you the sole real merit: More address space. For the rest, there are not any that are significant, as they all can be done with IPv4. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From gert at space.net Fri Jul 24 10:20:37 2009 From: gert at space.net (Gert Doering) Date: Fri, 24 Jul 2009 10:20:37 +0200 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A696C87.2090305@spaghetti.zurich.ibm.com> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> Message-ID: <20090724082037.GI8076@Space.Net> Hi, On Fri, Jul 24, 2009 at 10:10:47AM +0200, Jeroen Massar wrote: > [I wonder where the policy discussion went....] Well said. While I do quite enjoy the occasional IPv6/IPv4 advocacy discussion, I would indeed prefer to keep *this* list a bit more focused on *address policy related* topics: - developments that have impact on RIPE address policy work (so the economic views would fall into this) - weak points or operational problems with the current RIPE policies - not-yet-formal ideas for improving RIPE policy - comments to ongoing RIPE policy proposals "Whether or not IPv6 is technically superior to IPv4" is considered off-topic, as it has no real impact on our work: defining policies that help giving numbers to all those that need some, in a fair and impartial way. We need policies for those that want IPv6 numbers, and we need policies for those that want some of the remaining IPv4 numbers. thanks. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From mohta at necom830.hpcl.titech.ac.jp Fri Jul 24 11:39:41 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 24 Jul 2009 18:39:41 +0900 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <20090724082037.GI8076@Space.Net> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> <20090724082037.GI8076@Space.Net> Message-ID: <4A69815D.6090106@necom830.hpcl.titech.ac.jp> Gert Doering wrote: > While I do quite enjoy the occasional IPv6/IPv4 advocacy discussion, > I would indeed prefer to keep *this* list a bit more focused on > *address policy related* topics: > and we need > policies for those that want some of the remaining IPv4 numbers. The problem is that IPv4 address policy is affected a *LOT* by an answer to the following question: When IPv6 will be really deployed? Note that "never" can be a valid answer. So, it is impossible to evaluate most, if not all, IPv4 address policy proposals without assuming an answer to the question. If you want to stop the discussion on the question, we must accept multiple assumptions on answers to the question and never criticise proposals for their assumptions on the answers. Then, we can peacefully reach a uniform consensus on mutually incompatible multiple address policies. Do you want to have them? Or, shall we just ask the question to IETF and blindly accept their answer? Masataka Ohta From jeroen at unfix.org Fri Jul 24 12:02:14 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 24 Jul 2009 12:02:14 +0200 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A69815D.6090106@necom830.hpcl.titech.ac.jp> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> <20090724082037.GI8076@Space.Net> <4A69815D.6090106@necom830.hpcl.titech.ac.jp> Message-ID: <4A6986A6.5060208@spaghetti.zurich.ibm.com> Masataka Ohta wrote: > Gert Doering wrote: > >> While I do quite enjoy the occasional IPv6/IPv4 advocacy discussion, >> I would indeed prefer to keep *this* list a bit more focused on >> *address policy related* topics: > >> and we need >> policies for those that want some of the remaining IPv4 numbers. > > The problem is that IPv4 address policy is affected a *LOT* by > an answer to the following question: > > When IPv6 will be really deployed? Depends on what you mean with that :) There are a lot of "depends" for a lot of questions. If you want a question answered you'll have to elaborate a lot on what you exactly mean. There are two known things though: - IPv4 address space is running short, and IANA will run out sooner or later, most likely in the next two years. - At that point in time your business has to have a solution. Possible solutions: - Do IPv6 - scales quite well, requires upgrades - Do IPv4 CGN - doesn't scale. Your pick on WHEN you are going to do that. Can do it today, can do it in ten years when the competition has your customers. Enjoy ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From gert at space.net Fri Jul 24 12:13:42 2009 From: gert at space.net (Gert Doering) Date: Fri, 24 Jul 2009 12:13:42 +0200 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A69815D.6090106@necom830.hpcl.titech.ac.jp> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> <20090724082037.GI8076@Space.Net> <4A69815D.6090106@necom830.hpcl.titech.ac.jp> Message-ID: <20090724101342.GM8076@Space.Net> Hi, On Fri, Jul 24, 2009 at 06:39:41PM +0900, Masataka Ohta wrote: > Gert Doering wrote: > > > While I do quite enjoy the occasional IPv6/IPv4 advocacy discussion, > > I would indeed prefer to keep *this* list a bit more focused on > > *address policy related* topics: > > > and we need > > policies for those that want some of the remaining IPv4 numbers. > > The problem is that IPv4 address policy is affected a *LOT* by > an answer to the following question: > > When IPv6 will be really deployed? > > Note that "never" can be a valid answer. This question is something that we simply cannot answer - and even if we could, it doesn't matter. Some people do deploy IPv6 today (whether or not they "really" deploy IPv6 does not matter at all, as long as they need addresses for whatever they do), so we need IPv6 address policies to enable those to do so. Other people deploy IPv4 today, and will continue to do so, for a time frame unknown to me. So we also need IPv4 address policies. If the IPv4 pool runs out, we need to handle this, policy-wise. If it doesn't, because the Internet stops growing, everybody does NAT, or everybody migrats to IPv6, we don't - but we won't know in advance, so it is useful to have a plan for the case that it does run out. So - while the answer of your question might matter a lot to the well-being of the Internet at large, it has hardly any relevance on the policy work we do: "distribute numbers to those people that need numbers for their work, in an open, fair, and transparent way". (Note everybody agrees whether we do an optimum job here, and much of what we do turns out years later to be a "good" or "bad" decision, but that's the problem with todays crystal balls) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From bmanning at vacation.karoshi.com Fri Jul 24 12:18:02 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 24 Jul 2009 10:18:02 +0000 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A6986A6.5060208@spaghetti.zurich.ibm.com> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> <20090724082037.GI8076@Space.Net> <4A69815D.6090106@necom830.hpcl.titech.ac.jp> <4A6986A6.5060208@spaghetti.zurich.ibm.com> Message-ID: <20090724101802.GA22029@vacation.karoshi.com.> On Fri, Jul 24, 2009 at 12:02:14PM +0200, Jeroen Massar wrote: > Masataka Ohta wrote: > > Gert Doering wrote: > > > >> While I do quite enjoy the occasional IPv6/IPv4 advocacy discussion, > >> I would indeed prefer to keep *this* list a bit more focused on > >> *address policy related* topics: > > > >> and we need > >> policies for those that want some of the remaining IPv4 numbers. > > > > The problem is that IPv4 address policy is affected a *LOT* by > > an answer to the following question: > > > > When IPv6 will be really deployed? > > Depends on what you mean with that :) amen. Ohta-san, please come visit. You will find that unless your network devices are capabile of IPv6 transport, you will have no connectivity. with the exception of the IVI box and the DNS server, nothing has an IPv4 address. the other 40+ devices onnet are all runing native IPv6. I would say that this is emperical evidence of IPv6 deployment. Would you disagree? --bill From mohta at necom830.hpcl.titech.ac.jp Fri Jul 24 13:08:25 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 24 Jul 2009 20:08:25 +0900 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A6986A6.5060208@spaghetti.zurich.ibm.com> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> <20090724082037.GI8076@Space.Net> <4A69815D.6090106@necom830.hpcl.titech.ac.jp> <4A6986A6.5060208@spaghetti.zurich.ibm.com> Message-ID: <4A699629.3080402@necom830.hpcl.titech.ac.jp> Jeroen Massar wrote: > - At that point in time your business has to have a solution. > Possible solutions: > - Do IPv6 - scales quite well, requires upgrades > - Do IPv4 CGN - doesn't scale. CGN not scale? NAT, in general including CGN, does scale to the extent to make IPv6 not necessary. > Your pick on WHEN you are going to do that. Can do it today, can do it > in ten years when the competition has your customers. Enjoy ;) If it is 10 years, we should use not IPv6 but something else. Masataka Ohta PS As you don't accept the answer "never", discussion on whether it will actually be "never" or not is inevitable. From mohta at necom830.hpcl.titech.ac.jp Fri Jul 24 15:26:59 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 24 Jul 2009 22:26:59 +0900 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <20090724101342.GM8076@Space.Net> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> <20090724082037.GI8076@Space.Net> <4A69815D.6090106@necom830.hpcl.titech.ac.jp> <20090724101342.GM8076@Space.Net> Message-ID: <4A69B6A3.8070904@necom830.hpcl.titech.ac.jp> Gert Doering wrote: > Other people deploy IPv4 today, and will continue to do so, for a time > frame unknown to me. So we also need IPv4 address policies. And the time frame is the essential factor for IPv4 address policies. > If the IPv4 pool runs out, we need to handle this, policy-wise. If it > doesn't, because the Internet stops growing, everybody does NAT, or > everybody migrats to IPv6, we don't - but we won't know in advance, so > it is useful to have a plan for the case that it does run out. Not. As is written in RIPE NCC activity plan 2009 http://www.ripe.net/ripe/docs/ap.html To provide a fair, impartial distribution of Internet number resources guided by the RIPE community policies based on the goals of uniqueness, conservation and aggregation we must know where the goal of conservation is. When (including "never") IPv4 pool runs out strongly depends on IPv4 address policy. > we do: "distribute numbers to those people that need numbers for their > work, in an open, fair, and transparent way". Fairness includes fairness between people requesting IPv4 address today and tomorrow. Masataka Ohta From jeroen at unfix.org Fri Jul 24 16:01:13 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 24 Jul 2009 16:01:13 +0200 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A699629.3080402@necom830.hpcl.titech.ac.jp> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> <20090724082037.GI8076@Space.Net> <4A69815D.6090106@necom830.hpcl.titech.ac.jp> <4A6986A6.5060208@spaghetti.zurich.ibm.com> <4A699629.3080402@necom830.hpcl.titech.ac.jp> Message-ID: <4A69BEA9.5060604@spaghetti.zurich.ibm.com> Masataka Ohta wrote: > Jeroen Massar wrote: > >> - At that point in time your business has to have a solution. >> Possible solutions: >> - Do IPv6 - scales quite well, requires upgrades >> - Do IPv4 CGN - doesn't scale. > > CGN not scale? > > NAT, in general including CGN, does scale to the extent to make > IPv6 not necessary. It scales on paper, till you start using it. 1 IPv4 address, 65k TCP ports, if one user opens maps.google, he uses 200 TCP sessions on average, thus 65k/200 == 332 users per IPv4 address. Yes, indeed, really "scales" well. CGNs will btw only delay the inevitable. (On the subject of CGN and content-restricting ISPs for CP and other 'legal reasons': I would actually simply go with an HTTP-only proxy. Nothing difficult, nothing to evade unless people start encoding their stuff inside HTTP) >> Your pick on WHEN you are going to do that. Can do it today, can do it >> in ten years when the competition has your customers. Enjoy ;) > > If it is 10 years, we should use not IPv6 but something else. You can do that, your competition will love you for it. [..] > As you don't accept the answer "never", discussion on whether it will > actually be "never" or not is inevitable. Give me one valid technical reason why I would accept "never"? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From mohta at necom830.hpcl.titech.ac.jp Fri Jul 24 16:46:17 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 24 Jul 2009 23:46:17 +0900 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A69BEA9.5060604@spaghetti.zurich.ibm.com> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> <20090724082037.GI8076@Space.Net> <4A69815D.6090106@necom830.hpcl.titech.ac.jp> <4A6986A6.5060208@spaghetti.zurich.ibm.com> <4A699629.3080402@necom830.hpcl.titech.ac.jp> <4A69BEA9.5060604@spaghetti.zurich.ibm.com> Message-ID: <4A69C939.4000205@necom830.hpcl.titech.ac.jp> Jeroen Massar wrote: >>NAT, in general including CGN, does scale to the extent to make >>IPv6 not necessary. > It scales on paper, till you start using it. > > 1 IPv4 address, 65k TCP ports, if one user opens maps.google, he uses > 200 TCP sessions on average, thus 65k/200 == 332 users per IPv4 address. 200 is a peak of an extra ordinary application and, even with the application, unused ports are closed quickly that dynamic allocation of ports save average port requirements. Note also that consumption of extra ordinary number of port is a state maintenance problem for NAT between 6 and 4. > Yes, indeed, really "scales" well. Yes, of course. > CGNs will btw only delay the inevitable. It is inevitable that protocols have lifetime, of course. A problem is that the lifetime of IPv6 has already expired. > (On the subject of CGN and content-restricting ISPs for CP and other Let's not discuss it here, because there are alternative ways to NAT. >>If it is 10 years, we should use not IPv6 but something else. > You can do that, your competition will love you for it. Considering that route aggregation is also an important goal of address policy, which IPv6 failed to address, we do need something else. >>As you don't accept the answer "never", discussion on whether it will >>actually be "never" or not is inevitable. > Give me one valid technical reason why I would accept "never"? Because, as you failed to argue against, it is no better than IPv4 with NAT. Masataka Ohta From jeroen at unfix.org Fri Jul 24 17:12:54 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 24 Jul 2009 17:12:54 +0200 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A69C939.4000205@necom830.hpcl.titech.ac.jp> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> <20090724082037.GI8076@Space.Net> <4A69815D.6090106@necom830.hpcl.titech.ac.jp> <4A6986A6.5060208@spaghetti.zurich.ibm.com> <4A699629.3080402@necom830.hpcl.titech.ac.jp> <4A69BEA9.5060604@spaghetti.zurich.ibm.com> <4A69C939.4000205@necom830.hpcl.titech.ac.jp> Message-ID: <4A69CF76.9080904@spaghetti.zurich.ibm.com> Masataka Ohta wrote: [..] >> You can do that, your competition will love you for it. > > Considering that route aggregation is also an important goal of > address policy, which IPv6 failed to address, we do need something > else. That is a routing issue, not an addressing issue (which is what IPv6 solves), and it definitely is not a policy issue; as such it doesn't below on this list anyway. >>> As you don't accept the answer "never", discussion on whether it will >>> actually be "never" or not is inevitable. > >> Give me one valid technical reason why I would accept "never"? > > Because, as you failed to argue against, it is no better than IPv4 > with NAT. We'll talk further when you realize what happens when you are trying to SSH from your cozy island vacation resort to your computer at home which is behind several layers of NAT (at least the one at home, as your ISP will still only give you 1 ISP-NATted address and thus also the ISP NATted one, possibly a couple of extra as the ISP didn't get any addresses either). Greets, Jeroen (Small hint: There is a reason why PuTTY has IPv6 support :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From mohta at necom830.hpcl.titech.ac.jp Fri Jul 24 17:44:51 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 25 Jul 2009 00:44:51 +0900 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A69CF76.9080904@spaghetti.zurich.ibm.com> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> <20090724082037.GI8076@Space.Net> <4A69815D.6090106@necom830.hpcl.titech.ac.jp> <4A6986A6.5060208@spaghetti.zurich.ibm.com> <4A699629.3080402@necom830.hpcl.titech.ac.jp> <4A69BEA9.5060604@spaghetti.zurich.ibm.com> <4A69C939.4000205@necom830.hpcl.titech.ac.jp> <4A69CF76.9080904@spaghetti.zurich.ibm.com> Message-ID: <4A69D6F3.40506@necom830.hpcl.titech.ac.jp> Jeroen Massar wrote: >>Considering that route aggregation is also an important goal of >>address policy, which IPv6 failed to address, we do need something >>else. > That is a routing issue, not an addressing issue (which is what IPv6 > solves), and it definitely is not a policy issue; as such it doesn't > below on this list anyway. I'm afraid you confuse routability and aggregation. As is written in RIPE NCC activity plan 2009 http://www.ripe.net/ripe/docs/ap.html To provide a fair, impartial distribution of Internet number resources guided by the RIPE community policies based on the goals of uniqueness, conservation and aggregation aggregation is a goal of address policies. > We'll talk further when you realize what happens when you are trying to > SSH from your cozy island vacation resort to your computer at home which > is behind several layers of NAT (at least the one at home, as your ISP > will still only give you 1 ISP-NATted address and thus also the ISP > NATted one, possibly a couple of extra as the ISP didn't get any > addresses either). That is not a essential problem of NAT, because situation is no worse than with IPv6 ISPs not giving stable addresses to its customers. If you pay some ISP enough amount of money, the ISP will give you a fixed IPv6 address or a fixed IPv4 address+port. A fundamental problem of NAT was that end hosts did not know its public address and that end hosts did not restrict source port numbers, both of which are solvable and were solved. Masataka Ohta > > Greets, > Jeroen > > (Small hint: There is a reason why PuTTY has IPv6 support :) > From jeroen at unfix.org Fri Jul 24 18:05:24 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 24 Jul 2009 18:05:24 +0200 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A69D6F3.40506@necom830.hpcl.titech.ac.jp> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> <20090724082037.GI8076@Space.Net> <4A69815D.6090106@necom830.hpcl.titech.ac.jp> <4A6986A6.5060208@spaghetti.zurich.ibm.com> <4A699629.3080402@necom830.hpcl.titech.ac.jp> <4A69BEA9.5060604@spaghetti.zurich.ibm.com> <4A69C939.4000205@necom830.hpcl.titech.ac.jp> <4A69CF76.9080904@spaghetti.zurich.ibm.com> <4A69D6F3.40506@necom830.hpcl.titech.ac.jp> Message-ID: <4A69DBC4.2090906@spaghetti.zurich.ibm.com> Masataka Ohta wrote: > Jeroen Massar wrote: > >>> Considering that route aggregation is also an important goal of >>> address policy, which IPv6 failed to address, we do need something >>> else. > >> That is a routing issue, not an addressing issue (which is what IPv6 >> solves), and it definitely is not a policy issue; as such it doesn't >> below on this list anyway. > > I'm afraid you confuse routability and aggregation. > > As is written in RIPE NCC activity plan 2009 > > http://www.ripe.net/ripe/docs/ap.html > > To provide a fair, impartial distribution of Internet number > resources guided by the RIPE community policies based on the > goals of uniqueness, conservation and aggregation > > aggregation is a goal of address policies. Is that goal not reached anywhere then? The community set the policy for giving out IPv6 PA and PI. Aggregation is done on the size given out as a PI or PA block. If you have problem with those policies then write up a new policy and submit it, that is an appropriate thing to do on this list. >> We'll talk further when you realize what happens when you are trying to >> SSH from your cozy island vacation resort to your computer at home which >> is behind several layers of NAT (at least the one at home, as your ISP >> will still only give you 1 ISP-NATted address and thus also the ISP >> NATted one, possibly a couple of extra as the ISP didn't get any >> addresses either). > > That is not a essential problem of NAT, because situation is no worse > than with IPv6 ISPs not giving stable addresses to its customers. DynDNS solves that problem perfectly fine. > If you pay some ISP enough amount of money, the ISP will give you a > fixed IPv6 address or a fixed IPv4 address+port. This seems to be a CASH issue then, not a technical issue. Technically this is already solved as there are SRV records in existence, just not that many applications actually use them. What is an issue though is that at one point there will not be any IPv4 addresses for new organizations to use. IPv6 then still keeps on working. IPv4 won't, as you won't get a new address. > A fundamental problem of NAT was that end hosts did not know its > public address and that end hosts did not restrict source port > numbers, both of which are solvable and were solved. Indeed, IPv6 has been solving these issues for a long time already. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From mohta at necom830.hpcl.titech.ac.jp Sat Jul 25 03:57:48 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 25 Jul 2009 10:57:48 +0900 Subject: [address-policy-wg] RE: The price of address space In-Reply-To: <4A69DBC4.2090906@spaghetti.zurich.ibm.com> References: <521590921-1248389346-cardhu_decombobulator_blackberry.rim.net-632429694-@bxe1082.bisx.prod.on.blackberry> <4A696C87.2090305@spaghetti.zurich.ibm.com> <20090724082037.GI8076@Space.Net> <4A69815D.6090106@necom830.hpcl.titech.ac.jp> <4A6986A6.5060208@spaghetti.zurich.ibm.com> <4A699629.3080402@necom830.hpcl.titech.ac.jp> <4A69BEA9.5060604@spaghetti.zurich.ibm.com> <4A69C939.4000205@necom830.hpcl.titech.ac.jp> <4A69CF76.9080904@spaghetti.zurich.ibm.com> <4A69D6F3.40506@necom830.hpcl.titech.ac.jp> <4A69DBC4.2090906@spaghetti.zurich.ibm.com> Message-ID: <4A6A669C.2030202@necom830.hpcl.titech.ac.jp> Jeroen Massar wrote: > If you have problem with those policies then write up a new policy and > submit it, that is an appropriate thing to do on this list. Poor aggregation is a problem of protocol, not policy. >>That is not a essential problem of NAT, because situation is no worse >>than with IPv6 ISPs not giving stable addresses to its customers. > DynDNS solves that problem perfectly fine. As you are assuming cooperation between your server and an external relay of DynDNS servers, you can do anything with your server even if it is located behind legacy NAT with no port forwarding. >>If you pay some ISP enough amount of money, the ISP will give you a >>fixed IPv6 address or a fixed IPv4 address+port. > This seems to be a CASH issue then, not a technical issue. If you assume DynDNS free, you can also assume fixed IPv4 address+port free. > What is an issue though is that at one point there will not be any IPv4 > addresses for new organizations to use. That is the point. Unless NAT is mandated and IPv4 allocation is reduced, there will be the point, before we are ready to migrate to new Internet protocol to solve aggregation problem. > IPv6 then still keeps on working. In the real world, IPv6 Internet is not yet working at all. >>A fundamental problem of NAT was that end hosts did not know its >>public address and that end hosts did not restrict source port >>numbers, both of which are solvable and were solved. > Indeed, IPv6 has been solving these issues for a long time already. Not at all. As dual stack approach being abandoned, NAT between 6 and 4 causes the same problem. The only solution is to use end to end NAT or equivalent technology (such as port-wise routing) with modified end hosts in pure IPv4 world. Masataka Ohta From nick at inex.ie Sat Jul 25 18:12:45 2009 From: nick at inex.ie (Nick Hilliard) Date: Sat, 25 Jul 2009 17:12:45 +0100 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> Message-ID: <4A6B2EFD.6060200@inex.ie> On 16/07/2009 22:33, Marco Hogewoning wrote: > This is a bad proposal, completely going into the wrong direction and I > won't support it, it should have been dropped years ago instead of > keeping it sleeping. To be fair, this is a one-sided viewpoint. The reality is that the current policies cause people to lie on their PI application forms in order to justify a /24. The reason for this is simple. At a certain stage in their existence, many businesses realise that single-homing using PA address space can cause serious business continuity problems. If your single upstream has an outage, your site will go down and your money will stop coming in. If you want diversity through multiple providers, you can forget about it. But more importantly, there is a supplier lock-in associated with using your upstream's PA address space: if you decide to renumber to another address block, then this renumbering process is going to cost money, and if it's not done very carefully, it can also cause loss of revenue. So, when your connectivity provider starts acting the maggot, they can do so with a certain degree of impunity - and this degree has a discrete financial value associated with it. Provider independent addressing also puts the balance of negotiating power in the hands of the customer, rather than the provider. If they don't like the pricing, they can just go elsewhere and hey, it's really easy. All these things are serious and legitimate concerns for small businesses. So, if you're one of these businesses which depends on good quality, diverse upstream connectivity, but only have a requirement for relatively small numbers of addresses (for whatever reason - there can be many, ranging from frugality to low interface count), you have three choices for dealing with your business continuity requirements: 1. get a < /24 address block from the RIPE NCC and then discover that this is completely useless, 2. lie to RIPE NCC about your addressing requirements and get yourself a /24, or 3. continue to build your business on the basis of a continuing good relationship with a single upstream provider, and hope that this relationship does not deteriorate to the extent that the cost of continuing in this relationship does not exceed the cost of renumbering out of that address block and severing ties with that provider. I'm not attempting to justify any of these positions or say that a minimum assignment size of /24 is an elegant solution to this problem. All I'm saying is that they are simply the reality for many small businesses, and that continuing to stick our collective heads in the sand about this isn't going to change the reality. The result of this is that -- according to the prefixlen stats for PI assignments provided by the NCC which indicate that hardly anyone applies for < /24, and that the vast majority of assignments are for exactly /24 -- people are quite clearly making a wholesale mockery of the address assignment RIPE policies by consistently and wholeheartedly lying though their teeth on their application forms. This is, in my opinion, a much worse situation than compromising on a minimum assignment size of /24. I also note that most of the people complaining about proposal work with large organisations which are unaffected by the restrictions and workarounds that that 2006-05 attempts to solve. Nick From bgp2 at linuxadmin.org Sat Jul 25 18:44:10 2009 From: bgp2 at linuxadmin.org (Greg) Date: Sat, 25 Jul 2009 19:44:10 +0300 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <4A6B2EFD.6060200@inex.ie> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> Message-ID: <20090725180159.86E656A018@postboy.ripe.net> At 19:12 2009.07.25.?, you wrote: >The result of this is that -- according to the >prefixlen stats for PI assignments provided by >the NCC which indicate that hardly anyone >applies for < /24, and that the vast majority of >assignments are for exactly /24 -- people are >quite clearly making a wholesale mockery of the >address assignment RIPE policies by consistently >and wholeheartedly lying though their teeth on their application forms. > >This is, in my opinion, a much worse situation >than compromising on a minimum assignment size of /24. > >I also note that most of the people complaining >about proposal work with large organisations >which are unaffected by the restrictions and >workarounds that that 2006-05 attempts to solve. > >Nick Very wise words. You can only see how fast "large organization friendly" proposals go through and are accepted - this is just my personal view :) See the multiple /24 allocations for cTLDs that just got accepted. For multi-homing purposes and if your infrastructure allows it - you can easily get /24 ARIN ip space allocated from your US provider. However, to comply with Arin IP v4 rules you can only get one such block (/24 per company). We have worked with multiple clients (from Europe) and it works like a charm. We went this route because I don't think anything will change in the future (and thanks God we did it - it's been 2 years+ and nothing have changed). Greg http://www.linuxadmin.org/ From heldal at eml.cc Sat Jul 25 21:29:19 2009 From: heldal at eml.cc (Per Heldal) Date: Sat, 25 Jul 2009 21:29:19 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <4A6B2EFD.6060200@inex.ie> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> Message-ID: <20090725212919.33df4a73@obelix> On Sat, 25 Jul 2009 17:12:45 +0100 Nick Hilliard wrote: > Provider independent addressing also puts the balance of negotiating > power in the hands of the customer, rather than the provider. If > they don't like the pricing, they can just go elsewhere and hey, it's > really easy. > RIR policies is not the right tool to regulate ISP behaviour. Market regulators (national and international) should define the requirements and make it mandatory for ISPs to ease the transition from an address-block to another, prevent DNS hostage-taking etc. It's very similar to what's already done to provide number portability in mobile markets. //per From mark at streamservice.nl Sat Jul 25 23:25:07 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Sat, 25 Jul 2009 23:25:07 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090725212919.33df4a73@obelix> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725212919.33df4a73@obelix> Message-ID: <00d401ca0d6e$62802790$278076b0$@nl> Hello Per, That would mean that ALL Ip addresses could be taken to another provider/network and that it works. For example if a client has a /24 PA and they go to another network they need the option to take it with them. At least if you compare it to phone number portability in the Netherlands. This also means that if someone uses a /30 (a server with 2 or 3 SSL certificates for example) and they go to another network they can take the IP addresses (even with a /32). And other networks have to be required to route traffic to them or the old network has to route all traffic for that range to the new network. Currently this is not the case and without changing rules (even within the RIPE policy) it won't change probably. I would be happy to see something in the RIPE policy/rules that it works like the number portability for IP addresses, because RIPE NCC follows Dutch laws (and it is mentioned in new contracts for as far as I know) all network operators that have IP addresses from RIPE will also work like this. This means that filtering anything less than a /24 IPv4 is impossible (filtering by route objects or per IP is possible). It also creates "cheap" options for networks to get IP addresses from other networks if they want. Getting co location in another network and getting as much IP addresses as possible with that network and only using it for 1 or 3 months is enough to transfer the IP addresses. This is something that shouldn't be possible if you ask me. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Per Heldal Sent: zaterdag 25 juli 2009 21:29 To: Nick Hilliard Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 On Sat, 25 Jul 2009 17:12:45 +0100 Nick Hilliard wrote: > Provider independent addressing also puts the balance of negotiating > power in the hands of the customer, rather than the provider. If > they don't like the pricing, they can just go elsewhere and hey, it's > really easy. > RIR policies is not the right tool to regulate ISP behaviour. Market regulators (national and international) should define the requirements and make it mandatory for ISPs to ease the transition from an address-block to another, prevent DNS hostage-taking etc. It's very similar to what's already done to provide number portability in mobile markets. //per From jeroen at unfix.org Sat Jul 25 23:44:54 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 25 Jul 2009 23:44:54 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <00d401ca0d6e$62802790$278076b0$@nl> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725212919.33df4a73@obelix> <00d401ca0d6e$62802790$278076b0$@nl> Message-ID: <4A6B7CD6.3040608@spaghetti.zurich.ibm.com> Stream Service || Mark Scholten wrote: > Hello Per, > > That would mean that ALL Ip addresses could be taken to another > provider/network and that it works. For example if a client has a /24 PA and > they go to another network they need the option to take it with them. This is why PI exists. Try using that as has been suggested already several times by other people. > At > least if you compare it to phone number portability in the Netherlands. If you are going to compare IP addresses to phone numbers, then you have to make the Internet work like the Phone system, which would basically mean a 'flow based' routing system: at connect time get the destination, store this and presto keep on using that. This does not work for the Internet as routes change (for phone you get a disconnect when a route changes due to a fiber cut or some other such event. For the Internet, where a sender could just start spewing packets to a million destinations, and possibly from a million sources, flow-based routing does not work, take a small guess why. Also, this is a POLICY list, not a TECHNICAL PROPOSAL list, for the latter there is the IRTF, note the R for Research, as the IETF is not even ready for these kind of changes (rrg WG comes in mind though). Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From nick at inex.ie Sat Jul 25 23:57:04 2009 From: nick at inex.ie (Nick Hilliard) Date: Sat, 25 Jul 2009 22:57:04 +0100 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090725212919.33df4a73@obelix> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725212919.33df4a73@obelix> Message-ID: <4A6B7FB0.4050401@inex.ie> On 25/07/2009 20:29, Per Heldal wrote: > RIR policies is not the right tool to regulate ISP behaviour. I'm not attempting to cast judgement on this either way. All I'm saying is that because internet businesses recognise that PI addresses provide tangible business advantages, they will attempt to obtain them by any reasonable means at their disposal. If this means lying on an application form, then they will do this. I believe this to be harmful to the RIPE community. To get a handle on the problem, here are the PI assignment stats for the past couple of years: > http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2009/msg00267.html Since 2005-01-01, 128 assignments were made of less than /24 and 3934 of exactly /24. These figures do not look to me like the results of 3934 honest assignment application forms. Turning this around, if the minimum PI assignment size were increased from /32 to /24, there would have been 23k extra PI addresses out of 5493760 total PI addresses assigned between 2005-01-01 and 2009-05. That's about 0.4%. Nick From mark at streamservice.nl Sun Jul 26 00:47:21 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Sun, 26 Jul 2009 00:47:21 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <4A6B7CD6.3040608@spaghetti.zurich.ibm.com> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725212919.33df4a73@obelix> <00d401ca0d6e$62802790$278076b0$@nl> <4A6B7CD6.3040608@spaghetti.zurich.ibm.com> Message-ID: <00f401ca0d79$def088f0$9cd19ad0$@nl> Hello Jeroen, It was a reaction based on the message Per did write. If you compare IP addresses to phone numbers: compare everything and not just the part you like. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jeroen Massar Sent: zaterdag 25 juli 2009 23:45 To: Stream Service || Mark Scholten Cc: 'Per Heldal'; 'Nick Hilliard'; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 Stream Service || Mark Scholten wrote: > Hello Per, > > That would mean that ALL Ip addresses could be taken to another > provider/network and that it works. For example if a client has a /24 > PA and they go to another network they need the option to take it with them. This is why PI exists. Try using that as has been suggested already several times by other people. > At > least if you compare it to phone number portability in the Netherlands. If you are going to compare IP addresses to phone numbers, then you have to make the Internet work like the Phone system, which would basically mean a 'flow based' routing system: at connect time get the destination, store this and presto keep on using that. This does not work for the Internet as routes change (for phone you get a disconnect when a route changes due to a fiber cut or some other such event. For the Internet, where a sender could just start spewing packets to a million destinations, and possibly from a million sources, flow-based routing does not work, take a small guess why. Also, this is a POLICY list, not a TECHNICAL PROPOSAL list, for the latter there is the IRTF, note the R for Research, as the IETF is not even ready for these kind of changes (rrg WG comes in mind though). Greets, Jeroen From heldal at eml.cc Sun Jul 26 11:10:09 2009 From: heldal at eml.cc (Per Heldal) Date: Sun, 26 Jul 2009 11:10:09 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <00d401ca0d6e$62802790$278076b0$@nl> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725212919.33df4a73@obelix> <00d401ca0d6e$62802790$278076b0$@nl> Message-ID: <20090726111009.0f5be46c@obelix> On Sat, 25 Jul 2009 23:25:07 +0200 "Stream Service || Mark Scholten" wrote: > Hello Per, > > That would mean that ALL Ip addresses could be taken to another > provider/network and that it works. For example if a client has a /24 > PA and they go to another network they need the option to take it > with them. At least if you compare it to phone number portability in > the Netherlands. > Phone numbers compare better to DNS A-records than IP-addresses. I didn't in any way suggest that addresses should transfer between providers. My point is that there are technical solutions and operational practises available that greatly simplify renumbering, and I'd prefer to see those being refined (and enforced) over changes to RIR policies. This is thus an issue that is better addressed by a combination of standards bodies (IETF), tech communities and market regulators. I'm aware of complexities such as crypto certificates, but that's only a symptom of bad solutions which lack dynamic mechanisms to deal with necessary changes. I see the need for some very limited use of PI, but I don't feel the need for more permissive policies than we already have. //per From jeroen at unfix.org Sun Jul 26 15:33:01 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 26 Jul 2009 15:33:01 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <00f401ca0d79$def088f0$9cd19ad0$@nl> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725212919.33df4a73@obelix> <00d401ca0d6e$62802790$278076b0$@nl> <4A6B7CD6.3040608@spaghetti.zurich.ibm.com> <00f401ca0d79$def088f0$9cd19ad0$@nl> Message-ID: <4A6C5B0D.6030606@spaghetti.zurich.ibm.com> Stream Service || Mark Scholten wrote: > Hello Jeroen, > > It was a reaction based on the message Per did write. If you compare IP > addresses to phone numbers: compare everything and not just the part you > like. I indeed suggest you do that. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From martin.hannigan at batelnet.bs Sat Jul 25 03:23:15 2009 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Fri, 24 Jul 2009 21:23:15 -0400 Subject: [address-policy-wg] Re: [arin-ppml] The price of address space In-Reply-To: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> References: <51AA4CA9-122E-4E58-A05D-D3AF5023885B@rfc1035.com> <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4607e1d50907241823h2ade5641r6bde9149b8f2ba9d@mail.gmail.com> There's already factual data and a derived host value that has been published and presented at various RIR meetings. That price was determined by an actual for cash transaction. We also have hard evidence of ip addr leasing in the form of media. This is old news at best. Search engines are your friends. Yes, maybe it comes crashing down. Maybe. Too soon to tell. On 7/22/09, michael.dillon at bt.com wrote: >> To be serious, I think it's unwise to extrapolate from your >> anecdote about someone offering a six figure sum for a /20. > > Not at all. In several years of discussion of IP address markets, > this is the first time that I have seen someone put an actual > dollar value on an address block. Granted, it was an offered > amount that did not result in a sale, but it is the best data > point that I have seen so far. > >> For one thing, who could possibly know >> for sure if the figure you quoted that was offered recently >> will be the going rate for a /20 after the IPv4 run-out? > > I think that we all realise that in a real market, prices go > up and down with every transaction. So, given that someone is > willing to offer 100,000 USD for a /20 today, when there are > free alternatives at the RIR, what do you think the going rate > will be after the free alternative is gone? > >> If we assume there will be a market in IPv4 after the >> run-out, we should expect the usual laws of supply and demand >> will mean there's some sort of price equilibrium in the >> market. > > Equilibrium? When I learned basic economics, scarcity caused > prices to rise. After IPv4 runout, every block sold just makes > IPv4 addresses scarcer which means that there will be no equilibrium, > just increases until nobody can afford to pay the price. I would > expect that to be a stairstep increase because everyone knows that > addresses are scarcer and scarcer as time goes on. > > Then the whole thing comes crashing down when IPv6 gathers enough > momentum and people start releasing large amounts of IPv4 addresses. > >> Just like >> any predictions for the prices of shares or exchange rates or >> commodities N years in the future. > > You may not be able to predict exact prices, but you can do pretty good > at predicting minimum and maximum prices relative to a hard currency, > i.e. ounces of gold or barrels of crude, or Big Macs. > >> For instance more use of NAT and ALG >> (if these turn out to be cheaper than buying a /20 or >> whatever). > > How cheap do IPv4 addresses need to be to make it worthwhile for an > equipment vendor to buy up addresses today to drive up the price and > make it worthwhile for the market to buy carrier grade NAT boxes? > >> The point I'm making is that it doesn't seem sensible or even >> possible to predict what these prices might be post run-out. > > We could prohibit 3rd part transfers and only allow returns to > the RIR in which case we can confidently predict that the price > will be zero. In any case, it is very sensible to do these types > of scenario analysis as part of the policymaking process. > >> Or to invent policies which >> somehow influence or control those prices. [That might well >> have the look and feel of a cartel.] > > We have a cartel today and the price is zero. It's been like > that for many years now and nobody is complaining or investigating > the RIRs. > >> It would be an >> interesting academic exercise for economists to model the >> impact of various pricing scenarios though I'm not sure how >> useful that would be in practice. That said, it would be nice >> to have some sort of idea of the price points where the >> trade-offs between buying >> IPv4 or using more NAT/ALG or deploying IPv6 start to get fuzzy. > > I agree on that. Where are all the economics grad students? > > --Michael Dillon > > P.S. My position is that IPv6 is the answer and post runout, most > larger ISPs should be able to satisfy growth of IPv4 in one area > of their business by migrating lower margin services onto pure IPv6 > in order to free the IPv4 addresses for the sluggish corporates who > are willing to pay a higher margin for service using legacy technology. > Note that an economist might well consider this to be a market > alternative > because money is exchanged in return for IPv4 network services with > IPv4 addresses bundled in. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From jcurran at arin.net Sun Jul 26 03:35:57 2009 From: jcurran at arin.net (John Curran) Date: Sat, 25 Jul 2009 21:35:57 -0400 Subject: [address-policy-wg] Re: [arin-ppml] The price of address space In-Reply-To: <4607e1d50907241823h2ade5641r6bde9149b8f2ba9d@mail.gmail.com> References: <51AA4CA9-122E-4E58-A05D-D3AF5023885B@rfc1035.com> <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net> <4607e1d50907241823h2ade5641r6bde9149b8f2ba9d@mail.gmail.com> Message-ID: <337F33A6-2A1B-4531-9F26-CE210480A7CA@arin.net> On Jul 24, 2009, at 9:23 PM, Martin Hannigan wrote: > ... > There's already factual data and a derived host value that has been > published and presented at various RIR meetings. To the extent folks suspect Internet number resource fraud, please report it here: Thanks! /John John Curran President and CEO ARIN From bmanning at vacation.karoshi.com Sun Jul 26 04:19:09 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 26 Jul 2009 02:19:09 +0000 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090725212919.33df4a73@obelix> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725212919.33df4a73@obelix> Message-ID: <20090726021909.GB5944@vacation.karoshi.com.> On Sat, Jul 25, 2009 at 09:29:19PM +0200, Per Heldal wrote: > On Sat, 25 Jul 2009 17:12:45 +0100 > Nick Hilliard wrote: > > > Provider independent addressing also puts the balance of negotiating > > power in the hands of the customer, rather than the provider. If > > they don't like the pricing, they can just go elsewhere and hey, it's > > really easy. > > > > RIR policies is not the right tool to regulate ISP behaviour. right or wrong, its a fact of life. most ISPs set their filters based on the RIR min-allocation. > > Market regulators (national and international) should define the > requirements and make it mandatory for ISPs to ease the transition from > an address-block to another, prevent DNS hostage-taking etc. It's very > similar to what's already done to provide number portability in mobile > markets. > > > //per From michael.dillon at bt.com Mon Jul 27 11:54:35 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 27 Jul 2009 10:54:35 +0100 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090725212919.33df4a73@obelix> Message-ID: <28E139F46D45AF49A31950F88C49745802557254@E03MVZ2-UKDY.domain1.systemhost.net> > > Provider independent addressing also puts the balance of > negotiating > > power in the hands of the customer, rather than the > provider. If they > > don't like the pricing, they can just go elsewhere and hey, it's > > really easy. > > > > RIR policies is not the right tool to regulate ISP behaviour. And RIR policies do NOT regulate anything. Your comment is not relevant to the suggestion (above) that RIPE needs to meet the needs of that segment of the IP address user community that needs to have IP addressing independent of their ISP. > Market regulators (national and international) should define > the requirements and make it mandatory for ISPs to ease the > transition from an address-block to another, prevent DNS > hostage-taking etc. It's very similar to what's already done > to provide number portability in mobile markets. There is no point in discussing such things here since RIPE has nothing to do with regulators. --Michael Dillon From jim at rfc1035.com Mon Jul 27 12:31:42 2009 From: jim at rfc1035.com (Jim Reid) Date: Mon, 27 Jul 2009 11:31:42 +0100 Subject: [address-policy-wg] Is policy-making "large organisation friendly"? In-Reply-To: <20090725180159.86E656A018@postboy.ripe.net> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725180159.86E656A018@postboy.ripe.net> Message-ID: <1E218E35-6EF0-4BCB-B195-B3DE1B5C2E06@rfc1035.com> On 25 Jul 2009, at 17:44, Greg wrote: > You can only see how fast "large organization friendly" proposals go > through and are accepted - this is just my personal view :) See the > multiple /24 allocations for cTLDs that just got accepted. It's not clear what point, if any, you're making here. The recent change to provide space to TLDs for anycasting was discussed on this list. Everyone had a chance to contribute to that policy development. Many did. Including some like me who represent no large organisation or even an LIR. The consensus was that these allocations would be a Good Thing for the Internet, not just the TLD operators who would get the space. Everybody and everything using the Internet benefits if the DNS infrastructure for things like TLDs is made more robust by anycasting, there's not just a small number of DNS hosting companies offering commercial anycast services, etc, etc. I fail to understand why you'd characterise this policy as being "large organisation friendly". It's clearly for the benefit of everyone using the Internet. Oh and most TLD registries are not large organisations. The biggest of them have turnover and staffing equivalent to a modest ISP. My guess is the TLD registries that are NCC members will probably be in the small membership category because, comparitively speaking, they don't need or use a lot of numbering resources. Now it may be that large organisations are better placed than small ones to participate in policy discussions or attend RIPE meetings. That's just a a fact of life. However it doesn't mean policy-making is dominated by those large organisations. The barrier for participation in policy discussions could hardly be any lower: a mail/web client and some understanding of English. Your complaint, if it is indeed a complaint, seems to be a bit like moaning about the government when you've not even bothered to vote. From heldal at eml.cc Mon Jul 27 12:56:14 2009 From: heldal at eml.cc (Per Heldal) Date: Mon, 27 Jul 2009 12:56:14 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <28E139F46D45AF49A31950F88C49745802557254@E03MVZ2-UKDY.domain1.systemhost.net> References: <20090725212919.33df4a73@obelix> <28E139F46D45AF49A31950F88C49745802557254@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20090727125614.04376d56@obelix> On Mon, 27 Jul 2009 10:54:35 +0100 wrote: > > > > Provider independent addressing also puts the balance of > > negotiating > > > power in the hands of the customer, rather than the > > provider. If they > > > don't like the pricing, they can just go elsewhere and hey, it's > > > really easy. > > > > > > > RIR policies is not the right tool to regulate ISP behaviour. > > And RIR policies do NOT regulate anything. They shouldn't. I did however misinterpret a previous comment in the thread to be about liberalisation of PI-policy. I don't want RIPE to hand out smaller blocks, which was the basis for my arguments. I've re-read the proposal, and I do agree that RIPE should not hand out blocks smaller than what is defined as the minimum assignment. Handing out blocks smaller than what is permitted through general filtering recommendations makes no sense. Sorry for the confusion. //per From michiel at klaver.it Mon Jul 27 14:37:22 2009 From: michiel at klaver.it (Michiel Klaver) Date: Mon, 27 Jul 2009 14:37:22 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <4A5F3EE9.1070603@ripe.net> References: <4A5F3EE9.1070603@ripe.net> Message-ID: <4A6D9F82.8000400@klaver.it> At 16-7-2009 16:53, Andrea Cima wrote: > [Apologies for duplicate emails] > > Dear Colleagues, > > The RIPE NCC has published a new RIPE NCC procedural document: > ripe-475, "Independent Internet Number Resources  Contractual > Relationship Changes between sponsoring LIR and End User" > > This document describes the steps to be taken when there are changes in > the contractual relationship between the End User of independent > Internet number resources and the sponsoring Local Internet Registry > (LIR). It also describes the scenarios in which the RIPE NCC may > de-register independent Internet number resources and what happens to > those resources once they are de-registered. > > The new document is available at: > http://www.ripe.net/ripe/docs/ripe-475.html > > Kind regards, > > Andrea Cima > RIPE NCC >From the document: The End User contact email addresses listed in the RIPE Database object are notified by the RIPE NCC [...] I'm not a lawyer, but from what I understand on the matter of unilateral contract termination, e-mail notifications are not legally binding by Dutch law. You need certified registered postal mail with proof of delivery. In the case of a network that seized to exist and the resources become void and invalid, e-mail correspondention with that network might not be possible anymore. When applying for resources, one has to submit company registration documents and the corresponding organisation object created at the RIPE database should contain the same data. This data should be sufficient to track down and send out notifications to the correct holder by postal mail. Please consult your legal department on this matter and update the procedures described at the document. With kind regards, Michiel Klaver IT Professional From mark at streamservice.nl Mon Jul 27 14:53:58 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Mon, 27 Jul 2009 14:53:58 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <4A6D9F82.8000400@klaver.it> References: <4A5F3EE9.1070603@ripe.net> <4A6D9F82.8000400@klaver.it> Message-ID: <014c01ca0eb9$4f08dd00$ed1a9700$@nl> Hello Michiel, They could first try to receive a response by email. If they don't get that response (and a response that is not from a human person isn't good enough) they could send the papers by postal mail. This way they could try to reduce the costs for the contact. It also depends on when the resources where given to the person/organization using it. Rules regarding emails and legal binding are changing. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Michiel Klaver Sent: maandag 27 juli 2009 14:37 To: Andrea Cima Cc: ncc-services-wg at ripe.net; 'Address Policy Working Group' Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available At 16-7-2009 16:53, Andrea Cima wrote: > [Apologies for duplicate emails] > > Dear Colleagues, > > The RIPE NCC has published a new RIPE NCC procedural document: > ripe-475, "Independent Internet Number Resources  Contractual > Relationship Changes between sponsoring LIR and End User" > > This document describes the steps to be taken when there are changes in > the contractual relationship between the End User of independent > Internet number resources and the sponsoring Local Internet Registry > (LIR). It also describes the scenarios in which the RIPE NCC may > de-register independent Internet number resources and what happens to > those resources once they are de-registered. > > The new document is available at: > http://www.ripe.net/ripe/docs/ripe-475.html > > Kind regards, > > Andrea Cima > RIPE NCC >From the document: The End User contact email addresses listed in the RIPE Database object are notified by the RIPE NCC [...] I'm not a lawyer, but from what I understand on the matter of unilateral contract termination, e-mail notifications are not legally binding by Dutch law. You need certified registered postal mail with proof of delivery. In the case of a network that seized to exist and the resources become void and invalid, e-mail correspondention with that network might not be possible anymore. When applying for resources, one has to submit company registration documents and the corresponding organisation object created at the RIPE database should contain the same data. This data should be sufficient to track down and send out notifications to the correct holder by postal mail. Please consult your legal department on this matter and update the procedures described at the document. With kind regards, Michiel Klaver IT Professional From ingrid at ripe.net Mon Jul 27 16:08:07 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Mon, 27 Jul 2009 16:08:07 +0200 Subject: [address-policy-wg] 2008-07 Discussion Period extended until 24 August 2009 (Ensuring efficient use of historical IPv4 resources) Message-ID: <20090727140807.30A372F583@herring.ripe.net> PDP Number: 2008-07 Ensuring efficient use of historical IPv4 resources Dear Colleagues, The Discussion Period for the proposal 2008-07 has been extended until 24 August 2009. The text of the policy proposal 2008-07 has been revised. We have published the new version (version 3) today. In the new version, new members, requesting an initial allocation, are also asked about the utilisation and documentation of all address resources they hold, including pre-RIR registrations. In version 2 this was only proposed for additional allocations. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-07.html As a result a new Discussion Phase is set for the proposal. We encourage you to review this policy proposal and send your comments to . Regards, Ingrid Wijte Policy Development Officer RIPE NCC From sander at steffann.nl Mon Jul 27 16:10:55 2009 From: sander at steffann.nl (Sander Steffann) Date: Mon, 27 Jul 2009 16:10:55 +0200 (CEST) Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <014c01ca0eb9$4f08dd00$ed1a9700$@nl> References: <4A5F3EE9.1070603@ripe.net> <4A6D9F82.8000400@klaver.it> <014c01ca0eb9$4f08dd00$ed1a9700$@nl> Message-ID: <2167.80.101.103.96.1248703855.squirrel@webmail.sintact.nl> Hi Mark and Michiel, > They could first try to receive a response by email. If they don't get > that response (and a response that is not from a human person isn't good > enough) they could send the papers by postal mail. This way they could try > to reduce the costs for the contact. > > It also depends on when the resources where given to the > person/organization using it. Rules regarding emails and legal binding are > changing. I think this is more RIPE NCC operational related than address policy related. I don't think cross-posting between ncc-services and address-policy is useful for this discussion. Thanks, Sander Steffann APWG co-chair From leo.vegoda at icann.org Mon Jul 27 18:07:00 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 27 Jul 2009 09:07:00 -0700 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <4A6B7FB0.4050401@inex.ie> Message-ID: Nick, On 25/07/2009 2:57, "Nick Hilliard" wrote: [...] > Turning this around, if the minimum PI assignment size were increased from > /32 to /24, there would have been 23k extra PI addresses out of 5493760 > total PI addresses assigned between 2005-01-01 and 2009-05. That's about > 0.4%. I wonder if you are right. Right now, the policies for PA and PI are the same: if you qualify for a /28 of PA then you qualify for a /28 of PI. But if you change the policy so that when you qualify for a /28 of PA then you qualify for a /24 of PI then PI space becomes much more attractive because you get more space and it is independent of your ISP. Any time an ISP had a customer who wants more space than they qualify for under the PA policy they have an opportunity to upsell them a /24 of PI. I suspect that a policy along these lines could end up as a cash generator for ISPs. I don't know how to quantify this and maybe I'm wrong anyway. Nonetheless, I think this should be considered as a potential risk for a policy that allows /24 PI assignments based solely on a phrase as vague as "when routing is a major issue". Regards, Leo Vegoda From nick at inex.ie Mon Jul 27 18:38:23 2009 From: nick at inex.ie (Nick Hilliard) Date: Mon, 27 Jul 2009 17:38:23 +0100 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: References: Message-ID: <4A6DD7FF.3070707@inex.ie> On 27/07/2009 17:07, Leo Vegoda wrote: > Right now, the policies for PA and PI are the same: if you qualify for a /28 > of PA then you qualify for a /28 of PI. But if you change the policy so that > when you qualify for a /28 of PA then you qualify for a /24 of PI then PI > space becomes much more attractive because you get more space and it is > independent of your ISP. I deliberately left this out of the calculation, and perhaps phrased things slightly sloppily. It's a know unknown, or perhaps an unknown unknown, to borrow a cliche. Besides the two issues are still separate. Qualifying for /28 PA is a matter of just having 8 internet-connected machines within 1 year and the ability to configure a default route on each machine. Qualifying for /24 PI would be a matter of having 8 internet connected machines, a router, an ASN, more than one upstream transit partner or a bunch of peering partners and enough in-house or consultancy clue to make this all work. It's not rocket science, of course. But it does have a cost and it would be interesting to compare the cost of this scenario to the cost associated with becoming a LIR and requesting a minimum allocation (if all you're looking for is routable address space). > I don't know how to quantify this and maybe I'm wrong anyway. Nonetheless, I > think this should be considered as a potential risk for a policy that allows > /24 PI assignments based solely on a phrase as vague as "when routing is a > major issue". Yes, it's a risk, and should be noted explicitly in any proposal. I don't doubt that it would cause greater uptake of PI address assignment requests - and this is one of the reasons that this is not a pretty solution to the problem. On a side note, I wonder whether the lower number of requests for the year until may was due to the new contractual requirements. Nick From leo.vegoda at icann.org Mon Jul 27 18:59:23 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 27 Jul 2009 09:59:23 -0700 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <4A6DD7FF.3070707@inex.ie> Message-ID: Hi Nick, On 27/07/2009 9:38, "Nick Hilliard" wrote: > On 27/07/2009 17:07, Leo Vegoda wrote: >> Right now, the policies for PA and PI are the same: if you qualify for a /28 >> of PA then you qualify for a /28 of PI. But if you change the policy so that >> when you qualify for a /28 of PA then you qualify for a /24 of PI then PI >> space becomes much more attractive because you get more space and it is >> independent of your ISP. > > I deliberately left this out of the calculation, and perhaps phrased things > slightly sloppily. It's a know unknown, or perhaps an unknown unknown, to > borrow a cliche. > > Besides the two issues are still separate. Qualifying for /28 PA is a > matter of just having 8 internet-connected machines within 1 year and the > ability to configure a default route on each machine. Qualifying for /24 > PI would be a matter of having 8 internet connected machines, a router, an > ASN, more than one upstream transit partner or a bunch of peering partners > and enough in-house or consultancy clue to make this all work. Ah... That was the other piece of vague language. The proposed text says "demonstrate a plan to multihome". The word "plan" has been interpreted as a *very* low bar in the IPv6 policy and I suspect that it would be unreasonable to have the word interpreted very differently in this policy. So, my interpretation of the requirement as written in the proposal is that it requires "a plan". Not a set of contracts. Not proof that there is equipment. Not proof that there are people with the required skills. The way I read the text, a requester would need a network design and maybe a generic "fill in the blanks" implementation plan. That is all. So, while I can see that there is an unmet need, I also think that the text in this current proposal is sufficiently loose to allow the creation of a "pay for PI" industry. I make no comment on whether that is a desirable outcome. [...] > On a side note, I wonder whether the lower number of requests for the year > until may was due to the new contractual requirements. An excellent question. I would also like to know this. Regards, Leo Vegoda From mark at streamservice.nl Mon Jul 27 19:38:23 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Mon, 27 Jul 2009 19:38:23 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: References: <4A6DD7FF.3070707@inex.ie> Message-ID: <017301ca0ee1$0a3e3580$1ebaa080$@nl> Hello Nick and Leo, There is a lower request for IPv4 PI and it is very likely that the requests are lower because of this contract. I know multiple LIRs that don't have the contracts ready and don't process PI requests anymore (they don't have the contracts ready or don't want to offer the contracts). Regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Leo Vegoda Sent: maandag 27 juli 2009 18:59 To: Nick Hilliard Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 Hi Nick, On 27/07/2009 9:38, "Nick Hilliard" wrote: > On 27/07/2009 17:07, Leo Vegoda wrote: >> Right now, the policies for PA and PI are the same: if you qualify for a /28 >> of PA then you qualify for a /28 of PI. But if you change the policy so that >> when you qualify for a /28 of PA then you qualify for a /24 of PI then PI >> space becomes much more attractive because you get more space and it is >> independent of your ISP. > > I deliberately left this out of the calculation, and perhaps phrased things > slightly sloppily. It's a know unknown, or perhaps an unknown unknown, to > borrow a cliche. > > Besides the two issues are still separate. Qualifying for /28 PA is a > matter of just having 8 internet-connected machines within 1 year and the > ability to configure a default route on each machine. Qualifying for /24 > PI would be a matter of having 8 internet connected machines, a router, an > ASN, more than one upstream transit partner or a bunch of peering partners > and enough in-house or consultancy clue to make this all work. Ah... That was the other piece of vague language. The proposed text says "demonstrate a plan to multihome". The word "plan" has been interpreted as a *very* low bar in the IPv6 policy and I suspect that it would be unreasonable to have the word interpreted very differently in this policy. So, my interpretation of the requirement as written in the proposal is that it requires "a plan". Not a set of contracts. Not proof that there is equipment. Not proof that there are people with the required skills. The way I read the text, a requester would need a network design and maybe a generic "fill in the blanks" implementation plan. That is all. So, while I can see that there is an unmet need, I also think that the text in this current proposal is sufficiently loose to allow the creation of a "pay for PI" industry. I make no comment on whether that is a desirable outcome. [...] > On a side note, I wonder whether the lower number of requests for the year > until may was due to the new contractual requirements. An excellent question. I would also like to know this. Regards, Leo Vegoda From scottleibrand at gmail.com Mon Jul 27 21:33:42 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 27 Jul 2009 12:33:42 -0700 Subject: [address-policy-wg] 2008-07 Discussion Period extended until 24 August 2009 (Ensuring efficient use of historical IPv4 resources) In-Reply-To: <20090727140807.30A372F583@herring.ripe.net> References: <20090727140807.30A372F583@herring.ripe.net> Message-ID: <4A6E0116.7020704@gmail.com> Good catch. I support the change, and the proposal. -Scott Ingrid Wijte wrote: > PDP Number: 2008-07 > Ensuring efficient use of historical IPv4 resources > > > Dear Colleagues, > > The Discussion Period for the proposal 2008-07 has been extended until 24 August 2009. > > The text of the policy proposal 2008-07 has been revised. > > We have published the new version (version 3) today. In the new version, new members, requesting an initial allocation, are also asked about the utilisation and documentation of all address resources they hold, including pre-RIR registrations. In version 2 this was only proposed for additional allocations. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2008-07.html > > As a result a new Discussion Phase is set for the proposal. > > We encourage you to review this policy proposal and send your comments > to . > > Regards, > > Ingrid Wijte > Policy Development Officer > RIPE NCC > > From david.freedman at uk.clara.net Mon Jul 27 21:55:29 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 27 Jul 2009 20:55:29 +0100 Subject: [address-policy-wg] 2008-07 Discussion Period extended until 24 August 2009 (Ensuring efficient use of historical IPv4 resources) References: <20090727140807.30A372F583@herring.ripe.net> <4A6E0116.7020704@gmail.com> Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B0D7E3D@EXVS01.claranet.local> No immeadiate objections other than nothing really changes here (i.e if the user has any legacy or non-RIPE NCC space then they can simply claim it is "full") Also, note the policy only strives to document, not to instruct on how such matters are dealt with other than in the context of address consumption, does nothing to help people get off historical space for instance. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: address-policy-wg-admin at ripe.net on behalf of Scott Leibrand Sent: Mon 7/27/2009 20:33 To: address-policy-wg at ripe.net Cc: policy-announce at ripe.net Subject: Re: [address-policy-wg] 2008-07 Discussion Period extended until 24 August 2009 (Ensuring efficient use of historical IPv4 resources) Good catch. I support the change, and the proposal. -Scott Ingrid Wijte wrote: > PDP Number: 2008-07 > Ensuring efficient use of historical IPv4 resources > > > Dear Colleagues, > > The Discussion Period for the proposal 2008-07 has been extended until 24 August 2009. > > The text of the policy proposal 2008-07 has been revised. > > We have published the new version (version 3) today. In the new version, new members, requesting an initial allocation, are also asked about the utilisation and documentation of all address resources they hold, including pre-RIR registrations. In version 2 this was only proposed for additional allocations. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2008-07.html > > As a result a new Discussion Phase is set for the proposal. > > We encourage you to review this policy proposal and send your comments > to . > > Regards, > > Ingrid Wijte > Policy Development Officer > RIPE NCC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwkckid1 at ix.netcom.com Tue Jul 28 02:03:08 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Mon, 27 Jul 2009 17:03:08 -0700 Subject: [address-policy-wg] Is policy-making "large organisation friendly"? References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725180159.86E656A018@postboy.ripe.net> <1E218E35-6EF0-4BCB-B195-B3DE1B5C2E06@rfc1035.com> Message-ID: <4A6E403C.7B519DD4@ix.netcom.com> Jim and all, Anyone with half a brain and only a bit of experiance know that policy making almost always favors large orgs. significantly. Jim Reid wrote: > On 25 Jul 2009, at 17:44, Greg wrote: > > > You can only see how fast "large organization friendly" proposals go > > through and are accepted - this is just my personal view :) See the > > multiple /24 allocations for cTLDs that just got accepted. > > It's not clear what point, if any, you're making here. > > The recent change to provide space to TLDs for anycasting was > discussed on this list. Everyone had a chance to contribute to that > policy development. Many did. Including some like me who represent no > large organisation or even an LIR. The consensus was that these > allocations would be a Good Thing for the Internet, not just the TLD > operators who would get the space. Everybody and everything using the > Internet benefits if the DNS infrastructure for things like TLDs is > made more robust by anycasting, there's not just a small number of DNS > hosting companies offering commercial anycast services, etc, etc. > > I fail to understand why you'd characterise this policy as being > "large organisation friendly". It's clearly for the benefit of > everyone using the Internet. Oh and most TLD registries are not large > organisations. The biggest of them have turnover and staffing > equivalent to a modest ISP. My guess is the TLD registries that are > NCC members will probably be in the small membership category because, > comparitively speaking, they don't need or use a lot of numbering > resources. > > Now it may be that large organisations are better placed than small > ones to participate in policy discussions or attend RIPE meetings. > That's just a a fact of life. However it doesn't mean policy-making is > dominated by those large organisations. The barrier for participation > in policy discussions could hardly be any lower: a mail/web client and > some understanding of English. Your complaint, if it is indeed a > complaint, seems to be a bit like moaning about the government when > you've not even bothered to vote. Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From gert at space.net Tue Jul 28 10:30:41 2009 From: gert at space.net (Gert Doering) Date: Tue, 28 Jul 2009 10:30:41 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090725212919.33df4a73@obelix> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725212919.33df4a73@obelix> Message-ID: <20090728083041.GS79272@Space.Net> Hi, On Sat, Jul 25, 2009 at 09:29:19PM +0200, Per Heldal wrote: > Market regulators (national and international) should define the > requirements and make it mandatory for ISPs to ease the transition from > an address-block to another, prevent DNS hostage-taking etc. It's very > similar to what's already done to provide number portability in mobile > markets. Be careful with your wishes. "IP number portability", prescribed by the regulation authorities, would be the end of the Internet routing as we know it. Gert Doering -- APWG -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Tue Jul 28 10:36:21 2009 From: gert at space.net (Gert Doering) Date: Tue, 28 Jul 2009 10:36:21 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090727125614.04376d56@obelix> References: <20090725212919.33df4a73@obelix> <28E139F46D45AF49A31950F88C49745802557254@E03MVZ2-UKDY.domain1.systemhost.net> <20090727125614.04376d56@obelix> Message-ID: <20090728083621.GT79272@Space.Net> Hi, On Mon, Jul 27, 2009 at 12:56:14PM +0200, Per Heldal wrote: > I've re-read the proposal, and I do agree that RIPE should not > hand out blocks smaller than what is defined as the minimum assignment. They don't. The defined minimum assignment size for IPv4 PI is a /32. > Handing out blocks smaller than what is permitted through general > filtering recommendations makes no sense. Sorry for the confusion. Now there's the catch: who defines what is "permitted" on the Internet? If we could get a clear document from the Internet Routing Police, we could tie the policy to that... Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From david.freedman at uk.clara.net Tue Jul 28 10:36:12 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 28 Jul 2009 09:36:12 +0100 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725212919.33df4a73@obelix> <20090728083041.GS79272@Space.Net> Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B0D7E43@EXVS01.claranet.local> >Be careful with your wishes. "IP number portability", prescribed by the >regulation authorities, would be the end of the Internet routing as we >know it. It's ok, we can just do this all in the LISP-ALT! ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen at unfix.org Tue Jul 28 10:42:02 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 28 Jul 2009 10:42:02 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090728083621.GT79272@Space.Net> References: <20090725212919.33df4a73@obelix> <28E139F46D45AF49A31950F88C49745802557254@E03MVZ2-UKDY.domain1.systemhost.net> <20090727125614.04376d56@obelix> <20090728083621.GT79272@Space.Net> Message-ID: <4A6EB9DA.7090605@spaghetti.zurich.ibm.com> Gert Doering wrote: > Hi, > > On Mon, Jul 27, 2009 at 12:56:14PM +0200, Per Heldal wrote: >> I've re-read the proposal, and I do agree that RIPE should not >> hand out blocks smaller than what is defined as the minimum assignment. > > They don't. The defined minimum assignment size for IPv4 PI is a /32. > >> Handing out blocks smaller than what is permitted through general >> filtering recommendations makes no sense. Sorry for the confusion. > > Now there's the catch: who defines what is "permitted" on the Internet? > > If we could get a clear document from the Internet Routing Police, we > could tie the policy to that... The trick here though is that IP addresses are not only used on the Internet. Especially in the case of PI it is perfectly useful and IMHO a valid request case to request address space for interconnecting non-Internet connected resources. As such, a request that does not match to those IRP rules (aka the perceived current of a minimum of a /24) are definitely valid and should be accepted by RIPE. Then again, there is always the assumption that something will at one point appear on the Internets... Greets, Jeroen -- Btw: $ whois routingpolice.net No match for "ROUTINGPOLICE.NET". For all those domain-grabbers :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From ula at ripn.net Tue Jul 28 08:33:23 2009 From: ula at ripn.net (Larisa A. Yurkina) Date: Tue, 28 Jul 2009 10:33:23 +0400 (MSD) Subject: [address-policy-wg] 2008-07 Discussion Period extended until 24 August 2009 (Ensuring efficient use of historical IPv4 resources) In-Reply-To: <4A6E0116.7020704@gmail.com> Message-ID: <20090728092819.T61841-100000@capral.ripn.net> On Mon, 27 Jul 2009, Scott Leibrand wrote: > Good catch. I support the change, and the proposal. > > -Scott I support the proposal only partially. No objections to "LIR should be asked about the utilisation of all address resources ..." I'm against the position about "documentation of all address resources they hold, including pre-RIR registrations". The "documentation" in pre-RIR times did not look like "forms for gathering the required information", with "network infrastructure and future plans" from ripe-471 (6.1.). They only contained a template for db and that's all. To fulfil the proposed policy, I have to turn to customers of pre-rir /16s and ask them "all" to re-right their request forms to ripe-381. Which is hardly possible. LIR that holds pre-rir registrations is unable to provide the "documentation of all ... pre-RIR registrations" as the policy proposal demands. With respect, Larisa Yurkina -------------- RIPN Registry Center > > Ingrid Wijte wrote: > > PDP Number: 2008-07 > > Ensuring efficient use of historical IPv4 resources > > > > > > Dear Colleagues, > > > > The Discussion Period for the proposal 2008-07 has been extended until 24 August 2009. > > > > The text of the policy proposal 2008-07 has been revised. > > > > We have published the new version (version 3) today. In the new version, new members, requesting an initial allocation, are also asked about the utilisation and documentation of all address resources they hold, including pre-RIR registrations. In version 2 this was only proposed for additional allocations. > > > > You can find the full proposal at: > > > > http://www.ripe.net/ripe/policies/proposals/2008-07.html > > > > As a result a new Discussion Phase is set for the proposal. > > > > We encourage you to review this policy proposal and send your comments > > to . > > > > Regards, > > > > Ingrid Wijte > > Policy Development Officer > > RIPE NCC > > > > > > --- RIPN Registry center ----- From bmanning at vacation.karoshi.com Tue Jul 28 14:50:21 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 28 Jul 2009 12:50:21 +0000 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090728083041.GS79272@Space.Net> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725212919.33df4a73@obelix> <20090728083041.GS79272@Space.Net> Message-ID: <20090728125021.GA10884@vacation.karoshi.com.> On Tue, Jul 28, 2009 at 10:30:41AM +0200, Gert Doering wrote: > Hi, > > On Sat, Jul 25, 2009 at 09:29:19PM +0200, Per Heldal wrote: > > Market regulators (national and international) should define the > > requirements and make it mandatory for ISPs to ease the transition from > > an address-block to another, prevent DNS hostage-taking etc. It's very > > similar to what's already done to provide number portability in mobile > > markets. > > Be careful with your wishes. "IP number portability", prescribed by the > regulation authorities, would be the end of the Internet routing as we > know it. > > Gert Doering > -- APWG of course internet routing as we know it is doomed anyway, so why not do number portability? --bill From heldal at eml.cc Tue Jul 28 20:25:53 2009 From: heldal at eml.cc (Per Heldal) Date: Tue, 28 Jul 2009 20:25:53 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090728083041.GS79272@Space.Net> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725212919.33df4a73@obelix> <20090728083041.GS79272@Space.Net> Message-ID: <20090728202553.65438829@obelix> On Tue, 28 Jul 2009 10:30:41 +0200 Gert Doering wrote: > Hi, > Be careful with your wishes. "IP number portability", prescribed by > the regulation authorities, would be the end of the Internet routing > as we know it. > Once again: I've been been around more than long enough to know that "IP number portability" is rubbish, and I apologise if my statement was interpreted that way. I was however hinting towards a comparison of DNS-records and phone-numbers wrt portability. Hence my suggestion that market regulators may want to look at the ways in which ISP's and others hijack DNS records, and otherwise makes it much harder than it has to be to move from one IP-block to another. Micro PI blocks should really have been a no-issue by now. Note also that ARIN limits PI to /22, although it's recently been discussed to liberalise to /24. //per From heldal at eml.cc Tue Jul 28 20:39:58 2009 From: heldal at eml.cc (Per Heldal) Date: Tue, 28 Jul 2009 20:39:58 +0200 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <20090728083621.GT79272@Space.Net> References: <20090725212919.33df4a73@obelix> <28E139F46D45AF49A31950F88C49745802557254@E03MVZ2-UKDY.domain1.systemhost.net> <20090727125614.04376d56@obelix> <20090728083621.GT79272@Space.Net> Message-ID: <20090728203958.570e61c4@obelix> On Tue, 28 Jul 2009 10:36:21 +0200 Gert Doering wrote: > Hi, > > On Mon, Jul 27, 2009 at 12:56:14PM +0200, Per Heldal wrote: > > I've re-read the proposal, and I do agree that RIPE should not > > hand out blocks smaller than what is defined as the minimum > > assignment. > > They don't. The defined minimum assignment size for IPv4 PI is a /32. > > > Handing out blocks smaller than what is permitted through general > > filtering recommendations makes no sense. Sorry for the confusion. > > Now there's the catch: who defines what is "permitted" on the > Internet? You know, as well as I, that no-one does, but that common operational practises puts a practical limit at /24. I would not work with anything smaller, or recommend anyone else to do so. I'd take PA over PI References: <4A5F3EE9.1070603@ripe.net> <4A5F7AB3.1020700@futureinquestion.net> <1248176648.4763.3345.camel@shane-asus-laptop> Message-ID: <4A6F62A8.8000307@ukraine.su> Shane Kerr wrote: > Someone could always take the RIPE NCC to court, in the Netherlands or > in any other jurisdiction on the planet that will accept the case. And so what? It is very cheap for example in Ukraine to make Ukrainian court decision that 193.0.18.0/22 belongs to Max Tulyev :) Which kind of court orders RIPE NCC will really accept? Only Dutch or not? If not - what else? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From mark at streamservice.nl Tue Jul 28 23:39:25 2009 From: mark at streamservice.nl (Stream Service || Mark Scholten) Date: Tue, 28 Jul 2009 23:39:25 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <4A6F62A8.8000307@ukraine.su> References: <4A5F3EE9.1070603@ripe.net> <4A5F7AB3.1020700@futureinquestion.net> <1248176648.4763.3345.camel@shane-asus-laptop> <4A6F62A8.8000307@ukraine.su> Message-ID: <01c201ca0fcb$e0776820$a1663860$@nl> Hello Max, Probably only Dutch court. But Dutch court will accept almost all decisions made by any court in the EU. That way Dutch court will take the decision of the other court and without looking at if it is correct it will make the same decision (just a technical point). A few weeks back this was done in a case, see also: http://tweakers.net/nieuws/61109/oostenrijkse-rechter-veroordeelt-nederlands e-hostingprovider.html (Dutch). Google translate should be able to translate it. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Max Tulyev Sent: dinsdag 28 juli 2009 22:42 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available Shane Kerr wrote: > Someone could always take the RIPE NCC to court, in the Netherlands or > in any other jurisdiction on the planet that will accept the case. And so what? It is very cheap for example in Ukraine to make Ukrainian court decision that 193.0.18.0/22 belongs to Max Tulyev :) Which kind of court orders RIPE NCC will really accept? Only Dutch or not? If not - what else? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From sander at steffann.nl Wed Jul 29 00:54:16 2009 From: sander at steffann.nl (Sander Steffann) Date: Wed, 29 Jul 2009 00:54:16 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <01c201ca0fcb$e0776820$a1663860$@nl> References: <4A5F3EE9.1070603@ripe.net> <4A5F7AB3.1020700@futureinquestion.net> <1248176648.4763.3345.camel@shane-asus-laptop> <4A6F62A8.8000307@ukraine.su> <01c201ca0fcb$e0776820$a1663860$@nl> Message-ID: <49C45E7B-B0D9-4C46-AF7D-61F418A379D0@steffann.nl> Hi Max and Mark, > Probably only Dutch court. But Dutch court will accept almost all > decisions > made by any court in the EU. That way Dutch court will take the > decision of > the other court and without looking at if it is correct it will make > the > same decision (just a technical point). Please take this discussion off the policy list. NCC services would be more appropriate. Thanks, Sander From pfs at cisco.com Wed Jul 29 09:07:33 2009 From: pfs at cisco.com (Philip Smith) Date: Wed, 29 Jul 2009 17:07:33 +1000 Subject: [address-policy-wg] 2008-07 Discussion Period extended until 24 August 2009 (Ensuring efficient use of historical IPv4 resources) In-Reply-To: <20090728092819.T61841-100000@capral.ripn.net> References: <20090728092819.T61841-100000@capral.ripn.net> Message-ID: <4A6FF535.6010900@cisco.com> Hi Larisa, Larisa A. Yurkina said the following on 28/7/09 16:33 : > > I'm against the position about "documentation of all address resources > they hold,including pre-RIR registrations". > The "documentation" in pre-RIR times did not look like "forms for > gathering the required information", with "network infrastructure > and future plans" from ripe-471 (6.1.). > They only contained a template for db and that's all. > To fulfil the proposed policy, I have to turn to customers of pre-rir > /16s and ask them "all" to re-right their request forms to ripe-381. > Which is hardly possible. I don't see where the proposed policy says that customers who received pre-rir address space from you have to now fill in ripe-381 style forms. Can you point me to the text? What I'm proposing is that LIRs who hold pre-rir addresses simply document the utilisation of those addresses, and at what level. If your customer has received pre-RIR space from you, and they are announcing it all to you, then I'd say it is reasonable to assume that they are using it. If they are only announcing 50% of it, then it is reasonable to assume that only 50% is being used. The other 50% could be used by other customers of yours, or in your own infrastructure, etc. The policy proposal requests LIRs who have address space that is not used to indicate so when they apply for fresh space. In other words, request LIRs to use unused space first before applying for fresh space. Does this address your concerns? philip -- From ula at ripn.net Wed Jul 29 11:30:50 2009 From: ula at ripn.net (Larisa A. Yurkina) Date: Wed, 29 Jul 2009 13:30:50 +0400 (MSD) Subject: [address-policy-wg] 2008-07 Discussion Period extended until 24 August 2009 (Ensuring efficient use of historical IPv4 resources) In-Reply-To: <4A6FF535.6010900@cisco.com> Message-ID: <20090729121912.U77019-100000@capral.ripn.net> On Wed, 29 Jul 2009, Philip Smith wrote: > Hi Larisa, Hi Philip, > > Larisa A. Yurkina said the following on 28/7/09 16:33 : > > > > I'm against the position about "documentation of all address resources > > they hold,including pre-RIR registrations". > > The "documentation" in pre-RIR times did not look like "forms for > > gathering the required information", with "network infrastructure > > and future plans" from ripe-471 (6.1.). > > They only contained a template for db and that's all. > > To fulfil the proposed policy, I have to turn to customers of pre-rir > > /16s and ask them "all" to re-right their request forms to ripe-381. > > Which is hardly possible. > > I don't see where the proposed policy says that customers who received > pre-rir address space from you have to now fill in ripe-381 style forms. > Can you point me to the text? > "When requesting an additional allocation, an LIR will be asked about the utilisation and documentation of all address resources they hold, not just those they have received from the RIPE NCC (this includes pre-RIR registrations)." You include pre-rir registrations into procedure of getting additional allocation for LIR. Ripe-471 says: "Additional address space will only be allocated after the information supplied with the request has been verified and a new allocation deemed necessary." What kind of information you must supply? Please see the standard hm questionnaire: "For each netname listed which was assigned using your AW, please tell us what the organisation does and how they are using the address space. Please include numbers of customers and customer:IP ratio where such services are being provided. For broadband services using more than a /20 in total, please provide current utilisation statistics. This will give us an overview of how the IP addresses are distributed within the networks." In fact, it is ripe-381 information. Which is not a problem for your recent assignements documentation you have to keep according policy. But it can cause problems for some 15 years-old assignements. How you motivate old customers to provide inform like that? Just because you need a new allocation? All that can make getting additional allocation very problematic. > What I'm proposing is that LIRs who hold pre-rir addresses simply > document the utilisation of those addresses, and at what level. If your > customer has received pre-RIR space from you, and they are announcing it > all to you, then I'd say it is reasonable to assume that they are using > it. If they are only announcing 50% of it, then it is reasonable to > assume that only 50% is being used. The other 50% could be used by other > customers of yours, or in your own infrastructure, etc. > > The policy proposal requests LIRs who have address space that is not > used to indicate so when they apply for fresh space. In other words, > request LIRs to use unused space first before applying for fresh space. > I'm completely agree, if address space is not used, it should be re-assigned to those who use it. But, your proposal does not say a about "document the utilisation of those addresses" in some other way than the standard procedure of getting a new allocation. If you propose some kind of utilisation rate documentation for pre-rir please give more details. > Does this address your concerns? > > philip > -- > > Thank you. With respect, Larisa Yurkina --- RIPN Registry center ----- From sander at steffann.nl Wed Jul 29 14:25:56 2009 From: sander at steffann.nl (Sander Steffann) Date: Wed, 29 Jul 2009 14:25:56 +0200 (CEST) Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <49C45E7B-B0D9-4C46-AF7D-61F418A379D0@steffann.nl> References: <4A5F3EE9.1070603@ripe.net> <4A5F7AB3.1020700@futureinquestion.net> <1248176648.4763.3345.camel@shane-asus-laptop> <4A6F62A8.8000307@ukraine.su> <01c201ca0fcb$e0776820$a1663860$@nl> <49C45E7B-B0D9-4C46-AF7D-61F418A379D0@steffann.nl> Message-ID: <1724.80.101.103.96.1248870356.squirrel@webmail.sintact.nl> Hi Max and Mark, >> Probably only Dutch court. But Dutch court will accept almost all >> decisions made by any court in the EU. That way Dutch court will >> take the decision of the other court and without looking at if it is >> correct it will make the same decision (just a technical point). > > Please take this discussion off the policy list. NCC services would be > more appropriate. That sounds much harsher than I intended... I was just trying to keep discussions on the right list, and I wrote that message much too quickly. My apologies for the very bad wording. Sander APWG co-chair From pfs at cisco.com Wed Jul 29 16:29:44 2009 From: pfs at cisco.com (Philip Smith) Date: Thu, 30 Jul 2009 00:29:44 +1000 Subject: [address-policy-wg] 2008-07 Discussion Period extended until 24 August 2009 (Ensuring efficient use of historical IPv4 resources) In-Reply-To: <20090729121912.U77019-100000@capral.ripn.net> References: <20090729121912.U77019-100000@capral.ripn.net> Message-ID: <4A705CD8.9070307@cisco.com> Hi Larisa, Larisa A. Yurkina said the following on 29/7/09 19:30 : > On Wed, 29 Jul 2009, Philip Smith wrote: > >> I don't see where the proposed policy says that customers who received >> pre-rir address space from you have to now fill in ripe-381 style forms. >> Can you point me to the text? >> > "When requesting an additional allocation, an LIR will be asked about > the utilisation and documentation of all address resources they hold, > not just those they have received from the RIPE NCC (this includes > pre-RIR registrations)." I don't see where this says that ripe-381 style forms have to be filled in. My goal is to agree on the principle that LIRs have to document utilisation of all address resources they hold; policy proposals, in my experience, don't direct the RIPE NCC on how to implement them. > You include pre-rir registrations into procedure of getting additional > allocation for LIR. > Ripe-471 says: > "Additional address space will only be allocated after the information > supplied with the request has been verified and a new allocation deemed > necessary." Seems fair. > What kind of information you must supply? Please see the standard hm > questionnaire: As per above, I feel this is an implementation detail, not a problem with the policy itself. > Which is not a problem for your recent assignements documentation > you have to keep according policy. But it can cause problems > for some 15 years-old assignements. How you motivate old customers to > provide inform like that? Just because you need a new allocation? If we wish to talk about implementation details (rather than the policy itself), the way I'd motivate old customers is check and confirm with them what they are using, and whatever they are not using (i.e. not announcing to me or anyone else), I assume they are not using and therefore is free. As I described in my last e-mail. But isn't this really up to the RIPE NCC Secretariat to sort out at the implementation phase if this proposal is adopted... Best wishes, philip -- From andy at nosignal.org Wed Jul 29 21:22:59 2009 From: andy at nosignal.org (Andy Davidson) Date: Wed, 29 Jul 2009 20:22:59 +0100 Subject: [address-policy-wg] Reopening discussion on RIPE Policy Proposal 2006-05 In-Reply-To: <4A6B7FB0.4050401@inex.ie> References: <4A5F447F.2060408@easyhosting.nl> <9DD3D047-608B-4C18-B422-AB36AF537D09@marcoh.net> <4A6B2EFD.6060200@inex.ie> <20090725212919.33df4a73@obelix> <4A6B7FB0.4050401@inex.ie> Message-ID: <15D87869-7F40-4C6C-8225-14D35D9A1CBC@nosignal.org> On 25 Jul 2009, at 22:57, Nick Hilliard wrote: > Since 2005-01-01, 128 assignments were made of less than /24 and > 3934 of exactly /24. These figures do not look to me like the > results of 3934 honest assignment application forms. > > Turning this around, if the minimum PI assignment size were > increased from /32 to /24, there would have been 23k extra PI > addresses out of 5493760 total PI addresses assigned between > 2005-01-01 and 2009-05. That's about 0.4%. I agree that the amounts in question are trivial and the benefits to the community (at least for the ten minutes or so that there is unallocated ipv4 left...) will be appreciated by small orgs looking for the benefits of multihoming - Nick's words are right as usual. However, I don't think we should mandate that /24 be the minimum assignment size - the rule should allow requests for a /24 to be the minimum size for announcement on the Internet, but if networks are not planning to announce the prefix via bgp (e.g. non-announced loopback ranges), then they should be allowed to request a smaller range. But as you say if we do mandate this the effect is trivial. -- Regards, Andy Davidson +44 (0)20 7993 1700 www.netsumo.com NetSumo Ltd, Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC /* Opinions are my own and & may not constitute policy of any org I work for */ From president at ukraine.su Thu Jul 30 21:40:03 2009 From: president at ukraine.su (Max Tulyev) Date: Thu, 30 Jul 2009 22:40:03 +0300 Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <49C45E7B-B0D9-4C46-AF7D-61F418A379D0@steffann.nl> References: <4A5F3EE9.1070603@ripe.net> <4A5F7AB3.1020700@futureinquestion.net> <1248176648.4763.3345.camel@shane-asus-laptop> <4A6F62A8.8000307@ukraine.su> <01c201ca0fcb$e0776820$a1663860$@nl> <49C45E7B-B0D9-4C46-AF7D-61F418A379D0@steffann.nl> Message-ID: <4A71F713.8080005@ukraine.su> Hi Sander, NCC services WG is only for LIRs AFAIR. This case is about the life cycle of the PI space, so it should be interesting for non-members too, am I right? Sander Steffann wrote: > Hi Max and Mark, > >> Probably only Dutch court. But Dutch court will accept almost all >> decisions >> made by any court in the EU. That way Dutch court will take the >> decision of >> the other court and without looking at if it is correct it will make the >> same decision (just a technical point). > > Please take this discussion off the policy list. NCC services would be > more appropriate. > > Thanks, > Sander > > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From sander at steffann.nl Fri Jul 31 01:53:18 2009 From: sander at steffann.nl (Sander Steffann) Date: Fri, 31 Jul 2009 01:53:18 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <4A71F713.8080005@ukraine.su> References: <4A5F3EE9.1070603@ripe.net> <4A5F7AB3.1020700@futureinquestion.net> <1248176648.4763.3345.camel@shane-asus-laptop> <4A6F62A8.8000307@ukraine.su> <01c201ca0fcb$e0776820$a1663860$@nl> <49C45E7B-B0D9-4C46-AF7D-61F418A379D0@steffann.nl> <4A71F713.8080005@ukraine.su> Message-ID: <12C96DE6-5187-45E2-9246-D25B8247197D@steffann.nl> Hi Max, > NCC services WG is only for LIRs AFAIR. This case is about the life > cycle of the PI space, so it should be interesting for non-members > too, > am I right? The NCC services WG is just like all other RIPE WG's: completely open. As far as I know the only thing that is 'members only' is the RIPE NCC General Meeting. Sander