Wat zou een VPN-uitgangsadressenregister eigenlijk moeten vastleggen?
Een uitgangsregister is alleen nuttig als elke vermelding de betekenis, de uitgever en de vervaldatum vermeldt. Classificatie is geen identificatie van abonnees.
Uitgangsregisters klinken als lijsten, en de lijst is niet het moeilijke deel. Het moeilijke deel is beslissen wat elke vermelding beweert, wie die mag publiceren en wat er gebeurt als de bewering niet meer klopt. In deze voorstellen worden drie verschillende adresrollen door elkaar gehaald, en een register dat ze door elkaar haalt, kan geen enkele vraag betrouwbaar beantwoorden. Volg één vermelding van publicatie tot intrekking en de ontwerpeisen verschijnen vanzelf.
Begin bij het record, niet bij de lijst
De eerste vraag is niet hoeveel adressen erin moeten, maar wat één rij betekent. Beschrijft die waar clients verbinden, welke bron een bestemming kan zien, of wie een toewijzing in een register houdt? Dat zijn drie beweringen met drie eigenaren en drie faalwijzen. Een register dat niet aangeeft welke ervan het vastlegt, kan niet worden gevalideerd, gecorrigeerd of verlopen. De betekenis goed krijgen is het ontwerpwerk, en de lijst is alleen de uitvoer.
Schrijf de rijdefinitie voordat je een schema schrijft. Als de definitie het woord en nodig heeft, zijn het waarschijnlijk twee records die zich als één voordoen.
Drie adresrollen die op elkaar lijken
De rollen zijn makkelijk te verwarren omdat één implementatie alle drie tegelijk kan gebruiken, en dat vaak doet. Een dienst kan verbindingen op het ene adres beëindigen en verkeer van een ander adres doorsturen, terwijl een register een heel derde feit vastlegt.
| 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 |
Een hostingblok kan VPN-uitgangen en ongerelateerde workloads naast elkaar bevatten, dus een treffer in het register zegt niets over wat een bepaald adres op een bepaald moment doet. Een vermelding die zijn rol niet noemt, is geen bewijs voor iets bijzonders. Het noemen van de rol maakt het record weerlegbaar. Vermeld ook de adresfamilie, want een register dat stilzwijgend alleen IPv4 dekt, zal iedereen misleiden die het tegenovergestelde aanneemt.
Volg één vermelding van publicatie tot intrekking
Neem één hypothetische uitgang en volg die. Een operator publiceert het prefix en zijn rol op een vermeld ingangsmoment, consumenten halen het op, en later dient het adres niet meer als uitgang. Elke stap heeft een regel nodig: wie mag publiceren, wat het prefix werkelijk dekt, wanneer de vermelding ingaat en hoe die wordt ingetrokken. Een feed zonder intrekkingspad verzamelt verouderde beweringen die niemand van actuele kan onderscheiden.
Scheid de bevoegdheid om te publiceren van de nauwkeurigheid van het label. Een registerrecord dat een organisatie aan een resource koppelt, bewijst de toewijzing en niet het huidige gebruik, en dat zijn verschillende beweringen met verschillend bewijs. Consumenten moeten weten welke van de twee ze vertrouwen.
Definieer ook correctie. Een adres dat opnieuw aan een klant wordt toegewezen, of een ongerelateerde dienst die door een verkeerd label wordt geraakt, heeft een gedocumenteerd pad naar een oplossing nodig in plaats van een discussie in een ticketwachtrij. De intrekkingsprikkel hoort in hetzelfde document als de publicatieregel.
Wat een gepubliceerde feed wel en niet kan ondersteunen
Gepubliceerde prefixattributen zijn een gevestigd patroon, en de bestaande voorbeelden beschrijven geografie of eigendom in plaats van gedrag. Een VPN-feed zou zijn eigen semantiek, zijn eigen bewijsregels en zijn eigen beoordelingsproces nodig hebben, en het hernoemen van een landenlijst levert daar niets van. De ARIN-registergids laat zien wat toewijzingsrecords wel en niet beweren, en een nieuwe feed moet dezelfde helderheid over zijn eigen beweringen verdienen. Dat is een specificatietaak, geen herlabelingstaak.
Wat zo'n feed kan ondersteunen is een classificatiebeslissing over een netwerkbron. Wat hij niet kan, is een persoon achter een gedeeld adres identificeren, bewijzen dat al het verkeer van dat adres getunneld is, of beslissen of een bepaald verzoek misbruik is. Dat zijn drie afzonderlijke vragen met drie afzonderlijke bewijseisen.
Houd de juridische vraag buiten de specificatie
Een technische specificatie kan niet beslissen of een voorgestelde registratie-eis rechtmatig, evenredig of verstandig is. Die beoordeling vereist de werkelijke wettekst, de geraakte rechten, de jurisdictie en een juridische analyse die een dataformaat niet kan leveren. Een formaat kan goed ontworpen zijn en toch een slecht beleid ondersteunen.
Wat de specificatie kan doen, is het debat concreet maken. Definieer eerst de voorgestelde gegevens, hun grenzen en hun faalwijzen, zodat het beleidsargument over een echt mechanisme gaat in plaats van over een ongedefinieerde lijst die elke deelnemer zich anders voorstelt. Dat is het meeste wat een technisch document aan een juridische vraag kan bijdragen.