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 (Removing 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 (Removing 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 (Removing 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
Sun Dec 14 11:02:36 CET 2014
Hi Sander, Sorry, I thought all on the list knew my position about that. I will stole the arguments from Stefan Schiele. I hope he doesnt mind. In our case, we are not a software company providing hosting. We are a little Local ISP in an "small" town (arround 100k population) and same as Stefan Schiele, we runned out of IPv4 and our transit provider, in that moment, couldnt gave us more. Until that moment, I never cared out about IPv6. Only when we was "forced" to have an alloc of IPv6 I cared and thinked about it. Now, I consider myself an IPv6 warrior. >Andrea Cima wrote: >The RIPE NCC has started allocating /22s from the last /8 on 14 >September 2012. Since then 4190 IPv6 allocations have been made, out >of which 1160 are currently visible in the BGP routing tables. That means arround 27%. To be honest, I thought a really lower numbers before Andrea said the real ones. Taking into account the current IPv6 deployment rate, I'm more convinced we need the current requisite of having an IPv6 alloc to request the last /22. The only argument supporting the proposal: >In order to receive an allocation from the final /8, LIRs are >currently required to have received an IPv6 allocation. This >requirement was originally meant to foster IPv6 deployment. However, >in some cases it does the reverse. If LIRs have an existing IPv6 PI >assignment but no IPv6 PA allocation, they do not meet this criterion. >In order to qualify, they need to request an IPv6 allocation and >subsequently return their existing PI assignment (per ripe-589 section >7.1). The problem is LIRs with PI space dont having the requirements to recieve the v4 /22 from the last /8. Why just dont allow PI assignment to be valid to recieve an alloc from the final /8? >Since there is a huge difference between having received an IPv6 >allocation and actually deploying IPv6, there is doubt that the >requirement has in fact lead to wider IPv6 adoption. A 27% from a total of ~50% alloc/published ipv6 that will be lost in the current v6 deployment. TL;DR Requesting an IPv6 allocation dont takes time, its only a procedure. The 27% of LIRs who did the procedure have IPv6 published in BGP and I hope at least half of them have it working too. Just allowing v6PI space to be valid to recieve the /22 from last /8 is easier. And those are my arguments. PD: You asked for them, now you read it! :D El 13/12/2014 20:48, Sander Steffann escribió: > Hi Daniel, > >> Op 12 dec. 2014, om 10:53 heeft Daniel Baeza (Red y Sistemas TVT) <d.baeza at tvt-datos.es> het volgende geschreven: >> >> I dont agree. > > With what exactly? We make policy based on arguments. Please provide us (=this list) with arguments why you don't agree so they can be discussed. > > Thanks! > Sander > -- Daniel Baeza
- Previous message (by thread): [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Removing 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 (Removing IPv6 Requirement for Receiving Space from the Final /8)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]