diff --git a/i2p2www/spec/proposals/123-new-netdb-entries.rst b/i2p2www/spec/proposals/123-new-netdb-entries.rst index a2074332..4a1d6e9f 100644 --- a/i2p2www/spec/proposals/123-new-netdb-entries.rst +++ b/i2p2www/spec/proposals/123-new-netdb-entries.rst @@ -5,7 +5,7 @@ New netDB Entries :author: zzz, str4d, orignal :created: 2016-01-16 :thread: http://zzz.i2p/topics/2051 - :lastupdated: 2019-09-13 + :lastupdated: 2020-07-11 :status: Open :supercedes: 110, 120, 121, 122 @@ -1920,107 +1920,71 @@ backwards-compatibility issue. -Host Lookup Message -------------------- - -Client to router. - -A lookup of a hash will force the router to fetch the Lease Set, -so extended results may be returned in the Host Reply Message. -However, a lookup of a host name will not force the router to fetch the Lease Set -(unless the lookup was for a b32.i2p, which is discouraged, the client side -normally converts this to a hash lookup). - -To force a Lease Set lookup for a host name lookup, -we need a new request type. - - -Changes -``````` - -:: - - Add request type 3: Host name lookup and request Lease Set lookup. - Same contents as type 1, what follows is a host name string. - - -Notes -````` - -- Minimum router and client version is TBD for request type 3. - - - -Host Reply Message (meta) +Meta Redirect Message ------------------------- Router to client. +New message. + +Justification +````````````` A client doesn't know a priori that a given Hash will resolve to a Meta LS. -If a Host Lookup Message for a Hash yields a Meta LS, -the router needs to return one or more Destinations and expirations to the client. -Either the client must do the recursive resolution, or the router can do it. -Not clear how it should work. -For either method, we either need a new flavor of the Host Reply Message, -or define a new result code that means what follows is a list of Destinations -and expirations. +If a leaseset lookup for a Destination returns a Meta LS, +the router will do the recursive resolution. +For datagrams, the client side does not need to know; +however, for streaming, where the protocol checks the destination in +the SYN ACK, it must know what the "real" destination is. +Therefore, we need a new message. -If the router simply returns a single Destination whose Hash doesn't match -that of the lookup, it may fail sanity checks on the client side, -and the client has no way to get an alternate if that fails, -and has no way to know the expiration time. -There may be similar issues in BOB and SAM. +Usage +````` -Changes -``````` +The router maintains a cache for the actual destination is used from a meta LS. +When the client sends a message to a destination which resolves to a meta LS, +the router checks the cache for the actual destination last used. +If the cache is empty, the router selects a destination from the meta LS, +and looks up the leaseset. +If the leaseset lookup is successful, the router adds that destination +to the cache, and sends the client a Meta Redirect Message. +This is only done once, unless the destination expires and must be changed. +The client must also cache the information if needed. +The Meta Redirect Message is NOT sent in reply to every SendMessage. + +The router only sends this message to clients with version 0.9.47 or higher. + +The client does not send a reply to this message. + + +Message Type +```````````` + +The message type for the Meta Redirect Message is 43. + + +Format +`````` :: - If the client version is 0.9.42 or higher, and the result code is 0, - the following extended results are included after the Destination, - no matter what the request type, but only if the LeaseSet type is 7 - (Meta LS). Use cases for returning the extended information in - other cases is for further study. + Session ID (2 bytes) The value from the Send Message. + Message ID generated by the router (4 bytes) + 4 byte nonce previously generated by the client + (the value from the Send Message, may be zero) + Flags: 2 bytes + Unused, set to 0 for future compatibility + From the Meta Lease for the actual Destination + Cost (priority) 1 byte + From the Meta Lease for the actual Destination + Expiration: 4 bytes, big endian, seconds since epoch + From the Meta Lease for the actual Destination + Original (meta) Destination (387+ bytes) + Actual (real) Destination (387+ bytes) - 5. LeaseSet type (1 byte) - 0: Unknown or not found - 1: LS 1 - 3: LS 2 - 5: Encrypted LS 2 (if unable to decrypt) - 7: Meta LS - 6. LeaseSet expiration (4 bytes, big endian, seconds since the epoch) - 0 if unknown - 7. Number of encryption types supported (1 byte) - 0 if unknown - 8. That number of encryption types, 2 bytes each - 9. Lease set options, a Mapping, or 2 bytes of zeros if unknown. - 10. Flags (2 bytes) - Bit order: 15 14 13...3210 - Bit 0: 1 for offline keys, 0 if not - Bits 15-1: Unused, set to 0 for compatibility with future uses - 11. If offline keys, the transient key sig type (2 bytes, big endian) - 12. If offline keys, the transient public key - (length as implied by sig type) - 13. If LeaseSet type is Meta (7), the number of - meta entries to follow (1 byte) - 14. If LeaseSet type is Meta (7), the Meta Entries. - Each entry contains: (40 bytes) - - Hash (32 bytes) - - Flags (2 bytes) - TBD. Set all to zero for compatibility with future uses. - - Type (1 byte) The type of LS it is referencing; - 1 for LS, 3 for LS2, 5 for encrypted, 7 for meta, 0 for unknown. - - Cost (priority) (1 byte) - - Expires (4 bytes, big endian, seconds since epoch, rolls over in 2106) - -Notes -````` - -- Minimum router and client version is TBD for the extended results.