0
votes

Firstly, I'm new to the specifics of IPv6 so I wouldn't be surprised if this is just a mis-understanding of IPv6 routing. Consider the situation where I am running a P2P overlay network , part of which lives within the boundaries of a single LAN. The nodes within this LAN have the following link local addresses (as viewed by themselves):

  • Peer 1 fe80::225:4bff:fea8:e200%en0
  • Peer 2 fe80::225:4bff:fea8:e201%eth1
  • Peer 3 fe80::225:4bff:fea8:e202%en1

Now, assume each peer has been able to discover the others through some means, and have the addresses for each other. Each peer is listening on a port, say 12345. If peer 1 wanted to talk to peer 2, they might try and use the URI:

tcp://[fe80:225:4bff:fea8:e201%eth1]:12345

This is where I run into problems. Peer 1 does not have an adapter named "eth1", and so this IPv6 zone identifier is not known to it. If the zone ID is stripped off of the address, peer 1 cannot determine which of it's adapters it must use to contact the host.

So, the question: is it possible to resolve the zone identifier for an IPv6 address in a standard way? If not, do I have to query the system for all of the zone identifiers, and try connecting to the address using each zone identifier in turn until I get success? Or is attempting to communicate using link-local addresses a stupid idea in the first place?

1
You'd also want to encode that % char according to RFC 6874: tcp://[fe80:225:4bff:fea8:e201%25eth1]:12345treat your mods well

1 Answers

4
votes

Link local addresses are only appropriate when you have some mechanism to automatically locate the other node in question, and connect, binding to the correct interface.

If you expect the user to be manually entering addresses, you should use site-local addresses (or better yet, Unique Local Addresses) and have the user configure them themselves, or have an address resolution method on top of link-local addresses, such as mDNS.