1. ID-LOC Proposal Philip Matthews Eric Cooper Alan Johnston Avaya With contributions from Cullen Jennings, David Bryan, and Bruce Lowekamp

2. Not a Peer Protocol proposal ! ID-LOC = proposed addition to the Peer Protocol (i.e., Reload or whatever). ID-LOC = –Some selected ideas from HIP –Plus a few new ideas

3. Relationship to HIP Take from HIP: –Identifiers that look like IP addresses –NAT traversal done once for all apps –TCP over UDP (for NAT traversal) Not taken (for now): –HIP signaling (use Peer Protocol instead) –Encrypting all data packets using ESP New: –Domain names for peers

4. What ID-LOC allows earth.example.com NATNAT saturn.example.com NATNAT Overlay Example.com Browser Web server

5. Tech Details in 3 slides (1) 1.Assign domain names to overlays and peers: –saturn.example.com 2.DHT holds mapping between peer’s domain name and peer’s peer ID saturn.example.com => 0xA3F26E…

6. Tech Details in 3 slides (2) 3.Applications don’t use Peer IDs directly. Instead, use special IP addresses (LSIs). –An LSI is a ‘shorthand’ for a Peer ID –Unlike peer IDs, an LSI can be used anywhere a real IP address can be used –Taken from special address range ORCHID range (RFC 4843) for IPv6 Perhaps 1.x.x.x for IPv4

7. Tech Details in 3 slides (3) 4.NAT Traversal (ICE, etc) done for all applications by Peer Protocol (w/ ID-LOC extensions) –Apps don’t need to worry about this 5.Application data + transport protocol encapsulated inside UDP for NAT traversal reasons HTTP TCP UDP IP

8. Implementation One option is to implement using standard VPN client implementation techniques.

9. Advantages Turns a p2p overlay into a VPN Like VPNs, applications don’t need to change to work in an overlay Preserves the existing user interface (= domain names) and existing application interface (= sockets and use of IP addresses) NAT traversal handled in one place –Apps don’t need NAT traversal code –No need for endless “ICE for protocol X” drafts