Skip to content

Latest commit

 

History

History
24 lines (18 loc) · 2.77 KB

architecture-design.md

File metadata and controls

24 lines (18 loc) · 2.77 KB
description
This page details how ILP destination address prefixes are handled by the Connector when it encounters a Prepare packet.

Destination Address Handling

Packet Destination Address Handling

Every ILPv4 Prepare packet has a destination address that indicates where a packet should ultimately be delivered. These addresses MUST always conform to IL-RFC-15 and may begin with one of several valid address-prefixes.

Each of these prefixes has special meaning, and is handled by the Connector in slightly different ways, as described in the following chart.

Address Prefix System Applicability Purpose Connector Handling Accepts External Packets Forwards Out of Connector
g. Global Allocation Scheme ILP addresses that are intended to send and receive money from any other address in the global scheme. Forwarded to a plugin by the Packet-switching fabric. Yes Yes
private. Private allocation For ILP addresses that only have meaning in a private subnet or intranet. Analogous to the 192.168.0.0/16 range in IPv4. Forwarded to a plugin by the Packet-switching fabric. No Yes
example. Examples For "non-real" addresses that are used as examples or in documentation. Analogous to "555 phone numbers" in the USA. Always rejected by the Connector. No No
test., test1., test2.,test3. Interledger testnet and testing For addresses used on the public Interledger testnet and in local tests, such as unit or integration tests of compatible software. Handled identically to a g. address if the Connector's Operating Address begins with test; Otherwise always rejected by the Connector. Yes Yes
local. Connector-local For addresses that are valid only in the a local-connector network, such among a cluster of connectors operated by the same entity. Forwarded to a connected plugin by the Packet-switching fabric. No Yes (only to another local.)
peer. Peering Addresses for exchange of packets only with a direct peer. Connectors MUST NOT forward packets with peer. addresses. Packets exchanged between peers to pass routing and config information will use peer. addresses. Handled by the Connector as a message from a Peer. Yes No
self. Local loopback For addresses that are only valid on the local machine. For example, self.ping, self.echo, and other internal addresses that the Connector forwards traffic to for internal handling. External packets can make their way to self. handlers, but only indirectly. For example, Ping packets are addressed to this Connector's operator address, and are then forwarded to self.ping for handling. No No