Que debería rexistrar realmente un rexistro de enderezos de saída VPN?
Un rexistro de saídas só é útil se cada entrada declara o seu significado, o seu editor e a súa caducidade. A clasificación non é a identificación do subscritor.
Os rexistros de saída soan a listas, e a lista non é a parte difícil. A parte difícil é decidir que afirma cada entrada, quen pode publicala e que ocorre cando a afirmación deixa de ser certa. Nestas propostas confúndense tres roles de enderezo distintos, e un rexistro que os mestura non pode responder ningunha pregunta de forma fiable. Siga unha entrada desde a publicación ata a retirada e os requisitos de deseño aparecerán por si sós.
Comece polo rexistro, non pola lista
A primeira pregunta non é cantos enderezos incluír, senón que significa unha soa fila. Describe onde se conectan os clientes, que orixe pode ver un destino ou quen posúe unha asignación nun rexistro? Son tres afirmacións con tres propietarios e tres modos de fallo. Un rexistro que non indica cal delas rexistra non pode validarse, corrixirse nin caducar. Acertar o significado é o traballo de deseño, e a lista só é o resultado.
Escriba a definición da fila antes de escribir calquera esquema. Se a definición necesita a palabra e, probablemente sexan dous rexistros que finxen ser un.
Tres roles de enderezo que se parecen
Os roles son fáciles de confundir porque un despregamento pode usar os tres á vez, e a miúdo faino. Un servizo pode terminar conexións nun enderezo e reenviar tráfico desde outro, mentres que un rexistro anota un terceiro feito completamente distinto.
| Address role | Who may publish | What it does not prove | Withdrawal trigger |
|---|---|---|---|
| Forwarded exit | The operator that forwards the traffic, or a feed it authorizes | That a subscriber is behind the address, or that all its traffic is tunnelled | The address stops forwarding for that operator, or the prefix is reassigned |
| Registered allocation | The registry, or the holder of the allocation | That the resource is used as a VPN exit, or which application uses it | The allocation is returned, transferred, or the holder changes |
| Tunnel entry | The operator that terminates the tunnel | That traffic exits from the same address, or that the client is a subscriber | The endpoint is decommissioned or its address changes |
Un bloque de aloxamento pode conter saídas VPN e cargas de traballo non relacionadas unha ao lado da outra, así que unha coincidencia no rexistro non di nada sobre o que fai un enderezo concreto nun momento concreto. Unha entrada que non nomea o seu rol non é proba de nada en particular. Nomear o rol é o que fai refutable o rexistro. Indique tamén a familia de enderezos, porque un rexistro que só cobre IPv4 en silencio enganará a calquera que supoña o contrario.
Siga unha entrada desde a publicación ata a retirada
Tome unha saída hipotética e séguia. Un operador publica o prefixo e o seu rol nun momento de entrada en vigor declarado, os consumidores obtéñeno e, máis tarde, o enderezo deixa de servir como saída. Cada paso necesita unha regra: quen pode publicar, que cobre realmente o prefixo, cando entra en vigor a entrada e como se retira. Un feed sen ruta de retirada acumula afirmacións obsoletas que ninguén pode distinguir das actuais.
Separe a autoridade para publicar da exactitude da etiqueta. Un rexistro que vincula unha organización a un recurso demostra a asignación e non o uso actual, e son afirmacións distintas con probas distintas. Os consumidores necesitan saber en cal das dúas confían.
Defina tamén a corrección. Un enderezo reasignado a un cliente, ou un servizo non relacionado atrapado por unha etiqueta incorrecta, necesita unha ruta documentada cara a unha solución en lugar dunha discusión nunha cola de tíckets. O desencadeante da retirada pertence ao mesmo documento que a regra de publicación.
Que pode e que non pode soportar un feed publicado
Os atributos de prefixo publicados son un patrón consolidado, e os exemplos existentes describen xeografía ou propiedade en lugar de comportamento. Un feed VPN necesitaría a súa propia semántica, as súas propias regras de proba e o seu propio proceso de revisión, e renomear unha lista de países non achega nada diso. A guía do rexistro de ARIN mostra que afirman e que non os rexistros de asignación, e un feed novo ten que gañar a mesma claridade sobre as súas propias afirmacións. Iso é unha tarefa de especificación, non de reetiquetaxe.
O que un feed así pode soportar é unha decisión de clasificación sobre unha orixe de rede. O que non pode facer é identificar unha persoa detrás dun enderezo compartido, demostrar que todo o tráfico dese enderezo vai por un túnel ou decidir se unha petición concreta é abusiva. Son tres preguntas separadas con tres requisitos de proba separados.
Manteña a cuestión legal fóra da especificación
Unha especificación técnica non pode resolver se un requisito de rexistro proposto é legal, proporcionado ou sensato. Esa avaliación necesita o texto lexislativo real, os dereitos afectados, a xurisdición e unha análise xurídica que un formato de datos non pode achegar. Un formato pode estar ben deseñado e aínda así apoiar unha mala política.
O que a especificación pode facer é concretar o debate. Defina primeiro os datos propostos, os seus límites e os seus modos de fallo, para que o argumento político xire arredor dun mecanismo real e non dunha lista indefinida que cada participante imaxina de forma distinta. Iso é o máximo que un documento técnico pode achegar a unha cuestión legal.