Какво всъщност трябва да записва регистърът на адресите за изход на VPN?
Регистърът на изходите е полезен само ако всеки запис посочва значението си, издателя си и срока си на действие. Класификацията не е идентификация на абонат.
Регистрите на изходите звучат като списъци, а списъкът не е трудната част. Трудната част е да се реши какво твърди всеки запис, кой може да го публикува и какво се случва, когато твърдението престане да е вярно. В тези предложения се смесват три различни роли на адресите и регистър, който ги смесва, не може надеждно да отговори на нито един въпрос. Проследете един запис от публикуването до оттеглянето и изискванията към дизайна ще се появят сами.
Започнете със записа, а не със списъка
Първият въпрос не е колко адреса да включим, а какво означава един ред. Описва ли той къде се свързват клиентите, кой източник може да види дадена дестинация или кой държи разпределение в регистър? Това са три твърдения с три собственика и три режима на отказ. Регистър, който не посочва кое от тях записва, не може да бъде валидиран, коригиран или прекратен. Правилното значение е работата по дизайна, а списъкът е само резултатът.
Напишете дефиницията на реда, преди да напишете каквато и да е схема. Ако дефиницията се нуждае от думата и, вероятно това са два записа, представящи се за един.
Три роли на адресите, които изглеждат еднакво
Ролите лесно се объркват, защото едно внедряване може да използва и трите наведнъж и често го прави. Една услуга може да прекратява връзки на един адрес и да препраща трафик от друг, докато регистърът записва съвсем трети факт.
| 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 |
Хостинг блокът може да съдържа VPN изходи и несвързани работни натоварвания един до друг, така че съвпадението в регистъра не казва нищо за това какво прави даден адрес в даден момент. Запис, който не назовава ролята си, не е доказателство за нищо конкретно. Именно назоваването на ролята прави записа опровержим. Посочете и семейството на адресите, защото регистър, който мълчаливо покрива само IPv4, ще подведе всеки, който предполага друго.
Проследете един запис от публикуването до оттеглянето
Вземете един хипотетичен изход и го проследете. Операторът публикува префикса и ролята си в обявено време на влизане в сила, потребителите го изтеглят и по-късно адресът спира да служи като изход. Всяка стъпка изисква правило: кой може да публикува, какво всъщност покрива префиксът, кога записът влиза в сила и как се оттегля. Поток без път за оттегляне натрупва остарели твърдения, които никой не може да различи от актуалните.
Отделете правомощието да публикувате от точността на етикета. Регистров запис, свързващ организация с ресурс, доказва разпределението, а не текущото използване, и това са различни твърдения с различни доказателства. Потребителите трябва да знаят на кое от двете вярват.
Дефинирайте и корекцията. Адрес, преразпределен на клиент, или несвързана услуга, уловена от неправилен етикет, се нуждае от документиран път до поправка, а не от спор в опашката за заявки. Тригерът за оттегляне принадлежи в същия документ като правилото за публикуване.
Какво може и какво не може да подкрепи публикуван поток
Публикуваните атрибути на префиксите са утвърден модел и съществуващите примери описват география или собственост, а не поведение. VPN потокът би се нуждаел от своя семантика, свои правила за доказателства и свой процес на преглед, а преименуването на списък със страни не дава нищо от това. Ръководството за регистъра на ARIN показва какво твърдят и какво не твърдят записите за разпределения и новият поток трябва да спечели същата яснота относно собствените си твърдения. Това е задача по спецификация, а не по преетикетиране.
Това, което такъв поток може да подкрепи, е решение за класификация на мрежов източник. Това, което не може да направи, е да идентифицира човек зад споделен адрес, да докаже, че целият трафик от този адрес минава през тунел, или да реши дали конкретна заявка е злоупотреба. Това са три отделни въпроса с три отделни изисквания за доказателства.
Дръжте правния въпрос извън спецификацията
Техническа спецификация не може да реши дали предложено изискване за регистрация е законно, пропорционално или разумно. Тази оценка се нуждае от действителния законодателен текст, засегнатите права, юрисдикцията и правен анализ, който форматът на данни не може да предостави. Един формат може да е добре проектиран и въпреки това да подкрепя лоша политика.
Това, което спецификацията може да направи, е да направи дебата конкретен. Първо дефинирайте предложените данни, техните граници и режими на отказ, така че политическият аргумент да е за реален механизъм, а не за неопределен списък, който всеки участник си представя различно. Това е максимумът, който един технически документ може да допринесе за правен въпрос.