I have read through the ILP addressing spec and there is no mention of support for IP addresses to be used, just the allocation schemes described.
I think this can be a hangup for developers since it requires an additional devops skillset to deploy named based routing which is beyond getting started in ILP.
We should have an option to have “explicit addressing” or some override for what might be considered private infrastructure nodes.
I arrive at this post because I have some ILP nodes in the same subnet and want to push some ILP packets around but I see some challenges in the routing. For all intents there is no DNS services. (unless I create them).
BTP works with IP
ILP over HTTP works with IP
The embedded ILP packet with addressing however enforces rules. That means that deep within a private network I have no way to simply specify an ILP address like ip.172.25.0.4.alice . In a private infrastructure or local ‘dev0’ setup the packet will get parsed at the first node and fail to get routed if no name resolution services are available.
I understand the addresses for the most part were not planned to be ‘user’ facing and that SPSP provides payment pointer abstractions.
Nonetheless the addressing is logical and should support an IP allocation scheme. Maybe it does and I missed it.
Thoughts? I am suggesting an ‘ip’ scheme.
It’s an interesting suggest, but I’m not sure it would make sense to have an IP-based scheme for ILP addresses. ILP addresses are intended to help connectors / nodes route packets through the Interledger network. Even if all of the bilateral links between nodes go over IP, knowing another node’s IP address doesn’t necessarily help you figure out which of your Interledger peers to forward the packet to. You can kind of think of ILP as an overlay network on top of the Internet that defines its own routing addresses and rules.
Does that make sense?
Thank-you! 
I definitely understand more the abstraction, I did not know it was designed to be purely logical!
The confusion for me entered probably a while back when I was viewing the address scheme examples thinking that address parts were routable or part of a routable naming scheme.
This ILP address abstraction is actually quite important to maintain as it is what makes us an actual network by routing our own packets ourselves. Or we simply become another application layer.
I was at first wondering why simple “DNS Routable Paypoints” addresses that uses an already established trust infrastructure wasn’t a strategy since the protocol is able to process packets and move money without an SPSP application layer and extra server processing. (This PKI trust needs to be checked at the http_endpoint processing and btp endpoints at that lower level.)
I was envisioning to pay an invoice at a DNS routable pay point https://ilp.example.com/invoices/203334 . Thus when providing the client this pay pointer they can be more assured of its validity. However this can be still achieved in the application layer giving an additional abstraction for indirection as well which is even more useful and secure.
This does open some questions about widely accepted trust in the ILP routing and securing it, different topic.
I think you’ve got it but just to clarify, we do take advantage of the Web’s PKI and DNS for the Interledger application layer protocol SPSP and for some bilateral communication.
When you use SPSP, the payer fetches the payee’s details from a given HTTPS endpoint. These details include an ILP address and shared secret. The secret is used to ensure that the packets sent can only be fulfilled by the correct receiver. If packets are misrouted, they will all be rejected because that other receiver does not have the shared secret to generate the fulfillments.
With ILP-Over-HTTP, peers use HTTPS to send packets to one another. This leverages DNS and TLS to make configuration easier (than if we needed to hard code static IP addresses) and secure the connection.
For more information about Interledger routing, take a look at:
1 Like