WEBVTT

00:00.090 --> 00:01.050
Instructor: En esta

00:01.050 --> 00:04.200
lección, vamos a introducir los conceptos relacionados con

00:04.200 --> 00:06.600
IPv6, o Protocolo de Internet versión 6.

00:06.600 --> 00:07.740
Hasta ahora sólo

00:07.740 --> 00:10.230
hemos hablado de IPv4, pero uno de

00:10.230 --> 00:13.020
los problemas de IPv4 es que su espacio

00:13.020 --> 00:15.510
de direcciones es limitado.

00:15.510 --> 00:17.370
Esto se debe a que sólo hay 32 bits

00:17.370 --> 00:19.380
que componen una dirección IPv4,

00:19.380 --> 00:23.070
lo que nos da sólo 4. 2.000 millones de combinaciones de direcciones posibles.

00:23.070 --> 00:26.430
Ahora, sé 4. 2 billones suena como un montón de

00:26.430 --> 00:28.950
IPs, pero cuando quitamos porciones enteras de cosas,

00:28.950 --> 00:32.160
para cosas como direcciones APIPA, direcciones de host local, IPs

00:32.160 --> 00:34.770
privadas, y luego hubo una enorme cantidad de desperdicio

00:34.770 --> 00:36.720
antes de que incluso empezáramos a usar

00:36.720 --> 00:38.670
subredes, esto condujo a un gran problema,

00:38.670 --> 00:41.040
y empezamos a quedarnos sin direcciones de red dentro

00:41.040 --> 00:42.810
de IPv4.

00:42.810 --> 00:46.860
Esto se conoce como agotamiento de direcciones, y es algo real.

00:46.860 --> 00:49.260
De hecho, en noviembre de 2019, RIPE

00:49.260 --> 00:51.810
NCC, el Registro Regional de Internet

00:51.810 --> 00:55.020
para Europa, Asia Occidental y la antigua URSS, y

00:55.020 --> 00:56.160
la NASA, ya han agotado

00:56.160 --> 00:59.130
toda su reserva de direcciones IPv4.

00:59.130 --> 01:01.770
Por suerte, el Grupo de Trabajo de

01:01.770 --> 01:04.740
Ingeniería de Internet (IETF) ya había

01:04.740 --> 01:06.600
empezado a mirar hacia el

01:06.600 --> 01:09.690
futuro y desarrolló IPv6 como estándar

01:09.690 --> 01:13.380
en 1995 con un RFC que documentaba su visión de IPv6,

01:13.380 --> 01:17.790
al que denominaron IP Next Generation (IPNG).

01:17.790 --> 01:22.790
Como ves, IPv6 supone una enorme mejora con respecto a IPv4 en cuanto al número

01:22.860 --> 01:25.290
de direcciones disponibles.

01:25.290 --> 01:28.710
En lugar de utilizar una dirección de 32 bits como

01:28.710 --> 01:32.100
en IPv4, IPv6 utilizará una de 128 bits.

01:32.100 --> 01:35.490
Esto te dará un espacio de direcciones mucho mayor.

01:35.490 --> 01:37.620
De hecho, te va a dar una posibilidad

01:37.620 --> 01:41.430
de 340 undecillones de direcciones IP.

01:41.430 --> 01:42.930
Son suficientes direcciones

01:42.930 --> 01:45.930
IP para todos los hombres, mujeres y niños del planeta.

01:45.930 --> 01:48.540
Esto es dos a la 128ª potencia.

01:48.540 --> 01:51.300
De hecho, hay muchísimas direcciones IP para cada

01:51.300 --> 01:53.730
hombre, mujer y niño del planeta porque hay

01:53.730 --> 01:56.250
muchísimas direcciones IP disponibles.

01:56.250 --> 01:57.960
Puede que te preguntes:

01:57.960 --> 02:01.230
"Oye, hemos pasado de IPv4 a IPv6".

02:01.230 --> 02:03.090
¿Qué ha pasado con la versión 5?

02:03.090 --> 02:05.370
¿Por qué pasamos directamente a la versión 6?

02:05.370 --> 02:09.180
Bueno, se creó la versión 5, pero nunca se adoptó plenamente como

02:09.180 --> 02:11.190
protocolo o norma oficial.

02:11.190 --> 02:13.350
Y por lo tanto, nunca entró en producción.

02:13.350 --> 02:14.820
En cambio, muchos de esos conceptos

02:14.820 --> 02:16.350
que se desarrollaron en la versión

02:16.350 --> 02:17.970
5, porque era un protocolo experimental,

02:17.970 --> 02:19.920
se incorporaron a IPv6 cuando se convirtió

02:19.920 --> 02:21.870
en norma oficial.

02:21.870 --> 02:25.650
Hablemos de las ventajas de IPv6.

02:25.650 --> 02:26.910
Una de las mayores ventajas

02:26.910 --> 02:28.890
es que el espacio de direcciones es mucho

02:28.890 --> 02:31.350
mayor gracias a esas direcciones de 128 bits.

02:31.350 --> 02:32.460
Además, IPv6 también

02:32.460 --> 02:35.160
aumentó la eficiencia de nuestras redes al eliminar

02:35.160 --> 02:38.730
el tipo de flujo de datos de difusión de IPv4.

02:38.730 --> 02:41.250
Ahora, IPv6 también es más seguro porque

02:41.250 --> 02:44.010
no hay fragmentación de paquetes o datagramas

02:44.010 --> 02:46.050
dentro del estándar IPv6.

02:46.050 --> 02:48.150
Tampoco hay unidades de transmisión máximas

02:48.150 --> 02:51.330
para el descubrimiento dentro de cada sesión, a diferencia de IPv4,

02:51.330 --> 02:54.870
que contiene una MTU con un tamaño determinado para cada paquete.

02:54.870 --> 02:57.030
En IPv4, si te enviara un paquete que fuera

02:57.030 --> 02:59.820
más grande que el tamaño máximo de tu unidad de transmisión,

02:59.820 --> 03:01.080
lo fragmentaría y lo enviaría

03:01.080 --> 03:02.400
por la red.

03:02.400 --> 03:04.110
Y cuando llegaba a su destino,

03:04.110 --> 03:05.970
se volvía a montar y se leía.

03:05.970 --> 03:07.650
En realidad, se trataba de un riesgo para la seguridad.

03:07.650 --> 03:09.540
También requería un procesamiento adicional

03:09.540 --> 03:11.460
y podía ralentizar las redes, ya que se convertía

03:11.460 --> 03:13.920
en una forma muy ineficiente de hacer las cosas en nuestras

03:13.920 --> 03:15.120
redes modernas con velocidades

03:15.120 --> 03:17.070
de conexión a Internet más altas.

03:17.070 --> 03:19.830
Por eso, con IPv6, decidieron eliminar por

03:19.830 --> 03:21.900
completo la fragmentación.

03:21.900 --> 03:24.480
Ahora bien, además de proporcionar todas estas

03:24.480 --> 03:26.970
nuevas ventajas, los creadores de IPv6 también

03:26.970 --> 03:30.690
fueron muy listos y se dieron cuenta de que para que IPv6 se adoptara

03:30.690 --> 03:33.630
y aceptara plenamente, tendría que ser compatible hacia

03:33.630 --> 03:38.630
atrás con IPv4 y permitir que tanto IPv6 como IPv4 coexistieran en la misma red.

03:38.700 --> 03:41.490
Al fin y al cabo, ya a finales de la década de 1990

03:41.490 --> 03:43.950
se estaba desarrollando y lanzando IPv6 y

03:43.950 --> 03:45.270
ya había montones de redes

03:45.270 --> 03:47.490
informáticas en todo el mundo.

03:47.490 --> 03:48.900
Así que no sería factible

03:48.900 --> 03:51.960
cambiar todo en un solo día.

03:51.960 --> 03:53.490
Piense en ello como en la migración

03:53.490 --> 03:55.170
actual de los vehículos de gasolina

03:55.170 --> 03:56.730
a los eléctricos.

03:56.730 --> 03:58.920
Esto está ocurriendo durante toda la década

03:58.920 --> 04:00.420
de 2020 y hasta la de 2030.

04:00.420 --> 04:02.970
Ahora bien, sería imposible que dijéramos:

04:02.970 --> 04:05.850
oye, el 1 de enero de 2025 nadie podrá volver a utilizar

04:05.850 --> 04:07.710
vehículos de gas.

04:07.710 --> 04:08.700
Todos ellos serán sustituidos

04:08.700 --> 04:11.010
por vehículos eléctricos a partir de esa fecha.

04:11.010 --> 04:12.180
Si un gobierno intentara hacer

04:12.180 --> 04:14.160
eso, probablemente se encontraría con una revolución

04:14.160 --> 04:17.190
en sus manos, porque mucha gente ya tiene coches de gasolina y ha gastado

04:17.190 --> 04:19.890
mucho dinero e invertido en esos coches y en la infraestructura

04:19.890 --> 04:21.900
para mantenerlos.

04:21.900 --> 04:24.480
Por eso, no vamos a sustituir todos los coches

04:24.480 --> 04:26.250
de gas de la noche a la mañana.

04:26.250 --> 04:28.680
En su lugar, va a haber esta lenta transición de la

04:28.680 --> 04:32.130
energía de gas a la eléctrica que se prolongará hasta 2030 o tal vez 2040,

04:32.130 --> 04:34.890
a medida que cada vez más de los coches más nuevos que se

04:34.890 --> 04:37.050
venden en el mundo se vendan como eléctricos

04:37.050 --> 04:39.390
y dejen de vender vehículos de gas.

04:39.390 --> 04:42.900
Pues bien, con IPv6 ocurre exactamente lo mismo.

04:42.900 --> 04:47.010
Así pues, IPv6 permite que tanto IPv4 como IPv6 coexistan en las

04:47.010 --> 04:49.140
mismas redes y los equipos que las

04:49.140 --> 04:51.360
ejecutan pasan a denominarse de pila

04:51.360 --> 04:53.370
dual, lo que significa simplemente

04:53.370 --> 04:54.930
que pueden ejecutar simultáneamente

04:54.930 --> 04:58.200
los protocolos IPv4 e IPv6 en los mismos dispositivos

04:58.200 --> 05:01.080
de red.

05:01.080 --> 05:04.410
Con dispositivos de doble pila, si un cliente soporta IPv6,

05:04.410 --> 05:06.960
el switch del router preferirá usar IPv6 y hablará

05:06.960 --> 05:08.760
bajo ese método.

05:08.760 --> 05:11.370
Ahora, si un dispositivo no es capaz de soportar

05:11.370 --> 05:13.080
IPv6, se da la vuelta y dice, vale,

05:13.080 --> 05:16.380
hablaré contigo usando el antiguo protocolo IPv4.

05:16.380 --> 05:18.390
Así podré seguir apoyándote.

05:18.390 --> 05:20.850
Otro método que utilizamos se conoce como tunelización.

05:20.850 --> 05:24.780
Aquí es donde IPv6 va a ser tunelizado sobre un dispositivo IPv4.

05:24.780 --> 05:27.150
Esto permite que los routers IPv4 más antiguos

05:27.150 --> 05:29.580
sigan transportando tráfico IPv6.

05:29.580 --> 05:31.710
Básicamente, IPv6 se va a tunelizar

05:31.710 --> 05:34.860
como mecanismo para encapsular los paquetes IPv6

05:34.860 --> 05:38.370
en cabeceras IPv4 y transportar estos datos IPv6 a través

05:38.370 --> 05:40.320
de los routers IPv4 y otras infraestructuras

05:40.320 --> 05:42.480
ya existentes.

05:42.480 --> 05:44.640
Para ello, crea un túnel punto a punto entre

05:44.640 --> 05:46.380
el origen y el destino y, a continuación,

05:46.380 --> 05:48.450
encapsula esa información.

05:48.450 --> 05:51.630
Esto permite que los clientes y servidores IPv6 aislados puedan

05:51.630 --> 05:53.310
comunicarse sin necesidad de actualizar

05:53.310 --> 05:55.620
toda la infraestructura de routers y conmutadores

05:55.620 --> 05:59.040
que aún utilizan IPv4 que pueda existir entre ellos.

05:59.040 --> 06:02.880
Puede que algún día veamos cómo IPv4 se retira por completo.

06:02.880 --> 06:05.070
Pero hasta ahora no ha ocurrido.

06:05.070 --> 06:07.440
Y personalmente, no aguanto la respiración.

06:07.440 --> 06:08.670
Según algunos artículos

06:08.670 --> 06:11.160
que he leído, las predicciones apuntan a que

06:11.160 --> 06:14.340
IPv4 seguirá con nosotros al menos hasta 2040, así que vas

06:14.340 --> 06:17.430
a tener que saber trabajar tanto con IPv4 como con IPv6

06:17.430 --> 06:20.640
en el futuro inmediato como técnico de redes.

06:20.640 --> 06:24.120
Otra ventaja de IPv6 es que tiene una cabecera simplificada.

06:24.120 --> 06:26.850
Así, en lugar de los 12 campos de IPv4, en IPv6 sólo

06:26.850 --> 06:29.430
tenemos cinco, lo que hace que la cabecera sea

06:29.430 --> 06:30.960
mucho más eficiente a la hora

06:30.960 --> 06:33.630
de enviarla por nuestras redes.

06:33.630 --> 06:35.370
Quizá se pregunte cómo

06:35.370 --> 06:37.920
es una cabecera IPv6.

06:37.920 --> 06:40.500
Te lo voy a enseñar, pero ten en cuenta que no necesitas

06:40.500 --> 06:42.750
memorizarlo para el examen.

06:42.750 --> 06:44.940
En su lugar, esto es sólo para mostrar los diferentes

06:44.940 --> 06:47.040
campos que estaban en IPv4, que está en la parte superior,

06:47.040 --> 06:49.230
frente a IPv6, que está en la parte inferior.

06:49.230 --> 06:51.240
Y ahora puedes ver lo mucho

06:51.240 --> 06:54.450
más sencillo que es IPv6 sobre IPv4.

06:54.450 --> 06:56.190
Muy bien, volvamos a algunas cosas que

06:56.190 --> 06:58.170
sí necesitas entender para el examen.

06:58.170 --> 07:01.590
¿Cómo es una dirección IPv6?

07:01.590 --> 07:04.590
Bueno, ya he dicho que tiene 128 bits de longitud,

07:04.590 --> 07:08.160
lo que significa que tendría 128 unos o ceros si lo escribiéramos

07:08.160 --> 07:09.600
en binario, y eso me parece

07:09.600 --> 07:13.410
una muy mala idea, así que no vamos a hacerlo.

07:13.410 --> 07:15.210
Podríamos utilizar la notación

07:15.210 --> 07:16.680
decimal con puntos como en

07:16.680 --> 07:19.020
IPv4, pero aún así tendríamos que escribir

07:19.020 --> 07:23.670
muchos octetos porque necesitaríamos 16 octetos para representar los 128 bits.

07:23.670 --> 07:25.380
Para resolver este problema,

07:25.380 --> 07:27.360
el IETF decidió utilizar dígitos

07:27.360 --> 07:29.310
hexadecimales.

07:29.310 --> 07:31.860
Verás, el hexadecimal es base-16, que puede que

07:31.860 --> 07:33.150
recuerdes o no de tus clases

07:33.150 --> 07:34.980
de álgebra en el instituto.

07:34.980 --> 07:36.210
Ahora, en hexadecimal, cada

07:36.210 --> 07:38.760
dígito hexadecimal es en realidad cuatro bits.

07:38.760 --> 07:41.250
Y esto nos va a permitir representar una dirección IPv6

07:41.250 --> 07:43.710
combinando cuatro dígitos hexadecimales juntos para

07:43.710 --> 07:45.780
formar lo que llamamos un segmento.

07:45.780 --> 07:48.720
Ahora, un segmento va a tener 16 bits en él.

07:48.720 --> 07:51.030
Está representado por esos cuatro dígitos hexadecimales.

07:51.030 --> 07:52.440
Y luego vamos a añadir dos puntos

07:52.440 --> 07:53.880
y luego vamos a seguir añadiendo

07:53.880 --> 07:56.250
segmentos hasta llegar a 128 bits, que va a tomar ocho

07:56.250 --> 07:57.900
segmentos, cada uno de los cuales tiene

07:57.900 --> 08:00.510
cuatro dígitos hexadecimales cada uno.

08:00.510 --> 08:03.510
Esto me da un total de 32 dígitos hexadecimales, que

08:03.510 --> 08:05.460
sigue siendo bastante largo.

08:05.460 --> 08:09.330
Ahora, con 128 bits representados en una dirección IPv6, esto significa

08:09.330 --> 08:12.810
que no tendremos más de 32 dígitos hexadecimales dentro de

08:12.810 --> 08:14.700
todos estos segmentos.

08:14.700 --> 08:18.150
Ahora bien, ¿por qué he dicho que no más de 32 dígitos de longitud

08:18.150 --> 08:20.250
para el total de estos ocho segmentos?

08:20.250 --> 08:22.800
¿Por qué no serían simplemente 32 dígitos hexadecimales,

08:22.800 --> 08:25.710
ya que 32 dígitos multiplicados por cuatro bits por

08:25.710 --> 08:28.290
dígito nos darían 128 bits?

08:28.290 --> 08:31.320
Bueno, esto se debe a que IPv6 en realidad nos permite utilizar

08:31.320 --> 08:33.450
una taquigrafía para poder simplificar

08:33.450 --> 08:35.880
nuestras larguísimas direcciones IPv6.

08:35.880 --> 08:37.980
Ahora bien, las reglas de taquigrafía son muy importantes

08:37.980 --> 08:40.650
porque en ellas se pueden encontrar preguntas de examen.

08:40.650 --> 08:43.020
Así que si tienes cuatro ceros para un segmento,

08:43.020 --> 08:45.360
puedes poner un cero en su lugar y eliminar

08:45.360 --> 08:47.310
los ceros a la izquierda.

08:47.310 --> 08:50.790
Por ejemplo, supongamos que tengo una dirección IPv6

08:50.790 --> 08:55.790
realmente larga de 2018:0000:0000:0000:0000:0000:4815:54ae.

09:04.470 --> 09:05.820
Utilizando la regla simple,

09:05.820 --> 09:08.490
puedo sustituir todos los segmentos que tienen varios

09:08.490 --> 09:09.810
ceros por un solo cero.

09:09.810 --> 09:14.810
Esto me daría 2018:0:0:0:0:0:4815:54ae.

09:19.590 --> 09:22.680
Muy bien, esto redujo mi número de dígitos hexadecimales

09:22.680 --> 09:26.790
de 32 a sólo 17, por lo que es aproximadamente la mitad de la longitud.

09:26.790 --> 09:29.520
Estamos mejorando, pero no voy a detenerme ahí.

09:29.520 --> 09:30.710
Hay otra regla que puedo

09:30.710 --> 09:33.000
utilizar en el mundo de la taquigrafía IPv6.

09:33.000 --> 09:35.280
Esta regla dice que si hay múltiples segmentos

09:35.280 --> 09:36.840
que tienen todos ceros en ellos

09:36.840 --> 09:39.420
y no hay otros dígitos hexadecimales representados

09:39.420 --> 09:42.150
allí, puedo resumir eso usando dos puntos dobles y

09:42.150 --> 09:44.160
sacar todos esos ceros.

09:44.160 --> 09:45.420
Ahora bien, esta regla es

09:45.420 --> 09:48.540
especial porque sólo se puede hacer lo de los dos puntos dobles

09:48.540 --> 09:50.460
una vez dentro de una dirección IPv6.

09:50.460 --> 09:52.530
Así que utilizando mi regla de los

09:52.530 --> 09:57.530
dos puntos dobles, puedo resumir 2018:0:0:0:0:0:4815:54ae en eliminar todos

10:00.750 --> 10:03.270
esos cinco conjuntos de ceros y sustituirlos

10:03.270 --> 10:04.950
por dos puntos dobles y obtener

10:04.950 --> 10:07.450
2018::4815::54ae.

10:10.290 --> 10:13.020
Así que pasé de 32 dígitos hexadecimales

10:13.020 --> 10:14.910
a 17 dígitos hexadecimales

10:14.910 --> 10:17.160
y ahora he bajado de 17 dígitos a 12

10:17.160 --> 10:19.080
dígitos, mucho más pequeño,

10:19.080 --> 10:21.690
mucho más fácil de trabajar.

10:21.690 --> 10:24.240
Ya ves lo útil que resulta esta taquigrafía.

10:24.240 --> 10:27.150
¿Cómo se reconoce una dirección IPv6

10:27.150 --> 10:28.950
frente a una IPv4?

10:28.950 --> 10:32.130
Bueno, la primera forma es mirando lo que es IPv4.

10:32.130 --> 10:35.400
IPv4 siempre va a utilizar la notación decimal con puntos utilizando

10:35.400 --> 10:36.990
cuatro octetos.

10:36.990 --> 10:38.490
Ahora, IPv6, por otro lado, va

10:38.490 --> 10:40.530
a utilizar dos puntos entre sus números

10:40.530 --> 10:42.450
y va a ser escrito en hexadecimal.

10:42.450 --> 10:44.280
Muy bien, ahora, una de las preguntas

10:44.280 --> 10:45.810
que podrías ver el día del examen

10:45.810 --> 10:49.080
es identificar una dirección IPv6 cuando veas una.

10:49.080 --> 10:51.180
Por ejemplo, te pueden hacer una pregunta del

10:51.180 --> 10:53.700
tipo ¿cuál de las siguientes es una dirección IPv6?

10:53.700 --> 10:55.410
Esta será una pregunta justa que hacerle.

10:55.410 --> 10:59.280
Tendrás algunas opciones como 192. 168. 1. 1, que sabemos que

10:59.280 --> 11:01.830
no es porque es una dirección IPv4.

11:01.830 --> 11:06.830
Obtendrás 12:34:56:78:90:AB

11:07.590 --> 11:12.000
o 1234::5678::90AB.

11:12.000 --> 11:15.120
Un momento, los dos últimos que acabo de decir

11:15.120 --> 11:17.010
son muy parecidos, ¿no?

11:17.010 --> 11:20.310
Sí, pero sólo una de ellas es una dirección IPv6 válida.

11:20.310 --> 11:21.630
¿Sabes cuál es?

11:21.630 --> 11:24.000
Porque la mayoría de los estudiantes se confunden aquí.

11:24.000 --> 11:28.020
La segunda opción no es una dirección IPv6.

11:28.020 --> 11:29.820
En su lugar, es una dirección MAC.

11:29.820 --> 11:31.260
Recuerda, las direcciones MAC,

11:31.260 --> 11:33.060
que son direcciones físicas de Capa

11:33.060 --> 11:35.580
2, siempre van a tener 12 dígitos hexadecimales y

11:35.580 --> 11:37.230
separados por dos puntos.

11:37.230 --> 11:38.370
Normalmente, se escriben

11:38.370 --> 11:40.410
en seis grupos de dos dígitos cada

11:40.410 --> 11:43.200
uno, separados por dos puntos.

11:43.200 --> 11:46.080
Una dirección IPv6, por otro lado, siempre debe escribirse

11:46.080 --> 11:48.120
en segmentos de cuatro dígitos cada uno,

11:48.120 --> 11:50.580
y siempre deben tener 16 segmentos a menos que

11:50.580 --> 11:52.500
veas dos puntos dobles.

11:52.500 --> 11:55.080
En este ejemplo, tenemos dos puntos dobles entre el

11:55.080 --> 11:58.020
primer y el segundo segmento de nuestra tercera opción.

11:58.020 --> 12:00.840
Así que esta es una buena abreviatura que podemos usar

12:00.840 --> 12:03.450
e identificamos que era una dirección IPv6 porque

12:03.450 --> 12:05.130
quitamos todos los ceros entre

12:05.130 --> 12:08.520
el primer y segundo segmento dentro de esta dirección.

12:08.520 --> 12:09.960
Así que si cuentas algo que

12:09.960 --> 12:11.790
parece una dirección IPv6, y tiene

12:11.790 --> 12:15.480
12, exactamente 12 dígitos hexadecimales separados por dos puntos

12:15.480 --> 12:17.040
simples, y no ves dos puntos

12:17.040 --> 12:18.840
dobles en ninguna parte, eso es

12:18.840 --> 12:22.140
una dirección MAC, no una dirección IPv6.

12:22.140 --> 12:24.180
De lo contrario, si se parece a esto

12:24.180 --> 12:25.860
e incluye dígitos hexadecimales,

12:25.860 --> 12:29.190
el día del examen será una dirección IPv6.

12:29.190 --> 12:31.440
Para el examen, sólo tienes que ser capaz

12:31.440 --> 12:33.540
de reconocer cómo es una dirección IPv6,

12:33.540 --> 12:35.790
y deberías ser capaz de resumir una quitando

12:35.790 --> 12:38.070
ceros y consolidándolos usando ese truco

12:38.070 --> 12:39.960
de los dos puntos dobles.

12:39.960 --> 12:41.490
Si puedes hacer estas dos cosas,

12:41.490 --> 12:45.000
estarás bien para el direccionamiento IPv6 el día del examen.

12:45.000 --> 12:47.280
Ahora, cuando se trata de direccionamiento IPv6,

12:47.280 --> 12:50.100
hay tres tipos diferentes de direcciones que puedes utilizar:

12:50.100 --> 12:52.220
direcciones unicast, direcciones multicast

12:52.220 --> 12:54.210
y direcciones anycast.

12:54.210 --> 12:56.640
Una de las cosas interesantes de IPv6 que

12:56.640 --> 12:59.040
realmente lo distingue de IPv4 es que podemos

12:59.040 --> 13:01.830
asignar múltiples direcciones IPv6 a una única

13:01.830 --> 13:03.900
interfaz en un cliente.

13:03.900 --> 13:05.730
Y estas asignaciones pueden ser una

13:05.730 --> 13:07.680
mezcla de cualquiera de estos tres tipos

13:07.680 --> 13:10.290
diferentes: unicast, multicast y anycast.

13:10.290 --> 13:13.140
Así, aunque sólo tengas una tarjeta de interfaz de

13:13.140 --> 13:14.910
red en tu estación de trabajo o

13:14.910 --> 13:17.430
portátil, podrías tener varias direcciones

13:17.430 --> 13:19.860
IPv6 y distintos tipos de direcciones IPv6

13:19.860 --> 13:22.140
asignadas a esa única tarjeta.

13:22.140 --> 13:23.850
Las direcciones unicast se van a utilizar

13:23.850 --> 13:25.950
para identificar una única interfaz.

13:25.950 --> 13:28.950
Se dividen en direcciones unicast de enrutamiento global

13:28.950 --> 13:30.930
y direcciones link-local.

13:30.930 --> 13:32.760
Una dirección unicast enrutada globalmente

13:32.760 --> 13:36.150
es similar a lo que tenemos como dirección pública con IPv4 utilizando

13:36.150 --> 13:39.600
direcciones unicast de clase A, B y C.

13:39.600 --> 13:42.840
Ahora, en IPv6, una dirección unicast enrutada

13:42.840 --> 13:44.220
globalmente siempre

13:44.220 --> 13:49.050
va a empezar con su primer segmento conteniendo 2000-3999.

13:49.050 --> 13:52.740
Si ves 2000-3999 como primer segmento, significa que es una

13:52.740 --> 13:55.770
dirección unicast de enrutamiento global.

13:55.770 --> 13:58.050
Por ejemplo, la dirección

13:58.050 --> 14:03.050
IPv6 2584:0db8:8583:1234:5678:882e:0370:7334 se enrutaría

14:10.800 --> 14:14.010
globalmente como dirección unicast

14:14.010 --> 14:17.070
porque su primer segmento contiene

14:17.070 --> 14:20.670
2584, que está entre 2000 y 3999.

14:20.670 --> 14:22.650
En cambio, una dirección link-local,

14:22.650 --> 14:24.690
también llamada dirección de uso local,

14:24.690 --> 14:28.020
se utiliza como una dirección IP privada en IPv4.

14:28.020 --> 14:29.970
Una dirección link-local en IPv6

14:29.970 --> 14:32.097
sólo se puede utilizar en una red

14:32.097 --> 14:36.840
de área local y siempre va a comenzar con FE80 como su primer segmento dentro

14:36.840 --> 14:38.940
de una dirección IPv6.

14:38.940 --> 14:41.760
Ahora, cada vez que un sistema IPv6 arranca, va a crear

14:41.760 --> 14:44.100
una dirección link-local para cada interfaz

14:44.100 --> 14:47.070
IPv6 en ese sistema, incluso si una dirección globalmente

14:47.070 --> 14:48.720
enrutable ya fue configurada

14:48.720 --> 14:50.190
manualmente u obtenida a través

14:50.190 --> 14:53.700
de un protocolo de configuración como DHCP.

14:53.700 --> 14:56.340
Para ello, va a utilizar algo conocido como

14:56.340 --> 15:00.840
SLAAC, la autoconfiguración de direcciones sin estado o S-L-A-A-C.

15:00.840 --> 15:02.610
Con la autoconfiguración sin estado,

15:02.610 --> 15:04.680
el host no necesita obtener direcciones

15:04.680 --> 15:06.210
u otra información de configuración

15:06.210 --> 15:08.880
de un servidor centralizado como DHCP.

15:08.880 --> 15:11.640
En su lugar, puede asignarse a sí mismo de forma independiente

15:11.640 --> 15:13.050
una dirección link-local, comprobar

15:13.050 --> 15:15.420
la unicidad de esa dirección link-local, asignarse

15:15.420 --> 15:17.430
a sí mismo la dirección link-local, contactar

15:17.430 --> 15:20.220
con el router y proporcionar instrucciones al nodo sobre cómo

15:20.220 --> 15:22.680
proceder con la autoconfiguración.

15:22.680 --> 15:25.770
E incluso puede configurar la dirección unicast global

15:25.770 --> 15:27.090
que desea utilizar.

15:27.090 --> 15:29.520
Volveremos sobre este concepto dentro de unos minutos

15:29.520 --> 15:31.110
cuando profundicemos un poco más

15:31.110 --> 15:34.080
en él al empezar a hablar de EUI-64 y el protocolo de descubrimiento

15:34.080 --> 15:35.580
de vecinos, ya que ambos procesos

15:35.580 --> 15:37.650
se utilizan con el protocolo de autoconfiguración

15:37.650 --> 15:41.580
de direcciones sin estado conocido como SLAAC.

15:41.580 --> 15:43.680
A continuación, tenemos las direcciones multidifusión.

15:43.680 --> 15:45.360
Ahora, las direcciones de multidifusión se

15:45.360 --> 15:47.100
utilizan para identificar un grupo de interfaces,

15:47.100 --> 15:49.710
de modo que un paquete pueda enviarse a una dirección de multidifusión

15:49.710 --> 15:52.680
y, a continuación, entregarse a todas las interfaces de un grupo.

15:52.680 --> 15:56.550
En IPv6, una dirección multicast siempre contendrá FF como los dos

15:56.550 --> 15:59.460
primeros dígitos dentro del primer segmento.

15:59.460 --> 16:02.280
Si ve FF al principio de una dirección IPv6,

16:02.280 --> 16:04.800
recuerde que es multicast.

16:04.800 --> 16:06.330
El último tipo de dirección que

16:06.330 --> 16:08.700
tenemos se conoce como dirección anycast.

16:08.700 --> 16:11.610
Las direcciones Anycast se utilizan para identificar un conjunto de interfaces

16:11.610 --> 16:14.400
de modo que un paquete pueda enviarse a cualquier miembro de un conjunto.

16:14.400 --> 16:16.320
En realidad, las direcciones Anycast se asignan

16:16.320 --> 16:18.060
desde el espacio de direcciones Unicast.

16:18.060 --> 16:19.620
Así que realmente no hay manera

16:19.620 --> 16:22.710
de determinar si una dirección IPv6 es unicast o anycast

16:22.710 --> 16:25.410
sólo mirando la dirección IPv6.

16:25.410 --> 16:28.050
Cuando se trata de multidifusión o enlace

16:28.050 --> 16:29.790
local, es muy fácil hacerlo,

16:29.790 --> 16:31.440
pero no es fácil distinguir

16:31.440 --> 16:33.870
entre unidifusión y anycast.

16:33.870 --> 16:35.010
Muy bien, volvamos atrás

16:35.010 --> 16:36.990
y hablemos un poco más sobre SLAAC, el proceso

16:36.990 --> 16:40.140
de autoconfiguración de direcciones sin estado.

16:40.140 --> 16:42.090
Ahora, como he dicho, en IPv6, hay un

16:42.090 --> 16:45.120
proceso de auto-configuración conocido como SLAAC, y

16:45.120 --> 16:46.980
lo utilizamos para descubrir la red

16:46.980 --> 16:48.570
actual en la que se encuentra la

16:48.570 --> 16:51.360
interfaz y luego le permitimos seleccionar su propio

16:51.360 --> 16:56.360
ID de host basado en su dirección MAC utilizando un proceso conocido como EUI-64.

16:56.550 --> 17:01.410
Ahora, este proceso EUI-64 o Identificador Único Ampliado permitirá a un

17:01.410 --> 17:03.450
host asignarse a sí mismo un identificador

17:03.450 --> 17:07.967
de interfaz IPv6 único de 64 bits denominado EUI-64.

17:09.180 --> 17:12.000
Ahora, esta dirección en formato EUI-64 se obtiene

17:12.000 --> 17:15.480
utilizando la dirección MAC de 48 bits de la interfaz.

17:15.480 --> 17:19.260
La dirección MAC se separa primero en dos partes de 24 bits.

17:19.260 --> 17:22.890
La primera mitad de la dirección MAC contendrá el OUI (Organizational

17:22.890 --> 17:25.170
Unique Identifier).

17:25.170 --> 17:26.850
Y la segunda mitad va a contener la

17:26.850 --> 17:29.010
tarjeta de interfaz de red específica.

17:29.010 --> 17:30.780
Ahora, entre ellos,

17:30.780 --> 17:35.730
vamos a meter un valor hexadecimal de 16 bits de FFFE.

17:35.730 --> 17:39.990
De esta forma, puedo tomar 24 bits, 16 bits y 24 bits

17:39.990 --> 17:44.760
y juntarlos para obtener una dirección EUI de 64 bits.

17:44.760 --> 17:47.340
Ahora, esto te da los 64 bits que vas a necesitar

17:47.340 --> 17:49.860
para identificar tu interfaz en esa red.

17:49.860 --> 17:52.320
A continuación, la interfaz utilizará la detección

17:52.320 --> 17:53.910
automática para determinar la

17:53.910 --> 17:57.030
red en la que se encuentra y añadir la parte de red de la dirección

17:57.030 --> 18:00.960
IPv6, que serán los primeros 64 bits de nuestras direcciones.

18:00.960 --> 18:02.940
Ahora, vamos a poner los primeros 64

18:02.940 --> 18:05.580
bits para representar la red delante de los 64 bits

18:05.580 --> 18:09.390
de la dirección EUI-64 que creamos a partir de nuestra dirección MAC para

18:09.390 --> 18:13.050
crear una dirección IPv6 unicast globalmente enrutable que ahora

18:13.050 --> 18:14.550
podemos utilizar.

18:14.550 --> 18:16.890
Así que puedes ver como todo esto funciona junto

18:16.890 --> 18:18.180
usando esa dirección MAC para

18:18.180 --> 18:20.700
crear esta dirección globalmente enrutable.

18:20.700 --> 18:24.180
Ahora, DHCP también se puede utilizar dentro de IPv6

18:24.180 --> 18:25.560
si prefiere usarlo.

18:25.560 --> 18:29.520
Si lo haces, tendrás que utilizar el protocolo DHCPv6.

18:29.520 --> 18:30.930
Esto le permitiría tener

18:30.930 --> 18:34.650
DHCP asignar automáticamente las cosas de un servidor DHCPv6.

18:34.650 --> 18:38.520
Pero como el proceso de autoconfiguración con EUI-64 ya está integrado

18:38.520 --> 18:41.430
por defecto en el protocolo IPv6, no es necesario

18:41.430 --> 18:43.230
utilizar DHCPv6.

18:44.280 --> 18:47.580
Pero si quieres usar DHCPv6, puedes hacerlo, y te permitirá

18:47.580 --> 18:48.870
asignar qué direcciones

18:48.870 --> 18:51.360
va a obtener cada interfaz en lugar de permitirles

18:51.360 --> 18:52.500
usar el protocolo de

18:52.500 --> 18:55.170
autoconfiguración de SLAAC.

18:55.170 --> 18:58.560
Ahora, como he dicho, IPv6 elegirá su propia dirección basada

18:58.560 --> 19:00.930
en su dirección MAC por defecto, entonces va

19:00.930 --> 19:03.480
a utilizar esta cosa conocida como NDP o el protocolo

19:03.480 --> 19:05.310
de descubrimiento de vecinos para

19:05.310 --> 19:08.370
aprender acerca de las otras direcciones de capa 2 en la red

19:08.370 --> 19:09.990
basada en sus direcciones MAC

19:09.990 --> 19:12.630
y luego elegirá su propio ID de host.

19:12.630 --> 19:15.630
Ahora, para el examen, no necesitas conocer NDP en profundidad,

19:15.630 --> 19:17.850
pero deberías entender que NDP, este protocolo

19:17.850 --> 19:20.847
de descubrimiento de vecinos, se usa en IPv6 y toma muchas de

19:20.847 --> 19:22.410
las funciones del anuncio de router

19:22.410 --> 19:24.420
y el descubrimiento de vecinos y las maneja

19:24.420 --> 19:25.683
por ti.
