This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
- Previous message (by thread): [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
- Next message (by thread): [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Baeza (Red y Sistemas TVT)
d.baeza at tvt-datos.es
Wed Oct 15 12:05:56 CEST 2014
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
- Previous message (by thread): [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
- Next message (by thread): [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]