Boas Práticas de Filtragem BGP em IPv4 e IPv6

Olá Pessoal,

Este artigo tem por objetivo chamar a atenção para algumas recomendações e exemplos de boas práticas de filtragem de prefixos no BGP que são de grande interesse para aqueles responsáveis por um AS e que queiram impedir o recebimento de rotas inesperadas que sequer deveriam existir na Internet, mas que podem aparecer em decorrência de erros de configuração ou mesmo de ataques. A topologia abaixo é bastante simples, mas suficiente para exemplificar as configurações deste artigo.

Na tabela abaixo o leitor encontra uma relação das redes reservadas no IPv4 e que, portanto, devem ser filtradas nos filtros de entrada do BGP. Na tabela há uma breve descrição da finalidade de cada rede reservada, além do link para as respectivas RFCs com as aplicações das redes reservadas.

|------------------|---------------|------|
| Endereço         | Descrição     | RFC# |
|------------------|---------------|------|
| 0.0.0.0      /08 | Rede Zero     | 6890 |
| 10.0.0.0     /08 | Privado       | 1918 |
| 100.64.0.0   /10 | CGNAT         | 6598 |
| 127.0.0.0    /08 | Loopback      | 6890 |
| 169.254.0.0  /16 | Link Local    | 3927 |
| 172.16.0.0   /12 | Privado       | 1918 |
| 192.0.0.0    /24 | IETF          | 6890 |
| 192.0.2.0    /24 | Documentação  | 5737 |
| 192.168.0.0  /16 | Privado       | 1918 |
| 198.18.0.0   /15 | Benchmark     | 2544 |
| 198.51.100.0 /24 | Documentação  | 5737 |
| 203.0.113.0  /24 | Documentação  | 5737 |
| 224.0.0.0    /04 | Multicast     | 5771 |
| 240.0.0.0    /04 | Classe E      | 1700 |
|------------------|---------------|------|

Na sequência trago os comandos necessários para criar uma prefix-list denominada FILTRO-ENTRADA em que é negada a recepção de qulaquer uma dessas redes reservadas ou mesmo sub-redes geradas a partir delas. É comum utilizar prefix-list para esse fim pela flexibilidade de informar não apenas os prefixos exatos, mas também uma faixa de prefixos que sejam menores ou igual (le) do que determinado valor de referência. A última regra permite o recebimento de qualquer prefixo menor do que /24 (0.0.0.0/0 le 24), uma prática recomenda porque impede o recebimento de anúncios fragmentados que sejam maiores do que /24. Depois de criar a lista em R1, é necessário aplicá-la na entrada da vizinhança BGP com R4.

!-- Criação do Filtro via Prefix-List
R1(config)# ip prefix-list FILTRO-ENTRADA deny   0.0.0.0/8       le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   10.0.0.0/8      le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   100.64.0.0/10   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   127.0.0.0/8     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   169.254.0.0/16  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   172.16.0.0/12   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.0.0.0/24    le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.0.2.0/24    le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.168.0.0/16  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   198.18.0.0/15   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   198.51.100.0/24 le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   203.0.113.0/24  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   224.0.0.0/4     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   240.0.0.0/4     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA permit 0.0.0.0/0       le 24

!-- Aplicação do Filtro no Vizinho eBGP
R1(config)# router bgp 100
R1(config-router)# neighbor 203.0.113.2 remote-as 200
R1(config-router)# neighbor 203.0.113.2 prefix-list FILTRO-ENTRADA in
R1(config-router)# end
R1# clear bgp all 200 soft

É interessante aproveitar o assunto e fazer um paralelo com esse mesmo procedimento no contexto do protocolo IPv6. Na tabela abaixo o leitor encontra uma relação das redes reservadas no IPv6 e que, portanto, devem ser filtradas nos filtros de entrada do BGP. Na tabela há uma breve descrição da finalidade de cada rede reservada, além do link para as respectivas RFCs com as aplicações das redes reservadas.

|------------------|---------------|------|
| Endereço         | Descrição     | RFC# |
|------------------|---------------|------|
| ::          /0   | Default       |      |
| ::          /128 | Sem Endereço  | 4291 |
| ::1         /128 | Loopback      | 4291 |
| ::ffff:0:0  /96  | IPv4 Mapeado  | 4291 |
| 0100::      /64  | Descarte      | 6666 |
| 2000::      /3   | Global        | 3587 |
| 2001::      /32  | Teredo        | 4380 |
| 2001:10::   /28  | ORCHID        | 4843 |
| 2001:db8::  /32  | Documentação  | 3849 |
| 2002::      /16  | 6to4          | 3056 |
| fc00::      /7   | Unique Local  | 4193 |
| fe80::      /10  | Link-Local    | 4291 |
| ff00::      /8   | Multicast     | 4291 |
|------------------|---------------|------|

Na sequência trago os comandos necessários para criar uma prefix-list denominada FILTRO-ENTRADA-v6 em que é negada a recepção de qulaquer uma dessas redes reservadas ou mesmo sub-redes geradas a partir delas. Observem nos comandos abaixo que nem todas as redes reservadas da tabela acima aparecem explicitamente nas regras, já que a sequência de permissões e negações apresentada é suficiente para garantir a filtragem delas. Com base no filtro abaixo, somente são permitidos prefixos IPv6 iguais ou menores do que /48, uma boa prática para evitar o recebimento de prefixos fragmentados.

ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2001:db8::/32  le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2001::/32
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2001::/32      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2002::/16   
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2002::/16      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   3ffe::/16      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2000::/3       le 48   
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   ::/0           le 128

Caso o laboratório estivesse configurado com endereços IPv6, essa prefix-list poderia ser aplicada em um vizinho eBGP (2001:db8:cafe::40) através dos comandos abaixo. Uma diferença no contexto do IPv6 é que as políticas do BGP devem ser aplicadas no sub-modo de configuração da address-family IPv6. O leitor interessado na configuração de BGP através de IPv6 pode recorrer ao laboratório 34 do livro ou mesmo ao artigo intitulado "Peering IPv6 no Roteamento BGP".

!-- Exemplo de Aplicação do Filtro na Address Family IPv6
R1(config)# ipv6 unicast-routing
R1(config)# router bgp 100
R1(config-router)# neighbor 2001:DB8::2 remote-as 200
R1(config-router)# address-family ipv6 unicast
R1(config-router-af)# neighbor 2001:DB8::2 prefix-list FILTRO-ENTRADA-v6 in
R1(config-router-af)# neighbor 2001:DB8::2 activate

Há várias fontes de distribuição de filtros pradrões na Internet que tem por objetivo tornar a Internet um espaço mais seguro. Uma fonte interessante é do Team Cymru que atualiza sua relação de prefixos a cada 4 horas e que contempla, inclusive, aqueles prefixos alocados às  autoridades regionais da Internet (RIR) que ainda não foram atribuídos para nenhum AS. Vale à pena conferir o link abaixo...

http://www.team-cymru.org/bogon-reference-http.html

Façam seus testes...

Samuel.

Padrões da Internet em Protuguês Claro

Olá Pessoal.

No meu livro intitulado "IPv6 - O Novo Protocolo da Internet" explico ao leitor que a Internet é uma rede baseada em padrões abertos, onde suas tecnologia são publicadas pela IETF (Internet Engineering Task Force) em documentos públicos acessíveis a qualquer pessoa, que são denominados RFCs (Request for Comments). Essa é uma das características cruciais da rede, afinal, o desenvolvimento da Internet até ela se tornar o que conhecemos hoje só foi possível por causa dos padrões abertos.

Gostaria de compartilhar com vocês mais um vídeo produzido pelo amigo Moreiras do NIC.br, intitulado "IETF e os Padrões da Internet em Português Claro". Esse vídeo aborda de maneira sucinta (e clara) o que é a IETF, tradução literal de Força-Tarefa em Engenharia da Internet, bem como a importância do seu principal produto na busca pela padronização da Internet que são as RFCs.

Compartilhem com seus colegas interessados em fazer parte da Internet...

Samuel.

Extensões de Privacidade do IPv6 no Linux

Olá Pessoal.

No artigo anterior, intitulado "Endereço IPv6 e Função EUI-64 no Microsoft Windows", foi explicado ao leitor como habilitar a função EUI-64 no Windows para que o sufixo dos endereços IPv6 seja gerado a partir do endereço MAC das interfaces de rede. Essa configuração é necessária porque o comportamento padrão dos sistemas operacionais da Microsoft® consiste em gerar aleatoriamente os sufixos dos endereços IPv6, prática documentada na RFC 4941.

A Microsoft® optou por adotar essa prática das "extensões de privacidade" porque entende que utilizar o endereço MAC das interfaces de rede no próprio endereço IPv6 é um risco de segurança que atinge à privacidade dos usuários, uma vez que fica mais fácil rastrear a máquina do usuário independente da rede em que ele esteja conectado.

Enquanto que sistemas Microsoft utilizam as "extensões de privacidade" por padrão, as diversas distribuições do sistema operacional Linux utilizam por padrão a função de expansão EUI-64 para gerar o sufixo dos endereços IPv6 a partir do endereço MAC das interfaces de rede, conforme pode ser observado na figura abaixo em relação ao endereço de link-local (fe80) da interface wlan0.

Da mesma forma que no artigo anterior o leitor aprendeu a configurar o Windows para mudar seu comportamento padrão, esse artigo mostra como configurar o Linux para mudar seu comportamento padrão, ou seja, habilitar as "extensões de privacidade" para que os sufixos dos endereços IPv6 sejam gerados aleatoriamente. Para fazê-lo no Linux (em distribuições baseadas no Debian) é necessário ter privilégio de root e digitar as seguintes linhas de comando:

echo "2" > /proc/sys/net/ipv6/conf/all/use_tempaddr
/etc/init.d/networking restart

O resultado dessa configuração pode ser observado na figura abaixo que traz a saída do comando ifconfig na interface eth0. Reparem que com essas configurações, a partir do prefixo da rede (2001:db8:cafe::/64), o Linux autoconfigura dois endereços IPv6 com sufixos diferentes, sendo um originalmente gerado através da função EUI-64 (vermelho) e outro temporário gerado aleatoriamente (amarelo). Dessa forma os endereços com sufixo aleatório/temporário serão preferíveis aos endereços com sufixo EUI-64.

Essa configuração pode ser desfeita a qualquer momento alterando o valor do arquivo "use_tempaddr". Os possíveis valores do arquivo de configuração "use_tempaddr" localizado em "/proc/sys/net/ipv6/conf/all" são:

• <= 0 : Desativa a Privacidade (Padrão)
• == 1 : Ativa a Privacidade c/ Preferência por EUI-64
• >= 2 : Ativa a Privacidade c/ Preferência por Sufixos Aleatórios/Temporários

Façam seus testes...

Abraço.

Samuel.

Endereço IPv6 e Função EUI-64 no Microsoft Windows

Olá Pessoal.

Em outro artigo que escrevi, intitulado "Autoconfiguração de Endereços IPv6 (SLAAC)", expliquei ao leitor como funciona o processo de autoconfiguração de endereços no IPv6. De maneira bem resumida, apenas para relembrar, os roteadores são responsáveis por fazer o anúncio do(s) prefixo(s) através de mensagens ICMPv6 Tipo 134 (RA), enquanto que o sufixo identificador do host é automaticamente gerado a partir do endereço MAC da interface de rede.

Depois de aprendido o prefixo da rede, fica faltando apenas determinar o sufixo que será utilizado nos últimos 64 bits do Host-ID (sufixo de host). O sufixo de host é automaticamente gerado a partir do endereço físico (MAC) da interface de rede. O detalhe é que o MAC tem apenas 48 bis, por isso é aplicada uma função de expansão denominada IEEE EUI-64 (Extended Unique Identifier) no endereço físico que preenche os demais 16 bits através de um algoritmo padronizado, processo que pode ser relembrado na figura abaixo.

Esse é o comportamento padrão da maioria dos sistemas operacionais que seguem a RFC 2373, como acontece no Linux e no MacOS. No entanto, o Microsoft® Windows não utiliza a função de expansão EUI-64 para gerar o Host-ID a partir do MAC das interfaces. A Microsoft® optou por gerá-los aleatoriamente porque entende que é um risco de segurança incorporar os endereços físicos das interfaces de rede no próprio IPv6, o que é uma prática de privacidade proposta na RFC 4941 intitulada "Privacy Extensions for SLAAC in IPv6". Para exemplificar esse processo "padrão", a figura abaixo traz uma exibição das configurações de rede no Windows.

Reparem na imagem anterior que o endereço MAC da interface de rede é 00-22-5F-D1-BA-BD e o sufixo utilizado no endereço IPv6 é a5c9:9415:9239:e855 (anexado ao prefixo link-local fe80), ou seja, não existe nenhuma relação entre o sufixo gerado aleatoriamente e o endereço físico da interface de rede. Cabe destacar que o %X utilizado ao final dos endereços IPv6 no Windows é apenas um índice numérico utilizado para referenciar cada uma das interfaces instaladas no sistema e, portanto, não faz parte do endereço v6.

Apesar de gerar o sufixo aleatoriamente ser o comportamento padrão do Microsoft® Windows, isso pode trazer mais problemas de gestão do que benefícios. Esse processo pode tornar mais difícil o processo de monitoramento das máquinas e também requer sucessivas atualizações de DNS a cada vez que o endereço IPv6 do host é alterado em cada boot. O administrador pode optar por utilizar o método EUI-64 para gerar o sufixo de host em todas as interfaces do sistema, desativando as extensões de privacidade. Para fazê-lo, é necessário entrar no prompt de comandos com elevação de administrador e entrar com os seguintes comandos:.

netsh interface ipv6 set privacy state=disabled store=active

netsh interface ipv6 set privacy state=disabled store=persistent

netsh interface ipv6 set global randomizeidentifiers=disabled store=active

netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent

Depois de feito isso, basta exibir novamente as configurações de rede no Windows para observar que a função EUI-64 já está em operação, conforme saída da figura abaixo. Caso o leitor queira reativar as extensões de privacidade e, portanto, desativar o EUI-64, basta repetir esse procedimento substituindo o parâmetro state=disabled por state=enabled. 

Reparem na figura acima que agora o sufixo utilizado no endereço IPv6 é 0222:5fff:fed1:babd (anexado ao prefixo fe80), ou seja, ele foi gerado a partir do MAC 00-22-5F-D1-BA-BD. Para que esse processo fique ainda mais claro, vamos aplicar a função EUI-64 passo-a-passo:

Os 48 bits do MAC são separados em dois blocos de 24 bits, ou seja, <00225F> e <D1BABD>. Feito isso, são inseridos os algarismos hexadecimais FFFE entre eles, ficando 00225FFFFED1BABD. Por fim, o sétimo bit tem seu valor invertido, o que faz com que o segundo algarismo 0 seja transformado em 2. Dessa forma chega-se ao resultado 02225FFFFED1BABD. O resultado é o sufixo 0222:5fff:fed1:babd utilizado no endereço IPv6. Façam seus testes...

Abraço.

Samuel.

NAT no Redirecionamento de Endereços e Portas

Olá Pessoal.

Esse é mais um daqueles artigos que não aborda conteúdo relacionado aos exames de nível CCNA da Cisco, mas que explica como configurar algo muito comum no cotidiano das empresas: o redirecionamento de endereços e portas para que um dado serviço em execução na rede interna privada possa ser acessível através da Internet pública.

No Lab10 do livro "Laboratórios de Tecnologias Cisco em Infraestrutura de Redes" o leitor aprende a configurar o NAT para realizar a tradução dos endereços IPv4 privados de origem de uma rede interna para endereços públicos roteáveis na Internet, um procedimento denominado SNAT que é utilizado pelas empresas para fins de compartilhamento da Internet. 

Cabe apenas destacar que essa modalidade de NAT foi criada com o objetivo principal de economizar endereços IPv4, uma vez que toda uma rede com endereços privados da RFC 1918 (10/8, 172.16/12 e 192.168/16) pode ter acesso à Internet através de apenas um (ou poucos) endereço(s) público(s).  

No entanto, além do SNAT para fins de compartilhamento da Internet, existe uma outra modalidade de NAT, denominada DNAT, em que é feita a tradução dos endereços de destino. Apesar de DNAT não ser cobrado no exame CCNA, em contraste ao SNAT que é bastante cobrado, o DNAT é bastante praticado pelas empresas para fins de redirecionamento de endereços/portas e até mesmo para fins de balanceamento de carga (quando o destino redirecionado são vários endereços).

Nesse artigo estarei utilizando o cenário da figura abaixo (um complemento do Lab10 do livro) para mostrar como o NAT pode ser configurado para realizar o redirecionamento de endereços e portas de forma que um dado serviço web (intranet) em execução na rede privada 172.22.0.0/16, especificamente no servidor 172.22.0.1, possa ser acessado pelos funcionários da empresa em suas casas, através da Internet.

Nesse caso, como a rede utiliza o endereço privado 172.22.0.0/16 da RFC 1918, então o serviço web em execução no servidor não pode ser acessado através da Internet porque esses endereços simplesmente não são roteáveis publicamente. O primeiro ponto da empresa que tem alcançabilidade pela Internet é seu roteador de borda que possui o endereço público 100.1.1.2/30, provido por seu ISP. No Lab10 do livro esse mesmo cenário foi configurado com o NAT (SNAT) para realizar o compartilhamento da Internet para todas as máquinas da rede privada.

Agora trago um exemplo de como ficaria a configuração para habilitar o NAT na modalidade DNAT , permitindo que todo acesso destinado ao endereço público do roteador de borda (100.1.1.2) na porta 8080 seja redirecionado para o endereço privado 172.22.0.1 na porta 80.

01. Router-NAT(config)# int f0/0

02. Router-NAT(config-if)# ip nat inside

03. Router-NAT(config-if)# int s0/0

04. Router-NAT(config-if)# ip nat outside

05. Router-NAT(config-if)# exit

06. Router-NAT(config)# access-list 1 permit 172.22.0.0 0.0.255.255

07. Router-NAT(config)# ip nat inside source list 1 interface s0/0 overload

08. Router-NAT(config)# ip nat inside source static tcp 172.22.0.1 80 100.1.1.2 8080

Obs.: As configurações apresentadas nas linhas de 01 a 07 já existem no Lab10 do livro e foram utilizadas para definir as zonas inside (rede interna privada) e outside (zona externa pública) e para realizar a tradução dos endereços de origem para compartilhamento da Internet (linha 07). 

A configuração do NAT para fazer o redirecionamento de portas/endereços é exibida na linha 8 (destacada em amarelo), onde informamos o mapeamento estático entre um endereço inside e outro outside (e suas respectivas portas). Reparem, portanto, que "dissemos" ao roteador que todos os pacotes destinados ao seu endereço público na porta 8080 (100.1.1.2:8080) devem ser encaminhados para o endereço privado do servidor na porta padrão (172.22.0.1:80). 

Simples assim e bastante útil no cotidiano...

Abraço.

Samuel.

Servidores DHCPv6 em Redes IPv6

Olá Pessoal.

Muito se fala da visível diferença que existe nos endereços IPv4 (32 Bits) e IPv6 (128 Bits), o que permite uma quantidade de endereços de ordem astronômica com o "novo" protocolo - 340 undecilhões de endereços possíveis! Porém, pouco se fala das VÁRIAS outras diferenças que existem entre os protocolos. O IPv6 é um protocolo novo e que, portanto, possui muitas particularidades bem diferentes do seu antecessor - o tradicional IPv4.

Por exemplo, quando pensamos na questão da atribuição dos endereços, o "novo" IPv6 permite que essa configuração seja realizada de diversas maneiras, tais como:

• Autoconfiguração Stateless (SLAAC)

• Configuração Estática

• Configuração Estática EUI-64

• DHCPv6 Stateful

• DHCPv6 Stateless

Seria necessário um artigo para cada uma dessas técnicas, então esse artigo será focado apenas nas principais diferenças entre o DHCPv6 nas modalidades: (i) Stateful e (ii) Stateless. Aproveitarei a oportunidade para mostrar as diferenças na configuração de um serviço DHCP em roteadores Cisco para ambientes IPv4 e IPv6.

No IPv4 o tradicional serviço de DHCP (Dynamic Host Configuration Protocol) é definido na RFC 2131 e diz respeito à distribuição automática de endereços em uma rede TCP/IPv4 através de um servidor reponsável por executar uma instância de um serviço DHCP. É nesse servidor em que o administrador irá criar um escopo definindo o intervalo de endereços que será distribuído para as máquinas, bem como outras configurações importantes: gateway da rede, servidores de resolução de nomes (DNS), opções, etc.

Nesse caso cabe ao servidor manter uma tabela com o registro dos clientes, seus respectivos endereços atribuídos e seu tempo de empréstimo (lease). Uma vez que o servidor é responsável por manter essa tabela com o "estado" dos clientes associando os endereços físicos das máquinas (MAC) com os endereços lógicos atribuídos (IP), então dizemos que esse é um serviço de natureza stateful, ou seja, é mantido um registro de informações.

A sua configuração através de um roteador Cisco é bastante simples, bastando a entrada de alguns poucos comandos para fazê-lo. Vamos observar o cenário da figura abaixo em que temos uma rede 192.168.221.0 /24, sendo que todas as máquinas estarão configuradas para obter o endereço dinamicamente e o roteador será responsável por executar o serviço DHCP. As configurações necessárias seriam as seguintes:

01. Router(config)# ip dhcp excluded-address 192.168.221.1 192.168.221.30

02. Router(config)# ip dhcp pool NOME-ESCOPO

03. Router(config-dhcp)# network 192.168.221.0 255.255.255.0

04. Router(config-dhcp)# default-router 192.168.221.1

05. Router(config-dhcp)# dns-server 192.168.221.2

Na primeira linha definimos quais endereços devem ser excluídos do escopo que será posteriormente criado, uma vez que esses endereços serão atribuídos estaticamente porque são reservados para os servidores. Na segunda linha foi dado um nome para o escopo que irá compreender os endereços da rede informada na terceira linha, sendo que nas linhas 4 e 5 são informados os endereços que as máquinas deverão utilizar como gateway e DNS. Pois bem, até aqui bem simples! 

Acontece que quando pensamos em IPv6 as coisas mudam bastante. Primeiro porque nativamente as redes IPv6 têm suporte ao processo de autoconfiguração stateless em que as próprias máquinas são capazes de formar seu endereço através de duas etapas: (i) a máquina determina seu identificador de host (sufixo) a partir do endereço físico da interface (MAC) e (ii) a máquina determina seu identificador de rede (prefixo) através de anúncios emitidos pelo roteador através de um protocolo de descoberta de vizinhança (NDP). Em um próximo artigo escreverei detalhadamente sobre o processo de autoconfiguração dos enredeços IPv6...

Por conta disso, via de regra, um servidor DHCP seria algo dispensável em redes IPv6 e agora o roteador da infraestrutura se torna um elemento ainda mais importante. Apesar disso, o DHCPv6 é definido na RFC 3315 e pode existir em duas modalidades: (i) stateful e (ii) stateless. 

A modalidade stateless é aquela em que o servidor não mantém um registro dos endereços atribuídos aos clientes porque agora as máquinas irão formar automaticamente seu endereço a partir do endereço físico da interface de rede (MAC) e através dos anúncios dos prefixos dos roteadores. Nessa modalidade cabe ao servidor DHCPv6 informar apenas os endereços complementares, tais como: DNS e/ou Opções. Vale destacar que a funcionalidade stateless é muito útil para informar automaticamente os servidores DNS da rede, afinal em IPv6 o serviço DNS é fundamental para amenizar a "complexidade" do endereço de 128 bits.

Estamos falando de uma versão bastante simplificada do DHCP que não consome muitos recursos do "servidor" e que utiliza como base o processo de autoconfiguração! Para exemplificar como seria a configuração desse serviço, vamos observar o cenário da figura abaixo que é apenas uma reprodução da figura anterior num ambiente TCP/IPv6 em que temos a rede 2001:DB8:CAFE::/64.

O processo de configuração do DHCPv6 Stateless consiste em criar e configurar o "escopo" (linhas de 1 a 3), destacando que é importante ativar o serviço DHCPv6 na interface conectada à LAN que receberá os endereços dinâmicos (linha 7) e informar aos hosts que as informações complementares devem ser aprendidas pelo serviço DHCPv6 (linha 8), através da ativação da flag O (other-config-flag).

01. Router(config)# ipv6 dhcp pool NOME-ESCOPO
02. Router(config-dhcp)# dns-server 2001:DB8:CAFE::2
03. Router(config-dhcp)# domain-name labcisco.com.br
03. Router(config-dhcp)# exit
04. Router(config)# int f0/0
05. Router(config-if)# ipv6 enable
06. Router(config-if)# ipv6 address 2001:DB8:CAFE::1/64
07. Router(config-if)# ipv6 dhcp server NOME-ESCOPO
08. Router(config-if)# ipv6 nd other-config-flag
09. Router(config-if)# end

Embora não seja recomendado pela Cisco e nem todos os roteadores suportem, ainda existe uma versão stateful do DHCPv6 para aqueles que precisam manter o registro dos endereços dinamicamente atribuídos e que querem determinar o escopo explicitamente. Normalmente essa modalidade será empregada em servidores Linux e Windows Server. O processo de configuração do DHCPv6 Stateful no roteador ficaria:

01. Router(config)# ipv6 dhcp pool NOME-ESCOPO
02. Router(config-dhcp)# address prefix 2001:DB8:CAFE::/64 lifetime 1800 60
03. Router(config-dhcp)# dns-server 2001:DB8:CAFE::2
04. Router(config-dhcp)# exit
05. Router(config)# int f0/0
06. Router(config-if)# ipv6 enable
07. Router(config-if)# ipv6 address 2001:DB8:CAFE::1/64
08. Router(config-if)# ipv6 dhcp server NOME-ESCOPO
09. Router(config-if)# ipv6 nd managed-config-flag
10. Router(config-if)# exit

Reparem que agora tivemos que configurar na interface (linha 9) uma opção que instrui os clientes a receber todas as configurações de endereço via DHCPv6 (stateful), procedimento feito através da ativação da flag M (managed-config-flag). Além disso, na linha 2 o prefixo é explicitamente configurado.

Por fim, o segiunte comando poderia ser utilizado para fins de verificação:

Router# show ipv6 dhcp pool

Esse artigo mostra que as diferenças entre os protocolos IPv4 e IPv6 estão muito além do formato do endereço utilizado. O IPv6 é um protocolo que possui muitas particularidades que não existiam no seu antecessor, motivo pelo qual precisamos disseminar suas funcionalidades e qualificar mais profissionais preparados para lidar com o novo protocolo.

Abraço.

Samuel.

Protocolo EIGRP da Cisco Será Publicado em RFC

Olá Pessoal.

No último evento "Cisco Live!" que ocorreu em Londres (28/jan a 01/fev ) a Cisco anunciou oficialmente que estará publicando as especificações do protocolo EIGRP em RFC, conforme entrevista cedida por Donnie Savage, um dos desenvolvedores do protocolo original.

Com essa manobra o tradicional EIGRP "deixará" de ser um protocolo proprietário para fins de roteamento dinâmico, passando a ser um padrão da Internet. Uma vez que o protocolo será padronizado pelo IETF, então qualquer fabricante de dispositivos de rede poderá adotá-lo em seus equipamentos. Quem ganha com isso são as empresas que possuem roteadores de múltiplos fabricantes em sua infraestrutura porque dessa forma haverá interoperabilidade em seus ambientes híbridos.

Essa é uma iniciativa que deve popularizar ainda mais a adoção do EIGRP em várias redes de computadores, haja vista que atualmente o desempenho do EIGRP é tido como um dos melhores entre os protocolos de roteamento dinâmico. 

É interessante destacar a posição da Cisco em relação às concorrentes, afinal Savage deixa claro na entrevista (vejam o vídeo abaixo) que, durante essa fase inicial de padronização do protocolo, a Cisco estará totalmente aberta para dialogar com os demais fabricantes interessados em adotar o EIGRP para assegurar que haverá plena interoperabilidade.

Adendo: Hoje mesmo fui questionado se ao meu ver haverá interesse dos outros fabricantes em efetivamente implementar o EIGRP como solução de roteamento, acredito que sim. Apesar de muita gente estar insatisfeita com o fato da Cisco ter submetido para padronização apenas os recursos mais básicos (não haverá suporte a áreas stub) e de manter a "posse" do protocolo para posterior aperfeiçoamento, é inegável que o EIGRP tem uma fatia representativa do mercado e o interesse em atender os clientes é mais forte (e mais necessário) do que interesses individuais... O mercado é orientado ao CLIENTE!

Nesse meio-tempo vamos aguardar pelos desdobramentos dessa manobra. Vocês já conseguem imaginar como será a configuração do EIGRP no JunOS? Preparem-se para estabelecer vizinhanças EIGRP entre roteadores Cisco e Juniper! ;-)

Abraço.

Samuel.