Repository navigation
network: Allow to specify multiple IPv6Token for SLAAC - #14415
Conversation
|
looks pretty good to me from a superficial review. I'll leave it to @yuwata to merge though. |
|
Ping @yuwata |
3a964d5 to
f2ebf4d
Compare
|
Updated thanks for the review @poettering @yuwata |
|
LGTM. I will test this later. |
f2ebf4d to
4a85ac8
Compare
|
updated thanks @yuwata |
|
LGTM. I will test this later. |
4a85ac8 to
6e8c031
Compare
|
@ssahani Updated. Fixed several errors in (And sorry for late to test this.) |
|
I am not sure not able to compile from couple of days |
6e8c031 to
cd1d682
Compare
|
Lgtm |
cd1d682 to
1a2aa72
Compare
|
hmmmm?? |
|
Ah, @mrc0mmand Is it possible to update the unit file systemd-networkd.service? Please see #14670. |
unit file in case a PR introduces changes in them See: systemd/systemd#14415 (comment)
Should be fixed by systemd/systemd-centos-ci@0a37f42. I re-triggered both failing jobs, but it may take a while, as there's already a queue of running jobs. |
|
@mrc0mmand Thanks! |
1a2aa72 to
3a23d22
Compare
|
@poettering Thank you for the comments. Updated. PTAL. |
3a23d22 to
47723b0
Compare
|
Rebased. |
|
@keszybz Could you review this? We already addressed all suggestions by @poettering. |
47723b0 to
8607ad6
Compare
|
Rebased again. @keszybz PTAL. |
keszybz
left a comment
There was a problem hiding this comment.
Looks pretty OK in general...
Provide names to choose between different auto-generation types: 2.1 "eui64" for EUI-64 of RFC 4291 2.2 "prefixstable" for RFC 7217 ``` [Match] Name=veth99 [Network] DHCP=no IPv6AcceptRA=yes IPv6Token=prefixstable:2001:888:0db8:1:: ```
8607ad6 to
87bbebe
Compare
|
@keszybz Thank you for the review. All points are addressed. PTAL. |
|
Thanks, LGTM. |
| the token is only ever used for SLAAC, and not for DHCPv6 addresses, even | ||
| in the case DHCP is requested by router advertisement. By default, the | ||
| token is autogenerated.</para> | ||
| <para>Specifies an optional address generation mechanism and an optional address prefix. If |
There was a problem hiding this comment.
This documentation is somewhat confusing to me; when eui64 mode is used, the supplied address is not a prefix, it's a suffix. Unless someone is already working on it, I'd be happy to send a PR to improve the documentation.
There was a problem hiding this comment.
As I read through the code my confusion is growing... as this 'eui64' mode replaces the existing unnamed 'static' mode where the user supplies the token (which may or may not have been generated using the EUI-64 mechanism). This is even evident in the eui64 test case, where a static token is supplied which is almost certainly not a valid EUI-64 Interface Identifer, but it is treated as such in the code.
Unless I'm mistaken, there should be three modes:
- static - user supplies the lowest 64 bits of address, generated in any fashion they wish
- eui64 - user does not (and cannot) supply an address but explicitly requests that an EUI-64 IiD be generated
- prefixstable - user supplies a prefix (of varying length) and an RFC7217 IID is generated
I know I'm coming into this discussion quite late and the PR has already been merged, but I'm currently a happy user of the 'static' mode and I wouldn't want anyone to use the 'eui64' label for that mode, or for any diagnostic or error messages to refer to 'eui64' mode when I didn't request it.
Provide names to choose between different auto-generation types:
2.1 "eui64" for EUI-64 of RFC 4291
2.2 "prefixstable" for RFC 7217
closes #6889