Hi all I support this proposal +1 From my background as Chair of the Swiss IPv6 Council and many years of working with large organizations such as enterprises and governments, I know that basing an allocation size on number of users and size of network is not sufficient and does not allow them to create address plans that meet their various requirements. I think the RIPE NCC needs an open framework to be able to make meaningful allocations to such organizations, and thereby support and maybe even accelerate the deployment of IPv6 in the RIPE region. I therefore support it. Silvia Chair Swiss IPv6 Council -----Ursprüngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] Im Auftrag von LIR (BIT I 5) Gesendet: Donnerstag, 7. Mai 2015 11:57 An: Address Policy Working Group Betreff: Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) Hello, I agree with this opinion. Therefore: +1 Carsten LIR de.government -----Ursprüngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] Im Auftrag von James Blessing Gesendet: Dienstag, 28. April 2015 14:20 An: Address Policy Working Group Betreff: Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) On 28 April 2015 at 13:00, Marco Schmidt <mschmidt@ripe.net> wrote:

The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure.

https://www.ripe.net/participate/policies/proposals/2015-03

Support at current stage - may change after seeing IA J -- James Blessing 07989 039 476

On 11/05/2015 11:10, Gert Doering wrote:

I see "/32 as default, up to /29 if you ask" as very reasonable middle ground...

/29 gives 2^19 /48s, or a little over 500k /48s or 134 million /56s. Before supporting this proposal, I'd be interested to see a real life addressing plan which needed more than this amount of bit space. Nick

Hi Nick,

-----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Nick Hilliard Sent: 11 May 2015 14:08

On 11/05/2015 11:10, Gert Doering wrote:

...

I see "/32 as default, up to /29 if you ask" as very reasonable middle ground...

/29 gives 2^19 /48s, or a little over 500k /48s or 134 million /56s.

Before supporting this proposal, I'd be interested to see a real life addressing plan which needed more than this amount of bit space.

That is a perfectly reasonable question to ask (assuming it was effectively a question!). My difficulty however is adequately answering it without inadvertently releasing too much information about the UK MOD's infrastructure to a public mailing list. That is no one's problem but my own though so let me see how far I can get by at least covering some of the key principles. One clarification to get out of the way first given that this branch of the thread was a slight diversion from the core topic is that I am not looking at changing the '/32 as default, up to /29 if you ask' position as, like Gert, I agree that this is a very sensible default position. The issue presented is how to deal with those organisations who cannot fit within a /29, of which the UK MOD is one... As context for those not familiar, the UK MOD and Armed Forces are a large and complex organisation with an annual budget of over £37 billion (€52 billion) which puts it in the world's 'top 5' militaries by such a measure. Its global IP infrastructure spans land, sea, air and space environments using practically all conceivable physical layer transport type. From an IPv6 addressing perspective, the best place to start is arguably with the end sites. There are 10's of thousands of end sites encompassing what you might regard as 'conventional' sites (office/corporate environments, datacentres, military bases, dockyards etc) as well as military platforms (tanks, aircraft, ships etc) some of which could be regarded as enterprises in their own right (e.g. aircraft carriers). These end sites achieve their wider connectivity via ISPs (generally, but not exclusively, 'private' ISPs whose services are exclusive to the UK MOD) of which there are hundreds in each different geographic operating area (fixed UK, fixed overseas, deployed etc). Most end sites would connect to multiple ISPs, either simultaneously or varying over time (long term infrastructure changes down to short term connectivity changes in support of operations) and there is expected to be a mix of how to deal with this from an addressing perspective (readdressing, multiple prefixes, mobile IP, etc). In order to achieve aggregation and efficiency of routing (within the MOD, to other nations' militaries and to the Internet) this 'geographic area > ISP > end site' hierarchy becomes a key part of the addressing strategy. It is not a flat network and cannot be treated as one by the addressing strategy hence a straightforward 'number of end sites' calculation does not result in sufficient address space to be allocated. The issue is further compounded by the fact that the UK MOD must abide by national security policy which requires that ALL information that is generated, collected, stored, processed or shared is afforded the appropriate degree of protection according to its sensitivity and level of threat it faces. Security classifications are used to categorise the different levels of sensitivity/threat and effective delivery of these lead to the requirement to operate completely independent infrastructures with discrete routing policies for each classification hence multiple allocations are effectively required. The option of 'luxuries' such as semantics, nibble boundaries, 'just in case' expansion bits etc do not feature in the UK MOD's IPv6 addressing strategy - it is very much a 'minimum fit'. Whilst it is recognised that such practices might be sensible and commonplace in many organisations who achieve the default /32-/29 allocation we must acknowledge that when operating in the high order bit space we need to be aware of the disproportionate impact that such approaches would have. Even though I may have been vague with the numbers and specifics, does it help shed any light on how we might struggle to fit into a /29 allocation? In many respects, for us I feel that the fact there are >500k /48's in a /29 is similar to the fact that a /64 subnet has 2^64 addresses within it - it doesn't necessarily mean what the figures might otherwise first suggest! Regards, Mathew

Hi Jan, -----Original Message-----

From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Jan Ingvoldstad Sent: 12 May 2015 12:33

How do you manage your IPv4 space, then?

Not wishing to sound flippant, but the answer to that really is 'with some difficulty'. This is despite being in the fortunate position of holding a /8 IPv4 allocation (amongst other, smaller, ranges) in addition to widespread usage of (overlapping) RFC1918 address space.

Do you actually have routing that needs more than 8 total IPv4 spaces?

I cannot answer that directly because it is, in my view, a false dichotomy as it is far more complicated a situation than that. Besides which, migration to IPv6 would be a wasted opportunity if it was rolled out and configured in exactly the same way as IPv4 given all the existing problems and constraints that would continue to persist. Regards, Mathew

Hi,

On 12 May 2015, at 14:18, Jan Ingvoldstad <frettled@gmail.com> wrote:

On Tue, May 12, 2015 at 2:26 PM, Mathew Newton <Mathew.Newton643@official.mod.uk <mailto:Mathew.Newton643@official.mod.uk>> wrote: Hi Jan,

Hi again, Matthew, and thanks for answering.

-----Original Message-----

...

From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net <mailto:address-policy-wg-bounces@ripe.net>] On Behalf Of Jan Ingvoldstad Sent: 12 May 2015 12:33

...

How do you manage your IPv4 space, then?

Not wishing to sound flippant, but the answer to that really is 'with some difficulty'. This is despite being in the fortunate position of holding a /8 IPv4 allocation (amongst other, smaller, ranges) in addition to widespread usage of (overlapping) RFC1918 address space.

...

Do you actually have routing that needs more than 8 total IPv4 spaces?

I cannot answer that directly because it is, in my view, a false dichotomy as it is far more complicated a situation than that.

What it does give you, is the opportunity to create 2048 times the amount of routes you could in your current IPv4 /8, without worrying about the things you could do in your internal networks with the remaining part of the /64.

Besides which, migration to IPv6 would be a wasted opportunity if it was rolled out and configured in exactly the same way as IPv4 given all the existing problems and constraints that would continue to persist.

Oh, I agree with that. Over here, we actively abuse the system by randomly generating /80 addresses for internal use, and reusing those in ways that apparently never were intended by those who designed the IPv6 address specification.

What I do think is a problem, though, is that IPv6 address space is considered so plentiful that we're repeating the mistakes of when we thought the IPv4 address space was plentiful.

I don't see a big problem with RIPE NCC evaluating requests for allocations up to e.g. /24 in some very rare cases.

However, these things have a way of sliding down a slippery slope, and the IPv6 address space is most likely what we're going to be stuck with for our systems' lifetimes. The prospective system lifetimes are long, perhaps on the order of hundreds of years.

And that's actually something we need to keep in mind when setting policy today.

We’re to date only allocating from 1/8th of the overall IPv6 address space. There’s 7/8ths remaining in which policy can be changed, if required. And I would put a bet on IPv6 not being the mainstream global / interplanetary communication protocol in hundreds of years, but I won’t be around to collect, so…. On the /64 boundary, I’d point you at RFC7421. Tim

On May 12, 2015, at 09:07, Jan Ingvoldstad <frettled@gmail.com> wrote:

...

On Tue, May 12, 2015 at 3:40 PM, Tim Chown <tjc@ecs.soton.ac.uk> wrote: ..... On the /64 boundary, I’d point you at RFC7421.

Well, I guess that's a nice document to point people to, if they're unfamiliar with the history of IPv6 and the issues that have been raised. I'll be sure to mention it if I run into someone who needs it, thanks!

I'd like to call you attention to the following paragraph from the end of section 2 of RFC7421; The remainder of this document describes arguments that have been made against the current fixed IID length and analyzes the effects of a possible change. However, the consensus of the IETF is that the benefits of keeping the length fixed at 64 bits and the practical difficulties of changing it outweigh the arguments for change. The point being that neither RIPE nor the other RIRs are the place to discuss changes to the IPv6 architecture. If you feel changes to the IPv6 architecture needed, you need to participate in discussions in the IETF v6ops and 6man working groups. It would have been helpful to have added your voice in the the discussion of the Why64 draft that became RFC 7421. There was a lively discussion, but the paragraph above accurately reflects the current consensus. Participation in the discussion at the IETF is really the only way to change that consensus. Thanks -- =============================================== David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 ===============================================

On Wed, May 13, 2015 at 11:56 AM, Roger Jørgensen <rogerj@gmail.com> wrote:

Are work being done in several forums on interplanetary communication, both with thoughts on delay and on address space. AFAIK some of it is already in production to using IPv6... wish my memory worked today so I could remember where I saw that discussion :-(

In the more immediate future, I think the main concern will be IOT-related. (IOT = Internet of Things) While this is a bit of a lame buzzword now, something on the scale of what Manfred Macx et al have in the early chapters of Charles Stross's Accelerando, may very well be how things work in a couple of decades. It's hard to predict. In any case, what's most important to us now, is to at least be aware of the potential challenges, and not enact policies that will make the future much more difficult. And, again, I don't think the proposal discussed here poses such a problem. -- Jan

Hi, On Tue, May 12, 2015 at 03:18:15PM +0200, Jan Ingvoldstad wrote:

And that's actually something we need to keep in mind when setting policy today.

Actually, I am (and I'm having an wary eye on the community :-) ). But I *do* the math. We're inside the very first /12 ever assigned to the NCC, and that is inside the FP 001 - so comparing the number of possible consumers of "huge address blocks" (MoDs, incumbents, ...) - basically, "a few per country in the RIPE region", totalling "a few hundred" - with the number of /24s inside the /12 (4096), this seems to be withing acceptable bounds (well, split the /12 into 2048 /24s and 65000 /29s, so "there is still enough for smaller LIRs"). And if the /12 fills up, we have 507 left inside FP001. And if *that* fills up, we get 6 more tries on a more conservative side. So, yes, I think we're making good use of the available space, but we're not overdoing it... Gert Doering -- community member -- 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 (0)89/32356-444 USt-IdNr.: DE813185279

On Mon, May 11, 2015 at 11:10 AM, Gert Doering <gert@space.net> wrote:

Slightly off-track, but you made me curious. Given the number of /29s and /32s available in FP001, and the potential numbers of LIRs in the future (like, things explode and we'll see 100.000 LIRs) - where do you see the problem with our allocation sizes?

It's the old argument about quadrillions upon quadrillions (and more), and how it's setting up for possible future failure in a way that's going to be impossible to reverse at a later point in time. I do think it's too late to put the cat back in the bag, at least for large parts of how IPv6 addressing is handled, but I also don't think we need to compound failure with failure. I think we should balance between "too big" (aka: FP001 fills up, and

new LIRs won't be able to get what they need [or we start using FP010]) and "too small" (aka: LIRs will have to squeeze inside, and resort to unwanted behaviour, like "give customers only a single /64" or even "single /128").

I'm not sure that this is undesirable behaviour. If it's undesirable, it's because the entire system has been rigged to create the situation where it is undesirable, and then that is used as an excuse for what I consider excesses.

I see "/32 as default, up to /29 if you ask" as very reasonable middle ground...

It is far more than reasonable, and even though someone can legitimately claim that they are making a setup where they can _use_ the entire IPv6 address space themselves by creating some convoluted network segmenting scheme, it doesn't mean it's reasonable to do so. Sure, having a /32 or greater permits us to easily use hexadecimal notation for 4-bit granularity network segmenting. I remain unconvinced, though, that this is necessary, even with an internet of things that's on the level of Karl Schroeder's Ventus. The change in policy text doesn't do anything about the practical limit, except leaving more up to the good minds at the NCC to consider this. Ideally, I'd think that there should be a hard limit at /29, and that there should be very good reasons – reasons that need to be taken as a policy debate or something like that – to go beyond that size. As Nick states, "I'd be interested to see a real life addressing plan which needed more than this amount of bit space." I'd actually be interested to see a real life addressing plan that needed a /32 bit address space, where the need isn't constructed based on the mere possibility of getting that space instead of merely e.g. a few hundre million times of the entire IPv4 space. -- Jan

On 11/05/2015 16:36, Mikael Abrahamsson wrote:

On Mon, 11 May 2015, Jan Ingvoldstad wrote:

...

As Nick states, "I'd be interested to see a real life addressing plan which needed more than this amount of bit space." I'd actually be interested to see a real life addressing plan that needed a /32 bit address space, where the need isn't constructed based on the mere possibility of getting that space instead of merely e.g. a few hundre million times of the entire IPv4 space. -- Jan

Since it's perfectly valid to ask for /48 per customer, with companies having tens of millions of customers, it's not a problem to motivate larger than /29.

The proposed change doesn't change this at all as far as I can tell.

this is already catered for in the existing policy, though. Nick

On Mon, May 11, 2015 at 4:50 PM, Sander Steffann <sander@steffann.nl> wrote:

Hi Jan,

...

I'd actually be interested to see a real life addressing plan that needed a /32 bit address space, where the need isn't constructed based on the mere possibility of getting that space instead of merely e.g. a few hundre million times of the entire IPv4 space.

Giving significantly more than a single /64 to a single (home) user is part of the way IPv6 was designed. A /48 was a standard size from RFC 3177. It's successor RFC6177 is the current BCP. When working according to that BCP a /32 and even a /29 is really not that much.

If you don't agree with an RFC/BCP then this is not the place to deal with that...

I'll be sure not to answer when asked the next time, thanks. :P -- Jan

On Mon, May 11, 2015 at 03:58:46PM +0200, Jan Ingvoldstad wrote:

As Nick states, "I'd be interested to see a real life addressing plan which needed more than this amount of bit space." I'd actually be interested to see a real life addressing plan that needed a /32 bit address space, where the need isn't constructed based on the mere possibility of getting that space instead of merely e.g. a few hundre million times of the entire IPv4 space.

The way I read the proposal, it is not about assignment sizes but about a "aggregation" vs "conservation" conflict. The proponents have, AIUI, a problem where they might not fully assign a /32 or /29 allocation but have different routing policies for parts of their network, which cannot be satisfied without violating s3.4 of ripe-641. rgds, Sascha Luck

On Tue, May 12, 2015 at 01:28:39PM +0200, Jan Ingvoldstad wrote:

Apparently, my point was not very reader friendly, so I'll try again: Routing-wise, someone with 64 billion billion billion addresses, have about 16 billion billion ways to route the entire IPv4 internet, within the address space constraints of a /32 allocation.

In theory, yes. But the policy currently contradicts itself to an extent. Section 3.8 of ripe-641 clearly states: "In IPv6 address policy, the goal of aggregation is considered to be the most important." ss3.4 and 3.5 bear that out also. Yet, s5.1.2 seems to exclude aggregation as a valid reason for an allocation. The Proposal merely attempts to remove this contradiction. rgds, Sascha Luck

On Tue, May 12, 2015 at 03:09:16PM +0200, Jan Ingvoldstad wrote:

Well, yes, that's why I first wrote "This change makes sense … I support it". -- Jan

Oh yes, so you did. Should have read further up in the thread... cheers, Sascha Luck

On 13.05.2015 11:43, Mick O Donovan wrote:

Having listened to the rationale in person for this proposal I would give tentative support to this proposal on the basis that the request provides appropriate justification.

At this point I want to mention, that NCC-Staff is doing (and have always been doing) a very good job reviewing requests for resources. And although I was kind of p*ssed on one or another request back because of not good enough formulated justification, I am happy that they did it. Thanks for this! For the ones asking for more conservation: I know a bunch of LIRs who received a /29, as /29 currently does not need any justification. I also know that those LIR will never ever use more than a /48 or /40 ... so if we care that much about conservation now, I am sure that those few (we are currently talking about 10 Requests and about 45 currently allocated <= /28) requesters of larger V6-Space are nothing against the amount of /29 assignments which will never be used. Best regards -- Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo@opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989