... | ... | @@ -14,29 +14,30 @@ The data format **may change**, but for now we have: |
|
|
|
|
|
* **first 2 bytes**: udp port to connect to
|
|
|
* **one byte**: number of ip addresses specified. format of ip addresses follows:
|
|
|
** **first byte**:
|
|
|
*** bit 0-1: ip type (00 = ipv4, 01 = ipv6, other are reserved)
|
|
|
*** bit 2-4: priority of the server (for server fallback).
|
|
|
*** bit 5-7: preference of address (for servsers with same priority).
|
|
|
** **X bytes**: ip address, length depends on ipv4 or ipv6
|
|
|
* **one byte**: public key type (rsa-1024,rsa-2048 etc..) the complete list is to be defined.
|
|
|
* **Y bytes** the public key
|
|
|
|
|
|
Now in a single TXT record we have the ip addresses, with redundancy support, and the public key.
|
|
|
* **first byte**:
|
|
|
* bit 0-1: ip type (00 = ipv4, 01 = ipv6, other are reserved)
|
|
|
* bit 2-4: priority of the server (for server fallback).
|
|
|
* bit 5-7: preference of address (for servsers with same priority).
|
|
|
* **X bytes**: ip address, length depends on ipv4 or ipv6
|
|
|
* **Y * 2 ** bytes: uint16_t list of supported authentication algorithms.
|
|
|
* one byte: number of public keys
|
|
|
* **two bytes**: public key type (rsa-1024,rsa-2048 etc..) the complete list is to be defined.
|
|
|
* **two bytes**: public key id
|
|
|
* **Z bytes** the public key (size dependent on key type)
|
|
|
|
|
|
Now in a single TXT record we have the ip addresses, with redundancy support, and the public keys.
|
|
|
|
|
|
## Why don't you use the A and AAAA records for ips?
|
|
|
|
|
|
For 2 reasons:
|
|
|
|
|
|
* **efficiency**: each server, ip with priority and preference would have its own record, meaning that it also needs to be signed. so you get a signature of overhead per each record. way too much.
|
|
|
* **less delay**: if we use A or AAAA records then all the servers must support Fenrir and other protocols, too (think HTTP). which means that you have to try to connect to the server before you know if it supports Fenrir or not. which means more delay
|
|
|
* **less delay**: if we use A or AAAA records then all the servers must support Fenrir and other protocols, too (think HTTP). which means that you have to try to connect to the server before you know if it supports Fenrir or not. which means more delay.
|
|
|
|
|
|
## Priority? Preference? Aren't those the same?
|
|
|
|
|
|
While you can have servers with the same priority and/or preference, they are not the same.
|
|
|
|
|
|
In general, the higher the number, the more probability the ip address has of being chosen:
|
|
|
|
|
|
* **Priority**: This is used when you want a fallback server. clients will chose an ip from the highest priority, and try one with lower priority only if it doesn't work.
|
|
|
* **Preference**: This is used to randomize connections between servers with the same priority. Clients will generate a random number and chose the preference closer to that number.
|
|
|
|
... | ... | @@ -45,3 +46,5 @@ Since we only have 3 bits for the preference, the only preference probabilities |
|
|
----
|
|
|
|
|
|
All this information is now in a single packet, efficient and fairly easy to parse.
|
|
|
|
|
|
---- |
|
|
\ No newline at end of file |