WEBVTT

00:00.090 --> 00:01.050
Instrutor: Nesta

00:01.050 --> 00:04.200
lição, apresentaremos os conceitos relacionados ao IPv6,

00:04.200 --> 00:06.600
ou Protocolo de Internet versão 6.

00:06.600 --> 00:07.740
Até este ponto, falamos

00:07.740 --> 00:10.230
apenas sobre o IPv4, mas um dos problemas

00:10.230 --> 00:13.020
que temos com o IPv4 é que ele é limitado em

00:13.020 --> 00:15.510
seu espaço de endereço.

00:15.510 --> 00:17.370
Isso ocorre porque há apenas

00:17.370 --> 00:19.380
32 bits que compõem um endereço

00:19.380 --> 00:23.070
IPv4, o que nos dá apenas 4. 2 bilhões de combinações possíveis de endereços.

00:23.070 --> 00:26.430
Agora, eu sei 4. 2 bilhões parece uma grande quantidade

00:26.430 --> 00:28.950
de IPs, mas quando retiramos partes inteiras de coisas,

00:28.950 --> 00:32.160
como endereços APIPA, endereços de host local, IPs privados,

00:32.160 --> 00:34.770
e depois houve uma enorme quantidade de desperdício

00:34.770 --> 00:36.720
antes mesmo de começarmos a usar a sub-rede,

00:36.720 --> 00:38.670
isso levou a um grande problema, e começamos

00:38.670 --> 00:42.810
a ficar sem endereços de rede dentro do IPv4.

00:42.810 --> 00:46.860
Isso é conhecido como exaustão de endereço, e é algo real.

00:46.860 --> 00:49.260
Na verdade, em novembro de 2019, o RIPE

00:49.260 --> 00:51.810
NCC, o Registro Regional da Internet

00:51.810 --> 00:55.020
para a Europa, Ásia Ocidental e a antiga URSS, e

00:55.020 --> 00:56.160
a NASA já esgotaram

00:56.160 --> 00:59.130
todo o seu pool de endereços IPv4.

00:59.130 --> 01:01.770
Felizmente, porém, a Internet Engineering

01:01.770 --> 01:04.740
Task Force, ou IETF, já havia começado a

01:04.740 --> 01:06.600
olhar para o futuro e desenvolveu

01:06.600 --> 01:09.690
o IPv6 como um padrão em 1995, com uma RFC que

01:09.690 --> 01:13.380
documentava sua visão para o IPv6, que eles chamaram

01:13.380 --> 01:17.790
de IP Next Generation ou IPNG.

01:17.790 --> 01:22.790
Como você pode ver, o IPv6 é, na verdade, um grande avanço em relação ao IPv4 em termos

01:22.860 --> 01:25.290
do número de endereços disponíveis.

01:25.290 --> 01:28.710
Em vez de usar um endereço de 32 bits, como fazemos

01:28.710 --> 01:32.100
no IPv4, o IPv6 usará um endereço de 128 bits.

01:32.100 --> 01:35.490
Isso lhe dará um espaço de endereço muito maior.

01:35.490 --> 01:37.620
Na verdade, ele lhe dará uma possibilidade

01:37.620 --> 01:41.430
de 340 undecilhões de endereços IP.

01:41.430 --> 01:42.930
Isso representa endereços IP

01:42.930 --> 01:45.930
suficientes para cada homem, mulher e criança do planeta.

01:45.930 --> 01:48.540
Isso é dois elevado à 128ª potência.

01:48.540 --> 01:51.300
De fato, há muitos, muitos endereços IP para cada

01:51.300 --> 01:53.730
homem, mulher e criança no planeta, porque

01:53.730 --> 01:56.250
há muitos endereços IP disponíveis.

01:56.250 --> 01:57.960
Agora, você deve estar se

01:57.960 --> 02:01.230
perguntando: ei, passamos do IPv4 para o IPv6.

02:01.230 --> 02:03.090
O que aconteceu com a versão 5?

02:03.090 --> 02:05.370
Por que passamos direto para a versão 6?

02:05.370 --> 02:09.180
Bem, a versão 5 foi criada, mas nunca foi totalmente adotada como

02:09.180 --> 02:11.190
um protocolo ou padrão oficial.

02:11.190 --> 02:13.350
Portanto, ele nunca entrou em produção.

02:13.350 --> 02:14.820
Em vez disso, muitos desses conceitos

02:14.820 --> 02:16.350
que foram desenvolvidos na versão

02:16.350 --> 02:17.970
5, por se tratar de um protocolo experimental,

02:17.970 --> 02:19.920
foram trazidos para o IPv6 quando ele se tornou

02:19.920 --> 02:21.870
um padrão oficial.

02:21.870 --> 02:25.650
Então, vamos falar sobre os benefícios do IPv6.

02:25.650 --> 02:26.910
Um dos maiores benefícios

02:26.910 --> 02:28.890
é o espaço de endereço muito maior devido

02:28.890 --> 02:31.350
a esses endereços de 128 bits.

02:31.350 --> 02:32.460
Além disso, o IPv6 também

02:32.460 --> 02:35.160
aumentou a eficiência de nossas redes ao remover

02:35.160 --> 02:38.730
o tipo de fluxo de dados de transmissão do IPv4.

02:38.730 --> 02:41.250
Agora, o IPv6 também é mais seguro porque

02:41.250 --> 02:44.010
não há fragmentação de pacotes ou datagramas

02:44.010 --> 02:46.050
no padrão IPv6.

02:46.050 --> 02:48.150
Também não há unidades máximas de transmissão

02:48.150 --> 02:51.330
para descoberta em cada sessão, ao contrário do IPv4, que contém

02:51.330 --> 02:54.870
um MTU com um determinado tamanho para cada pacote.

02:54.870 --> 02:57.030
No IPv4, se eu lhe enviasse um pacote maior

02:57.030 --> 02:59.820
que o tamanho máximo da unidade de transmissão, ele

02:59.820 --> 03:01.080
o fragmentaria e o enviaria

03:01.080 --> 03:02.400
pela rede.

03:02.400 --> 03:04.110
E, quando chegasse ao seu destino,

03:04.110 --> 03:05.970
seria remontado e lido.

03:05.970 --> 03:07.650
Isso era de fato um risco à segurança.

03:07.650 --> 03:09.540
Isso também exigia processamento extra e poderia,

03:09.540 --> 03:11.460
na verdade, tornar suas redes mais lentas, pois

03:11.460 --> 03:13.920
se tornou uma maneira muito ineficiente de fazer as coisas em

03:13.920 --> 03:15.120
nossas redes modernas com velocidades

03:15.120 --> 03:17.070
de conexão à Internet mais altas.

03:17.070 --> 03:19.830
Portanto, com o IPv6, eles decidiram acabar completamente

03:19.830 --> 03:21.900
com a fragmentação.

03:21.900 --> 03:24.480
Agora, além de oferecer todos esses novos benefícios,

03:24.480 --> 03:26.970
os criadores do IPv6 também foram muito inteligentes

03:26.970 --> 03:30.690
e perceberam que, para ser adotado e aceito totalmente, o IPv6

03:30.690 --> 03:33.630
teria que ser compatível com o IPv4 e permitir que

03:33.630 --> 03:38.630
tanto o IPv6 quanto o IPv4 coexistissem na mesma rede.

03:38.700 --> 03:41.490
Afinal, já era final da década de 1990 quando o IPv6

03:41.490 --> 03:43.950
estava sendo desenvolvido e lançado, e muitas

03:43.950 --> 03:45.270
redes de computadores já

03:45.270 --> 03:47.490
estavam instaladas em todo o mundo.

03:47.490 --> 03:48.900
Portanto, não seria viável

03:48.900 --> 03:51.960
para nós simplesmente mudar tudo em um único dia.

03:51.960 --> 03:53.490
Pense nisso como a migração atual que estamos

03:53.490 --> 03:55.170
fazendo de veículos movidos a gasolina para

03:55.170 --> 03:56.730
veículos movidos a eletricidade.

03:56.730 --> 03:58.920
Isso está acontecendo durante toda a

03:58.920 --> 04:00.420
década de 2020 e até 2030.

04:00.420 --> 04:02.970
Agora, seria impossível dizer: "ei, todo mundo,

04:02.970 --> 04:05.850
em 1º de janeiro de 2025, ninguém mais poderá usar veículos

04:05.850 --> 04:07.710
movidos a gasolina".

04:07.710 --> 04:08.700
Todos eles serão substituídos

04:08.700 --> 04:11.010
por veículos elétricos a partir dessa data.

04:11.010 --> 04:12.180
Se um governo tentasse fazer

04:12.180 --> 04:14.160
isso, provavelmente teria uma revolução em

04:14.160 --> 04:17.190
suas mãos, porque muitas pessoas já possuem carros movidos a gasolina

04:17.190 --> 04:19.890
e gastaram muito dinheiro e investiram nesses carros e na infraestrutura

04:19.890 --> 04:21.900
para apoiá-los.

04:21.900 --> 04:24.480
Agora, por esse motivo, não vamos simplesmente substituir todos os

04:24.480 --> 04:26.250
carros movidos a gasolina da noite para o dia.

04:26.250 --> 04:28.680
Em vez disso, haverá uma transição lenta

04:28.680 --> 04:32.130
da energia a gás para a elétrica até 2030 ou talvez 2040, pois

04:32.130 --> 04:34.890
cada vez mais carros novos vendidos no mundo serão

04:34.890 --> 04:37.050
vendidos como elétricos e deixarão

04:37.050 --> 04:39.390
de ser vendidos veículos a gás.

04:39.390 --> 04:42.900
Bem, exatamente a mesma coisa está acontecendo com o IPv6.

04:42.900 --> 04:47.010
Portanto, o IPv6 permite que tanto o IPv4 quanto o IPv6 coexistam nas

04:47.010 --> 04:49.140
mesmas redes, e o equipamento que executa

04:49.140 --> 04:51.360
essas redes passa a ser conhecido como

04:51.360 --> 04:53.370
pilha dupla, o que significa simplesmente

04:53.370 --> 04:54.930
que eles podem executar simultaneamente

04:54.930 --> 04:58.200
os protocolos IPv4 e IPv6 nos mesmos dispositivos de

04:58.200 --> 05:01.080
rede.

05:01.080 --> 05:04.410
Com dispositivos de pilha dupla, se um cliente for compatível com

05:04.410 --> 05:06.960
o IPv6, o switch do roteador preferirá usar o IPv6

05:06.960 --> 05:08.760
e conversará com esse método.

05:08.760 --> 05:11.370
Agora, se um dispositivo não for compatível com o IPv6,

05:11.370 --> 05:13.080
ele volta atrás e diz: "Tudo bem,

05:13.080 --> 05:16.380
vou falar com você usando o protocolo IPv4 mais antigo".

05:16.380 --> 05:18.390
Dessa forma, ainda posso apoiá-lo.

05:18.390 --> 05:20.850
Outro método que usamos é conhecido como tunelamento.

05:20.850 --> 05:24.780
É aqui que o IPv6 será encapsulado em um dispositivo IPv4.

05:24.780 --> 05:27.150
Isso permite que seus roteadores IPv4 mais

05:27.150 --> 05:29.580
antigos ainda transportem tráfego IPv6.

05:29.580 --> 05:31.710
Essencialmente, o IPv6 será encapsulado

05:31.710 --> 05:34.860
como um mecanismo para encapsular os pacotes IPv6 em

05:34.860 --> 05:38.370
cabeçalhos IPv4 e transportar esses dados IPv6 pelos roteadores

05:38.370 --> 05:40.320
IPv4 e outras infraestruturas já

05:40.320 --> 05:42.480
existentes.

05:42.480 --> 05:44.640
Ele faz isso criando um túnel ponto a ponto entre

05:44.640 --> 05:46.380
a origem e o destino e, em seguida, encapsulando

05:46.380 --> 05:48.450
essas informações.

05:48.450 --> 05:51.630
Isso permite que clientes e servidores IPv6 isolados possam se

05:51.630 --> 05:53.310
comunicar sem a necessidade de atualizar

05:53.310 --> 05:55.620
todos os roteadores e a infraestrutura de switches

05:55.620 --> 05:59.040
que ainda usam IPv4 que possam existir entre eles.

05:59.040 --> 06:02.880
Agora, um dia, poderemos ver o IPv4 totalmente aposentado.

06:02.880 --> 06:05.070
Mas, até o momento, isso não aconteceu.

06:05.070 --> 06:07.440
E, pessoalmente, não estou prendendo a respiração.

06:07.440 --> 06:08.670
De acordo com alguns

06:08.670 --> 06:11.160
artigos que li, as previsões são de que o

06:11.160 --> 06:14.340
IPv4 permanecerá conosco até pelo menos 2040, portanto,

06:14.340 --> 06:17.430
você terá que saber como trabalhar com IPv4 e IPv6

06:17.430 --> 06:20.640
em um futuro próximo como técnico de rede.

06:20.640 --> 06:24.120
Outro benefício do IPv6 é que ele tem um cabeçalho simplificado.

06:24.120 --> 06:26.850
Portanto, em vez dos 12 campos que tínhamos no IPv4,

06:26.850 --> 06:29.430
temos apenas cinco campos no IPv6, o que torna o

06:29.430 --> 06:30.960
cabeçalho mais fino e muito

06:30.960 --> 06:33.630
mais eficiente para o envio em nossas redes.

06:33.630 --> 06:35.370
Então, você deve estar se perguntando:

06:35.370 --> 06:37.920
como é um cabeçalho IPv6?

06:37.920 --> 06:40.500
Bem, vou mostrar a você, mas saiba que não é necessário

06:40.500 --> 06:42.750
memorizar isso para o exame.

06:42.750 --> 06:44.940
Em vez disso, isso serve apenas para mostrar a você

06:44.940 --> 06:47.040
os diferentes campos do IPv4, que está na parte superior,

06:47.040 --> 06:49.230
e do IPv6, que está na parte inferior.

06:49.230 --> 06:51.240
E agora você pode ver como o IPv6

06:51.240 --> 06:54.450
é realmente muito mais simples do que o IPv4.

06:54.450 --> 06:56.190
Muito bem, vamos voltar a alguns aspectos

06:56.190 --> 06:58.170
que você precisa entender para o exame.

06:58.170 --> 07:01.590
Por exemplo, qual é a aparência real de um endereço IPv6?

07:01.590 --> 07:04.590
Bem, eu já disse que ele tem 128 bits de comprimento,

07:04.590 --> 07:08.160
o que significa que ele teria 128 uns ou zeros se o escrevêssemos

07:08.160 --> 07:09.600
em binário, o que me parece

07:09.600 --> 07:11.910
uma péssima ideia, portanto, não vamos

07:11.910 --> 07:13.410
fazer isso.

07:13.410 --> 07:15.210
Agora, poderíamos usar a notação decimal

07:15.210 --> 07:16.680
pontilhada, como fizemos no

07:16.680 --> 07:19.020
IPv4, mas ainda assim seriam muitos octetos para

07:19.020 --> 07:23.670
escrever, pois precisaríamos de 16 octetos para representar todos os 128 bits.

07:23.670 --> 07:25.380
Portanto, para resolver esse problema,

07:25.380 --> 07:27.360
a IETF decidiu que deveríamos usar dígitos

07:27.360 --> 07:29.310
hexadecimais.

07:29.310 --> 07:31.860
Veja bem, hexadecimal é a base 16, que você pode

07:31.860 --> 07:33.150
ou não lembrar das aulas

07:33.150 --> 07:34.980
de álgebra do ensino médio.

07:34.980 --> 07:36.210
Agora, em hexadecimal, cada

07:36.210 --> 07:38.760
dígito hexadecimal é, na verdade, quatro bits.

07:38.760 --> 07:41.250
E isso nos permitirá representar um endereço IPv6

07:41.250 --> 07:43.710
combinando quatro dígitos hexadecimais para

07:43.710 --> 07:45.780
formar o que chamamos de segmento.

07:45.780 --> 07:48.720
Agora, um segmento terá 16 bits.

07:48.720 --> 07:51.030
Isso é representado por esses quatro dígitos hexadecimais.

07:51.030 --> 07:52.440
Em seguida, adicionaremos

07:52.440 --> 07:53.880
dois pontos e continuaremos

07:53.880 --> 07:56.250
a adicionar segmentos até chegarmos a 128 bits,

07:56.250 --> 07:57.900
o que exigirá oito segmentos, cada

07:57.900 --> 08:00.510
um com quatro dígitos hexadecimais.

08:00.510 --> 08:03.510
Isso me dá um total de 32 dígitos hexadecimais,

08:03.510 --> 08:05.460
o que ainda é bastante longo.

08:05.460 --> 08:09.330
Agora, com 128 bits sendo representados em um endereço IPv6, isso significa

08:09.330 --> 08:12.810
que não teremos mais do que 32 dígitos hexadecimais dentro de

08:12.810 --> 08:14.700
todos esses segmentos.

08:14.700 --> 08:18.150
Agora, por que eu disse que o total desses oito segmentos

08:18.150 --> 08:20.250
não deve ter mais de 32 dígitos?

08:20.250 --> 08:22.800
Por que não seriam apenas 32 dígitos hexadecimais,

08:22.800 --> 08:25.710
já que 32 dígitos vezes quatro bits por dígito

08:25.710 --> 08:28.290
nos daria 128 bits?

08:28.290 --> 08:31.320
Bem, isso ocorre porque o IPv6 nos permite usar uma

08:31.320 --> 08:33.450
abreviação para simplificar nossos

08:33.450 --> 08:35.880
endereços IPv6 muito longos.

08:35.880 --> 08:37.980
Agora, as regras de taquigrafia são realmente importantes

08:37.980 --> 08:40.650
porque você pode ver perguntas de exames sobre elas.

08:40.650 --> 08:43.020
Portanto, se você tiver quatro zeros em um

08:43.020 --> 08:45.360
segmento, poderá colocar um zero em vez disso

08:45.360 --> 08:47.310
e eliminar os zeros iniciais.

08:47.310 --> 08:50.790
Por exemplo, vamos supor que eu tenha um endereço IPv6

08:50.790 --> 08:55.790
muito longo de 2018:0000:0000:0000:0000:0000:0000:4815:54ae.

09:04.470 --> 09:05.820
Usando a regra simples, posso

09:05.820 --> 09:08.490
substituir todos os segmentos que têm vários zeros

09:08.490 --> 09:09.810
por um único zero.

09:09.810 --> 09:14.810
Isso me daria 2018:0:0:0:0:0:0:4815:54ae.

09:19.590 --> 09:22.680
Muito bem, isso reduziu meu número de dígitos hexadecimais de

09:22.680 --> 09:26.790
32 para apenas 17, o que significa que o comprimento é aproximadamente a metade.

09:26.790 --> 09:29.520
Estamos melhorando, mas não vou parar por aqui.

09:29.520 --> 09:30.710
Há outra regra que posso

09:30.710 --> 09:33.000
usar no mundo da abreviação IPv6.

09:33.000 --> 09:35.280
Essa regra diz que, se houver vários segmentos

09:35.280 --> 09:36.840
com zeros e nenhum outro dígito

09:36.840 --> 09:39.420
hexadecimal estiver sendo representado ali,

09:39.420 --> 09:42.150
posso resumir isso usando dois pontos duplos e retirando

09:42.150 --> 09:44.160
todos esses zeros.

09:44.160 --> 09:45.420
Essa regra é especial

09:45.420 --> 09:48.540
porque só é possível usar dois pontos duplos uma única

09:48.540 --> 09:50.460
vez em um endereço IPv6.

09:50.460 --> 09:52.530
Portanto, usando minha regra de dois

09:52.530 --> 09:57.530
pontos duplos, posso resumir 2018:0:0:0:0:0:0:4815:54ae para remover todos

10:00.750 --> 10:03.270
esses cinco conjuntos de zeros e substituí-los

10:03.270 --> 10:04.950
por dois pontos duplos e obter

10:04.950 --> 10:07.450
2018::4815::54ae.

10:10.290 --> 10:13.020
Assim, passei de 32 dígitos hexadecimais

10:13.020 --> 10:14.910
para 17 dígitos hexadecimais

10:14.910 --> 10:17.160
e agora passei de 17 dígitos para 12

10:17.160 --> 10:19.080
dígitos, muito menores e muito

10:19.080 --> 10:21.690
mais fáceis de trabalhar.

10:21.690 --> 10:24.240
Você pode ver como essa abreviação é realmente útil.

10:24.240 --> 10:27.150
Então, como você vai reconhecer um endereço IPv6

10:27.150 --> 10:28.950
em relação a um endereço IPv4?

10:28.950 --> 10:32.130
Bem, a primeira maneira é ver o que é o IPv4.

10:32.130 --> 10:35.400
O IPv4 sempre usará a notação decimal pontilhada

10:35.400 --> 10:36.990
com quatro octetos.

10:36.990 --> 10:38.490
Agora, o IPv6, por outro lado,

10:38.490 --> 10:40.530
usará dois pontos entre os números e

10:40.530 --> 10:42.450
será escrito em hexadecimal.

10:42.450 --> 10:44.280
Muito bem, uma das perguntas que

10:44.280 --> 10:45.810
você poderá ver no dia do teste

10:45.810 --> 10:49.080
é identificar um endereço IPv6 quando vir um.

10:49.080 --> 10:51.180
Por exemplo, você pode receber uma pergunta

10:51.180 --> 10:53.700
como: qual dos seguintes é um endereço IPv6?

10:53.700 --> 10:55.410
Essa é uma pergunta justa a ser feita a você.

10:55.410 --> 10:59.280
Você terá algumas opções como 192. 168. 1. 1, que sabemos que

10:59.280 --> 11:01.830
não é o endereço, pois é um endereço IPv4.

11:01.830 --> 11:06.830
Você obterá 12:34:56:78:90:AB

11:07.590 --> 11:12.000
ou 1234::5678::90AB.

11:12.000 --> 11:15.120
Então, espere um pouco, os dois últimos que acabei de dizer

11:15.120 --> 11:17.010
são muito parecidos, não são?

11:17.010 --> 11:20.310
Sim, mas apenas um deles é um endereço IPv6 válido.

11:20.310 --> 11:21.630
Você sabe qual é?

11:21.630 --> 11:24.000
Porque a maioria dos alunos se confunde nesse ponto.

11:24.000 --> 11:28.020
Agora, a segunda opção aqui não é de fato um endereço IPv6.

11:28.020 --> 11:29.820
Em vez disso, é um endereço MAC.

11:29.820 --> 11:31.260
Lembre-se de que os endereços

11:31.260 --> 11:33.060
MAC, que são endereços físicos da camada

11:33.060 --> 11:35.580
2, sempre terão 12 dígitos hexadecimais e serão separados

11:35.580 --> 11:37.230
por dois pontos.

11:37.230 --> 11:38.370
Normalmente, eles são

11:38.370 --> 11:40.410
escritos como seis grupos de dois dígitos

11:40.410 --> 11:43.200
cada e cada um deles é separado por dois pontos.

11:43.200 --> 11:46.080
Um endereço IPv6, por outro lado, sempre deve ser escrito

11:46.080 --> 11:48.120
em segmentos de quatro dígitos cada e

11:48.120 --> 11:50.580
sempre deve ter 16 segmentos, a menos que você

11:50.580 --> 11:52.500
veja dois pontos duplos.

11:52.500 --> 11:55.080
Neste exemplo, temos dois pontos duplos entre o primeiro

11:55.080 --> 11:58.020
e o segundo segmento em nossa terceira opção.

11:58.020 --> 12:00.840
Portanto, essa é uma boa abreviação que podemos usar

12:00.840 --> 12:03.450
e identificamos que se trata de um endereço IPv6 porque

12:03.450 --> 12:05.130
removemos todos os zeros entre

12:05.130 --> 12:08.520
o primeiro e o segundo segmento dentro desse endereço.

12:08.520 --> 12:09.960
Portanto, se você contar

12:09.960 --> 12:11.790
algo que se pareça com um endereço

12:11.790 --> 12:15.480
IPv6 e tiver 12, exatamente 12 dígitos hexadecimais separados por

12:15.480 --> 12:17.040
dois pontos simples, e não vir

12:17.040 --> 12:18.840
dois pontos duplos em lugar algum,

12:18.840 --> 12:22.140
esse é um endereço MAC, não um endereço IPv6.

12:22.140 --> 12:24.180
Caso contrário, se for parecido

12:24.180 --> 12:25.860
com este e incluir dígitos hexadecimais,

12:25.860 --> 12:29.190
será um endereço IPv6 no dia do exame.

12:29.190 --> 12:31.440
Para o exame, você só precisa ser capaz de

12:31.440 --> 12:33.540
reconhecer a aparência de um endereço

12:33.540 --> 12:35.790
IPv6 e deve ser capaz de resumir um deles retirando

12:35.790 --> 12:38.070
os zeros e consolidando-os usando o truque

12:38.070 --> 12:39.960
dos dois pontos.

12:39.960 --> 12:41.490
Se você conseguir fazer essas duas

12:41.490 --> 12:45.000
coisas, não terá problemas com o endereçamento IPv6 no dia do exame.

12:45.000 --> 12:47.280
Agora, quando se trata de endereçamento IPv6,

12:47.280 --> 12:50.100
há três tipos diferentes de endereços que você pode

12:50.100 --> 12:52.220
usar: endereços unicast, endereços multicast

12:52.220 --> 12:54.210
e endereços anycast.

12:54.210 --> 12:56.640
Um dos aspectos interessantes do IPv6 que

12:56.640 --> 12:59.040
realmente o distingue do IPv4 é que podemos

12:59.040 --> 13:01.830
atribuir vários endereços IPv6 a uma única interface

13:01.830 --> 13:03.900
em um cliente.

13:03.900 --> 13:05.730
E essas atribuições podem ser uma mistura

13:05.730 --> 13:07.680
de qualquer um desses três tipos diferentes:

13:07.680 --> 13:10.290
unicast, multicast e anycast.

13:10.290 --> 13:13.140
Portanto, mesmo que você tenha apenas uma placa de

13:13.140 --> 13:14.910
interface de rede em sua estação

13:14.910 --> 13:17.430
de trabalho ou laptop, poderá ter vários endereços

13:17.430 --> 13:19.860
IPv6 e diferentes tipos de endereços IPv6

13:19.860 --> 13:22.140
atribuídos a essa placa.

13:22.140 --> 13:23.850
Os endereços unicast serão usados

13:23.850 --> 13:25.950
para identificar uma única interface.

13:25.950 --> 13:28.950
Eles são divididos em endereços unicast roteados globalmente

13:28.950 --> 13:30.930
e endereços locais de link.

13:30.930 --> 13:32.760
Um endereço unicast roteado globalmente

13:32.760 --> 13:36.150
é semelhante ao que temos como endereço público com o IPv4

13:36.150 --> 13:39.600
usando endereços unicast de classe A, B e C.

13:39.600 --> 13:42.840
Agora, no IPv6, um endereço unicast roteado

13:42.840 --> 13:44.220
globalmente sempre

13:44.220 --> 13:49.050
começará com seu primeiro segmento contendo 2000-3999.

13:49.050 --> 13:52.740
Agora, se você vir 2000-3999 como seu primeiro segmento, isso significa

13:52.740 --> 13:55.770
que é um endereço unicast roteado globalmente.

13:55.770 --> 13:58.050
Por exemplo, o endereço IPv6

13:58.050 --> 14:03.050
de 2584:0db8:8583:1234:5678:882e:0370:7334 seria roteado

14:10.800 --> 14:14.010
globalmente como um endereço unicast

14:14.010 --> 14:17.070
porque seu primeiro segmento contém

14:17.070 --> 14:20.670
2584, que está entre 2000 e 3999.

14:20.670 --> 14:22.650
Agora, um endereço local de link, por

14:22.650 --> 14:24.690
outro lado, também chamado de endereço

14:24.690 --> 14:28.020
de uso local, é usado como um endereço IP privado era no IPv4.

14:28.020 --> 14:29.970
Um endereço link-local no

14:29.970 --> 14:32.097
IPv6 só pode ser usado em uma

14:32.097 --> 14:36.840
rede local e sempre começará com FE80 como seu primeiro segmento

14:36.840 --> 14:38.940
em um endereço IPv6.

14:38.940 --> 14:41.760
Agora, sempre que um sistema IPv6 for iniciado, ele criará

14:41.760 --> 14:44.100
um endereço local de link para cada interface

14:44.100 --> 14:47.070
IPv6 desse sistema, mesmo que um endereço globalmente

14:47.070 --> 14:48.720
roteável já tenha sido configurado

14:48.720 --> 14:50.190
manualmente ou obtido por meio

14:50.190 --> 14:53.700
de um protocolo de configuração como o DHCP.

14:53.700 --> 14:56.340
Para fazer isso, ele usará algo conhecido

14:56.340 --> 15:00.840
como SLAAC, a autoconfiguração de endereço sem estado ou S-L-A-A-C.

15:00.840 --> 15:02.610
Com a configuração automática sem estado,

15:02.610 --> 15:04.680
o host não precisa obter endereços ou outras

15:04.680 --> 15:06.210
informações de configuração de

15:06.210 --> 15:08.880
um servidor centralizado, como o DHCP.

15:08.880 --> 15:11.640
Em vez disso, ele pode atribuir a si mesmo, de forma independente,

15:11.640 --> 15:13.050
um endereço local de link, testar

15:13.050 --> 15:15.420
a exclusividade desse endereço local de link, atribuir

15:15.420 --> 15:17.430
o endereço local de link a si mesmo, entrar em

15:17.430 --> 15:20.220
contato com o roteador e fornecer orientação ao nó sobre como proceder

15:20.220 --> 15:22.680
com a configuração automática.

15:22.680 --> 15:25.770
E ele pode até mesmo configurar o endereço unicast global

15:25.770 --> 15:27.090
que deseja usar.

15:27.090 --> 15:29.520
Voltaremos a esse conceito em alguns minutos, quando

15:29.520 --> 15:31.110
nos aprofundarmos um pouco mais

15:31.110 --> 15:34.080
nele e começarmos a falar sobre o EUI-64 e o protocolo de descoberta

15:34.080 --> 15:35.580
de vizinhos, já que esses dois

15:35.580 --> 15:37.650
processos são usados com o protocolo de autoconfiguração

15:37.650 --> 15:41.580
de endereços sem estado conhecido como SLAAC.

15:41.580 --> 15:43.680
Em seguida, temos os endereços multicast.

15:43.680 --> 15:45.360
Agora, os endereços multicast são usados

15:45.360 --> 15:47.100
para identificar um grupo de interfaces,

15:47.100 --> 15:49.710
de modo que um pacote possa ser enviado a um endereço multicast

15:49.710 --> 15:52.680
e depois entregue a todas as interfaces de um grupo.

15:52.680 --> 15:56.550
No IPv6, um endereço multicast sempre conterá FF como os dois

15:56.550 --> 15:59.460
primeiros dígitos no primeiro segmento.

15:59.460 --> 16:02.280
Se você vir FF no início de um endereço IPv6, lembre-se

16:02.280 --> 16:04.800
de que se trata de multicast.

16:04.800 --> 16:06.330
O último tipo de endereço que

16:06.330 --> 16:08.700
temos é conhecido como endereço anycast.

16:08.700 --> 16:11.610
Os endereços anycast são usados para identificar um conjunto de interfaces,

16:11.610 --> 16:14.400
de modo que um pacote possa ser enviado a qualquer membro do conjunto.

16:14.400 --> 16:16.320
Os endereços anycast são, na verdade, alocados

16:16.320 --> 16:18.060
do espaço de endereços unicast.

16:18.060 --> 16:19.620
Portanto, não há realmente nenhuma

16:19.620 --> 16:22.710
maneira de determinar se um endereço IPv6 é unicast ou anycast

16:22.710 --> 16:25.410
apenas olhando para o endereço IPv6.

16:25.410 --> 16:28.050
Agora, quando se trata de multicast ou link-local, você

16:28.050 --> 16:29.790
tem uma maneira muito fácil de fazer

16:29.790 --> 16:31.440
isso, mas não tem uma maneira fácil

16:31.440 --> 16:33.870
de descobrir unicast versus anycast.

16:33.870 --> 16:35.010
Muito bem, vamos voltar

16:35.010 --> 16:36.990
e falar um pouco mais sobre o SLAAC, o processo

16:36.990 --> 16:40.140
de autoconfiguração de endereços sem estado.

16:40.140 --> 16:42.090
Como eu disse, no IPv6, há um processo

16:42.090 --> 16:45.120
de autoconfiguração conhecido como SLAAC, que usamos

16:45.120 --> 16:46.980
para descobrir a rede atual em que

16:46.980 --> 16:48.570
a interface está localizada

16:48.570 --> 16:51.360
e, em seguida, permitir que ela selecione seu próprio

16:51.360 --> 16:56.360
ID de host com base em seu endereço MAC usando um processo conhecido como EUI-64.

16:56.550 --> 17:01.410
Agora, esse processo de EUI-64 ou identificador exclusivo estendido permitirá

17:01.410 --> 17:03.450
que um host atribua a si mesmo um identificador

17:03.450 --> 17:07.967
de interface IPv6 exclusivo de 64 bits chamado EUI-64.

17:09.180 --> 17:12.000
Agora, esse endereço no formato EUI-64 é obtido

17:12.000 --> 17:15.480
usando o endereço MAC de 48 bits da interface.

17:15.480 --> 17:19.260
O endereço MAC é primeiro separado em duas partes de 24 bits.

17:19.260 --> 17:22.890
A primeira metade do endereço MAC conterá o OUI (Organizational Unique Identifier),

17:22.890 --> 17:25.170
ou seja, o identificador exclusivo da organização.

17:25.170 --> 17:26.850
E a segunda metade conterá a placa

17:26.850 --> 17:29.010
de interface de rede específica.

17:29.010 --> 17:30.780
Agora, entre eles, vamos

17:30.780 --> 17:35.730
inserir um valor hexadecimal de 16 bits de FFFE.

17:35.730 --> 17:39.990
Dessa forma, posso pegar 24 bits, 16 bits e 24 bits

17:39.990 --> 17:44.760
e juntá-los para obter um endereço EUI de 64 bits.

17:44.760 --> 17:47.340
Isso lhe dá os 64 bits necessários para

17:47.340 --> 17:49.860
identificar a interface na rede.

17:49.860 --> 17:52.320
Em seguida, a interface usará a descoberta

17:52.320 --> 17:53.910
automática para determinar

17:53.910 --> 17:57.030
a rede em que está e adicionará a parte da rede do endereço

17:57.030 --> 18:00.960
IPv6, que será os primeiros 64 bits dentro dos nossos endereços.

18:00.960 --> 18:02.940
Agora, vamos colocar os primeiros

18:02.940 --> 18:05.580
64 bits para representar a rede na frente dos

18:05.580 --> 18:09.390
64 bits do endereço EUI-64 que criamos a partir do nosso endereço

18:09.390 --> 18:13.050
MAC para criar um endereço IPv6 unicast globalmente roteável

18:13.050 --> 18:14.550
que podemos usar.

18:14.550 --> 18:16.890
Assim, você pode ver como tudo isso funciona em conjunto

18:16.890 --> 18:18.180
usando o endereço MAC para criar

18:18.180 --> 18:20.700
esse endereço globalmente roteável.

18:20.700 --> 18:24.180
Agora, o DHCP também pode ser usado no IPv6, se você

18:24.180 --> 18:25.560
preferir usá-lo.

18:25.560 --> 18:29.520
Se for o caso, você terá que usar o protocolo DHCPv6.

18:29.520 --> 18:30.930
Isso permitiria que você fizesse

18:30.930 --> 18:34.650
com que o DHCP atribuísse automaticamente coisas de um servidor DHCPv6.

18:34.650 --> 18:38.520
Mas como o processo de configuração automática com EUI-64 já está incorporado

18:38.520 --> 18:41.430
ao protocolo IPv6 por padrão, você realmente não precisa

18:41.430 --> 18:43.230
usar o DHCPv6.

18:44.280 --> 18:47.580
Mas se você quiser usar o DHCPv6, poderá fazê-lo, e ele permitirá

18:47.580 --> 18:48.870
que você atribua os endereços

18:48.870 --> 18:51.360
que cada interface receberá, em vez de permitir

18:51.360 --> 18:52.500
que elas usem o protocolo

18:52.500 --> 18:55.170
de configuração automática do SLAAC.

18:55.170 --> 18:58.560
Agora, como eu disse, o IPv6 escolherá seu próprio endereço com

18:58.560 --> 19:00.930
base em seu endereço MAC por padrão e, em seguida,

19:00.930 --> 19:03.480
usará esse recurso conhecido como NDP ou protocolo

19:03.480 --> 19:05.310
de descoberta de vizinhos para conhecer

19:05.310 --> 19:09.990
os outros endereços da Camada 2 na rede com base em seus endereços MAC e, então, escolherá

19:09.990 --> 19:12.630
seu próprio ID de host.

19:12.630 --> 19:15.630
Agora, para o exame, você não precisa conhecer o NDP a fundo,

19:15.630 --> 19:17.850
mas deve entender que o NDP, esse protocolo

19:17.850 --> 19:20.847
de descoberta de vizinho, é usado no IPv6 e que ele assume muitas

19:20.847 --> 19:22.410
das funções do anúncio de roteador

19:22.410 --> 19:24.420
e da descoberta de vizinho e as manipula

19:24.420 --> 19:25.683
para você.
