Resumo

  • O RFC 5180 produz evidência sobre um perfil de laboratório declarado. Uma porta não é o chassi; IPv6 puro não é coexistência; quadro grande não é distribuição real; throughput não identifica sozinho o caminho de hardware ou software.
  • Para Hop-by-Hop, o método oferece 1%, 10% e 50% da banda e observa recursos, porque mede impacto de processamento. No contexto do RFC 8200, a configuração explícita para processar o cabeçalho precisa acompanhar o resultado.

Uma operadora regional recebe três propostas. Todas exibem “RFC 5180 tested” e line rate. A vencedora parece óbvia até alguém pedir a topologia: uma porta ativa, quadros de 1518 bytes, um destino, vizinhos estáticos, nenhum filtro e tráfego IPv6 puro. A rede comprada, porém, usará muitas portas, mistura IPv4 e IPv6, políticas de ingresso e fluxos pequenos em uma das direções.

O laudo pode estar tecnicamente correto e economicamente inadequado. A falha surge quando o número deixa de pertencer ao ensaio e passa a pertencer ao produto inteiro.

Publicado em 2008 como RFC Informational, o RFC 5180 complementa o RFC 2544 e usa termos do RFC 1242. Ele pede repetibilidade, análise de variância e cuidado com a significância de poucos trials. Não é uma certificação obrigatória nem prova de adoção universal. É uma linguagem comum para caracterizar equipamento IPv6 em condições controladas.

Uma porta não reserva a capacidade do chassi

O documento separa single-port de multi-port. O primeiro mede forwarding por interface; o segundo investiga como a plataforma escala. A diferença é decisiva para quem compra portas que compartilham fabric, memória, lookup, buffers ou caminhos de software. Multiplicar o resultado de uma interface pelo número de slots é uma hipótese financeira, não uma medição.

Direção também precisa permanecer aberta. O RFC recomenda tráfego bidirecional, mas avisa que esse resultado mostra apenas o desempenho mais baixo entre os dois sentidos. Um teste unidirecional pode localizar assimetria. Uma política aplicada na entrada, uma resposta maior que a solicitação ou uma classificação em apenas um caminho alteram o custo por pacote.

Uma proposta deveria, portanto, apresentar pelo menos três dimensões separadas: por porta, plataforma e direção. A agregação só vem depois que a demanda prevista é mapeada sobre elas. Caso contrário, “capacidade contratada” é um nome para uma extrapolação não assinada.

Quadro e destino mudam o custo

Para Ethernet, RFC 5180 lista 64, 128, 256, 512, 1024, 1280 e 1518 bytes. No mesmo bit rate, quadros pequenos exigem muito mais decisões por segundo. Quadros grandes valorizam Gbit/s; pequenos expõem packet rate. A curva completa importa mais que o melhor ponto.

As taxas máximas Ethernet são teóricas e precisam tolerar variação de relógio de mais ou menos 100 ppm. Em Packet over SONET, bit stuffing pode alterar frame rate. Um painel com precisão excessiva não elimina incerteza física.

O destino é outro gerador de trabalho. Um único par de endereços pode manter lookup e cache estáveis. Destinos aleatórios exercitam um conjunto maior. O método manda começar pelo par único e repetir aleatoriamente; /48, /64, /126 e /128 são fronteiras de prefixo recomendadas. O relatório precisa preservar faixa, seed e distribuição, não apenas o máximo.

Vizinhos entram no mesmo contrato. Podem ser estáticos ou descobertos dinamicamente; o modo dinâmico é preferido quando o tester mantém caches ativos. Os endpoints simulados ficam um salto além do DUT para evitar tempestades de NS e NA causadas por Neighbor Unreachability Detection. Uma entrada fixa não mede expiração e reconstrução de cache.

Coexistência não cabe no resultado IPv6-only

O método prevê IPv4-only, IPv6-only e misturas 90/10, 50/50 e 10/90. Isso é especialmente relevante para operadoras em transição: recursos internos podem ser compartilhados, e a proporção muda com clientes, CPEs e serviços.

O valor de IPv6 puro pode ser útil para isolar um caminho, mas não liquida a pergunta comercial sobre carga conjunta. Nem a mistura de hoje liquida o horizonte de três anos. O planejamento deve associar cada perfil a um cenário e declarar o que permanece sem medir.

Há ainda uma fronteira tecnológica. RFC 8219 diz que tradução e encapsulamento ficam fora do escopo do RFC 5180 e precisam de metodologia complementar. Dual stack pode usar RFC 2544 e RFC 5180; uma função stateful de transição exige olhar tabelas de estado, conexões e sobrecarga. O rótulo IPv6 não torna esses mecanismos equivalentes.

Hop-by-Hop mostra por que o caminho precisa ser observado

O RFC recomenda ensaiar cada extension header individualmente e depois uma cadeia. Para comparar tráfego com e sem cabeçalhos em tamanhos pequenos, escolhe-se um mesmo mínimo; sem isso, a própria geometria do quadro cria o diferencial.

Hop-by-Hop recebe tratamento diferente. Em vez de buscar throughput comum, o tester injeta 1%, 10% e 50% da banda da interface e monitora recursos. CPU e memória devem ser coletados fora de banda, independentes das interfaces de teste. O objetivo é perceber o impacto e obter indícios sobre hardware, recirculação, software ou control plane.

A interpretação atual precisa marcar a versão da norma. Em 2008, RFC 5180 descrevia o comportamento de RFC 2460. RFC 8200 depois afirmou que os nós no caminho só são esperados a examinar e processar Hop-by-Hop quando configurados explicitamente. RFC 7045 já admitia ignore ou slow path em routers de alto desempenho. RFC 9098 detalha limites de lookup, recirculação, software forwarding e descarte.

Por isso, uma linha “Hop-by-Hop passou” é insuficiente. Deve registrar configuração, opções, taxa, duração, proteção e curva de recursos. Throughput sozinho não revela o caminho. Um ensaio controlado também não prova resistência a ataque ou comportamento de outra versão.

Política vazia mede uma rede que não será operada

Filtros e routing table fazem parte do perfil. Se o dispositivo precisa atravessar a cadeia de headers para encontrar informação de camada superior, pode usar parse profundo ou outro estágio. Um filtro e vinte e cinco filtros não executam necessariamente a mesma máquina. O comprador que exige segurança e depois aceita benchmark sem política compra duas promessas incompatíveis.

Recuperação também tem nomes diferentes. System recovery mede retorno após overload. Reset mede retorno após reinício de equipamento ou software. O RFC deixa de recomendar back-to-back frames para IPv6 devido à variância de curto prazo. Nem toda métrica tradicional merece virar SLA.

O laboratório deve ser independente, sem caminho para produção ou rede de gestão. A observação é black-box, externa ao DUT/SUT, e não deveria haver recurso especial de benchmark. Essa higiene impede tuning de palco. Ao mesmo tempo, confirma que a produção não foi observada: churn, filas, falhas comuns, políticas e versões heterogêneas foram removidos de propósito.

Até o endereço registra a separação. O texto original tinha errata técnica verificada; o registro IANA atual aponta 2001:2::/48 para benchmarking e não o considera globalmente alcançável. Espaço de teste correto reduz a chance de misturar laboratório e operação.

O dossiê antes da assinatura

A compra deveria exigir um profile ID imutável com modelo e build, features, portas, meio, topologia, tester, clock, frame series, destinos e prefixes, neighbor mode, extension headers, filtros, rotas, control traffic, direção, mistura IP, carga, duração, número de trials, loss, latency, amostras, recursos fora de banda, recuperação e desvios.

Separar os responsáveis fecha incentivos: metodologia define a pergunta; laboratório conserva a execução; estatística qualifica a incerteza; release management prova equivalência de build; operações observa produção com segurança. O fornecedor não deve assinar pelo tráfego futuro do cliente, e o cliente não deve pedir ao nome RFC que faça isso.

O benchmark continua valioso. Ele apenas deixa de ser uma escritura sobre capacidade não medida.

Fontes

  1. RFC 5180 — HTML
  2. RFC 5180 — texto
  3. Página do RFC Editor
  4. Documento no IETF Datatracker
  5. Histórico no Datatracker
  6. Referências no Datatracker
  7. Errata do RFC 5180
  8. RFC 2544
  9. RFC 1242
  10. RFC 8200
  11. RFC 7045
  12. RFC 9098
  13. RFC 4861
  14. RFC 8201
  15. RFC 6890
  16. Registro IANA de endereços IPv6 especiais
  17. RFC 8219
  18. Heng Lu — camadas de realidade
  19. Heng Lu — especificação mínima e adoção voluntária
  20. Heng Lu — primazia do código em execução