[Lista ArNOG] IPv6 en ISP

Vie Sep 23 13:38:05 ART 2016

Owen !! great explanation!
We really appreciate your collaboration.

Thanks
El 21/09/16 a las 16:22, DeLong, Owen escribió:
> Forgive my limited Spanish, so I will post in English.
>
> There are many good reasons to stick to /48 instead of /56.
>
> +Simplified automatic prefix distribution within growing home network
> complexity and automation.
> +Improved ability to provide network segmentation in automated topologies
> +Better mechanisms for numbering future home automation and IoT
> +Giving all subscribers the same prefix size simplifies administration and
> reduces the potential for human error.
>
> The only possible benefit to selecting /56 is for an ISP to reduce 
> it’s RIR fees.
>
> This is such a minor fraction of costs at any scale where it could be 
> relevant that I think it is both
> short-sighted and ill-advised.
>
> Many people are so entrenched in IPv4-think from decades of living in 
> a scarcity mentality that they have
> a hard time understanding that so-called conservation in IPv6 is 
> actually wasteful.
>
> Think of it this way… There are two ways to waste addresses:
>
> 1.Deploy them in networks where they provide no benefit.
> 2.Avoid deploying them to such an extent that they are never deployed 
> even up to the
> point of protocol extinction.
>
> Obviously in the case of IPv6, we are hoping that confirmation of the 
> second case is many years down the
> road and we are hoping that we arrive at the point of protocol 
> extinction for IPv6 with some addresses
> still in inventory. However, whether that happens with a single /32 or 
> a dozen /12s or even more really
> makes no difference. There’s absolutely no advantage to keeping 
> addresses on the shelf if they are useful.
>
> Consider that IANA has issued roughly 6 /12s from the current /3 
> designated for IPv6 UNICAST (1 full /12
> to each RIR and some various other fragments from earlier experiments 
> and early allocations).
>
> Each /12 contains 2^36 = ~64 Billion /48s. There are 7 Billion people 
> world wide. That means that each
> RIR already holds enough address space to grant 9 ISPs enough /48s to 
> allocate one to every single man,
> woman, and child on earth and still have lots left over. (There are 5 
> RIRs, so in fact, worldwide, that’s
> 45 ISPs).
>
> I don’t know very many people who subscribe to more than 3 or 4 ISPs 
> in total. Even if we assume that
> half of that address space is needed for servers, network 
> infrastructure, businesses, etc., we’re still
> OK and that’s just in the first 5 /12s. There are 506 times that much 
> space remaining in the IANA free
> pool of designated unicast addresses just waiting to go to RIRs if the 
> need arises. That’s
> enough addresses for 23,000 ISPs to give EVERY man, woman and child 
> their own /48. (11,500 if we
> assume half of all address space goes to infrastructure, servers, 
> businesses, etc.)
>
> So long as we rationally allocate /48s, there will not be an address 
> shortage in IPv6 as a result, so there
> is simply no justification and no benefit whatsoever from 
> micro-allocating down to the /56.
>
> Another consideration I will put here:
>
> We don’t know what will happen in the future. We do know what has 
> happened in the past. Today, we have
> very screwy and difficult limitations in doing many innovative things 
> on the internet that are a result
> of address scarcity and the unfortunate pitfalls of address-sharing 
> technologies like NAT.
>
> Tons of services that would be quick, simple, straightforward, and 
> reliable to implement via a
> direct peer-to-peer connection involve convoluted solutions with 
> rendezvous hosts and other hacks
> and workarounds just to cope with this address scarcity.
>
> Let’s not encumber the future with the same mistakes of the past.
>
> Some will see that statement as an argument for more aggressive 
> conservation in IPv6, but only if they
> have not reviewed the math and the historical details.
>
> When 32 bits was chosen for IPv4, it was not expected to be a 
> direct-to-consumer network. There was
> no concept of a “world wide web”. The “browser” did not exist yet. 
> There were no “URLs”. The internet
> was something used by researchers and educational institutions and 
> primarily for sending email
> and transferring files between mini computers using ASCII terminals 
> and text interfaces.
>
> 4 billion seemed like a lot of addresses because we didn’t expect to 
> need to number very much of the
> world.
>
> We learned from that mistake and 64 bits was chosen because it would 
> provide enough addresses to
> number virtually everything on earth down to the molecule.
>
> (Yes, I said 64 bits… That _WAS_ the initial plan for IPv6, 64 bits 
> with /48 subnets allowing
> for 65,536 hosts per subnet).
>
> Later someone decided that stateless address configuration would be 
> useful for lightweight implementations
> and wanted to use EUI-64 addresses as an address suffix. This idea 
> appealed to people at the time,
> so the address space was extended to 64-bit subnets and to make things 
> fit well in memory chunks
> the prefix portion was rounded up to 64 bits as well. While CIDR has 
> been preserved in IPv6 and
> all software should fully support any valid prefix length down to 
> /127, conceptually, IPv6 is designed
> to be thought of as 64+64 where you have a 64 bit network number and 
> 64 bit host. Further, the
> design took into account the growing amount of network equipment in 
> the average home and suggested
> the use of /48s as a standard end-site prefix.
>
> They made sure that there would be enough addresses to number 
> EVERYTHING even with such large allocations.
>
> Oh, and there’s also a built-in escape hatch.
>
> See in all of that math I quoted above… That’s just the first 1/8th of 
> the address space. There’s some
> special purpose utilization in the last 1/8th as well, so let’s 
> discount that and say that even if we use
> up all of those two /3s, we’ve still got 3/4 of the total address 
> space available.
>
> So, I encourage everyone to use /48s and try it this way. If we run 
> out of the first /3 within my lifetime,
> I will happily help you work towards more restrictive practices on the 
> remaining 6 /3s.
>
> Owen
>
>> On Sep 19, 2016, at 13:39 , Fernando R. Soto <fsoto en fi.uba.ar 
>> <mailto:fsoto en fi.uba.ar>> wrote:
>>
>> Gracias por la respuesta Arturo
>> Por favor, me explicas pq no alcanzaría un /56 para q el cliente arme 
>> sus propias subredes? (256 subredes)
>> Es un tema de automatización de la creación de esas subredes?
>> Slds.
>> *De:*lista-bounces en arnog.com.ar <mailto:lista-bounces en arnog.com.ar> 
>> [mailto:lista-bounces en arnog.com.ar]*En nombre de*Arturo Servin
>> *Enviado el:*lunes, 19 de septiembre de 2016 5:02 p. m.
>> *Para:*lista en arnog.com.ar <mailto:lista en arnog.com.ar>
>> *Asunto:*Re: [Lista ArNOG] IPv6 en ISP
>> Fernando
>> Te vas a quedar corto sobre la hipótesis que los servicios futuros 
>> van a requerir mas de una subred. Por ejemplo al dia de hoy podria 
>> normal que se requiriera una subred para tus invitados, otra para tu 
>> home-networking y otra para tus dispositivos. Porque IPv4 es tan 
>> escaso que solo tenemos una, pero si no fuera por eso podriamos tener 
>> mas.
>> Por ello, un /64 o un /56 (256 /64s) sera insuficientes y por ello 
>> requieres planear a dar un /48 (aunque ahora des un /56 o /64), de 
>> otra forma vas a tener que renumerar y eso te va a costar plata.
>> Si la hipotesis es valida o no, eso es otra cosa. Lo que si es que te 
>> recomendaria no dar /64 y al menos un /56, eso creo que es mas o 
>> menos aceptado. Un /48, es debatible aun pero para algunos es lo que 
>> recomiendan.
>> /as
>> On Mon, 19 Sep 2016 at 19:56 Fernando R. Soto <fsoto en fi.uba.ar 
>> <mailto:fsoto en fi.uba.ar>> wrote:
>>> Hola Ariel
>>> No entendí pq me voy a quedar corto. Siendo que entrego un bloque 
>>> menor a los clientes. /56 en vez de /48
>>> No se podría entregar /64 a clientes hogareños y /56 o /48 a 
>>> servicios corporativos?
>>> Slds.
>>> *De:*lista-bounces en arnog.com.ar 
>>> <mailto:lista-bounces en arnog.com.ar>[mailto:lista-bounces en arnog.com.ar 
>>> <mailto:lista-bounces en arnog.com.ar>]*En nombre de*Ariel Weher
>>> *Enviado el:*lunes, 19 de septiembre de 2016 2:02 p. m.
>>>
>>> *Para:*lista en arnog.com.ar <mailto:lista en arnog.com.ar>
>>> *Asunto:*Re: [Lista ArNOG] IPv6 en ISP
>>> Con el tiempo te vas a quedar corto. Mi consejo es mantener el /48 y 
>>> extender el /32 asignado a /29.
>>> No debería ser un problema, porque en v6 abundan las direcciones y 
>>> no LACNIC va a ser  más permisivo que con v4.
>>> Incluso en RIPE hay políticas aprobadas para entregar /29 en vez de 
>>> /32, a fin de favorecer algunas técnicas de transición.
>>> S2
>>> 2016-09-19 14:00 GMT-03:00 Fernando R. Soto <fsoto en fi.uba.ar 
>>> <mailto:fsoto en fi.uba.ar>>:
>>>> /48 es la escuela de Jordi. Je
>>>> A mi q con un solo AS manejo varios Pops se me complicar entregar 
>>>> un /48 por cliente
>>>> Q pasa si entrego /56?
>>>> Slds.
>>>> *De:*lista-bounces en arnog.com.ar 
>>>> <mailto:lista-bounces en arnog.com.ar>[mailto:lista-bounces en arnog.com.ar 
>>>> <mailto:lista-bounces en arnog.com.ar>]*En nombre de*Ariel Weher
>>>> *Enviado el:*lunes, 19 de septiembre de 2016 1:39 p. m.
>>>> *Para:*lista en arnog.com.ar <mailto:lista en arnog.com.ar>
>>>> *Asunto:*Re: [Lista ArNOG] IPv6 en ISP
>>>> /48 a cada cliente, sin importar que clase de servicio sea.
>>>> RFC6177
>>>> S2.
>>>> 2016-09-19 13:10 GMT-03:00 Mariano Carea <mcarea en grupojunin.com.ar 
>>>> <mailto:mcarea en grupojunin.com.ar>>:
>>>>>
>>>>> Buen día, algún ISP ya implementó IPv6 en sus clientes ? como 
>>>>> subdividió la redes ?
>>>>>
>>>>> gracias
>>>>>
>>>>> -- 
>>>>> Ing. Mariano Carea
>>>>> Dpto. de Comunicaciones
>>>>> Grupo Servicios Junín
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Lista mailing list
>>>>> Lista en arnog.com.ar <mailto:Lista en arnog.com.ar>
>>>>> http://mailmancabase.interdotnet.com.ar/mailman/listinfo/lista 
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailmancabase.interdotnet.com.ar_mailman_listinfo_lista&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=CzEjTBajXfTP9RRXS6wBa3iLtjqvm25nRzQ6XwtBPxE&s=Mf-ttdf2pQ_cJWbLkqxc-ES8syrAXxAuvdyVa7Gi-j0&e=>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Lista mailing list
>>>> Lista en arnog.com.ar <mailto:Lista en arnog.com.ar>
>>>> http://mailmancabase.interdotnet.com.ar/mailman/listinfo/lista 
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailmancabase.interdotnet.com.ar_mailman_listinfo_lista&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=CzEjTBajXfTP9RRXS6wBa3iLtjqvm25nRzQ6XwtBPxE&s=Mf-ttdf2pQ_cJWbLkqxc-ES8syrAXxAuvdyVa7Gi-j0&e=>
>>>>
>>> _______________________________________________
>>> Lista mailing list
>>> Lista en arnog.com.ar <mailto:Lista en arnog.com.ar>
>>> http://mailmancabase.interdotnet.com.ar/mailman/listinfo/lista 
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailmancabase.interdotnet.com.ar_mailman_listinfo_lista&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Q_d8tNiSzoBecM8os8iGQA&m=CzEjTBajXfTP9RRXS6wBa3iLtjqvm25nRzQ6XwtBPxE&s=Mf-ttdf2pQ_cJWbLkqxc-ES8syrAXxAuvdyVa7Gi-j0&e=>
>> _______________________________________________
>> Lista mailing list
>> Lista en arnog.com.ar <mailto:Lista en arnog.com.ar>
>> http://mailmancabase.interdotnet.com.ar/mailman/listinfo/lista
>
>
>
> _______________________________________________
> Lista mailing list
> Lista en arnog.com.ar
> http://mailmancabase.interdotnet.com.ar/mailman/listinfo/lista

-- 
Andres Pugawko
Chief Technology Officer
Cámara Argentina de Internet - CABASE
Suipacha 128 - Piso 3°  F
(C1008AAD)  Buenos Aires - Argentina
Tel: (54-11) 4326-0777 int 9112
Cel: 11-6915-7866
www.cabase.org.ar

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mailmancabase.interdotnet.com.ar/pipermail/lista/attachments/20160923/e0ae51f8/attachment-0001.html>