On 10/21/11 2:02 PM, boggits wrote:

On 21 October 2011 12:42, Gert Doering<gert@space.net> wrote:

...

I'm not exactly sure how you're proposing to modify this? "Special case for 6rd only"?

Send a guidance note...

"Dear IPRAs,

The AP-WG believe that 6RD as discussed in RFC5969 is a valid reason to request more than a /32 in order to give end user networks a sensible level of address space but please make sure that requests above a /29 have followed the correct mathematical calculations.

Love The AP-WG"

... this doesn't require a change to the policy (correct me if I'm wrong) and stops people just requesting a /29 without a challenge.

Hi, We went through long discussion regarding this and this also needs a change of a policy, making one particular technology special. The common voice from community was "please, don't make 6rd special, because we don't know what follows". And, /29 is not a considerable waste of space, specially if we know that legacy IPv6 initial allocations were done with /29 reservation, so that place is there and will not be used by anyone else other than LIR, that got /32 from the beginning of this reservation. Why not making IPv6 more easily deployable, without those restrictions from IPv4 and legacy thinking about maximum conservation? Cheers, Jan

Sound like a good idea to make it easier to get a /29, but Michael Adams had one sentence that I think I've heard before..... On Mon, Oct 24, 2011 at 10:02 AM, Michael Adams <madams@netcologne.de> wrote: <snip>

I'm conviced a /29 will be very helpful for proper addressing plans and I'm strongly supporting this proposal.

Isn't that almost the same that was said when we went from /35 to /32, and now again when we go to /29? Nothing wrong in that, the world keep growing so it's just fair the address-space grow with it. -- Roger Jorgensen           | rogerj@gmail.com          | - IPv6 is The Key! http://www.jorgensen.no   | roger@jorgensen.no

Hi, On Mon, Oct 24, 2011 at 10:41:40AM +0200, Mikael Abrahamsson wrote:

On Mon, 24 Oct 2011, Roger Jørgensen wrote:

...

Isn't that almost the same that was said when we went from /35 to /32, and now again when we go to /29? Nothing wrong in that, the world keep growing so it's just fair the address-space grow with it.

Haven't we already reserved the encompassing /29 per initial /32 the past few years?

Yes.

Does this proposal suggest that a /26 should be reserved for an initial allocation of /29?

It doesn't say so (otherwise it would have been written down :) ), but since the NCC has moved from "allocate linearily, always leaving 3 bits in reserve" to "binary chop", no reservations are needed anymore (or, phrased differently, "reservations automatically use all the space still available"). If you look at the stats files, this is nicely visible in recent allocations: ripencc|FI|ipv6|2a03:9b80::|32|20111011|allocated ripencc|PT|ipv6|2a03:9c80::|32|20111011|allocated ripencc|SE|ipv6|2a03:9a80::|32|20111011|allocated ripencc|GB|ipv6|2a03:9e80::|32|20111012|allocated ripencc|RS|ipv6|2a03:9d80::|32|20111012|allocated ripencc|DE|ipv6|2a03:a080::|32|20111013|allocated ripencc|FI|ipv6|2a03:9f80::|32|20111013|allocated ripencc|IT|ipv6|2a03:a280::|32|20111014|allocated ripencc|IT|ipv6|2a03:a380::|32|20111014|allocated ripencc|RU|ipv6|2a03:a180::|32|20111014|allocated 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

Hi there, On 24 Oct 2011, at 09:41, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

Haven't we already reserved the encompassing /29 per initial /32 the past few years? Does this proposal suggest that a /26 should be reserved for an initial allocation of /29?

This might be a good idea. Asking for impact analysis stats might be funny, along the lines of "RIPENCC running out in 2 millennia rather than 6", but impact analysis/due diligence is important. If we decided to reserve a /26 per future lir, is this in line with and permitted by any global policy, should RIPENCC need to go and ask for more v6 ? Andy

Hi, On Mon, Oct 24, 2011 at 10:29:15AM -0700, Randy Bush wrote:

...

...

I'm conviced a /29 will be very helpful for proper addressing plans and I'm strongly supporting this proposal. Isn't that almost the same that was said when we went from /35 to /32, and now again when we go to /29? Nothing wrong in that, the world keep growing so it's just fair the address-space grow with it.

why are we screwing around? let's go straight to a /16 or at least a /20.

So you're proposing to adjust the proposal for a minimum size of /20? It's a tough fit inside RIPE's /12, but I always thought that was too narrow-minded in the first place. With a /20 per LIR, RIPE would need a /7 now and a /6 soonish - which would be nicely utilizing the available space inside FP001... 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

a bit off topic... On Mon, Oct 24, 2011 at 8:52 PM, David Conrad <drc@virtualized.org> wrote:

On Oct 24, 2011, at 10:38 AM, Gert Doering wrote:

...

...

...

Nothing wrong in that, the world keep growing so it's just fair the address-space grow with it.

why are we screwing around?  let's go straight to a /16 or at least a /20.

So you're proposing to adjust the proposal for a minimum size of /20?

It's a tough fit inside RIPE's /12, but I always thought that was too narrow-minded in the first place.  With a /20 per LIR, RIPE would need a /7 now and a /6 soonish - which would be nicely utilizing the available space inside FP001...

Somebody (or hopefully somebodies) forgot a smiley.

well, why? I don't say /20 or /16 is the right size but we started with /35, then to /32 and now to /29. Seems like we are pushing things every few years. So why not go bigger this time? And we got the space to waste if people are afraid of that to, we're still only on the first out of 7-8 big block (2000::/3...) -- Roger Jorgensen           | rogerj@gmail.com          | - IPv6 is The Key! http://www.jorgensen.no   | roger@jorgensen.no

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

On 10/24/11 11:36 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 :)

well, they could convert to a /16. but they would only be allowed to change their whois data on odd numbered wednesdays while standing on their left foot

There were suggestions to go directly to /24 (as then you can easily deploy 6RD, give out /56 and have no incentive to go to native v6), but this did not seem a good idea to many of people we discussed with about this matter. When mentioning this to you, you had no preferences and/or objections :) I know it's politics and policy, but we just exposed the problem from real operations world towards policy-making community and community decided we need to deal with this issue. We are also well aware, that "6rd is wrong way of doing right thing (or even vice-versa)", but it out there and happening. whois data and wednesdays, well, this is implementation issue, not policy so we can fix that later on :) :) :) cheers, Jan

Hi, On Oct 25, 2011, at 8:01, Dan Luedtke <maildanrl@googlemail.com> wrote:

...

A 6RD allocation should be 100% 6RD and no other use of it should be allowed, so that it can easily be returned once the 6RD deployment is no longer in use. I agree regarding allocations that were requested for use with 6RD. However, LIR/ISP requesting space from "their own" /29 should not require documentation when used for 6RD. For some reason, ISPs tend to deploy 6RD inside "their own" /29 rather than requesting a new /2x.

Requests for more space than /32 SHOULD require documentation, so your pretext I do not agree with. Moreover, it is easy and completely rational to, on your "subnet" lines, indicate if there is a 6RD subnet present in your plan/motivation. Additionally, it is very easy to subnet in such a way that 6RD is placed in the higher bits of the /29 or so, such that the space can be returned when no longer use. Admittedly, this gets more tricky with an initial allocation.

...

That, or, roll native. ;) I like the rolling native part :) When it comes to mobile network, we might be stuck to transition technologies forever(tm). There will be parts of the network that will never be LTE only, like strange sensors in some (hopefully not mission critical) infrastructure and things like that. So chances are, when looking at mobile networks, that a 6RD deployment will never be returned. :(

See other email.

Best, Martin

Hallo, On Mon, Oct 24, 2011 at 10:02 AM, Michael Adams <madams@netcologne.de> wrote:

2) Stick to policy for subsequent allocations. In our case this means additional unneccessary work. Anyway it ends in a /29 for us.

Isn't it better to change that procedure to not require unnecessary work? The space is reserved for growth and to contain fragmentation. Instead of increasing the initial allocation I propose to make it easier to request subsequent allocations from the prior reserved /29. A short notice "hey, we are growing" should be enough. If it's not, then we need to change that. Handing out /29 initially might lead to over-generous network planing, but one should not be having problems getting the rest of one's /29 when growing! But maybe I am just not getting your point?! regards.  danrl -- Dan Luedtke http://www.danrl.de

Hallo, On Mon, Oct 24, 2011 at 2:12 PM, Michael Adams <madams@netcologne.de> wrote:

...

Isn't it better to change that procedure to not require unnecessary work? For us this would be sufficient. Something like "If you qualify for an initial /29 you may extend your /32 directly to a /29 an skip the HD-ratio rule." would

Am 24.10.2011 11:59, schrieb Dan Luedtke: perfectly match for us.

I am not a RIPE member (just a regular customer of a LIR), so I don't know if I can propose a policy change, but I am sure you can. -- snip -- 5.2.1. Subsequent allocation criteria Subsequent allocation will be provided when an organisation (i.e. ISP/LIR): a) 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) qualifies in accordance with the criteria for an initial allocation of /29. -- snap -- Something like this? regards.  danrl -- Dan Luedtke http://www.danrl.de

Hi, On Fri, Oct 21, 2011 at 1:42 PM, Gert Doering <gert@space.net> wrote:

Hi,

On Fri, Oct 21, 2011 at 12:01:12PM +0100, boggits wrote:

...

On 21 October 2011 11:44, Emilio Madaio <emadaio@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.

The feedback we got at the last RIPE meeting was "please do not tie this to a specific transition technology, and go down the rathole of potentially having to revoke the allocation if 6rd is no longer in use".

So the proposers have decided to go for the "minimum fuzz" thing - ask for it, get it.

I'm not exactly sure how you're proposing to modify this?  "Special case for 6rd only"?

My personal opinion on 6RD is: if it is to be treated as a special case, it should be a special case, meaning it is a temporary allocation (like all others, but with emphasis), valid only so long it is used. A 6RD allocation should be 100% 6RD and no other use of it should be allowed, so that it can easily be returned once the 6RD deployment is no longer in use. That, or, roll native. ;) Best, Martin

Hi, On Oct 25, 2011, at 8:49, "Jan Zorz @ go6.si" <jan@go6.si> wrote:

On 10/24/11 8:56 PM, Martin Millnert wrote:

...

My personal opinion on 6RD is: if it is to be treated as a special case, it should be a special case, meaning it is a temporary allocation (like all others, but with emphasis), valid only so long it is used. A 6RD allocation should be 100% 6RD and no other use of it should be allowed, so that it can easily be returned once the 6RD deployment is no longer in use.

That, or, roll native. ;)

Hi,

Special case means special IPv6 space and special allocations out of that and that means burning RIPE-NCC resources claiming that space back later on - and good luck with that, as we know that allocations rarely can be returned, because somebody deployed something else in that space and is now sorry :)

Cheers, Jan

With the enormous economical disaster looming, isnt providing jobs a good thing? ;) Seriously though, I cannot support a policy proposal for 6RD or other transition technologies that burns this much v4 space ( ie , full mapping of ipv4), that does not explicitly attach requirements on the space to A) not be used for anything but the transition technology, and B) clearly be marked by the NCC as being of transition tech $FOO, and finally C) very explicitly be only valid as long as the use stays. Failing any of these points, I do not support the proposal on the basis that it is careless use of v6 space. Regarding mobile networks, there is little differentiation here to other link layers as far as address assignment goes I think. And again, numbering must be done in the way I describe if this or similar proposals is to have my support. So, I guess to make it clear, until the proposal has texts like the above in it, I do not support the proposal. Best, Martin

On 10/26/11 7:46 AM, Mikael Abrahamsson wrote:

On Wed, 26 Oct 2011, Martin Millnert wrote:

...

Seriously though, I cannot support a policy proposal for 6RD or other transition technologies that burns this much v4 space ( ie , full mapping of ipv4), that does not explicitly attach requirements on the space to A) not be used for anything but the transition technology, and B) clearly be marked by the NCC as being of transition tech $FOO, and finally C) very explicitly be only valid as long as the use stays.

I agree with the above. I do not like to blanket increase to /29 and keep it there for everybody, but I do want people using 6RD who need to map the entire IPv4 space (which isn't strictly needed, if you're a small network you can map just part of the IPv4 space into IPv6 space, for instance on /16 border instead of at /0.

Agree.

I also feel that 6RD justifies a /32, it doesn't justify a /30 or alike.

No. 6RD in it's natural form "needs" /24 in order to give /56 to users. /30 is a compromise to give /62 (4 subnets) to end user.

6RD is a transitioning tech that I would like to see gone in 5 years,

We all wish that but usually temporary solutions are most permanent ones. Old DSLAMs are there to stay and probably we'll see this stuff in the networks for next 10 or 15 years.

and until then I believe a single /64 in the home should be enough for these transitioning tech users. When they get native IPv6, they can get their /56. If an ISP wants to give more space to their end users using 6RD, they'll have to do more granular 6RD mapping.

We would really like to prevent abusive/proxy/crap technologies to emerge just to be able to split that /64 in more subnets. Please, do us a favor and re-think :)

So I guess my counter-proposal is to give everybody a /32, and if they say 6RD then they may get a /31 instead, with the additional /32 usage being reviewed every 5 years or so.

This introduces an incentive to lie to IPRAs. We know that in IPv4, the trend is to lie to get more space. We are well aware of that so our proposal tends not to introduce an incentive to start lie to IPRAs. One incentive already emerged there, if you have hosting datacenter and no need to be LIR, don't say you'll give IPv6 addresses to your customers (servers) if you want to get IPv6 PI space. I hope this one will also be removed. Cheers, Jan

On 10/26/11 12:05 PM, Mikael Abrahamsson wrote:

On Wed, 26 Oct 2011, Jan Zorz @ go6.si wrote:

...

...

I also feel that 6RD justifies a /32, it doesn't justify a /30 or alike.

No. 6RD in it's natural form "needs" /24 in order to give /56 to users.

Yes, "needs" indeed. It's not a MUST though, it's just operationally easier.

Exactly. But... (there's always a but), operators are yelling about small margins, about not having money to invest in more complex operations, about operations overhead and so on and so on. Personally, I would go with multiple 6RD domains and be done with it. Again, this are facts, complains and questions we get from real life on the operational field.

With 6RD you can take a IPv6 /36, map 8 bits of IPv4 into a IPv4 /24, map 24 bits into IPv6, and now you have that /60 you wanted for your customers. Yes, you "wasted" an IPv4 /24, but if you're that big so you need avoid doing 6RD on IPv4 /16 level (map 16 bits of IPv4 into a single IPv4 6RD relay address), give that relay a /40, then you can give your customers a /56, "wasting" a single IPv4 address per /16 with some additional configuration.

Just to give some perspective if someone still thinks one can't deploy 6RD without mapping all of IPv4 space into IPv6. It's not true, it's just more complex.

Yes. Easily possible, but not heavily practiced in real life. Least possible complexity, least possible operational overhead. If we get them this option, IPv6 service gets deployed. Note the usage of the word "service", not "native" :) Cheers, Jan

On 10/26/11 1:55 PM, Martin Millnert wrote:

...

Again, this are facts, complains and questions we get from real life on the operational field.

Knowing you represent Go6, I do wonder what operators are requesting this.

Hi, I'm not going into names, but even many of them who are looking into multiple domains now would go into one domain 6RD if this would be even remotely possible. While doing IPv6 world-tour with Go6 presentation I talk to many of them at the events and there is repeating story, over and over again.

It wouldn't hurt if they came here and voiced their opinions directly either. The APWG-ml community is not a 1:1 map to RIPE region operators, so the community response you will get here may or may not be what you want.

This is a pitty. I would also like them to voice out their opinion here. Looks like *I* need this policy to change, but I don't, even in my country there will be no 6RD deployment, we cause we did our homework right. So, this effort is purely to ease some things for others.

I wish it was feasible to counter-suggest that those who spend more effort get a better service to customers and 'market forces' takes care of the rest (ie, native IPv6 provides the best service, and competition eats up those 15 year old DSLAMs...).

This is how it is supposed to go, yes.

(On second thought, isn't it?)

IMHO, we're not necessarily helped with deploying IPv6 services at unlimited cost. And being too lazy to not map 32 bits of IPv4 space into 6RD strikes me like such a thing (and if you want to do it, you still could, with the A,B,C and attached justifying documentation.)

I'll leave the cost calculations to operators and their staff, but, again, from what I hear, there are economical issues that I even don't properly understand (as I'm not economist). Cheers from OECD meeting in Paris :) :) :) Jan

On 26.10.11 15:44, "Michael Adams" <madams@netcologne.de> wrote:

But we want to do native v6 and we need additional bits to make the v6 pools on our access routers big enough for all our residential customers from the beginning. Fortunately the policy text itself is not mentioning 6RD and so it solves our problem too.

+1. Our network model is based on a core network that is owned and operated by Altibox, and several partners networks that is operated by Altibox and owned by the partner. 6RD is a method we are considering for IPv6 deployment, mostly because our partners might not have the budgets to upgrade their infrastructure in thread with our IPv6 deployment. Having many prefixes, a multi-domain 6RD setup will be a hassle, both for prefix management at traffic management. However, this is not our prime reason to support this. We support this policy change mostly because it gives us the address space to needed to do good address aggregation in our partners networks. With a /32, we need to break down the allocations to smaller prefixes, hence making aggregation more difficult. The size of each partner vary greatly in number of end customers, and a larger prefix will help us keep the aggregations simple and unified. Best Regards Ragnar Anfinsen Senior Architect CPE Netinfrastructure Technology and Innovation Altibox AS Phone: +47 51 90 80 00 Phone direct: +47 51 90 82 35 Mobile +47 93 48 82 35 E-mail: ragnar.anfinsen@altibox.no Video phone: ragnar.anfinsen.altibox@video.altibox.net Skype: ragnar_anfinsen www.altibox.no

Hi, On Sat, Nov 05, 2011 at 03:37:09AM +0100, Daniel Roesen wrote:

Raising the HD-ratio so much (from 0.8 to 0.94) was a clear mistake in my opinion. Even if you have every(!) german citizen as customer, you would never qualify for more than a /28. That's ridiculous.

Indeed it is, as your statement is missing one important bit to be useful - the size of the prefix you intend to give your customers. If you give out /64s, you have 4 billion of those in a /32, so you don't need more to number roughly 80 million customers. If you give out /56s, indeed, ripe-523/appendix A shows that you qualify for a /28 - which contains 268 million /56s, so whether this is sufficient or not depends on the internal network structure, and it might be a bit tight if you have multiple levels of aggregation, yes. If you hand out /48s to your customers, (roughly) 80 million customers would be counted as 256*80 million = 20 billion /56s - and appendix A permits allocation of a /19 in that case.

The 128 bit IPv6 addr width had the promise to provide enough bits for internal hierarchy for "nice" (read: cheap to manage, easy to deal with in general and specifically operations) addressing plans. For large/mid-scale residential ISPs of certain topologies and access infrastructures, the current "ruleset" of "consider only 2-3yrs plans for initial alloc" in combination with HD-ratio 0.94 requirement for getting more bits, is a real problem. We're back to slice-and-dice-on-demand - no proper hierarchical structure anymore. Otherwise, HD-ratio 0.94 WILL bite sooner or later.

I think I mentioned this a few times before: if you think the HD ratio is using the wrong number, or if you think the HD formula is completely wrong to start with, please submit a policy proposal to change this to whatever you think would work better. But this is somewhat out of scope for the discussion of 2011-04 and should not be discussed in *this* thread. 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

On 05-11-11 12:16, "Gert Doering" <gert@space.net> wrote:

I think I mentioned this a few times before: if you think the HD ratio is using the wrong number, or if you think the HD formula is completely wrong to start with, please submit a policy proposal to change this to whatever you think would work better.

But this is somewhat out of scope for the discussion of 2011-04 and should not be discussed in *this* thread.

+1 from my side as well. In addition, I consider it rather a feature of the current HD-ratio that using transition technologies such as 6RD can get you in trouble for subsequent allocations if you don't clean up at some point. Best, Remco 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.

On 10/26/11 7:36 AM, Martin Millnert wrote:

Failing any of these points, I do not support the proposal on the basis that it is careless use of v6 space.

Hi, At first, my thoughts was to go exactly the way you propose. But, then we had long discussions with many people, also RIPE-NCC staff (I just needed some data and how IPRAs operate), and then we presented the proposal at RIPE62 in Amsterdam. If you remember, one of proposed solutions was also separate v6 space for transition mechanisms and temporary allocations, but this idea did not manage to fly (maybe before the presentation, but not after). The message we got back was "don't think v4 way, let's enable people to deploy IPv6 and not install speed bumps". If this is a request, then our first thought was - let's go straight to /29 as minimum initial allocation - but this could be seen from some individuals as "ripping more money from LIRs", so we introduced "from /32 to /29" option. I agree with all you said, just it seems it does not work this way. ARIN did that, but RIPE community want's it differently. But, if we hear many more suggestions in this way, we can withdraw the proposal and go different way, but for now - let's hear what community has to say :) Cheers, Jan