Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement ipv6-address-token-id key (LP: #1737976) #161

Merged
merged 6 commits into from
Aug 31, 2020

Conversation

slyon
Copy link
Collaborator

@slyon slyon commented Aug 28, 2020

Description

This allows to statically configure the IPv6 host ID (low 64 bits) when auto-generated IPv6 addressing is used (i.e. DHCPv6 stateless, SLAAC).

It introduces one new YAML key in the schema: ipv6-address-token-id.

Fixes LP: #1737976

Checklist

@slyon slyon added the schema change This PR includes a change to netplan's YAML schema, which needs sign-off label Aug 28, 2020
@codecov-commenter
Copy link

codecov-commenter commented Aug 28, 2020

Codecov Report

Merging #161 into master will increase coverage by 0.03%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #161      +/-   ##
==========================================
+ Coverage   93.12%   93.15%   +0.03%     
==========================================
  Files           9        9              
  Lines        2618     2631      +13     
==========================================
+ Hits         2438     2451      +13     
  Misses        180      180              
Impacted Files Coverage Δ
src/networkd.c 100.00% <100.00%> (ø)
src/nm.c 100.00% <100.00%> (ø)
src/parse.c 97.65% <100.00%> (+0.01%) ⬆️
src/validation.c 87.31% <100.00%> (+0.19%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fd750e2...9b35145. Read the comment docs.

@slyon
Copy link
Collaborator Author

slyon commented Aug 28, 2020

Hey @vorlonofportland I'd like to get your opinion on the the schema key wording: ipv6-address-token-id
I wasn't really sure how to name it... what do you think about it?

@ghost
Copy link

ghost commented Aug 28, 2020

You could drop the id portion of the schema key. The noun in this case is token; there is no other identifier.

ipv6-address-token

@slyon
Copy link
Collaborator Author

slyon commented Aug 28, 2020

You could drop the id portion of the schema key. The noun in this case is token; there is no other identifier.

ipv6-address-token

Yeah... I was thinking about this as well... but this token is basically the "IPv6 interface identifier", so I wanted to add the -id part.
Maybe ipv6-interface-id would be a good name?

@ghost
Copy link

ghost commented Aug 28, 2020

That's actually not what a token is. A token allows the administrator to set the host portion of the address to a static value even though the rest of the configuration is some form of autoconfiguration. It has more to do with what address the interface winds up with than anything else. Also, interface ID is very ambiguous with other configuration elements. The only truly accurate and unambiguous name for this is ipv6-address-token.

Add: I shy away from attaching id to any configuration element that does not serve to uniquely identify the "thing" being configured. In this case, it's easy (and often done) to assign the same token value to every interface of a multi-homed system (e.g. router, firewall), so that the host portion of every interface on that system is, say, ::1. Since this configuration element does not need to be unique across interfaces in the same system, I would hesitate to attach id, since it doesn't function as an identifier at all.

src/parse.c Outdated Show resolved Hide resolved
src/parse.c Outdated Show resolved Hide resolved
src/validation.c Outdated
@@ -195,6 +195,9 @@ validate_netdef_grammar(NetplanNetDefinition* nd, yaml_node_t* node, GError** er
goto netdef_grammar_error;
}

if (nd->ip6_addr_gen_mode > NETPLAN_ADDRGEN_EUI64 && nd->ip6_addr_gen_token)
return yaml_error(node, error, "%s: ipv6-address-generation and ipv6-address-token-id are mutually exclusive", nd->id);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm uncomfortable with this being an inequality comparison. If other values are added to NetplanAddrGenMode in the future, what guarantees these checks are correct?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! I switched to a != NETPLAN_ADDRGEN_DEFAULT comparison, which makes it more explicit to fail if ipv6-address-generation is set in any way.

: Define an IPv6 address token for creating a static interface identifier for
IPv6 Stateless Address Autoconfiguration. This implies a slightly modified
``eui64`` mode and is mutually exclusive with ``ipv6-address-generation``.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the other PR comments: "token id" is redundant.

I also think that "token" itself is unclear; and at least in networkd, token is used to mean something other than just the id.

https://tools.ietf.org/html/rfc4862 mentions in Appendix B that they /used to/ use the term "interface token" but now say "interface identifier".

At https://developer.gnome.org/NetworkManager/stable/settings-ipv6.html, NetworkManager references draft-chown-6man-tokenised-ipv6-identifiers-02 for its definition of "token". But this also refers to "tokenized interface identifier" - so "interface identifier" is used consistently.

Therefore I recommend "ipv6-interface-identifier" as the key for this.

Copy link

@ghost ghost Aug 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The term used in iproute2, NetworkManager, systemd, etc. is "token." The token is not an interface identifier; labeling it as such is extremely misleading. The accurate key for this is, as stated, ipv6-address-token.

Ignore what I said previously. Apparently the terminology has been changed, as you stated. That's what I get for forgetting that technology and documentation are living entities; my apologies.

I would prefer something like ipv6-token-id, though it was said to be redundant earlier. I would prefer the term 'token' to be retained within the key, if only to provide some clarity/context.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree it's important that this be discoverable for people who are looking for "token", given that this term is used throughout iproute2, NetworkManager, and networkd as you mention (though, not with a consistent meaning).

Given that the term 'token' is deprecated in the RFCs, however, I don't like ipv6-token-id as this propagates the idea of a 'token' as something that new users are expected to understand.

My suggestions are either to use the ipv6-interface-identifier and reference 'token' in the documentation; or use ipv6-address-token.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much @cluonbeam and @vorlonofportland for your input!
I'm going with ipv6-address-token then, to keep it in line with the related ipv6-address-generation setting.

Copy link
Collaborator

@sil2100 sil2100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, this looks good. I see all Steve's review comments have also been addressed, so I think this is good to go.

@slyon slyon merged commit ee50582 into master Aug 31, 2020
@slyon slyon deleted the slyon/tokenized-ipv6-identifiers branch September 3, 2020 09:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
schema change This PR includes a change to netplan's YAML schema, which needs sign-off
Projects
None yet
4 participants