Resumo

  • A RFC 4012 manteve import, export e default no escopo IPv4 unicast e acrescentou atributos mp-* com seleção por família.
  • Nos atributos novos, omitir a cláusula AFI significa any para unicast e multicast de IPv4 e IPv6; não significa “nenhuma família”.

Uma AFI ausente não era um campo em branco

Ao encontrar um mp-import sem cláusula afi, alguém poderia concluir que a família não foi indicada. A RFC 4012 determina o contrário: a omissão vale any, um escopo definido que abrange IPv4 unicast, IPv4 multicast, IPv6 unicast e IPv6 multicast. A palavra não aparece na linha, mas a regra continua lá. O leitor ou analisador não deve preencher a lacuna por conta própria.

Esse padrão só vale para os novos atributos mp-*. import, export e default continuam com seu sentido anterior de IPv4 unicast. A compatibilidade fica preservada sem deixar a nova expressão multiprotocolo semanticamente vazia. Antes de interpretar a política escrita, o primeiro passo é entender o que a gramática atribui ao escopo quando ninguém escreveu afi.

De um vocabulário de unicast IPv4 a um modelo multiprotocolo

Em 1999, a RFC 2622 definiu o RPSL para descrever políticas de roteamento unicast IPv4. import, export e default tinham sentido dentro desse escopo. Publicada em março de 2005, a RFC 4012 estendeu o modelo a IPv6 e multicast, procurando preservar a compatibilidade com o que já existia. RFC 2622 RFC 4012

Os atributos antigos continuaram significando unicast IPv4. Para descrever políticas multiprotocolo, surgiram mp-import, mp-export e mp-default, acompanhados de uma cláusula afi que pode identificar ipv4.unicast, ipv4.multicast, ipv6.unicast ou ipv6.multicast, entre outros escopos. Quando a cláusula opcional é omitida num atributo mp-*, a RFC 4012 define o alcance como any, cobrindo as quatro famílias. Isso especifica como interpretar a declaração; não garante suporte ou adoção no equipamento. RFC 4012, seções 2.1 a 2.5

Essa escolha evita supor que uma política escrita para IPv4 possa ser reaproveitada sem distinção. O registro consegue dizer com mais precisão a que família se refere. A rede continua podendo operar filtros, vizinhanças e decisões diferentes para IPv4 e IPv6.

O vocabulário também combina escopos: ipv4 e ipv6 abrangem unicast e multicast de cada versão; any.unicast e any.multicast reúnem o mesmo tipo de tráfego nas duas; any é a união das quatro combinações básicas. A concisão vem de nomear essas uniões, não de deixar o alcance implícito.

A mesma sigla AFI, em camadas diferentes

A RFC 4012 também acrescentou a classe route6, mas a chave desse objeto e a autorização de mudanças são questões distintas da cláusula AFI opcional; a RFC 2725 trata dessa autorização. Aqui, ela apenas marca um limite, sem abrir uma segunda tese. RFC 4012, seção 3 RFC 2725

O BGP também usa AFI/SAFI, mas a RFC 4760 os associa ao alcance de rede e ao próximo salto em mensagens UPDATE. A AFI opcional da RFC 4012 delimita uma expressão de política em RPSL. A sigla comum não torna essas declarações intercambiáveis; a seleção de rotas e os anúncios por vizinho pertencem ao funcionamento descrito pela RFC 4271. RFC 4271 RFC 4760

As uniões nomeadas tornaram a gramática combinável

Dizer que o RPSL passou a descrever IPv6 é correto, mas incompleto. A RFC 4012 tornou explícito o alcance por família e nomeou as uniões entre versões e tipos de tráfego. Isso descreve a linguagem, não a adoção uniforme das duas versões.

Essa precisão importa numa rede dual-stack. As políticas de vizinhança, filtragem e anúncio podem diferir por família. afi ipv6.unicast e afi any não dizem a mesma coisa. Ainda assim, nem a expressão mais clara resolve qual política o AS carregará nos equipamentos.

A RFC 8212, publicada em 2017, oferece um marco cronológico posterior: exige política explícita para EBGP, mas trata do comportamento do BGP e não altera a interpretação da RFC 4012 quando a AFI é omitida no RPSL. RFC 8212

As Notas 65 e 64 de Lu Heng orientam a leitura editorial: a camada comum deve corresponder ao que os sistemas precisam para interoperar, e mudanças só ganham efeito quando participantes as adotam. Não se trata de atribuir essas ideias aos autores da RFC 4012. A distinção ajuda a enxergar o limite: o RPSLng melhora a descrição compartilhada; o sistema que roda BGP decide o que efetivamente carrega e anuncia. Nota 65 Nota 64

As fontes não informam uma taxa de adoção do RPSLng, a completude dos registros nem a implantação atual de IPv6 por qualquer operador. A conclusão sustentada é mais contida: a RFC 4012 tornou a política documentada mais expressiva; para saber o que ocorreu na rede, é preciso observar sua configuração e o estado BGP.

Fontes primárias