segunda-feira, 30 de setembro de 2013

Cisco Networking Academy Promove Webinar Sobre IPv6

Olá Pessoal.

Nos dias 01/out (terça-feira) e 03/out (quinta-feira), das 11h às 15h, o Programa Cisco Networking Academy estará promovendo dois webinars sobre IPv6 exclusivos para seus instrutores no Brasil e demais países de língua portuguesa. O objetivo do webinar é fornecer aos instrutores ferramentas necessárias para sua atualização nos conteúdos do curso CCNA R&S com base no novo currículo 5.0, já que a maior cobrança pelo tópico IPv6 passa a ser uma mudança bastante significativa. 

Eu e outros dois colegas instrutores fomos escalados para conduzir as apresentações, sendo que todos os slides que serão utilizados no evento foram baseados no conteúdo do meu livro recém-lançado intitulado "IPv6 - O Novo Protocolo da Internet", afinal a obra possui a chancela "IPv6 Forum Officially Certified Guide" em países de língua portuguesa.


Todos os instrutores do Programa Cisco Networking Academy são estimulados a participar dos webinars. As apresentações serão distribuídas entre os dois dias da seguinte maneira:

|******
| Dia 1 - 01/10/2013 (terça-feira)
|
| Part 1: Flávio Provedel e Rodrigo Floriano (Cisco NetAcad)
| Opening Address
| CCNA R&S Pedagogy Changes (20min)
| CCNA R&S Update (20min)
| Break (10min)
|
| Part 2: Samuel Henrique Bucke Brito
| Introducing Basic IPv6 (30min)
| Understanding IPv6 - Addressing & Subnetting (20min)
| Break (10min)
|
| Part 3: Gerson Castro
| Understanding IPv6 - Addressing & Subnetting (50min)
| Break (10min)
|
| Part 4: Samuel Henrique Bucke Brito
| Understanding IPv6 - Addressing & Subnetting (50min)
|******

|******
| Dia 2 - 03/10/2013 (quinta-feira)
|
| Part 5: 
| Packet Tracer 6.0.1 (30min), Rodrigo Floriano
| IPv6 Headers (15min), Edson Soares Ferreira
| Break (10min)
|
| Part 6: Edson Soares Ferreira
| Understanding IPv6 - Neighbor Discovery (45min)
| Break (10min)
|
| Part 7: Gerson Castro
| Understanding IPv6 - Routing (45min)
| Break (10min)
|
| Part 8: Samuel Henrique Bucke Brito
| Implementing Single Area OSPFv3 (20min)
| Configuring IPv6 ACL (30min)
|******

Os links para registro nas sessões que serão transmitidas online via WebEx são:

Sessão do Dia 1:

Sessão do Dia 2:

Abraço.

Samuel.

segunda-feira, 23 de setembro de 2013

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.

domingo, 15 de setembro de 2013

Private VLAN na Segurança e Particionamento de VLANs

Olá Pessoal.

As VLANs são comumente utilizadas para quebrar os domínios de broadcast em grandes redes de computadores, o que é muito desejável para dois fins principais: (i) desempenho e (ii) segurança. Quando algumas portas de um (ou mais) switch(es) são colocadas em uma determinada VLAN os quadros de broadcast originados por uma máquina ficam restritos somente a essas portas, o que implica em melhor desempenho decorrente da presença de menos máquinas gerando broadcasts. Outra vantagem do ponto de vista de segurança é que deixa de existir a possibilidade de alcançabilidade entre outras portas que não sejam membros da mesma VLAN na camada de enlace.

Embora a principal funcionalidade das VLANs seja segmentar os domínios de broadcast, há algumas situações específicas em que pode ser necessário particionar uma dada VLAN para que, por exemplo, algumas portas de uma VLAN tenham acesso a apenas algumas outras portas da mesma VLAN, ao invés de ter acesso a todas as porta da sua respectiva VLAN. Esse é um requisito de segurança comum em alguns ambientes, a exemplo de server-farms onde ficam localizados os servidores da empresa. 

Nesse contexto, é muito comum que os servidores de uma empresa tenham sua própria sub-rede (layer-3) associada com uma respectiva VLAN (layer-2), de forma que os acessos dos hosts aos servidores tenham que passar pelas políticas de segurança impostas pelos roteadores com função de firewall. Acontece que, ainda assim, caso haja alguma vulnerabilidade na rede e alguém consiga acesso não autorizado a qualquer um dos servidores, então provavelmente será fácil, a partir dele, acessar qualquer outro servidor da server-farm porque existe uma relação "natural" de confiança (nem sempre desejável) entre os servidores que pertencem à mesma VLAN e sub-rede.

Para evitar esse tipo de situação é conveniente do ponto de vista de segurança que os servidores não tenham alcançabilidade entre si no mesmo domínio de broadcast, mesmo que pertençam à mesma VLAN. É impossível fazer isso através de VLANs convencionais, mas esse cenário pode ser implementado em switches Catalyst e Nexus da Cisco através da configuração de Private VLANs.

Em muitos casos não há necessidade de comunicação dos servidores entre si, o que faz desses servidores bons candidatos a serem totalmente isolados em suas VLANs. Em outros casos é necessário que haja comunicação entre os servidores, por exemplo em clusters onde os nós trocam mensagens entre si com frequência para manter a abstração do cluster como sendo uma máquina "única" composta por todos os seus nós que executam a solução de clusterização (middleware). Então vamos observar a figura abaixo para enxergar essas diferentes possibilidades e para entender de que forma a Private VLAN pode ser bastante desejável.


Na configuração de "Private VLANs" somente pode existir  uma única VLAN primária que, por sua vez, pode ser vinculada a várias VLANs secundárias. As VLANs secundárias podem ser de dois tipos: (i) community ou (ii) isolated. Uma VLAN secundária do tipo community é aquela em que suas portas podem se comunicar apenas umas com as outras e também com a VLAN primária. Já as portas de uma VLAN secundária do tipo isolated não podem se comunicar entre si e só conseguem alcançar a VLAN primária.

Na figura temos uma VLAN primária que possui dois sub-domínios vinculados à ela (círculo amarelo), sendo uma do tipo isolated onde os servidores não conseguem se comunicar entre si (círculo azul) e outra do tipo community onde precisa haver comunicação entre as portas para que os servidores possam trocar mensagens e formar um cluster (círculo rosa).

A associação das portas de um switch que irão utilizar o recurso da "Private VLAN" não é tão direta quanto as associações convencionais de portas e VLANs que era realizada através do comando "switchport access vlan X".  Essa configuração é diferente porque agora as portas podem assumir dois modos: (i) promiscuous ou (ii) host.

A porta configurada em modo promíscuo normalmente é aquela em que é conectado o roteador/firewall que é o gateway das máquinas, afinal essa porta pode se comunicar com qualquer outra porta na VLAN primária ou em suas respectivas VLANs secundárias, sejam elas community ou isolated. A porta é configurada em modo host quando conecta uma máquina regular porque somente pode se comunicar com portas em modo promíscuo na VLAN primária ou com outras portas da sua VLAN secundária, desde que essa VLAN secundária seja do tipo community.

Para exemplificar como seria o processo de configuração vamos utilizar como base o cenário da figura acima, onde estaremos assumindo que a VLAN 10 será primária, que a VLAN 20 será secundária do tipo isolated e que a VLAN 30 será secundária do tipo community. Estaremos assumindo que a interface g1/1 do switch está conectada ao roteador que é gateway dos servidores, enquanto que as interfaces f0/1, f0/2 e f0/3 conectam os servidores do cluster da VLAN 20 e as interfaces f0/4, f0/5 e f0/6 conectam os servidores isolados da VLAN 30.

01. Switch(config)# vlan 20
02. Switch(config-vlan)# name "VLAN do Cluster"
03. Switch(config-vlan)# private-vlan community
04. Switch(config-vlan)# vlan 30
05. Switch(config-vlan)# name "VLAN dos Servidores Isolados"
06. Switch(config-vlan)# private-vlan isolated
07. Switch(config-vlan)# vlan 10
08. Switch(config-vlan)# name "VLAN Primaria"
09. Switch(config-vlan)# private-vlan primary
10. Switch(config-vlan)# private-vlan association 20,30
11. Switch(config-vlan)# exit
12. Switch(config)# interface range f0/1 - 3
13. Switch(config-if-range)# switchport mode private-vlan host
14. Switch(config-if-range)# switchport private-vlan host-association 10 20
15. Switch(config-if-range)# interface range f0/4 - 6
16. Switch(config-if-range)# switchport mode private-vlan host
17. Switch(config-if-range)# switchport private-vlan host-association 10 30
18. Switch(config-if-range)# interface g1/1
19. Switch(config-if)# switchport mode private-vlan promiscuous
20. Switch(config-if)# switchport private-vlan mapping 10 20,30

Na configuração acima criamos primeiro as VLANs secundárias, sendo a VLAN 20 do tipo community (linhas de 01 a 03) e a VLAN 30 do tipo isolated (linhas de 04 a 06). Na sequência criamos a VLAN 10 do tipo primária e já informamos o vínculo com suas VLANs secundárias (linhas de 07 a 10). Nas linhas de 12 a 14 associamos as interfaces f0/1, f0/2 e f0/3 em modo host com a VLAN 20 (cluster), sendo que o primeiro número que aparece no comando é menção à VLAN primária em que ela possui vínculo. O mesmo procedimento é feito nas linhas de 15 a 17 em relação às interfaces f0/4, f0/5 e f0/6 que pertencem à VLAN 30 (servidores isolados). Por fim, nas linhas de 18 a 20 configuramos a interface g1/1 em modo promíscuo na VLAN primária (e secundárias).

Para encerrar o artigo, é importante ter em mente que "Private VLANs" só existem no contexto local de um único switch e por isso não são propagadas através dos links trunk, devendo ser configuradas individualmente em cada switch no qual se estendem. Outro detalhe importante é que não são todas as versões do IOS que têm suporte a esse recurso, por isso convém pesquisar no site da Cisco!

Abraço.

Samuel.

sexta-feira, 6 de setembro de 2013

Palestras do Cisco Academy Day 2013

Olá Pessoal.

No dia 05/09 ocorreu o evento Academy Day 2013 organizado pela Cisco. O evento ocorreu simultaneamente em São Paulo e no Rio de Janeiro, sendo que as palestras realizadas no período noturno foram transmitidas online via Internet. Se você não pôde acompanhar as palestras por algum motivo, não há razão para ficar chateado! A gravação das palestras realizadas no evento já estão disponíveis e podem ser acompanhadas através do link logo abaixo da figura.


Vários dos participantes do evento (presencial e remoto) pediram pelos slides utilizados nas apresentações dos especialistas, por isso estou comparilhando abaixo os links para que vocês possam ter acesso aos materiais das apresentações.

- IPv6 na Internet e no Novo Currículo CCNA 5.0

- Tendências Tecnológicas em Redes das Operadoras de Telecomunicações

- Redes WiFi de Nova Geração

Abraço.

Samuel.

quarta-feira, 4 de setembro de 2013

Manipulação do STP na Otimização de Redes Layer-2

Olá Pessoal.

Em minhas aulas sempre costumo lembrar os alunos que a configuração das características de layer-2 (camada de enlace) em infraestruturas de redes é comumente deixada de lado por muitos profissionais da área pelo simples fato de switches serem dispositivos de natureza "plug-and-play", diferente de roteadores que requerem configuração preliminar para funcionar. Ou seja, basta ligá-los na tomada, esperar as luzes estabilizarem, e está tudo Ok! (Ah se fosse assim...)

No entanto, é um erro grave a presunção de que a natureza "plug-and-play" dos switches siginifica que não é necessário fazer nenhuma configuração nesses dispositivos. Ao contrário, há vários protocolos e configurações importantes na camada de enlace que devem receber atenção do profissoinal de infraestrutura porque comumente essa camada se torna um ponto comum de subotimização do desempenho em vista dos "relaxos" de configuração (ou desconhecimento) do administrador.

As características de layer-2 são extremamente importantes porque a tecnologia ethernet tem uma lógica de operação relativamente simplista, o que implica em desempenho ruim sem configurações específicas para melhorar seu comportamento padrão. Por exemplo, o simples fato de criar várias sub-redes layer-3 na sua empresa não quer dizer que você esteja otimizando o desempenho da sua rede porque no layer-2 continua existindo um único domínio de broadcast no qual serão propagados todos os quadros gerados, por exemplo, pelo ARP e DHCP - muito comuns nas redes atuais.

Costumo brincar em aula dizendo que o switch não é nem um pouco tímido porque qualquer encaminhamento que ele tenha que fazer e não saiba seu destino, então ele sai logo "gritando" para toda a rede (sem nenhuma vergonha) - esse é o efeito de broadcast tão ruim do ponto de vista de desempenho. No caso do exemplo anterior, é uma boa prática de projeto sempre associar uma VLAN (Layer-2) com cada Sub-Rede (Layer-3) para minimizar o efeito negativo dos broadcasts.

O objetivo desse artigo não é explicar o funcionamento das VLANS, mas falar um pouco sobre como otimizar o desempenho de redes layer-2 através da manipulação do comportamento do protocolo STP (Spanning-Tree Protocol). O STP (802.1d) e o rSTP (802.1w) são protocolos utilizados pelos switches para evitar a ocorrência de loops no caso de ligação redundante de links ou mesmo através da ligação entre switches de maneira a formar um circuito, ou seja, uma topologia que possa permitir o tráfego infinito de quadros em "círculos".

Vamos utilizar como exemplo a figura abaixo, em que temos dois switches de distribuição juntos para fins de disponibilidade conectados a um switch de acesso, um abordagem muito comum do ponto de projeto de redes. É comum os switches de acesso onde são conectados os dispositivos terminais ficarem localizados em mini-racks nas proximidades e serem conectados a ambos os switches de agregação naquilo que chamamos de camada de distribuição. Essa topologia acaba possibilitando a ocorrência de loops e para que isso não ocorra o STP entra em ação, também de maneira automática, bloqueando uma das portas. 


Parte da lógica do STP consiste na eleição de um switch raíz que ficará propagando quadros de controle (mensagem hello a cada 2 segundos) para os demais switches da rede depois que a topologia estiver estabilizada. Como caberá ao switch raiz a propagação dessas mensagens de controle em toda a infraestrutura layer-2, também é uma boa prática de projeto que esse switch seja bem escolhido no sentido de manter a simetria e o desempenho da rede, tendo, assim, a menor distância possível na propagação dessas mensagens entre os demais switches - o que otimiza o uso dos links. Nessa linha de raciocínio é sempre conveniente utilizar os switches das camadas superiores como raíz.

Reparem na figura que nenhuma porta, aparentemente, está sendo bloqueada porque todas estão com a indicação verde, ou seja, encaminhando! Se o STP é automático então uma das portas deveria ser bloqueada para evitar a ocorrência de loops, mas por que isso não aconteceu? A resposta é que isso não aconteceu porque eu mudei as configurações padrões do STP justamente para otimizar o desempenho da rede, permitindo que o tráfego das VLANs 10 e 20 seja distribuído entre os uplinks

Nesse cenário existem a VLAN-10 e VLAN-20 em todos os switches. O ASW está conectado através de sua interface f0/1 ao DSW1 e através de sua interface f0/2 ao DSW2 que, por sua vez, estão conectados entre si. Tenham em mente que o objetivo desse laboratório é mostrar a melhor configuração do STP, por isso não estamos preocupados com o fato de que os uplinks entre switches sejam apenas fast-ethernet (100Mbps). 

Uma primeira boa prática de projeto então seria configurar DSW1 ou DSW2 para que um seja o raíz da rede e outro seja seu backup. Isso poderia ser feito facilmente atribuindo a prioridade 0 para DSW1 e a prioridade 4096 para DSW2, lembrando que a prioridade padrão de switches é 32.768. Ok, então vamos imaginar que deixamos DSW1 como raíz e DSW2 como seu backup. Ao fazer isso todos os quadros originados na VLAN-10 e VLAN-20 em ASW seriam encaminhados apenas pela interface f0/1 (interface conectada ao switch raíz) porque sua interface f0/2 seria bloqueada para evitar loops. Seria melhor do ponto de vista de desempenho se pudéssemos utilizar ambos os uplinks para distribuir todo o tráfego e, ainda assim, em caso de falhas, teríamos a rede operacional. 

Pois bem, é por isso que estaremos tirando proveito do método PVST (Per VLAN STP) dos switches da Cisco para criar duas instâncias de topologias STP distintas, uma para a VLAN-10 e outra para VLAN-20. No contexto da VLAN-10 vamos configurar DSW1 para ser raíz e DSW2 seu backup, enquanto que no contexto da VLAN-20 vamos configurar DSW2 para ser raíz e DSW1 seu backup. Ao fazer isso, estaremos balanceando todo o tráfego das VLANs 10 e 20 entre os dois uplinks, conforme veremos nas saídas adiante. 

Apesar da descrição da solução parecer complicada a princípio, não é! Reparem que com apenas duas VLANs fica muito fácil visualizar logicamente as duas topologias distintas. As configurações de DSW1 e DSW2 irão ficar assim:

DSW1(config)# spanning-tree vlan 10 priority 0
DSW1(config)# spanning-tree vlan 20 priority 4096
**
DSW2(config)# spanning-tree vlan 10 priority 4096
DSW2(config)# spanning-tree vlan 20 priority 0

Com apenas essas configurações já conseguimos ter um ganho considerável de desempenho por causa do efeito de balanceamento porque quadros da VLAN-10 serão encaminhados pelo uplink da interface f0/1 de ASW, enquanto que quadros da VLAN-20 serão encaminhados pelo uplink da interface f0/2 de ASW. Observem nas saídas abaixo que para a VLAN-10 (destaque em amarelo) a interface f0/1 está em estado FWD (forwarding) e a interface f0/2 está em estado BLK (blocking). No contexto da VLAN-20 (destaque em azul) a situação é inversa, ou seja, a interface f0/1 está em estado BLK e a interface f0/2 está em estado FWD.

ASW#show spanning-tree vlan 10,20

VLAN0010
  Spanning tree enabled protocol ieee
  Root ID    Priority    10
             Address     000A.4148.08C5
             Cost        19
             Port        1(FastEthernet0/1)
             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    36874  (priority 36864 sys-id-ext 10)
             Address     0060.2F37.1B0D
             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  20

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/1            Root FWD 19        128.1    P2p
Fa0/2            Altn BLK 19        128.2    P2p
Fa0/10           Desg FWD 19        128.10   P2p

VLAN0020
  Spanning tree enabled protocol ieee
  Root ID    Priority    20
             Address     0001.6359.999D
             Cost        19
             Port        2(FastEthernet0/2)
             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    36884  (priority 36864 sys-id-ext 20)
             Address     0060.2F37.1B0D
             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  20

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/1            Altn BLK 19        128.1    P2p
Fa0/2            Root FWD 19        128.2    P2p
Fa0/20           Desg FWD 19        128.20   P2p

Apesar das configurações em si serem simples, o mais importante em relação ao STP e suas variações (rSTP 802.1w e MST 802.1s) é conhecer seu modus operandi para tirar proveito do melhor desenho de projeto que possa otimizar o desempenho da rede. Esse artigo é importante para reforçar aos profissionais da área de redes que, apesar de switches serem "plug-and-play", isso não quer dizer que não haja necessidade de configurá-los - um visão equivocada que pode custar caro no desempenho de uma rede.

Abraço.

Samuel.

segunda-feira, 2 de setembro de 2013

Perfil do Próximo Bilhão de Usuários da Internet

Olá Pessoal.

Desde 2006 o número de usuários na Internet praticamente dobrou, sendo que atualmente existem 2,4 bilhões de usuários conectados na grande rede. A estimativa é de que teremos 1 bilhão de novos usuários na rede até 2017, um número muito grande que evidencia ainda mais a importância da adoção do IPv6 na Internet em caráter de urgência.

Você alguma vez já se perguntou qual seria o perfil desses novos usuários da Internet? Recentemente fui contatado pela Shannon Hamilton, uma das pessoas responsáveis por conduzir um estudo para traçar o perfil do próximo 1 bilhão de usuários da Internet. Na oportunidade do contato ela me disse que seria interessante ter esses resultados compartilhados em português com os meus leitores.


A primeira conclusão faz todo sentido, os novos usuários irão utilizar dispositivos móveis, uma realidade sem volta. No último trimestre de 2012 foram vendidos mais de 207 milhões de novos smartphones, um número maior que a população do Brasil (quinto maior país do mundo)! Até 2017 espera-se que as conexões móveis cheguem a 8,2 bilhões!!! Aliás, um dos gráficos do estudo mostra que estamos prestes a ter mais conexões móveis na Internet do que aquelas originadas por desktops, uma informação que achei bem interessante.


Outro resultado do estudo mostra que 40% dos usuários dos EUA aceitariam de maneira positiva  a idéia de utilizar gadgets "vestíveis", ou seja, acoplados aos nossos corpos. Atualmente os mais comuns desses dispositivos são óculos e relógios, mas temos que ter a mente aberta e saber que são muitas as possibilidades com a chamada Internet das coisas - o que mais uma vez reforça a importância do IPv6!

Outro resultado natural do estudo é que a maior parte dos novos usuários serão dos países emergentes, como China, Índia, Indonésia, etc. Além da Ásia, a previsão é de que a África também deve ter um crescimento considerável - lembrando que a previsão de estogamento de endereços IPv6 na África é somente para 2020!!! O Brasil certamente é um dos países que está inserido nesse contexto.

Algumas das respostas trazidas no estudo parecem óbvias, mas acho que sempre é válido discutirmos dados numéricos para tentar entender o panorama futuro das coisas. Todos os dados trazidos nesse artigo foram reproduzidos a pedido (e sob autorização) da Shannon! A síntese original do estudo pode ser acessada na íntegra através do link: 


Abraço.

Samuel.