From Remco.vanMook at eu.equinix.com Thu Apr 2 15:15:59 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Thu, 2 Apr 2009 15:15:59 +0200 Subject: [address-policy-wg] 2009-02 New Policy Proposal (Allocating Resources to the RIPE NCC) References: <20090324154116.ADB4D2F583@herring.ripe.net> <2E61C47A190CA44ABFCF23147E57E4BC0109B6A3@NLEN1EX1.eu.win.equinix.com> <49D1EE3B.90404@inex.ie> <49D21524.8050209@futureinquestion.net> Message-ID: <2E61C47A190CA44ABFCF23147E57E4BCE638F2@NLEN1EX1.eu.win.equinix.com> Dear all, My apologies for not responding any quicker - getting Internet access in the middle of nowhere (which is a very nice place by the way) is hard, but getting access to company networks is even harder. I think Nicks suggestion has merit and will change the proposal accordingly. I also have a slight preference for the pool of arbiters; any comments in that respect? Kind regards, Remco -----Original Message----- From: David Monosov [mailto:davidm at futureinquestion.net] Sent: dinsdag 31 maart 2009 15:06 To: Nick Hilliard Cc: Remco van Mook; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2009-02 New Policy Proposal (Allocating Resources to the RIPE NCC) Dear Nick, Remco, address-policy-wg, The suggested changes Nick put forward appear sensible, and should result in a lasting framework with a less irregular process. By keeping the hostmasters in the loop, the requirement "For the purpose of evaluating, the request will be treated as if it were filed by a regular LIR." is met by the most competent authority. This, in turn, allows the Pool of Arbiters to concentrate on the merit of a request rather than policy technicalities. Therefore, I support these changes. -- Respectfully yours, David Monosov Nick Hilliard wrote: > On 25/03/2009 08:41, Remco van Mook wrote: >> There won't be a contract because it's an impossibility - that's one of >> the main rationales behind the proposal. We could have the NCC sign >> twice but that's a bit ridiculous and won't be a legal contract anyway. > > A couple of comments here: > > 1. It may be a good idea to explicitly note in the proposal that the > RIPE NCC is formally exempted from signing any of the normal contracts > required for number resource assignment / allocation. > > 2. I don't want to sound like the language fascist here, but as the > proposal deals with both assignment and allocation of resources (to use > the RIPE NCC terminology), it might be a good idea to use the two terms > in the policy proposal. Currently the word "allocation" is used, but if > the NCC is going to apply for a PI ipv6 /48, then that's an assignment. > Similarly for ASNs. > > 3. I have a slight preference for using the Pool of Arbiters instead of > the WG Chairs for the approval mechanism, purely on the grounds that > smaller committees are better than bigger ones. I don't have a problem > with Remco being proposer of this policy change and also being on the > pool of arbiters. Just out of interest, the pool of arbiters is > described here: > > http://www.ripe.net/membership/arbitration.html > > 4. Regarding the function of the approval group, there are two important > requirements for RIPE NCC number resource assignment / allocation process: > > a. consistency with the assignment / allocation guidelines > b. process transparency > > As it stands, the proposed process delegates the entire process of > number resource approval to the approval group, with no obligation to > explain or publicise their decision. I just wonder if it wouldn't be > better to have a process like this: > > 4.1: assignment / allocation request received and processed by RIPE > NCC hostmasters who will give a formal written opinion on whether the > request is consistent with current assignment / allocation guidelines > 4.2: this opinion is evaluated by [pool of arbiters / WG chairs] who > are entitled to approve the request only if the hostmaster team find > that the request is consistent with current rules. > 4.3: either way, the request, the hostmaster recommendation and the > reasoning of [pool of arbiters / WG chairs] is published. > 4.4: if both hostmasters and [pool of arbiters / WG chairs] decline > request, then petition can be made to RIPE Plenary. > > There are a couple of reasons for this alternative proposal. First, > it's the purpose of the RIPE NCC hostmaster team to evaluate whether > number requests are consistent with the rules. The [pool of arbiters / > WG chairs] are not hostmasters. Secondly, the [pool of arbiters / WG > chairs] should not necessarily be given sole authority to decide whether > a number request is consistent with current RIPE rules; 4.2 above > implies that if the RIPE NCC hostmaster team believes that a request is > not justified, the [pool of arbiters / WG chairs] have no authority to > override that decision. Thirdly, the reasoning and decision of the [pool > of arbiters / WG chairs] should be published so that this mystical ideal > of transparency is achieved. > > Nick > 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 rhe at nosc.ja.net Fri Apr 3 00:41:48 2009 From: rhe at nosc.ja.net (Rob Evans) Date: Thu, 2 Apr 2009 23:41:48 +0100 Subject: [address-policy-wg] 2009-02 New Policy Proposal (Allocating Resources to the RIPE NCC) In-Reply-To: <2E61C47A190CA44ABFCF23147E57E4BCE638F2@NLEN1EX1.eu.win.equinix.com> References: <20090324154116.ADB4D2F583@herring.ripe.net> <2E61C47A190CA44ABFCF23147E57E4BC0109B6A3@NLEN1EX1.eu.win.equinix.com> <49D1EE3B.90404@inex.ie> <49D21524.8050209@futureinquestion.net> <2E61C47A190CA44ABFCF23147E57E4BCE638F2@NLEN1EX1.eu.win.equinix.com> Message-ID: <00BE3AF9-DFE8-4F87-9B9C-E52C654A28B3@nosc.ja.net> Hi Remco, > I also have a slight preference for the pool of arbiters; any comments > in that respect? As a working group co-chair, I'm fully in favour of that change. It would appear to be a far better choice. All the best, Rob From filiz at ripe.net Tue Apr 7 10:15:55 2009 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 07 Apr 2009 10:15:55 +0200 Subject: [address-policy-wg] Run Out Fairly (2009-03) New Policy Proposal Message-ID: <20090407081555.AAB612F583@herring.ripe.net> PDP Number: 2009-03 Run Out Fairly Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-03.html We encourage you to review this proposal and send your comments to before 5 May 2009. Regards Filiz Yilmaz Policy Development Officer RIPE NCC From daniel.karrenberg at ripe.net Mon Apr 6 14:10:40 2009 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 6 Apr 2009 14:10:40 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" Message-ID: <20090406121040.GT56098@reiftel.karrenberg.net> Dear colleagues, attached you will find a policy proposal we call "Run Out Fairly". It is based on a discussion instigated by your's truly during the open policy hour at the latest RIPE meeting. This is a proposal to gradually reduce the allocation and assignment periods in step with the expected life time of the IPv4 unallocated pool in order to address the perception of unfairness once the pool has run out. The proposal is not intended to stretch the lifetime of the unallocated pool. The proposal is independent of other proposals to reserve address space for transition purposes and/or new entrants. It can be implemented independently of these. We thank Filiz Yilmaz for her help, invite discussion of this proposal and look forward to high quality comments. For the authors Daniel Karrenberg PS: Can we refer to this proposal by name and not by number? ;-) -------------- next part -------------- 1. Number (will be assigned by the RIPE NCC) 2. Policy Proposal Name: Run Out Fairly 3. Authors a. name: Daniel Karrenberg b. e-mail: daniel.karrenberg at ipe.net c. organisation: RIPE NCC a. name: Niall O'Reilly b. e-mail: Niall.oReilly at ucd.ie c. organisation: University College Dublin a. name: Nigel Titley b. e-mail: nigel at titley.com c: organisation: Easynet Nigel Titley serves on the RIPE NCC board of directors. a. name: Randy Bush b. e-mail: randy at psg.com c. organisation: IIJ 4. Proposal Version: 1.5 5. Submission Date: 6 April 2009 6. Suggested RIPE Working Group for discussion and publication: Address Policy 7. Proposal type: Modify 8. Policy term: Renewable 9. Summary of proposal This is a proposal to gradually reduce the allocation and assignment periods in step with the expected life time of the IPv4 unallocated pool in order to address the perception of unfairness once the pool has run out. The proposal is not intended to stretch the lifetime of the unallocated pool. The proposal is independent of other proposals to reserve address space for transition purposes and/or new entrants. It can be implemented independently of these. 10. Policy text (from ripe-449) a. Current: 5.0 Policies and Guidelines for Allocations ... The RIPE NCC allocates enough address space to LIRs to meet their needs for a period of up to 12 months. 6.3 Utilisation Rates Assignments' immediate utilisation should be at least 25% of the assigned space. After one year, this should be at least 50% of the space unless special circumstances are defined. b. New: 5.0 Policies and Guidelines for Allocations ... The RIPE NCC allocates enough address space to LIRs to meet their needs for a period of up to 12 months. Starting on 1 July 2010, a gradual reduction in the allocation period will be applied as follows: As of 1 July 2010, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to nine months. As of 1 January 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to six months. As of 1 July 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to three months. 6.0 Policies and Guidelines for Assignments The End Users must be assigned with enough address space to meet their needs for a period of up to 12 months. Starting on 1 July 2010, a gradual reduction in the assignment period will be applied as follows: As of 1 July 2010, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to nine months. As of 1 January 2011, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to six months. As of 1 July 2011, the RIPE NCC or the LIRs will start assigning enough address space to End Users to meet their needs for a period of up to three months. 6.3 Utilisation Rates The utilisation rate of an assignment must be at least 50% of the total space half way through the assignment period applied at the time of the assignment. For example, in the case of a 12-month assignment period, half of the total space assigned must be utilised after six months. 11. Rationale: In order to avoid possible oversight or confusion, we point out this proposal makes the time periods governing allocations and assignments identical immediately upon adoption. Both periods will then be reduced according to a fixed time scheme. The assignment utilisation rate requires 50% utilisation not, as formerly, after one year, but rather at the halfway point of that period and there is no longer a specific target for the immediate utilisation. See below for the rationale behind this. a. Arguments supporting the proposal As the RIPE NCC IPv4 unallocated pool runs out, the current policy will allow for the very last allocations to be made for the purpose of deployment up to 12 months afterwards. Once the unallocated pool has in fact run out, there will be some users that just received up to 24 months worth of address space and some who will receive nothing. This will very likely cause concerns because a quite valid perception of this event is that one user will be able to grow their business for another 12 month while the next one in the queue will be stuck. There is a also a real potential for a very large address space user to receive a huge allocation under this policy which pre-empts a lot of requests from smaller users ; this will greatly increase the perception of unfairness. RIPE and our self-governance can very well come under serious adverse criticism when this happens. We will appear to be have been quite careless and short-sighted in the eyes of those who perceive this unfairness. There are some scenarios where a large number of RIPE NCC members will feel this way, as will governments and regulators. During RIPE 57, one of the authors presented this rationale during the Address Policy Working Group. The presentation, including data about allocation sizes between 2001 and 2007, can be found at: http://www.ripe.net/ripe/meetings/ripe-57/presentations/Karrenberg-The_Very_Last_IPv4_Allocations_Some_Concerns_About_Perceived_Unfairness.ufxZ.pdf The feedback in that session suggested that this concrete proposal be developed. The principle of distributing address space according to demonstrated need is sound should not be changed. In order to address the unfairness we propose to reduce the period over which the need is recognised roughly in correlation with the expected life time of the unallocated pool. This addresses the unfairness without abandoning the principle. The same principle should apply to assignments for both Provider Independent (PI) and Provider Aggregatable (PA) address space for End Users that can be made directly by the RIPE NCC or the LIRs. The exact date of the exhaustion of the RIPE NCC's IPv4 unallocated pool is hard to predict. It will also be influenced by other policy changes that are currently being discussed. A widely accepted projection of unallocated pool exhaustion dates is published by Geoff Huston, Chief Scientist of APNIC. His projection for the exhaustion of the RIPE NCC pool can be found at http://www.potaroo.net/tools/ipv4/fig29b.png The time line proposed here aims to set a schedule that roughly follows these projections and is simple and predictable at the same time. No one can predict the actual point in time when the RIPE NCC pool will be exhausted. We propose not to base policy on changing predictions but rather to decide on a reasonable schedule today that is fixed now and thus predictable. We stress that this proposal aims to address only the perceived unfairness we outline above. The proposal explicitly does not aim to increase the lifetime of the unallocated pool nor to address any other issue. The proposal is independent of other proposals to reserve address space for transition purposes and/or new entrants. It can be implemented independently these. In particular there is no inter-dependency with "Use of final /8" (2008-6). The time schedule of this proposal need only be updated if further policy changes drastically change the expected date of exhaustion of the unallocated pool. Note well that the proposal sets higher allocation rate targets that are consistent with allocation and assignment sizes immediately on adoption. There no longer is a requirement for 'immediate' utilisation of 25%. The rationale for this change is twofold: firstly it aligns both periods which makes application of this policy significantly more straight forward than it would otherwise be; secondly it sets a goals for assignment utilisation half way through the period rather at the beginning and after the fixed period of one year. This is based on feedback from the RIPE NCC registration services staff. b. Arguments opposing the proposal Some may argue that reduced allocation and assignment periods will be too short to sustain efficiency in routing and ISP, provider and LIR operations. However, we believe that towards the end of the available IPv4 pool, it is the responsibility of all, to make sure the allocation and assignment of the resources remain perceived as "fair". -------------- next part -------------- A non-text attachment was scrubbed... Name: 20090406-run-out-fairly-submit.pdf Type: application/pdf Size: 67797 bytes Desc: not available URL: From dogwallah at gmail.com Tue Apr 7 10:31:31 2009 From: dogwallah at gmail.com (McTim) Date: Tue, 7 Apr 2009 11:31:31 +0300 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <20090406121040.GT56098@reiftel.karrenberg.net> References: <20090406121040.GT56098@reiftel.karrenberg.net> Message-ID: HI Daniel, On Mon, Apr 6, 2009 at 3:10 PM, Daniel Karrenberg wrote: > > Dear colleagues, > > attached you will find a policy proposal we call "Run Out Fairly". Seems fair to me, count me as +1 in support. -- Cheers, McTim From filiz at ripe.net Tue Apr 7 12:46:26 2009 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 07 Apr 2009 12:46:26 +0200 Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) Message-ID: <20090407104626.405C72F593@herring.ripe.net> PDP Number: 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-04.html We encourage you to review this proposal and send your comments to before 5 May 2009. Regards Filiz Yilmaz Policy Development Officer RIPE NCC From marcoh at marcoh.net Tue Apr 7 13:14:04 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 7 Apr 2009 13:14:04 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <20090406121040.GT56098@reiftel.karrenberg.net> References: <20090406121040.GT56098@reiftel.karrenberg.net> Message-ID: <53DE318C-89C5-4250-A4DF-1B0230391DA8@marcoh.net> Hi all, This seems indeed fair and I therefor support this proposal. I have one question though, are there similair proposals out there in other regions ? Groet, MarcoH From ms at man-da.de Tue Apr 7 13:47:15 2009 From: ms at man-da.de (Marcus Stoegbauer) Date: Tue, 07 Apr 2009 13:47:15 +0200 Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) In-Reply-To: <20090407104626.405C72F593@herring.ripe.net> References: <20090407104626.405C72F593@herring.ripe.net> Message-ID: <49DB3D43.7060200@man-da.de> > PDP Number: 2009-04 > IPv4 Allocation and Assignments to Facilitate IPv6 Deployment > > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. I think I have a feeling what the meaning of this proposal should be, but the actual words used to write it are saying something completely different for me. For a start: I can't really tell if the new policy text should replace the old IPv4 address allocation and assignment policy. The new policy only talks about address space given out to ISPs for transition techniques, so I assume that an ISP with a lot of free (i.e. not assigned/unused) IPv4 address space can also get another allocation under this policy? Then the minimum size of /27. Obviously it would be a brilliant test to see if routers will be able to hold all the IPv6 PI prefixes that will come to life once we allow them to be handed out. And it would be a very handy way to tear down the v4 internet, so it's in full compliance with some IPv6 implementation plans. But to be serious for a minute: if all those /27 would be announced a IPv4 full table would nearly triple in size (or in other words: all those /27 are twice the size of a full IPv4 table today). This can't possibly end well, so I'm not in favor for this proposal in its current form. Marcus From ripe+apwg at karotte.org Tue Apr 7 13:49:08 2009 From: ripe+apwg at karotte.org (Sebastian Wiesinger) Date: Tue, 7 Apr 2009 13:49:08 +0200 Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) In-Reply-To: <20090407104626.405C72F593@herring.ripe.net> References: <20090407104626.405C72F593@herring.ripe.net> Message-ID: <20090407114908.GA1385@danton.fire-world.de> * Filiz Yilmaz [2009-04-07 12:48]: > PDP Number: 2009-04 > IPv4 Allocation and Assignments to Facilitate IPv6 Deployment > > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2009-04.html > > We encourage you to review this proposal and send your comments to > before 5 May 2009. Hi, if I understand this proposal correctly, you want to give a /27 to an LIR or end user so that they can do NAT-PT or something like that? First: It won't work. Most people I know filter prefixes smaller than /24 in the DFZ. They will not see these allocations. You can't assume that they will change their filters for this. I would estimate that most of them won't. Many can't do this because it will not fit in their RIB/FIB. So if you do this you would have to give out a /24 at least. Second: We do want to facilitate deployment of IPv6. I think this proposal could be counterproductive. You're splitting up the remaining space in smaller peaces so that more people can use IPv4 for a longer timespan. And if you have to give out /24s you can bet that people will use it for other things besides NAT-PT etc. Third: Is it necessary? You already have to demonstrate a need for address space if you want a new allocation. If an LIR already has an allocation I assume that they can spare an /27 for IPv6 transition. If you have a new LIR you allocate them a /21 if they can demonstrate the need for it, no change there. Kind Regards, Sebastian -- GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From filiz at ripe.net Tue Apr 7 14:02:48 2009 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 7 Apr 2009 14:02:48 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <53DE318C-89C5-4250-A4DF-1B0230391DA8@marcoh.net> References: <20090406121040.GT56098@reiftel.karrenberg.net> <53DE318C-89C5-4250-A4DF-1B0230391DA8@marcoh.net> Message-ID: <4E2936DB-572E-45C5-B1CF-751D680B0750@ripe.net> Dear Marco, Yes, there are some proposals in other regions that seem to be similar to this one. Note that the similarity is often in the *intentions* rather than the detailed criteria they are proposing as of a solution to the foreseen problem. Below, please find a brief overview of these proposals: -o- In ARIN, there is a proposal called "Depleted IPv4 reserves". It is proposing to set a limit to be applied to all IPv4 address requests when ARIN's reserve of unallocated IPv4 address space drops below an equivalent of /9. By then, the address space that an organisation can receive will be limited to a single /20 within a six month period. This is currently under discussion and you can find further details at: https://www.arin.net/policy/proposals/2009_2.html -o- In APNIC, they have discussed two proposals in their last meeting back in February. One of them was to change the timeframe APNIC uses to make IPv4 allocations to meet LIRs' needs from twelve months to six months. The other was to set a maximum APNIC allocation size, by gradually decrease the maximum allocation size based on the remaining number of /8s in the IANA free pool. Both of these proposals were abandoned after APNIC 27, following a lack of community support. You can still find their details at: http://www.apnic.net/policy/proposals/prop-063-v002.html http://www.apnic.net/policy/proposals/prop-070-v001.html -o- LACNIC has reached consensus back in 2008 on a proposal called "Special IPv4 Allocations/Assignments Reserved for New Members". Accordingly when IANA's pool of IPv4 addresses is exhausted and LACNIC has a /12 left in their pool, only new members will receive address space from LACNIC. This space will be a /24 as the minimum and a /22 as the maximum. They have further detailed criteria and you can see them at: http://lacnic.net/documentos/politicas/LAC-2008-04-propuesta-en.pdf I hope this helps. Kind regards, Filiz Yilmaz Policy Development Officer RIPE NCC On Apr 7, 2009, at 1:14 PM, Marco Hogewoning wrote: > Hi all, > > This seems indeed fair and I therefor support this proposal. I have > one question though, are there similair proposals out there in other > regions ? > > Groet, > > MarcoH > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcoh at marcoh.net Tue Apr 7 14:16:35 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 7 Apr 2009 14:16:35 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <20090407121020.GB9760@reiftel.karrenberg.net> References: <20090406121040.GT56098@reiftel.karrenberg.net> <53DE318C-89C5-4250-A4DF-1B0230391DA8@marcoh.net> <20090407121020.GB9760@reiftel.karrenberg.net> Message-ID: <819E00A7-2EA7-4DBB-99E6-4DA524E69B89@marcoh.net> On 7 apr 2009, at 14:10, Daniel Karrenberg wrote: > On 07.04 13:14, Marco Hogewoning wrote: >> Hi all, >> >> This seems indeed fair and I therefor support this proposal. I have >> one question though, are there similair proposals out there in other >> regions ? > > Not yet, although I have seen some discussion in the same general > direction. Of course it would not be ideal if only one region > eventually did this. But this cannot be a reason to do nothing. If > it > turns out that at one point in the future we have too widely varying > policies in effect across the regions, we have to review the situation > and then again make the trade-off between different kinds of fairness. Agreed, we can't sit on our hands and wait. At the same time if the other 4 regions take a different approach this might encourage people to go shopping between RIR's. Groet, MarcoH From president at ukraine.su Tue Apr 7 14:34:14 2009 From: president at ukraine.su (Max Tulyev) Date: Tue, 07 Apr 2009 15:34:14 +0300 Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) In-Reply-To: <20090407104626.405C72F593@herring.ripe.net> References: <20090407104626.405C72F593@herring.ripe.net> Message-ID: <49DB4846.30101@ukraine.su> Hi All, I think it is a good proposal, but only with IPv6 PI support. Now a number of our IPv4 PI clients wants IPv6 PI, but can't get it... Filiz Yilmaz wrote: > PDP Number: 2009-04 > IPv4 Allocation and Assignments to Facilitate IPv6 Deployment > > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2009-04.html > > We encourage you to review this proposal and send your comments to > before 5 May 2009. > > Regards > > Filiz Yilmaz > Policy Development Officer > RIPE NCC > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Tue Apr 7 14:38:16 2009 From: president at ukraine.su (Max Tulyev) Date: Tue, 07 Apr 2009 15:38:16 +0300 Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) In-Reply-To: <49DB3D43.7060200@man-da.de> References: <20090407104626.405C72F593@herring.ripe.net> <49DB3D43.7060200@man-da.de> Message-ID: <49DB4938.8090806@ukraine.su> Marcus Stoegbauer wrote: > But to be serious for a minute: if all those /27 would be announced a > IPv4 full table would nearly triple in size (or in other words: all > those /27 are twice the size of a full IPv4 table today). This can't > possibly end well, so I'm not in favor for this proposal in its current > form. When the price for IPv4 will be much higher, we will see even a lot of /32 in the table ;) Seriously, in that time hardware will become capable of carrying that easy. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From swmike at swm.pp.se Tue Apr 7 14:48:32 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 7 Apr 2009 14:48:32 +0200 (CEST) Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) In-Reply-To: <49DB4938.8090806@ukraine.su> References: <20090407104626.405C72F593@herring.ripe.net> <49DB3D43.7060200@man-da.de> <49DB4938.8090806@ukraine.su> Message-ID: On Tue, 7 Apr 2009, Max Tulyev wrote: > Seriously, in that time hardware will become capable of carrying that > easy. What timeframe is that? 10 years ago, the state of the art core routing platforms were capable of a few hundreds of thousands of FIB routes, today it seems to be 1-2M for the more expensive platforms. If you're talking about 2020 then by then 3-4M might be working well, but you'd still spend a lot more than than needed in converging a network with that many prefixes. For the good of the Internet, let's not put more prefixes in DFZ than needed. -- Mikael Abrahamsson email: swmike at swm.pp.se From president at ukraine.su Tue Apr 7 15:39:33 2009 From: president at ukraine.su (Max Tulyev) Date: Tue, 07 Apr 2009 16:39:33 +0300 Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) In-Reply-To: References: <20090407104626.405C72F593@herring.ripe.net> <49DB3D43.7060200@man-da.de> <49DB4938.8090806@ukraine.su> Message-ID: <49DB5795.9080101@ukraine.su> I hear from Juniper they was capable of 5M routes an year ago. I think, 2020 year hardware should be capable about 500M prefixes easy. Mikael Abrahamsson wrote: > On Tue, 7 Apr 2009, Max Tulyev wrote: > >> Seriously, in that time hardware will become capable of carrying that >> easy. > > What timeframe is that? > > 10 years ago, the state of the art core routing platforms were capable > of a few hundreds of thousands of FIB routes, today it seems to be 1-2M > for the more expensive platforms. If you're talking about 2020 then by > then 3-4M might be working well, but you'd still spend a lot more than > than needed in converging a network with that many prefixes. > > For the good of the Internet, let's not put more prefixes in DFZ than > needed. > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From ondrej.sury at nic.cz Tue Apr 7 15:53:04 2009 From: ondrej.sury at nic.cz (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Tue, 7 Apr 2009 15:53:04 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <20090406121040.GT56098@reiftel.karrenberg.net> References: <20090406121040.GT56098@reiftel.karrenberg.net> Message-ID: On Mon, Apr 6, 2009 at 2:10 PM, Daniel Karrenberg < daniel.karrenberg at ripe.net> wrote: > > Dear colleagues, > > attached you will find a policy proposal we call "Run Out Fairly". > It is based on a discussion instigated by your's truly during the > open policy hour at the latest RIPE meeting. > > This is a proposal to gradually reduce the allocation and assignment > periods in step with the expected life time of the IPv4 unallocated pool > in order to address the perception of unfairness once the pool has run > out. > > The proposal is not intended to stretch the lifetime of the unallocated > pool. > > The proposal is independent of other proposals to reserve address space > for transition purposes and/or new entrants. It can be implemented > independently of these. > > We thank Filiz Yilmaz for her help, invite discussion of this proposal > and look forward to high quality comments. > > For the authors > > Daniel Karrenberg > > PS: Can we refer to this proposal by name and not by number? ;-) > I have read the "Run Out Fairly" proposal and I support it. Ondrej -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at Linux.IT Tue Apr 7 16:08:33 2009 From: md at Linux.IT (Marco d'Itri) Date: Tue, 7 Apr 2009 16:08:33 +0200 Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) In-Reply-To: <49DB5795.9080101@ukraine.su> References: <20090407104626.405C72F593@herring.ripe.net> <49DB3D43.7060200@man-da.de> <49DB4938.8090806@ukraine.su> <49DB5795.9080101@ukraine.su> Message-ID: <20090407140833.GA20490@bongo.bofh.it> On Apr 07, Max Tulyev wrote: > I hear from Juniper they was capable of 5M routes an year ago. > > I think, 2020 year hardware should be capable about 500M prefixes easy. You keep missing the point. Even if we junk the Sup720-3BXL then the problem will be processing the updates without resorting again to dampening. -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From daniel.karrenberg at ripe.net Tue Apr 7 14:10:20 2009 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 7 Apr 2009 14:10:20 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <53DE318C-89C5-4250-A4DF-1B0230391DA8@marcoh.net> References: <20090406121040.GT56098@reiftel.karrenberg.net> <53DE318C-89C5-4250-A4DF-1B0230391DA8@marcoh.net> Message-ID: <20090407121020.GB9760@reiftel.karrenberg.net> On 07.04 13:14, Marco Hogewoning wrote: > Hi all, > > This seems indeed fair and I therefor support this proposal. I have > one question though, are there similair proposals out there in other > regions ? Not yet, although I have seen some discussion in the same general direction. Of course it would not be ideal if only one region eventually did this. But this cannot be a reason to do nothing. If it turns out that at one point in the future we have too widely varying policies in effect across the regions, we have to review the situation and then again make the trade-off between different kinds of fairness. Groetjes Daniel From daniel.karrenberg at ripe.net Tue Apr 7 14:19:25 2009 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 7 Apr 2009 14:19:25 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <4E2936DB-572E-45C5-B1CF-751D680B0750@ripe.net> References: <20090406121040.GT56098@reiftel.karrenberg.net> <53DE318C-89C5-4250-A4DF-1B0230391DA8@marcoh.net> <4E2936DB-572E-45C5-B1CF-751D680B0750@ripe.net> Message-ID: <20090407121925.GC9760@reiftel.karrenberg.net> On 07.04 14:02, Filiz Yilmaz wrote: > ... > > In ARIN, there is a proposal called "Depleted IPv4 reserves". > It is proposing to set a limit to be applied to all IPv4 address > requests when ARIN's reserve of unallocated IPv4 address space drops > below an equivalent of /9. By then, the address space that an > organisation can receive will be limited to a single /20 within a six > month period. > > This is currently under discussion and you can find further details at: > > https://www.arin.net/policy/proposals/2009_2.html While similar this appears to be a transition/new entrant reservation. It is orthogonal to "Run Out Fairly". > -o- > > In APNIC, they have discussed two proposals in their last meeting back > in February. One of them was to change the timeframe APNIC uses to > make IPv4 allocations to meet LIRs' needs from twelve months to six > months. The other was to set a maximum APNIC allocation size, by > gradually decrease the maximum allocation size based on the remaining > number of /8s in the IANA free pool. > > Both of these proposals were abandoned after APNIC 27, following a > lack of community support. > You can still find their details at: > > http://www.apnic.net/policy/proposals/prop-063-v002.html > http://www.apnic.net/policy/proposals/prop-070-v001.html These were the discussions I referred to. Note that one of the auhors of "Run Out Fairly" plays some role in the APNIC policy sig. ... > -o- > > LACNIC has reached consensus back in 2008 on a proposal called > "Special IPv4 Allocations/Assignments Reserved for New Members". > Accordingly when IANA's pool of IPv4 addresses is exhausted and LACNIC > has a /12 left in their pool, only new members will receive address > space from LACNIC. This space will be a /24 as the minimum and a /22 > as the maximum. They have further detailed criteria and you can see > them at: > > http://lacnic.net/documentos/politicas/LAC-2008-04-propuesta-en.pdf Again more of a transition/new entrant reservation. From daniel.karrenberg at ripe.net Tue Apr 7 14:19:53 2009 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 7 Apr 2009 14:19:53 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <819E00A7-2EA7-4DBB-99E6-4DA524E69B89@marcoh.net> References: <20090406121040.GT56098@reiftel.karrenberg.net> <53DE318C-89C5-4250-A4DF-1B0230391DA8@marcoh.net> <20090407121020.GB9760@reiftel.karrenberg.net> <819E00A7-2EA7-4DBB-99E6-4DA524E69B89@marcoh.net> Message-ID: <20090407121953.GD9760@reiftel.karrenberg.net> On 07.04 14:16, Marco Hogewoning wrote: > > On 7 apr 2009, at 14:10, Daniel Karrenberg wrote: > > >On 07.04 13:14, Marco Hogewoning wrote: > >>Hi all, > >> > >>This seems indeed fair and I therefor support this proposal. I have > >>one question though, are there similair proposals out there in other > >>regions ? > > > >Not yet, although I have seen some discussion in the same general > >direction. Of course it would not be ideal if only one region > >eventually did this. But this cannot be a reason to do nothing. If > >it > >turns out that at one point in the future we have too widely varying > >policies in effect across the regions, we have to review the situation > >and then again make the trade-off between different kinds of fairness. > > > Agreed, we can't sit on our hands and wait. At the same time if the > other 4 regions take a different approach this might encourage people > to go shopping between RIR's. Yep. And we have to deal with that then. Daniel From andy at nosignal.org Tue Apr 7 19:54:00 2009 From: andy at nosignal.org (Andy Davidson) Date: Tue, 7 Apr 2009 18:54:00 +0100 Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) In-Reply-To: <20090407104626.405C72F593@herring.ripe.net> References: <20090407104626.405C72F593@herring.ripe.net> Message-ID: <4F891C73-15CE-4A70-9F08-535E13DA9FED@nosignal.org> On 7 Apr 2009, at 11:46, Filiz Yilmaz wrote: > http://www.ripe.net/ripe/policies/proposals/2009-04.html I don't know if it's entirely fair and just to hold v4 to ransom in order to drive v6 adoption, but as someone who has done v6 rollouts on his own network already, and is paid to roll v6 out onto others' networks, I appreciate the sentiment and think that healthy to set our minds wandering and get conversation started. If it's good to restrict the allocation and assignment of v4 resources to organisations who have a stated v6 deployment policy, then why do we need to wait until the final /8 has been allocated to the NCC before we begin such a policy ? Perhaps we should have a phased process that asks organisations how they are deploying v6 on the PA and PI request forms, and then future requests from that organisation, or related organisations are refused if the deployment has not started. Why was /27 selected rather than /26 or /25 ? Since most deployments have multiple, separate infrastructure assignments, and services/user assignments, it seems that a /27 as a minimum allocation is far to small to promote any degree of aggregation whatsoever. This policy is therefore counter to one of RIPE's regularly stated aims - to promote route aggregation. The counter argument to this is that I might as well accept that we the side of common sense has lost the v4 aggregation debate, and v4 after-market sales will drive deagg further, so why should we care ? On the other hand, perhaps this policy will be seen as an ipv4 life extension policy. We do not want to muddy the message that we send to the community. V4's free pool will soon be gone. Do not gamble your company on policies designed to extend the availability of a very scarce resource. Maybe we can pool some of the ideas in 2009-03 and -04, and the community response, and build a solid run down policy that encourages v6 adoption, but doesn't pretend to be able to extend the life of v4. Andy From leo.vegoda at icann.org Tue Apr 7 20:11:05 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 7 Apr 2009 11:11:05 -0700 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <20090406121040.GT56098@reiftel.karrenberg.net> Message-ID: Hi, Can the authors please explain how this proposal would work with the current policy, which sets the minimum allocation at /21? For instance, on 2 January 2011, how much address space should be allocated to a network which needs a /21 for the next year? If the minimum allocation needs to change along with the allocation and assignment periods then that should probably be documented in the proposal. Thanks, Leo From remco.vanmook at eu.equinix.com Tue Apr 7 20:58:09 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Tue, 07 Apr 2009 20:58:09 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <20090406121040.GT56098@reiftel.karrenberg.net> Message-ID: Dear Daniel, dear all, First of all I support this proposal, and thank you for taking the time to create it. I think the idea has great merit, but I?m also reminded of an idea I sent out to the address policy mailing list and the feedback I got based on that. For that thread, see: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00501. html . Just to refresh your memory, I proposed a policy that would only allocate a single block of space, regardless of the size of the request and available remaining inventory. One of the main shortcomings of my idea was that assignments from a new allocation don?t happen in a ?gradual? way, which is one of the main assumptions behind any scheme based on time-windows. Larger organizations will just come back quicker ? not necessarily after the set window. I?m afraid this proposal has the same ?weakness?. Kind regards, Remco On 06-04-09 14:10, "Daniel Karrenberg" wrote: > > > Dear colleagues, > > attached you will find a policy proposal we call "Run Out Fairly". > It is based on a discussion instigated by your's truly during the > open policy hour at the latest RIPE meeting. > > This is a proposal to gradually reduce the allocation and assignment > periods in step with the expected life time of the IPv4 unallocated pool > in order to address the perception of unfairness once the pool has run > out. > > The proposal is not intended to stretch the lifetime of the unallocated > pool. > > The proposal is independent of other proposals to reserve address space > for transition purposes and/or new entrants. It can be implemented > independently of these. > > We thank Filiz Yilmaz for her help, invite discussion of this proposal > and look forward to high quality comments. > > For the authors > > Daniel Karrenberg > > PS: Can we refer to this proposal by name and not by number? ;-) > 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 shane at time-travellers.org Tue Apr 7 21:09:56 2009 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 07 Apr 2009 21:09:56 +0200 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <20090326130519.868942F583@herring.ripe.net> References: <20090326130519.868942F583@herring.ripe.net> Message-ID: <49DBA504.30401@time-travellers.org> All, Filiz Yilmaz wrote: > PDP Number: 2008-05 > Anycasting Assignments for TLDs and Tier 0/1 ENUM This policy proposal makes sense to me. -- Shane From swmike at swm.pp.se Tue Apr 7 23:59:42 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 7 Apr 2009 23:59:42 +0200 (CEST) Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) In-Reply-To: <49DB5795.9080101@ukraine.su> References: <20090407104626.405C72F593@herring.ripe.net> <49DB3D43.7060200@man-da.de> <49DB4938.8090806@ukraine.su> <49DB5795.9080101@ukraine.su> Message-ID: On Tue, 7 Apr 2009, Max Tulyev wrote: > I hear from Juniper they was capable of 5M routes an year ago. Yes, 5M routes in RIB, not in FIB. State of the art platforms today do 1-2M FIB entries. > I think, 2020 year hardware should be capable about 500M prefixes easy. Why do you think so? If we increased ten times in the last ten years, why would we increase hundreds of times the next ten years? -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Wed Apr 8 01:56:49 2009 From: randy at psg.com (Randy Bush) Date: Wed, 08 Apr 2009 08:56:49 +0900 Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) In-Reply-To: <49DB3D43.7060200@man-da.de> References: <20090407104626.405C72F593@herring.ripe.net> <49DB3D43.7060200@man-da.de> Message-ID: > But to be serious for a minute: if all those /27 would be announced a > IPv4 full table would nearly triple in size this policy is analogous to one in apnic, except apnic's says "the then current minimum allocation." and we expect that, some day, it will be sub-/24. remember the goal, multi-homed sites using nat64 etc. so the size of the routing table will be propotional to multi-homing, a fact of life that this proposal will not significantly change. randy From randy at psg.com Wed Apr 8 01:57:37 2009 From: randy at psg.com (Randy Bush) Date: Wed, 08 Apr 2009 08:57:37 +0900 Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) In-Reply-To: <49DB5795.9080101@ukraine.su> References: <20090407104626.405C72F593@herring.ripe.net> <49DB3D43.7060200@man-da.de> <49DB4938.8090806@ukraine.su> <49DB5795.9080101@ukraine.su> Message-ID: > I hear from Juniper they was capable of 5M routes an year ago. as we say in my family, "do i smell cows?" randy From daniel.karrenberg at ripe.net Wed Apr 8 16:37:41 2009 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 8 Apr 2009 16:37:41 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: References: <20090406121040.GT56098@reiftel.karrenberg.net> Message-ID: <20090408143741.GA484@reiftel.karrenberg.net> On 07.04 11:11, Leo Vegoda wrote: > Hi, > > Can the authors please explain how this proposal would work with the current > policy, which sets the minimum allocation at /21? > > For instance, on 2 January 2011, how much address space should be allocated > to a network which needs a /21 for the next year? If the minimum allocation > needs to change along with the allocation and assignment periods then that > should probably be documented in the proposal. > > Thanks, > > Leo I do not think a change is necessary here to address the objective of the proposal. From daniel.karrenberg at ripe.net Wed Apr 8 16:40:22 2009 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 8 Apr 2009 16:40:22 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: References: <20090406121040.GT56098@reiftel.karrenberg.net> Message-ID: <20090408144022.GB484@reiftel.karrenberg.net> On 07.04 20:58, Remco van Mook wrote: > > Dear Daniel, dear all, > > First of all I support this proposal, and thank you for taking the time to > create it. I think the idea has great merit, but I?m also reminded of an > idea I sent out to the address policy mailing list and the feedback I got > based on that. For that thread, see: > http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00501. > html . Just to refresh your memory, I proposed a policy that would only > allocate a single block of space, regardless of the size of the request and > available remaining inventory. One of the main shortcomings of my idea was > that assignments from a new allocation don?t happen in a ?gradual? way, > which is one of the main assumptions behind any scheme based on > time-windows. Larger organizations will just come back quicker ? not > necessarily after the set window. I?m afraid this proposal has the same > ?weakness?. > > Kind regards, > > Remco That can be so, but still the requests will be chopped up so that others can get in the queue rather than being pre-empted by a huge request. Daniel From remco.vanmook at eu.equinix.com Thu Apr 9 12:55:29 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Thu, 09 Apr 2009 12:55:29 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <20090408144022.GB484@reiftel.karrenberg.net> Message-ID: Hi Daniel, That was the purpose of my idea as well ? this idea obviously is closer to currently set policy so the repercussions are likely to be better understood. It still leaves the option of ?cleaning out the cupboard? in one request, though. It just makes it harder to justify. (Which I?m fine with, by the way, any extra limitation is better than none at all) Best, Remco On 08-04-09 16:40, "Daniel Karrenberg" wrote: > On 07.04 20:58, Remco van Mook wrote: >> > >> > Dear Daniel, dear all, >> > >> > First of all I support this proposal, and thank you for taking the time to >> > create it. I think the idea has great merit, but I?m also reminded of an >> > idea I sent out to the address policy mailing list and the feedback I got >> > based on that. For that thread, see: >> > >> http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2008/msg00501. >> > html . Just to refresh your memory, I proposed a policy that would only >> > allocate a single block of space, regardless of the size of the request and >> > available remaining inventory. One of the main shortcomings of my idea was >> > that assignments from a new allocation don?t happen in a ?gradual? way, >> > which is one of the main assumptions behind any scheme based on >> > time-windows. Larger organizations will just come back quicker ? not >> > necessarily after the set window. I?m afraid this proposal has the same >> > ?weakness?. >> > >> > Kind regards, >> > >> > Remco > > That can be so, but still the requests will be chopped up so that others > can get in the queue rather than being pre-empted by a huge request. > > Daniel > 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 gert at space.net Thu Apr 9 17:15:40 2009 From: gert at space.net (Gert Doering) Date: Thu, 9 Apr 2009 17:15:40 +0200 Subject: [address-policy-wg] Agenda items for upcoming RIPE meeting? Message-ID: <20090409151540.GA68609@Space.Net> Hi APWG, the next RIPE meeting is getting close - so if you want to see something specific on the agenda for the APWG meeting in May, please let the WG chairs know. All the "usual" things will be on the agenda already, of course (discussion of open policy proposals, overview of ongoing work, etc.) - this is mainly for exceptional items. I will send a detailed draft agenda with all your input end of next week. 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 tomas.hlavacek at elfove.cz Fri Apr 10 01:00:51 2009 From: tomas.hlavacek at elfove.cz (Tomas Hlavacek) Date: Fri, 10 Apr 2009 01:00:51 +0200 Subject: [address-policy-wg] Re: 2008-05 New Policy Proposal (Anycasting Tier 0/1 ENUM) In-Reply-To: <20080904113736.523DC2F583@herring.ripe.net> References: <20080904113736.523DC2F583@herring.ripe.net> Message-ID: <49DE7E23.5030106@elfove.cz> Greetings! I support this proposal. I definitely want (g|cc)TLD operators to have an opportunity to increase resilience by setting up multiple anycasting clouds. And I think that the actual anycast address space spent for this will not even approach the "worst case" prediction - equivalent of slightly over /15 additional space. If I am wrong and it would get wide spread to fill up the /15, it is worth for that in my opinion. Best regards, Tomas Filiz Yilmaz wrote: > PDP Number: 2008-05 > Anycasting Tier 0/1 ENUM -- Tom?? Hlav??ek From tomas.hlavacek at elfove.cz Fri Apr 10 01:35:29 2009 From: tomas.hlavacek at elfove.cz (Tomas Hlavacek) Date: Fri, 10 Apr 2009 01:35:29 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <20090406121040.GT56098@reiftel.karrenberg.net> References: <20090406121040.GT56098@reiftel.karrenberg.net> Message-ID: <49DE8641.5010806@elfove.cz> Greetings! As I quickly read it I think it brings a fairness to the End. And it is good thing. But can you/somebody estimate what this would cost us in the matter of deaggregation and what it can cost NCC in the increase of request rate? I mean is it likely or at least possible, that when you shorten those periods from 1y to 1/2y and put in place the 50% usage in the half of the period criterion, then the increase of request rate (and therefore new routes in DFZ) will be not two-times but say ten-times more? In fact my concern is the same as in a section "Arguments Opposing the Proposal". My question is how much would we "pay" for the fairness? Best regards, Tomas Daniel Karrenberg wrote: > Dear colleagues, > > attached you will find a policy proposal we call "Run Out Fairly". > PS: Can we refer to this proposal by name and not by number? ;-) > -- Tom?? Hlav??ek From tomas.hlavacek at elfove.cz Fri Apr 10 03:00:10 2009 From: tomas.hlavacek at elfove.cz (Tomas Hlavacek) Date: Fri, 10 Apr 2009 03:00:10 +0200 Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) In-Reply-To: <20090407104626.405C72F593@herring.ripe.net> References: <20090407104626.405C72F593@herring.ripe.net> Message-ID: <49DE9A1A.3030503@elfove.cz> Greetings! First I do not like the /27 minimum allocation and assignment. I do not belive that people will adapt their filtering policies for this single /8. And I do not belive in RFC5211 at all. Here in the Czech Republic I know about some ISPs which just stopped all IPv6 deployment activites probably due to crisis-related budget cuts. So I do not like any policy which gives existing ISPs a chance to obtain some addresses from the last /8. In my opinion they have plenty of time to deploy IPv6 transition mechanisms and are able to obtain addresses for NAT(-PT|...) under current policies before the End. I would rather reserve the last /8 purely for newcomers and I would set some maximum allocation and assignment boundary in order to make sure that it will sustain for at least X newcomers which are expected to come in Y years. I do not try to argue that this is more "fair" than the 2009-04 and I do not want to punish existing ISPs. I just want to support more newcomers instead of handing out some portion of the last /8 to companies which have (in case of LIRs) at least /21 and are likely able to pick addresses for IPv6 transition mechanisms from their old allocations. Best regards, Tomas Filiz Yilmaz wrote: > PDP Number: 2009-04 > IPv4 Allocation and Assignments to Facilitate IPv6 Deployment > -- Tom?? Hlav??ek From alain.bidron at orange-ftgroup.com Fri Apr 10 10:56:31 2009 From: alain.bidron at orange-ftgroup.com (alain.bidron at orange-ftgroup.com) Date: Fri, 10 Apr 2009 10:56:31 +0200 Subject: [address-policy-wg] 2009-04 New Policy Proposal (IPv4 Allocationand Assignments to Facilitate IPv6 Deployment) Message-ID: Thank you for the first comments received on 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment). Please find hereafter some response. >From Marcus Stoegbauer: >> For a start: I can't really tell if the new policy text should replace >> the old IPv4 address allocation and assignment policy. The new policy >> only talks about address space given out to ISPs for transition >> techniques, so I assume that an ISP with a lot of free (i.e. not >>assigned/unused) IPv4 address space can also get another allocation >>under this policy? Response This policy is done in accordance with existing v4 policies and basic principle is that allocation/assignment should be based on needs. The difference with that policy is the minimum allocation/assignment size is different and filtering policies, should be different in this range. So when requesting additional IPv4 resources (after the IPv4 pool is depleted - from the transition /8) an ISP should still demonstrate the required utilisation of already allocated addresses. If an ISP has already sufficient resources allocated for implementing transition techniques it should not be qualified to receive additional resources from that policy, except if the use of these resources implies fragmentation and filtering issues. This is to be evaluated by the RIPE-NCC when analysing the request. >From Marcus Stoegbauer: > >Then the minimum size of /27. Obviously it would be a brilliant test >> to see if routers will be able to hold all the IPv6 PI prefixes that >> will come to life once we allow them to be handed out. And it would be > >a very handy way to tear down the v4 internet, so it's in full >> compliance with some IPv6 implementation plans. >> But to be serious for a minute: if all those /27 would be announced a > >IPv4 full table would nearly triple in size (or in other words: all > >those /27 are twice the size of a full IPv4 table today). This can't >> possibly end well, so I'm not in favor for this proposal in its >> current form. Response I don't think this policy will really change the size of routing table. If the policy is based on a /24 it would only waste v4 resources, and reduce on medium long term the possibility to provide those necessary resources. The growth of the routing table will be proportional to the growth of the number of new ISPs - PA holders and the use of multi-homing, exactly as today, this proposal will not change this significantly. Please note that a /27 under this proposal will actually represent a today's /21 ( or even shorter prefix). >From Sebastian Wiesinger [ripe+apwg at karotte.org] >> First: It won't work. Most people I know filter prefixes smaller than >> /24 in the DFZ. They will not see these allocations. You can't assume >> that they will change their filters for this. I would estimate that >> most of them won't. Many can't do this because it will not fit in >> their RIB/FIB. So if you do this you would have to give out a /24 at least. Response: It won't work in the current situation but will have to work in the new depleted context. Rather than splitting the existing v4 resources in small pieces, the proposal suggests to dedicate a specific /8 where filtering policies could be adapted. >From Sebastian Wiesinger [ripe+apwg at karotte.org] >> Second: We do want to facilitate deployment of IPv6. I think this >> proposal could be counterproductive. You're splitting up the remaining >> space in smaller peaces so that more people can use IPv4 for a longer >> timespan. And if you have to give out /24s you can bet that people >> will use it for other things besides NAT-PT etc. Response: No we don't want to prolong v4 lifetime, only to allow for v6 providers to interact with the existing v4 environment that will not disappear overnight. This proposal will not in my views prolong v4. Whether we want this or not, the demand for IPv4 address space after the IPv4 pool is depleted will continue. It will be proportional to the amount of existing IPv4-only resources and the number of newly connected customers, regardless whether they are IPv4 or IPv6-only, or dual-stack. This proposal attempts to satisfy this demand on continuous and predictable basis for the transition period without changing the fundamental principles of resource allocation. >From Sebastian Wiesinger [ripe+apwg at karotte.org] > Third: Is it necessary? You already have to demonstrate a need for > address space if you want a new allocation. If an LIR already has an > allocation I assume that they can spare an /27 for IPv6 transition. >> If you have a new LIR you allocate them a /21 if they can demonstrate > the need for it, no change there. Response: I say YES it is necessary because remember we are in a depleted context. It means that the RIPE-NCC will not be in a position to allocate IPv4 addresses under today policies. Are you totally sure that all existing holders of IPv4 resources will be able to spare /27 for IPv6 transition? And regarding new entrants where those /21 will come from? I think we cannot deny that exhaustion is becoming a reality. >From Andy Davidson >> If it's good to restrict the allocation and assignment of v4 resources >> to organisations who have a stated v6 deployment policy, then why do >> we need to wait until the final /8 has been allocated to the NCC >> before we begin such a policy ? Perhaps we should have a phased >> process that asks organisations how they are deploying v6 on the PA >> and PI request forms, and then future requests from that organisation, >> or related organisations are refused if the deployment has not started. Good point Andy, I am not opposed to think about something that could be inserted in the "run out fairly proposal" opening the way to something stricter on the last /8 policy >From Andy Davidson >>Why was /27 selected rather than /26 or /25 ? Since most deployments >>have multiple, separate infrastructure assignments, and services/user >> assignments, it seems that a /27 as a minimum allocation is far to >> small to promote any degree of aggregation whatsoever. This policy is >> therefore counter to one of RIPE's regularly stated aims - to promote >> route aggregation. The counter argument to this is that I might as > >well accept that we the side of common sense has lost the v4 > >aggregation debate, and v4 after-market sales will drive deagg > >further, so why should we care ? Response: Remember that we need a mechanism that allows to provide the small amount of IPv4 addresses needed to interact with the IPv4 environment for a long time (before Ipv4 addresses being completely obsolete).A similar approved policy in ARIN is based on a /28! A downscaling factor of 64 is in my view a good compromise. >From Andy Davidson >> On the other hand, perhaps this policy will be seen as an ipv4 life >> extension policy. We do not want to muddy the message that we send to >> the community. V4's free pool will soon be gone. Do not gamble your >> company on policies designed to extend the availability of a very >> scarce resource. >> Maybe we can pool some of the ideas in 2009-03 and -04, and the >> community response, and build a solid run down policy that encourages >>v6 adoption, but doesn't pretend to be able to extend the life of v4. Response: The intention of the proposal is certainly not to extent the IPv4 life. On the contrary we try to put some incentive for a move to v6 facilitating to those who go that way a fair access to the limited v4 resources strictly needed to interact with the existing v4 environment. We must be realistic even if we all call for a move to v6 Ipv4 will not disappear overnight and transition to IPv6 requires continuous supply of IPv4. Without this we will face an double or triple NAT and walled garden alternatives which will change the architecture and principles of the Internet significantly and will never get us to IPv6. Regards Alain ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingrid at ripe.net Tue Apr 14 14:57:40 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Tue, 14 Apr 2009 14:57:40 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) Message-ID: <20090414125740.9D52C2F583@herring.ripe.net> PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-05.html We encourage you to review this proposal and send your comments to before 12 May 2009. Regards Ingrid Wijte Assistant Policy Development Officer RIPE NCC From marcoh at marcoh.net Tue Apr 14 15:53:46 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 14 Apr 2009 15:53:46 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090414125740.9D52C2F583@herring.ripe.net> References: <20090414125740.9D52C2F583@herring.ripe.net> Message-ID: <21D35AFE-F0F0-4224-A36C-375927E48232@marcoh.net> On 14 apr 2009, at 14:57, Ingrid Wijte wrote: > PDP Number: 2009-05 > Multiple IPv6 /32 Allocations for LIRs > > Dear Colleagues > > A new RIPE Policy Proposal has been made and is now available for > discussion. Personally I don't like the following phrase: 'In case the routing policies would no longer be unique and/or the networks have effectively merged, the additional /32 allocations must be returned to the RIPE NCC' IMHO this should be extended to at least give a decent timeframe to renumber and possibly should differentiate between LIR's which have requested additional blocks for routing and/or administrative purposes and those who ended up with multiple allocations because they merged with some other LIR. And as an open question, what would happen if I would merge 2 autonomous systems in 1 LIR (If I understand correctly this is after all what is being proposed) both are operating a /32 which is over 50% usage ? a) grow one of the 2 allocations to /31 and renumber the other b) keep the 2 /32's on expense of 1 extra route in the DFZ but save yourself the renumbering task and secondly doesn't this open up the path to /32 per AS instead to / 32 per LIR ? Groet, MarcoH From Remco.vanMook at eu.equinix.com Tue Apr 14 17:00:36 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Tue, 14 Apr 2009 17:00:36 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) References: <20090414125740.9D52C2F583@herring.ripe.net> Message-ID: <2E61C47A190CA44ABFCF23147E57E4BCE6393B@NLEN1EX1.eu.win.equinix.com> Dear all, While I sympathise with the idea, I don't support the proposal as-is today. As I read it, it allows a LIR to avoid any requirements for fillrates of address space as long as they've got an extra AS, essentially making the number of ASes a metric for the amount of address space one can get without questions. This puts a lot of extra weight on the decision of assigning an extra AS to a LIR and that should be a fully separate discussion. If we can somehow fix this unintended interdependency I'll gladly review my opinion. Kind regards, Remco van Mook -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Ingrid Wijte Sent: dinsdag 14 april 2009 14:58 To: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-05.html We encourage you to review this proposal and send your comments to before 12 May 2009. Regards Ingrid Wijte Assistant Policy Development Officer RIPE NCC 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 vfrank at csc.com Tue Apr 14 17:12:40 2009 From: vfrank at csc.com (Volker Frank) Date: Tue, 14 Apr 2009 16:12:40 +0100 Subject: [address-policy-wg] Volker Frank/PLZ/CSC is out of the office. Message-ID: I will be out of the office starting 08.04.2009 and will not return until 20.04.2009. From drueegg at emea.att.com Tue Apr 14 17:22:36 2009 From: drueegg at emea.att.com (Rueegg, Daniel) Date: Tue, 14 Apr 2009 17:22:36 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <2E61C47A190CA44ABFCF23147E57E4BCE6393B@NLEN1EX1.eu.win.equinix.com> References: <20090414125740.9D52C2F583@herring.ripe.net> <2E61C47A190CA44ABFCF23147E57E4BCE6393B@NLEN1EX1.eu.win.equinix.com> Message-ID: Hi Remco, I'm not sure where you see that a second AS would allow a LIR to get a second /32. I'm happy to reword the Policy Text but I think it already specifies the rule: "...separate AS number and a unique routing policy..." The unique routing policy implies that the two AS will have different peering relations so are operated as two different networks. I'm happy to add a sentence about peering too it that makes it clear. I agree to the comment Marco wrote. It would make sense to specify a time-line by when a low used /32 has to be returned after AS have merged together. Dani -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Remco van Mook Sent: Tuesday, April 14, 2009 5:01 PM To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) Dear all, While I sympathise with the idea, I don't support the proposal as-is today. As I read it, it allows a LIR to avoid any requirements for fillrates of address space as long as they've got an extra AS, essentially making the number of ASes a metric for the amount of address space one can get without questions. This puts a lot of extra weight on the decision of assigning an extra AS to a LIR and that should be a fully separate discussion. If we can somehow fix this unintended interdependency I'll gladly review my opinion. Kind regards, Remco van Mook -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Ingrid Wijte Sent: dinsdag 14 april 2009 14:58 To: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-05.html We encourage you to review this proposal and send your comments to before 12 May 2009. Regards Ingrid Wijte Assistant Policy Development Officer RIPE NCC 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 Remco.vanMook at eu.equinix.com Tue Apr 14 17:36:09 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Tue, 14 Apr 2009 17:36:09 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) References: <20090414125740.9D52C2F583@herring.ripe.net> <2E61C47A190CA44ABFCF23147E57E4BCE6393B@NLEN1EX1.eu.win.equinix.com> Message-ID: <2E61C47A190CA44ABFCF23147E57E4BCE6393C@NLEN1EX1.eu.win.equinix.com> Hi Daniel, The 'unique routing policy' is already a requirement to get a second (or any subsequent) AS as far as I know, so it doesn't really add any limitation. Best, Remco -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Rueegg, Daniel Sent: dinsdag 14 april 2009 17:23 To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) Hi Remco, I'm not sure where you see that a second AS would allow a LIR to get a second /32. I'm happy to reword the Policy Text but I think it already specifies the rule: "...separate AS number and a unique routing policy..." The unique routing policy implies that the two AS will have different peering relations so are operated as two different networks. I'm happy to add a sentence about peering too it that makes it clear. I agree to the comment Marco wrote. It would make sense to specify a time-line by when a low used /32 has to be returned after AS have merged together. Dani -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Remco van Mook Sent: Tuesday, April 14, 2009 5:01 PM To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) Dear all, While I sympathise with the idea, I don't support the proposal as-is today. As I read it, it allows a LIR to avoid any requirements for fillrates of address space as long as they've got an extra AS, essentially making the number of ASes a metric for the amount of address space one can get without questions. This puts a lot of extra weight on the decision of assigning an extra AS to a LIR and that should be a fully separate discussion. If we can somehow fix this unintended interdependency I'll gladly review my opinion. Kind regards, Remco van Mook -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Ingrid Wijte Sent: dinsdag 14 april 2009 14:58 To: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-05.html We encourage you to review this proposal and send your comments to before 12 May 2009. Regards Ingrid Wijte Assistant Policy Development Officer RIPE NCC 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 gajda at man.poznan.pl Wed Apr 15 10:08:52 2009 From: gajda at man.poznan.pl (Bartek Gajda) Date: Wed, 15 Apr 2009 10:08:52 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <21D35AFE-F0F0-4224-A36C-375927E48232@marcoh.net> References: <20090414125740.9D52C2F583@herring.ripe.net> <21D35AFE-F0F0-4224-A36C-375927E48232@marcoh.net> Message-ID: <49E59614.7080403@man.poznan.pl> Marco Hogewoning wrote: > > On 14 apr 2009, at 14:57, Ingrid Wijte wrote: > >> PDP Number: 2009-05 >> Multiple IPv6 /32 Allocations for LIRs >> >> Dear Colleagues >> >> A new RIPE Policy Proposal has been made and is now available for >> discussion. > Summary of Proposal: > This is a proposal to allow an LIR operating separate networks in > unconnected geographical areas to receive multiple /32 IPv6 allocations. This policy is a must-have policy for hundreds of thousand users in my county and more than 20 LIRs. However there is a strong limitation for me in this policy, because we are using at least two different policies but within ONE single geographical areas. The differences in routing policies are not because of different geographical areas but because of different kind of customers we are serving. Currently we have to divide single /32 into multiple pieces and announce them under different ASs we have, which weak but the only possible solution. We do not have any chance to get a second /32 from RIPE so far. It would be really helpful to reflect this real life situation in single policy like this one. So after removing the part about "different unconnected geographical areas" this policy will get strong support from LIRs I'm writing about. Best regards, Bartek Gajda From remco.vanmook at eu.equinix.com Wed Apr 15 10:35:01 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Wed, 15 Apr 2009 10:35:01 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <49E59614.7080403@man.poznan.pl> Message-ID: Hang on a second. This is now devolving into a proposal where you can get a separate AS and /32 for every customer your LIR serves and I will definitely not support that. I want a pony, too. Remco On 15-04-09 10:08, "Bartek Gajda" wrote: > Marco Hogewoning wrote: >> > >> > On 14 apr 2009, at 14:57, Ingrid Wijte wrote: >> > >>> >> PDP Number: 2009-05 >>> >> Multiple IPv6 /32 Allocations for LIRs >>> >> >>> >> Dear Colleagues >>> >> >>> >> A new RIPE Policy Proposal has been made and is now available for >>> >> discussion. >> > Summary of Proposal: >> > This is a proposal to allow an LIR operating separate networks in >> > unconnected geographical areas to receive multiple /32 IPv6 allocations. > > This policy is a must-have policy for hundreds of thousand users in my > county and more than 20 LIRs. However there is a strong limitation for > me in this policy, because we are using at least two different policies > but within ONE single geographical areas. The differences in routing > policies are not because of different geographical areas but because of > different kind of customers we are serving. > Currently we have to divide single /32 into multiple pieces and announce > them under different ASs we have, which weak but the only possible > solution. We do not have any chance to get a second /32 from RIPE so far. > > It would be really helpful to reflect this real life situation in single > policy like this one. So after removing the part about "different > unconnected geographical areas" this policy will get strong support from > LIRs I'm writing about. > > Best regards, > Bartek Gajda > > 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 Piotr.Strzyzewski at polsl.pl Wed Apr 15 10:46:16 2009 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 15 Apr 2009 10:46:16 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: References: <49E59614.7080403@man.poznan.pl> Message-ID: <20090415084616.GC22775@hydra.ck.polsl.pl> On Wed, Apr 15, 2009 at 10:35:01AM +0200, Remco van Mook wrote: > > Hang on a second. This is now devolving into a proposal where you can get a > separate AS and /32 for every customer your LIR serves and I will definitely > not support that. I want a pony, too. Correct me if I'm wrong, but allocation's goes to LIRs and not to customers. Moreover, AS'es are owned by clearly distinguished "entities". We could add those two things together and make that like: /32 for every AS owned by LIR (in simplification). Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From gajda at man.poznan.pl Wed Apr 15 10:50:26 2009 From: gajda at man.poznan.pl (Bartek Gajda) Date: Wed, 15 Apr 2009 10:50:26 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: References: Message-ID: <49E59FD2.4090708@man.poznan.pl> Remco van Mook wrote: > > Hang on a second. This is now devolving into a proposal where you can > get a separate AS and /32 for every customer your LIR serves and I > will definitely not support that. I want a pony, too. > > Remco But I do not need any new AS.The current policy for getting AS number is fine for me! I only need to announce a "production quality" IPv6 allocation which is /32 within each AS I have. And I am in ONE geographical location. Can this policy take care of me (and not only me)? So I only recommend to remove this statement about "unconnected geographical areas" because this reflect only some too narrow LIRs' situation. Best regards, Bartek > > On 15-04-09 10:08, "Bartek Gajda" wrote: > > Marco Hogewoning wrote: > > > > On 14 apr 2009, at 14:57, Ingrid Wijte wrote: > > > >> PDP Number: 2009-05 > >> Multiple IPv6 /32 Allocations for LIRs > >> > >> Dear Colleagues > >> > >> A new RIPE Policy Proposal has been made and is now available for > >> discussion. > > Summary of Proposal: > > This is a proposal to allow an LIR operating separate networks in > > unconnected geographical areas to receive multiple /32 IPv6 > allocations. > > This policy is a must-have policy for hundreds of thousand users in my > county and more than 20 LIRs. However there is a strong limitation for > me in this policy, because we are using at least two different > policies > but within ONE single geographical areas. The differences in routing > policies are not because of different geographical areas but > because of > different kind of customers we are serving. > Currently we have to divide single /32 into multiple pieces and > announce > them under different ASs we have, which weak but the only possible > solution. We do not have any chance to get a second /32 from RIPE > so far. > > It would be really helpful to reflect this real life situation in > single > policy like this one. So after removing the part about "different > unconnected geographical areas" this policy will get strong > support from > LIRs I'm writing about. > > Best regards, > Bartek Gajda > > > > > 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 Piotr.Strzyzewski at polsl.pl Wed Apr 15 10:54:51 2009 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 15 Apr 2009 10:54:51 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090414125740.9D52C2F583@herring.ripe.net> References: <20090414125740.9D52C2F583@herring.ripe.net> Message-ID: <20090415085451.GD22775@hydra.ck.polsl.pl> Hi There has been similar informal proposal issued by me and my collegues during RIPE-54. The proposal and presentation could be seen here: http://www.ripe.net/ripe/meetings/ripe-54/presentations/IPv6_Subsequent_Allocation.pdf Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From remco.vanmook at eu.equinix.com Wed Apr 15 10:54:38 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Wed, 15 Apr 2009 10:54:38 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090415084616.GC22775@hydra.ck.polsl.pl> Message-ID: I'm sorry but that goes back to my previous e-mail - a request for an AS is a request for an AS and I don't see how that should be related in any way to address space. What this achieves is the same level of fragmentation of the IPv6 space, but then in /32 blocks instead of /33, /34 and /35s. I don't see what the wider community gains here. If you need more space, request a larger block. If your issue is that some people filter smaller than /32 announcements then try to solve that. It's not like the global IPv6 routing table is going to explode any time soon. Personally I think IPv6 is going to be a runaway success by the time the DFZ hits 10,000 routes - filtering more specifics I can see the reason for, filtering smaller announcements I can not. Remco On 15-04-09 10:46, "Piotr Strzyzewski" wrote: > On Wed, Apr 15, 2009 at 10:35:01AM +0200, Remco van Mook wrote: >> > >> > Hang on a second. This is now devolving into a proposal where you can get a >> > separate AS and /32 for every customer your LIR serves and I will >> definitely >> > not support that. I want a pony, too. > > Correct me if I'm wrong, but allocation's goes to LIRs and not to > customers. Moreover, AS'es are owned by clearly distinguished "entities". > We could add those two things together and make that like: /32 for every > AS owned by LIR (in simplification). > > Piotr > > -- > gucio -> Piotr Strzy?ewski > E-mail: Piotr.Strzyzewski at polsl.pl > 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 gajda at man.poznan.pl Wed Apr 15 11:06:57 2009 From: gajda at man.poznan.pl (Bartek Gajda) Date: Wed, 15 Apr 2009 11:06:57 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: References: Message-ID: <49E5A3B1.6090207@man.poznan.pl> Remco van Mook wrote: > > I?m sorry but that goes back to my previous e-mail ? a request for an > AS is a request for an AS and I don?t see how that should be related > in any way to address space. What this achieves is the same level of > fragmentation of the IPv6 space, but then in /32 blocks instead of > /33, /34 and /35s. I don?t see what the wider community gains here. If > you need more space, request a larger block. If your issue is that > some people filter smaller than /32 announcements then try to solve that. So what about is the current policy? You want to give some LIRs additional /32 because: "According to the IPv6 policy an IPv6 allocation must be announced as one prefix. Therefore, an organization operating four separate networks with one /32 IPv6 allocation cannot de-aggregate into for example a /34 route announcement per network." And here you are suggesting me to de-agradate my allocation which this proposal trying to avoid! Doesn't it looks like one can get what he or she wants but the other "can de-agraaate"?? Bartek > It?s not like the global IPv6 routing table is going to explode any > time soon. > > Personally I think IPv6 is going to be a runaway success by the time > the DFZ hits 10,000 routes ? filtering more specifics I can see the > reason for, filtering smaller announcements I can not. > > Remco > > > On 15-04-09 10:46, "Piotr Strzyzewski" wrote: > > On Wed, Apr 15, 2009 at 10:35:01AM +0200, Remco van Mook wrote: > > > > Hang on a second. This is now devolving into a proposal where you > can get a > > separate AS and /32 for every customer your LIR serves and I will > definitely > > not support that. I want a pony, too. > > Correct me if I'm wrong, but allocation's goes to LIRs and not to > customers. Moreover, AS'es are owned by clearly distinguished > "entities". > We could add those two things together and make that like: /32 for > every > AS owned by LIR (in simplification). > > Piotr > > -- > gucio -> Piotr Strzy?ewski > E-mail: Piotr.Strzyzewski at polsl.pl > > > > 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 remco.vanmook at eu.equinix.com Wed Apr 15 11:11:20 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Wed, 15 Apr 2009 11:11:20 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <49E5A3B1.6090207@man.poznan.pl> Message-ID: ..or you can file a proposal to change the current policy. You're very obviously trying to solve a problem and I don't disagree that the problem exists; I just don't like the proposed solution. Remco On 15-04-09 11:06, "Bartek Gajda" wrote: > Remco van Mook wrote: >> > >> > I'm sorry but that goes back to my previous e-mail - a request for an >> > AS is a request for an AS and I don't see how that should be related >> > in any way to address space. What this achieves is the same level of >> > fragmentation of the IPv6 space, but then in /32 blocks instead of >> > /33, /34 and /35s. I don't see what the wider community gains here. If >> > you need more space, request a larger block. If your issue is that >> > some people filter smaller than /32 announcements then try to solve that. > So what about is the current policy? > You want to give some LIRs additional /32 because: > "According to the IPv6 policy an IPv6 allocation must be announced as > one prefix. Therefore, an organization operating four separate networks > with one /32 IPv6 allocation cannot de-aggregate into for example a /34 > route announcement per network." > And here you are suggesting me to de-agradate my allocation which this > proposal trying to avoid! Doesn't it looks like one can get what he or > she wants but the other "can de-agraaate"?? > > Bartek > >> > It's not like the global IPv6 routing table is going to explode any >> > time soon. >> > >> > Personally I think IPv6 is going to be a runaway success by the time >> > the DFZ hits 10,000 routes - filtering more specifics I can see the >> > reason for, filtering smaller announcements I can not. >> > >> > Remco >> > >> > >> > On 15-04-09 10:46, "Piotr Strzyzewski" wrote: >> > >> > On Wed, Apr 15, 2009 at 10:35:01AM +0200, Remco van Mook wrote: >>> > > >>> > > Hang on a second. This is now devolving into a proposal where you >> > can get a >>> > > separate AS and /32 for every customer your LIR serves and I will >> > definitely >>> > > not support that. I want a pony, too. >> > >> > Correct me if I'm wrong, but allocation's goes to LIRs and not to >> > customers. Moreover, AS'es are owned by clearly distinguished >> > "entities". >> > We could add those two things together and make that like: /32 for >> > every >> > AS owned by LIR (in simplification). >> > >> > Piotr >> > >> > -- >> > gucio -> Piotr Strzy?ewski >> > E-mail: Piotr.Strzyzewski at polsl.pl >> > >> > >> > >> > 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 Piotr.Strzyzewski at polsl.pl Wed Apr 15 11:12:13 2009 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 15 Apr 2009 11:12:13 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: References: <20090415084616.GC22775@hydra.ck.polsl.pl> Message-ID: <20090415091213.GE22775@hydra.ck.polsl.pl> On Wed, Apr 15, 2009 at 10:54:38AM +0200, Remco van Mook wrote: > I'm sorry but that goes back to my previous e-mail - a request for an AS is > a request for an AS and I don't see how that should be related in any way to So, as I understand, are you going to say, that RIPE NCC is assigning more than one/few ASNs to the same unique LIR just "for free"? If not (I hope so ;-) ), why we couldn't base new policy (IPv6 allocations) on other solid policy and practice (ASN assignments)? It's like in math - you must (or at least should ;-) ) base one thing on another. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From fweimer at bfk.de Wed Apr 15 11:16:13 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 15 Apr 2009 11:16:13 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090415084616.GC22775@hydra.ck.polsl.pl> (Piotr Strzyzewski's message of "Wed, 15 Apr 2009 10:46:16 +0200") References: <49E59614.7080403@man.poznan.pl> <20090415084616.GC22775@hydra.ck.polsl.pl> Message-ID: <821vrujmzm.fsf@mid.bfk.de> * Piotr Strzyzewski: > We could add those two things together and make that like: /32 for every > AS owned by LIR (in simplification). This is more IETF material, IMHO. There could be a magic /5 which contains a /32 for every 27-bit AS number, and a magic /16 with a /48 for every 32 bit AS number. RIRs are only needed to handle the reverse delegation. In any case, to me it looks like multiple requests for /32s are needed only to work around route filters. If this is really the case, those filters have to go. -- 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 Piotr.Strzyzewski at polsl.pl Wed Apr 15 10:41:28 2009 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 15 Apr 2009 10:41:28 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <21D35AFE-F0F0-4224-A36C-375927E48232@marcoh.net> References: <20090414125740.9D52C2F583@herring.ripe.net> <21D35AFE-F0F0-4224-A36C-375927E48232@marcoh.net> Message-ID: <20090415084127.GB22775@hydra.ck.polsl.pl> On Tue, Apr 14, 2009 at 03:53:46PM +0200, Marco Hogewoning wrote: > and secondly doesn't this open up the path to /32 per AS instead to / > 32 per LIR ? And is there anything wrong with that? I clearly understand the conservation goal, but to be honest - is there any problem with (for example) 1k more /32s which could be allocated under that policy? I sometimes personally wonder if we are going to promote ipv6 or not by using too strict policies. And yes - i know the history of ipv4. ;-) Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From remco.vanmook at eu.equinix.com Wed Apr 15 11:31:48 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Wed, 15 Apr 2009 11:31:48 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <821vrujmzm.fsf@mid.bfk.de> Message-ID: Either that or a global policy proposal to use a /4 to automatically allocate a /32 to every 28-bit AS (maximizing the potential here :) - that should keep everybody happy and remove the need for the RIRs to be involved with all but the largest IPv6 requirements. Future generations might ask why we wasted all this space linking it to AS-numbers but at least it will then be in a block that can be easily filtered. Not that I?d support that proposal, either. We?ve already wasted quite enough bits of IPv6 space in policy, IMHO. Remco On 15-04-09 11:16, "Florian Weimer" wrote: > * Piotr Strzyzewski: > >> > We could add those two things together and make that like: /32 for every >> > AS owned by LIR (in simplification). > > This is more IETF material, IMHO. There could be a magic /5 which > contains a /32 for every 27-bit AS number, and a magic /16 with a /48 > for every 32 bit AS number. RIRs are only needed to handle the > reverse delegation. > > In any case, to me it looks like multiple requests for /32s are needed > only to work around route filters. If this is really the case, those > filters have to go. > > -- > 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 > 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 Piotr.Strzyzewski at polsl.pl Wed Apr 15 11:32:45 2009 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 15 Apr 2009 11:32:45 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <821vrujmzm.fsf@mid.bfk.de> References: <49E59614.7080403@man.poznan.pl> <20090415084616.GC22775@hydra.ck.polsl.pl> <821vrujmzm.fsf@mid.bfk.de> Message-ID: <20090415093245.GF22775@hydra.ck.polsl.pl> On Wed, Apr 15, 2009 at 11:16:13AM +0200, Florian Weimer wrote: > In any case, to me it looks like multiple requests for /32s are needed > only to work around route filters. If this is really the case, those > filters have to go. >From the proposal: "According to the IPv6 policy an IPv6 allocation must be announced as one prefix." There is more than one (filters) problem. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From Jerzy.Pawlus at cyf-kr.edu.pl Wed Apr 15 11:25:06 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Wed, 15 Apr 2009 11:25:06 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090414125740.9D52C2F583@herring.ripe.net> (message from Ingrid Wijte on Tue, 14 Apr 2009 14:57:40 +0200) References: <20090414125740.9D52C2F583@herring.ripe.net> Message-ID: <200904150925.n3F9P6IC007074@nc.cyf-kr.edu.pl> On 14 apr 2009, at 14:57, Ingrid Wijte wrote: > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2009-05.html > There is a need of changing ripe-450. There are some LIR's which have more than one routing policy. This was possible with IPv4 and is impossible with IPv6. We are all worried about a slow deployment of IPv6 but we ourselves are slowing it down. Look, where IPv4 started. In IPv6 we want to be perfect from the beginning. It is O.K but there is a "real life" too. I will support this proposal if the reference to "different unconnected geographical areas" is removed. It is a bit unclear, and what area we have in mind? My original thought of new version of ripe-450 was: New version: --------------------- 5.2.1. Subsequent allocation criteria a) Subsequent allocation will be provided when an organisation (i.e. ISP/LIR) satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments. The HD-Ratio [RFC 3194] is used to determine the utilisation thresholds that justify the allocation of additional address as described below. b) An LIR may request an additional minimum allocation size for a second and subsequent Autonomus System assigned to that LIR. -------------------------- Regards, Jurek P.S. Allow our children to fix something. From marcoh at marcoh.net Wed Apr 15 11:34:47 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 15 Apr 2009 11:34:47 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: References: Message-ID: On 15 apr 2009, at 11:11, Remco van Mook wrote: > > ..or you can file a proposal to change the current policy. You?re > very obviously trying to solve a problem and I don?t disagree that > the problem exists; I just don?t like the proposed solution. All, Let's assume you have a seperate entity in your company, which operates in a different geographical region under it's own AS and routing policy. Only one company (the holding for instance) is an LIR in the current situation. How do you solve this at the moment iin IPv4-land ? How many of you actually use RIPE-449 section 5.4 and won't PI solve your problem ? I'm happy with a proposal to include similair wording as seciotn 5.4 into RIPE-450 as long as it comes with a big disclaimer saying it's at your own risk and routing as always isn't guaranteed (point to 450, 4.2). At the same time we can set boundaries onto it to ease up filttering, like in the v4 case. As it stands I won't support the proposal as-is, it's far to specific and it harms fairness as the only requirement is an AS number and no references are made to HD-ratio or the regular subsequent allocation policy. Groet, MarcoH From Jerzy.Pawlus at cyf-kr.edu.pl Wed Apr 15 11:37:25 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Wed, 15 Apr 2009 11:37:25 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <821vrujmzm.fsf@mid.bfk.de> (message from Florian Weimer on Wed, 15 Apr 2009 11:16:13 +0200) References: <49E59614.7080403@man.poznan.pl> <20090415084616.GC22775@hydra.ck.polsl.pl> <821vrujmzm.fsf@mid.bfk.de> Message-ID: <200904150937.n3F9bPsV010847@nc.cyf-kr.edu.pl> * Florian Weimer > > In any case, to me it looks like multiple requests for /32s are needed > only to work around route filters. If this is really the case, those > filters have to go. > But you can't build your long term business plan on that assumpion There will be be some who would filter it. Jurek From marcoh at marcoh.net Wed Apr 15 11:41:15 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 15 Apr 2009 11:41:15 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904150925.n3F9P6IC007074@nc.cyf-kr.edu.pl> References: <20090414125740.9D52C2F583@herring.ripe.net> <200904150925.n3F9P6IC007074@nc.cyf-kr.edu.pl> Message-ID: On 15 apr 2009, at 11:25, Jerzy Pawlus wrote: > New version: > > --------------------- > 5.2.1. Subsequent allocation criteria > > a) Subsequent allocation will be provided when an organisation (i.e. > ISP/LIR) > satisfies the evaluation threshold of past address utilisation in > terms of > the number of sites in units of /56 assignments. The HD-Ratio [RFC > 3194] > is used to determine the utilisation thresholds that justify > the allocation of additional address as described below. > > b) An LIR may request an additional minimum allocation size for a > second and > subsequent Autonomus System assigned to that LIR. > > -------------------------- And there are basically no limitittations on getting a seperate AS number to work around a), so you might as well drop 5.2.1 completely. Groet, MarcoH From fweimer at bfk.de Wed Apr 15 11:43:07 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 15 Apr 2009 11:43:07 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: (Remco van Mook's message of "Wed, 15 Apr 2009 11:31:48 +0200") References: Message-ID: <82r5zui76c.fsf@mid.bfk.de> * Remco van Mook: > Either that or a global policy proposal to use a /4 to automatically > allocate a /32 to every 28-bit AS (maximizing the potential here :) - that > should keep everybody happy and remove the need for the RIRs to be involved > with all but the largest IPv6 requirements. Note that the RIRs still need to handle reverse delegations (more so with DNSSEC; without DNSSEC, you can use magic addresses). -- 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 remco.vanmook at eu.equinix.com Wed Apr 15 11:43:46 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Wed, 15 Apr 2009 11:43:46 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904150937.n3F9bPsV010847@nc.cyf-kr.edu.pl> Message-ID: People can also filter all ASNs ending with the digit 4. There?s no policy against it. Doesn?t make it less stupid, though. Remco On 15-04-09 11:37, "Jerzy Pawlus" wrote: > > > * Florian Weimer > >> > >> > In any case, to me it looks like multiple requests for /32s are needed >> > only to work around route filters. If this is really the case, those >> > filters have to go. >> > > But you can't build your long term business plan on that assumpion > There will be be some who would filter it. > > Jurek > > 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 fweimer at bfk.de Wed Apr 15 11:47:45 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 15 Apr 2009 11:47:45 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904150937.n3F9bPsV010847@nc.cyf-kr.edu.pl> (Jerzy Pawlus's message of "Wed, 15 Apr 2009 11:37:25 +0200 (METDST)") References: <49E59614.7080403@man.poznan.pl> <20090415084616.GC22775@hydra.ck.polsl.pl> <821vrujmzm.fsf@mid.bfk.de> <200904150937.n3F9bPsV010847@nc.cyf-kr.edu.pl> Message-ID: <82myaii6ym.fsf@mid.bfk.de> * Jerzy Pawlus: >> In any case, to me it looks like multiple requests for /32s are needed >> only to work around route filters. If this is really the case, those >> filters have to go. >> > But you can't build your long term business plan on that assumpion > There will be be some who would filter it. There's no long-term guarantee of routability for /32s, either. -- 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 Piotr.Strzyzewski at polsl.pl Wed Apr 15 11:47:55 2009 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 15 Apr 2009 11:47:55 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: References: <200904150937.n3F9bPsV010847@nc.cyf-kr.edu.pl> Message-ID: <20090415094755.GG22775@hydra.ck.polsl.pl> On Wed, Apr 15, 2009 at 11:43:46AM +0200, Remco van Mook wrote: > > People can also filter all ASNs ending with the digit 4. There?s no policy > against it. Doesn?t make it less stupid, though. And guess what is more probable. Be realistic. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From Jerzy.Pawlus at cyf-kr.edu.pl Wed Apr 15 11:48:29 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Wed, 15 Apr 2009 11:48:29 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: (message from Marco Hogewoning on Wed, 15 Apr 2009 11:41:15 +0200) References: <20090414125740.9D52C2F583@herring.ripe.net> <200904150925.n3F9P6IC007074@nc.cyf-kr.edu.pl> Message-ID: <200904150948.n3F9mTia013623@nc.cyf-kr.edu.pl> > > And there are basically no limitittations on getting a seperate AS > number to work around a), so you might as well drop 5.2.1 completely. > Do you observe an unlimited number of requests for an AS assignment now? Jurek From fweimer at bfk.de Wed Apr 15 11:48:51 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 15 Apr 2009 11:48:51 +0200 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <20090406121040.GT56098@reiftel.karrenberg.net> (Daniel Karrenberg's message of "Mon, 6 Apr 2009 14:10:40 +0200") References: <20090406121040.GT56098@reiftel.karrenberg.net> Message-ID: <82ljq2i6ws.fsf@mid.bfk.de> * Daniel Karrenberg: > As of 1 July 2010, the RIPE NCC will start allocating enough address > space to LIRs to meet their needs for a period of up to nine months. > > As of 1 January 2011, the RIPE NCC will start allocating enough address > space to LIRs to meet their needs for a period of up to six months. > > As of 1 July 2011, the RIPE NCC will start allocating enough address > space to LIRs to meet their needs for a period of up to three months. This trades address space for routing table slots. Isn't this a bad thing? Do you suggesst to refuse requests for indepedently routable IP space if immediate need for the next three months does not justify a sufficiently large chunk of address space? -- 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 andy at nosignal.org Wed Apr 15 11:49:31 2009 From: andy at nosignal.org (Andy Davidson) Date: Wed, 15 Apr 2009 10:49:31 +0100 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090414125740.9D52C2F583@herring.ripe.net> References: <20090414125740.9D52C2F583@herring.ripe.net> Message-ID: <31AA349B-F419-4898-A236-3B8FD70DDA15@nosignal.org> On 14 Apr 2009, at 13:57, Ingrid Wijte wrote: > Multiple IPv6 /32 Allocations for LIRs I do not support this proposal. If an org (LIR or not) needs a separate address block for routing reasons, then this should be catered for through the PI policy. PA should be aggregatable. There's a clue in the name. ;-) Andy From Jerzy.Pawlus at cyf-kr.edu.pl Wed Apr 15 11:51:23 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Wed, 15 Apr 2009 11:51:23 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: (message from Remco van Mook on Wed, 15 Apr 2009 11:43:46 +0200) References: Message-ID: <200904150951.n3F9pNHv013844@nc.cyf-kr.edu.pl> > > People can also filter all ASNs ending with the digit 4. There=B9s no policy > against it. Doesn=B9t make it less stupid, though. > Yes they can, but they certeinly will if it contradics offical RIPE policy Jurek From Jerzy.Pawlus at cyf-kr.edu.pl Wed Apr 15 11:52:58 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Wed, 15 Apr 2009 11:52:58 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <82myaii6ym.fsf@mid.bfk.de> (message from Florian Weimer on Wed, 15 Apr 2009 11:47:45 +0200) References: <49E59614.7080403@man.poznan.pl> <20090415084616.GC22775@hydra.ck.polsl.pl> <821vrujmzm.fsf@mid.bfk.de> <200904150937.n3F9bPsV010847@nc.cyf-kr.edu.pl> <82myaii6ym.fsf@mid.bfk.de> Message-ID: <200904150952.n3F9qwLC014830@nc.cyf-kr.edu.pl> > > There's no long-term guarantee of routability for /32s, either. > This is interesting. Could you give a time frame? Jurek From Jerzy.Pawlus at cyf-kr.edu.pl Wed Apr 15 11:57:38 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Wed, 15 Apr 2009 11:57:38 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <31AA349B-F419-4898-A236-3B8FD70DDA15@nosignal.org> (message from Andy Davidson on Wed, 15 Apr 2009 10:49:31 +0100) References: <20090414125740.9D52C2F583@herring.ripe.net> <31AA349B-F419-4898-A236-3B8FD70DDA15@nosignal.org> Message-ID: <200904150957.n3F9vc7B016027@nc.cyf-kr.edu.pl> *Andy, > > Multiple IPv6 /32 Allocations for LIRs > > I do not support this proposal. If an org (LIR or not) needs a > separate address block for routing reasons, then this should be > catered for through the PI policy. > > PA should be aggregatable. There's a clue in the name. ;-) > And guess what is more scalable. PI per client or PA per AS. Jurek From andy at nosignal.org Wed Apr 15 12:04:27 2009 From: andy at nosignal.org (Andy Davidson) Date: Wed, 15 Apr 2009 11:04:27 +0100 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904150957.n3F9vc7B016027@nc.cyf-kr.edu.pl> References: <20090414125740.9D52C2F583@herring.ripe.net> <31AA349B-F419-4898-A236-3B8FD70DDA15@nosignal.org> <200904150957.n3F9vc7B016027@nc.cyf-kr.edu.pl> Message-ID: On 15 Apr 2009, at 10:57, Jerzy Pawlus wrote: > *Andy, > >>> Multiple IPv6 /32 Allocations for LIRs >> >> I do not support this proposal. If an org (LIR or not) needs a >> separate address block for routing reasons, then this should be >> catered for through the PI policy. >> >> PA should be aggregatable. There's a clue in the name. ;-) >> > > And guess what is more scalable. PI per client or PA per AS. If I read this as "routing table slots per client" or "routing table slots per AS" then the two are broadly equivalent... Andy PS, I would like a pony too. From Jerzy.Pawlus at cyf-kr.edu.pl Wed Apr 15 12:06:46 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Wed, 15 Apr 2009 12:06:46 +0200 (METDST) Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <20090406121040.GT56098@reiftel.karrenberg.net> (message from Daniel Karrenberg on Mon, 6 Apr 2009 14:10:40 +0200) References: <20090406121040.GT56098@reiftel.karrenberg.net> Message-ID: <200904151006.n3FA6kwj017791@nc.cyf-kr.edu.pl> Dear colleagues, > attached you will find a policy proposal we call "Run Out Fairly". > It is based on a discussion instigated by your's truly during the > open policy hour at the latest RIPE meeting. > I will support this policy. Jurek From slz at baycix.de Wed Apr 15 12:09:55 2009 From: slz at baycix.de (Sascha Lenz) Date: Wed, 15 Apr 2009 12:09:55 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <31AA349B-F419-4898-A236-3B8FD70DDA15@nosignal.org> References: <20090414125740.9D52C2F583@herring.ripe.net> <31AA349B-F419-4898-A236-3B8FD70DDA15@nosignal.org> Message-ID: <49E5B273.5020706@baycix.de> Hi, Andy Davidson schrieb: > > On 14 Apr 2009, at 13:57, Ingrid Wijte wrote: > >> Multiple IPv6 /32 Allocations for LIRs > > I do not support this proposal. If an org (LIR or not) needs a separate > address block for routing reasons, then this should be catered for > through the PI policy. > > PA should be aggregatable. There's a clue in the name. ;-) ...soo... instead of announcing an aggregated /32 for say 200 customers you want 200 unaggregated say /48s in the routing table? Requesting an ALLOCATION usually means, you want to ASSIGN Subnets of the allocation to 3rd parties (internal branches, customers....). PI .. a) ..forbids "sub-assignments" b) ..means that you have to announce each PI prefix seperately even if you could aggregate it due to same routing policy Your idea only works smoothly if you really only need ONE assignment. (But then it would be the right thing to do, getting PI.) But for the record: I don't really support the proposal eiter since it's rather a workaround for the "i-can-only-annonce-a-/32-to-certain-parties"-problem mentioned earlier in the thread. I do recognize the problem though, hust hopeing someone comes up with a nicer solution to this. I have a similar problem where i have to descide upon continuing to announce /40s ("Sub-Allocations") of a /32 PA Allocation for seperate ASNs with "fallback tunnels" to the AS announcing the /32 (so i don't loose traffic from providers doing strict-RIR-filtering) - or to get ~50 PI assignments (for now, more in the future) and announce each of those seperately since i can't aggregate that. I think i have to roll dice, both is somewhat ridiculous in the end<...> And no, none of those ASNs wants to become a LIR in their own right due to multiple reasons beyond the scope of this mail (let's call it "reality"). -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From Jerzy.Pawlus at cyf-kr.edu.pl Wed Apr 15 12:09:50 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Wed, 15 Apr 2009 12:09:50 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: (message from Andy Davidson on Wed, 15 Apr 2009 11:04:27 +0100) References: <20090414125740.9D52C2F583@herring.ripe.net> <31AA349B-F419-4898-A236-3B8FD70DDA15@nosignal.org> <200904150957.n3F9vc7B016027@nc.cyf-kr.edu.pl> Message-ID: <200904151009.n3FA9od8018881@nc.cyf-kr.edu.pl> > > > And guess what is more scalable. PI per client or PA per AS. > > If I read this as "routing table slots per client" or "routing table > slots per AS" then the two are broadly equivalent... > PI per client are reality in some regions. Jurek From Jerzy.Pawlus at cyf-kr.edu.pl Wed Apr 15 12:19:02 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Wed, 15 Apr 2009 12:19:02 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <49E5B273.5020706@baycix.de> (message from Sascha Lenz on Wed, 15 Apr 2009 12:09:55 +0200) References: <20090414125740.9D52C2F583@herring.ripe.net> <31AA349B-F419-4898-A236-3B8FD70DDA15@nosignal.org> <49E5B273.5020706@baycix.de> Message-ID: <200904151019.n3FAJ2rx021558@nc.cyf-kr.edu.pl> Sascha Lenz writes: > I don't really support the proposal eiter since it's rather a workaround > for the "i-can-only-annonce-a-/32-to-certain-parties"-problem mentioned > earlier in the thread. > I do recognize the problem though, hust hopeing someone comes up with a > nicer solution to this. > Time is running faster and faster. Perhaps we can put a time limit to "Multiple IPv6 /32 Allocations for LIRs" Jurek From Jerzy.Pawlus at cyf-kr.edu.pl Wed Apr 15 12:22:12 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Wed, 15 Apr 2009 12:22:12 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <49E5B273.5020706@baycix.de> (message from Sascha Lenz on Wed, 15 Apr 2009 12:09:55 +0200) References: <20090414125740.9D52C2F583@herring.ripe.net> <31AA349B-F419-4898-A236-3B8FD70DDA15@nosignal.org> <49E5B273.5020706@baycix.de> Message-ID: <200904151022.n3FAMCh6022594@nc.cyf-kr.edu.pl> Sascha Lenz writes: > I have a similar problem where i have to descide upon continuing to > announce /40s ("Sub-Allocations") of a /32 PA Allocation for seperate > ASNs with "fallback tunnels" to the AS announcing the /32 (so i don't > loose traffic from providers doing strict-RIR-filtering) - or to get ~50 > PI assignments (for now, more in the future) and announce each of those > seperately since i can't aggregate that. We all have similar problems and think how much time we wasted on finding solution. Jurek From nick at inex.ie Wed Apr 15 12:32:26 2009 From: nick at inex.ie (Nick Hilliard) Date: Wed, 15 Apr 2009 11:32:26 +0100 Subject: [address-policy-wg] Policy Proposal : "Run Out Fairly" In-Reply-To: <20090406121040.GT56098@reiftel.karrenberg.net> References: <20090406121040.GT56098@reiftel.karrenberg.net> Message-ID: <49E5B7BA.7030705@inex.ie> On 06/04/2009 13:10, Daniel Karrenberg wrote: > attached you will find a policy proposal we call "Run Out Fairly". [...] > PS: Can we refer to this proposal by name and not by number? ;-) You'll have to forgive me for being suspicious about titles like this. It reminds me a little of the Democratic Peoples' Republic of Korea insisting on the word "democratic" being in their country's title, just to make sure that people are aware that it's a democracy - if they didn't already know. I'm curious to understand how smaller LIRs will cope with these requirements, particularly in light of Daniel's statement: > I do not think a change [of minimum allocation size] is necessary here > to address the objective of the proposal. If you're a small ISP, with a low customer signon rate, how are you going to justify requesting a /21 for 3 months usage when a /21 might normally last you for a period of, say 6 months or a year or something? I'm aware that the timescales are such that this period of enforced "fairness" won't be long. However it strikes me that during this period, very small ISPs will end up facing a tough fight to justify a /21 when it's clear from their previous allocation records that their address burn rate is very low and that /21 is significantly more than they would require within the assignment period. Nick From jakub.jermak at polsl.pl Wed Apr 15 13:25:08 2009 From: jakub.jermak at polsl.pl (Jakub Jermak) Date: Wed, 15 Apr 2009 13:25:08 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <2E61C47A190CA44ABFCF23147E57E4BCE6393C@NLEN1EX1.eu.win.equinix.com> References: <20090414125740.9D52C2F583@herring.ripe.net> <2E61C47A190CA44ABFCF23147E57E4BCE6393B@NLEN1EX1.eu.win.equinix.com> <2E61C47A190CA44ABFCF23147E57E4BCE6393C@NLEN1EX1.eu.win.equinix.com> Message-ID: <20090415112508.GA30008@polsl.pl> Hello Remco, On Tue, Apr 14, 2009 at 05:36:09PM +0200, Remco van Mook wrote: > The 'unique routing policy' is already a requirement to get a second (or > any subsequent) AS as far as I know, so it doesn't really add any > limitation. Oh yes it does add limitation to a number of AS assigned by RIPE NCC to a given LIR. Recently I faced it. There has to be solid unique routing policy reason. Jakub Jermak -- - Jakub Jermak Silesian University of Technology - jermak at polsl.pl (JJ1214-RIPE) Akademicka 16, 44-100 Gliwice, Poland - PGP: http://hydra.ck.polsl.pl/~jermak phone: +48 32 230-76-86 From info at streamservice.nl Wed Apr 15 14:45:00 2009 From: info at streamservice.nl (Stream Service) Date: Wed, 15 Apr 2009 14:45:00 +0200 Subject: [address-policy-wg] RE: Multiple IPv6 /32 Allocations for LIRs In-Reply-To: References: <20090414125740.9D52C2F583@herring.ripe.net> <31AA349B-F419-4898-A236-3B8FD70DDA15@nosignal.org> <00b101c9bdbb$dfdbfc80$9f93f580$@nl> Message-ID: <00c001c9bdc7$fd98c940$f8ca5bc0$@nl> Hello, (ab)using IPv6 PI is also not a good solution for it I guess. How should we make it possible? With kind regards, Mark Scholten -----Original Message----- From: Andy Davidson [mailto:andy.davidson at netsumo.com] Sent: woensdag 15 april 2009 13:54 To: Stream Service Subject: Re: Multiple IPv6 /32 Allocations for LIRs On 15 Apr 2009, at 12:18, Stream Service wrote: > It should be aggegatable for as far as the LIR wants. It should also > be > possible to split it up to /48's without a problem (for example is 1 > LIR has > multiple ASN's or when some address space should only be available via > peering). It is possible with IPv4 for as far as I know, why don't > make it > possible with IPv6? Hi, Mark Thank you for your email. It is possible with IPv6. The question is, do we really want the v6 table to be as fragmented as the v4 one ? Of course we do not. We want fast convergence in the default free zone. We wont get this if we don't look after the policies which govern assignment though. Andy -- Regards, Andy Davidson, NetSumo Limited D: +44 (0) 20 7993 1702 S: +44 (0) 20 7993 1700 E: andy.davidson at netsumo.com From gert at space.net Wed Apr 15 15:51:41 2009 From: gert at space.net (Gert Doering) Date: Wed, 15 Apr 2009 15:51:41 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090414125740.9D52C2F583@herring.ripe.net> References: <20090414125740.9D52C2F583@herring.ripe.net> Message-ID: <20090415135141.GN61514@Space.Net> Hi, On Tue, Apr 14, 2009 at 02:57:40PM +0200, Ingrid Wijte wrote: > PDP Number: 2009-05 > Multiple IPv6 /32 Allocations for LIRs let me try to summarize the discussion so far: - (some/most) people acknowledge that there is a need for a number of network operators to run two distinct networks - for different reasons, be it "commercial" vs. "national research network", or be it "different country networks for large multinational ISPs". - the current policy doesn't permit a single LIR to receive multiple allocations (warning: an allocation can be bigger than a /32, so this needs to be taken into account in the wording) - the main issue right now seems to be the definition of criteria, under which circumstances a LIR can be eligible to receive further /32s - tieing this criteria to the 'the LIR has multiple AS numbers' is seen as problematic, because it could lead to "if we can't get the address space we want, we sneak it through the 'AS number' backdoor" I do not think that "waste of addresses" is the primary issue we should worry about, at least not when talking about a few thousand extra /32s (out of a billion). "Routing table slots" is something we need to be careful about, and "fairness and clear rules", and "make IPv6 workable". So I think this discussion should move towards: - find examples of networks that have problems with the current policy, and try to figure out common criteria - formulate criteria for "additional allocations" that can get (rough) consensus - re-word the policy proposal accordingly 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 pk at DENIC.DE Wed Apr 15 15:43:00 2009 From: pk at DENIC.DE (Peter Koch) Date: Wed, 15 Apr 2009 15:43:00 +0200 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <20090326130519.868942F583@herring.ripe.net> References: <20090326130519.868942F583@herring.ripe.net> Message-ID: <20090415134300.GB13037@x27.adm.denic.de> On Thu, Mar 26, 2009 at 02:05:19PM +0100, Filiz Yilmaz wrote: > Anycasting Assignments for TLDs and Tier 0/1 ENUM > http://www.ripe.net/ripe/policies/proposals/2008-05.html {Full disclosure: DENIC would benefit from the implementation of this proposal.} I support the proposal, but I'm still unhappy with parts of the wording: {only looking at the v4 text, comments apply to the v6 version accordingly} >> 6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers >> >> Critical DNS infrastructure is defined as infrastructure providing Authoritative >> TLD or ENUM Tier 0/1 DNS lookup services. The term "Critical DNS infrastructure" is defined here just to be referred to in one single place three paragraphs down. I'd prefer if the term would be avoided and "Authoritative TLD or ENUM Tier 0/1 DNS lookup services" be inserted at the appropriate place. >> The organisations applicable under this policy are TLD operators as defined by >> IANA and ENUM operators as defined by the ITU. The organisation may receive up >> to four /24 prefixes per TLD/ENUM. These prefixes must be used for the sole "TLD operators as defined by IANA" may be a well intended phrase, but many affected registries would reject being "defined" by IANA. This layer 9 stuff aside, I'm still uncertain whether the assignment goes to the registry itself or to some operator who provides name service for TLDs (or ENUM, for that matter). The former makes more sense to me. "TLD manager/administrator as described in RFC 1591" might be more acceptable. Similar considerations apply to "ENUM operators as defined by the ITU". As a side note, ENUM Tier 0 assignments would probably have interactions with the policy proposal on "Assignments to the NCC". >> purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as >> described in RFC 3258. This is a verbatim quote from the current policy documents, but a reference to BCP126/RFC4786 might be more appropriate these days. >> Assignments for Critical DNS infrastructure are subject to the policies >> described in the RIPE document entitled "Contractual Requirements for Provider >> Independent Resource Holders in the RIPE NCC Service Region". >> >> Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in >> the RIPE Database and must be returned to the RIPE NCC if not in use for >> Critical DNS infrastructure any longer. OK, 2nd occurence, but s/Critical DNS infrastructure/the purpose justifying the assignment/. -Peter From fweimer at bfk.de Wed Apr 15 16:20:05 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 15 Apr 2009 16:20:05 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904150952.n3F9qwLC014830@nc.cyf-kr.edu.pl> (Jerzy Pawlus's message of "Wed, 15 Apr 2009 11:52:58 +0200 (METDST)") References: <49E59614.7080403@man.poznan.pl> <20090415084616.GC22775@hydra.ck.polsl.pl> <821vrujmzm.fsf@mid.bfk.de> <200904150937.n3F9bPsV010847@nc.cyf-kr.edu.pl> <82myaii6ym.fsf@mid.bfk.de> <200904150952.n3F9qwLC014830@nc.cyf-kr.edu.pl> Message-ID: <82k55mf17u.fsf@mid.bfk.de> * Jerzy Pawlus: >> There's no long-term guarantee of routability for /32s, either. > This is interesting. Could you give a time frame? Malfunction due to more or less unforeseen routing table growth. Some operators might think that your prefix/ASN has no place on their network. We've seen it with IPv4 from time to time. -- 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 Ray.Bellis at nominet.org.uk Wed Apr 15 16:25:16 2009 From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk) Date: Wed, 15 Apr 2009 15:25:16 +0100 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <82k55mf17u.fsf@mid.bfk.de> References: <49E59614.7080403@man.poznan.pl> <20090415084616.GC22775@hydra.ck.polsl.pl> <821vrujmzm.fsf@mid.bfk.de> <200904150937.n3F9bPsV010847@nc.cyf-kr.edu.pl> <82myaii6ym.fsf@mid.bfk.de> <200904150952.n3F9qwLC014830@nc.cyf-kr.edu.pl> <82k55mf17u.fsf@mid.bfk.de> Message-ID: > > We've seen it with IPv4 from time to time. > Indeed - I remember seeing it many years ago on a FreeBSD box running bgpd which fell over when the number of kernel routes exceeded 2^16. Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists-ripe at c4inet.net Wed Apr 15 17:41:56 2009 From: lists-ripe at c4inet.net (lists-ripe at c4inet.net) Date: Wed, 15 Apr 2009 16:41:56 +0100 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090415135141.GN61514@Space.Net> References: <20090414125740.9D52C2F583@herring.ripe.net> <20090415135141.GN61514@Space.Net> Message-ID: <20090415154156.GA21294@cilantro.c4inet.net> On Wed, Apr 15, 2009 at 03:51:41PM +0200, Gert Doering wrote: > - the current policy doesn't permit a single LIR to receive multiple > allocations (warning: an allocation can be bigger than a /32, so this > needs to be taken into account in the wording) I think this would be most easily solved by removing the condition that each /32 must be announced as such. In my opinion an "address allocation/ assignment" policy is not supposed to make routing decisions anyway. From Jerzy.Pawlus at cyf-kr.edu.pl Wed Apr 15 16:43:04 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Wed, 15 Apr 2009 16:43:04 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090415135141.GN61514@Space.Net> (message from Gert Doering on Wed, 15 Apr 2009 15:51:41 +0200) References: <20090414125740.9D52C2F583@herring.ripe.net> <20090415135141.GN61514@Space.Net> Message-ID: <200904151443.n3FEh4kg001821@nc.cyf-kr.edu.pl> Gert, > So I think this discussion should move towards: > > - find examples of networks that have problems with the current policy, > and try to figure out common criteria > > > Can anybody (maybe from a RIPE staff) give a number of LIR's with more than one AS assigned? This can give us a rough estimate. Jurek From Jerzy.Pawlus at cyf-kr.edu.pl Wed Apr 15 16:47:32 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Wed, 15 Apr 2009 16:47:32 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090415154156.GA21294@cilantro.c4inet.net> (lists-ripe@c4inet.net) References: <20090414125740.9D52C2F583@herring.ripe.net> <20090415135141.GN61514@Space.Net> <20090415154156.GA21294@cilantro.c4inet.net> Message-ID: <200904151447.n3FElWdJ003321@nc.cyf-kr.edu.pl> On Wed, Apr 15, 2009 at 03:51:41PM +0200, Gert Doering wrote: > > - the current policy doesn't permit a single LIR to receive multiple > > allocations (warning: an allocation can be bigger than a /32, so this > > needs to be taken into account in the wording) > > I think this would be most easily solved by removing the condition that > each /32 must be announced as such. In my opinion an "address allocation/ > assignment" policy is not supposed to make routing decisions anyway. > This is acceptable solution, however it leaves more space to "uncontrolable deaggregation". The net result will be more inconsistent filters. Jurek From gert at space.net Wed Apr 15 16:58:05 2009 From: gert at space.net (Gert Doering) Date: Wed, 15 Apr 2009 16:58:05 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904151443.n3FEh4kg001821@nc.cyf-kr.edu.pl> References: <20090414125740.9D52C2F583@herring.ripe.net> <20090415135141.GN61514@Space.Net> <200904151443.n3FEh4kg001821@nc.cyf-kr.edu.pl> Message-ID: <20090415145804.GP61514@Space.Net> Hi, On Wed, Apr 15, 2009 at 04:43:04PM +0200, Jerzy Pawlus wrote: > > So I think this discussion should move towards: > > > > - find examples of networks that have problems with the current policy, > > and try to figure out common criteria > > Can anybody (maybe from a RIPE staff) give a number of LIR's with > more than one AS assigned? This can give us a rough estimate. Not for the paragraph you quoted. Currently, AS numbers are used with PA blocks, PI space, sub-allocations of PA blocks, etc. I was asking specifically for real-world examples of networks that cannot operate with "a single PA block (plus a number of PI blocks for customers) per LIR". IPv6 PI does not exist today, but is likely going to exist in a few months (the IPv6 PI proposal passed last call and is currently in WG chairs last call). 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 -------------- 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 Wed Apr 15 16:59:32 2009 From: gert at space.net (Gert Doering) Date: Wed, 15 Apr 2009 16:59:32 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090415154156.GA21294@cilantro.c4inet.net> References: <20090414125740.9D52C2F583@herring.ripe.net> <20090415135141.GN61514@Space.Net> <20090415154156.GA21294@cilantro.c4inet.net> Message-ID: <20090415145932.GQ61514@Space.Net> Hi, On Wed, Apr 15, 2009 at 04:41:56PM +0100, lists-ripe at c4inet.net wrote: > On Wed, Apr 15, 2009 at 03:51:41PM +0200, Gert Doering wrote: > > - the current policy doesn't permit a single LIR to receive multiple > > allocations (warning: an allocation can be bigger than a /32, so this > > needs to be taken into account in the wording) > > I think this would be most easily solved by removing the condition that > each /32 must be announced as such. In my opinion an "address allocation/ > assignment" policy is not supposed to make routing decisions anyway. The current policy requires announcement of the aggregate, but does not forbid announcements of more-specifics. Whether or not more-specifics *work*, as in "all important peers accept your routes", is not something the APWG can decide. 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 lists-ripe at c4inet.net Wed Apr 15 18:12:45 2009 From: lists-ripe at c4inet.net (lists-ripe at c4inet.net) Date: Wed, 15 Apr 2009 17:12:45 +0100 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090415145932.GQ61514@Space.Net> References: <20090414125740.9D52C2F583@herring.ripe.net> <20090415135141.GN61514@Space.Net> <20090415154156.GA21294@cilantro.c4inet.net> <20090415145932.GQ61514@Space.Net> Message-ID: <20090415161245.GB21294@cilantro.c4inet.net> Hi, On Wed, Apr 15, 2009 at 04:59:32PM +0200, Gert Doering wrote: > The current policy requires announcement of the aggregate, but does not > forbid announcements of more-specifics. Announcing the aggregate falls down in the "disconnected networks" case, though. > Whether or not more-specifics *work*, as in "all important peers accept > your routes", is not something the APWG can decide. There's not even a guarantee that a /32 (or more that one, fwiw) are going to be accepted. Who knows what people put in their filters? Regards, Sascha Luck From gert at space.net Wed Apr 15 17:09:39 2009 From: gert at space.net (Gert Doering) Date: Wed, 15 Apr 2009 17:09:39 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090415161245.GB21294@cilantro.c4inet.net> References: <20090414125740.9D52C2F583@herring.ripe.net> <20090415135141.GN61514@Space.Net> <20090415154156.GA21294@cilantro.c4inet.net> <20090415145932.GQ61514@Space.Net> <20090415161245.GB21294@cilantro.c4inet.net> Message-ID: <20090415150939.GR61514@Space.Net> Hi, On Wed, Apr 15, 2009 at 05:12:45PM +0100, lists-ripe at c4inet.net wrote: > On Wed, Apr 15, 2009 at 04:59:32PM +0200, Gert Doering wrote: > > The current policy requires announcement of the aggregate, but does not > > forbid announcements of more-specifics. > > Announcing the aggregate falls down in the "disconnected networks" case, > though. This is why we need to see specific examples of networks having problems with the current policy. To make more educated decisions about what problems we are trying to solve. 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 leo.vegoda at icann.org Wed Apr 15 18:02:06 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 15 Apr 2009 09:02:06 -0700 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: Message-ID: On 15/04/2009 2:34, "Marco Hogewoning" wrote: [...] > Let's assume you have a seperate entity in your company, which > operates in a different geographical region under it's own AS and > routing policy. Only one company (the holding for instance) is an LIR > in the current situation. > > How do you solve this at the moment iin IPv4-land ? Good question. Isn't the normal answer to open a separate LIR for the separate business unit? Regards, Leo Vegoda From pk at DENIC.DE Wed Apr 15 18:57:33 2009 From: pk at DENIC.DE (Peter Koch) Date: Wed, 15 Apr 2009 18:57:33 +0200 Subject: [address-policy-wg] Draft Proposal: Assignment of an IPv4 /24 for documentation purposes Message-ID: <20090415165733.GD13037@x27.adm.denic.de> Dear WG, this is a rough draft policy proposal. I'd appreciate some feedback before I decide whether to invoke the formal process. Summary: The RIPE NCC is asked to assign an IPv4 /24 for documentation purposes. Background: In example configurations, RFCs, training material and other documentation it is necessary from time to time to include IP addresses, domain names or even phone numbers as examples. These resources should meet all syntactical requirements (e.g., be "real" IP addresses), but should not interfere with assignments or registrations by innocent third parties. See RFC 4085 (BCP 105) for what could happen in the worst case. For the DNS, RFC 2606 (BCP 32) has set aside several top level and second level domain names and the network 192.0.2/24 has been dedicated for documentation and test purposes by the IANA in the past (see RFC 3330). RFC 3849 ("IPv6 Address Prefix Reserved for Documentation") documents APNIC's assignment of 2001:DB8::/32 for the sole use in example texts. Motivation: During recent discussion within the IETF, but also on other occasions in the past, it appeared that a single /24 is often not enough to support instructive examples. This may include more complex network designs, or the use of addresses for DNS name servers, where good practice (see RFC 2182, BCP 16) suggests topological diversity. Sometimes, address space from RFC 1918 (BCP 5) is used in addition to or as a replacement for 192.0.2/24, but this is also a source of confusion due to the special nature of the "private address space". It also conflicts with the goal to avoid any collision with addresses used in real life, even if the burden would be spread across many users of RFC 1918 address space. Request: The RIPE NCC is asked to assign and dedicate a /24 that is reasonable visually distinct from 192.0.2/24 for documentation only purposes. The network is not to be used and the prefix is never expected to be announced in any BGP session (cf. 3849). The new assignment is not intended to serve as a supplement to RFC 1918 address space. It is intentionally left open here whether similar considerations would suggest an additional assignment in v6 space, as well. The pros should be obvious to anyone who ever had to write documentation or example configurations, but there are also some cons: o another /24 is a waste of space o just a /24 won't be enough o this creates yet another bogon o any invest in IPv4 is a waste of resources, anyway o nobody knew 192.0.2/24 in the first place, so why add to the confusion? o this doesn't need a policy proposal, but could be dealt with through a specially "sponsored" PI assignment A special action seems cleaner to me than some random PI assignment, but this is why I'd like to ask the WG for feedback. Also, if anyone is aware of other address space similar to 192.0.2/24, I'd appreciate a pointer. Best regards, Peter From info at streamservice.nl Wed Apr 15 19:11:43 2009 From: info at streamservice.nl (Stream Service) Date: Wed, 15 Apr 2009 19:11:43 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904151447.n3FElWdJ003321@nc.cyf-kr.edu.pl> References: <20090414125740.9D52C2F583@herring.ripe.net> <20090415135141.GN61514@Space.Net> <20090415154156.GA21294@cilantro.c4inet.net> <200904151447.n3FElWdJ003321@nc.cyf-kr.edu.pl> Message-ID: <016801c9bded$40bf56b0$c23e0410$@nl> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jerzy Pawlus Sent: woensdag 15 april 2009 16:48 To: lists-ripe at c4inet.net Cc: gert at space.net; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) On Wed, Apr 15, 2009 at 03:51:41PM +0200, Gert Doering wrote: > > - the current policy doesn't permit a single LIR to receive multiple > > allocations (warning: an allocation can be bigger than a /32, so this > > needs to be taken into account in the wording) > > I think this would be most easily solved by removing the condition that > each /32 must be announced as such. In my opinion an "address allocation/ > assignment" policy is not supposed to make routing decisions anyway. > This is acceptable solution, however it leaves more space to "uncontrolable deaggregation". The net result will be more inconsistent filters. Jurek --------------------- Just make it policy that it shouldn't be smaller as a /48. This will reduce it a little bit, also requesting to aggregate where possible should be fine I guess. Mark From info at streamservice.nl Wed Apr 15 19:11:43 2009 From: info at streamservice.nl (Stream Service) Date: Wed, 15 Apr 2009 19:11:43 +0200 Subject: [address-policy-wg] Draft Proposal: Assignment of an IPv4 /24 for documentation purposes In-Reply-To: <20090415165733.GD13037@x27.adm.denic.de> References: <20090415165733.GD13037@x27.adm.denic.de> Message-ID: <015401c9bded$40052e70$c00f8b50$@nl> Hello Peter, Why not use private address space in documentation? It is used many times for things it is not really designed for, but it works great. For example the 10.254.254.0/24 is a range I did see a long time back in documentation, it is something that could be used in documentation I guess. Default private address space that is used on devices are in the 192.168.x.x range and 10.0.x.x and 10.10.x.x and 10.8.x.x range for as far as I know. Wasting IPv4 IPs isn't good for the future I guess. Also I am missing some other private address space that I did never see in use. Best regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Peter Koch Sent: woensdag 15 april 2009 18:58 To: RIPE address policy WG Subject: [address-policy-wg] Draft Proposal: Assignment of an IPv4 /24 for documentation purposes Dear WG, this is a rough draft policy proposal. I'd appreciate some feedback before I decide whether to invoke the formal process. Summary: The RIPE NCC is asked to assign an IPv4 /24 for documentation purposes. Background: In example configurations, RFCs, training material and other documentation it is necessary from time to time to include IP addresses, domain names or even phone numbers as examples. These resources should meet all syntactical requirements (e.g., be "real" IP addresses), but should not interfere with assignments or registrations by innocent third parties. See RFC 4085 (BCP 105) for what could happen in the worst case. For the DNS, RFC 2606 (BCP 32) has set aside several top level and second level domain names and the network 192.0.2/24 has been dedicated for documentation and test purposes by the IANA in the past (see RFC 3330). RFC 3849 ("IPv6 Address Prefix Reserved for Documentation") documents APNIC's assignment of 2001:DB8::/32 for the sole use in example texts. Motivation: During recent discussion within the IETF, but also on other occasions in the past, it appeared that a single /24 is often not enough to support instructive examples. This may include more complex network designs, or the use of addresses for DNS name servers, where good practice (see RFC 2182, BCP 16) suggests topological diversity. Sometimes, address space from RFC 1918 (BCP 5) is used in addition to or as a replacement for 192.0.2/24, but this is also a source of confusion due to the special nature of the "private address space". It also conflicts with the goal to avoid any collision with addresses used in real life, even if the burden would be spread across many users of RFC 1918 address space. Request: The RIPE NCC is asked to assign and dedicate a /24 that is reasonable visually distinct from 192.0.2/24 for documentation only purposes. The network is not to be used and the prefix is never expected to be announced in any BGP session (cf. 3849). The new assignment is not intended to serve as a supplement to RFC 1918 address space. It is intentionally left open here whether similar considerations would suggest an additional assignment in v6 space, as well. The pros should be obvious to anyone who ever had to write documentation or example configurations, but there are also some cons: o another /24 is a waste of space o just a /24 won't be enough o this creates yet another bogon o any invest in IPv4 is a waste of resources, anyway o nobody knew 192.0.2/24 in the first place, so why add to the confusion? o this doesn't need a policy proposal, but could be dealt with through a specially "sponsored" PI assignment A special action seems cleaner to me than some random PI assignment, but this is why I'd like to ask the WG for feedback. Also, if anyone is aware of other address space similar to 192.0.2/24, I'd appreciate a pointer. Best regards, Peter From info at streamservice.nl Wed Apr 15 19:11:43 2009 From: info at streamservice.nl (Stream Service) Date: Wed, 15 Apr 2009 19:11:43 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: References: Message-ID: <016501c9bded$40a34330$c1e9c990$@nl> Hello Leo, Just requesting an extra AS and PI space is now possible I guess. Maybe someone from Leaseweb/Fiberring can say how they do it? With kind regards, Mark -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Leo Vegoda Sent: woensdag 15 april 2009 18:02 To: Marco Hogewoning; Remco van Mook Cc: Bartek Gajda; Piotr Strzyzewski; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) On 15/04/2009 2:34, "Marco Hogewoning" wrote: [...] > Let's assume you have a seperate entity in your company, which > operates in a different geographical region under it's own AS and > routing policy. Only one company (the holding for instance) is an LIR > in the current situation. > > How do you solve this at the moment iin IPv4-land ? Good question. Isn't the normal answer to open a separate LIR for the separate business unit? Regards, Leo Vegoda From garry at nethinks.com Wed Apr 15 19:26:04 2009 From: garry at nethinks.com (Garry Glendown) Date: Wed, 15 Apr 2009 19:26:04 +0200 Subject: [address-policy-wg] Draft Proposal: Assignment of an IPv4 /24 for documentation purposes In-Reply-To: <20090415165733.GD13037@x27.adm.denic.de> References: <20090415165733.GD13037@x27.adm.denic.de> Message-ID: <49E618AC.7070106@nethinks.com> Peter Koch wrote: > The new assignment is not intended to serve as a supplement to RFC 1918 > address space. It is intentionally left open here whether similar > considerations would suggest an additional assignment in v6 space, as well. Why would you not want to use RFC1918's IPs in documentation? Everybody inclined enough to read documentation will probably know those addresses at a glance ... instead, you want to throw a new set of IPs on the market that nobody knows, nobody cares for, most likely nobody will use and that have no real benefit as far as documentation goes ... (at least none I'd see). Heck, I've never known that 192.0.2/24 is reserved for test purposes ... or that there are "test domains" ... but maybe I'm just ignorant ... ;) (not that saving that /24 would mitigate the dawning IPv4 shortage ...) -garry From nick at inex.ie Wed Apr 15 20:26:32 2009 From: nick at inex.ie (Nick Hilliard) Date: Wed, 15 Apr 2009 19:26:32 +0100 Subject: [address-policy-wg] Draft Proposal: Assignment of an IPv4 /24 for documentation purposes In-Reply-To: <20090415165733.GD13037@x27.adm.denic.de> References: <20090415165733.GD13037@x27.adm.denic.de> Message-ID: <49E626D8.80206@inex.ie> On 15/04/2009 17:57, Peter Koch wrote: > A special action seems cleaner to me than some random PI assignment, but > this is why I'd like to ask the WG for feedback. Also, if anyone is > aware of other address space similar to 192.0.2/24, I'd appreciate a pointer. Isn't this sort of thing more the area of the IETF? I'm not sure if it's really the responsibility of a regional IR to assign space for this sort of thing, in much the same way that I am sure that it's more appropriate to have this sort of thing encoded in an RFC. Nick From sander at steffann.nl Wed Apr 15 21:52:29 2009 From: sander at steffann.nl (Sander Steffann) Date: Wed, 15 Apr 2009 21:52:29 +0200 Subject: [address-policy-wg] Draft Proposal: Assignment of an IPv4 /24 for documentation purposes In-Reply-To: <20090415165733.GD13037@x27.adm.denic.de> References: <20090415165733.GD13037@x27.adm.denic.de> Message-ID: <374D3C78-B034-463B-8FC2-8F6D477BAB16@steffann.nl> Hello Peter, > For the DNS, RFC 2606 (BCP 32) has set aside several top level and > second level domain names and the network 192.0.2/24 has been > dedicated > for documentation and test purposes by the IANA in the past (see > RFC 3330). I am curious why the RIPE NCC is asked for this /24. If IANA has provided 192.0.2/24 in the past, why can't IANA provide another /24? It would require an RFC, but isn't that the right place to do this? Just trying to get all the background information :) Sander From Piotr.Strzyzewski at polsl.pl Wed Apr 15 22:20:56 2009 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 15 Apr 2009 22:20:56 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: References: Message-ID: <20090415202056.GA28448@hydra.ck.polsl.pl> On Wed, Apr 15, 2009 at 09:02:06AM -0700, Leo Vegoda wrote: > On 15/04/2009 2:34, "Marco Hogewoning" wrote: > > Let's assume you have a seperate entity in your company, which > > operates in a different geographical region under it's own AS and > > routing policy. Only one company (the holding for instance) is an LIR > > in the current situation. > > > > How do you solve this at the moment iin IPv4-land ? > > Good question. Isn't the normal answer to open a separate LIR for the > separate business unit? Sometimes it is not that case. For example, there could be one entity (LIR) which serves with the same staff (one business unit; limited resources) both commercial and academic customers using different boxes, IPs and ASes and (sometimes the most important) funds, which (all) due to whatever reason(s) which is beyond the scope of this thread, could not be mixed together. Opening a separate LIR is either an abuse of current policy (*) or unnecessary waste of time and money. (*) And let me remind that this abuse is necessary only for ipv6 (which we should promote). It seems that in ipv4 world people either do filters based on route objects or use fixed /24 size. Both options give some flexibility in announcing routes smaller then allocation. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From gih at apnic.net Wed Apr 15 23:27:46 2009 From: gih at apnic.net (Geoff Huston) Date: Thu, 16 Apr 2009 07:27:46 +1000 Subject: [address-policy-wg] Draft Proposal: Assignment of an IPv4 /24 for documentation purposes In-Reply-To: <374D3C78-B034-463B-8FC2-8F6D477BAB16@steffann.nl> References: <20090415165733.GD13037@x27.adm.denic.de> <374D3C78-B034-463B-8FC2-8F6D477BAB16@steffann.nl> Message-ID: On 16/04/2009, at 5:52 AM, Sander Steffann wrote: > Hello Peter, > >> For the DNS, RFC 2606 (BCP 32) has set aside several top level and >> second level domain names and the network 192.0.2/24 has been >> dedicated >> for documentation and test purposes by the IANA in the past (see >> RFC 3330). > > I am curious why the RIPE NCC is asked for this /24. If IANA has > provided 192.0.2/24 in the past, why can't IANA provide another /24? > It would require an RFC, but isn't that the right place to do this? > > Just trying to get all the background information :) > Sander > Perhaps I may be permitted to add some background data here. This topic has surfaced in the past in the case of IPv6 addresses and AS numbers. In the case of IPv6 the original APNIC proposal was rephrased as an RFC and the IANA documented the reservation in the IPv6 address registry on the basis of the published RFC. In the case of AS numbers there was a policy proposal in APNIC whose implementation was abandoned following the publication of an RFC that requested IANA to perform the registration. My interpretation of the relative roles of the RIRs, IANA and the IETF in this area is that such reservations, as distinct from allocations or assignments, should be performed by the IANA, and for IANA to undertake this it should be part of the protocol's address plan, and hence should be published as an RFC. i.e. as far as I understand the situation such reservations of number resources for documentation purposes falls to IANA to perform, and the instructions to IANA are in the form of a published RFC. The logical inference is that such proposals should head to the IETF rather than the RIRs. thanks, Geoff From t.klicki at net.icm.edu.pl Wed Apr 15 23:12:46 2009 From: t.klicki at net.icm.edu.pl (Tomasz Klicki) Date: Wed, 15 Apr 2009 23:12:46 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090415202056.GA28448@hydra.ck.polsl.pl> References: <20090415202056.GA28448@hydra.ck.polsl.pl> Message-ID: <49E64DCE.4080005@net.icm.edu.pl> Piotr Strzyzewski pisze: > Sometimes it is not that case. For example, there could be one entity > (LIR) which serves with the same staff (one business unit; limited > resources) both commercial and academic customers using different boxes, > IPs and ASes and (sometimes the most important) funds, which (all) due > to whatever reason(s) which is beyond the scope of this thread, could > not be mixed together. Opening a separate LIR is either an abuse of > current policy (*) or unnecessary waste of time and money. We have similar situation as described above. And - as it was probably said before in this discussion - many many LIRs in Poland, not only academic ones. I completely agree with your opinion, Piotr. Second LIR shouldn't be created just for achieving same policy of routing as in today's IPv4 world. Business and political rules are staying the same for IPv6, we are only changing type of addresses we use, thats all. With only one prefix we can't get same setup as we have right now. -- Tomasz Klicki ICM Core Network Services, University of Warsaw t.klicki at net.icm.edu.pl (+48-22) 5520527, 8268009, fax. 8284195 http://www.net.icm.edu.pl/ From randy at psg.com Thu Apr 16 01:03:51 2009 From: randy at psg.com (Randy Bush) Date: Thu, 16 Apr 2009 08:03:51 +0900 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <20090415134300.GB13037@x27.adm.denic.de> References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> Message-ID: > "TLD operators as defined by IANA" may be a well intended phrase, but many > affected registries would reject being "defined" by IANA. running a number of cctlds which have not signed silly papers with iana, i have no problem with the phrase. though i think it could probably be improved, e.g. servers in the root zone is what i suspect is intended. this comment should not be taken to imply i support this policy proposal. randy From Jerzy.Pawlus at cyf-kr.edu.pl Thu Apr 16 10:11:51 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Thu, 16 Apr 2009 10:11:51 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090415202056.GA28448@hydra.ck.polsl.pl> (message from Piotr Strzyzewski on Wed, 15 Apr 2009 22:20:56 +0200) References: <20090415202056.GA28448@hydra.ck.polsl.pl> Message-ID: <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> Leo, On Wed, Apr 15, 2009 at 09:02:06AM -0700, Leo Vegoda wrote: > On 15/04/2009 2:34, "Marco Hogewoning" wrote: > > Let's assume you have a seperate entity in your company, which > > operates in a different geographical region under it's own AS and > > routing policy. Only one company (the holding for instance) is an LIR > > in the current situation. > > > > How do you solve this at the moment iin IPv4-land ? > > Good question. Isn't the normal answer to open a separate LIR for the > separate business unit? Your solution, although possible, has some drawbacks: It adds administrative burden, this was discussed here. But it also will diminish the remaining unallocated IPv4 space. I think we can modify your idea slightly. Let's assign 10 'scoring units' for a second and subsequent /32 not fulfilling HD-Ratio. It will effectively move an LIR to a higher billing category. This, plus requirement of seperate routing policy may convince people to support the new policy. Jurek From remco.vanmook at eu.equinix.com Thu Apr 16 10:28:18 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Thu, 16 Apr 2009 10:28:18 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> Message-ID: Dear Jurek, I think you?re still missing the point that some of us are trying to make. I simply don?t think that the proposal is a good way of solving the problem (which is apparently part of a sentence in current policy). Adding a second /32 to the global routing table has just as much impact as splitting up a /32 in 2 /33s so there?s no gain there. And as indicated, filters that are set by people are outside the scope of the address policy WG, and arguably also outside the scope of RIPE policy. Now, if you were to suppose to just take out the offending part of current policy, that would have my undying support. Kind regards, Remco On 16-04-09 10:11, "Jerzy Pawlus" wrote: > > > Leo, > > On Wed, Apr 15, 2009 at 09:02:06AM -0700, Leo Vegoda wrote: >> > On 15/04/2009 2:34, "Marco Hogewoning" wrote: >>> > > Let's assume you have a seperate entity in your company, which >>> > > operates in a different geographical region under it's own AS and >>> > > routing policy. Only one company (the holding for instance) is an LIR >>> > > in the current situation. >>> > > >>> > > How do you solve this at the moment iin IPv4-land ? >> > >> > Good question. Isn't the normal answer to open a separate LIR for the >> > separate business unit? > > > Your solution, although possible, has some drawbacks: > > It adds administrative burden, this was discussed here. > But it also will diminish the remaining unallocated IPv4 space. > > I think we can modify your idea slightly. Let's assign > 10 'scoring units' for a second and subsequent /32 not fulfilling HD-Ratio. > It will effectively move an LIR to a higher billing category. > This, plus requirement of seperate routing policy may convince people > to support the new policy. > > Jurek > > > > 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 sander at steffann.nl Thu Apr 16 10:32:06 2009 From: sander at steffann.nl (Sander Steffann) Date: Thu, 16 Apr 2009 10:32:06 +0200 Subject: [address-policy-wg] Draft Proposal: Assignment of an IPv4 /24 for documentation purposes In-Reply-To: References: <20090415165733.GD13037@x27.adm.denic.de> <374D3C78-B034-463B-8FC2-8F6D477BAB16@steffann.nl> Message-ID: <49E6ED06.7020103@steffann.nl> Hi Geoff, > Perhaps I may be permitted to add some background data here. Ofcourse! Thank you :) > My interpretation of the relative roles of the RIRs, IANA and the IETF > in this area is that such reservations, as distinct from allocations or > assignments, should be performed by the IANA, and for IANA to undertake > this it should be part of the protocol's address plan, and hence should > be published as an RFC. i.e. as far as I understand the situation such > reservations of number resources for documentation purposes falls to > IANA to perform, and the instructions to IANA are in the form of a > published RFC. The logical inference is that such proposals should head > to the IETF rather than the RIRs. I had the same feeling, but it's good to get this background information. Thanks, Sander From gert at space.net Thu Apr 16 10:42:26 2009 From: gert at space.net (Gert Doering) Date: Thu, 16 Apr 2009 10:42:26 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: References: <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> Message-ID: <20090416084226.GU61514@Space.Net> Hi, On Thu, Apr 16, 2009 at 10:28:18AM +0200, Remco van Mook wrote: > I think you?re still missing the point that some of us are trying to make. I > simply don?t think that the proposal is a good way of solving the problem > (which is apparently part of a sentence in current policy). Adding a second > /32 to the global routing table has just as much impact as splitting up a > /32 in 2 /33s so there?s no gain there. Mmmh, it's actually more than this. If you are a large multinational ISP, and run separate networks, these different networks might have completely different addressing needs, and growth rates. So one country network might be perfectly happy with a /35, another might need a /33, and a third one might grow into a /29 over time... Splitting a single /32 into something that has no potential for individual growth is likely to lead to more fragmentation and *more* routes in the medium run. (Of course, some other networks know their size perfectly well, and know that they will not grow much - like a NREN that serves universities that bring their own address space, so the NREN will likely be happy forever with a /48 for their infrastructure... (and *could* use PI for 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 Piotr.Strzyzewski at polsl.pl Thu Apr 16 10:46:12 2009 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Thu, 16 Apr 2009 10:46:12 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: References: <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> Message-ID: <20090416084611.GB19154@hydra.ck.polsl.pl> On Thu, Apr 16, 2009 at 10:28:18AM +0200, Remco van Mook wrote: Hi > I think you?re still missing the point that some of us are trying to make. I > simply don?t think that the proposal is a good way of solving the problem > (which is apparently part of a sentence in current policy). Adding a second > /32 to the global routing table has just as much impact as splitting up a > /32 in 2 /33s so there?s no gain there. And as indicated, filters that are > set by people are outside the scope of the address policy WG, and arguably > also outside the scope of RIPE policy. I don't agree with that. People tend to believe RIPE NCC (which is good). And if RIPE NCC publish in RIPE-447 that the longest prefix is /32, then this is the solid message on which one can easily setup filters with that prefix. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From info at streamservice.nl Thu Apr 16 11:05:38 2009 From: info at streamservice.nl (Stream Service) Date: Thu, 16 Apr 2009 11:05:38 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090416084611.GB19154@hydra.ck.polsl.pl> References: <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> <20090416084611.GB19154@hydra.ck.polsl.pl> Message-ID: <01ed01c9be72$83279b90$8976d2b0$@nl> Hello, -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Piotr Strzyzewski Sent: donderdag 16 april 2009 10:46 To: Remco van Mook Cc: Jerzy Pawlus; leo.vegoda at icann.org; marcoh at marcoh.net; gajda at man.poznan.pl; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) On Thu, Apr 16, 2009 at 10:28:18AM +0200, Remco van Mook wrote: Hi > I think you?re still missing the point that some of us are trying to make. I > simply don?t think that the proposal is a good way of solving the problem > (which is apparently part of a sentence in current policy). Adding a second > /32 to the global routing table has just as much impact as splitting up a > /32 in 2 /33s so there?s no gain there. And as indicated, filters that are > set by people are outside the scope of the address policy WG, and arguably > also outside the scope of RIPE policy. I don't agree with that. People tend to believe RIPE NCC (which is good). And if RIPE NCC publish in RIPE-447 that the longest prefix is /32, then this is the solid message on which one can easily setup filters with that prefix. Piotr =================== And don't forget all the systems that filter based on route objects in the RIR databases. So it should be allowed/possible to create route object for everything with more IPs as a /48 if you ask me. If you are required to aggregate it into 1 /32 if you have PA space there will be filters that check it and require it to be a /32 or refuse it at all. Please note that this requirement is by RIPE policy the case at this moment if I am correct. Just my 0.2 cents. Regards, Mark From gert at space.net Thu Apr 16 11:15:32 2009 From: gert at space.net (Gert Doering) Date: Thu, 16 Apr 2009 11:15:32 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <01ed01c9be72$83279b90$8976d2b0$@nl> References: <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> <20090416084611.GB19154@hydra.ck.polsl.pl> <01ed01c9be72$83279b90$8976d2b0$@nl> Message-ID: <20090416091532.GV61514@Space.Net> Hi, On Thu, Apr 16, 2009 at 11:05:38AM +0200, Stream Service wrote: > And don't forget all the systems that filter based on route objects in the > RIR databases. So it should be allowed/possible to create route object for > everything with more IPs as a /48 if you ask me. This is very well possible. The RIPE database permits route6: objects of any size, as long as they fit into your inet6num: object (so you can't create a /30 route if you only have a /32 inet6num, but you can perfectly well create a /40 route). So, please, get your facts right - heating up the discussion based on incorrect information isn't helping us to figure out how the new policy should look like. 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 brettlists at gmail.com Thu Apr 16 13:34:55 2009 From: brettlists at gmail.com (B C) Date: Thu, 16 Apr 2009 12:34:55 +0100 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <20090415134300.GB13037@x27.adm.denic.de> References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> Message-ID: <5c494b510904160434i40e2971ci3ce76282a9a38497@mail.gmail.com> Peter, thanks for the input much appreciated. On Wed, Apr 15, 2009 at 2:43 PM, Peter Koch wrote: > On Thu, Mar 26, 2009 at 02:05:19PM +0100, Filiz Yilmaz wrote: > >> Anycasting Assignments for TLDs and Tier 0/1 ENUM > >> http://www.ripe.net/ripe/policies/proposals/2008-05.html > > {Full disclosure: DENIC would benefit from the implementation of this proposal.} > > I support the proposal, but I'm still unhappy with parts of the wording: > {only looking at the v4 text, comments apply to the v6 version accordingly} > >>> 6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers >>> >>> Critical DNS infrastructure is defined as infrastructure providing Authoritative >>> TLD or ENUM Tier 0/1 DNS lookup services. > > The term "Critical DNS infrastructure" is defined here just to be referred to > in one single place three paragraphs down. I'd prefer if the term would be > avoided and "Authoritative TLD or ENUM Tier 0/1 DNS lookup services" be > inserted at the appropriate place. > I'm happy to change this if the working group feels it's needed. >>> The organisations applicable under this policy are TLD operators as defined by >>> IANA and ENUM operators as defined by the ITU. The organisation may receive up >>> to four /24 prefixes per TLD/ENUM. These prefixes must be used for the sole > > "TLD operators as defined by IANA" may be a well intended phrase, but many > affected registries would reject being "defined" by IANA. This layer 9 stuff > aside, I'm still uncertain whether the assignment goes to the registry itself > or to some operator who provides name service for TLDs (or ENUM, for that > matter). The former makes more sense to me. "TLD manager/administrator as > described in RFC 1591" might be more acceptable. Well the input from the working group I had received earlier was that the allocation should not necessarily go to either the registry or the DNS operator but to the organisation who has been delegated authority over the namespace from either IANA or ITU, In most cases this is the same organisation but it could be that the IANA/ITU gives responsibility for a Tier1 ENUM to an organisation[1] and they subcontract the registry to one company[2] and public facing DNS to another [3], in this situation my intention was for the allocation to go to [1] I believe the wording as is reflects this, I'm happy to update it but would prefer the allocation still goes to [1] How about "The organisations applicable under this policy are TLD operators as recorded in the IANA's Root Zone Database and ENUM operators as approved and recorded by the ITU". > Similar considerations apply to "ENUM operators as defined by the ITU". > As a side note, ENUM Tier 0 assignments would probably have interactions > with the policy proposal on "Assignments to the NCC". > >>> purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as >>> described in RFC 3258. > > This is a verbatim quote from the current policy documents, but a reference to > BCP126/RFC4786 might be more appropriate these days. This sounds sensible > >>> Assignments for Critical DNS infrastructure are subject to the policies >>> described in the RIPE document entitled "Contractual Requirements for Provider >>> Independent Resource Holders in the RIPE NCC Service Region". >>> >>> Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in >>> the RIPE Database and must be returned to the RIPE NCC if not in use for >>> Critical DNS infrastructure any longer. > > OK, 2nd occurence, but s/Critical DNS infrastructure/the purpose justifying the > assignment/. > Thanks for the comments, Some credit should also go to Leo Vegoda for some input, thanks Leo. Brett From randy at psg.com Thu Apr 16 14:00:36 2009 From: randy at psg.com (Randy Bush) Date: Thu, 16 Apr 2009 21:00:36 +0900 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <5c494b510904160434i40e2971ci3ce76282a9a38497@mail.gmail.com> References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> <5c494b510904160434i40e2971ci3ce76282a9a38497@mail.gmail.com> Message-ID: >> The term "Critical DNS infrastructure" is defined here just to be referred to >> in one single place three paragraphs down. I'd prefer if the term would be >> avoided and "Authoritative TLD or ENUM Tier 0/1 DNS lookup services" be >> inserted at the appropriate place. > I'm happy to change this if the working group feels it's needed. i like "critical infrastructre." this is because, while i understand that the roots need golden space, and i can almost see that anycasted services need micro-allocations, i do not feel that tlds per se are critical in the sense that they need golden space. there is a reason the dns maps from names to addresses. use it. randy From michael.dillon at bt.com Thu Apr 16 14:23:51 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 16 Apr 2009 13:23:51 +0100 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904151443.n3FEh4kg001821@nc.cyf-kr.edu.pl> Message-ID: <28E139F46D45AF49A31950F88C497458A15DD1@E03MVZ2-UKDY.domain1.systemhost.net> > Can anybody (maybe from a RIPE staff) give a number of LIR's with > more than one AS assigned? This can give us a rough estimate. There are also companies like us who have a dozen or more LIR's. Some of those LIRs might only have one AS. It's not necessarily easy for RIPE or anyone else to figure out which LIRs belong to the same organization. It is risky to make assumptions based on trawling the RIPE database because it is: a) a warped and incomplete view b) historical information We don't really know how closely IPv6 networks will resemble IPv4 networks. Of course, many organizations will come up with some network transition plan that mirrors their IPv4 networks onto IPv6, but there will also be innovators who do something completely different. When other organizations begin to copy the innovators, it is a whole new environment. IPv6 makes it much easier to create push-type services like phone-ringing and it is hard to predict the impact of such services. For example, the simply ability to make a telephone ring in your house, created a huge increase in demand for telephones, far beyond the demand created by merely transmitting sound over the wire. Many of the original telephone services faded away completely, once phone-ringing was invented, and nowadays, the only people who know about services other than telephone calls, are the people who read books on telephone history. RIPE policy on IPv6 needs to avoid being restrictive, and if we have accidentally made the policy restrictive, or if too many people mistakenly interpret the policy as being restrictive, then we need to change it. --Michael Dillon From pk at DENIC.DE Thu Apr 16 16:04:44 2009 From: pk at DENIC.DE (Peter Koch) Date: Thu, 16 Apr 2009 16:04:44 +0200 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> <5c494b510904160434i40e2971ci3ce76282a9a38497@mail.gmail.com> Message-ID: <20090416140444.GI11589@unknown.office.denic.de> On Thu, Apr 16, 2009 at 09:00:36PM +0900, Randy Bush wrote: > i like "critical infrastructre." this is because, while i understand > that the roots need golden space, and i can almost see that anycasted > services need micro-allocations, i do not feel that tlds per se are > critical in the sense that they need golden space. that would suggest an external reference to the term and other evaluation criteria than those proposed. Also, could you elaborate on the difference between "micro-allocations" and "golden space"? > there is a reason the dns maps from names to addresses. use it. Sure, we use anycast to support performant and resilient mapping. -Peter From leo.vegoda at icann.org Thu Apr 16 16:12:24 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 16 Apr 2009 07:12:24 -0700 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> Message-ID: Hi Jerzy, On 16/04/2009 1:11, "Jerzy Pawlus" wrote: [...] >>> How do you solve this at the moment iin IPv4-land ? >> >> Good question. Isn't the normal answer to open a separate LIR for the >> separate business unit? > > Your solution, although possible, has some drawbacks: > > It adds administrative burden, this was discussed here. True. I think that administrative burden would act as a restraint against unnecessary additional allocations. > But it also will diminish the remaining unallocated IPv4 space. How does it do that at a different rate than not opening a new LIR? While I understand that the proposal requires a one-to-one relationship between IPv4 and IPv6 networks, my reading of the text was that the requirement was there to ensure that a separate IPv6 network was required. If someone has opened a new LIR then I suspect that separate test is not required. > I think we can modify your idea slightly. Let's assign > 10 'scoring units' for a second and subsequent /32 not fulfilling HD-Ratio. > It will effectively move an LIR to a higher billing category. > This, plus requirement of seperate routing policy may convince people > to support the new policy. While I agree that this proposal could have a negative financial impact on the RIPE NCC I don't believe that we can change the charging scheme through the policy development process. Finally, if a network running an LIR closes the address space will naturally be reclaimed after the RIPE NCC's due diligence process. This proposal seems to put a burden on an LIR to remember to return space once it is not being used. Experience suggests that resources get lost as people move around between departments and companies. If the general concept is accepted I think a strong regular review mechanism is required to ensure that we don't leave a mess of unmanaged resources lying around in the RIPE database. Regards, Leo From marcoh at marcoh.net Thu Apr 16 16:18:34 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 16 Apr 2009 16:18:34 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> References: <20090415202056.GA28448@hydra.ck.polsl.pl> <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> Message-ID: On 16 apr 2009, at 10:11, Jerzy Pawlus wrote: > I think we can modify your idea slightly. Let's assign > 10 'scoring units' for a second and subsequent /32 not fulfilling > HD-Ratio. > It will effectively move an LIR to a higher billing category. Let's not do that, as it would simply reduce the whole policy to you get as much addresses as you can afford instead of you get the addresses you need. Skipping HD-ratio in favor of scoring units is bad, very bad. Groet, MarcoH From Piotr.Strzyzewski at polsl.pl Thu Apr 16 16:23:19 2009 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Thu, 16 Apr 2009 16:23:19 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: References: <20090415202056.GA28448@hydra.ck.polsl.pl> <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> Message-ID: <20090416142319.GA12916@hydra.ck.polsl.pl> On Thu, Apr 16, 2009 at 04:18:34PM +0200, Marco Hogewoning wrote: > On 16 apr 2009, at 10:11, Jerzy Pawlus wrote: > > I think we can modify your idea slightly. Let's assign > > 10 'scoring units' for a second and subsequent /32 not fulfilling > >HD-Ratio. > > It will effectively move an LIR to a higher billing category. > > Let's not do that, as it would simply reduce the whole policy to you > get as much addresses as you can afford instead of you get the > addresses you need. Skipping HD-ratio in favor of scoring units is > bad, very bad. Which is what we have right now. Setup new (another) LIR (money). Get allocation. Merge LIRs (or not). Which is: "you get as much address as you can afford". Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From marcoh at marcoh.net Thu Apr 16 16:33:10 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 16 Apr 2009 16:33:10 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090416142319.GA12916@hydra.ck.polsl.pl> References: <20090415202056.GA28448@hydra.ck.polsl.pl> <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> <20090416142319.GA12916@hydra.ck.polsl.pl> Message-ID: <8FA135DF-F3AF-43F1-A730-6E3ED7A070E7@marcoh.net> On 16 apr 2009, at 16:23, Piotr Strzyzewski wrote: > On Thu, Apr 16, 2009 at 04:18:34PM +0200, Marco Hogewoning wrote: >> On 16 apr 2009, at 10:11, Jerzy Pawlus wrote: >>> I think we can modify your idea slightly. Let's assign >>> 10 'scoring units' for a second and subsequent /32 not fulfilling >>> HD-Ratio. >>> It will effectively move an LIR to a higher billing category. >> >> Let's not do that, as it would simply reduce the whole policy to you >> get as much addresses as you can afford instead of you get the >> addresses you need. Skipping HD-ratio in favor of scoring units is >> bad, very bad. > > Which is what we have right now. Setup new (another) LIR (money). Get > allocation. Merge LIRs (or not). Which is: "you get as much address > as > you can afford". In which case HD-ratio will apply, or at least I assume RIPE-301, 2.6 would equally apply to IPv6 as it does to IPv4. Groet, MarcoH (trimmed the CC a bit to avoid duplicates) From ondrej.sury at nic.cz Thu Apr 16 17:21:15 2009 From: ondrej.sury at nic.cz (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Thu, 16 Apr 2009 17:21:15 +0200 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <20090415134300.GB13037@x27.adm.denic.de> References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> Message-ID: Peter, On Wed, Apr 15, 2009 at 3:43 PM, Peter Koch wrote: >>> 6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers >>> >>> Critical DNS infrastructure is defined as infrastructure providing Authoritative >>> TLD or ENUM Tier 0/1 DNS lookup services. > > The term "Critical DNS infrastructure" is defined here just to be referred to > in one single place three paragraphs down. ?I'd prefer if the term would be > avoided and "Authoritative TLD or ENUM Tier 0/1 DNS lookup services" be > inserted at the appropriate place. We could probably change this, but I think that the reasoning behind this definition was not only to use it as reference, but also to say that these DNS servers are different - all other domain names depend on them. >>> The organisations applicable under this policy are TLD operators as defined by >>> IANA and ENUM operators as defined by the ITU. The organisation may receive up >>> to four /24 prefixes per TLD/ENUM. These prefixes must be used for the sole > > "TLD operators as defined by IANA" may be a well intended phrase, but many > affected registries would reject being "defined" by IANA. ?This layer 9 stuff > aside, I'm still uncertain whether the assignment goes to the registry itself > or to some operator who provides name service for TLDs (or ENUM, for that > matter). ?The former makes more sense to me. "TLD manager/administrator as > described in RFC 1591" might be more acceptable. I did some reading on IANA website and maybe the problem is that each of us imagine different thing under "defined by IANA" since I didn't find anything like this on IANA website. Since RFC 1591 and ICP-1 uses term 'designated manager' and other IANA documents speaks about "(re)delegation" would: "designated manager for TLD as delegated by IANA" be OK > Similar considerations apply to "ENUM operators as defined by the ITU". > As a side note, ENUM Tier 0 assignments would probably have interactions > with the policy proposal on "Assignments to the NCC". ITU documents use these terms: 3.2.1 administrator: The organization entrusted with the administration of a resource derived from an international numbering plan. 3.2.2 assignee: The applicant to whom E-series international numbering resources have been assigned. 3.2.3 assignment: The process for providing an international numbering resource to an eligible applicant. 3.2.4 country: A specific country, a group of countries in an integrated numbering plan or a specific geographical area. so is "ENUM administrator as assigned by the ITU" more appropriate? Ondrej -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From Piotr.Strzyzewski at polsl.pl Thu Apr 16 18:07:41 2009 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Thu, 16 Apr 2009 18:07:41 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <8FA135DF-F3AF-43F1-A730-6E3ED7A070E7@marcoh.net> References: <20090415202056.GA28448@hydra.ck.polsl.pl> <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> <20090416142319.GA12916@hydra.ck.polsl.pl> <8FA135DF-F3AF-43F1-A730-6E3ED7A070E7@marcoh.net> Message-ID: <20090416160741.GB12916@hydra.ck.polsl.pl> On Thu, Apr 16, 2009 at 04:33:10PM +0200, Marco Hogewoning wrote: > In which case HD-ratio will apply, or at least I assume RIPE-301, 2.6 > would equally apply to IPv6 as it does to IPv4. First of all, one doesn't have to close/merge LIR if "can afford" it. Moreover, existing LIR can (there is simplification here): 1. setup new LIR (withing the same organization; for example in another country, part of country, with different funds, etc.), 2. send RIPE-425 form, 3. obtain another allocation (probably /32). I assume, that in most cases this first IPv6 allocation is more than enough and HD-ratio in this scenario is not used. Note that there are organizations which (ab)use the current policy using that method just to obtain another "initial" allocation and this is exactly "you get as much address as you can afford" which is not a good policy. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From pk at DENIC.DE Thu Apr 16 18:41:18 2009 From: pk at DENIC.DE (Peter Koch) Date: Thu, 16 Apr 2009 18:41:18 +0200 Subject: [address-policy-wg] Draft Proposal: Assignment of an IPv4 /24 for documentation purposes In-Reply-To: <20090415165733.GD13037@x27.adm.denic.de> References: <20090415165733.GD13037@x27.adm.denic.de> Message-ID: <20090416164118.GA12461@unknown.office.denic.de> Dear WG, > Summary: > The RIPE NCC is asked to assign an IPv4 /24 for documentation purposes. thanks for all the questions and comments. It seems that several people share the need but the current wisdom suggests that a formal policy proposal is not necessary right now. In responding to the original message I'll try to address the questions in a single message. Apologies for anyone I missed. Basicly, two questions came up: 1) Why not use RFC 1918 space for documentation purpose? 2) Why not address this through IANA/IETF (or: why RIPE [NCC])? An attempt to address the first question was already in the proposal, > Sometimes, address space from RFC 1918 (BCP 5) is used in addition to > or as a replacement for 192.0.2/24, but this is also a source of > confusion due to the special nature of the "private address space". > It also conflicts with the goal to avoid any collision with addresses > used in real life, even if the burden would be spread across many > users of RFC 1918 address space. but the feedback suggests some additional explanation could help in whatever document will describe additional documentation prefixes. Also, the awareness of these special reservations could be raised (and I missed RFC 5398 as a reference myself). The second question or bundle of questions deserves more thought: o Why do this in the RIPE region? There's nothing special, any of the five RIRs would do, it's just that this region is the one I had easiest "access" to. As Geoff mentioned (see below), the IPv6 and ASN examples have resulted from similar initiatives in the APNIC region. o Isn't this something for the IETF or IANA to do? Geoff was kind enough to provide detailed background: > This topic has surfaced in the past in the case of IPv6 addresses and > AS numbers. > > In the case of IPv6 the original APNIC proposal was rephrased as an > RFC and the IANA documented the reservation in the IPv6 address > registry on the basis of the published RFC. > > In the case of AS numbers there was a policy proposal in APNIC whose > implementation was abandoned following the publication of an RFC that > requested IANA to perform the registration. > > My interpretation of the relative roles of the RIRs, IANA and the IETF > in this area is that such reservations, as distinct from allocations > or assignments, should be performed by the IANA, and for IANA to > undertake this it should be part of the protocol's address plan, and > hence should be published as an RFC. i.e. as far as I understand the > situation such reservations of number resources for documentation > purposes falls to IANA to perform, and the instructions to IANA are in > the form of a published RFC. The logical inference is that such > proposals should head to the IETF rather than the RIRs. and I'm foolish enough to argue the following: Once the addresses (or number resources) are instantiated and handed over to IANA for distribution (maintenance) through the RIRs, they are out of the hands of the IETF but subject to the applicable policies set in the respective regions. When an addressing (or numbering) plan is designed from scratch, a special range can be set aside as "protocol elements" rather than number resources and subsequently be reserved or dedicated for the purpose intended here (and others). But this time is long since gone for IPv4. {192.0.2/24 appears in an "Assigned Numbers" or "Internet Numbers" RFC the first time around March 1987: RFC 997, was UNASSIGNED in RFC 990.} So, my reading is that the IETF has no such addresses at its disposal (in contrast to, say, 240/4, not yet dedicated). Now, the IETF can ask IANA (in a different role) to assign these prefixes, but where would IANA get these? As the IPv6 example quoted above shows, there's little else than go asking the RIRs to "hand back" the requested assignment (or reservation). Fine, but under what criteria (read: policy) would an RIR satisfy this request? Back to square one. Meanwhile I have been very kindly enlightened off-list that things are already progressing (the source may or may not choose to elaborate here), so I'm convinced that no further action on this draft proposal is necessary. Thanks for all the responses, Peter From mohsen.souissi at nic.fr Thu Apr 16 18:45:19 2009 From: mohsen.souissi at nic.fr (Mohsen Souissi) Date: Thu, 16 Apr 2009 18:45:19 +0200 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <20090416140444.GI11589@unknown.office.denic.de> References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> <5c494b510904160434i40e2971ci3ce76282a9a38497@mail.gmail.com> <20090416140444.GI11589@unknown.office.denic.de> Message-ID: <20090416164519.GB95849@kerkenna.nic.fr> Hi all, 1) I fully support this policy to move forward. As a matter of fact, AFNIC is preparing an in-house Anycast solution, to be deployed soon for a first group of nodes. Later, we intend to deploy other groups and we will then need to rely on this policy to ask for extra Prefixes. Btw, for our two other running Anycast groups, our choice is a priori to let the Anycast operator ask for address resources they need (a way to mutualize those resources among their customers, thus less address consumption globally). 2) I don't have a strong opinion on using or not "Critical infrastructure expression. Nonetheless, I would prefer we rather avoid that expression in this kind of document (I know it's too late for DNS Root Servers). This might be interpreted by some publicauthorities as an elevation of the TLDs DNS service to a rank of other well-known "Critical infrastructures" like Water or Electricity. I'm not sure we have reached that level of criticity equivalence today, nor am I sure that TLD operators want to spread this perception nowadays. Instead, maybe something less "loaded/exposing" such as "Key/Essential service/infrastructure" (choose a combination as you like) would be more appropriate for this document. Cheers, Mohsen. On 16 Apr, Peter Koch wrote: | On Thu, Apr 16, 2009 at 09:00:36PM +0900, Randy Bush wrote: | | > i like "critical infrastructre." this is because, while i understand | > that the roots need golden space, and i can almost see that anycasted | > services need micro-allocations, i do not feel that tlds per se are | > critical in the sense that they need golden space. | | that would suggest an external reference to the term and other evaluation | criteria than those proposed. Also, could you elaborate on the difference | between "micro-allocations" and "golden space"? | | > there is a reason the dns maps from names to addresses. use it. | | Sure, we use anycast to support performant and resilient mapping. | | -Peter -- -- //===================================================================\\ | Mohsen Souissi | | AFNIC - Responsable R&D | | Mohsen.Souissi at nic.fr | T?l./Fax : 01 39 30 83 40 / 01 39 30 83 01 | \\===================================================================// From marcoh at marcoh.net Thu Apr 16 21:01:49 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 16 Apr 2009 21:01:49 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090416160741.GB12916@hydra.ck.polsl.pl> References: <20090415202056.GA28448@hydra.ck.polsl.pl> <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> <20090416142319.GA12916@hydra.ck.polsl.pl> <8FA135DF-F3AF-43F1-A730-6E3ED7A070E7@marcoh.net> <20090416160741.GB12916@hydra.ck.polsl.pl> Message-ID: On Apr 16, 2009, at 6:07 PM, Piotr Strzyzewski wrote: > On Thu, Apr 16, 2009 at 04:33:10PM +0200, Marco Hogewoning wrote: >> In which case HD-ratio will apply, or at least I assume RIPE-301, 2.6 >> would equally apply to IPv6 as it does to IPv4. > > First of all, one doesn't have to close/merge LIR if "can afford" it. > Moreover, existing LIR can (there is simplification here): > 1. setup new LIR (withing the same organization; for example in > another > country, part of country, with different funds, etc.), > 2. send RIPE-425 form, > 3. obtain another allocation (probably /32). > I assume, that in most cases this first IPv6 allocation is more than > enough and HD-ratio in this scenario is not used. > Note that there are organizations which (ab)use the current policy > using > that method just to obtain another "initial" allocation and this is > exactly "you get as much address as you can afford" which is not a > good > policy. Then maybe this is another hole that needs plugging, but I think we have to realise that we problem won't solve all of the world's problems right here and now. As Leo already suggested, opening up a new LIR will introduce some burden in the form of costs and overhead which will probably make people think twice about what they are doing and wether or not it is absolutely neccessary. Further that new LIR has to comply with the normal procedures and policies, which makes me think that this might help to achieve goals like fairness, registration and traceabillity. So yes, I understand your problem and I'm happy to voice my support for a proposal to solve it, as long as it is a good one and IMHO this isn't such a proposal. In the past few days various other solutions have been posted: - Open a second LIR - Use PI (in the works) - sub-allocated from the initial /32 (Like RIPE-449 allows for IPv4) And in fact we can even start a debate wether or not the current document (RIPE-450), although stating you MUST announce the allocated prefix as a whole, forbids you from deaggregating and announcing more specifics for that allocation as well. And yes this will put some additional strain on the routing table and create some extra BGP noise, but the same applies for the original concept of allocating an additional /32. The other big objections I read are concerning the filters. Routabillity of address blocks (any address block) is as always not guarenteed and routing policy for individual networks is way out of scope for this WG or the RIPE NCC as a whole. Maybe you should follow up to the IETF and draft a BCP on IPv6 route filtering, otherwise I guess the market will eventually solve it, if it turns out to really be a problem, and alter the filters. In the meantime the original proposal slipped into one where HD-ratio is being traded for scoring points. Call me old-fashioned, conservative or other, but I think that, although IPv6 'provides enough address space to last us a lifetime', we should still keep those old values like address space conservation and a fair and level playing field to distribute them in mind when creating or applying policies. To me a large part of what you are saying, in v4 land can would be put under 'administrative ease' which by RIPE-449 is not a valid reason for assignment and I personally don't see reasons to allow it for IPv6 even when it's not explicitly stated in the policy document. If somebody wants to rewrite this proposal, taking the comments made on this list into account or if you want to draft a new one, seeking another solution for this problem, I'm happy to help and make some time available. As it currently stands I cannot voice support for this proposal and it's very unlikely that this will happen in the future, unless changes are made. Greetings, MarcoH From randy at psg.com Fri Apr 17 00:36:14 2009 From: randy at psg.com (Randy Bush) Date: Fri, 17 Apr 2009 07:36:14 +0900 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <20090416140444.GI11589@unknown.office.denic.de> References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> <5c494b510904160434i40e2971ci3ce76282a9a38497@mail.gmail.com> <20090416140444.GI11589@unknown.office.denic.de> Message-ID: >> i like "critical infrastructre." this is because, while i understand >> that the roots need golden space, and i can almost see that anycasted >> services need micro-allocations, i do not feel that tlds per se are >> critical in the sense that they need golden space. > that would suggest an external reference to the term and other evaluation > criteria than those proposed. > Also, could you elaborate on the difference between > "micro-allocations" and "golden space"? the use case for micro-allocation that ws used in arin, until cathy started screaming at me, was cnn. >> there is a reason the dns maps from names to addresses. use it. > Sure, we use anycast to support performant and resilient mapping. i have sympathy for the anycast need. i do not have sympathy for non-anycast tds, and i run a number of them. randy From randy at psg.com Fri Apr 17 00:58:47 2009 From: randy at psg.com (Randy Bush) Date: Fri, 17 Apr 2009 07:58:47 +0900 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> Message-ID: > We could probably change this, but I think that the reasoning behind this > definition was not only to use it as reference, but also to say that these > DNS servers are different - all other domain names depend on them. ahh, you meant the root servers. indeed, as one can not look them up using a resilient dymanic protocol, they ar eunique. the rest, try using the dns. randy From brettlists at gmail.com Fri Apr 17 10:54:35 2009 From: brettlists at gmail.com (B C) Date: Fri, 17 Apr 2009 09:54:35 +0100 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> Message-ID: <5c494b510904170154y7748fd83rf5ce09ed2e0e21@mail.gmail.com> Thanks for the commets all, Ondrej and myself are in the process of tweaking the proposal to take these into consideration. We hope to publish a new version when the current review period ends and in advance of RIPE 58. Brett Carr Nominet. From Jerzy.Pawlus at cyf-kr.edu.pl Fri Apr 17 11:42:21 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Fri, 17 Apr 2009 11:42:21 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: (message from Marco Hogewoning on Thu, 16 Apr 2009 21:01:49 +0200) References: <20090415202056.GA28448@hydra.ck.polsl.pl> <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> <20090416142319.GA12916@hydra.ck.polsl.pl> <8FA135DF-F3AF-43F1-A730-6E3ED7A070E7@marcoh.net> <20090416160741.GB12916@hydra.ck.polsl.pl> Message-ID: <200904170942.n3H9gL69000355@nc.cyf-kr.edu.pl> Marco wrote: [...] > > As Leo already suggested, opening up a new LIR will introduce some > burden in the form of costs and overhead which will probably make > people think twice about what they are doing and wether or not it is > absolutely neccessary. > I can assure you that the burden of opening up a new LIR is nothing in comparison to maintaining a seperate routing policy up to the client. It costs additional money and an expertise and nobody sane will willingly do it. So raising up this as an argument that it will stop people from opening up a new LIR is probably meaningless. ---- I only state that the current RIPE policy will not stand. Either the 5.1.1 shall be removed or 5.2.1 modified. The policy, in my opinion, is and was in the past more restrictive than equivalent IPv4 policy. Lets just recall 200 clients rule or lack of IPv6 PI space. In its current form it is harmful to IPv6 deployment. So far we have seen only two groups interested in changing it, but the others will follow when they try to bring IPv6 into production. In it simplest: Under current policy some LIRs cannot offer the same set of services they used to offer in IPv4, and IPv6 was supposed to offer new oportunities. ---- [...] > The other big objections I read are concerning the > filters. Routabillity of address blocks (any address block) is as > always not guarenteed and routing policy for individual networks is > way out of scope for this WG or the RIPE NCC as a whole. Maybe you > should follow up to the IETF and draft a BCP on IPv6 route filtering, > otherwise I guess the market will eventually solve it, if it turns out > to really be a problem, and alter the filters. > But we also cannot create a policy for policy itself. It must respect a real life scenario too. Of course "Routabillity of address blocks (any address block) is as always not guarenteed" but as practise shows most "legally" obtained legacy prefixes are still routable and special rules for some IPv4 ranges are generally accepted. I am afraid you can't say the same for a more specific /32 PA prefix. [...] > To me a large part of what you are saying, in v4 land can would be put > under 'administrative ease' which by RIPE-449 is not a valid reason > for assignment and I personally don't see reasons to allow it for IPv6 > even when it's not explicitly stated in the policy document. > It is not 'administrative ease'. It is be or not to be. Regards, Jurek From marcoh at marcoh.net Fri Apr 17 11:54:55 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 17 Apr 2009 11:54:55 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904170942.n3H9gL69000355@nc.cyf-kr.edu.pl> References: <20090415202056.GA28448@hydra.ck.polsl.pl> <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> <20090416142319.GA12916@hydra.ck.polsl.pl> <8FA135DF-F3AF-43F1-A730-6E3ED7A070E7@marcoh.net> <20090416160741.GB12916@hydra.ck.polsl.pl> <200904170942.n3H9gL69000355@nc.cyf-kr.edu.pl> Message-ID: On 17 apr 2009, at 11:42, Jerzy Pawlus wrote: > ---- > I only state that the current RIPE policy will not stand. Either the > 5.1.1 shall be removed or 5.2.1 modified. > The policy, in my opinion, is and was in the past more restrictive > than equivalent IPv4 policy. Lets just recall 200 clients rule or > lack > of IPv6 PI space. I find it less restrictive, administrative ease is allowed and you'll always get a /32. > In its current form it is harmful to IPv6 deployment. So far we > have seen > only two groups interested in changing it, but the others will follow > when they try to bring IPv6 into production. Please stop this nonsense, you find a ton of reasons why IPv6 isn't deployed and I don't see proof that changing the policy actually caused an increase in IPv6 addoption. Surely somebody probably got himself a /32, which by now is gathering dust somewhere being bound to null0. > In it simplest: Under current policy some LIRs cannot offer the > same set > of services they used to offer in IPv4, and IPv6 was supposed to > offer > new oportunities. > Yes agian, we here you....it's not the problem that is bothering me, it's the proposed solution. >> The other big objections I read are concerning the >> filters. Routabillity of address blocks (any address block) is as >> always not guarenteed and routing policy for individual networks is >> way out of scope for this WG or the RIPE NCC as a whole. Maybe you >> should follow up to the IETF and draft a BCP on IPv6 route filtering, >> otherwise I guess the market will eventually solve it, if it turns >> out >> to really be a problem, and alter the filters. > > But we also cannot create a policy for policy itself. It must respect > a real life scenario too. > Of course "Routabillity of address blocks (any address block) is as > always > not guarenteed" but as practise shows most "legally" obtained > legacy prefixes > are still routable and special rules for some IPv4 ranges are > generally > accepted. I am afraid you can't say the same for a more specific > /32 PA prefix. I have had to lower my filters in the past a few times after complaints from customers and I guess I'm not the only one, at the same time I have had boxes which not even accepted /24 as a general rule because of memory shortage. That's what I meant by 'let the market do it's work'. > > [...] > >> To me a large part of what you are saying, in v4 land can would be >> put >> under 'administrative ease' which by RIPE-449 is not a valid reason >> for assignment and I personally don't see reasons to allow it for >> IPv6 >> even when it's not explicitly stated in the policy document. >> > > > It is not 'administrative ease'. It is be or not to be. We'll I've been running networks in the same situation, one company with 2 policies and 2 ASns which from time to time didn't touch eachother and I'm still here :) Groet, MarcoH From drueegg at emea.att.com Fri Apr 17 12:01:44 2009 From: drueegg at emea.att.com (Rueegg, Daniel) Date: Fri, 17 Apr 2009 12:01:44 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: References: <20090415202056.GA28448@hydra.ck.polsl.pl> <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> <20090416142319.GA12916@hydra.ck.polsl.pl> <8FA135DF-F3AF-43F1-A730-6E3ED7A070E7@marcoh.net> <20090416160741.GB12916@hydra.ck.polsl.pl> Message-ID: It is really amazing how many unqualified comments I saw on this during the last couple of days. Seems that a lot of people on this list just see an incredible small slice of the net and believe they see the whole internet. Good luck to all those which plan to use PI space for their services and also to all those which believe they can get an IPv6 PA smaller /32 routed through all T1 ISPs. You'll sooner or later face some serious problems in the IPv6 world (if you even participate in that at all). Anyway, for me it does not matter whether this proposal gets through or not. We have a workaround and that covers us for the coming years. - I wanted to prevent others from being forced the same ugly road too but I leave it to those ISPs to get that process/rules fixed when they face the problem. I'll remove my self from this list. Dani Rueegg From Jerzy.Pawlus at cyf-kr.edu.pl Fri Apr 17 12:28:57 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Fri, 17 Apr 2009 12:28:57 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: (message from Marco Hogewoning on Fri, 17 Apr 2009 11:54:55 +0200) References: <20090415202056.GA28448@hydra.ck.polsl.pl> <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> <20090416142319.GA12916@hydra.ck.polsl.pl> <8FA135DF-F3AF-43F1-A730-6E3ED7A070E7@marcoh.net> <20090416160741.GB12916@hydra.ck.polsl.pl> <200904170942.n3H9gL69000355@nc.cyf-kr.edu.pl> Message-ID: <200904171028.n3HASvuA012287@nc.cyf-kr.edu.pl> Marco wrote: [...] > > I find it less restrictive, administrative ease is allowed and you'll > always get a /32. > As you will always get a minimum allocation slot for IPv4. So you can't say it is less restrictive. The problem with /32 is that it is too big and 99% of LIR's will never approach to HD-Ratio. So in the future IPv6 table you will have a few thousand of PA prefixes and possible ten's of thousand PI prefixes. Certainly we can spare a few hundred additional PA prefixes for the new policy. Regards, Jurek From rhe at nosc.ja.net Fri Apr 17 13:32:59 2009 From: rhe at nosc.ja.net (Rob Evans) Date: Fri, 17 Apr 2009 12:32:59 +0100 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904171028.n3HASvuA012287@nc.cyf-kr.edu.pl> References: <20090415202056.GA28448@hydra.ck.polsl.pl> <200904160811.n3G8BpH5012601@nc.cyf-kr.edu.pl> <20090416142319.GA12916@hydra.ck.polsl.pl> <8FA135DF-F3AF-43F1-A730-6E3ED7A070E7@marcoh.net> <20090416160741.GB12916@hydra.ck.polsl.pl> <200904170942.n3H9gL69000355@nc.cyf-kr.edu.pl> <200904171028.n3HASvuA012287@nc.cyf-kr.edu.pl> Message-ID: <49E868EB.8070400@nosc.ja.net> > The problem with /32 is that it is too big and 99% of LIR's will never > approach to HD-Ratio. So in the future IPv6 table you will have > a few thousand of PA prefixes and possible ten's of thousand PI prefixes. > Certainly we can spare a few hundred additional PA prefixes for > the new policy. If a /32 is 'too big,' then I am yet to be convinced that more of them in the routing table is the answer as opposed to /33s, /34s, /35s or /36s. Maybe I'm just not 'thinking IPv6.' Filtering guidelines change. Just because a /32 is what people filter on at the moment, it doesn't mean that is the way it should remain. 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 Jerzy.Pawlus at cyf-kr.edu.pl Fri Apr 17 15:27:11 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Fri, 17 Apr 2009 15:27:11 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090415135141.GN61514@Space.Net> (message from Gert Doering on Wed, 15 Apr 2009 15:51:41 +0200) References: <20090414125740.9D52C2F583@herring.ripe.net> <20090415135141.GN61514@Space.Net> Message-ID: <200904171327.n3HDRBit029066@nc.cyf-kr.edu.pl> Gert wrote: > > So I think this discussion should move towards: > > - find examples of networks that have problems with the current policy, > and try to figure out common criteria > Gert, I don't think that at the moment we can find more examples other than you mentioned in your letter, ie. Telcos and NREN networks. To some extent it understandable. Big ISP need more time to prepare themselves, especially in the access area. NREN networks tend to see problems rather sooner than later. Others will follow as Dami said "when they face the problem". On the other hand the interest in and discussion on this matter is surpisingly small. > > - formulate criteria for "additional allocations" that can get > (rough) consensus > As you clearly stated in one of your letters it almost impossible to apply HD-Ratio to a big ISP. To succesfully run such a business you must assume some hierarchy in addressing scheme. Any hierarchy leads to address waste anf if you stick to this you will never reach HD-Ratio. This is a 'real life' If not to big ISP where else we can apply HD-ratio? Other LIRs will never reach it. The conclusion is rather surpising. We can silently drop HD-Ratio criteria and nothing wrong will happen. In IPv6 world HD-Ratio seems not to work as well as in IPv4 The only criteria which is meaningfull to me is: "The routing reason" whatever it means. Maybe we can leave it to the hostmaster staff to decide whether subsequent allocations are justifiable. They earned our trust. For the beginning they can apply this to those LIR's which already use separate routing polices in IPv4 world. > > - re-word the policy proposal accordingly > We can have something like this: --- 5.2.1. Subsequent allocation criteria: a) An LIR may request an additional minimum allocation size for a second and subsequent separate routing policy. b) Subsequent allocation will be provided when an organisation (i.e. ISP/LIR) satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments. The HD-Ratio [RFC 3194] is used to determine the utilisation thresholds that justify the allocation of additional address as described below. --- We can leave point b) in a case somebody reaches the HD-Ratio :) The policy does not have to be perfect. It was changed several times and it will be changed again. At worst we will end up with a few fundered additional IPv6 prefixes which is insignificant to what we have in IPv4 now. Kind regards, Jurek From jim at rfc1035.com Fri Apr 17 15:34:29 2009 From: jim at rfc1035.com (Jim Reid) Date: Fri, 17 Apr 2009 14:34:29 +0100 Subject: [address-policy-wg] Anycast assignments for ENUM/TLD registries In-Reply-To: <20090415134300.GB13037@x27.adm.denic.de> References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> Message-ID: <0482053B-8063-405E-9366-B2B723F7BCFC@rfc1035.com> Apologies for providing a meaningful Subject: header. :-) On Apr 15, 2009, at 14:43, Peter Koch wrote: > "TLD operators as defined by IANA" may be a well intended phrase, > but many > affected registries would reject being "defined" by IANA. Peter, I feel you're being overly picky here. If an organisation doesn't like the wording of some policy then they are of course free to choose not to enjoy the benefits of that policy. Better still, they could suggest text that makes them feel more comfortable. :-) I think the wording Ondrej has proposed should provide that level of comfort. I'm ultimately guilty of the insertion of "as defined by IANA". The intent here was to come up with a policy that would allow anycast assignments to real TLD registries (ie those in the IANA database) rather than for whatever gunk lies in so-called alternate roots and so forth. The same goes for the ENUM Tier-1 registries, though in this case it's ITU and not IANA that has the definitive database for that. Again, the intent here was to have policy wording that would prevent charlatans setting up bogus-e164.com (or whatever) and then come to NCC claiming an entitlement of 200 or so Tier-1 "country code" anycast assignments: ie essentially having alternate roots in a slightly different guise. In an earlier discussion about this draft I contributed text containing the URLs for the IANA and ITU databases. This was considered a Bad Idea because these links could change. So that's what provoked the "as defined by" revision in the next iteration of the document. > This layer 9 stuff > aside, I'm still uncertain whether the assignment goes to the > registry itself > or to some operator who provides name service for TLDs (or ENUM, for > that > matter). The former makes more sense to me. I am still not certain the latest draft resolves this confusion either. I strongly believe that the assignment should go to the registry and not the provider of registry or DNS services for that registry. Even if these are the same entity, their roles and their responsibilities are different. On a practical level, the TLD or Tier-1 administrator might want to split their anycast assignment between DNS providers: say discrete /24s to each of them. This wouldn't be easy to do (or change) if that anycast assignment was held by their registry operator. And suppose the registry has a serious disagreement its registry operator or the back-end provider changes when the contract goes out to tender. > "TLD manager/administrator as described in RFC 1591" might be more > acceptable. IMO the language that needs to be use here has somehow to be linked to the TLD managers that are known to the IANA database. RFC 1591 seems too fuzzy and very out of date. The excellent text Ondrej suggested -- "designated manager for TLD as delegated by IANA" -- works for me. I hope it will for everyone else. > Similar considerations apply to "ENUM operators as defined by the > ITU". I don't think so. ITU implicitly define this as they have effective administrative control for the delegations under e164.arpa. Ondrej's come up with better text for that too: "ENUM administrator as assigned by the ITU". Can we agree to use that? > OK, 2nd occurence, but s/Critical DNS infrastructure/the purpose > justifying the > assignment/. Again, I think you're being unduly picky Peter. IIRC there was a rough consensus on the policy draft using "Critical DNS Infrastructure" as a definition of the DNS servers needed for the TLDs in the IANA database and the Tier-0/1 ENUM domains in the ITU database. If you don't like the word "Critical" here, let's choose something else like "Qualifying" or "Eligible". OTOH, this is for critical DNS infrastructure so there's no reason IMO for not making that explicit. From shane at time-travellers.org Fri Apr 17 15:49:52 2009 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 17 Apr 2009 15:49:52 +0200 Subject: [address-policy-wg] Anycast assignments for ENUM/TLD registries In-Reply-To: <0482053B-8063-405E-9366-B2B723F7BCFC@rfc1035.com> References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> <0482053B-8063-405E-9366-B2B723F7BCFC@rfc1035.com> Message-ID: <49E88900.5040505@time-travellers.org> Jim, Jim Reid wrote: > >> This layer 9 stuff >> aside, I'm still uncertain whether the assignment goes to the registry >> itself >> or to some operator who provides name service for TLDs (or ENUM, for that >> matter). The former makes more sense to me. > > I am still not certain the latest draft resolves this confusion either. > > I strongly believe that the assignment should go to the registry and not > the provider of registry or DNS services for that registry. Even if > these are the same entity, their roles and their responsibilities are > different. On a practical level, the TLD or Tier-1 administrator might > want to split their anycast assignment between DNS providers: say > discrete /24s to each of them. This wouldn't be easy to do (or change) > if that anycast assignment was held by their registry operator. And > suppose the registry has a serious disagreement its registry operator or > the back-end provider changes when the contract goes out to tender. I agree that the assignment should go to the registry. -- Shane From brettlists at gmail.com Fri Apr 17 18:13:08 2009 From: brettlists at gmail.com (B C) Date: Fri, 17 Apr 2009 17:13:08 +0100 Subject: [address-policy-wg] Anycast assignments for ENUM/TLD registries In-Reply-To: <0482053B-8063-405E-9366-B2B723F7BCFC@rfc1035.com> References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> <0482053B-8063-405E-9366-B2B723F7BCFC@rfc1035.com> Message-ID: <5c494b510904170913r55159c33i881a996cf9d09900@mail.gmail.com> On Fri, Apr 17, 2009 at 2:34 PM, Jim Reid wrote: > Apologies for providing a meaningful Subject: header. :-) > > On Apr 15, 2009, at 14:43, Peter Koch wrote: > >> "TLD operators as defined by IANA" may be a well intended phrase, but many >> affected registries would reject being "defined" by IANA. > > Peter, I feel you're being overly picky here. If an organisation doesn't > like the wording of some policy then they are of course free to choose not > to enjoy the benefits of that policy. Better still, they could suggest text > that makes them feel more comfortable. :-) I think the wording Ondrej has > proposed should provide that level of comfort. > This wording will be in the new version. > I'm ultimately guilty of the insertion of "as defined by IANA". The intent > here was to come up with a policy that would allow anycast assignments to > real TLD registries (ie those in the IANA database) rather than for whatever > gunk lies in so-called alternate roots and so forth. The same goes for the > ENUM Tier-1 registries, though in this case it's ITU and not IANA that has > the definitive database for that. Again, the intent here was to have policy > wording that would prevent charlatans setting up bogus-e164.com (or > whatever) and then come to NCC claiming an entitlement of 200 or so Tier-1 > "country code" anycast assignments: ie essentially having alternate roots in > a slightly different guise. > > In an earlier discussion about this draft I contributed text containing the > URLs for the IANA and ITU databases. This was considered a Bad Idea because > these links could change. So that's what provoked the "as defined by" > revision in the next iteration of the document. > >> This layer 9 stuff >> aside, I'm still uncertain whether the assignment goes to the registry >> itself >> or to some operator who provides name service for TLDs (or ENUM, for that >> matter). ?The former makes more sense to me. > > I am still not certain the latest draft resolves this confusion either. > This has also been addressed in the newest version. > I strongly believe that the assignment should go to the registry and not the > provider of registry or DNS services for that registry. Even if these are > the same entity, their roles and their responsibilities are different. On a > practical level, the TLD or Tier-1 administrator might want to split their > anycast assignment between DNS providers: say discrete /24s to each of them. > This wouldn't be easy to do (or change) if that anycast assignment was held > by their registry operator. And suppose the registry has a serious > disagreement its registry operator or the back-end provider changes when the > contract goes out to tender. > >> "TLD manager/administrator as described in RFC 1591" might be more >> acceptable. > > IMO the language that needs to be use here has somehow to be linked to the > TLD managers that are known to the IANA database. RFC 1591 seems too fuzzy > and very out of date. The excellent text Ondrej suggested -- "designated > manager for TLD as delegated by IANA" -- works for me. I hope it will for > everyone else. > This has also been added to the new version. >> Similar considerations apply to "ENUM operators as defined by the ITU". > > I don't think so. ITU implicitly define this as they have effective > administrative control for the delegations under e164.arpa. Ondrej's come up > with better text for that too: "ENUM administrator as assigned by the ITU". > Can we agree to use that? > >> OK, 2nd occurence, but s/Critical DNS infrastructure/the purpose >> justifying the >> assignment/. > > Again, I think you're being unduly picky Peter. IIRC there was a rough > consensus on the policy draft using "Critical DNS Infrastructure" as a > definition of the DNS servers needed for the TLDs in the IANA database and > the Tier-0/1 ENUM domains in the ITU database. If you don't like the word > "Critical" here, let's choose something else like "Qualifying" or > "Eligible". OTOH, this is for critical DNS infrastructure so there's no > reason IMO for not making that explicit. > > I have removed the "critical dns infrastructure wording" from the document and replaced it with something a little less controversial but meaningful. I think/hope that the new draft Ondrej and I submitted today should address everything below and satisfy points made here by everybody (It's Friday and hence I'm feeling positive) it will be made available shortly after the review period ends for current version (23/04) Brett From leo.vegoda at icann.org Fri Apr 17 21:53:18 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 17 Apr 2009 12:53:18 -0700 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904171327.n3HDRBit029066@nc.cyf-kr.edu.pl> Message-ID: Hi Jerzy, On 17/04/2009 6:27, "Jerzy Pawlus" wrote: [...] > Maybe we can leave it to the hostmaster staff to decide whether subsequent > allocations are justifiable. They earned our trust. I think it would be unfair on the RIPE NCC to do this to it. I agree that its staff are both competent and trustworthy but I think that giving them this responsibility would put them in a very awkward position. The RIPE NCC has to implement the policies set by RIPE - but unless the policy is clearly described and documented RIPE is effectively giving the RIPE NCC the task of deciding on the policy each and every time it evaluates a request. Perhaps more importantly, if the RIPE NCC is asked to do this on a case-by-case basis the policy ceases to be consistent, open and transparent, unless the details of the requests are published. It also puts the RIPE NCC at risk of claims that it didn't act in a neutral and impartial way towards all applicants. I can see that some network operators have a genuine problem but I don't think this option would hold water for long. Regards, Leo From gert at space.net Fri Apr 17 22:25:53 2009 From: gert at space.net (Gert Doering) Date: Fri, 17 Apr 2009 22:25:53 +0200 Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <200904171327.n3HDRBit029066@nc.cyf-kr.edu.pl> References: <20090414125740.9D52C2F583@herring.ripe.net> <20090415135141.GN61514@Space.Net> <200904171327.n3HDRBit029066@nc.cyf-kr.edu.pl> Message-ID: <20090417202553.GW61514@Space.Net> Hi, On Fri, Apr 17, 2009 at 03:27:11PM +0200, Jerzy Pawlus wrote: > > So I think this discussion should move towards: > > > > - find examples of networks that have problems with the current policy, > > and try to figure out common criteria > > Gert, I don't think that at the moment we can find more examples other than > you mentioned in your letter, ie. Telcos and NREN networks. > To some extent it understandable. Big ISP need more time to prepare > themselves, especially in the access area. NREN networks tend to see > problems rather sooner than later. Others will follow as Dami said > "when they face the problem". > On the other hand the interest in and discussion on this matter is > surpisingly small. Actually, "Big Telcos" and "NRENs" seem to be able to work with the current IPv6 policy fairly well. "Big Telcos" seem to be able to get up to a /20, and I see a number of NRENs with IPv6... > > - formulate criteria for "additional allocations" that can get > > (rough) consensus > > As you clearly stated in one of your letters it almost impossible > to apply HD-Ratio to a big ISP. To succesfully run such a business you must > assume some hierarchy in addressing scheme. Any hierarchy leads to address > waste anf if you stick to this you will never reach HD-Ratio. > This is a 'real life' Please read up on how HD ratio works. The whole point about HD ratio is to handle the additional waste caused exactly due to *hierarchy* in addressing. IPv4 has a fixed 80% usage ratio. IPv6 is much more flexible here. > If not to big ISP where else we can apply HD-ratio? Other LIRs will never > reach it. The conclusion is rather surpising. We can silently drop > HD-Ratio criteria and nothing wrong will happen. > In IPv6 world HD-Ratio seems not to work as well as in IPv4 I don't understand what you are trying to tell us. There is no HD-ratio in IPv4. There is HD-ratio in IPv6 (and whether it works or not remains to be seen, as I don't know any ISP that has filled up his IPv6 allocation and has come back to the RIPE NCC for more space). 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 pk at DENIC.DE Fri Apr 17 23:01:00 2009 From: pk at DENIC.DE (Peter Koch) Date: Fri, 17 Apr 2009 23:01:00 +0200 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> Message-ID: <20090417210100.GB32685@x27.adm.denic.de> Ondrej, Brett, thanks for your considerate responses. On Thu, Apr 16, 2009 at 05:21:15PM +0200, Ond??ej Sur? wrote: > > in one single place three paragraphs down. ?I'd prefer if the term would be > > avoided and "Authoritative TLD or ENUM Tier 0/1 DNS lookup services" be > > inserted at the appropriate place. > > We could probably change this, but I think that the reasoning behind this > definition was not only to use it as reference, but also to say that these > DNS servers are different - all other domain names depend on them. I respectfully suggest we don't even try to go down this path and for the reasoning I'd like to refer to Mohsen's message. He hit the nail on the head. > > matter). ?The former makes more sense to me. "TLD manager/administrator as > > described in RFC 1591" might be more acceptable. > > I did some reading on IANA website and maybe the problem is that > each of us imagine different thing under "defined by IANA" since I didn't > find anything like this on IANA website. If you mean that some IANA document(?) ``defines'' the term, then that'd not be a problem. The way it is written looks like IANA would define _who_ the operator is. I assume we agree that's not the case, so > "designated manager for TLD as delegated by IANA" be OK is better, but "recorded" would even better reflect the point that this is only to make sure there's a single database that is to be consulted -- and not how entries got in there. > > As a side note, ENUM Tier 0 assignments would probably have interactions > > with the policy proposal on "Assignments to the NCC". Not to forget this ... > ITU documents use these terms: [...] > "ENUM administrator as assigned by the ITU" I doubt that since ITU may have defined the term (then quote that reference) but does not assign the administrator rights. Similar to the TLDs, it's probably more important to give guidance where the list of operators is available. I'd assume that the ENUM Tier0 operator has such a list (and would have it independent of the fact that this is again the NCC with a different role). Regards, Peter From Jerzy.Pawlus at cyf-kr.edu.pl Sat Apr 18 00:31:46 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Sat, 18 Apr 2009 00:31:46 +0200 (METDST) Subject: [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs) In-Reply-To: <20090417202553.GW61514@Space.Net> from Gert Doering at Apr "17," 2009 "10:25:53" pm Message-ID: <200904172231.n3HMVkwB023220@nc.cyf-kr.edu.pl> Hi Gert, [...] > > > Please read up on how HD ratio works. The whole point about HD ratio is > to handle the additional waste caused exactly due to *hierarchy* in > addressing. > Sorry, I have stopped reading Appendix A Of the http://www.ripe.net/ripe/docs/ripe-450.html when I saw it referring to HD-Ratio equal to 0.94. There is another paragraph that says that it is equal to 0.8 [...] > > I don't understand what you are trying to tell us. There is no HD-ratio > in IPv4. There is HD-ratio in IPv6 (and whether it works or not remains > to be seen, as I don't know any ISP that has filled up his IPv6 > allocation and has come back to the RIPE NCC for more space). > My point was that it is doubtfull that we will ever see an LIR reaching HD-Ratio. Regards, Jurek -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: /tmp/AAAa18807 URL: From Woeber at CC.UniVie.ac.at Sun Apr 19 13:32:00 2009 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Sun, 19 Apr 2009 11:32:00 +0000 Subject: [address-policy-wg] 2008-05 - Anycast assignments for ENUM/TLD registries In-Reply-To: <5c494b510904170913r55159c33i881a996cf9d09900@mail.gmail.com> References: <20090326130519.868942F583@herring.ripe.net> <20090415134300.GB13037@x27.adm.denic.de> <0482053B-8063-405E-9366-B2B723F7BCFC@rfc1035.com> <5c494b510904170913r55159c33i881a996cf9d09900@mail.gmail.com> Message-ID: <49EB0BB0.5000608@CC.UniVie.ac.at> Editorial - B C wrote: > On Fri, Apr 17, 2009 at 2:34 PM, Jim Reid wrote: > >>Apologies for providing a meaningful Subject: header. :-) Could we please keep the policy proposal ID in the Subject? Thanks, Wilfried. >>On Apr 15, 2009, at 14:43, Peter Koch wrote: >> >> >>>"TLD operators as defined by IANA" may be a well intended phrase, but many >>>affected registries would reject being "defined" by IANA. >> >>Peter, I feel you're being overly picky here. If an organisation doesn't >>like the wording of some policy then they are of course free to choose not >>to enjoy the benefits of that policy. Better still, they could suggest text >>that makes them feel more comfortable. :-) I think the wording Ondrej has >>proposed should provide that level of comfort. >> > > > This wording will be in the new version. > > >>I'm ultimately guilty of the insertion of "as defined by IANA". The intent >>here was to come up with a policy that would allow anycast assignments to >>real TLD registries (ie those in the IANA database) rather than for whatever >>gunk lies in so-called alternate roots and so forth. The same goes for the >>ENUM Tier-1 registries, though in this case it's ITU and not IANA that has >>the definitive database for that. Again, the intent here was to have policy >>wording that would prevent charlatans setting up bogus-e164.com (or >>whatever) and then come to NCC claiming an entitlement of 200 or so Tier-1 >>"country code" anycast assignments: ie essentially having alternate roots in >>a slightly different guise. >> >>In an earlier discussion about this draft I contributed text containing the >>URLs for the IANA and ITU databases. This was considered a Bad Idea because >>these links could change. So that's what provoked the "as defined by" >>revision in the next iteration of the document. >> >> >>>This layer 9 stuff >>>aside, I'm still uncertain whether the assignment goes to the registry >>>itself >>>or to some operator who provides name service for TLDs (or ENUM, for that >>>matter). The former makes more sense to me. >> >>I am still not certain the latest draft resolves this confusion either. >> > > > This has also been addressed in the newest version. > > > >>I strongly believe that the assignment should go to the registry and not the >>provider of registry or DNS services for that registry. Even if these are >>the same entity, their roles and their responsibilities are different. On a >>practical level, the TLD or Tier-1 administrator might want to split their >>anycast assignment between DNS providers: say discrete /24s to each of them. >>This wouldn't be easy to do (or change) if that anycast assignment was held >>by their registry operator. And suppose the registry has a serious >>disagreement its registry operator or the back-end provider changes when the >>contract goes out to tender. >> >> >>>"TLD manager/administrator as described in RFC 1591" might be more >>>acceptable. >> >>IMO the language that needs to be use here has somehow to be linked to the >>TLD managers that are known to the IANA database. RFC 1591 seems too fuzzy >>and very out of date. The excellent text Ondrej suggested -- "designated >>manager for TLD as delegated by IANA" -- works for me. I hope it will for >>everyone else. >> > > > This has also been added to the new version. > > > >>>Similar considerations apply to "ENUM operators as defined by the ITU". >> >>I don't think so. ITU implicitly define this as they have effective >>administrative control for the delegations under e164.arpa. Ondrej's come up >>with better text for that too: "ENUM administrator as assigned by the ITU". >>Can we agree to use that? >> >> >>>OK, 2nd occurence, but s/Critical DNS infrastructure/the purpose >>>justifying the >>>assignment/. >> >>Again, I think you're being unduly picky Peter. IIRC there was a rough >>consensus on the policy draft using "Critical DNS Infrastructure" as a >>definition of the DNS servers needed for the TLDs in the IANA database and >>the Tier-0/1 ENUM domains in the ITU database. If you don't like the word >>"Critical" here, let's choose something else like "Qualifying" or >>"Eligible". OTOH, this is for critical DNS infrastructure so there's no >>reason IMO for not making that explicit. >> >> > > > I have removed the "critical dns infrastructure wording" from the > document and replaced it with something a little less controversial > but meaningful. > > > I think/hope that the new draft Ondrej and I submitted today should > address everything below and satisfy points made here by everybody > (It's Friday and hence I'm feeling positive) it will be made available > shortly after the review period ends for current version (23/04) > > Brett > > From webmaster at ripe.net Mon Apr 20 13:18:52 2009 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Mon, 20 Apr 2009 13:18:52 +0200 Subject: [address-policy-wg] New Document available: RIPE-465 Message-ID: <20090420111852.7A5182F66A@herring.ripe.net> Dear Colleagues, The mention of 0.8 as the HD ratio (in two occurrences) in ripe-450 is an error. In RIPE, the HD ratio for IPv6 has been set at 0.94 since November 2007 and was documented correctly in the previous IPv6 Address Allocation and Assignment Policy (ripe-421). We have corrected the error and published an updated document (ripe-465) that you can find at: http://test-www.ripe.net/ripe/docs/ripe-465.html We apologise for any confusion this may have caused and will put in place additional checks to prevent similar errors in the future Kind Regards Adrian Bedford Web Services Team Leader RIPE NCC and Filiz Yilmaz Policy Development Officer RIPE NCC From adrian at ripe.net Mon Apr 20 13:26:38 2009 From: adrian at ripe.net (Adrian Bedford) Date: Mon, 20 Apr 2009 13:26:38 +0200 Subject: [address-policy-wg] New Document available: RIPE-465 In-Reply-To: <20090420111852.7A5182F66A@herring.ripe.net> References: <20090420111852.7A5182F66A@herring.ripe.net> Message-ID: <49EC5BEE.1030704@ripe.net> Please note, the URL for the document is: http://test-www.ripe.net/ripe/docs/ripe-465.html Regards Adrian Bedford Web Services Team Leader RIPE NCC RIPE NCC Document Announcement Service wrote: > Dear Colleagues, > > The mention of 0.8 as the HD ratio (in two occurrences) in ripe-450 is an error. > > In RIPE, the HD ratio for IPv6 has been set at 0.94 since November 2007 and was documented correctly in the previous IPv6 Address Allocation and Assignment Policy (ripe-421). > > We have corrected the error and published an updated document (ripe-465) that you can find at: > > http://test-www.ripe.net/ripe/docs/ripe-465.html > > We apologise for any confusion this may have caused and will put in place additional checks to prevent similar errors in the future > > Kind Regards > > Adrian Bedford > Web Services Team Leader > RIPE NCC > > and > > Filiz Yilmaz > Policy Development Officer > RIPE NCC > From adrian at ripe.net Mon Apr 20 13:27:32 2009 From: adrian at ripe.net (Adrian Bedford) Date: Mon, 20 Apr 2009 13:27:32 +0200 Subject: [address-policy-wg] New Document available: RIPE-465 In-Reply-To: <20090420111852.7A5182F66A@herring.ripe.net> References: <20090420111852.7A5182F66A@herring.ripe.net> Message-ID: <49EC5C24.2040702@ripe.net> Please note, the URL for the new RIPE Document is http://www.ripe.net/ripe/docs/ripe-465.html Regards Adrian Bedford RIPE NCC Document Announcement Service wrote: > Dear Colleagues, > > The mention of 0.8 as the HD ratio (in two occurrences) in ripe-450 is an error. > > In RIPE, the HD ratio for IPv6 has been set at 0.94 since November 2007 and was documented correctly in the previous IPv6 Address Allocation and Assignment Policy (ripe-421). > > We have corrected the error and published an updated document (ripe-465) that you can find at: > > http://test-www.ripe.net/ripe/docs/ripe-465.html > > We apologise for any confusion this may have caused and will put in place additional checks to prevent similar errors in the future > > Kind Regards > > Adrian Bedford > Web Services Team Leader > RIPE NCC > > and > > Filiz Yilmaz > Policy Development Officer > RIPE NCC > From frederic at placenet.org Tue Apr 21 10:38:40 2009 From: frederic at placenet.org (Frederic) Date: Tue, 21 Apr 2009 10:38:40 +0200 Subject: [address-policy-wg] do you believe ? the time is near. Message-ID: <1240303120.6957.6.camel@kzinti.placenet.org> hi, http://www.ripe.net/ripe/policies/proposals/2006-01.html it is time to permit IPV6-PI assignement. That the way to permit to IPV6 to be alive in the entire network. Awaiting Decision from WG Chairs : Please give you d?cision. we need, we want ask our Ipv6-PI ! Bst regards. F. From fweimer at bfk.de Tue Apr 21 16:54:50 2009 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 21 Apr 2009 16:54:50 +0200 Subject: [address-policy-wg] Draft Proposal: Assignment of an IPv4 /24 for documentation purposes In-Reply-To: <20090415165733.GD13037@x27.adm.denic.de> (Peter Koch's message of "Wed, 15 Apr 2009 18:57:33 +0200") References: <20090415165733.GD13037@x27.adm.denic.de> Message-ID: <82tz4ikqf9.fsf@mid.bfk.de> * Peter Koch: > During recent discussion within the IETF, but also on other occasions > in the past, it appeared that a single /24 is often not enough to > support instructive examples. This may include more complex network > designs, or the use of addresses for DNS name servers, where good > practice (see RFC 2182, BCP 16) suggests topological diversity. Uhm? Thanks to CIDR and IGPs supporting VLSMs, it's possible to have topological diversity within a /24. -- 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 nick at inex.ie Tue Apr 21 17:19:01 2009 From: nick at inex.ie (Nick Hilliard) Date: Tue, 21 Apr 2009 16:19:01 +0100 Subject: [address-policy-wg] Draft Proposal: Assignment of an IPv4 /24 for documentation purposes In-Reply-To: <82tz4ikqf9.fsf@mid.bfk.de> References: <20090415165733.GD13037@x27.adm.denic.de> <82tz4ikqf9.fsf@mid.bfk.de> Message-ID: <49EDE3E5.4050207@inex.ie> On 21/04/2009 15:54, Florian Weimer wrote: > Uhm? Thanks to CIDR and IGPs supporting VLSMs, it's possible to have > topological diversity within a /24. Sometimes for the purposes of documentation, it helps to have different significant digits to clearly indicate different subnets. I don't think that there should be a problem filing away a couple of /24s for this purpose: we have quite a few left, and documentation is a worthy cause. Nick From fweimer at bfk.de Wed Apr 22 09:27:45 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 22 Apr 2009 09:27:45 +0200 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <20090326130519.868942F583@herring.ripe.net> (Filiz Yilmaz's message of "Thu, 26 Mar 2009 14:05:19 +0100") References: <20090326130519.868942F583@herring.ripe.net> Message-ID: <823ac1jgge.fsf@mid.bfk.de> * Filiz Yilmaz: > The text of the policy proposal 2008-05, "Anycasting Assignments for > TLDs and Tier 0/1 ENUM" has been revised. We have published the new > version (version 3.0) today. The draft documents for the proposal > have also been published, as well as the impact analysis that was > conducted for this proposal. This proposal does not allow for a local/global node split. Is this a problem? Section 6.9 make it clear whether the prefix is per service or per organization (that is, if an organization which runs multiple TLDs and ENUM receives one, two, or many prefixes). Should critical DNS infrastructure include DLV zones for public use? -- 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 bmanning at vacation.karoshi.com Wed Apr 22 10:06:52 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 22 Apr 2009 08:06:52 +0000 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <823ac1jgge.fsf@mid.bfk.de> References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> Message-ID: <20090422080652.GA14547@vacation.karoshi.com.> On Wed, Apr 22, 2009 at 09:27:45AM +0200, Florian Weimer wrote: > * Filiz Yilmaz: > > > The text of the policy proposal 2008-05, "Anycasting Assignments for > > TLDs and Tier 0/1 ENUM" has been revised. We have published the new > > version (version 3.0) today. The draft documents for the proposal > > have also been published, as well as the impact analysis that was > > conducted for this proposal. > > This proposal does not allow for a local/global node split. Is this a > problem? > > Section 6.9 make it clear whether the prefix is per service or per > organization (that is, if an organization which runs multiple TLDs and > ENUM receives one, two, or many prefixes). > > Should critical DNS infrastructure include DLV zones for public use? $diety NO. --bill > > -- > 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 fweimer at bfk.de Wed Apr 22 10:27:01 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 22 Apr 2009 10:27:01 +0200 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <20090422080652.GA14547@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Wed, 22 Apr 2009 08:06:52 +0000") References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> <20090422080652.GA14547@vacation.karoshi.com.> Message-ID: <82r5zlhz56.fsf@mid.bfk.de> >> Should critical DNS infrastructure include DLV zones for public use? > > $diety NO. Why not? How it is different from ENUM? -- 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 jim at rfc1035.com Wed Apr 22 10:28:32 2009 From: jim at rfc1035.com (Jim Reid) Date: Wed, 22 Apr 2009 09:28:32 +0100 Subject: [address-policy-wg] 2008-05 Anycast for DLV zones In-Reply-To: <823ac1jgge.fsf@mid.bfk.de> References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> Message-ID: On 22 Apr 2009, at 08:27, Florian Weimer wrote: > Should critical DNS infrastructure include DLV zones for public use? No. Absolutely not. DLV is not critical to the operation of the Internet. [IMO it's a short-term hack that will go away once the root and/or major TLDs get signed.] The DNS servers for TLDs, and to a lesser extent, the Tier-1 ENUM delegations are critical. If they went away, everyone would immediately notice that. If a DLV zone's DNS servers fail, an insignificant number of people would notice. DLV users are a fraction of the tiny number of people using DNSSEC today. Another point: anyone can set themselves up a DLV provider. So if arbitrary DLV operators were able to get anycast allocations, this would be a good way of depleting the remaining IPv4 space. At least there's a finite number of TLD and Tier-1 ENUM delegations which are underpinned by "official" registries and procedures for obtaining/ managing them. This is not the case for DLV providers (if I can use that vague term). Oh and what happens when the next flavour-of-the-month DNSSEC validation hack comes along? Should the policy be modified to accommodate that too?? BTW I am also uncomfortable with attempts to shore up DLV or to make it more permanent. That takes resources away from getting DNSSEC properly deployed by having the root and TLDs signed. From brettlists at gmail.com Wed Apr 22 11:08:14 2009 From: brettlists at gmail.com (B C) Date: Wed, 22 Apr 2009 10:08:14 +0100 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <823ac1jgge.fsf@mid.bfk.de> References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> Message-ID: <5c494b510904220208o76eb9a4er862f02ca10483445@mail.gmail.com> On Wed, Apr 22, 2009 at 8:27 AM, Florian Weimer wrote: > * Filiz Yilmaz: > >> The text of the policy proposal 2008-05, "Anycasting Assignments for >> TLDs and Tier 0/1 ENUM" has been revised. We have published the new >> version (version 3.0) today. The draft documents for the proposal >> have also been published, as well as the impact analysis that was >> conducted for this proposal. > > This proposal does not allow for a local/global node split. ?Is this a > problem? I don't think it is a problem I don't believe the policy should refer to any type/implementation of Anycast. > > Section 6.9 make it clear whether the prefix is per service or per > organization (that is, if an organization which runs multiple TLDs and > ENUM receives one, two, or many prefixes). I had already decided that this needed clarification and it has been done int he new version. > > Should critical DNS infrastructure include DLV zones for public use? > Definitley not DLV although it can be useful is a short term hack that hopefully will go away when the root (and some significant TLD's) is signed. Brett Carr From filiz at ripe.net Wed Apr 22 11:31:07 2009 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 22 Apr 2009 11:31:07 +0200 Subject: [address-policy-wg] 2006-01 Proposal Accepted (Provider Independent (PI) IPv6 Assignments for End User Organisations) Message-ID: <20090422093107.698EC2F5DC@herring.ripe.net> PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations Dear Colleagues, Consensus has been reached, and the proposal described in 2006-01, "Provider Independent (PI) IPv6 Assignments for End User Organisations" has been accepted by the RIPE community. The related RIPE policy document is now updated, published and can be found at: http://www.ripe.net/ripe/docs/ripe-466.html or http://www.ripe.net/ripe/docs/ipv6-policies.html The proposal is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2006-01.html The RIPE NCC will implement this new policy within one month. Thank you for your input. Regards Filiz Yilmaz Policy Development Officer RIPE NCC From fweimer at bfk.de Wed Apr 22 11:38:11 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 22 Apr 2009 11:38:11 +0200 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <5c494b510904220208o76eb9a4er862f02ca10483445@mail.gmail.com> (B. C.'s message of "Wed, 22 Apr 2009 10:08:14 +0100") References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> <5c494b510904220208o76eb9a4er862f02ca10483445@mail.gmail.com> Message-ID: <82bpqphvuk.fsf@mid.bfk.de> * B. C.: >> This proposal does not allow for a local/global node split. ?Is >> this a problem? > > I don't think it is a problem I don't believe the policy should > refer to any type/implementation of Anycast. If you assign a /24 instead of a /23, you rule out certain implementations. You can't reliably run cross-AS local nodes with a single /24 because a preferred, non-exported prefix typically suppresses announcements of the prefix---even if a non-preferred prefix exists which could be announced. -- 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 frederic at placenet.org Wed Apr 22 11:47:58 2009 From: frederic at placenet.org (Frederic) Date: Wed, 22 Apr 2009 11:47:58 +0200 Subject: [address-policy-wg] 2006-01 Proposal Accepted (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20090422093107.698EC2F5DC@herring.ripe.net> References: <20090422093107.698EC2F5DC@herring.ripe.net> Message-ID: <1240393678.4414.0.camel@kzinti.placenet.org> Le mercredi 22 avril 2009 ? 11:31 +0200, Filiz Yilmaz a ?crit : > PDP Number: 2006-01 > Provider Independent (PI) IPv6 Assignments for End User Organisations > > Dear Colleagues, > > Consensus has been reached, and the proposal described in 2006-01, > "Provider Independent (PI) IPv6 Assignments for End User > Organisations" has been accepted by the RIPE community. > > The related RIPE policy document is now updated, published and can > be found at: > > http://www.ripe.net/ripe/docs/ripe-466.html > or > http://www.ripe.net/ripe/docs/ipv6-policies.html > > The proposal is now archived and can be found at: > > http://www.ripe.net/ripe/policies/proposals/2006-01.html > > The RIPE NCC will implement this new policy within one month. > > Thank you for your input. > > Regards > > Filiz Yilmaz > Policy Development Officer > RIPE NCC > > champagne ! From fweimer at bfk.de Wed Apr 22 13:05:14 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 22 Apr 2009 13:05:14 +0200 Subject: [address-policy-wg] 2008-05 Anycast for DLV zones In-Reply-To: (Jim Reid's message of "Wed, 22 Apr 2009 09:28:32 +0100") References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> Message-ID: <824owhhrth.fsf@mid.bfk.de> * Jim Reid: > On 22 Apr 2009, at 08:27, Florian Weimer wrote: > >> Should critical DNS infrastructure include DLV zones for public use? > > No. Absolutely not. DLV is not critical to the operation of the > Internet. And ENUM is? Which part of the Internet depends on it? > The DNS servers for TLDs, and to a lesser extent, the Tier-1 ENUM > delegations are critical. If they went away, everyone would > immediately notice that. Could you name a ENUM delegation which is critical in this sense? (This is exclusively about e164.arpa and its children, right?) > Another point: anyone can set themselves up a DLV provider. So if > arbitrary DLV operators were able to get anycast allocations, this > would be a good way of depleting the remaining IPv4 space. At least > there's a finite number of TLD and Tier-1 ENUM delegations which are > underpinned by "official" registries and procedures for obtaining/ > managing them. This is not the case for DLV providers (if I can use > that vague term). This is certainly the best argument, although it's rather discriminating. (Although the situation with TLDs will likely evolve into more general availability.) > Oh and what happens when the next flavour-of-the-month DNSSEC > validation hack comes along? Should the policy be modified to > accommodate that too?? Oh, come on, DLV is less of a hack than ENUM. At least it uses DNS for storing DNS-related data, and it's a rather good match conceptually (incremental dialing anyone?). > BTW I am also uncomfortable with attempts to shore up DLV or to make > it more permanent. I can understand that, but isn't this something beyond addressing policy? It's a bit like denying .BY an anycast prefix because you don't like the political situation over there. -- 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 jim at rfc1035.com Wed Apr 22 13:42:01 2009 From: jim at rfc1035.com (Jim Reid) Date: Wed, 22 Apr 2009 12:42:01 +0100 Subject: [address-policy-wg] 2008-05 Anycast for DLV zones In-Reply-To: <824owhhrth.fsf@mid.bfk.de> References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> <824owhhrth.fsf@mid.bfk.de> Message-ID: On 22 Apr 2009, at 12:05, Florian Weimer wrote: > * Jim Reid: > >> On 22 Apr 2009, at 08:27, Florian Weimer wrote: >> >>> Should critical DNS infrastructure include DLV zones for public use? >> >> No. Absolutely not. DLV is not critical to the operation of the >> Internet. > > And ENUM is? Well it definitely has more people/applications depending on it than DLV. And unlike DLV, ENUM has paying customers and businesses which depend on it. Even in the public e164.arpa tree. > Which part of the Internet depends on it? See above. Pretty much anything doing lookups in e164.arpa: Asterisk servers, various other SIP services, VoIP providers, smartphones, etc. ENUM may have a low usage. But unlike DLV, ENUM is not just for consenting adults: everything and anything can do an ENUM lookup straight out of the box. This is not the case for DLV because DNSSEC- aware validators -- a miniscule percentage of the world's resolving servers -- have to be specially configured, DLV policies need to be defined, key mangament issues have to be worked out, etc, etc. >> The DNS servers for TLDs, and to a lesser extent, the Tier-1 ENUM >> delegations are critical. If they went away, everyone would >> immediately notice that. > > Could you name a ENUM delegation which is critical in this sense? Well I know there are paying customers and commercial services dependent on ENUM in Austria, Romania and the UK. I expect this is also true other countries: I can't be bothered to look. FYI the Austrian regulator has set aside a block of their number space for ENUM-only telephony. > Oh, come on, DLV is less of a hack than ENUM. At least it uses DNS > for storing DNS-related data, and it's a rather good match > conceptually (incremental dialing anyone?). This is not the forum to debate whether ENUM or DLV is a better use of the DNS. Please take this argument somewhere else. >> BTW I am also uncomfortable with attempts to shore up DLV or to make >> it more permanent. > > I can understand that, but isn't this something beyond addressing > policy? It's a bit like denying .BY an anycast prefix because you > don't like the political situation over there. It's not like that at all. The policy can be summarised as "important DNS infrastructure can get an anycast allocation from the NCC". No more, no less. You're quibbling about what the definition of important is. So far the view on this list is that DLV zones do not deserve to be called important. IMO valid reasons have been presented to explain why DLV doesn't deserve one of these anycast allocations. You may well disgaree with that view. But you've yet to present any justification why DLV zones should be treated in the same way as a TLD or ENUM Tier-1 delegation. Saying "I think ENUM sucks" does not make that case. If you think DLV deserves these anycast allocations, present the justifcation and convince this list. From remco.vanmook at eu.equinix.com Wed Apr 22 13:51:44 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Wed, 22 Apr 2009 13:51:44 +0200 Subject: [address-policy-wg] 2008-05 Anycast for DLV zones In-Reply-To: Message-ID: What Jim said. In addition, the way I see it is that DLV is a temporary measure until the root gets signed and all the world is happily using DNSsec. As this is only a very temporary situation, why make this part of permanent policy? If DLV needs anycast, file a proposal. Better yet - the RIRs in my experience have no problems doing temporary resource allocations for experiments, given a justification. Why not try that? Or will DLV be another artefact that will be around forever? Best, Remco On 22-04-09 13:42, "Jim Reid" wrote: > On 22 Apr 2009, at 12:05, Florian Weimer wrote: > >> * Jim Reid: >> >>> On 22 Apr 2009, at 08:27, Florian Weimer wrote: >>> >>>> Should critical DNS infrastructure include DLV zones for public use? >>> >>> No. Absolutely not. DLV is not critical to the operation of the >>> Internet. >> >> And ENUM is? > > Well it definitely has more people/applications depending on it than > DLV. And unlike DLV, ENUM has paying customers and businesses which > depend on it. Even in the public e164.arpa tree. > >> Which part of the Internet depends on it? > > See above. Pretty much anything doing lookups in e164.arpa: Asterisk > servers, various other SIP services, VoIP providers, smartphones, etc. > ENUM may have a low usage. But unlike DLV, ENUM is not just for > consenting adults: everything and anything can do an ENUM lookup > straight out of the box. This is not the case for DLV because DNSSEC- > aware validators -- a miniscule percentage of the world's resolving > servers -- have to be specially configured, DLV policies need to be > defined, key mangament issues have to be worked out, etc, etc. > >>> The DNS servers for TLDs, and to a lesser extent, the Tier-1 ENUM >>> delegations are critical. If they went away, everyone would >>> immediately notice that. >> >> Could you name a ENUM delegation which is critical in this sense? > > Well I know there are paying customers and commercial services > dependent on ENUM in Austria, Romania and the UK. I expect this is > also true other countries: I can't be bothered to look. FYI the > Austrian regulator has set aside a block of their number space for > ENUM-only telephony. > >> Oh, come on, DLV is less of a hack than ENUM. At least it uses DNS >> for storing DNS-related data, and it's a rather good match >> conceptually (incremental dialing anyone?). > > This is not the forum to debate whether ENUM or DLV is a better use of > the DNS. Please take this argument somewhere else. > >>> BTW I am also uncomfortable with attempts to shore up DLV or to make >>> it more permanent. >> >> I can understand that, but isn't this something beyond addressing >> policy? It's a bit like denying .BY an anycast prefix because you >> don't like the political situation over there. > > It's not like that at all. The policy can be summarised as "important > DNS infrastructure can get an anycast allocation from the NCC". No > more, no less. You're quibbling about what the definition of important > is. So far the view on this list is that DLV zones do not deserve to > be called important. IMO valid reasons have been presented to explain > why DLV doesn't deserve one of these anycast allocations. You may well > disgaree with that view. But you've yet to present any justification > why DLV zones should be treated in the same way as a TLD or ENUM > Tier-1 delegation. Saying "I think ENUM sucks" does not make that case. > > If you think DLV deserves these anycast allocations, present the > justifcation and convince this list. > 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 Apr 22 15:00:30 2009 From: gert at space.net (Gert Doering) Date: Wed, 22 Apr 2009 15:00:30 +0200 Subject: [address-policy-wg] (Draft) Agenda for RIPE 58 Message-ID: <20090422130030.GU61514@Space.Net> Hi APWG folks, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Amsterdam in the following 2.5 time slots: Wednesday, May 6, 09:45 - 10:30 Wednesday, May 6, 11:00 - 12:30 Thursday, May 7, 09:00 - 10:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". If you have anything else you want to see on the agenda, or of we need to change anything, please let us know. Due to the "RIPE 20 years" celebration on Thursday, we didn't get as much time as I had hoped for, so some of the discussions might have to be cut short and redirected to the mailing list. Sorry for that. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:45-10:30 ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) Update on the implementation of 2007-01 ** will be covered in the NCC Services WG ** B. Current Policy Topics - Filiz Yilmaz [25-30 min] - overview over concluded protocols (2006-01 [IPv6 PI], 2007-05 [ULA-Central], 2007-08 [Transfers], 2008-09 [ASPLAIN format]) - common policy topics in all regions (end of IPv4, transfers, ...) C. ASN 32-bit policy - Experiences and Review presentation by Daniel Karrenberg, discussion [10+10 min] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- E. New Proposals since RIPE 57 overview about what's coming [5-10 min] F. Discussion of open policy proposals, grouped by similarity of topic --- PI and special-case address space related --- 2006-05 PI Assignment Size [0 min] (will be mentioned in the "overview" and will not be discussed again) 2008-05 Anycasting Assignments for TLDs and Tier 0/1 ENUM [15 min] (5-minute presentation about v3 and issues addressed, Q&A, discussion) 2009-02 Internet Resource Assignment to the RIPE NCC (Remco) [10 min] (3-minute presentation about v2, Q&A, discussion) 2009-05 Multiple IPv6 Allocations for LIRs [15 min] --- end of IPv4 session (1) --- 2009-03 IPv4 Run-Out Fairly Proposal (Daniel Karrenberg) [25 min] ---------------------------------------------------------------------- Thursday, 09:00-11:30 ---------------------------------------------------------------------- --- end of IPv4 session (2) --- 2009-01 Global Policy for the allocation of IPv4 blocks to [15-20 min] Regional Internet Registries (see also http://www.apnic.net/policy/discussions/prop-069-v002.txt) Presentation by Axel Pawlik from the RIPE NCC. 2008-06 Phil Smith (1) - Usage of final /8 [5 min] (see also http://www.apnic.net/policy/discussions/prop-062-v002.txt) 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment [5 min] (Alain Bidron) joint discussion about both proposals, because both [30 min] affect usage of the last /8 -> the WG needs to decide how to proceed with these two colliding proposals. 2008-07 Phil Smith (2) - Efficient use of historical IPv4 res. [15-20 min] (see also http://www.apnic.net/policy/discussions/prop-066-v004.txt) --- cross-WG material --- 2008-08 Initial Certification Policy for PA Space Holders [0 min] CA-TF, presentation by Nigel Titley, + Discussion (this will also be discussed in the NCC services WG, just included in the list of "open proposals" for completeness) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." (Idea from ARIN policy meeting) Z. AOB -- 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 bmanning at vacation.karoshi.com Wed Apr 22 11:02:19 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 22 Apr 2009 09:02:19 +0000 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <82r5zlhz56.fsf@mid.bfk.de> References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> <20090422080652.GA14547@vacation.karoshi.com.> <82r5zlhz56.fsf@mid.bfk.de> Message-ID: <20090422090219.GA14933@vacation.karoshi.com.> On Wed, Apr 22, 2009 at 10:27:01AM +0200, Florian Weimer wrote: > >> Should critical DNS infrastructure include DLV zones for public use? > > > > $diety NO. > > Why not? How it is different from ENUM? > > -- > Florian Weimer DLV - as practiced by many - is a specific service offering by one vendor. ENUM on the other hand is a broadly defined/used service by many parties. I refer to Jim Reids posting for more reasons why DLV-specific policies by an RIR are short-sighted at best. --bill From brettlists at gmail.com Wed Apr 22 22:57:14 2009 From: brettlists at gmail.com (B C) Date: Wed, 22 Apr 2009 21:57:14 +0100 Subject: [address-policy-wg] 2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM) In-Reply-To: <82bpqphvuk.fsf@mid.bfk.de> References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> <5c494b510904220208o76eb9a4er862f02ca10483445@mail.gmail.com> <82bpqphvuk.fsf@mid.bfk.de> Message-ID: <5c494b510904221357m62a4f0b1y58a2f27b75294de4@mail.gmail.com> Florian, On Wed, Apr 22, 2009 at 10:38 AM, Florian Weimer wrote: > * B. C.: > >>> This proposal does not allow for a local/global node split. ?Is >>> this a problem? >> >> I don't think it is a problem I don't believe the policy should >> refer to any type/implementation of Anycast. > > If you assign a /24 instead of a /23, you rule out certain > implementations. ?You can't reliably run cross-AS local nodes with a > single /24 because a preferred, non-exported prefix typically > suppresses announcements of the prefix---even if a non-preferred > prefix exists which could be announced. The purpose of the proposed policy amendment is two fold. 1. To expand the policy to cover enum aswell as TLD's. 2. To expand the usage from one nameserver to up to four nameservers. I think you raise a valid point above and this may be something that the working group needs to discuss further (maybe with input from the routing-wg) however I believe this is out of scope of the current proposal and if you feel this is important it could/should be submitted as a seperate proposal. Brett. From ingrid at ripe.net Thu Apr 23 09:53:10 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Thu, 23 Apr 2009 09:53:10 +0200 Subject: [address-policy-wg] 2009-02 Discussion Period extended until 21 May 2009 (Allocating/Assigning Resources to the RIPE NCC) Message-ID: <20090423075310.194B22F5E1@herring.ripe.net> PDP Number: 2009-02 Allocating/Assigning Resources to the RIPE NCC Dear Colleagues, The text of the policy proposal 2009-02 has been revised based on the community feedback received on the mailing list. We have published the new version (version 2) today. As a result a new Discussion Phase is set for the proposal. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-02.html We encourage you to review this policy proposal and send your comments to address-policy-wg at ripe.net before 21 May 2009. Regards, Ingrid Wijte Policy Development Officer RIPE NCC From Niall.oReilly at ucd.ie Thu Apr 23 11:52:10 2009 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 23 Apr 2009 10:52:10 +0100 Subject: [address-policy-wg] 2009-02 Discussion Period extended until 21 May 2009 (Allocating/Assigning Resources to the RIPE NCC) In-Reply-To: <20090423075310.194B22F5E1@herring.ripe.net> References: <20090423075310.194B22F5E1@herring.ripe.net> Message-ID: <1240480330.7002.149.camel@d410-heron> On Thu, 2009-04-23 at 09:53 +0200, Ingrid Wijte wrote: > We encourage you to review this policy proposal and send your comments > to address-policy-wg at ripe.net before 21 May 2009. Nit: The phrase 'IP Resource Analyst' should be used on the first occasion where 'IPRA' occurs. No objections. Niall O'Reilly From marcoh at marcoh.net Thu Apr 23 12:03:15 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 23 Apr 2009 12:03:15 +0200 Subject: [address-policy-wg] 2009-02 Discussion Period extended until 21 May 2009 (Allocating/Assigning Resources to the RIPE NCC) In-Reply-To: <20090423075310.194B22F5E1@herring.ripe.net> References: <20090423075310.194B22F5E1@herring.ripe.net> Message-ID: On 23 apr 2009, at 09:53, Ingrid Wijte wrote: > PDP Number: 2009-02 > Allocating/Assigning Resources to the RIPE NCC > > Dear Colleagues, > > The text of the policy proposal 2009-02 has been revised based on > the community feedback received > on the mailing list. > > We have published the new version (version 2) today. > As a result a new Discussion Phase is set for the proposal. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2009-02.html > > We encourage you to review this policy proposal and send your comments > to address-policy-wg at ripe.net before 21 May 2009. I see no problems here, please go ahead. Groet, MarcoH From ingrid at ripe.net Mon Apr 27 09:33:40 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Mon, 27 Apr 2009 09:33:40 +0200 Subject: [address-policy-wg] 2008-05 Review Period extended until 11 May 2009 (Anycasting Assignments for TLDs and Tier 0/1 ENUM) Message-ID: <20090427073340.D840E2F596@herring.ripe.net> PDP Number: 2008-05 Anycasting Assignments for TLDs and Tier 0/1 ENUM Dear Colleagues, The text of the policy proposal 2008-05 has been revised based on the community feedback. We have published the new version (version 4.0) today. As a result a new Review Phase is set for the proposal. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-05.html and the draft RIPE Documents at: http://www.ripe.net/ripe/draft-documents/ripe-449-draft2008-05-v4.html http://www.ripe.net/ripe/draft-documents/ripe-466-draft2008-05.html We encourage you to read the revised proposal and the draft documents, and send any comments to address-policy-wg at ripe.net before 11 May 2008. Regards, Ingrid Wijte Policy Development Officer RIPE NCC