I2P Client Protocol (I2CP)

Přehled

Toto je specifikace I2P Control Protocol (I2CP), nízkoúrovňového rozhraní mezi klienty a routerem. Java klienti budou používat I2CP klientské API, které implementuje tento protokol.

Neexistují žádné známé implementace klientské knihovny pro I2CP mimo Javu. Navíc aplikace orientované na sockety (streaming) by potřebovaly implementaci streaming protokolu, ale ani pro ten neexistují knihovny mimo Javu. Proto by klienti mimo Javu měli místo toho používat protokol vyšší vrstvy SAM SAMv3 , pro který existují knihovny v několika jazycích.

Jedná se o nízkoúrovňový protokol podporovaný jak interně, tak externě Java I2P routerem. Protokol je serializován pouze v případě, že klient a router nejsou ve stejném JVM; jinak jsou I2CP zprávy jako Java objekty předávány přes interní JVM rozhraní. I2CP je také externě podporován C++ routerem i2pd.

Více informací najdete na stránce Přehled I2CP I2CP .

Relace

Protokol byl navržen pro zpracování více “sessions” (relací), každá s 2-bytovým ID session, přes jediné TCP spojení, nicméně více sessions nebylo implementováno až do verze 0.9.21. Viz sekce multisession níže . Nepokoušejte se používat více sessions na jediném I2CP spojení s routery staršími než verze 0.9.21.

Zdá se také, že existují některá ustanovení pro jediného klienta, aby komunikoval s více routery přes samostatná připojení. Toto je také netestované a pravděpodobně neužitečné.

Neexistuje způsob, jak udržet relaci po odpojení nebo ji obnovit na jiném I2CP připojení. Když je socket uzavřen, relace je zničena.

Příklady sekvencí zpráv

Poznámka: Příklady níže neukazují Protocol Byte (0x2a), který musí být odeslán z klienta do routeru při prvním připojení. Více informací o inicializaci připojení najdete na stránce I2CP Overview I2CP .

Standardní ustanovení relace

  Client                                           Router

                           --------------------->  Get Date Message
        Set Date Message  <---------------------
                           --------------------->  Create Session Message
  Session Status Message  <---------------------
Request LeaseSet Message  <---------------------
                           --------------------->  Create LeaseSet Message

Získat limity šířky pásma (jednoduchá relace)

  Client                                           Router

                           --------------------->  Get Bandwidth Limits Message
Bandwidth Limits Message  <---------------------

Vyhledání cíle (jednoduchá relace)

  Client                                           Router

                           --------------------->  Dest Lookup Message
      Dest Reply Message  <---------------------

Odchozí zpráva

Existující relace, s i2cp.messageReliability=none

  Client                                           Router

                           --------------------->  Send Message Message

Existující relace s i2cp.messageReliability=none a nenulovým nonce

  Client                                           Router

                           --------------------->  Send Message Message
  Message Status Message  <---------------------
  (succeeded)

Existující relace, s i2cp.messageReliability=BestEffort

  Client                                           Router

                           --------------------->  Send Message Message
  Message Status Message  <---------------------
  (accepted)
  Message Status Message  <---------------------
  (succeeded)

Příchozí zpráva

Existující relace, s i2cp.fastReceive=true (od verze 0.9.4)

  Client                                           Router

 Message Payload Message  <---------------------

Existující relace, s i2cp.fastReceive=false (ZASTARALÉ)

  Client                                           Router

  Message Status Message  <---------------------
  (available)
                           --------------------->  Receive Message Begin Message
 Message Payload Message  <---------------------
                           --------------------->  Receive Message End Message

Poznámky k více relacím

Více relací na jednom I2CP připojení je podporováno od verze routeru 0.9.21. První relace, která je vytvořena, je “primární relace”. Další relace jsou “podrelace”. Podrelace se používají k podpoře více destinací sdílejících společnou sadu tunelů. Počáteční aplikace je pro primární relaci použít ECDSA podpisové klíče, zatímco podrelace používá DSA podpisové klíče pro komunikaci se starými eepsites.

Subsessions sdílejí stejné fondy příchozích a odchozích tunelů jako primární relace. Subsessions musí používat stejné šifrovací klíče jako primární relace. To platí jak pro šifrovací klíče leaseSet, tak pro (nepoužívané) šifrovací klíče Destination. Subsessions musí používat různé podepisovací klíče v destinaci, takže hash destinace se liší od primární relace. Protože subsessions používají stejné šifrovací klíče a tunely jako primární relace, je všem zřejmé, že Destinations běží na stejném routeru, takže obvyklé záruky anonymity proti korelaci neplatí.

Subsessions jsou vytvořeny odesláním zprávy CreateSession a přijetím odpovědní zprávy SessionStatus, jako obvykle. Subsessions musí být vytvořeny až po vytvoření primární session. Odpověď SessionStatus bude při úspěchu obsahovat jedinečné Session ID, odlišné od ID primární session. Zatímco zprávy CreateSession by měly být zpracovány v pořadí, neexistuje spolehlivý způsob, jak korelovat zprávu CreateSession s odpovědí, takže klient by neměl mít současně více nevyřízených zpráv CreateSession. Možnosti SessionConfig pro subsession nemusí být respektovány tam, kde se liší od primární session. Zejména, protože subsessions používají stejný tunnel pool jako primární session, možnosti tunnel mohou být ignorovány.

Router pošle klientovi samostatné zprávy RequestVariableLeaseSet pro každou Destination a klient musí odpovědět zprávou CreateLeaseSet pro každou z nich. Leases pro tyto dvě Destinations nebudou nutně identické, i když jsou vybrány ze stejného tunnel poolu.

Subsession může být zničena pomocí zprávy DestroySession jako obvykle. Toto nezničí primární session ani nezastaví I2CP spojení. Zničení primární session však zničí všechny subsessions a zastaví I2CP spojení. Zpráva Disconnect ničí všechny sessions.

Poznamenejte si, že většina, ale ne všechny, I2CP zprávy obsahují Session ID. Pro ty, které ho neobsahují, mohou klienti potřebovat dodatečnou logiku pro správné zpracování odpovědí routeru. DestLookup a DestReply neobsahují Session ID; použijte místo toho novější HostLookup a HostReply. GetBandwidthLimts a BandwidthLimits neobsahují session ID, nicméně odpověď není specifická pro session.

Poznámky k verzi

Počáteční bajt verze protokolu (0x2a) odesílaný klientem se pravděpodobně nezmění. Před vydáním verze 0.8.7 nebyly informace o verzi routeru dostupné klientovi, což bránilo novým klientům ve spolupráci se starými routery. Od vydání verze 0.8.7 se řetězce verzí protokolu obou stran vyměňují ve zprávách Get/Set Date Messages. Do budoucna mohou klienti tyto informace použít ke správné komunikaci se starými routery. Klienti a routery by neměly odesílat zprávy, které druhá strana nepodporuje, protože obecně odpojují relaci po obdržení nepodporované zprávy.

Vyměněné informace o verzi jsou “základní” verze API nebo verze I2CP protokolu a nemusí nutně odpovídat verzi routeru.

Základní shrnutí verzí I2CP protokolu je následující. Podrobnosti viz níže.

Hlavička I2CP zprávy

Popis

Společná hlavička pro všechny I2CP zprávy, obsahující délku zprávy a typ zprávy.

Obsah

1. 4 bajtový Integer specifikující délku těla zprávy
2. 1 bajtový Integer specifikující typ zprávy.
3. Tělo I2CP zprávy, 0 nebo více bajtů

Poznámky

Skutečný limit délky zprávy je přibližně 64 KB.

ID zprávy

Popis

Jednoznačně identifikuje zprávu čekající na konkrétním routeru v daném okamžiku. Toto je vždy generováno routerem a NENÍ totéž jako nonce generovaný klientem.

Obsah

1. 4 byte Integer

Poznámky

ID zpráv jsou jedinečné pouze v rámci relace; nejsou globálně jedinečné.

Payload

Popis

Tato struktura je obsahem zprávy doručované z jedné Destination do druhé.

Obsah

1. 4 bajtový Integer délka
2. Tolik bajtů

Poznámky

Datová část je ve formátu gzip jak je specifikováno na stránce I2CP Overview I2CP-FORMAT .

Skutečný limit délky zprávy je asi 64 KB.

Konfigurace relace

Popis

Definuje konfigurační možnosti pro konkrétní klientskou relaci.

Obsah

1. Destination
2. Mapping možností
3. Datum vytvoření Date
4. Signature předchozích 3 polí, podepsaný pomocí SigningPrivateKey

Poznámky

• Možnosti jsou specifikovány na stránce I2CP Overview I2CP-OPTIONS .
• Mapping musí být seřazeno podle klíče, aby byl podpis v routeru správně validován.
• Datum vytvoření musí být v rozmezí +/- 30 sekund od aktuálního času při zpracování routerem, jinak bude konfigurace odmítnuta.

Offline podpisy

• Pokud je Destination offline podepsaná, Mapping musí obsahovat tři možnosti i2cp.leaseSetOfflineExpiration, i2cp.leaseSetTransientPublicKey a i2cp.leaseSetOfflineSignature. Signature je pak generována dočasným SigningPrivateKey a je ověřována pomocí SigningPublicKey specifikovaného v i2cp.leaseSetTransientPublicKey. Podrobnosti viz I2CP-OPTIONS .

Session ID

Popis

Jedinečně identifikuje relaci na konkrétním router v daném okamžiku.

Obsah

1. 2 byte Integer

Poznámky

Session ID 0xffff se používá k označení “žádné session”, například pro vyhledávání názvů hostů.

Zprávy

Viz také I2CP Javadocs .

Typy zpráv

Popis

Informuj klienta o omezeních šířky pásma.

Odesláno z Router do Client jako odpověď na GetBandwidthLimitsMessage .

Obsah

1. 4 byte Integer Limit příchozích dat klienta (KBps)
2. 4 byte Integer Limit odchozích dat klienta (KBps)
3. 4 byte Integer Limit příchozích dat router (KBps)
4. 4 byte Integer Burst limit příchozích dat router (KBps)
5. 4 byte Integer Limit odchozích dat router (KBps)
6. 4 byte Integer Burst limit odchozích dat router (KBps)
7. 4 byte Integer Burst čas router (sekundy)
8. Devět 4-byte Integer (nedefinováno)

Poznámky

Limity klienta mohou být jediné nastavené hodnoty a mohou představovat skutečné limity routeru, nebo procento z limitů routeru, nebo být specifické pro konkrétního klienta, což závisí na implementaci. Všechny hodnoty označené jako limity routeru mohou být 0, což závisí na implementaci. Od vydání 0.7.2.

BlindingInfoMessage

Popis

Informuje router, že Destination je blinded (zastíněná), s volitelným heslem pro vyhledávání a volitelným soukromým klíčem pro dešifrování. Podrobnosti naleznete v návrzích 123 a 149.

Router potřebuje vědět, zda je cíl zaslepený. Pokud je zaslepený a používá tajné nebo per-client ověřování, potřebuje mít také tyto informace.

Host Lookup nové b32 adresy formátu (“b33”) říká routeru, že adresa je zaslepená, ale neexistuje mechanismus pro předání tajného nebo soukromého klíče routeru ve zprávě Host Lookup. Ačkoli bychom mohli rozšířit zprávu Host Lookup o tyto informace, je čistší definovat novou zprávu.

Tato zpráva poskytuje programový způsob, jak může klient informovat router. Jinak by uživatel musel manuálně konfigurovat každou destinaci.

Použití

Před tím, než klient odešle zprávu do blinded destination (skryté cílové adresy), musí buď vyhledat “b33” ve zprávě Host Lookup, nebo odeslat zprávu Blinding Info. Pokud blinded destination vyžaduje tajný klíč nebo autentifikaci podle klienta, musí klient odeslat zprávu Blinding Info.

Router neposílá odpověď na tuto zprávu. Odesílá se z klienta do routeru.

Obsah

1. Session ID
2. 1 byte Integer Flags

• Pořadí bitů: 76543210 > - Bit 0: 0 pro všechny, 1 pro jednotlivé klienty > - Bity 3-1: Schéma autentifikace, pokud je bit 0 nastaven na 1 pro > jednotlivé klienty, jinak 000 > - 000: DH autentifikace klienta (nebo žádná autentifikace jednotlivých klientů) > - 001: PSK autentifikace klienta > - Bit 4: 1 pokud je vyžadováno tajemství, 0 pokud není vyžadováno tajemství > - Bity 7-5: Nepoužívané, nastavte na 0 pro budoucí kompatibilitu

3. 1 byte Integer Typ koncového bodu

• Typ 0 je Hash > - Typ 1 je hostname String > - Typ 2 je Destination > - Typ 3 je Sig Type a > SigningPublicKey

4. 2 byte Integer Blinded Signature Type
5. 4 byte Integer Expiration Sekundy od epochy
6. Endpoint: Data podle specifikace, jeden z

• Typ 0: 32 bytový Hash > > - Typ 1: název hostitele String > > - Typ 2: binární Destination > > > > - Typ 3: 2 bytový Integer typ podpisu, následovaný > > - SigningPublicKey (délka podle > typu podpisu)

7. PrivateKey Dešifrovací klíč Přítomen pouze pokud je flag bit 0 nastaven na 1. 32-bajtový ECIES_X25519 privátní klíč, little-endian
8. String Heslo pro vyhledávání Přítomen pouze pokud je flag bit 4 nastaven na 1.

Poznámky

• Od verze 0.9.43.
• Typ koncového bodu Hash pravděpodobně není užitečný, pokud router nemůže provést zpětné vyhledání v adresáři pro získání Destination.
• Typ koncového bodu hostname pravděpodobně není užitečný, pokud router nemůže provést vyhledání v adresáři pro získání Destination.

CreateLeaseSetMessage

ZASTARALÉ. Nelze použít pro LeaseSet2, offline klíče, jiné typy šifrování než ElGamal, více typů šifrování nebo šifrované LeaseSets. Použijte CreateLeaseSet2Message se všemi routery verze 0.9.39 nebo vyšší.

Popis

Tato zpráva je odeslána v odpovědi na RequestLeaseSetMessage nebo RequestVariableLeaseSetMessage a obsahuje všechny struktury Lease , které by měly být publikovány do I2NP Network Database.

Odesláno z klienta do routeru.

Obsah

1. Session ID
2. DSA SigningPrivateKey nebo 20 bajtů ignorováno
3. PrivateKey
4. LeaseSet

Poznámky

SigningPrivateKey odpovídá SigningPublicKey z LeaseSet pouze tehdy, pokud je typ podpisového klíče DSA. Toto slouží pro odvolání LeaseSet, které není implementováno a pravděpodobně nikdy implementováno nebude. Pokud typ podpisového klíče není DSA, toto pole obsahuje 20 bytů náhodných dat. Délka tohoto pole je vždy 20 bytů, nikdy se nerovná délce ne-DSA podpisového soukromého klíče.

PrivateKey odpovídá PublicKey z LeaseSet. PrivateKey je nezbytný pro dešifrování zpráv směrovaných pomocí garlic encryption.

Odvolání není implementováno. Připojení k více routerům není implementováno v žádné klientské knihovně.

CreateLeaseSet2Message

Popis

Tato zpráva je odeslána jako odpověď na RequestLeaseSetMessage nebo RequestVariableLeaseSetMessage a obsahuje všechny struktury Lease , které by měly být publikovány do I2NP Network Database.

Odesláno z klienta do routeru. Od verze 0.9.39. Autentizace per-klient pro EncryptedLeaseSet je podporována od verze 0.9.41. MetaLeaseSet zatím není podporován přes I2CP. Viz návrh 123 pro více informací.

Obsah

1. Session ID
2. Jeden bajt typu lease set, který následuje.

• Typ 1 je LeaseSet (zastaralý) > - Typ 3 je LeaseSet2 > - Typ 5 je EncryptedLeaseSet > - Typ 7 je MetaLeaseSet

3. LeaseSet nebo LeaseSet2 nebo EncryptedLeaseSet nebo MetaLeaseSet
4. Jeden byte číslo privátních klíčů následujících.
5. Seznam PrivateKey . Jeden pro každý veřejný klíč v lease setu, ve stejném pořadí. (Není přítomno pro Meta LS2)

• Typ šifrování (2 bajtový Integer ) > - Délka šifrovacího klíče (2 bajtový Integer ) > - Šifrovací PrivateKey (počet bajtů > specifikovaný)

Poznámky

PrivateKeys odpovídají každému z PublicKey z LeaseSet. PrivateKeys jsou nezbytné pro dešifrování zpráv směrovaných pomocí garlic encryption.

Více informací o šifrovaných leaseSetech naleznete v návrhu 123.

Obsah a formát pro MetaLeaseSet jsou předběžné a mohou se změnit. Neexistuje žádný protokol specifikovaný pro správu více routerů. Více informací naleznete v návrhu 123.

Soukromý klíč pro podepisování, dříve definovaný pro zrušení a nepoužitý, není v LS2 přítomen.

Předběžná verze s typem zprávy 40 byla v 0.9.38, ale formát byl změněn. Typ 40 je opuštěn a není podporován. Typ 41 není platný do verze 0.9.39.

CreateSessionMessage

Popis

Tato zpráva je odeslána z klienta pro zahájení relace, kde relace je definována jako připojení jednoho Destination k síti, do kterého budou doručeny všechny zprávy pro tento Destination a přes které budou odesílány všechny zprávy, které tento Destination posílá jakémukoliv jinému Destination.

Odesláno z klienta do routeru. Router odpovídá zprávou SessionStatusMessage .

Obsah

1. Konfigurace relace

Poznámky

• Toto je druhá zpráva odeslaná klientem. Dříve klient odeslal GetDateMessage a obdržel odpověď SetDateMessage .
• Pokud je Datum v Session Config příliš vzdálené (více než +/- 30 sekund) od aktuálního času routeru, bude session odmítnuta.
• Pokud již existuje session na routeru pro tuto Destination, bude session odmítnuta.
• Mapping v Session Config musí být seřazen podle klíče, aby mohl být podpis správně ověřen v routeru.

DestLookupMessage

Popis

Odesláno z Klienta do Routeru. Router odpovídá zprávou DestReplyMessage .

Obsah

1. SHA-256 Hash

Poznámky

Od verze 0.7.

Od verze 0.8.3 jsou podporovány vícenásobné probíhající vyhledávání a vyhledávání je podporováno jak v I2PSimpleSession, tak ve standardních relacích.

HostLookupMessage je preferována od verze 0.9.11.

DestReplyMessage

Popis

Odesláno z routeru klientovi jako odpověď na DestLookupMessage .

Obsah

1. Destination při úspěchu, nebo Hash při selhání

Poznámky

Od verze 0.7.

Od verze 0.8.3 je požadovaný Hash vrácen, pokud vyhledávání selhalo, takže klient může mít více vyhledávání probíhajících současně a korelovat odpovědi s vyhledáváními. Pro korelaci odpovědi Destination s požadavkem vezměte Hash Destination. Před verzí 0.8.3 byla odpověď při selhání prázdná.

DestroySessionMessage

Popis

Tato zpráva je odeslána z klienta pro zrušení relace.

Odesláno z klienta na router. Router by měl odpovědět zprávou SessionStatusMessage (Destroyed). Viz však důležité poznámky níže.

Obsah

1. ID relace

Poznámky

Router by v tomto okamžiku měl uvolnit všechny prostředky související se session.

Až do API 0.9.66 se Java I2P router a klientské knihovny podstatně odchylují od této specifikace. Router nikdy neodesílá odpověď SessionStatus(Destroyed). Pokud nezůstaly žádné relace, odešle DisconnectMessage . Pokud existují podrelace nebo zůstává primární relace, neodpovídá.

Java klientská knihovna reaguje na zprávu SessionStatus zrušením všech relací a opětovným připojením.

Rušení jednotlivých podsezení na připojení s více sezeními nemusí být plně otestováno nebo funkční v různých implementacích routerů a klientů. Postupujte opatrně.

Implementace by měly zacházet s příkazem destroy pro primární relaci jako s příkazem destroy pro všechny podrelace, ale umožnit destroy pro jednu podrelaci a udržet spojení otevřené, Java I2P to však nyní nedělá. Pokud bude chování Java I2P v následujících verzích změněno, bude to zde zdokumentováno.

DisconnectMessage

Popis

Oznámí druhé straně, že existují problémy a současné spojení bude ukončeno. Tím se ukončí všechny relace na tomto spojení. Socket bude brzy uzavřen. Odesíláno buď z routeru ke klientovi nebo z klienta k routeru.

Obsah

1. Důvod String

Poznámky

Implementováno pouze ve směru router-to-client, alespoň v Java I2P.

GetBandwidthLimitsMessage

Popis

Požádejte router, aby sdělil, jaké jsou jeho aktuální omezení šířky pásma.

Odesláno z Klienta do Routeru. Router odpovídá s BandwidthLimitsMessage .

Obsah

Žádné

Poznámky

Od verze 0.7.2.

Od verze 0.8.3 je podporováno jak v I2PSimpleSession, tak ve standardních relacích.

GetDateMessage

Popis

Odesláno z klienta do routeru. Router odpoví zprávou SetDateMessage .

Obsah

1. Verze I2CP API String
2. Ověřování Mapping (volitelné, od vydání 0.9.11)

Poznámky

• Obecně první zpráva odeslaná klientem po odeslání bajtu verze protokolu.
• Řetězec verze je zahrnut od vydání 0.8.7. To je užitečné pouze pokud klient a router nejsou ve stejném JVM. Pokud není přítomen, klient je verze 0.8.6 nebo starší.
• Od vydání 0.9.11 může být zahrnuto autentifikační Mapping s klíči i2cp.username a i2cp.password. Mapping nemusí být seřazeno, protože tato zpráva není podepsaná. Před verzí 0.9.10 včetně je autentifikace zahrnuta v Session Config Mapping a žádná autentifikace není vynucována pro GetDateMessage , GetBandwidthLimitsMessage nebo DestLookupMessage . Pokud je povolena, je od vydání 0.9.16 vyžadována autentifikace prostřednictvím GetDateMessage před jakýmikoli jinými zprávami. To je užitečné pouze mimo kontext routeru. Jedná se o nekompatibilní změnu, ale ovlivní pouze relace mimo kontext routeru s autentifikací, což by mělo být vzácné.

HostLookupMessage

Popis

Odesláno z klienta do routeru. Router odpovídá zprávou HostReplyMessage .

Toto nahrazuje DestLookupMessage a přidává ID požadavku, timeout a podporu pro vyhledávání názvů hostitelů. Jelikož také podporuje Hash vyhledávání, může být použito pro všechna vyhledávání, pokud to router podporuje. Pro vyhledávání názvů hostitelů bude router dotazovat naming service svého kontextu. To je užitečné pouze pokud je klient mimo kontext routeru. Uvnitř kontextu routeru by měl klient dotazovat naming service přímo, což je mnohem efektivnější.

Obsah

1. Session ID
2. 4 byte Integer ID požadavku
3. 4 byte Integer timeout (ms)
4. 1 byte Integer typ požadavku
5. SHA-256 Hash nebo název hostitele String nebo Destination

Typy požadavků:

Poznámky

• Od vydání 0.9.11. Pro starší routery použijte DestLookupMessage .
• ID relace a ID požadavku budou vráceny v HostReplyMessage . Pokud neexistuje relace, použijte pro ID relace hodnotu 0xFFFF.
• Timeout je užitečný pro vyhledávání Hash. Doporučené minimum je 10 000 (10 sekund). V budoucnu může být také užitečné pro vzdálené vyhledávání v názvových službách. Hodnota nemusí být respektována pro vyhledávání místních názvů hostitelů, které by mělo být rychlé.
• Vyhledávání názvu hostitele v Base 32 je podporováno, ale je preferováno jej nejprve převést na Hash.

HostReplyMessage

Popis

Odesláno z router do klienta v reakci na HostLookupMessage .

Obsah

1. Session ID
2. 4 byte Integer ID požadavku
3. 1 byte Integer kód výsledku

• 0: Úspěch > - 1: Neúspěch > - 2: Vyžadováno heslo pro vyhledávání (od verze 0.9.43) > - 3: Vyžadován privátní klíč (od verze 0.9.43) > - 4: Vyžadováno heslo pro vyhledávání a privátní klíč (od verze 0.9.43) > - 5: Neúspěšné dešifrování leaseSetu (od verze 0.9.43) > - 6: Neúspěšné vyhledávání leaseSetu (od verze 0.9.66) > - 7: Nepodporovaný typ vyhledávání (od verze 0.9.66)

4. Destination , přítomen pouze pokud je kód výsledku nula, s výjimkou případů kdy může být také vrácen pro typy vyhledávání 2-4. Viz níže.
5. Mapping , přítomen pouze pokud je kód výsledku nula, vrácen pouze pro typy vyhledávání 2-4. Od verze 0.9.66. Viz níže.

Odpovědi pro typy vyhledávání 2-4

Proposal 167 definuje další typy vyhledávání, které vrací všechny možnosti z leaseset, pokud jsou k dispozici. Pro typy vyhledávání 2-4 musí router načíst leaseset, i když je vyhledávací klíč v adresáři.

Pokud je operace úspěšná, HostReply bude obsahovat options Mapping z leaseset a zahrne jej jako položku 5 po destination. Pokud v Mapping nejsou žádné options, nebo byl leaseset verze 1, bude stále zahrnut jako prázdný Mapping (dva bajty: 0 0). Všechny options z leaseset budou zahrnuty, nejen options pro service record. Například mohou být přítomny options pro parametry definované v budoucnu. Vrácený Mapping může nebo nemusí být seřazen, závisí na implementaci.

Při selhání vyhledání leaseset bude odpověď obsahovat nový kód chyby 6 (Selhání vyhledání leaseset) a nebude zahrnovat mapování. Když je vrácen kód chyby 6, pole Destination může nebo nemusí být přítomno. Bude přítomno, pokud bylo vyhledání hostname v adresáři úspěšné, nebo pokud bylo předchozí vyhledání úspěšné a výsledek byl uložen do cache, nebo pokud bylo Destination přítomno ve vyhledávací zprávě (typ vyhledání 4).

Pokud typ vyhledávání není podporován, odpověď bude obsahovat nový kód chyby 7 (typ vyhledávání není podporován).

Poznámky

• Od vydání 0.9.11. Viz poznámky k HostLookupMessage .
• ID relace a ID požadavku jsou ty z HostLookupMessage .
• Kód výsledku je 0 pro úspěch, 1-255 pro neúspěch. 1 označuje obecný neúspěch. Od verze 0.9.43 byly definovány dodatečné kódy neúspěchu 2-5 pro podporu rozšířených chyb pro vyhledávání “b33”. Viz návrhy 123 a 149 pro další informace. Od verze 0.9.66 byly definovány dodatečné kódy neúspěchu 6-7 pro podporu rozšířených chyb pro vyhledávání typu 2-4. Viz návrh 167 pro další informace.

MessagePayloadMessage

Popis

Doručit užitečná data zprávy klientovi.

Odesláno z routeru klientovi. Pokud je i2cp.fastReceive=true, což není výchozí nastavení, klient odpovídá zprávou ReceiveMessageEndMessage .

Obsah

1. ID relace
2. ID zprávy
3. Užitečné zatížení

Poznámky

MessageStatusMessage

Popis

Oznámit klientovi stav doručení příchozí nebo odchozí zprávy. Odesláno z Router do klienta. Pokud tato zpráva indikuje, že je k dispozici příchozí zpráva, klient odpovídá pomocí ReceiveMessageBeginMessage . Pro odchozí zprávu je toto odpověď na SendMessageMessage nebo SendMessageExpiresMessage .

Obsah

1. Session ID
2. Message ID generované routerem
3. 1 byte Integer status
4. 4 byte Integer velikost
5. 4 byte Integer nonce dříve generované klientem

Poznámky

Do verze 0.9.4 jsou známé hodnoty stavu 0 pro zpráva je k dispozici, 1 pro přijato, 2 pro best effort uspěšné, 3 pro best effort neúspěšné, 4 pro garantované uspěšné, 5 pro garantované neúspěšné. Celé číslo size specifikuje velikost dostupné zprávy a je relevantní pouze pro stav = 0. I když garantované doručení není implementováno (best effort je jediná služba), současná implementace routeru používá kódy garantovaného stavu, nikoli kódy best effort.

Od verze routeru 0.9.5 jsou definovány další stavové kódy, avšak nemusí být nutně implementovány. Podrobnosti najdete v MessageStatusMessage Javadocs . Pro odchozí zprávy kódy 1, 2, 4 a 6 označují úspěch; všechny ostatní jsou selhání. Vrácené kódy selhání se mohou lišit a jsou specifické pro danou implementaci.

Všechny stavové kódy:

ReceiveMessageBeginMessage

ZASTARALÉ. Není podporováno i2pd.

Popis

Požádejte router o doručení zprávy, o které byl předem informován. Odesílá se z klienta do routeru. Router odpovídá zprávou MessagePayloadMessage .

Obsah

1. ID relace
2. ID zprávy

Poznámky

ReceiveMessageBeginMessage se odesílá jako odpověď na MessageStatusMessage oznamující, že je k dispozici nová zpráva k vyzvednutí. Pokud je id zprávy uvedené v ReceiveMessageBeginMessage neplatné nebo nesprávné, router může jednoduše neodpovědět, nebo může poslat zpět DisconnectMessage .

Toto se nepoužívá v režimu “rychlého přijímání”, který je výchozí od verze 0.9.4.

ReceiveMessageEndMessage

ZASTARALÉ. Není podporováno i2pd.

Popis

Řekněte routeru, že doručení zprávy bylo úspěšně dokončeno a že router může zprávu zahodit.

Odesláno z klienta do routeru.

Obsah

1. ID relace
2. ID zprávy

Poznámky

ReceiveMessageEndMessage se odesílá poté, co MessagePayloadMessage kompletně doručí payload zprávy.

Toto se nepoužívá v režimu “rychlého příjmu”, který je výchozí od verze 0.9.4.

ReconfigureSessionMessage

Popis

Odesláno z klienta do routeru pro aktualizaci konfigurace relace. Router odpovídá SessionStatusMessage .

Obsah

1. ID relace
2. Konfigurace relace

Poznámky

• Od verze 0.7.1.
• Pokud je datum v Session Config příliš vzdálené (více než +/- 30 sekund) od aktuálního času routeru, bude relace odmítnuta.
• Mapping v Session Config musí být seřazen podle klíče, aby byla signatura správně validována v routeru.
• Některé možnosti konfigurace lze nastavit pouze v CreateSessionMessage a změny zde nebudou routerem rozpoznány. Změny možností tunelu inbound.* a outbound.* jsou vždy rozpoznány.
• Obecně by router měl sloučit aktualizovanou konfiguraci s aktuální konfigurací, takže aktualizovaná konfigurace musí obsahovat pouze nové nebo změněné možnosti. Kvůli sloučení však možnosti nelze tímto způsobem odstranit; musí být explicitně nastaveny na požadovanou výchozí hodnotu.

ReportAbuseMessage

ZASTARALÉ, NEPOUŽÍVANÉ, NEPODPOROVANÉ

Popis

Informovat druhou stranu (client nebo router), že je pod útokem, potenciálně s odkazem na konkrétní MessageId. Pokud je router pod útokem, client se může rozhodnout migrovat na jiný router, a pokud je client pod útokem, router může znovu vybudovat své routery nebo zařadit na černou listinu některé z peerů, které mu poslaly zprávy s útokem.

Odesláno buď z routeru klientovi nebo z klienta routeru.

Obsah

1. Session ID
2. 1 byte Integer závažnost zneužití (0 je minimálně škodlivé, 255 je extrémně škodlivé)
3. Důvod String
4. Message ID

Poznámky

Nepoužíváno. Není plně implementováno. Router i klient mohou generovat ReportAbuseMessage , ale ani jeden nemá handler pro zprávu při jejím přijetí.

RequestLeaseSetMessage

ZASTARALÉ. Není podporováno i2pd. Neposílá se Java I2P klientům verze 0.9.7 nebo vyšší (2013-07). Použijte RequestVariableLeaseSetMessage.

Popis

Požadavek, aby klient autorizoval zahrnutí konkrétní sady příchozích tunnelů. Odesílá se z routeru klientovi. Klient odpovídá zprávou CreateLeaseSetMessage .

První z těchto zpráv odeslaných v relaci je signál pro klienta, že tunely jsou vybudovány a připraveny pro provoz. Router nesmí odeslat první z těchto zpráv, dokud nebude vybudován alespoň jeden příchozí A jeden odchozí tunnel. Klienti by měli vypršet časový limit a zničit relaci, pokud první z těchto zpráv není přijata po určité době (doporučeno: 5 minut nebo více).

Obsah

1. Session ID
2. 1 byte Integer počet tunelů
3. Tolik párů:
   1. Hash
   2. TunnelId
4. Koncové Date

Poznámky

Toto požaduje LeaseSet se všemi Lease záznamy nastavenými tak, aby vypršely ve stejnou dobu. Pro klientské verze 0.9.7 nebo vyšší se používá RequestVariableLeaseSetMessage .

RequestVariableLeaseSetMessage

Popis

Požadavek, aby klient autorizoval zahrnutí konkrétní sady příchozích tunnelů.

Odesláno z routeru klientovi. Klient odpovídá zprávou CreateLeaseSetMessage nebo CreateLeaseSet2Message .

První z těchto zpráv odeslaných v rámci relace je signálem pro klienta, že tunnely jsou postavené a připravené pro provoz. Router nesmí odeslat první z těchto zpráv, dokud není postaven alespoň jeden příchozí A jeden odchozí tunnel. Klienti by měli relaci ukončit kvůli vypršení času a zničit ji, pokud první z těchto zpráv není přijata po určité době (doporučeno: 5 minut nebo více).

Obsah

1. Session ID
2. 1 byte Integer počet tunnelů
3. Tolik Lease záznamů

Poznámky

Toto vyžaduje LeaseSet s individuálním časem vypršení pro každý Lease .

Od vydání 0.9.7. Pro klienty před tímto vydáním použijte RequestLeaseSetMessage .

SendMessageMessage

Popis

Takto klient odesílá zprávu (payload) na Destination . Router použije výchozí dobu platnosti.

Odesláno z klienta do routeru. Router odpovídá zprávou MessageStatusMessage .

Obsah

1. Session ID
2. Destination
3. Payload
4. 4 byte Integer nonce

Poznámky

Jakmile SendMessageMessage dorazí kompletně neporušená, router by měl vrátit MessageStatusMessage oznamující, že byla přijata k doručení. Tato zpráva bude obsahovat stejný nonce poslaný zde. Později, na základě záruk doručení konfigurace relace, může router dodatečně poslat zpět další MessageStatusMessage aktualizující stav.

Od vydání 0.8.1 router neposílá ani MessageStatusMessage , pokud i2cp.messageReliability=none.

Před vydáním verze 0.9.4 nebyla hodnota nonce 0 povolena. Od vydání verze 0.9.4 je hodnota nonce 0 povolena a říká routeru, že by neměl posílat MessageStatusMessage , tj. chová se, jako kdyby i2cp.messageReliability=none pouze pro tuto zprávu.

Před vydáním verze 0.9.14 nebylo možné přepsat session s i2cp.messageReliability=none na základě jednotlivých zpráv. Od verze 0.9.14 může v session s i2cp.messageReliability=none klient vyžádat doručení MessageStatusMessage s úspěchem nebo neúspěchem doručení nastavením nonce na nenulovou hodnotu. Router neodešle “přijatou” MessageStatusMessage , ale později odešle klientovi MessageStatusMessage se stejným nonce a hodnotou úspěchu nebo neúspěchu.

SendMessageExpiresMessage

Popis

Odesíláno z klienta do routeru. Stejné jako SendMessageMessage , kromě toho, že obsahuje expiraci a možnosti.

Obsah

1. Session ID
2. Destination
3. Payload
4. 4 byte Integer nonce
5. 2 bajty příznaků (možnosti)
6. Expiration Date zkrácený z 8 bajtů na 6 bajtů

Poznámky

Od verze 0.7.1.

V režimu “best effort”, jakmile SendMessageExpiresMessage dorazí kompletně neporušená, router by měl vrátit MessageStatusMessage oznamující, že byla přijata k doručení. Tato zpráva bude obsahovat stejný nonce zaslaný zde. Později, na základě záruk doručení konfigurace relace, může router dodatečně zaslat další MessageStatusMessage aktualizující stav.

Od verze 0.8.1 router neposílá žádnou Message Status Message, pokud i2cp.messageReliability=none.

Před verzí 0.9.4 nebyla povolena nonce hodnota 0. Od verze 0.9.4 je nonce hodnota 0 povolena a říká routeru, že nemá odeslat žádnou Message Status Message, tedy se chová, jako by bylo nastaveno i2cp.messageReliability=none pouze pro tuto zprávu.

Před verzí 0.9.14 nemohla být relace s i2cp.messageReliability=none přepsána pro jednotlivé zprávy. Od verze 0.9.14 může v relaci s i2cp.messageReliability=none klient požádat o doručení Message Status Message s informací o úspěchu nebo neúspěchu doručení nastavením nonce na nenulovou hodnotu. Router neodešle “accepted” Message Status Message, ale později odešle klientovi Message Status Message se stejným nonce a hodnotou úspěchu nebo neúspěchu.

Pole příznaků

Od verze 0.8.4 jsou horní dva byty Date předefinovány tak, aby obsahovaly příznaky. Příznaky musí být výchozně nastaveny na všechny nuly kvůli zpětné kompatibilitě. Date nezasáhne do pole příznaků až do roku 10889. Příznaky mohou být použity aplikací k poskytnutí návodů routeru ohledně toho, zda má být s touto zprávou doručen LeaseSet a/nebo ElGamal/AES Session Tags. Nastavení významně ovlivní množství protokolové režie a spolehlivost doručování zpráv. Jednotlivé bity příznaků jsou definovány následovně od verze 0.9.2. Definice se mohou změnit. Pro vytvoření příznaků použijte třídu SendMessageOptions.

Pořadí bitů: 15…0

Bity 15-11

Nepoužíváno, musí být nula

Bity 10-9

Přepsání spolehlivosti zpráv (Neimplementováno, bude odstraněno).

: Pokud 1, nezahrnuj leaseSet do garlic encryption s touto zprávou. Pokud

0, the router may bundle a lease set at its discretion.

Bity 7-4

Nízký práh tagů. Pokud je k dispozici méně tagů než tento počet,

send more. This is advisory and does not force tags to be delivered. For ElGamal only. Ignored for ECIES-Ratchet.

: Počet tagů k odeslání, pokud je to požadováno. Toto je pouze doporučující a není

force tags to be delivered. For ElGamal only. Ignored for
ECIES-Ratchet.

Popis

Informovat klienta o stavu jeho relace.

Odesláno z routeru klientovi, jako odpověď na CreateSessionMessage , ReconfigureSessionMessage , nebo DestroySessionMessage . Ve všech případech, včetně odpovědi na CreateSessionMessage , by router měl odpovědět okamžitě (nečekejte na vybudování tunnelů).

Obsah

1. Session ID
2. 1 bajt Integer status

Hodnoty stavu jsou definovány výše. Pokud je stav Created, Session ID je identifikátor, který se má používat po zbytek relace.

SetDateMessage

Popis

Aktuální datum a čas. Odesíláno z routeru ke klientovi jako součást počátečního handshaku. Od verze 0.9.20 může být také odesíláno kdykoli po handshaku, aby klient byl informován o posunu hodin.

Obsah

1. Datum
2. Verze I2CP API String

Poznámky

Toto je obecně první zpráva odeslaná routerem. Řetězec verze je zahrnut od vydání 0.8.7. To je užitečné pouze pokud klient a router nejsou ve stejném JVM. Pokud není přítomen, router je verze 0.8.6 nebo starší.

Dodatečné zprávy SetDate nebudou odeslány klientům ve stejném JVM.

Reference

• Date
• Destination
• EncryptedLeaseSet
• Hash
• Přehled I2CP
• I2CP Javadocs
• Integer
• Lease
• LeaseSet
• LeaseSet2
• Mapping
• MetaLeaseSet
• MessageStatusMessage Javadocs
• PrivateKey
• PublicKey
• RouterIdentity
• SAMv3
• Signature
• SigningPrivateKey
• SigningPublicKey
• String
• TunnelId