[GTER] IX - ATMv6 - Pacotes Broadcast(multicast) corretamente esperados

[Douglas Fischer]

Renan,
de cara eu confesso que até fiquei um tiquinho indignado com sua sugestão.
Mas lembrei da curca de Dunning-Kruger e voltei a dar uma olhada na rfc.
E agradeço a sugestão.

      Source Address
                     Either an address assigned to the interface from
                     which this message is sent or (if Duplicate Address
                     Detection is in progress [ADDRCONF
<https://tools.ietf.org/html/rfc4861#ref-ADDRCONF>]) the
                     unspecified address.



E a conclusão que cheguei é que continuo sem entender exatamente o que
acontece.


Eu me lembro de ter lido em alguma das RFCs relacionadas a IPv6 que a ordem
de precedência de escolha do endereço a ser utilizado é sempre do maior
escopo DISPONÍVEL para o menor...
 - 1º Global Address
 - 2º Unique Local Address
 - 3º Link-Local.
A não ser que as camadas superiores definam o endereço de origem.

Na prática, o que eu andei vendo na rede do IX (multi-vendor e bem
heterogênea)é que:
    (Informação baseada no EUI, mac pode ter sido clonado)
 - Os servers do NIC sempre usam Global Address como source para Neighbor
Solicitation.
 - A maioria dos Cisco e dos Huawei usam o Global Address como source para
N.S.
 - Uma pequena parte dos Juniper usam Global Address como source para N.S.
 - Praticamente todos os MK(routerboard) usam LinkLocal como source para
N.S.
   - Os que usam Global Address, acho que estão com mac clonado. TTL indica
isso.


E agora? Oque significa isso?
- Que nessa parte(qual source será usado) existe um ponto de livre escolha?
- Vendors que não estão em compliance com alguma das RFCs envolvidas?
- Existem configurações em cada vendor que colocariam isso dentro dos
conformes?



Em 9 de maio de 2018 09:55, Renan Menezes <renanitmanager at gmail.com>
escreveu:

> Bom dia Douglas,
>
> Dá uma olhada na RFC, talvez ela te esclareça sobre o que deve usar.
>
> https://tools.ietf.org/html/rfc4861
>
> Uma apostila muito bem elaborada é a do nic.br
> http://ipv6.br/media/arquivo/ipv6/file/48/IPv6-apostila.pdf [Página 91 do
> PDF]
>
>
> Em 9 de maio de 2018 00:43, Douglas Fischer <fischerdouglas at gmail.com>
> escreveu:
>
> > Em 29 de abril de 2018 20:32, Rubens Kuhl <rubensk at gmail.com> escreveu:
> >
> > > 2018-04-29 17:21 GMT-03:00 Douglas Fischer <fischerdouglas at gmail.com>:
> > >
> > > > Os participantes não deveriam estar emitindo esses pacotes
> > > > somente perguntando por destinos na Faixa Rede do ATMv6?
> > >
> > > Vale questionar neste caso se não é de gente que subiu sessão entre
> > > diferentes ASN no ATMv6 e quis assim. Talvez isso fosse mais apropriado
> > em
> > > VLANs entre participantes, mas não me parece tão grave se for esse
> mesmo
> > o
> > > caso.
> > >
> >
> > Além dos casos de participantes com Neighbor Solicitation com os Target
> em
> > LinkLocal(FE80)
> > (essa tá meio atravessada na garganta ainda)
> >
> > ​Constatei que existem:
> > a - participantes que fazem Neighbor solicitation usando origem
> > Global-Address
> > b - participantes que fazem Neighbor solicitation usando origem
> Link-Local
> >
> > Não consegui identificar nenhuma similaridade entre eles...
> > - Múltiplos vendors em cada uma delas.
> > ​- Acho que não ví Routeboard nos que usam Global-Address.​
> > ​- Creio que tudo que vi vindo de server do NIC.BR ​usava Global-Address
> > com origem da NS
> >
> >
> > ​Existe alguma lógica ou protocolo que define quando se usa Endereço
> Global
> > ou Link-Local para procurar MAC de um outro Neighbor?​
> >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação