Resumo

  • O RFC 9952 registra os bytes 0x63 0x6f, representados por co, para CoAP sobre DTLS e autoriza sua divulgação em SVCB. O mesmo texto afirma que o RFC 7252 não definiu ALPN no handshake DTLS e que o novo registro não cria regras como as do RFC 8323.
  • Registro, descoberta e negociação são fatos distintos. A prova de wire precisa da lista completa em ClientHello, da seleção em ServerHello ou do erro; identidade do peer, autorização CoAP e efeito da aplicação continuam separados.

O valor usado por CoAP sobre TLS é coap. Para DTLS, o RFC 9952 escolhe um nome próprio e menor. Não reutilizar a mesma etiqueta entre transportes evita ambiguidade. Poupar dois bytes também pode ajudar quando um handshake atravessa 6LoWPAN e está perto de um limite de fragmentação.

Essa decisão é útil justamente porque é modesta. Ela diz como chamar a combinação. Não ordena que todo endpoint CoAP/DTLS envie ALPN.

O registro não edita o ClientHello

A tabela da IANA prova que existe um significado comum para co. Ela não prova que uma biblioteca tem suporte, que a opção foi habilitada naquele listener ou que o cliente a incluiu naquela conexão.

O limite aparece numa frase expressa do RFC: o RFC 7252 não definiu o uso da extensão ALPN durante o handshake DTLS; o RFC 9952 não muda esse comportamento nem estabelece o conjunto de regras do RFC 8323. Portanto, uma declaração de conformidade precisa nomear o perfil adicional que transforma disponibilidade em obrigação.

Quando um perfil local exige co, o recibo deve unir requisito, versão do cliente, versão do servidor e resultado observado. Quando apenas permite, a ausência de ALPN não pode virar violação automática.

Publicação DNS e estado do endpoint

SVCB pode trazer alpn=co, mas esse registro é uma afirmação de descoberta. Autoridade de publicação, validação, TTL, idade do cache, aliases e seleção local precedem a conexão. DNSSEC protege origem e integridade da resposta; não atesta que o processo atrás do endereço carregou a mesma geração.

Rollouts podem deixar DNS e servidores em momentos diferentes. Um cliente pode ignorar SVCB ou escolher outra alternativa. O erro de governança é condensar tudo em “ALPN implantado”, escondendo quem controla cada passagem.

No wire, o RFC 7301 define outra evidência: lista ordenada oferecida pelo cliente e uma seleção do servidor tomada dessa lista. Sem interseção, há o resultado de erro aplicável. O registro operacional deve conservar conexão, endpoints, versão DTLS, oferta, seleção ou alerta, horário e origem da observação.

Economia de bytes precisa de medição

co é dois bytes menor que coap. Mesmo assim, o tamanho total depende de cipher suites, key shares, assinaturas, cookies, certificados e extensões. Fragmentação de registro DTLS e fragmentação 6LoWPAN são fenômenos diferentes. Perda, MTU e retransmissão completam o quadro.

Uma decisão de desempenho deve comparar tamanho, fragmentos, retransmissões, latência e falhas numa configuração identificada. A justificativa do RFC é válida; o ganho de uma implantação continua sendo fato local.

A seleção ainda não autoriza o recurso

Um ServerHello com co não autentica sozinho o serviço. Certificado ou chave pública, identidade de referência, âncora e validade ainda precisam passar. Depois vêm parser CoAP, correlação, método, opções, política de recurso e efeito.

A cadeia útil separa: vocabulário IANA; anúncio DNS; candidato do cliente; oferta; seleção; identidade; troca CoAP; autorização; efeito; resultado medido. O inverso também é importante: a ausência de ALPN não prova ausência de CoAP sobre DTLS, pois o RFC não criou um mandato universal.

O princípio de especificação mínima de Lu Heng preserva um núcleo comum pequeno e deixa futuras decisões a quem suporta o risco. As camadas de realidade não permitem que um símbolo tome o lugar do pacote nem que o pacote tome o lugar da decisão. A primazia do código executado procura binário, configuração e handshake reais.

O RFC 9952 registrou uma palavra curta. A operação responsável não deve transformá-la numa história longa sem recibos.

Exceções são parte da topologia real

Uma migração não leva toda a frota de um estado uniforme a outro. Sensores podem permanecer num firmware anterior, gateways podem consultar outra visão de DNS, respostas SVCB podem ficar em cache e clientes com destino estático talvez nunca façam descoberta. Cada condição muda aquilo que o endpoint poderia saber e oferecer. Um percentual geral de implantação esconde justamente as diferenças que explicam os incidentes.

O inventário de exceções precisa nomear proprietário, população, motivo, versão, prazo e comportamento de fallback. Prazo vencido não é evidência de encerramento. A exceção termina quando a última população é observada fora do caminho antigo. Enquanto uma rota alternativa existir, suas conexões devem ter identidades próprias e os efeitos CoAP precisam ser atribuíveis a elas, sem deixar a segunda tentativa apagar a primeira.

A prova de uma liberação combina pelo menos quatro artefatos: binário ou firmware com suporte, configuração que ativa o recurso, geração DNS vista pelo cliente e trace com oferta e seleção. Nenhum substitui os demais. Software novo pode carregar configuração antiga; DNS novo pode apontar para listener antigo; um canário saudável não descreve a frota inteira.

Essa decomposição também protege as fronteiras de responsabilidade. DNS demonstra publicação, não ClientHello. A plataforma demonstra ativação local, não escolha remota. Segurança valida a identidade, não a autorização do recurso. A aplicação observa um efeito, mas pode não saber qual tentativa o produziu. O relatório só deve declarar a cadeia concluída depois de preservar e unir esses veredictos independentes.

Fontes