Destination Address Handling

This page details how ILP destination address prefixes are handled by the Connector when it encounters a Prepare packet.

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

Concepts - Previous

Routing Table Design

Next - Concepts

Balance Tracking

Last updated 11 months ago

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