Introducción de IPv6 en Telecom Argentina · Introducción de IPv6 en Telecom Argentina 1 Estado...

Introducción de IPv6 en Telecom

Argentina

1

Estado actual y próximos pasos

LACNOG - San Pablo, Brasil

Octubre de 2010

Gabriel N. Castro

Introducción de IPv6 en Telecom Argentina

AgendaParte A -Despliegue

• ESTADO ACTUAL DEL DESPLIEGUE de IPv6

• INTRODUCCION DE IPv6 EN EL BACKBONE MPLS- Foco en accesos corporativos y wholesale

• TECNOLOGIA “6PE”

• TECNOLOGIA “6VPE”

• EXPERIENCIA EN ACTIVACIÓN DE SERVICIOS IPv6

Parte B- Prospección

2

Parte B- Prospección

• ESTUDIO DE ESTRATEGIAS DE TRANSICION A IPV6 EN EL ACCESO MASIVO

• PRIMER PASO EN LA ESTRATEGIA DE RESOLUCION DE FALTA DE DIRECCIONES IPV4 PARAACCESOS MASIVOS- CARRIER GRADE NAT-

TECNOLOGÍA DE TUNNELING “6RD”- Foco en Accesos Masivos

• TECNOLOGÍA DE DUAL–STACK- Foco en Accesos Masivos

• CASO ACCESO BROADBAND FIJO xdsl DUAL-STACK- Arquitectura PPPoE – IPoE

• CASO ACCESO BROADBAND MOVIL DUAL STACK

RECOMENDACIONES

• Tecnología dual-stack IPv6+IPv4 para servicios de acceso a Internet en

proceso despliegue en el edge del Backbone IP/MPLS- mas del 95%

completo.

• Interconexion internacional en dual-stack IPv6 + IPv4 actualmente en

producción con 3000 prefijos IPv6 recibidos desde el exterior y presencia

de Telecom en Internet IPv6 con su propio prefijo.

Estado Actual del Despliegue de IPv6

Introducción de IPv6 en Telecom Argentina- Parte A “ Despliegue”

3

de Telecom en Internet IPv6 con su propio prefijo.

• Un cliente corporativo en producción para servicios de acceso a internet

en dual-stack IPv6 + IPv4 accediendo a PE del BBIP mediante acceso

metroethernet layer 2.

• En desarrollo incorporación de tecnología dual-stack para servicios VPN

MPLS en IPv6. Actualmente en fase de homologación interna en

laboratorio.

• En estudio soluciones técnicas para incorporar IPv6 al acceso broadband

móvil celular y fijo.

Introducción de IPv6 en Telecom Argentina - Parte A “ Despliegue”

Introducción de IPv6 en el Backbone MPLS

-foco en servicios corporativos y wholesale-

• Tecnología “6PE”- RFC 4798. 6PE- IPv6 packets transported

from PE to PE inside MPLS network

• Tecnología ”6VPE”- RFC 4659- 6VPE (IPv6 packets

4

• Tecnología ”6VPE”- RFC 4659- 6VPE (IPv6 packets

transported from PE to PE inside VPN-MPLS network)


Tecnología “6PE”: Principales Beneficios y

Consideraciones

• No se requiere modificar el funcionamiento de la capa de core

MPLS “P” existente

• El trafico IPv6 recibe los beneficios de MPLS ( TE, FRR, rápida

conmutación, etc.)

• Se debe adaptar la capa de edge MPLS “PE” que aprovisionara los

5

• Se debe adaptar la capa de edge MPLS “PE” que aprovisionara los

servicios al cliente. Esta función posibilita brindar conectividad IPv4,

IPv4+IPv6, o IPv6 hacia el CPE. Solo los routers PE deberán ser

adaptados, minimizando el impacto

• Los routers PE podran soportar los protocolos de routing en IPv6

de forma similar a los usados en IPv4. Los recursos de control plane

estan compartidos. En este punto, hay que tener en cuenta el

concepto de “ DOS REDES LOGICAS Superpuestas “


• La función de MP-BGP utilizada para los servicios IPv4 se mantiene con el

agregado de una familia de direcciones nueva para IPv6. Se puede reultilizar la

misma infraestructura de Route Reflector de IPv4, aunque es recomendable

separar las funciones de control plane IPv6 de la de IPv4 para lograr mayor

estabilidad y escalabilidad ( un RR para Ipv4 y otro para IPv6 )

Tecnología “6PE”: Principales Beneficios y

Consideraciones

Key Points:

6

• El atributo next-hop que va en la publicación MP-BGP es la dirección IPv4

loopback del 6PE. Es un dirección IPv4 mapeada a IPv6. Se forma del siguiente

modo para ser publicada (::FFFF:<6PE loopback IPv4 address>).

• Al paquete IPv6 de ingreso en la red se lo transporta mediante la imposición de

dos etiquetas lógicas del stack MPLS:

Outer label: la etiqueta ldp en este nivel los conduce hasta el 6PE de salida

Inner label: la etiqueta asignada por iBGP para que el paquete IPv6 en cuanto

arribe al 6PE de salida llegue al destino. Sin esta etiqueta el paquete seria

descartado luego del penultimate-hop-popping. Se denomina BGP label


Prefijo IPv6 6PE

7

B 2001:F00D::/64 [200/0]

vía ::FFFF:200.10.10.1, IPv6-mpls

2001:F00D::/64,

nexthop ::FFFF:200.10.10.1

tags imposed { 48 65 }

ldp bgpFuente : Cisco Systems


• 6VPE agrega el soporte de IPv6 a la funcionalidad ya existente de

MPLS VPN en IPv4.

• El cliente final mantiene el mismo servicio de VPN con las mismas

funcionalidades (calidad de servicio, topologías full mesh o hub and

spoke, acceso a internet, etc).

• En el backbone MPLS se mantiene la misma modalidad de

Tecnología “6VPE”: Principales Beneficios y

Consideraciones

8

• En el backbone MPLS se mantiene la misma modalidad de

configuración para la provisión y operación, tanto para una VPNv4

como una VPNv6.

• La capa de core del Backbone se mantiene sin cambios.

• Se debe adaptar la capa de edge MPLS “PE” que provisionará los

servicios al cliente. Esta función posibilita brindar conectividad en

VPN para IPv4, IPv4+IPv6, o IPv6 hacia el CPE. Solo los routers PE

deberán ser adaptados, minimizando el impacto


• La función de MP-BGP utilizada para los servicios VPNv4 se

mantiene con el agregado de una familia de direcciones nueva

para VPNv6 (AFI=2, SAFI=128). Se puede reultilizar la misma

infraestructura de Route Reflector de VPNv4, aunque es

Tecnología “6VPE”: Principales Beneficios y

Consideraciones

9

infraestructura de Route Reflector de VPNv4, aunque es

recomendable separar las funciones de control plane VPNv6 de la

de VPNv4 para lograr mayor estabilidad y escalabilidad ( un RR para

VPNv4 y otro para VPNv6).

• Los routers PE podrán soportar los protocolos de routing en IPv6

de forma similar a los usados en IPv4. Los recursos de control plane

estan compartidos. En este punto, hay que tener en cuenta el

concepto de “ DOS REDES LOGICAS superpuestas “.


Prefijos IPv6 en VRF

10

B 2001:db8:beef:1::/64 [200/0]

via 200.10.10.1%Default-IP-Routing-Table, indirectly connected

B 2001:db8:beef:2::/64 [20/0]

via FE80::A8BB:CCFF:FE01:FA00, Ethernet1/0

B 2001:db8:cafe:1::/64 [200/0]

via 200.10.10.1%Default-IP-Routing-Table, indirectly connected

C 2001:db8:cafe:3::/64 [0/0]

via Ethernet1/0, directly connected

Fuente : Cisco Systems


Experiencia en Activación de Servicios IPv6

• Con el test field finalizado en 2010 con la Red de

Interconexión universitaria administrada por la RIU, Telecom

marco su primer hito iniciando un camino de largo plazo hacia

la transición final a IPv6. Es el primer servicio comercial de

acceso a internet brindado por la compañía.

11

• http://www.riu.edu.ar/topologia.html

• La solución utilizada es 6PE (IPv6 over mpls-ipv4) sobre el Backbone y Dual Stack IPv4-IPv6 en el acceso .


La RIU (4270) propaga a Telecom los siguiente prefijos

*> 2800:110::/32 2001:13d0::2 0 0 4270 i ��-- RIU

*> 2800:340::/32 2001:13d0::2 0 4270 5692 I ��-- AS clientes RIU

*> 2800:1c0::/32 2001:13d0::2 0 4270 27770 i

El router internacional anuncia los prefijos ipv6propagados:

Network Next Hop From AS Path

2001:13d0::/32 190.225.250.10 200.3.61.94 i

2001:41a8:5000:2::c/126

:: Local ?


12

:: Local ?2800:110::/32 190.225.250.10 200.3.61.94 4270

2800:1c0::/32 190.225.250.10 200.3.61.94 4270 27770 i

2800:340::/32 190.225.250.10 200.3.61.94 4270 5692 i

Loocking glass del prefijo RIU (4270) anunciado por Seabone-v6

2800:110::/32

BGP routing table entry for 2800:110::/32, version 40716

Bestpath Modifiers: deterministic-med

Paths: (1 available, best #1, table Global-IPv6-Table)

Not advertised to any peer

7303 4270

:FFFF:195.22.220.253 (metric 815) from 195.22.220.253(195.22.220.253)

Origin IGP, metric 0, localpref 100, valid, internal, best

Community: 6762:1 6762:92 6762:15400

El siguiente show muestra el data plane de trafico en sentido download deinternet. El trafico es conducido por el LSP con impositions de labels mplsque aplica el primer salto al core, el P recibira el paquete y hace el pop delldp-label (outer label).

2001:13d0::/32, version 3, internal 0x40040001 (0x9d82fa80) [1], 0x0 (0x0), 0x4100(0x9d607728)

Updated Jun 3 17:00:49.113

Prefix Len 32, traffic index 0, precedence routine (0)

via ::ffff:190.225.250.10, 3 dependencies, recursive ��--- ipv6 nh no valido

next hop ::ffff:190.225.250.10 via ::ffff:190.225.250.10:0

next hop 200.3.32.133 Te0/0/0/0 labels imposed {16509 20137} ��-- bgp-label

next hop 200.117.124.13 Te0/9/0/0 labels imposed {16619 20137} ��- ldp-label


• Se requirió un periodo de prueba de campo para estabilizar el servicio.

• Las pruebas se iniciaron en la modalidad de túneles manuales IPv6 sobre

IPv4 . La solución se extendió hasta el upstream provider. Los resultados

en esta etapa no fueron satisfactorios debido a la inestabilidad en el

routing y la dificultad operativa en el troubleshoting.

• Al migrar a la solución dual-stack en el acceso, se logro mantener el

Experiencia en Activación de Servicios IPv6 con Clientes

13

• Al migrar a la solución dual-stack en el acceso, se logro mantener el

mismo plano de forwarding para IPv4 e IPV6, logrando una mejor

predicción de trayectorias de tráfico y facilidad de la operación industrial

a gran escala.

• El costo de la solución es mayor en Dual Stack (se construyen y mantienen

dos redes, seguridad incluida).



Estado DNS

DNS Resolver software dual stack.

DNS dentro del dominio IPv6: 0.d.3.1.1.0.0.2.ip6.arpaANSWER SECTION:0.d.3.1.1.0.0.2.ip6.arpa. 1H IN NS sn2.telecom.net.ar.0.d.3.1.1.0.0.2.ip6.arpa. 1H IN NS sn1.telecom.net.ar.0.d.3.1.1.0.0.2.ip6.arpa. 1H IN SOA sn1.telecom.net.ar. noc.ta.telecom.com.ar

Resolución inversa del prefijo /32 asignado a Telecom, OK.

14

Resolución inversa del prefijo /32 asignado a Telecom, OK.

Resolución inversa y directa de los inversos de cada host IPv6 de

Telecom : falta adaptar la aplicación que hace de interfaz de usuario

para la carga de los registros. La opción hoy es manual. En estudio

addressing.

Resolución autoritativa software dual stack.



Estado DNS

query nslookup ipv6.google.com aaaa

> set type=aaaa

> ipv6.google.com

Servidor: ns1.arnet.com.ar

Address: (x.x.x.x , ipv4)

Respuesta no autoritativa:

ipv6.google.com canonical name = ipv6.l.google.com

ipv6.l.google.com AAAA IPv6 address = 2800:3f0:8001::68

Access Google services over IPv6, www.google.com/intl/en/ipv6/

*separate DNS servers for your IPv6 users ( not shares

with IPv4-oly users)

15

ipv6.l.google.com AAAA IPv6 address = 2800:3f0:8001::68

query nslookup www.google.com aaaa > set type=aaaa

> www.google.com




www.google.com canonical name = www.l.google.com

I.google.com

primary name server = ns1.google.com

responsible mail addr = dns-admin.google.com

query nslookup www.google.com a >set type=a

> www.l.google.com




Nombre: www.l.google.com

Address: 209.85.195.104



Estado DNSnslookup www.yahoo.com.arServidor: rc.a07.yahoodns.netAddress: 206.190.60.37Aliases: www.yahoo.com.ar

rc.yahoo.com

nslookup www.facebook.comServidor: www.facebook.comAddress: 69.63.190.18

nslookup isoc.orgServidor: isoc.orgAddresses: 2001:41c8:20::19

212.110.167.157nslookup www.iana.orgServidor: ianawww.vip.icann.orgAddresses: 2620:0:2d0:200::8

192.0.32.8Aliases: www.iana.orgnslookup www.arin.netServidor: www.arin.net

Dual Stack

nslookup twitter.comServidor: twitter.comAddresses: 128.242.245.148

128.242.250.148128.242.245.244

nslookup www.linkedin.comServidor: www.linkedin.comAddress: 64.74.98.80

16

Address: 69.63.190.18

nslookup www.flickr.comServidor: www.flickr.a00.yahoodns.netAddress: 68.142.214.24Aliases: www.flickr.com

nslookup www.ebay.comServidor: hp-core.ebay.comAddresses: 66.211.181.11

66.211.181.1566.211.181.19

Aliases: www.ebay.com

Servidor: www.arin.netAddresses: 2001:500:4:13::81

2001:500:4:13::80192.149.252.76192.149.252.75

nslookup www.lacnic.netServidor: lacnic.netAddresses: 001:13c7:7002:4000::10

200.3.14.10Aliases: www.lacnic.netnslookup www.ietf.orgServidor: www.ietf.orgAddresses: 2001:1890:1112:1::20

64.170.98.32

Address: 64.74.98.80

---------------------------------------------

nslookup www.youtube.comServidor: youtube-ui.l.google.comAddresses: 72.14.253.91

72.14.253.9372.14.253.19072.14.253.136

Aliases: www.youtube.com( require Google over IPv6 service )



• Trayectorias con baja latencia.

Desafíos en la Interconexión

Hipótesis:

“ Cuando una determinada cantidad de clientes tengan la

posibilidad de acceder a IPv6, sus comunicaciones fallarán por

timeout en lugar de transparentemente switchear a IPv4….”

17

• Trayectorias con baja latencia.

• Simetria en trayectos IPv4 e IPv6 para el mismo sitio.

• Confiabilidad

• Conectividad de DNS

• Soporte con procesos industriales




New York IPv41 nyk-bb2-link.telia.net (80.91.248.161) 0.339 ms

1.982 ms nyk-bb1-link.telia.net (80.91.249.17) 1.989

ms

2 ash-bb1-link.telia.net (80.91.245.98) 35.500 ms

ash-bb1-link.telia.net (80.91.248.200) 29.940 ms

6.747 ms

3 atl-bb1-link.telia.net (213.248.80.142) 20.051 ms

atl-bb1-link.telia.net (80.91.248.137) 21.459 ms

21.437 ms

Honk Kong IPv41 las-bb1-link.telia.net (80.91.247.102)

174.447 ms 174.536 ms 174.502 ms

2 dls-bb1-link.telia.net (213.248.80.14)

213.887 ms 213.555 ms 213.396 ms

3 mai-b1-link.telia.net (80.91.252.62) 244.275

ms 244.249 ms 244.304 ms

4 telecomitalia-ic-127261-mai-b1.c.telia.net

(80.239.193.162) 244.468 ms 244.349 ms

244.372 ms

Berlin IPv41 ffm-bb2-link.telia.net (80.91.254.228) 20 msec 20 msec

20 msec

2 ffm-b2-link.telia.net (80.91.252.174) 44 msec

ffm-b2-link.telia.net (80.91.247.169) 20 msec 16 msec

3 te1-3.franco34.fra.seabone.net (89.221.34.161) 20

msec 20 msec

te2-2.franco34.fra.seabone.net (89.221.34.165) 20

msec

4 telecom-argentina.baires2.bai.seabone.net

------------------------------------------ TeliaSonera Looking Glass-----------------------------------------------------------------

18

21.437 ms

4 mai-b1-link.telia.net (80.91.252.58) 38.984 ms

37.525 ms mai-bb1-link.telia.net (80.91.251.29)

53.776 ms

5 telecomitalia-ic-127261-mai-b1.c.telia.net

(80.239.193.162) 43.492 ms 39.071 ms 60.046 ms


(195.22.220.214) 170.154 ms 165.210 ms 166.600

ms

IPv61 ash-bb1-v6.telia.net (2001:2000:3018:2b::1)

6.936 ms 7.998 ms 12.983 ms

2 2001:41a8:5000:2::e (2001:41a8:5000:2::e)

168.867 ms 164.793 ms 166.435 ms

3 * * *

4 2001:13d0:0:1::1 (2001:13d0:0:1::1) 170.741 ms

172.377 ms 182.020 ms

244.372 ms


(195.22.220.214) 381.264 ms 379.152 ms 380.029 ms

IPv61 ash-bb1-v6.telia.net (2001:2000:3018:2b::1)

230.699 ms 244.673 ms 223.001 ms

2 2001:41a8:5000:2::e (2001:41a8:5000:2::e)

393.738 ms 387.043 ms 399.169 ms

3 * * *

4 2001:13d0:0:1::1 (2001:13d0:0:1::1)

426.185 ms 392.505 ms 397.927 ms


(195.22.220.214) 268 msec 276 msec 280 msec

IPv61 * * *

2 telia.franco34.fra.seabone.net (2001:41A8:600:2::45)

20 msec

telia.franco34.fra.seabone.net (2001:41A8:600:2::5D)

20 msec

telia.franco34.fra.seabone.net (2001:41A8:600:2::45) 20

msec

3 telia.franco34.fra.seabone.net (2001:41A8:600:2::5D)

20 msec * 20 msec

4 2001:41A8:5000:2::E 284 msec 284 msec 264 msec

5 * * *

6 2001:13D0:0:1::1 284 msec 284 msec 272 msec

Testing IPv6-IPv4,Buenos Aires2001:13d0:0:1::1 , 186.125.253.1

Sao Paulo IPv41 201.20.8.37,static.201.20.8.37.datacenter1.com.br,0.0%,5,0.6,1.7,2.2

2 201.20.8.201,g3-3-edge-02-sp.alog.com.br,0.0%,5,0.6,1.0,42.9

3 195.22.219.73,ge5-0-3-100.sanpaolo2.spa.seabone.net,0.0%,5,1.4,2.4,1.7

4 195.22.220.121,ge2-0-0.baires2.bai.seabone.net,0.0%,5,28.1,28.4,28.3

5 195.22.220.214,telecom-argentina.baires2.bai.seabone.net,0.0%,5,29.3,31.6,30.2

6 200.3.32.137,host137.200-3-32.telecom.net.ar,0.0%,5,29.0,29.2,29.1

Sao Paulo IPv41 ge-2-1-0-1.core-a.spo511.ctbc.com.br (201.48.235.9) 0.706

ms 0.714 ms 0.729 ms

2 ge-2-1-0-0.core-b.spo511.ctbc.com.br (201.48.44.26) 0.592

ms 0.655 ms 0.627 ms

3 ge4-0-0.sanpaolo1.spa.seabone.net (195.22.219.181) [AS

6762] 1.385 ms 1.140 ms 1.001 ms

Looking Glass Algar Telecom ALOG Datacenters do Brasil - Looking Glass




19



IPv61, 2001:12e8:1:6::2,--,0.0%,5,0.7,0.9,0.8

2 2001:12e8:1:1::2:1,--,0.0%,5,0.6,2.5,1.1

3 2001:12ff:aaaa::3:703:1,as22548-703.ipv6.nic.br,0.0%,5,0.9,1.0,1.0

4 2001:12ff:2:1::241,ge-0-2-0.0.gw01.registro.br,0.0%,51.0,1.0,1.1

5 2001:450:2002:7f::1,--,60.0%,5,1.3,1.3,1.3,

6 ???,--,100.0,5,0.0,0.0,0.0

7 2001:41a8:5000:2::e,--,20.0%,5,50.7,50.7,51.5

8 2001:41a8:5000:2::e,--,40.0%,5,50.5,52.0,51.1

9 ???,--,100.0,5,0.0,0.0,0.0,

10 2001:13d0:0:1::1,--,60.0%,5,51.3,51.3,52.0

6762] 1.385 ms 1.140 ms 1.001 ms

4 ge0-0-0.baires2.bai.seabone.net (195.22.220.123) [AS 6762]

68.062 ms 68.078 ms 68.278 ms

5 telecom-argentina.baires2.bai.seabone.net (195.22.220.214)

[AS 6762] 83.737 ms 91.210 ms 64.700 ms

IPv61 2001:1291:0:28::b (2001:1291:0:28::b) 0.729 ms 0.656 ms

0.511 ms

2 2001:1291:0:5::a (2001:1291:0:5::a) 0.690 ms 10.228 ms

0.723 ms

3 ctbc.sanpaolo1.spa.seabone.net (2001:41a8:5200:2::11)

16.820 ms 1.494 ms 16.633 ms

4 2001:41a8:5000:2::e (2001:41a8:5000:2::e) 43.117 ms

32.112 ms 30.711 ms

5 2001:41a8:5000:2::e (2001:41a8:5000:2::e) 29.883 ms

29.131 ms 28.761 ms

Introducción de IPv6 en Telecom Argentina - Parte B “ Prospección”

Estudio de Estrategias de Transición a IPv6 en el

Acceso Masivo

20



Primer Paso en la Estrategia de Mitigación de Falta de

Direcciones IPv4 para Accesos Masivos - Carrier

Grade NAT-

• Estandarizacion IETF: Double NAT (NAT444) for CGN ( Carrier Grade NAT).

NAT444 with ISP Shared Address. draft-shirasaki-nat444-isp-shared-addr-

00.

• A los usuarios se les asigna un dirección IPv4 privada. En el acceso al

21

• A los usuarios se les asigna un dirección IPv4 privada. En el acceso al

backbone , se traduce a IPv4 pública , compartida entre varios .

• En estudio para eventual introducción en conexión GGSN y servicios

broadband móvil.

• Desafíos en tratamiento (intercepción legal y patrones de aplicaciones

particulares , operación y troubleshooting). No resuelve el largo plazo

para la falta de direcciones IPv4).


• Statefull NAT444

• 20M de translaciones

• 1M de conecciones/seg

• Registros (timestamp, privado/publico SA, DA, port information)

• Alto throughput simetrico (perfil ~10 sesiones con 100Kb de b/w cada una)


Direcciones IPv4 para Accesos Masivos - Carrier Grade NAT-

22

• Alto throughput simetrico (perfil ~10 sesiones con 100Kb de b/w cada una)

• Port Limit (100/30/3)

• Port Forwarding

• ALGs (problema de RTSP, costo/complejidad en el soporte de ALGs para

miles de subscriptores con IP privada, variedad de versiones de ALGs

dependiendo de la aplicación, problemas regulatorios si se modifican en la

red aplicaciones OTT utilizando ALGs, geo-localización,etc )

• Redundancia activa 1 + 1



Direcciones IPv4 para Accesos Masivos - Carrier Grade NAT-


23

Incoming VRF Outgoing VRF SrcAddress Translated Adr SrcPort Translated Port Protocol

60000002 60000003 192.168.1.29 128.107.74.221 409 54115 UDP

60000002 60000003 192.168.1.130 128.107.74.221 410 54106 UDP

60000002 60000003 192.168.1.131| 128.107.74.221 411 37093 UDP


Tecnología de Tunneling “6RD”- Foco en Accesos

Masivos

• Estandarización IETF : PROPOSED-STANDARD RFC 5969

IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

Protocol Specification

Abstract :”This document specifies an automatic tunneling mechanism tailored to

advance deployment of IPv6 to end users via a service provider's IPv4 network

infrastructure. Key aspects include automatic IPv6 prefix delegation to sites,

24

infrastructure. Key aspects include automatic IPv6 prefix delegation to sites,

stateless operation, simple provisioning, and service, which is equivalent to native

IPv6 at the sites that are served by the mechanism”

• Mecanismo de transición para un rápido despliegue de servicios IPv6 sobre redes

de acceso IPv4 existentes. Encapsula el tráfico IPv6 sobre IPv4. Se requiere

provisionar únicamente sobre los extremos del túnel. No se requiere

implementar Neighbor Discovery, ICMPv6, u otros protoclos de Ipv6 en la red de

acceso.

• Extremos del túnel : 6RD Border Relay dual stack en el backbone, y módem dual

stack en la casa de cliente con soporte de 6RD


Principales ventajas:

• La dirección IPv6 se deriva de la dirección IPv4 (prefijo IPv6 6RD del carrier + IPv4 del CPE +

ID de interfaz ). El RG obtiene el prefijo 6RD y la dirección IPv4 del BR mediante DHCPv4.

• Facilita el provisioning y reduce la inversión en sistemas informáticos

• No requiere modificar la red de acceso. No requiere BAS con soporte IPv6. Solo el CPE dual

stack.

• No requiere mantener estados


Masivos

25

• No requiere mantener estados

• Se puede combinar con NAT444

• Routing eficiente interdominio. Utiliza el prefijo IPv6 del carrier, a diferencia de 6to4. El

tráfico IPv6 sigue el enrutamiento IPv4. Si la dirección IPv6 destino pertenece al mismo

carrier, el paquete es enrutado directamente al destino sin pasar por el BR.

Desafíos :

• Se requiere upgrade de los CPE. En desarrollo en el mercado.

• Planning capacity. Bottlenecks

• El extraheader de encapsulado podría reducir el rendimiento del BW de acceso.

• Multicast



Masivos

26

Prefijo 6RD IP v4 Interface ID

Prefijo IPv6 (64 bits) 64 bits

<= 32 bits 32 bits

Dirección IPv6 formada utilizando un prefijo 6RD



Tecnología “Dual Stack”- Foco en Accesos Masivos

IPv6 y IPv4 dual stack

Ventajas

•Soporta aplicaciones IPv4

existentes.

Puede ser combinado con NAT44

Desafíos

•Continuar utilizando IPv4 no

resuelve la falta de direcciones

IPv4.

27

•Puede ser combinado con NAT44

para mitigación de falta de

direcciones IPv4.

•Cuando los servicios estén en IPv6,

se puede discontinuar IPv4

fácilmente.

IPv4.

•Desplegar IPv6 sobre una

infraestructura IPv4 deriva en un

modelo de dos redes lógicas , que

puede aumentar el costo de Capex

y Opex



Acceso Broadband PPP

Acceso Broadband IPoE

•Dual Stack soportado sobre una misma sesión PPP compartida. Se

ejecuta NCP v4 y NCP v6 simultáneamente.

•No consume recursos extra de estado de sesión de BRAS.

• Esta en estudio la forma de simular el concepto de “sesión”. Las

28

Estandarizacion:

Broadband Forum TR-187: IPv6 for PPP Broadband Access

Broadband Forum TR-101: BNG capabilities and definitions

Broadband Forum WT-177 (draft): IPv6 in the Context of TR-101

• Esta en estudio la forma de simular el concepto de “sesión”. Las

posibilidades son :

•Modelo de dos sesiones independientes, una para IPv4 y otra para IPv6.

•Modelo de una única sesión Layer 2, donde Ipv4 e Ipv6 se ejecutan

sobre una sesión L2/MAC en común.



Métodos de Asignación de Direcciones IPv6

•RA

El BAS distribuye al cliente un prefijo /64 .

• DHCPv6-PD

El BAS distribuye al CPE un prefijo /48 utilizando DHCPv6-

PD, luego el CPE distribuye al cliente un prefijo / 64 utilizando

29

PD, luego el CPE distribuye al cliente un prefijo / 64 utilizando

RA.

• RA y DHCPv6-PD

El BAS distribuye al uplink del CPE un prefijo /64 utilizando

RA. Luego el BAS distribuye al CPE un prefijo /48 utilizando

DHCPv6-PD, por último el CPE distribuye al cliente un prefijo

/64 utilizando RA .

• Single Shot AAA


Caso Acceso Broadband Fijo xdsl Dual-Stack- Arquitectura

PPPoE -

Arquitectura con sesiones PPPoE Dual Stack , sin DHCP- v6 PD, con Radius

El Server RADIUS requiere soportar RFC3162 (RADIUS attributes and IPv6).

Los pooles de prefijos y sus nombres son aplicables mediante AAA.

Los siguientes atributos RADIUS descriptos en la RFC 3162 estan soportados para IPv6:

Framed-Interface-Id, Framed-IPv6-Prefix, Login-IPv6-Host, Framed-IPv6-Route, Framed-IPv6-

30

Framed-Interface-Id, Framed-IPv6-Prefix, Login-IPv6-Host, Framed-IPv6-Route, Framed-IPv6-

Pool.

Ejemplo Configuracion RADIUS con asignación de prefijo /64 permanente:

Auth-Type = Local, Password = “nnn”

User-Service-Type = Framed-User,

Framed-Protocol = PPP,

cisco-avpair = “ipv6:prefix=2001:DB8:1:1::/64”

Interface Identifier Attribute (Framed-Interface-Id) :

Interface-Id = “0:0:0:1”,


Caso Acceso Broadband Fijo xdsl Dual-Stack - Alternativa

IPoE

Arquitectura alternativa IPoE Dual Stack -modo 1:1

( una vlan por cada cliente)

Comparación IPv6(oE) con VLANs 1:1 vs PPPoE

A nivel 2 , IPv6(oE) con el modelo de VLAN 1:1 tiene semejanzas con la

31

A nivel 2 , IPv6(oE) con el modelo de VLAN 1:1 tiene semejanzas con la

arquitectura PPPoE.

Ambos son conexiones punto a punto. Los dominios de broadcast en

éste tipo de conexiones no requiere complejidad adicional de nivel2

El identificador de linea de cliente es la misma subinterfaz VLAN 1:1

SLAAC y Route Discovery funcionan igual

La diferencia es que el modelo VLAN 1:1 e IPoE v6 en general requieren

funcionalidades adicionales en los BAS, aumentando el costo, respecto

de PPP (ya maduro). Ejemplos : Autenticación DHCP para el modelo

AAA, Neighbor discovery, técnicas de seguridad ,ect)


Arquitectura alternativa IPoE Dual Stack -modo N :1

( N clientes en una misma vlan )

Caso Acceso Broadband Fijo xdsl Dual-Stack - Alternativa

IPoE

•Los usuarios aparentan compartir un mismo dominio de broadcast.

•Se habilita split-horizont para las reglas de forwarding de L2.

el tráfico de usuario a usuario se bloquea a nivel 2.

32

el tráfico de usuario a usuario se bloquea a nivel 2.

todo el tráfico se dirige al BNG, funcionando como una red NBMA.

•Identificación de la linea de cliente

La VLAN no puede ser mapeada a un identificador de linea de cliente.

• trabajos en desarrollo,

routing de IPv6 en redes NBMA, correlacion del ID del cliente desde el cpe

hasta el BAS, (ref: Broadband Forum WT-177 (draft): IPv6 in the Context of TR-101 )


Caso Acceso Broadband Móvil Dual-Stack

Conección PDN Dual Stack y contexto PDP Dual Stack

33

Fuente : Ericsson


Recomendaciones

• Desplegar dual stack en los PE ( “6PE&6VPE”)- Revisar escalabilidad –

Adaptar seguridad.

• Especializar RRs (Ipv4 / IPv6).

• Preveer posibilidad DNS dedicados para IPv6.

• Habilitar dual-stack en todos los peering points ( controlar paths

asimetricos Ipv4/IPv6 y alta latencia).

• Planificar CGN con segmentación por servicio.

34

• Planificar CGN con segmentación por servicio.

• Probar 6RD y dual stack para uso en el acceso masivo.

(Dual stack para móvil, 6RD/Dual Stack para fijo)

• Comenzar la integración de IPv6 a los procesos industriales de

gestion/servicio existentes en IPv4 (confiabilidad).

• Seguir evolución leading cases (comcast6.net IPv6 Information Center,

contenidos en IPv6 *)

http://www.comcast6.net

http://www.networkworld.com/news/2010/020410-ipv6-web-sites.html?page=2


PREGUNTAS ….?

35

Gabriel Castro

[email protected]

Introducción de IPv6 en Telecom Argentina · Introducción de IPv6 en Telecom Argentina 1 Estado...

Documents

Transcript of Introducción de IPv6 en Telecom Argentina · Introducción de IPv6 en Telecom Argentina 1 Estado...