O que o IPv6CP negocia e o que ainda precisa de um prefixo
Um endereço link-local na interface PPP é um passo de configuração, não acesso IPv6. Separe a troca de identificadores dos prefixos, das rotas e da integração do cliente.
O IPv6 sobe na interface PPP, aparece um endereço link-local e a alteração é declarada concluída. Depois nada é encaminhado, não existe endereço global e um teste para um destino público falha enquanto a interface continua a parecer configurada. O link subiu; a rede nunca. Execute as quatro verificações abaixo por ordem e pare naquela que explica a diferença.
O que um endereço link-local realmente prova
O IPv6CP levanta o IPv6 no link PPP e negocia um identificador de interface para cada lado. Esse identificador produz um endereço link-local, que basta para falar com o par através do link e não basta para chegar a mais nada. O endereço prova que o link está pronto para IPv6 e não prova nada sobre a rede atrás do par. Lê-lo como endereço de acesso é o erro com que começa a maior parte destas investigações.
As quatro perguntas abaixo separam o que a camada de ligação resolve do que o serviço tem de fornecer. Responda por ordem, porque a uma pergunta posterior não se pode responder enquanto uma anterior continuar aberta.
| Question | Answered by | What it does not settle |
|---|---|---|
| Is IPv6 up on the link? | IPv6CP: interface identifiers, then link-local addresses | Any address reachable beyond the peer |
| Where does a global prefix come from? | Router advertisement, delegated prefix, DHCPv6 or static configuration | IPv6CP carries no prefix of its own |
| Who owns the routes? | The client's tunnel configuration and the server's return path | A link-local address implies no route at all |
| How does this client get configured? | Explicit tunnel settings or router advertisements, depending on the client | The standard does not choose for the implementation |
De onde tem de vir o prefixo
Um endereço global precisa de um prefixo de algum lado: um anúncio de router, um prefixo delegado, DHCPv6 ou configuração estática. O IPv6CP não transporta nenhum, e nenhuma espera no link produzirá um. RFC 5072 coloca o IPv6CP como o passo de configuração que corre antes de outros protocolos IPv6 funcionarem no link, e esse é todo o seu âmbito: preparar o link, não numerar a rede. Forneça o prefixo e a interface começa a transportar tráfego em vez de apenas existir.
Os anúncios de router são a resposta habitual numa LAN e uma resposta menos fiável num túnel ponto a ponto, porque o cliente tem de enviar solicitações e aceitar a resposta ao mesmo tempo. Alguns clientes de túnel não fazem nem uma coisa nem outra. Verifique o que o cliente está disposto a aceitar antes de decidir que o servidor o deve enviar.
O mesmo prefixo tem de ser alcançável a partir do outro extremo. Um cliente que tem um endereço global mas nenhum caminho de volta está configurado, não ligado.
As rotas são uma promessa separada
Mesmo com um endereço, o cliente precisa de saber que destinos pertencem ao túnel, e o servidor precisa de um caminho de volta para esses destinos. São duas decisões tomadas em dois locais. Um túnel que transporta todo o tráfego IPv6 precisa de uma rota predefinida no cliente e de uma rota de volta no servidor; um túnel dividido exige que os dois lados concordem na mesma lista de prefixos. Quando não concordam, o tráfego sai e nunca regressa.
Escreva a lista antes de configurar seja o que for. Se o plano disser que só o prefixo da empresa passa pelo túnel, o cliente não deve ter uma rota IPv6 predefinida, e o servidor não deve anunciar nenhuma.
A integração do cliente decide o resto
Alguns clientes de túnel configuram o IPv6 de forma explícita. O Network Extension da Apple, por exemplo, recebe um endereço, um prefixo e um conjunto de rotas para o túnel, pelo que uma aplicação que o usa não espera um anúncio ao estilo Ethernet. Outros dependem de anúncios de router que chegam pelo link. Os dois modelos são legítimos e exigem comportamentos diferentes do servidor, pelo que a escolha errada produz um cliente que espera para sempre por uma mensagem que ninguém envia. Identifique o modelo antes de alterar o servidor.
Um nome de interface antigo como ppp0 não prova nada sobre a pilha que corre hoje. Um cliente atual pode usar uma API de túnel de pacotes em vez de uma interface PPP, e assumir que se comporta como uma ligação histórica é a forma de quebrar um desenho que funciona. Pergunte pela versão do cliente e pelo método de aprovisionamento, não pelo nome da interface.
Escreva o plano de que o cliente precisa
Uma descrição completa cobre três coisas: que endereço o cliente tem, que destinos o túnel deve transportar e como a rede envia as respostas de volta. Um endereço link-local não responde a nenhuma delas, e um anúncio aceite responde apenas a parte de uma. Verifique cada item em separado em vez de aceitar um indicador verde. Depois registe que mecanismo forneceu cada resposta, porque esse registo transforma o próximo relatório de IPv6 numa verificação de dois minutos.
Guarde o registo com a documentação do serviço e atualize-o quando o cliente mudar. Um plano que estava correto para um cliente PPP pode estar errado para um cliente de túnel de pacotes no mesmo serviço. As quatro perguntas permanecem as mesmas; só as respostas se deslocam.