Resumo

  • O RFC 10030 transporta mensagens NTP de cliente-servidor e modo simétrico dentro de eventos PTP unicast, permitindo carimbos de tempo em placas que reconhecem apenas PTP e correções de relógios transparentes compatíveis.
  • A correção não recebe autoridade: não pode ser autenticada, resultados negativos são rejeitados, o root delay não é alterado e o cliente NTP continua escolhendo fontes e calculando seu limite de erro.

Uma adaptação para o hardware que já existe

Algumas placas de rede não conseguem carimbar todo o tráfego recebido na velocidade do enlace. Elas filtram apenas pacotes PTP, às vezes por transporte, porta ou tipo de evento. O NTP comum em UDP 123 pode passar por uma etapa de software antes de receber seu tempo, incorporando fila e processamento à medição.

O novo RFC cria um invólucro. A mensagem NTP entra em um TLV específico de organização e viaja em um evento PTP unicast. O escopo cobre cliente, servidor e modo simétrico, não o broadcast NTP. No OUI 00-00-5E da IANA, o subtipo 0x1 foi registrado como Network Time Protocol Message.

Quem recebe a solicitação por esse transporte deve responder pela mesma via. A resposta não pode exceder o tamanho da solicitação, uma defesa contra amplificação. Se precisar de espaço, o cliente preenche antes. Para sincronização, tamanhos iguais reduzem assimetria em rotas que não oferecem suporte PTP completo.

O anúncio do RFC Editor, datado de 14 de agosto de 2026, identifica Miroslav Lichvar como autor e a revisão 08 do Internet-Draft como texto de origem do grupo Network Time Protocols.

A troca embutida na porta 319

No transporte UDP, origem e destino devem preferencialmente usar a porta de eventos PTP 319. É assim que o filtro da NIC reconhece a mensagem e gera o carimbo de recepção. Ao mesmo tempo, a randomização da porta de origem recomendada pelo RFC 9109 deixa de funcionar com um filtro que só aceita 319.

O operador recebe precisão e assume outra exposição. O Network Time Security continua protegendo o conteúdo NTP, mas não autentica o cabeçalho PTP externo. Uma proteção válida no interior não transforma automaticamente a correção do caminho em dado assinado.

No PTP 2.1, domainNumber e sdoId também precisam corresponder. Os padrões recomendados são 123 e 0, com possibilidade de configuração em caso de conflito. Todos os participantes da mesma conversa precisam usar o mesmo par.

Esse par define alcance operacional. Não atesta que o relógio remoto esteja certo ou que deva vencer outras fontes na seleção NTP.

O campo que corrige sem provar origem

Relógios transparentes one-step E2E somam seu atraso de encaminhamento ao correction field do evento. Para corrigir ida e volta, o cliente precisa das duas direções. A resposta traz a própria correção no cabeçalho PTP; a correção da solicitação retorna no novo campo de extensão NTP Network Correction, tipo 0x010A.

O servidor deve ignorar qualquer correção recebida na solicitação, e o cliente deve enviá-la zerada. Com os dois valores, é possível ajustar peer delay e offset, considerando também a duração de recepção e uma margem para erro de frequência dos relógios transparentes.

Os limites importam mais que a fórmula. Se atraso corrigido, correção de ida ou correção de volta forem negativos, a amostra não pode sincronizar o relógio. O root delay não deve ser corrigido, preservando root distance como erro máximo independente das alegações do caminho.

As correções PTP não são autenticáveis. Um agente em trânsito pode mudá-las. O cliente aceita apenas correções menores que o atraso medido; o RFC compara o impacto restante ao atraso deliberado de uma mensagem NTP intacta. Trata-se de limitar poder, não de certificar identidade.

A seleção continua onde o risco termina

O NTP compara servidores, filtra amostras, remove fontes falhas e disciplina o relógio local. O transporte PTP melhora o ponto de coleta do carimbo e acrescenta evidência de trânsito. Ele não transfere a seleção para a placa, o switch ou o domínio PTP.

Um host pode sincronizar diretamente por PTP em um domínio e usar outro apenas para transportar NTP. Nem sequer é obrigatório haver outros relógios PTP no caminho. Se existirem relógios transparentes compatíveis, há correções; sem eles, o carimbo de hardware da NIC ainda pode ser útil.

É uma especificação inicial estreita: suficiente para interoperar, pequena o bastante para não reescrever o sistema que já funciona. Cada rede pode adotar conforme hardware e risco, sem aceitar que o instrumento de medição se torne dono da decisão.

Fontes