Mikrotik - Getting IPv6 Going on RouterOS 7.1

 

I already did a post about IPv6 on Mikrotik but with RouterOS 7 going out, some things have slightly changed. So, it’s time for an updated guide. And, as one might expect, things are pretty much the same.

As before, prerequisite is that you get at least /64 prefix from your ISP (Comcast in my case) via DHCPv6. Also assumed is empty IPv6 configuration.

The first thing I like doing is disabling the default neighbor discovery interface. Blasting IPv6 router advertisements on all interfaces is not necessarily a good idea:

Terminal 
/ipv6 nd
set [ find default=yes ] disabled=yes

The next step is to setup DHCP client. Within a few seconds, you should see the prefix being allocated:

Terminal 
/ipv6 dhcp-client
add add-default-route=yes interface=ether1 pool-name=general-pool6 request=prefix  use-peer-dns=no

:delay 5s
print
Flags: D - dynamic, X - disabled, I - invalid
 #    INTERFACE             STATUS        REQUEST             PREFIX
 0    ether1                bound         prefix              2601:db8:9780:ee2c::/64, 3d14h41m41s

At this time I love to allocate address ending with ::1 to the router itself:

Terminal 
/ipv6 address
add address=::1 from-pool=general-pool6 interface=bridge1 advertise=yes

Now it should be possible to ping its address from external computer (in this example address would be 2601:db8:9780:ee2c::1). If this doesn’t work, do check if you have link-local addresses. If none are present, reboot the router and they will be regenerated.

With router reachable, it is time to delegate IPv6 prefix to internal machines too. For this purpose, setup RA (router announcement) over the bridge. While default interval settings are just fine, I like to make them a bit shorter (20-60 seconds):

Terminal 
/ipv6 nd
add interface=bridge1 ra-interval=20s-60s

And that’s all. Now your computers behind the router will have direct IPv6 route to the Internet. Do not forget to setup both router firewall and firewall of individual devices. There is no NAT to save your butt here.

PS: Here is the basic IPv6 firewall allowing all connections out while allowing only established back in:

Terminal 
/ipv6 firewall filter

add chain=input action=drop connection-state=invalid comment="Drop invalid"
add chain=input action=accept connection-state=established,related comment="Accept established"
add chain=input action=accept in-interface=ether1 protocol=udp src-port=547 limit=10,20:packet
add chain=input action=drop in-interface=ether1 protocol=udp src-port=547 comment="Drop ext DHCP >10/sec"
add chain=input action=accept in-interface=ether1 protocol=icmpv6 limit=10,20:packet
add chain=input action=drop in-interface=ether1 protocol=icmpv6 comment="Drop ext ICMP >10/sec"
add chain=input action=accept in-interface=!ether1 protocol=icmpv6 comment="Accept internal ICMP"
add chain=input action=drop in-interface=ether1 comment="Drop external"
add chain=input action=reject comment="Reject everything else"

add chain=output action=accept comment="Accept all"

add chain=forward action=drop connection-state=invalid comment="Drop invalid"
add chain=forward action=accept connection-state=established,related comment="Accept established"
add chain=forward action=accept in-interface=ether1 protocol=icmpv6 limit=20,50:packet"
add chain=forward action=drop in-interface=ether1 protocol=icmpv6 comment="Drop ext ICMP >20/sec"
add chain=forward action=accept in-interface=!ether1 comment="Accept internal"
add chain=forward action=accept out-interface=ether1 comment="Accept outgoing"
add chain=forward action=drop in-interface=ether1 comment="Drop external"
add chain=forward action=reject comment="Reject everything else"

fonte: https://www.medo64.com/2022/01/getting-ipv6-going-on-routeros-7-1/

Read More

IPv6 - artigo muito bom

 

OpenWrt: Configurando IPv6 (6 anos depois)

Mais um artigo da série sobre o OpenWrt/LEDE.

O que motivou iniciar o uso do OpenWrt não foi os inúmeros recursos a mais que você pode fazer com ele. O real motivador foi que eu queria usar IPv6 na minha rede. Escrevi sobre isso em 2012. Acho que cabe retomar o assunto.

Na época, o IPv6 no OpenWrt era opcional. As operadoras entregarem IPv6 era lenda urbana, quando não queriam te "vender" o pacote extra IPv6. O acesso IPv6 era coisa de universidade. A única alternativa era criar um túnel (lento) para um broker IPv6. De lá para cá, muita coisa mudou.

Hoje, todas as operadoras que se consideram minimamente significativas oferecem IPv6 a seus clientes. Então, se você não tem IPv6, já sabe o nível da sua operadora. As operadoras já estão com falta de IPv4 faz um tempo, tendo que apelar para técnicas como CGN (NAT na operadora) que, basicamente, coloca uma NAT na frente da sua NAT. O problema é que a sua NAT você tinha um certo nível de controle, podendo abrir/encaminhar portas. Já a NAT da operadora... Isso quebra um monte de coisas que iriam conectar na sua casa (ex: torrent, VPN, Câmera IP...). Se sua operadora tem que usar CGN, mas ao menos entrega IPv6, é a vida. Procure migrar suas coisas para IPv6. Se ela usa CGN mas não entrega IPv6... ela é incompetente. Procure trocar de operadora.

No mundo do OpenWrt, o IPv6 melhorou muito. Hoje em dia, ele vem autoconfigurado para IPv6. O normal é ele funcionando tão bem quanto IPv4, sem a necessidade de qualquer configuração. Não precisa de pacotes extras, ele simplesmente sai funcionando.

Vamos a um básico IPv6. Primeiro, o endereço. O IPv4 usava 32-bit, que dava um pouco mais de 4 bilhões de endereços (2^32). Deste tanto, tinha que tirar algumas faixas reservadas, um tanto para equipamentos intermediários, endereço de rede, broadcast. No fim, temos endereços para bem menos do que 4 bilhões de equipamentos. E com 7 bilhões de pessoas no planeta, isso era insuficiente. No IPv6, o pessoal exagerou e resolveu aumentar de 32-bit para 128-bit. Fica um trambolho deste tamanho:

2001:db8:85a3:8d3:1319:8a2e:370:7348

Cada conjunto separado por ":" tem 16-bit, ou 65536 variações. Com dois destes poderíamos colocar a internet IPv4 inteira (e temos 8 aqui). Como os números começaram a ficar grandes, resolveram usar notação hexadecimal, que inclui os algarismos normais e as letras de A até F. Isto permite usar endereços legíveis engraçadinhos. Caso tenha uma sequência de zeros, usa-se a notação "::", mas somente uma vez no endereço.

Existem variações para endereços especiais, como multicast, link-local, mas no caso geral, o endereço IPv6 pode ser dividido em duas partes, cada uma com 64-bit. No exemplo anterior, seriam as partes verdes e azul. A verde é seu prefixo de rede, que identifica uma rede IPv6 no mundo. A parte azul é o identificador da interface. Para fazer a analogia com  algo que todos têm familiaridade, seria algo assim no IPv4 privado da sua rede atual:

192.168.3.131/24

Então, com IPv4 você normalmente trabalha com redes /24 com 254 endereços "livres". Com IPv6, no mínimo temos 18.446.744.073.709.551.616 (2^64). Para quê tudo isso? Bem, assim você pode usar o endereço MAC da sua placa (48-bit) e obter automaticamente um endereço sem chance de conflito. Esse é o método de obtenção de endereços sem estado (SLAAC). Funciona assim:

equipamento: olá! tem um roteador aí? Eu preciso de uma rede!

roteador: Oi, eu sou o roteador no endereço fe80::1234:1234:3214:1234. Eu ofereço o prefixo de rede 2001:db8:85a3:8d3::/64

E o equipamento começa a usar 2001:db8:85a3:8d3:1319:8a2e:370:7348 usando fe80::1234:1234:3214:1234 como roteador padrão. Sem mais nenhum passo. Sem nenhuma negociação ou confirmação.

Este endereço, apesar de parecer "aleatório", será sempre igual, claro, se mantido o prefixo de rede. Equipamentos mais simples (IoT) podem só funcionar desta forma. E o DNS? Esse pode vir pelo serviço RDNSS, que vem junto com a resposta do roteador. Mas nem todos os clientes e roteadores suportam isso.

E não tem DHCPv6? Tem sim. Ele funciona de uma forma bem parecida com DHCPv4, mas pode tanto gerar os endereços dos clientes da mesma forma que o SLAAC ou da forma tradicional do IPv4: alocando de uma faixa de endereços (que podem ser fixados).

O prefixo de rede ainda pode ser dividido em duas partes: prefixo de roteamento e um identificador de subrede. O prefixo de roteamento é o que identifica todas as redes gerenciadas pelo seu roteador. Então, qualquer rede "acessível globalmente" no seu roteador compartilha essa parte inicial. O que sobra até atingir os 64-bit é usado pelo seu roteador para subdividir a rede em múltiplas redes locais. 

Vamos ao OpenWrt.

Ao ligar o OpenWrt, ele cria aleatoriamente um endereço de rede local (ULA). Sim, o recomendado é ser aleatório mesmo. Esse endereço é um /48 e sempre começa com "fd". Ex:

fdab:1234:1343::/48

Você pode ver (ou modificar) este endereço na aba "network/interfaces", lá no final. Isto seria equivalente a sua rede privada 192.168.1.0/24 do IPv4. Diferentemente do IPv4, eu não recomendo que mude este valor. 

O OpenWrt usa o "prefixo de roteamento" fdab:1234:1343:: e adiciona um identificador de subrede para formar uma rede final, normalmente de tamanho /64, mas pode ser modificado pela opção "ip6assign". E de onde ele pega identificador de subrede? Do campo "ip6hint". Se não definido, ele usa zero. Para o endereço anterior, ficaria:

fdab:1234:1343::/64

Mas é igual? Não! Agora tem um monte de zeros até chegar ao /64. De 48 para 64 são 16-bit ou 4 algarismos/letras em hexadecimal. Seria igual a isso:

fdab:1234:1343:0000::/64

Onde o magenta é o identificador da subrede. Se ele fosse "12", o resultado seria:

fdab:1234:1343:0012::/64

Simples? Por enquanto estamos só na rede local. O DHCPv6 pode ser configurado no mesmo local onde era configurado o IPv4, ao final da edição de cada interface. Lá você pode configurar se o roteador se anunciará como roteador (para SLAAC), se terá DHCPv6 e qual modo de endereços será distribuído pelo DHCPv6: SLAAC, por atribuição ou ambos. 

E como ficariam os endereços de rede? O OpenWrt normalmente usa o identificador de rede ::1 para si. Então, na subrede fdab:1234:1343:123A::/64, ele ficaria com:

fdab:1234:1343:0012::1/64

Mas o "::1" pode ser modificado pelo campo ip6ifaceid. E uma máquina na rede? Se ela tiver o endereço MAC 11:22:33:44:55:66, por SLAAC ela teria o endereço:

fdab:1234:1343:0012:1322:33ff:fe44:5566/64

Note que o MAC sofre uma pequena alteração, mas ele é visível no endereço. E se for por atribuição DHCPv6, será dinâmico (com relativa estabilidade) como no DHCPv4. E se eu quiser fixar? Assim como a interface tem o atributo "ip6ifaceid", a entrada DHCP onde você fixa o IPv4 terá um campo "hostid" (na interface WEB está como "IPv6-Suffix") onde você pode preencher o que quiser lá (até 64-bit ou 16 algarismos hexadecimais). Se for "cafe", o endereço ficaria:

fdab:1234:1343:0012::cafe/64

Pronto. Temos uma rede local que fala IPv6. Isto vai estar disponível em qualquer OpenWrt recente, mesmo que sua operadora não ofereça IPv6. Os endereços fd00::/8 não são (normalmente) roteáveis para a internet. Só devem ser usados dentro da sua rede doméstica ou corporativa.

Agora vamos falar com a Internet.

O básico de um roteador é ter uma interface WAN e uma ou mais LAN. Normalmente o endereço WAN IPv6 é obtido por DHCPv6 (ex: NetVirtua) ou por PPPoE/PPPoA (ex: Oi). Como é um protocolo diferente do IPv4, no OpenWrt é necessário usar uma segunda interface (ex: wan6) que utiliza o mesmo dispositivo físico da wan IPv4. Por padrão, ele já vem com uma wan6 configurada como DHCPv6, que resolve em grande parte dos casos.

O que muda do DHCPv4? Na requisição do DHCPv6, além de pedir um endereço para a interface WAN, existe um pedido de um campo adicional chamado de "prefixo de rede delegada" (Prefix Delegated - PD).  Você receberá da sua operadora um endereço WAN para seu roteador e um prefixo de rede com endereços reais (globais) para distribuir dentro da sua rede. O tamanho do prefixo solicitado pode ser modificado pelo campo "reqprefix", mas as operadoras não vão respeitar mesmo. Você receberá algo como:

IPv6 WAN: 2804:14d:baba:1000::17d7/64

IPv6 prefixo delegado: 2804:14d:baba:1f00::/56

Se a WAN IPv6 utilizar endereço IP fixo, você pode informar a rede delegada manualmente.

O que o OpenWrt faz com isso? O IPv6 WAN é usado para a interface WAN. Ele pode ser, inclusive um /128. Já o prefixo delegado é distribuído para todas as LANs internas. Da mesma forma que ocorreu com a  rede ULA, ele utilizará o prefixo roteado em conjunto com o identificador da subrede para criar prefixos de rede para cada rede interna. No exemplo, a operadora ofereceu um prefixo /56 (ex: Oi ADSL residencial), que permitiria subdividi-lo em 256 redes. É o suficiente para uma residência ou mesmo para um pequeno negócio.

( Bem, tem algumas operadoras que entregam apenas um /64 para seus clientes. Sim NetVirtua, estou apontando para você. Pode ser trauma da escassez de IPv4 mas não se justifica no mundo IPv6. Até a Oi, que normalmente não é usada como bom exemplo, oferece uma rede /56. Com uma rede /64, eu não tenho espaço para subdividir a rede em múltiplas redes LAN e ainda usar SLAAC. Isto quer dizer que não tenho como criar uma segunda LAN com IPv6. Mas quem precisa de duas LAN? Isso é coisa de empresa! Claro, o vizinho que eventualmente fez uma visita e precisou conectar na Wifi aqui em casa jamais irá enviar um vídeo por engano ao meu Chromecast, nem mesmo irá olhar sem querer na babá eletrônica... realmente a segunda rede é desnecessária. Não preciso dizer qual foi a resposta do Call Center da Net. Mas voltando... )

Com as redes do exemplo, a LAN do roteador passa a ter estes dois endereços:

fdab:1234:1343:0012::1/64

2804:14d:baba:1f12::1/64

E a máquina que tem o endereço MAC 11:22:33:44:55:66? Se usar tanto o SLAAC como o sufixo "cafe", teremos todos estes endereços configurados:

fdab:1234:1343:0012:1322:33ff:fe44:5566/64

fdab:1234:1343:0012::cafe/64

2804:14d:baba:1f12:1322:33ff:fe44:5566/64

2804:14d:baba:1f12::cafe/64

E para cada outra LAN no roteador, basta configurar o campo ip6hint dela com um identificador diferente das demais LAN e ela receberá seu cunhão de endereços automaticamente.

E se não tiver espaço para uma segunda LAN? O que posso fazer? E se minha operadora não entregar um prefixo delegado? Infelizmente, ainda temos a alternativa de usar NAT66 (NAT entre duas redes IPv6).

Beleza. Acabei de olhar a interface do meu computador e tem esses quatro endereços aí e mais um monte! Sim, temos ainda endereços usados apenas no contexto do enlace local (link-local), que começam com "fe80". Ele seria equivalente ao famigerado 169.254.0.0/24 do IPv4.

fe80::1322:33ff:fe44:5566/64

Este endereço normalmente nem responde aos serviços de rede normais. Ele é usado para as tarefas administrativas do IPv6, como encontrar um outro equipamento na mesma rede ou o seu roteador. É necessário.

Mas tenho muito mais endereços! Bem, o endereço MAC não é algo muito "mutável" nas máquinas. Como ele começou a fazer parte do endereço visível na internet, ficou fácil rastrear os equipamentos que usam SLAAC. Mesmo que você mude o prefixo, o final sempre será o mesmo. Com isso você obtem o MAC e individualiza o computador. Solução? Uma extensão de privacidade. Além de todos os endereços listados anteriormente, a máquina pode periodicamente criar novos endereços com o identificador de interface (parte verde) aleatória. Quando usada a extensão de privacidade, o endereço SLAAC fixo é usado para receber conexões que queiram se conectar no computador enquanto os endereços aleatórios são usados pelo computador para acessar serviços remotos. Depois de um tempo, o endereço aleatório é desativado e outro é criado. Com isso, o serviço remoto não tem como rastrear o equipamento apenas pelo endereço de origem. Se deixar um computador que usa a extensão de privacidade muito tempo ligado, é normal ver uma lista mais de uma dezena de endereços IPv6.

E tem mais assuntos IPv6? Tem! Firewall IPv6, NAT66 (sim, NAT para IPv6 as vezes é necessário), multihoming (duas WANs), VPN sobre IPv6, e assim por diante. Mas isso fica para outro artigo.

Se pintar uma dúvida, temos o fórum.

fonte: http://luizluca.blogspot.com/2018/04/openwrt-configurando-ipv6-6-anos-depois.html

comentario:

Estamos na porta de 2021, gente trabalhando em casa, home office cada vez mais comum, e esses demônios de operadora só oferecem /64. Vivo fibra ótica, Net/Claro mesma coisa. Só a Oi que oferece /56, mas aí eles não oferecem fibra ótica onde moro!

Read More

IPv6 - EUI64 conversao

http://www.dltec.com.br/blog/cisco/descubra-o-endereco-ipv6-de-link-local-eui-64-sem-usar-calculadora/

http://labcisco.blogspot.com.br/2013/10/endereco-ipv6-e-funcao-eui-64-no.html

Read More

IPv6 - BGP

IPv4 BGP vs IPv6 BGP

BGP is older than IPv6. Even BGP-4, the version we still use today, predates IPv6: the first BGP-4 RFC (RFC 1654) was published in July 1994, while RFC 1883, the first IPv6 RFC, wasn’t published until December 1995. And unlike protocols like RIP and OSPF, which have separate versions for IPv4 and IPv6, there’s only one BGP: BGP-4 handles both IPv4 and IPv6. (And VPNs, MPLS and more.)
A little magic is required to let a 21-year-old routing protocol carry routing information for a 19-year-old network protocol: that would be the Multiprotocol Extensions. These turn regular BGP-4 into Multiprotocol BGP (MP-BGP), although that term is rarely used these days. The Multiprotocol Extensions, originally published as RFC 2283 in 1998, use some clever encoding to allow BGP-4 to carry a wide range of “address families”.
Usually, an address family identifies a network protocol, but there are also AFI (address family identifier) numbers given out for phone numbers and DNS names, which don’t map directly to a network protocol. In addition to the AFI, MP-BGP also uses a Subsequent Address Family Identifier (SAFI), which indicates the use of regular unicast routing, multicast routing, distributing VPN information, and so on. For instance, AFI 1 with SAFI 2 means BGP will carry IPv4 multicast routing information, and AFI 2 with SAFI 1 specifies IPv6 unicast routing information.
BGP routers that support IPv6 allow BGP sessions to be set up using IPv6 addresses. MP-BGP speakers tell their neighbors which AFI+SAFI combinations they want to use in the OPEN message at the beginning of a BGP session. This can lead to the situation where IPv6 routing information is exchanged over IPv4, or IPv4 routing information is exchanged over IPv6. In principle, there’s nothing wrong with that, but it does lead to a complication: how does the router know what IPv6 next hop address to include in its updates towards an IPv4 neighbor? To avoid this situation, it’s considered best practice to only exchange IPv4 prefixes over an IPv4 external BGP (EBGP) session and only exchange IPv6 prefixes over an IPv6 EBGP session.
However, internal BGP (IBGP) doesn’t update the next hop address, so there are no problems exchanging both IPv4 and IPv6 prefixes over the same IBGP session. So most networks use the existing IPv4 IBGP sessions to exchange IPv6 prefixes rather than set up a whole new set of IPv6 IBGP sessions. The only downside of this approach is that if then something bad happens to IPv4, the IPv4 IBGP sessions go down and IPv6 is also affected. If IPv6 had its own IBGP sessions, it may have continued to operate independently from IPv4.
All this comingling of IPv4 and IPv6 within BGP does make configuring a router a bit more complex. This is what a simple BGP configuration on a Cisco router looks like in an IPv4-only world:

!
router bgp 64512
network 172.16.0.0 mask 255.240.0.0
neighbor 192.0.2.2 remote-as 65500
neighbor 192.0.2.2 description My favorite BGP neighbor
neighbor 192.0.2.2 prefix-list outfilter out
neighbor 192.0.2.2 filter-list 1 out
!
ip as-path access-list 1 permit ^(64512_)*$
ip prefix-list outfilter permit 172.16.0.0/12
!

A BGP configuration that does the same thing for IPv6 looks like this:

!
router bgp 64512
neighbor 2001:db8:c0f:fee::6:5500 remote-as 65500
neighbor 2001:db8:c0f:fee::6:5500 description My favorite BGP neighbor
!
address-family ipv6 unicast
neighbor 2001:db8:c0f:fee::6:5500 activate
neighbor 2001:db8:c0f:fee::6:5500 prefix-list outfilter out
neighbor 2001:db8:c0f:fee::6:5500 filter-list 1 out
network 3ffe::/16
!
ip as-path access-list 1 permit ^(64512_)*$
ipv6 prefix-list outfilter permit 3ffe::/16
!

So the settings that are the same for both IPv4 and IPv6 (most notably the remote AS number, but also the description) are configured immediately following the “router bgp …” line, but anything IPv6-specific is grouped under “address-family ipv6”. (Or “address-family ipv6 unicast”.) Obviously, the IPv6 prefixlist goes under the IPv6 settings, but the same applies to the IP AS path access list: you may want to apply different AS path filters to IPv4 and IPv6. Things get interesting when we merge both configurations. If we then display the router configuration, it will look something like this:

!
router bgp 64512
neighbor 2001:DB8:C0F:FEE::6:5500 remote-as 65500
neighbor 2001:DB8:C0F:FEE::6:5500 description My favorite BGP neighbor
neighbor 192.0.2.2 remote-as 65500
neighbor 192.0.2.2 description My favorite BGP neighbor
!
address-family ipv6
neighbor 2001:DB8:C0F:FEE::6:5500 activate
neighbor 2001:DB8:C0F:FEE::6:5500 prefix-list outfilter out
neighbor 2001:DB8:C0F:FEE::6:5500 filter-list 1 out
network 3FFE::/16
exit-address-family
!
address-family ipv4
no neighbor 2001:DB8:C0F:FEE::6:5500 activate
neighbor 192.0.2.2 activate
neighbor 192.0.2.2 prefix-list outfilter out
neighbor 192.0.2.2 filter-list 1 out
network 172.16.0.0 mask 255.240.0.0
exit-address-family
!

So what has happened is that the router decided that now that we’re using an IPv6 address family, we need to be more specific about our IPv4, too, and moved all the IPv4-specific configuration commands to a new “address-family ipv4” section.
Also note how neighbors are deactivated for IPv4 and activated for IPv6, as exchanging IPv4 prefixes and not exchanging IPv6 prefixes are the default behavior—even for BGP sessions towards an IPv6 neighbor. However, these defaults may not be universal across software versions and different BGP implementations that use Cisco-like configuration commands, so it’s best to always explicitly activate and deactivate all IP version combinations, with the exception of activating IPv4 for IPv4.
Old Cisco IOS versions curiously used show bgp for IPv6 wherever show ip bgp was used for IPv4. Later this was changed to show bgp ipv6 and after that to show bgp ipv6 unicast . (And show ipv4 unicast can be used for IPv4.)
The minimum prefix size that you’ll see in IPv6 is /48, which is the size of provider independent address blocks. ISPs get at least a /32. The IPv6 routing table is much smaller at some 21,000 prefixes while the IPv4 global routing table is well over half a million prefixes. But with the above in mind, there’s really no fundamental difference between how BGP works for IPv4 and IPv6. IPv6 is still IP, after all.

Boost BGP Preformance

Automate BGP Routing optimization with Noction IRP

fonte: https://www.noction.com/blog/ipv4_bgp_vs_ipv6_bgp

links:  http://aconaway.com/2011/02/10/routing-ipv6-with-bgp-the-basics/
           https://majornetwork.net/2013/04/configuring-bgp-sessions-in-ipv6/

Read More

IPv6 - Tools links

https://getipv6.info/display/IPv6/Troubleshoot+IPv6+Issues

Read More

IPv6 - Windows não aceita DNS via stateless

http://techgenix.com/ipv6-windows-admins-part4/

--- endereços temporarios

http://www.netadm.com.br/desabilitando-enderecos-ipv6-nao-temporarios-randomicos-e-voltando-a-utilizar-o-padrao-eui-64-no-windows/

Read More

IPv6 - Configurando 6to4 no MikroTik para uma rede inválida

O ambiente de teste utiliza-do foi com um modem Velox roteado, um Router Board MikroTik RB433, um notebook e o Tunnel Broker (Hurricane Electric).

Configurações de IPs

 - Modem: 192.168.1.1

 - Mikrotik: 192.168.1.254

Primeiramente precisamos configurar o IP do Mikrotik na zona DMZ (Zona Desmilitarizada) do modem roteado. Assim todas as conexões ao ip válido do modem serão redirecionadas para o mikrotik.

Em seguida loga-se no site Tunnel Broker (tunnelbroker.net) para poder criar o túnel 6to4.

Clique no menu esquerdo em "Create Regular Tunnel" e cadastre o ip válido do modem (www.meuip.com.br)

Pronto, a configuração no lado servidor do túnel 6to4 esta criado. Agora falta o lado cliente.

Clique em "Example Configurations" e selecione "Mikrotik"

Ex.:

/interface 6to4 add comment="Hurricane Electric IPv6 Tunnel Broker" disabled=no local-address=201.58.125.113 mtu=1280 name=sit1 remote-address=209.51.161.58

/ipv6 route add comment="" disabled=no distance=1 dst-address=2000::/3 gateway=2001:470:4:818::1 scope=30 target-scope=10

/ipv6 address add address=2001:470:4:818::2/64 advertise=yes disabled=no eui-64=no interface=sit1

Agora abra o "winbox" e conecte no Mikrotik. Certifique-se que os pacotes IPv6 estão ativados indo no menu "System" -> "Packages".

Vá em "New Terminal" e execute as três linhas oferecidas pelo site Tunnel Broker.

Para fechar o túnel atrás de um NAT deve-se alterar o IP local do túnel. Para isso no menu "Interfaces" e edite o túnel "sit1", trocando o ip "Local Address" para o ip do mikrotik (192.168.1.254).

Para testar se o túnel foi fechado, localise o ip do Server IPv6 no site tunnel broker e tente fazer o ping através do mikrotik

Ex.: Server IPv6 Address: 2001:470:4:818::1/64

No mikrotik vá em "Tools" -> "Ping", preencha o ip e start. O status retornado deve ser "echo reply".

Verifique no site do Tunnel Broker qual é a sua Rede.

Ex.: Routed /64: 2001:470:5:818::/64

No mikrotik vá em "IPv6" -> "Addresses" e cadastre um ip, dentro da rede recebida, para o seu mikrotik na interface onde estarão os clientes.

Ex. 2001:470:5:818::1/64

No computador cliente verifique se o IPv6 foi configurado automaticamente. Caso não seja configurado automaticamente configure com o ip e gateway dentro da rede recebida.

Ex.:

 IP: 2001:470:5:818::2

 Mascara: 64

 Gateway: 2001:470:5:818::1

No site Tunnel Broker verifique os ips de DNS para serem colocados nos clientes e configure os dns dos clientes.

Ex.:

Anycasted IPv6 Caching Nameserver: 2001:470:20::2

Anycasted IPv4 Caching Nameserver: 74.82.42.42

Agora abra a console no cliente e tente pingar o endereço:

> ping6 ipv6.google.com

Acesse o site http://www.ipv6.br/ , verifique no topo da página se o IPv6 aparece e se o globo no lado direito da tela esta girando.

Referências:

• http://www.bitabit.eng.br/2011/02/03/conectividade-ipv6-em-casa-%E2%80%93-parte-1/
• http://tunnelbroker.net/
• https://sites.google.com/site/silviogarbes/sistemas/redes/mikrotik/ipv6---configurando-6to4-no-mikrotik-para-uma-rede-invalida

Read More