Hi, On 25/08/14 14:59, Jan Ingvoldstad wrote:

On Mon, Aug 25, 2014 at 9:10 PM, Nick Hilliard <nick@inex.ie <mailto:nick@inex.ie>> wrote:

On 25/08/2014 19:47, Gert Doering wrote: > while I can understand that beaches and drinks are more attractive than > policy work, we have a proposal here that needs a bit of caring - > this one is in Review Phase until Friday, and has received exactly one > comment yet (strong support). I could use a *bit* more feedback here...

Whoops, sorry about that!

Beach-and-drink time was over a month ago! some are still at the beach :)

tl;dr: don't support as-is, but could be convinced

--

I support the idea as it's a bugfix policy proposal, but the wording is need to be improved. At the moment, it ties the policy to the idea of the RIPE NCC being the routing police. Probably this isn't the intention.

I think you're right about that. I would go as far as to say, as long as you have/use IPv6 (no matter which color and from whom) you can request the last /22. I would also accept a change proposal that would completely remove this requirement and believe it's even a better idea.

It may be better to consider alternative wording, e.g.

> An allocation will only be made to a LIR if the LIR has already been > assigned or allocated an IPv6 address block from a RIR.

Even better, remove the requirement completely as it's pointless.

+1

I'm not convinced that it's a pointless requirement, but I concur that the wording needs to be changed a bit before I feel comfortable with it.

As it is, however, I don't feel strongly either way about this part of the policy, but a clearer policy is something I'll support. :) -- Jan

Kind regards, Elvis -- <http://v4escrow.net> Elvis Daniel Velea Chief Business Analyst Email: elvis@V4Escrow.net <mailto:elvis@v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.

On Mon, Aug 25, 2014 at 08:10:53PM +0100, Nick Hilliard wrote:

...

An allocation will only be made to a LIR if the LIR has already been assigned or allocated an IPv6 address block from a RIR.

Even better, remove the requirement completely as it's pointless.

Couln'd agree more. This requirement does nothing for actual IPv6 deployment. It just forces people to fill out another form and pimp statistics. That's what we call "window dressing". If and when people want to deploy IPv6, they will request IP space for this. If they don't, having a net block lying around doesn't make them deploy any sooner. IMHO. YMMV. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On 08/09/2014 04:08, Aleksi Suhonen wrote:

It seems clear that we can't reach consensus on removing it completely, so I'm hoping for your support. Let's take baby steps so we can get at least some progress?

yep, agreed.

The wording does not refer to route6 objects, only inet6num objects. The part about "globally routeable" refers to 2000::/3 so that people don't try to advance fc00::/7 or fec0::/10 address space (for example) as "theirs."

In that case it would probably be advisable to refer to IANA designated Global Unicast address space rather than "globally routable": http://www.iana.org/assignments/ipv6-address-space

Our intention was to allow assignments by other LIRs or NIRs or whatever as well as RIRs.

It's not clear what you mean here. Are you talking about provider independent direct assignments - which are exclusively assigned by NIRs and RIRs, or PA assignments - which are exclusively assigned by LIRs? The proposal only makes sense for direct / PI assignments, not PA assignments. Nick

Hello, On 09/08/2014 06:18 PM, Nick Hilliard wrote:

...

The wording does not refer to route6 objects, only inet6num objects. The part about "globally routeable" refers to 2000::/3 so that people don't try to advance fc00::/7 or fec0::/10 address space (for example) as "theirs."

In that case it would probably be advisable to refer to IANA designated Global Unicast address space rather than "globally routable":

http://www.iana.org/assignments/ipv6-address-space

The definition we had written is as follows: [O]rganisations are eligible to receive an allocation from the final /8 if they have an inet6num object registered in the RIPE Database or any of the other RIR databases mirrored by the RIPE NCC. This will validate the address space on both the macro and the micro level. I think this is a more convenient definition than referring to the IANA database. Do you disagree? The above definition is in the summary of the proposal instead of the proposed policy text change. It should make it into the supporting notes of the policy. We wrote it like this, because we think that this is the way it's usually done. The policy text is more generic and the supporting notes go into the nitty gritty detail. Yours, -- Aleksi Suhonen You say "potato", I say "closest-exit."

On 11/09/2014 05:59, Aleksi Suhonen wrote:

The definition we had written is as follows:

[O]rganisations are eligible to receive an allocation from the final /8 if they have an inet6num object registered in the RIPE Database or any of the other RIR databases mirrored by the RIPE NCC.

This will validate the address space on both the macro and the micro level. I think this is a more convenient definition than referring to the IANA database. Do you disagree?

You still haven't made it clear what you're trying to do here. - if you're suggesting that an organisation with a PA assignment (or equivalent) of /128 from some random LIR-type organisation anywhere in the world should be eligible for a last-/8-allocation, then this is basically meaningless and you would be better off removing the rule completely. The reason for this is that the policy is intended to encourage LIRs to deploy IPv6 for the end-users and provider-associated address space is pretty meaningless for LIRs in this regard. It is not a good idea to create policy which can be satisfied by tick-box compliance. - alternatively, if it's your intention that only provider independent / allocation style address space be used for this policy, you need to state that. From my understanding of the original intention of the policy, this would be most appropriate in this situation. From the point of view of the policy development process, you need to make it clear because there's an important semantic difference here which you're glossing over. Once you've made it clear, only then will it be possible to have a meaningful discussion about the most appropriate wording for inet6num vs "Global Unicast".

The above definition is in the summary of the proposal instead of the proposed policy text change. It should make it into the supporting notes of the policy. We wrote it like this, because we think that this is the way it's usually done. The policy text is more generic and the supporting notes go into the nitty gritty detail.

The policy proposal proposes to change a single line in the policy. The supporting notes are arguments to help it through the working group, but they are not part of the policy. Nick

On 19/09/2014 10:31, Martin Pels wrote:

You are correct in that having received a small IPv6 PA assigment from another LIR may not be enough for deploying IPv6 to end-customers. But I could argue that having this PA assignment actually deployed in your network is more meaningful than having requested your own PA allocation without doing anything with it (which would satisfy the policy as it is now).

From a syntax point of view, the wording is contradictory. The summary states that there is a requirement for an "inet6num object registered in

There is nothing in the proposal about deployment of either PI or PA space, so it's not clear why you're making this argument. The proposal as it stands is window dressing because it requires only tickbox-style compliance. This is completely pointless. Organisations will either deploy ipv6 or they won't, and this decision will be made on business merit rather than because a RIPE NCC IPRA delayed a /22 allocation because of a policy violation. the RIPE Database or any of the other RIR databases mirrored by the RIPE NCC". The policy itself does not state this; just that the /22 allocation can be made if the LIR has "already received a valid globally routeable unicast IPv6 address block". These two things are not the same. If you intend something to be in the policy, then put it into the policy. The policy is what ends up in RIPE-* documents; the summary is not a part of this.

From an implementation point of view, it may be worth asking the RIPE NCC if they intend to demand that the assignee of the inet6num is an exact text match of the legal name of the LIR. Most organisations are pretty sloppy about this, and this is a likely source of future confusion because getting PA or other RIR assignment/allocation details changed in order to qualify for the /22 could turn out to be surprisingly troublesome.

FWIW, the RIPE NCC has done the community a favour by implicitly pointing this out: "Delay and extra workload is only expected if the provided IPv6 range is not clearly registered to the requesting RIPE NCC member." In other words, be careful what you ask for because you might get it. Also, the RIPE NCC has clarified that IPv6 assignments to different companies within the same company group do not qualify for this proposal.

From what I understand, this was one of the original complaints about the existing policy, and it will not be fixed with this proposal.

overall: - I don't support this policy because window dressing is not a good basis for making ip addressing policy. - even if I did support it, a) the policy doesn't say what you think it says and b) it doesn't handle some of the problems of the current policy. I would kindly suggest either dropping the ipv6 requirement completely from the last /8 policy, or if you feel strongly that it should stay, rewording this proposal to make it say what you intend. Nick

Hi Gert, Any windows dressing in the policy should be avoided .. If people want to implement v6, they will .. If people need to request v6 in order to obtain v6, they will.. But it doesn't mean they will deploy ... Based on that, I would say, strike the v6 requirement in order to request the last v4 /22 .. Added to that, having people that deployed v6 based on PI having to turn in their space as it doesn't fit the requirement feels like a slap in the face and a waste of effort ... I would vote to have that fixed ... Erik Bais Verstuurd vanaf mijn iPad

Op 10 okt. 2014 om 21:20 heeft Gert Doering <gert@space.net> het volgende geschreven:

Hi,

...

On Wed, Oct 08, 2014 at 11:40:03PM +0100, Nick Hilliard wrote: The proposal as it stands is window dressing because it requires only tickbox-style compliance. This is completely pointless. Organisations will either deploy ipv6 or they won't, and this decision will be made on business merit rather than because a RIPE NCC IPRA delayed a /22 allocation because of a policy violation.

Indeed, but that's what we have in the policy right *now* :-)

So maybe the question to the group should be:

- abandon the IPv6 requirement completely, and "who asks for their last /22 gets it, done"

or

- come to some agreement about what sort of IPv6 window dressing should be there, maybe only to serve as an awareness thing.

- *iff* that, what sort of IPv6 space should qualify?

Onlookers might have noticed that this proposal should have ended it's current phase (discussion) quite a while ago, was extended, and should have ended now again - but we'll extend the discussion phase again, to clarify this point. Then the proposers have a clear direction in which way to re-word their proposal for the next discussion phase - the current text certainly hasn't reached consensus yet.

So, working group, please let us know what you think.

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 (0)89/32356-444 USt-IdNr.: DE813185279

On Sat, Oct 11, 2014 at 10:45 AM, Roger Jørgensen <rogerj@gmail.com> wrote:

On Fri, Oct 10, 2014 at 9:57 PM, Erik Bais <ebais@a2b-internet.com> wrote:

...

Hi Gert,

Any windows dressing in the policy should be avoided .. If people want to implement v6, they will .. If people need to request v6 in order to obtain v6, they will.. But it doesn't mean they will deploy ...

Based on that, I would say, strike the v6 requirement in order to request the last v4 /22 .. Added to that, having people that deployed v6 based on PI having to turn in their space as it doesn't fit the requirement feels like a slap in the face and a waste of effort ... I would vote to have that fixed ...

agree, let's just drop the v6 and give out the last /22 to those that want it.

I could probably write a couple of thousands of words about this, but I'll be brief: Yes, please let's just drop the v6 requirement. -- Jan

Hi Daniel, Some comments to clarify the discussion:

I totally disagree. In other hand, I'll make harder the v6 requeriment to get the /22.

For what purpose? When making statements like this please explain what your underlying intentions are. We make policy for a purpose and if the purpose isn't clear then it is impossible to have a reasonable discussion about the solution space.

How? Making the policy not only "to have" the v6 alloc, I'll require also having it with route6 and published in BGP. RIPEstat is a good tool to check if the v6 is publicly visible.

IP addresses allocated/assigned do not have to be routed on 'the global internet' (for whatever value of 'global internet' you pick). Routing requirements were explicitly removed from the IPv6 policy with https://www.ripe.net/ripe/policies/proposals/2009-06. Cheers, Sander

On 13 Oct 2014, at 16:46, Daniel Baeza (Red y Sistemas TVT) <d.baeza@tvt-datos.es> wrote:

If we want to migrate from v4 to v6, some drastic changes should be made. One of them, requiring the v6 to be publicly visible if you want to have the last /22.

In your opinion.

That way we ensure that LIR/Network will have, 'at least', ipv6 working on the router. Its sad we cant check deeper if clients/servers/etc is having v6 conectivity but at least we can check if v6 is public in bgp.

This is just silly. An LIR could easily pass your "working IPv6" test without actually deploying or using IPv6 in their network for real. All this protocol policing would do is the equivalent of security theatre at an airport. People get a (bogus) feeling that Something Is Being Done which has little bearing on anything that actually matters. Few, if any, incentives have made a meaningful difference to IPv6 deployment to date. So I doubt the one you are advocating can succeed where other, better ones have failed.

...

...

How? Making the policy not only "to have" the v6 alloc, I'll require also having it with route6 and published in BGP. RIPEstat is a good tool to check if the v6 is publicly visible.

IP addresses allocated/assigned do not have to be routed on 'the global internet' (for whatever value of 'global internet' you pick). Routing requirements were explicitly removed from the IPv6 policy with https://www.ripe.net/ripe/policies/proposals/2009-06.

So please, tell me why someone will require/request public ip space if is not to be publicly routed on "the global internet". And that is a real question since I saw that "IP addresses allocated/assigned do not have to be routed on 'the global internet" several times and cant understand why.

One of the jobs of an RIR is to distribute globally unique IP addresses. It's up to the address holder to decide if they want to route those addresses or not, nobody else. The RIR doesn't get to decide that. FYI many organisations use globally unique addresses so that they do not have to undergo expensive renumbering if/when they sell off parts of their business or acquire another company or interconnect with other corporate nets that aren't directly connected to the Internet

Hi, Sorry for late answer as Im really busy here :) El 13/10/2014 19:43, Gert Doering escribió:

- who will be requesting that /22? Will it make a difference in the big picture if they deploy IPv6 "soonish" or not?

Only 1 wont make the difference in the big picture. Thousands of them will do.

- will it make a difference if we force them to provide some sort of "look I have IPv6!" dance? (We had this discussion every now and then in the last years, including "give every LIR a /32 right away!" and the end consensus was along the lines of "if they want to deploy, it is easy enough to get space, so forcing an IPv6 prefix on them won't make a difference") Deploying IPv6 is more than "setup a tunnel somewhere and anounce your prefix", so we should consider whether the incentives we give are effective, or just theater.

There arent at this moment (or I dont know them) any incentives to deploy IPv6... If nobody does, nobody will do.

- who will benefit, and who will be hurt by such a requirement? Right now we have a policy which is actually hurting people that already *have* deployed IPv6, just not the right type of addresses... (because they have to get their own PA and renumber out of the PI they have already deployed). *This* is certainly not a useful incentive.

Then lets change the text of the policy for recieving the last /22. Point 5.1, rule 4: From: Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. To: Allocations will only be made to LIRs if the have already received and IPv6 PI or PA from another LIR, RIPE NCC or other RIR. (Please, dont just read literally as my english is not very good. Try to read what I want to transmit)

I officially do not have an opinion here, but I hope I'm asking the right questions to reach some useful policy at the end :-) (but indeed, I am known to be in favour of fairly simple and easy to implement policies)

We should not make policy only considering the simplicity and ease of implementation. Of course, if we have 2 options for a policy change saying the same but with different implementations, we should use the simple and easy one. Cheers, -- Daniel Baeza

Hi, El 15/10/2014 11:23, Gert Doering escribió:

Hi,

On Wed, Oct 15, 2014 at 11:16:24AM +0200, Daniel Baeza (Red y Sistemas TVT) wrote:

...

There arent at this moment (or I dont know them) any incentives to deploy IPv6... If nobody does, nobody will do.

Repeating the claim that "nobody deploys IPv6" - which is quite obviously not true, and everybody can see that - is not really strengthening any argument based on that.

Sorry, I didnt mean to say nobody have deployed IPv6. For example I did and currently at least 40% of my customers have IPv6 ready equipment (modem and their cpe) and arround 15% of my total traffic is IPv6. A this moment only the 18.46% of ASN are announcing an IPv6 prefix. Imagine this situation: A new created LIR is asking for the last /22 v4 allocation. RIPE says, "hey, you can recieve also an IPv6 alloc" and the new LIR checks how many ppl have IPv6 and see is a marginal percentage. Why is going that LIR to stress the mind to implement IPv6 if "nobody" does and will not make any difference to the quality of their customer connections? Again, im sure im not writting what Im trying to say, but Im doing my best on that.

There are quite some incentives to deploy IPv6, like "IPv4 run-out" and "cost of CGN, cost of IPv4 deployment, poor quality of web services to IPv4-behind-CGN users, etc."

Those arent incentives, are facilities. An incentive is, for example: Hey, you will recieve a /23 IPv4 alloc if you make your network dual-stack. Note: IS AN EXAMPLE!!!! It's the first incentive that has fly on my mind, but surely there are many more and not related to more IPv4 allocs.

Even our policy has (indirect) incentives to deploy IPv6 - getting IPv6 address blocks is so much easier than it ever was for IPv4 addresses...

Same. That is facilities, not incentives.

[..]

...

Then lets change the text of the policy for recieving the last /22.

Point 5.1, rule 4:

From:

Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.

To:

Allocations will only be made to LIRs if the have already received and IPv6 PI or PA from another LIR, RIPE NCC or other RIR. (Please, dont just read literally as my english is not very good. Try to read what I want to transmit)

But that's basically back to "window dressing" - acquiring an IPv6 network is trivial, but if someone does not want to deploy IPv6, it will not make him.

Sorry, cant understand what you mean.

[..]

...

...

I officially do not have an opinion here, but I hope I'm asking the right questions to reach some useful policy at the end :-) (but indeed, I am known to be in favour of fairly simple and easy to implement policies)

We should not make policy only considering the simplicity and ease of implementation. Of course, if we have 2 options for a policy change saying the same but with different implementations, we should use the simple and easy one.

If we have a clause in the policy that is there to achieve something, but doesn't do so, and the policy without the clause is easier to understand and implement, this is definitely preferred.

If the clause in the policy dont change the way the policy is, and make easier to understand and implement, for sure is preferred. If the clause is "core" and without it the policy completely changes, only to make is easier I do not agree with that. -- Daniel Baeza

Hi Daniel,

Then lets change the text of the policy for recieving the last /22.

Point 5.1, rule 4:

From: Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.

To: Allocations will only be made to LIRs if the have already received and IPv6 PI or PA from another LIR, RIPE NCC or other RIR.

That is still something that won't push real deployment, only administrative work... A different idea: if we want people requesting IPv4 space to be aware of IPv6 then why not just make it a requirement that the requester declares that they are aware that IPv4 is a scarce and limited resource and that for further scalability of the internet IPv6 deployment is required. It would probably have the same impact on real IPv6 deployment without any window dressing. And it would avoid requiring people to request resources that they have no intention of using at that point in time. IPv6 resources are easy to get: when they decide to deploy IPv6 it is easy for them to get the necessary resources at that point. And they will probably also know better what to request. I wonder how many LIRs have just requested an IPv6 /32 without thinking because they only needed to go through the motions to get an IPv4 /22. Cheers, Sander

Hello Wilfried,

In general, I would be much more in favour of a version of the proposal which removes the IPV6 holdership or usage *completely*. For all the reasons that have been pointed out already by others. (Thanks for that!).

I fully agree. I will work with the authors and help them to update the proposal text. Cheers, Sander PS: yes, this means that I am involved in this policy proposal and I will abstain on all WG-chair related duties about this proposal as I have now clearly given up my neutrality on this :) Gert has agreed to decide on this proposal without my input.

Hi Steffan, El 13/10/2014 21:07, Sander Steffann escribió:

For example if running a closed network that interconnects with other organisations but not with the whole internet. For example a closed network between banks or municipalities that needs guaranteed globally unique addresses to avoid clashes with the networks of the connected organisations. The network itself is not connected to the internet but systems at the participating organisations probably are. Therefore you need globally unique addresses. Another example might be a car manufacturer that wants addresses for the internal networks of the cars they manufacture. You probably don't want your cars systems to be connected to the global internet. Having connectivity to some other systems (monitoring, fleet management etc) might be useful though. And those systems are connected to the internet so the cars need globally unique addresses that don't overlap with anything used on the internet or within the companies that run the remote systems.

And these are just some things that I can think of now. There certainly will be others. We have a registry to make sure we hand out unique addresses to organisations so no clashes occur and so we know who is responsible for which addresses. Not to limit the kinds of networks and the way those networks are connected to each other.

There isnt any other way of doing it? I mean: - Public and unique IP Space works for both, private and public networks. - Private and NOT unique Space only works for private networks. Since public and unique IP Space is the only one you can use for "whole internet" and we (not we as me, we as all LIRs/RIRs) are running out of v4 space. There is a little conflict as private networks can work with private space, but public ones cant. Do you know what I mean? Cheers, -- Daniel Baeza

On Mon, Oct 13, 2014 at 5:46 PM, Daniel Baeza (Red y Sistemas TVT) <d.baeza@tvt-datos.es> wrote:

Easy. The current IPv6 deploy makes me cry like a little girl.

https://www.youtube.com/watch?v=XjJQBjWYDTs

NOBODY (as percentage) is deploying it in their customer/backone/whatever network.

This is not true.

If we want to migrate from v4 to v6, some drastic changes should be made.

Like only handing out /22 any more?

One of them, requiring the v6 to be publicly visible if you want to have the last /22.

This is not something that will drive v6 adoption. It's laughably easy to get around this requirement. For Gert's benefit: I am fine with removing and/or softening this requirement. Richard

...

Easy. The current IPv6 deploy makes me cry like a little girl. NOBODY (as percentage) is deploying it in their customer/backone/whatever network. ... even if stated again and again, it simply is not true. Please stop

Daniel Baeza (Red y Sistemas TVT) wrote: these claims, they may be even more detrimental to IPv6 deployment, if read by some people not having "real data" and/or first-hand experience.

perhaps a pointer to these real data would make your point randy

...

...

...

Easy. The current IPv6 deploy makes me cry like a little girl. NOBODY (as percentage) is deploying it in their customer/backone/whatever network. ... even if stated again and again, it simply is not true. Please stop

Daniel Baeza (Red y Sistemas TVT) wrote: these claims, they may be even more detrimental to IPv6 deployment, if read by some people not having "real data" and/or first-hand experience. perhaps a pointer to these real data would make your point Take a look at e.g. http://www.vix.at/vix_participants.html?&no_cache=1&L=1, the

column "IPv6 Routeserver activated".

I presume it wouldn't be useful to have that configured, unless there is deployment in these ASNs.

with all due respect, wilfred. iij has had a backbone configiured for ipv6 since 1997. but that is anecdote not data. randy

At least Im not the only one saying IPv6 isnt really deployed. As you all can see, Only a 5% of Google traffic is v6. For sure, google is not the only one, but the most used search engine and their stats can give us an "external eye" to v6 deploy in the world. Again, the current v6 deploy makes me cry like a children. For that reason, I dont support this proposal. We, as community, must try to foment IPv6 over everything. If we dont do anything now, we'll pay in near future, when in 10 years v4 still being the "main protocol" instead of v6. Cheers, -Dani El 30/11/2014 15:38, Jan Ingvoldstad escribió:

On Fri, Nov 28, 2014 at 11:26 AM, Randy Bush <randy@psg.com <mailto:randy@psg.com>> wrote:

> Take a look at > e.g. http://www.vix.at/vix_participants.html?&no_cache=1&L=1, the > column "IPv6 Routeserver activated". > > I presume it wouldn't be useful to have that configured, unless there > is deployment in these ASNs.

with all due respect, wilfred. iij has had a backbone configiured for ipv6 since 1997. but that is anecdote not data.

Yep, data is much more useful.

http://www.google.com/intl/en/ipv6/statistics.html -- Jan

El 01/12/2014 9:38, Jan Ingvoldstad escribió:

On Mon, Dec 1, 2014 at 9:25 AM, Daniel Baeza (Red y Sistemas TVT) <d.baeza@tvt-datos.es <mailto:d.baeza@tvt-datos.es>> wrote:

At least Im not the only one saying IPv6 isnt really deployed.

I'm not saying it isn't really deployed, so if you counted me as some sort of support to your claim, you need to rethink that.

As you all can see, Only a 5% of Google traffic is v6.

Did you look at the curve for the uptake of v6 traffic?

Yes I did.

You've been making theses "IPv6 isn't really deployed" claims for a pretty long time now.

Pretty long time? What is "long time" for you? Few months? A year?

Meanwhile, IPv6 traffic at Google has more than tripled.

Please, of course, from 1% to 2% is double. And from 1% to 5% is quintupled. But still being only a 5%... Will it keep the curve or will it relax? Dont really know, we'll see in the upcoming years.

Prediction:

You'll be making the claim when IPv6 traffic is 10%, 20%, 40%, and even 50%.

Bad prediction. Between 10% and 20%, for this year, I think is a good number. We are a very little ISP and around 15% of our traffic is v6 when only a half of our customers have v6 capable módems and from that 50%, not all of them have a v6 ready cpe(lot of winxp still outside). Of course, 99% of them is to google services (youtube,gmail,search...) and if we as little isp can do it, Im sure more big ISPs than us can do it too. So please, dont make predictions on what Im going to claim as you dont know me :) If you feel I said something not respectfull, Im very sorry, english is not my native language and sometimes is hard to me to explain what Im thinking with the proper words. To this topic, I love the signature of Gert: "have you enabled IPv6 on something today...?" Cheers, -- Daniel Baeza

El 01/12/2014 12:58, Gert Doering escribió:

Hi,

On Mon, Dec 01, 2014 at 09:25:58AM +0100, Daniel Baeza (Red y Sistemas TVT) wrote:

...

For that reason, I dont support this proposal.

We, as community, must try to foment IPv6 over everything.

I agree that we need to see more IPv6 deployment.

Thanks :D

As far as your opposition to the proposal goes, I consider it to be heard and addressed (because the group considers the requirements in the current policy to be insufficient to actually further IPv6 deployment, and as such, sticking to it is not helping to reach that goal).

Im ok with that. I was just pointing my reasons.

Since there is quite strong support otherwise, and we only need *rough* consensus, we'll go forward with it anyway. Consensus does not have to be unanimous.

Agree. If there is consensus the proposal should go forward. :) -- Daniel Baeza

...

I would kindly suggest either dropping the ipv6 requirement completely from the last /8 policy I'd support such a policy proposal.

As would I. It's tickyboxitis. D. Airspeed Telecom