Host bits on prefix/route options are non-zero, can cause confusion.

robbat2 commented 7 years ago

If a route or prefix option in the configuration has more bits specified than the address length mask, Radvd should:

warn or error.
forcing the non-network bits to zero.
collapse now duplicate prefix/routes.

Specifications:

https://tools.ietf.org/html/rfc4861#section-4.6.2 page 30:

      Prefix         An IP address or a prefix of an IP address.  The
                     Prefix Length field contains the number of valid
                     leading bits in the prefix.  The bits in the prefix
                     after the prefix length are reserved and MUST be
                     initialized to zero by the sender and ignored by
                     the receiver.

Emphasis: The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender.

https://tools.ietf.org/html/rfc4191#section-2.3 page 5:

   Routers MUST NOT include two Route Information Options with the same
   Prefix and Prefix Length in the same Router Advertisement.

Splitting options in this case between two immediately sequential Router Advertisements should be considered as a case of a single long RA (of a link with infinite MTU).

Sample configuration input:

    prefix fd3c:b2e8:93df:1:2::/64 { };
    prefix fd3c:b2e8:93df:1:3::/64 { };
    route fd3c:b2e8:93df:cafe:f0fe::/64 { };
    route fd3c:b2e8:93df:cafe:f0ff::/64 { };

actual tcpdump:

prefix info option (3), length 32 (4): fd3c:b2e8:93df:1:2::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
prefix info option (3), length 32 (4): fd3c:b2e8:93df:1:3::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
route info option (24), length 24 (3):  fd3c:b2e8:93df:cafe:f0fe::/64, pref=medium, lifetime=5400s
route info option (24), length 24 (3):  fd3c:b2e8:93df:cafe:f0ff::/64, pref=medium, lifetime=5400s

expected tcpdump:

prefix info option (3), length 32 (4): fd3c:b2e8:93df:1::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
route info option (24), length 24 (3):  fd3c:b2e8:93df:cafe::/64, pref=medium, lifetime=5400s

Problems to discuss:

What happens when the route/prefixes in the configuration have DIFFERENT parameters? How should Radvd handle it?

robbat2 commented 6 years ago

A further case that needs special handling:

    prefix ::/64 { AdvValidLifetime 3600; };
    prefix fd3c:b2e8:93df:1:2::/64 { AdvValidLifetime 86400; };

vs.

    prefix fd3c:b2e8:93df:1:2::/64 { AdvValidLifetime 86400; };
    prefix ::/64 { AdvValidLifetime 3600; };

How should prefix fd3c:b2e8:93df:1:2::/64 be handled? On Linux hosts, this is treated as two seperate RAs, and the lifetime is seen flapping.

This is even more problematic when you want use prefix ::/64, but suppress a single prefix from it.

reubenhwk commented 6 years ago

Hmmm... I think radvd should mask out the bits beyond the prefix, but this may break existing configurations out there.

As for the ::/64, I'm not sure.. I suspect leaving it as is and letting it flap is possibly ok. Mixing automatic prefixes with explicit ones seems error prone to me. I think the way to handle that error would be to tell the user to remove the address with that prefix from that interface so it wouldn't be picked up by the ::/64 code.

I don't think the ::/64 code was not intended to be used in conjunction with other prefixes. The whole idea is you don't know what the prefix is so just use whatever my interface has...

On Mon, Oct 30, 2017 at 2:52 PM, Robin H. Johnson notifications@github.com wrote:

A further case that needs special handling:
prefix ::/64 { AdvValidLifetime 3600; };
prefix fd3c:b2e8:93df:1:2::/64 { AdvValidLifetime 86400; };
vs.
prefix fd3c:b2e8:93df:1:2::/64 { AdvValidLifetime 86400; };
prefix ::/64 { AdvValidLifetime 3600; };
How should prefix fd3c:b2e8:93df:1:2::/64 be handled? On Linux hosts, this is treated as two seperate RAs, and the lifetime is seen flapping.

This is even more problematic when you want use prefix ::/64, but suppress a single prefix from it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/reubenhwk/radvd/issues/67#issuecomment-340596219, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMTe3RAx1qc7JOG2l9e3yZhKDVaSZPTks5sxkU5gaJpZM4K6QAG .

robbat2 commented 6 years ago

I ask about the combination case because I recently encountered it inside Ubiquiti EdgeRouters when using DHCPv6-PD. It runs radvd with a prefix ::/64, and then the PD daemon rotates the addresses on the interface as pushed by the ISP. If you want to also run your own ULA address, with different parameter, you get the the duplicate prefix in the RA along with the flap. Or worse, if you wanted to have AdvAutonomous off on the ULA prefix, you're stuck, because the unspecified prefix causes it to be sent :-(.

reubenhwk commented 6 years ago

I guess what will have to be done is we’ll need to decide which one take priority and code it up accordingly, and update the man page with the new behavior.

Sent from my iPhone

On Oct 31, 2017, at 12:16 PM, Robin H. Johnson notifications@github.com wrote:

I ask about the combination case because I recently encountered it inside Ubiquiti EdgeRouters when using DHCPv6-PD. It runs radvd with a prefix ::/64, and then the PD daemon rotates the addresses on the interface as pushed by the ISP. If you want to also run your own ULA address, with different parameter, you get the the duplicate prefix in the RA along with the flap. Or worse, if you wanted to have AdvAutonomous off on the ULA prefix, you're stuck, because the unspecified prefix causes it to be sent :-(.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

reubenhwk commented 6 years ago

I think the auto prefix should NOT take priority over a static one. What do you think?

Sent from my iPhone

On Oct 31, 2017, at 12:16 PM, Robin H. Johnson notifications@github.com wrote:

I ask about the combination case because I recently encountered it inside Ubiquiti EdgeRouters when using DHCPv6-PD. It runs radvd with a prefix ::/64, and then the PD daemon rotates the addresses on the interface as pushed by the ISP. If you want to also run your own ULA address, with different parameter, you get the the duplicate prefix in the RA along with the flap. Or worse, if you wanted to have AdvAutonomous off on the ULA prefix, you're stuck, because the unspecified prefix causes it to be sent :-(.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

robbat2 commented 6 years ago

I think we can give ourselves easy flexibility: Introduce a priority param for prefixes.

Highest value wins.
Defaults to some middle number: Auto could have a lower default than static.
Settings taken for each unique prefix with highest priority.

robbat2 commented 6 years ago

HostBits: Thinking about your concern in breaking existing configs, adding a new toplevel (command-line arg?) or interface option, for strict RFC, so it masks the hostbits?

reubenhwk commented 6 years ago

I’m leaning toward just doing RFC spec. I’m having doubts that if anybody is doing that that it would work as expected.

Sent from my iPhone

On Oct 31, 2017, at 12:48 PM, Robin H. Johnson notifications@github.com wrote:

HostBits: Thinking about your concern in breaking existing configs, adding a new toplevel (command-line arg?) or interface option, for strict RFC, so it masks the hostbits?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

Neustradamus commented 4 years ago

Any news?

radvd-project / radvd