protocols.csv: Add "ip6%" multiaddr (IPv6 with zone ID) #68
Conversation
|
Another point I'm not sure about: I couldn't figure out any pattern or logic to the protocol code assignment so I just went with IP6 + 1. |
|
Yeah, I'd rather have This would mean "connect to link X, and from there, connect to IP Y, ...". Thoughts? /cc @lgierth you generally have opinions on multiaddr stuff. |
|
Why not make /ip6 accept the zone-id? It's a valid part of an IPv6 address after all. (Just making sure I'm not missing anything while going through my backlog.) |
The argument length is currently fixed so that would break existing addresses.
It's a part of a valid textual IPv6 address but there's no place for it in the binary representation. |
|
Got it -- that makes sense. It's also in line with Name bikeshed: /ipzone? The additional characters don't seem too scary, especially given they're not sent over the network anyway. |
|
Well, I was thinking this could also work with IP4 and potentially mac. |
|
I had considered adding a separate zoneid "multiaddr" code, but there were a few points I didn't quite like about it:
I'll admit these arguments are all quite weak, so if there is otherwise a consensus against the proposal as currently implemented, I'll make the necessary changes. As already stated in point 3., the only thing I strongly disagree with is the addition of a more general |
|
So, what do you think? Would you accept a patch adding an |
True, but we don't using
Yes, before. It'd be
So, I'm pretty sure that the zone ID always corresponds to an interface number (on all platforms).
So... this quite often isn't the case. For example, in go, the IP struct doesn't have a place for the Zone. Instead, you have to use the IPAddr struct. This really is a general problem because the binary representation of an IPv6 address doesn't encode the zone. FYI, an alternative is to just do what BSD does and store the zone ID in second 16bit word of the address. This will never conflict with anything as, in "proper" IPv6, this word must be 0. Actually, this may be the way to go. I'm not suggesting we display it there or put it there in the string format. Basically, we'd take an address in the form Thoughts? |
|
Basically, I'd like to avoid having two ipv6 protocols. |
|
You're spot on @Stebalien 👍 |
|
FYI, an alternative is to just do what BSD does and store the zone
ID in second 16bit word of the address. This will never conflict
with anything as, in "proper" IPv6, this word must be 0. Actually,
this may be the way to go.
I'm not suggesting we *display* it there or put it there in the
string format. Basically, we'd take an address in the form
`/ip6/fe80::...%0/...` and serialize it to binary as `fe80:0:...`.
Old versions may display these addresses as `/ip6/fe80:x:/...`,
but that's not really a problem.
Thoughts?
I was aware of this BSD trick, however, I can see three major
reasons against using it in multiaddr:
1. I don't believe the RFC (rfc4007) specifies a maximum length for
the numeric zone ID. There is in principle nothing preventing an
operating system from creating interfaces with arbitrarily large
IDs, such as `(uint64_t)-1`, although the RFC does refer to these
as indexes, which would _suggest_ that they should be allocated
sequentially. Better not to take any risks I'd say.
2. More fundamentally, I can already imagine two situations where
the user wishes to specify the zone by name rather than by index
and where the translation from name to index must be delayed:
a. The user is a remote client sending commands to a server in
non-textual form. These commands might include binary-encoded
multiaddresses, which may include IPv6 addresses with zones.
There would be no way for the client's multiaddr library to
know how to translate the names to indexes.
b. The interface might not yet be available. This could very
easily happen in a processes that launches containers for
instance.
3. I haven't read all the relevant RFCs but as far as I can tell,
there's no guarantee that only `fe80::/64` link-local addresses
can have a (non-default) zone. Quite the opposite, rfc4007 talks
quite a bit about multicast addresses.
In conclusion, I will be implementing a `zone` "protocol" (probably
this week).
Do you think it would make sense (fit in with multiaddr's design
principles) to add some syntactic sugar translating
`/ip6/<ip6>%<zone>` to `/zone/<zone>/ip6/<ip6>`? I feel like it
would make for a better user experience in cases where human input
is expected, but is it worth the added complexity? What about the
reverse translation?
…--
mwnx
GPG: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726
|
All very good points.
If we go with the (although I'd still call it something like |
|
Sign-offs: The proposal here is to add a new protocol, The alternatives were:
Given that this is a decision that'll impact us down the road, you should take a look and think about it. Questions:
|
|
Well, I finally got to it (one week late, sorry). I've force-pushed on all four projects. I went with the "zone" prefix solution. And yes, I do think it should be called "zone" since that is the vocabulary used in the IETF standard (rfc4007). |
Hm. I see. There's actually a distinction between link-local and interface-local so either interface or link would definitely be wrong. |
|
So, uh, any chance of this being merged? |
|
I was hoping to get a signoff from either @lgierth or @diasdavid. |
|
Note: It looks like the multicodec definition still needs to be updated. |
|
On Sun, Jul 29, 2018 at 03:10:56PM -0700, Steven Allen wrote:
Note: It looks like the multicodec definition still needs to be updated.
Indeed. I updated the commit message but forgot to update the file.
Done.
…--
mwnx
GPG: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726
|
|
@mwnx need to push 😄. |
|
On Mon, Jul 30, 2018 at 08:14:49PM +0000, Steven Allen wrote:
@mwnx need to push :smile:.
I pushed but I'd never made the pull request...
multiformats/multicodec#79
…--
mwnx
GPG: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726
|
|
This PR also needs to be updated. |
|
On Mon, Jul 30, 2018 at 10:43:55PM +0000, Steven Allen wrote:
This PR also needs to be updated.
Oops again. And... fixed.
…--
mwnx
GPG: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726
|
|
Bump :) |
|
Still trying to get at least one other PL member to sign off on this. |
protocols.csv
Outdated
| @@ -4,6 +4,7 @@ code, size, name, comment | |||
| 17, 16, udp, | |||
| 33, 16, dccp, | |||
| 41, 128, ip6, | |||
| 42, V, zone, rfc4007 IPv6 zone | |||
There was a problem hiding this comment.
Can we make it more explicit and use ip6zone for the name?
There was a problem hiding this comment.
Yes let's go with /ip6zone -- these zones are about IPv6 only at the moment, and at the moment I don't see us generalizing this enough to fit other cases (similar to /dns4,6 vs. /dns).
|
Pinging the Lead Maintainer of the |
|
Sounds reasonable. I guess I'll wait for further confirmations before updating all the pull requests then? |
|
This looks good to me and the change to |
|
Makes sense to me! 👍 |
Can be prefixed to the "ip6" protocol. See [rfc4007]. [rfc4007] https://tools.ietf.org/html/rfc4007
|
On Wed, Aug 22, 2018 at 12:46:57AM -0700, David Dias wrote:
Make it more explicit and use `ip6zone` for the name instead
Done. Force-pushed on all 4 repositories.
…--
mwnx
GPG: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726
|
|
I guess we can still say "faster than the IETF", but that's not saying much. |
|
@mwnx mind making PRs against go-multiaddr now? |
|
On Mon, Sep 10, 2018 at 04:31:50PM -0700, Steven Allen wrote:
@mwnx mind making PRs against go-multiaddr now?
Just fixed the conflict in my go-multiaddr PR [1]. See also the
go-multiaddr-net PR [2].
[1] multiformats/go-multiaddr#69
[2] multiformats/go-multiaddr-net#42
…--
mwnx
GPG: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726
|
This is a generalization of the "ip6" multiaddr which accepts an
optional zone ID as specified in [rfc4007].
[rfc4007] https://tools.ietf.org/html/rfc4007
One probably controversial point is that I'm using a non alphanumeric character ('%') in the protocol string. I'll be happy to change it to a 'z' if there is the slightest objection.
See also: