Prop. 123: For Meta LS, replace extended Host Reply Message

(never implemented) with new Meta Redirect Message. To be reviewed.

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.