- address-policy-wg - mailman.ripe.net

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

02 Nov '11

On 21 October 2011 12:44, Emilio Madaio <emadaio(a)ripe.net> wrote: > 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. Hi On the premises that there are no protocol specific comments in the policy then I support this proposal too. This should be a matter of address assignment policy only. Based on a mixture of /56 and /48 assignments to users it's easily possible for a medium to large ISP to need more than a /32. Also, increasing allocation sizes can only do good things for the IPv6 DFZ. -- Daniel Holme

1 0

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

02 Nov '11

On Tue, Oct 25, 2011 at 11:51:26AM +0200, Emilio Madaio wrote: > > http://www.ripe.net/ripe/policies/proposals/2011-05 > I, too, support this proposal (Disclosure: We operate an IXP) Kind Regards, Sascha Luck

1 0

2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Kjetil Otter Olsen 02 Nov '11

02 Nov '11

We (Norwegian Internet eXchange) support this proposal. Best regards, Kjetil Otter Olsen, NIX.no

1 0

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 Daniel Holme 01 Nov '11

01 Nov '11

On 25 October 2011 11: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. > http://www.ripe.net/ripe/policies/proposals/2011-05 Hi I support this proposal. -- Daniel Holme Kcom

1 0

2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Rolf Schärer 01 Nov '11

01 Nov '11

+1 I support the proposal Cheers, Rolf ------------------------------------------------------------------------------- netspring gmbh rolf schärer, ccie #17218 alte gasse 4 rolf.schaerer(a)netspring.ch 8610 uster, switzerland Tel: +41 44 500 79 70

1 0

2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Basile Bluntschli 01 Nov '11

01 Nov '11

+1 i support the proposal -- s w i s s i x - Swiss Internet Exchange Basile Bluntschli Board Member

1 0

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