October 2011 - address-policy-wg

Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)?
by DI. Thomas Schallar 09 Nov '11

09 Nov '11

Hello! What ist the current status on the multihomed v6 PI topic? regards, Thomas

32 70

Re: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation)
by boggits 05 Nov '11

05 Nov '11

On 21 October 2011 11:44, Emilio Madaio <emadaio(a)ripe.net> wrote: > www.ripe.net/ripe/policies/proposals/2011-04 Okay, I can see the logic, but please can we not do this :) I'm all for allowing a policy that says LIR can request a /29 rather than a /32 and that deploying 6rd is a valid reason for allocating a /29 as an initial block but can we do this by having the LIR send the documentation in and having it reviewed for logic. J -- James Blessing 07989 039 476

15 41

concept document: IPv6 PA/PI unification
by Gert Doering 01 Nov '11

01 Nov '11

Hi AP WG, next week at the RIPE meeting (and by remote participation, of course) I want to continue discussing an idea that came up before, and that I brought up at RIPE 62 already - doing away with the distinction between IPv6 PA and IPv6 PI space, going for a "unified number distribution policy" (to give credits, it's not exactly my original idea, but has been brought up a couple of times by members of the community in the last years). Feedback from RIPE 62 was mostly positive, with "we need to think about many details", so Sander and I sat down and tried to write a concept document that has some answers about the details - which needs to be discussed, refined, and eventually formed into a full-featured policy proposal to go through the PDP. So far, this is to start the thought process, and to get your ideas about it - especially ideas of the sort "this is not going to work *because* <detail we've overlooked>". But I'm taking "we want to keep the difference between PA and PI!" as well - but if you say so, please explain where you see the benefit of "more complicated rules". The discussion will take place on Thursday morning, in the 09:00-10:30 time slot. thanks for helping shape policy, Gert Doering -- APWG chair --------------------------------------------------------------- Motivation: why? ---------------- - PA and PI are just different labels for "IPv6 addresses" ... but with different strings attached: - PI must not be used for 3rd party assignments (problem for hosting providers) - only single PA allocation for LIRs possible, even if multiple independent networks exist - network structure and operation is very different these days than at the time where the PA/PI distinction was made. The boundaries between networks, different operators and different services are not as clear as they used to be... - the classic distinction "PA is for ISPs and their access customers" "PI is for enterprises that do not do ISP-like business" has been overcome by reality, and there are no longer clear borders between "ISP", "enterprise" and "end-customer" networks - Network addresses are for *numbering network devices*. Limiting what someone is allowed to do with certain addresses creates confusion. Constantly having to tweak policy to work around this is the wrong solution. Goals and Caveats ----------------- - encourage IPv6 deployment - be flexible enough to accommodate both typical and non-typical network- and business models - do not encourage assignment of /64 or single addresses to end users - do not encourage excessive routing table growth - encourage proper documentation and discourage lying to the RIPE NCC to wiggle around policy restrictions The Proposal ------------ - abandon distinction between PA (allocation) and PI (assignment) - everything is just "numbers" - RIPE NCC hands out "block(s) of numbers" to "users of numbers" - see below for answers on the fine print... Who get's address space? ------------------------ - existing model is kept: LIRs as distribution point for address space - either to "the LIR organization" - classic model: "LIR is part of the Internet Provider business" - or via the LIR to "the entity that wants to use the space and take responsibility for it" (sponsoring LIR), keeping the contractual requirements of 2007-01 - "Direct Assignment Users" members could still be possible, but "every NCC member is an LIR" would simplify things further (see "Costs" section) Amount of space per "block of numbers"? --------------------------------------- - /48 (or larger with justification) by default - /32.../29 (or larger with justification) allowed when planning to assign to 3rd parties - multiple "blocks of numbers" to or via a single LIR allowed and expected to be a frequently seen usage case Allocation from well-known ranges for anything that people might want to treat specially in their routing policy (former "special case" and PI policies): - IXP - Root DNS - Anycast DNS - /33.../48 blocks Cost? ----- - determined by AGM, but we can discuss models here and provide recommendations to AGM and NCC board, e.g.: * base cost per year per LIR * yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks" Multiple blocks per LIR? ------------------------ - since there would no longer be any difference between PA and PI, "more than one block going to a single LIR" would be a typical case - so it needs to be permitted - "get any number of blocks that people are asking for" is not likely to get consensus due to pressure on the routing system - proposal for compromise: ``one "block of numbers" per "network"'' - needs workable definition for "network": - interconnected network - operated by the same entity - operated as a layer 3 network - be flexible in allowing multiple blocks, but don't *require* anyone to actually ask for multiple number blocks if they are happy with using the same address block for multiple networks/sites/... - problem cases to keep in mind, leading to this definition - ISPs providing L3 services on top of other ISPs' Layer 2 infrastructure - single LIRs providing addresses to two independent Layer 3 networks that are not directly connected - e.g. due to political (commercial/NREN), legal or geographical reasons - "classical PI" type connections - end users with independent numbers - Multiple L3 providers providing address space to a single user must be allowed (multi-homing, special-purpose networks, etc.) -- have you enabled IPv6 on something today...? 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

4 7

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Florian Weimer 31 Oct '11

31 Oct '11

* Emilio Madaio: > http://www.ripe.net/ripe/policies/proposals/2011-05 I oppose this policy. IXPs shouldn't be special-cased. The assumption of a single peering LAN per organization does not seem to match the requirements of the industry. It is odd that preexisting PI space must be returned, but not existing PA space. -- Florian Weimer <fweimer(a)bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99

2 1

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Sascha Lenz 31 Oct '11

31 Oct '11

Hi, Am 25.10.2011 um 11:51 schrieb Emilio Madaio: > > > Dear Colleagues, > > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. > > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-05 > > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 22 November 2011. i'm not a fan of "special entities", but IXPs actually are a bit special and the proposal again makes some examples why, so i do support this proposal. Reserving an(other) /16 for this purpose doesn't really hurt anyone either. I am not quite sure if 180days for returning the old prefix is really enough in a world where it's hard to reach some peering partners and get reactions in under 360days :-) but i'm not an IXP operator so what do i know... I just assume it's reasonable? -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect

2 1

Re: [address-policy-wg] 2011-04 New Policy Proposal
by Ahmed Abu-Abed 28 Oct '11

28 Oct '11

In reality RIPE will be giving up a finite resource for implementing one particular type of a transition protocol, i.e. 6rd. Can't the response be go back to your vendor and ask them to implement a different transition protocol that doesn't waste address space ? After all, there are many such protocols out there. -Ahmed Date: Tue, 25 Oct 2011 11:04:20 +0200 From: "Jan Zorz @ go6.si" <jan(a)go6.si> Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal To: address-policy-wg(a)ripe.net Message-ID: <4EA67B94.2090305(a)go6.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 10/25/11 9:44 AM, Ahmed Abu-Abed wrote: > Interesting to see a v6-in-v4 access protocol triggering a significant > change in allocation policy. > > As 6rd gobbles up 32 bits for the v4 address at the consumers v6 > assignment, there is an alternative in RFC 5572 (TSP) that presents > v6-in-v4 access on CPEs without such a need. And TSP can be implemented > as a software client so LIRs do not need to change the CPEs to roll out > IPv6 to end users. Dear Ahmed, We are aware of many similar technologies that would fulfill the same or similar goal, but what we are doing here is just listen to complains and requests from the field and try to make deployment of IPv6 (native or as service in this case) as easy as possible with this change of the policy proposal. Reality usually wins :) Cheers, Jan -------------------------------------------------- From: "Ahmed Abu-Abed" <ahmed(a)tamkien.com> Sent: Tuesday, October 25, 2011 9:44 AM To: "RIPE Address Policy" <address-policy-wg(a)ripe.net> Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal > Interesting to see a v6-in-v4 access protocol triggering a significant > change in allocation policy. > > As 6rd gobbles up 32 bits for the v4 address at the consumers v6 > assignment, there is an alternative in RFC 5572 (TSP) that presents > v6-in-v4 access on CPEs without such a need. And TSP can be implemented as > a software client so LIRs do not need to change the CPEs to roll out IPv6 > to end users. > > -Ahmed > > ------------------------------ > > Message: 8 > Date: Mon, 24 Oct 2011 21:28:47 +0200 > From: "Jan Zorz @ go6.si" <jan(a)go6.si> > Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal > (Extension of the Minimum Size for IPv6 Initial Allocation) > To: address-policy-wg(a)ripe.net > Message-ID: <4EA5BC6F.90005(a)go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/24/11 7:29 PM, Randy Bush wrote: >> why are we screwing around? let's go straight to a /16 or at least a >> /20. > > it would not be fair to legacy v6 allocations :) > > can only expand to /29 without renumbering :S > > cheers, Jan >

7 9

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Tom Bird 28 Oct '11

28 Oct '11

On 25/10/11 10:51, Emilio Madaio wrote: > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-05 Morning, I support this proposal. -- Tom Bird Director, http://www.portfast.co.uk/ : AS8916 UK Limited company #6061075 : +44 1777 29 28 27

6 6

Re: [address-policy-wg] [policy-announce] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by David Croft 28 Oct '11

28 Oct '11

On 25 October 2011 10:51, Emilio Madaio <emadaio(a)ripe.net> wrote: > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. I support this proposal as written. Regards, David Croft

1 0

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Andy Davidson 28 Oct '11

28 Oct '11

> You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-05 I support this proposal. -harald > > We encourage you to review this proposal and send your comments to > <address-policy-wg at ripe.net> before 22 November 2011. -- Harald Michl <harald.michl(a)univie.ac.at> Vienna University - ACOnet www.ACO.net - VIX www.VIX.at Universitaetsstrasse 7, A-1010 Vienna, Austria, Europe Tel: +43 1 4277 - 14078 (Fax: - 9140) HM3550-RIPE

3 2

Removal of multihomed requirement for IPv6 PI ?
by DI. Thomas Schallar 28 Oct '11

28 Oct '11

Hello! Four days ago the current phase on http://www.ripe.net/ripe/policies/proposals/2011-02 ended (Sep.26th-Oct.24th). What now? regards, Thomas

2 1

2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Steven Bakker 28 Oct '11

28 Oct '11

Just piping in to say I support this proposal. -- Steven

1 0

2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Michiel Appelman 28 Oct '11

28 Oct '11

I fully support the new policy proposal. -- Michiel Appelman AMS-IX

1 0

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Nigel Titley 27 Oct '11

27 Oct '11

On 25/10/2011 10:51, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. > I hate to be a killjoy here, but doesn't the average IXP use less than a /22? Part of the rational says: "Much of the work that goes into creating Internet Exchange Points today is done in regions of the world where there is no Internet Exchange Point yet. Opening an IXP helps to develop the Internet and Internet community in that region, so the work really is 'good of the Internet'. Starving these regions of an opportunity to build a simple open Internet Exchange Point would be severely damaging to Internet users in regions under-served by IXPs." But a brand new IXP will be able to get a /22 under the existing rules. Surely that's enough? I have a general dislike of "special cases" especially where they don't seem to be necessary. And this seems to be unnecessary. Nigel

3 7

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Barry O'Donovan 27 Oct '11

27 Oct '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/10/11 10:51, Emilio Madaio wrote: > A proposed change to RIPE Document ripe-530, "IPv4 Address > Allocation and Assignment Policies for the RIPE NCC Service > Region", is now available for discussion. We support this policy. - Barry - -- Kind regards, Barry O'Donovan http://www.opensolutions.ie/ Open Source Solutions Ltd Lynx House, Old Church Road, Lower Kilmacud Road, Stillorgan, Co. Dublin. Open Source Solutions Limited is a company registered in the Republic of Ireland (#438231). Open Source Solutions Limited trades as Open Solutions (registered business name #329120). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ppK0ACgkQ9qwC7To4L8xItACdEfwnvF3KijY7um0Pba0/VfsQ ly0An1TO9dfQfDjKm9TCDt4kexwS589H =uiRD -----END PGP SIGNATURE-----

1 0

2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Vincent PAGES 27 Oct '11

27 Oct '11

HI, I'm the technical manager of LyonIX (Lyon Internet Exchange http://www.lyonix.net) We support the proposal. Regards, -- Vincent PAGES - Responsable Technique Rezopole - Lyonix Rezopole inaugure SaintetIX le 17 Novembre 2011 Mail: vpages(a)rezopole.net Standard: +33 4 27 46 00 50 Fax: +33 4 27 46 00 51 PGP: 7E06128C Skype: vincent.rezopole REZOPOLE (LYONIX Le GIX NAP de Lyon / Rhone-Alpes) 5 passage de l'avenir 69200 Vénissieux France - Email : info(a)lyonix.net - Web : www.lyonix.net

1 0

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Tom Hodgson 27 Oct '11

27 Oct '11

On Tue, 25 Oct 2011, Emilio Madaio wrote: > > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. > I do wonder how many special cases we will see crop up before we've let v4 exit stage left, however the benefits brought by the reservation of a /16 for increased network interconnection I think justify the addition to the policy. There is a question of whether the IXP should just become an LIR to receive an allocation that way, however I neither believe that an IXP should be forced into becoming an LIR or that all IXPs necessarily have an appropriate entity with which to do so, especially when they are in the startup phase. Therefore I support this policy. -- Tom Hodgson tom(a)someaddress.net

4 3

Proposal 2011-02 moving to Last Call
by Sander Steffann 26 Oct '11

26 Oct '11

Hello working group, After a extensive analysis of the discussions on the mailing list about proposal 2011-02 we have come to the conclusion that we have rough consensus on this policy proposal, and we have decided to move this policy proposal to Last Call. We have seen much support for this proposal on the mailing list. On the other hand we have seen concern about accelerated growth of the routing table caused by implementing this policy. Data from other RIRs that have a more liberal IPv6 PI policy have not shown evidence for excessive growth in IPv6 PI assignments. As of today, Sep 23, there are 2420 /48 routes in the global BGP table, compared to 3600 /32 routes and ~1100 routes of other prefix lengths. Based on this data we consider the arguments agains this proposal based on possible routing table growth as addressed. We will ask the RIPE NCC to ask for extensive documentation in the IPv6 PI request form about why IPv6 PI space is requested instead of PA space. The intention of this is to be able to analyze the reasons for organizations to request PI space and to make requesters think twice when requesting PI space. If this policy proposal has consensus at the end of Last Call we will also ask the RIPE NCC to monitor and regularly report on IPv6 PI assignment statistics so we can see if the number of PI requests runs out of bounds. On behalf of the Address Policy WG chairs, Sander Steffann

25 81

AP WG Agenda for RIPE63
by Gert Doering 26 Oct '11

26 Oct '11

Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Amsterdam in the following three time slots: Wednesday, Nov 02, 09:00 - 10:30 Wednesday, Nov 02, 11:00 - 12:30 Thursday, Nov 03, 09:00 - 11: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. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Emilio Madaio - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE61 [list of things that the WG chairs collective agrees on] - brief overview over new proposals (2011-04, 2011-05) C. Policy Development Office Activities - Emilio Madaio D. Feedback From NCC Registration Service - Alex le Heux (Emilio and Alex will give the WG some insights on policy development topics from the NCC side) E Discussion of open policy proposals, part I 2011-02 IPv6 PI assignment policy / removal of multihoming req. (current status, by the AP WG chairs) 2011-04 initial IPv6 allocation size / 6rd (Jan Zorz) ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- J. Welcome back K. Discussion of open policy proposals, part II 2011-05 IPv4 Assignments to IXPs from the Last /8 (Andy Davidson, representing the EIX WG) L. on (Inter-RIR) transfers - Dave Wilson (tbc) M. IPv4 maintenance policy - Rob Blokzijl Introduction to a Work-in-Progress document about governance of IPv4 resources in the RIPE region after run-out + Q&A. N. On Renumbering IPv6 networks - N.N. [ report from the discussion in the IPv6 WG on Tuesday ] O. On Certificates - from the APWG chair [ what happened, and what next ] ---------------------------------------------------------------------- Thursday, 09:00-10:30 ---------------------------------------------------------------------- R. On IPv6 PI/PA Unification Discussion how the IPv6 PA/PI policies can be reworked in a fundamental way to better fit the needs of all IPv6 Users. Discussion led by working group chairs. S. Rough Edges of the current policies "if things show up" T. Discussion of open policy proposals "if we need more time" 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 -- have you enabled IPv6 on something today...? 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

1 1

Policy Proposal: 2006-05 "PI Assignment Size" implemented
by Matt Parker 26 Oct '11

26 Oct '11

[Apologies for duplicate emails] Dear Colleagues, We are pleased to announce that the policy described in proposal 2006-05, "PI Assignment Size", has been implemented. Requests for IPv4 Provider Independent (PI) address space received on or after Wednesday, 27 October 2011, will be evaluated by the RIPE NCC Registration Services Department under the new policy. The RIPE policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2006-05 The following RIPE Documents have been updated to reflect this policy implementation: http://www.ripe.net/ripe/docs/ipv4-policies http://www.ripe.net/ripe/docs/pi-requestsupport Regards, Matt Parker RIPE NCC Registration Services

1 0

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Remco Van Mook 26 Oct '11

26 Oct '11

Hi all, As I already indicated when this was last presented at the RIPE meeting, I strongly support a proposal to this end. The one thing I'm missing is the criteria for the size of the assignment - when does an IXP get a /24, /23 or a /22? With 'run out fairly' as accepted policy I don't think the timeframes set there are in any way realistic for Internet exchanges. So, clean as the current proposal is, I'd suggest making it a bit messier and adding very explicit criteria. With some first hand experience in setting up Exchanges, I would suggest the following: - a new IXP gets a /24 - an existing IXP that runs out of its /24 (whether from this /16 or another range) gets a /23 and has to return the old /24 - an existing IXP that runs out of its /23 (whether from this /16 or another range) gets a /22 and has to return the old /23 (Yes, this means renumbering every single time. Yes, it's a pain. Yes, if you run out of a /22 for your peering LAN you're fresh out of luck.) And while we're at it, I would suggest to add to 5.6.4: c. Any address space that is returned by an IXP will be added to the reserve as outlined in 5.6.2. Sorry :) Best, Remco van Mook Director of Interconnection, Europe remco.vanmook(a)eu.equinix.com +31 61 135 6365 MOB EQUINIX 51-53 Great Marlborough Street London, W1F 7JT, United Kingdom On 25-10-11 11:51, "Emilio Madaio" <emadaio(a)ripe.net> wrote: > > >Dear Colleagues, > >A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation >and Assignment Policies for the RIPE NCC Service Region", is now >available for discussion. > > > >You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-05 > >We encourage you to review this proposal and send your comments to ><address-policy-wg(a)ripe.net> before 22 November 2011. > >Regards > >Emilio Madaio >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, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.

3 3

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Martin Millnert 26 Oct '11

26 Oct '11

Hi, On Oct 25, 2011, at 11:51, "Emilio Madaio" <emadaio(a)ripe.net> wrote: > http://www.ripe.net/ripe/policies/proposals/2011-05 I support this policy. I do have a question for clarification: andy, you speak about "peering LAN" in singular. How is the policy to be interpreted by the IPRAs for IXPs requesting space for different-size MTU peering LANs? A luxury we can't afford after runout, or? Best, Martin

2 1

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Dan Luedtke 26 Oct '11

26 Oct '11

I support this proposal. One question: Is it the same /16 in 5.6.2 as in 5.6.3? Or does that mean that two /16 will be held back? regards. danrl -- Dan Luedtke http://www.danrl.de

3 2

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Brian Nisbet 25 Oct '11

25 Oct '11

On 25/10/2011 10:51, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. > > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-05 I support this policy. Brian.

1 0

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by boggits 25 Oct '11

25 Oct '11

On 25 October 2011 10:51, Emilio Madaio <emadaio(a)ripe.net> wrote: > http://www.ripe.net/ripe/policies/proposals/2011-05 > I support this policy J -- James Blessing 07989 039 476

1 0

2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Emilio Madaio 25 Oct '11

25 Oct '11

Dear Colleagues, A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-05 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 22 November 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] 2011-04 New Policy Proposal
by Ahmed Abu-Abed 25 Oct '11

25 Oct '11

Interesting to see a v6-in-v4 access protocol triggering a significant change in allocation policy. As 6rd gobbles up 32 bits for the v4 address at the consumers v6 assignment, there is an alternative in RFC 5572 (TSP) that presents v6-in-v4 access on CPEs without such a need. And TSP can be implemented as a software client so LIRs do not need to change the CPEs to roll out IPv6 to end users. -Ahmed ------------------------------ Message: 8 Date: Mon, 24 Oct 2011 21:28:47 +0200 From: "Jan Zorz @ go6.si" <jan(a)go6.si> Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation) To: address-policy-wg(a)ripe.net Message-ID: <4EA5BC6F.90005(a)go6.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 10/24/11 7:29 PM, Randy Bush wrote: > why are we screwing around? let's go straight to a /16 or at least a > /20. it would not be fair to legacy v6 allocations :) can only expand to /29 without renumbering :S cheers, Jan

2 1

Re: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation)
by Remco Van Mook 24 Oct '11

24 Oct '11

All, I support the thought that LIRs should be able to get up to a /29 as an initial allocation with no documentation required. However, that doesn't mean I support the policy proposal in its current form. Here's why. In the current policy text, it's very clear cut that unless you provide documentation (which means you've thought about how to deploy), you get a /32. I would not want a situation where people get a /29 without thinking, making a mess of it and then come back. So you could get a /29 if you asked for it specifically, otherwise you get a /32. So I would propose the following: Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For initial allocations up to /29 no additional documentation is necessary. Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure. --snip-- And, of course, using up your /29 in one go means no additional adjacent reserved address space on the RIPE NCC books, but that's an implementation issue :) Best Remco van Mook Director of Interconnection, Europe remco.vanmook(a)eu.equinix.com +31 61 135 6365 MOB EQUINIX 51-53 Great Marlborough Street London, W1F 7JT, United Kingdom On 21-10-11 12:44, "Emilio Madaio" <emadaio(a)ripe.net> wrote: > >Dear Colleagues, > >A new RIPE Policy Proposal has been made and is now available for >discussion. > >You can find the full proposal at: > > www.ripe.net/ripe/policies/proposals/2011-04 > >We encourage you to review this proposal and send your comments to ><address-policy-wg(a)ripe.net> before 18 November 2011. > >Regards > >Emilio Madaio >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, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.

3 2

Re: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation)
by Sascha Lenz 24 Oct '11

24 Oct '11

Hi, > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > www.ripe.net/ripe/policies/proposals/2011-04 > > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 18 November 2011. Short: I support it. Long: well, i'm one of those guys who prefer to implement native IPv6 from scratch and skip all those crappy transition methods completely. It actually works im my world. ...but unfortunately(?) my world is huge corporate networks and rather small scale ISPs, haven't worked for a big ISPs for a decade now, so i guess there could be a case for 6rd somewhere else. It's a little awkward that the proposal mentions "small ISPs", because with small ISPs there shouldn't be a problem to implement native IPv6... Anyways, the reason why i do support the proposal is just getting the additional bits for proper subnetting, that actually is a little PITA if you're a "not-big-yet-but-not-so-little-anymore"-type ISP. Doing network design meant to last more than some years the right way is a little hard there with a /32 sometimes. So i would welcome /29s instead of /32s. I cannot always justify more than an initial /32 at the moment. If that also helps with 6RD deployments, and it certainly does, sure, good thing. I don't see any downside of that since even for the earlier Allocations this was reserved already. But we should be clear here: /29 should be the end of the road for "no documentation needed". -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect

1 0

2011-03 Proposal Accepted (Post-depletion IPv4 address recycling)
by Emilio Madaio 21 Oct '11

21 Oct '11

Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-528, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-03 The updated RIPE policy document is ripe-530 and is available at: http://www.ripe.net/ripe/docs/ripe-530 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation)
by Emilio Madaio 21 Oct '11

21 Oct '11

Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: www.ripe.net/ripe/policies/proposals/2011-04 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 18 November 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2011-01 Proposal Accepted (Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA)
by Emilio Madaio 20 Oct '11

20 Oct '11

Dear Colleagues, Consensus has been reached, and the proposal described in 2011-01, "Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA", has been accepted by the RIPE community. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-01 The new RIPE document is ripe-529 and is available at: http://www.ripe.net/ripe/docs/ripe-529 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2006-05 Proposal Accepted (PI Assignment Size)
by Emilio Madaio 20 Oct '11

20 Oct '11

Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-527, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-05 The updated RIPE document is ripe-528 and is available at: http://www.ripe.net/ripe/docs/ripe-528 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Items for the AP WG meeting agenda?
by Gert Doering 11 Oct '11

11 Oct '11

Hi APWG folks, RIPE 63 is nearing, and Sander and I are working on the agenda for the meeting. We have three time slots: Wednesday, 09:00-12:30, and Thursday, 09:00-10:30, so we have plenty of time to discuss things that *you* want to see discussed... So far the agenda has all the usual stuff (reporting on the PDP, discussion of open policy proposals), which will be published in the next days - we're still working on details, and waiting for some confirmations. If there is anything non-standard that you want to see, please let me or Sander know. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? 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

1 0

2008-08 Policy Proposal Withdrawn (Initial Certification Policy in the RIPE NCC Service Region)
by Emilio Madaio 03 Oct '11

03 Oct '11

Dear Colleagues, The proposal 2008-08, "Initial Certification Policy in the RIPE NCC Service Region", has been withdrawn. It is now archived and can be found at: http://www.ripe.net/ripe/policies/archived-policy-proposals Reason for withdrawal: after carefully following the discussion in the Concluding Phase of the Policy Development Process, the proposer is of the opinion that consensus on this proposal is not possible within the RIPE community. As a consequence, the proposer has decided to withdraw the proposal. Regards Emilio Madaio Policy Development Officer RIPE NCC

14 27