Hva bør egentlig et VPN-utgangsadresseregister registrere?
Et utgangsregister er bare nyttig hvis hver oppføring oppgir betydningen, utgiveren og utløpsdatoen. Klassifisering er ikke abonnentidentifikasjon.
Utgangsregistre høres ut som lister, og listen er ikke den vanskelige delen. Den vanskelige delen er å avgjøre hva hver oppføring hevder, hvem som kan publisere den, og hva som skjer når påstanden ikke lenger er sann. Tre forskjellige adresseroller blandes sammen i disse forslagene, og et register som blander dem, kan ikke svare på noe spørsmål pålitelig. Følg én oppføring fra publisering til tilbaketrekking, og designkravene dukker opp av seg selv.
Begynn med oppføringen, ikke med listen
Det første spørsmålet er ikke hvor mange adresser som skal tas med, men hva en enkelt rad betyr. Beskriver den hvor klienter kobler til, hvilken kilde en destinasjon kan se, eller hvem som har en tildeling i et register? Det er tre påstander med tre eiere og tre feilmoduser. Et register som ikke oppgir hvilken av dem det registrerer, kan ikke valideres, korrigeres eller utløpe. Å få betydningen riktig er designarbeidet, og listen er bare utdataene.
Skriv raddefinisjonen før du skriver noe skjema. Hvis definisjonen trenger ordet og, er det sannsynligvis to oppføringer som utgir seg for å være én.
Tre adresseroller som ser like ut
Rollene er lette å forveksle fordi én utrulling kan bruke alle tre samtidig, og ofte gjør det. En tjeneste kan avslutte tilkoblinger på én adresse og videresende trafikk fra en annen, mens et register registrerer et helt tredje faktum.
| 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 |
En hostingblokk kan inneholde VPN-utganger og urelaterte arbeidsbelastninger side om side, så en registertreff sier ingenting om hva en gitt adresse gjør på et gitt tidspunkt. En oppføring som ikke navngir rollen sin, er ikke bevis for noe bestemt. Det er navngivningen av rollen som gjør oppføringen falsifiserbar. Oppgi også adressefamilien, for et register som stilltiende bare dekker IPv4, vil villede alle som antar noe annet.
Følg én oppføring fra publisering til tilbaketrekking
Ta én hypotetisk utgang og følg den. En operatør publiserer prefikset og rollen sin på et angitt ikrafttredelsestidspunkt, forbrukere henter det, og senere slutter adressen å tjene som utgang. Hvert trinn trenger en regel: hvem som kan publisere, hva prefikset faktisk dekker, når oppføringen trer i kraft, og hvordan den trekkes tilbake. En feed uten tilbaketrekkingsvei samler foreldede påstander som ingen kan skille fra gjeldende.
Skill myndigheten til å publisere fra etikettens nøyaktighet. En registeroppføring som kobler en organisasjon til en ressurs, beviser tildelingen og ikke dagens bruk, og det er forskjellige påstander med forskjellige bevis. Forbrukerne må vite hvilken av de to de stoler på.
Definer også korreksjon. En adresse som tildeles en kunde på nytt, eller en urelatert tjeneste som fanges av en feil etikett, trenger en dokumentert vei til en rettelse i stedet for en diskusjon i en billetkø. Tilbaketrekkingsutløseren hører til i samme dokument som publiseringsregelen.
Hva en publisert feed kan og ikke kan støtte
Publiserte prefiksattributter er et etablert mønster, og de eksisterende eksemplene beskriver geografi eller eierskap snarere enn atferd. En VPN-feed ville trenge sin egen semantikk, sine egne bevistregler og sin egen gjennomgangsprosess, og å gi en landliste nytt navn gir ingen av dem. ARIN-registerveiledningen viser hva tildelingsoppføringer hevder og ikke hevder, og en ny feed må oppnå samme klarhet om sine egne påstander. Det er en spesifikasjonsoppgave, ikke en ometiketteringsoppgave.
Det en slik feed kan støtte, er en klassifiseringsbeslutning om en nettverkskilde. Det den ikke kan, er å identifisere en person bak en delt adresse, bevise at all trafikk fra den adressen er tunnellert, eller avgjøre om en bestemt forespørsel er misbruk. Det er tre separate spørsmål med tre separate beviskrav.
Hold det juridiske spørsmålet utenfor spesifikasjonen
En teknisk spesifikasjon kan ikke avgjøre om et foreslått registreringskrav er lovlig, forholdsmessig eller klokt. Den vurderingen trenger den faktiske lovteksten, de berørte rettighetene, jurisdiksjonen og en juridisk analyse som et dataformat ikke kan levere. Et format kan være godt designet og likevel støtte en dårlig politikk.
Det spesifikasjonen kan gjøre, er å gjøre debatten konkret. Definer først de foreslåtte dataene, grensene deres og feilmodusene, slik at det politiske argumentet handler om en reell mekanisme i stedet for en udefinert liste som hver deltaker forestiller seg forskjellig. Det er det meste et teknisk dokument kan bidra med til et juridisk spørsmål.