ipv6 iol intact certification #97
Conversation
-During the testing process for the IOL INTACT cetification for IPv6, we discovered some issues: Test 'v6LC.2.2.25 (C): Recursive DNS (RDNSS) Option Expired' Failed because RDNSS lifetime is not supported. Test Description: - TR1 to transmit Router Advertisement A with a lifetime 60 in the RDNSS Option. - Configure the HUT to transmit an Echo Request with a destination of 'node1.test.example.com'. - Observe the HUT transmitting a DNS Query to DNS-Server. - Wait 65 seconds. - Configure the HUT to transmit an Echo Request with a destination of node1.test.example.com. - Observe the HUT doesn't transmit a DNS Query to DNS-Server Solution: odhcp6c read RDNSS lifetime from RA and save it but never use it. It should be passed to /lib/netifd/dhcpv6.script via RA_DNS environment variable. entry_to_env function should include entries 'valid' element in the env variable (RA_DNS) when type is ENTRY_HOST. Signed-off-by: kaies Chaouch <kc@simonwunderlich.de>
-During the testing process for the IOL INTACT cetification for IPv6, we discovered some issues: Test 'v6LC.2.2.25 (F): Search List (DNSSL) Option Expired' Failed because DNSSL lifetime is not supported. Test Description: - TR1 to transmit Router Advertisement A. The RDNSS Option has a lifetime that lasts the entire test. The DNSSL Option has a lifetime of 60. - Configure the HUT to transmit an Echo Request with a destination of 'node1'. - Observe the HUT transmitting a DNS Query to DNS-Server. - Wait 65 seconds. - Configure the HUT to transmit an Echo Request with a destination of 'node1'. - Observe the HUT doesn't transmit a DNS Query to DNS-Server. Solution: odhcp6c read DNSSL lifetime from RA and save it but never use it. It should be passed to /lib/netifd/dhcpv6.script via RA_DOMAINS environment variable. search_to_env function should include entries 'valid' element in the env variable RA_DOMAINS. Signed-off-by: kaies Chaouch <kc@simonwunderlich.de>
-The minimum value of Valid Lifetime should be set to 2 hours only for the prefix address
and not for the onlink route.If device receive L-bit set and Lifetime zero,
onlink route should be removed. We should to respect RFC 8461 6.3.4
The only way to cancel a previous on-link indication is to advertise that prefix with the
L-bit set and the Lifetime set to zero
-Fix Adress Valid Lifetime condition to respect RFC 2462 5.5.3 e
If the advertised prefix matches the prefix of an autoconfigured
address (i.e., one obtained via stateless or stateful address
autoconfiguration) in the list of addresses associated with the
interface, the specific action to perform depends on the Valid
Lifetime in the received advertisement and the Lifetime
associated with the previously autoconfigured address (which we
call StoredLifetime in the discussion that follows):
1) If the received Lifetime is greater than 2 hours or greater
than StoredLifetime, update the stored Lifetime of the
corresponding address.
2) If the StoredLifetime is less than or equal to 2 hours and the
received Lifetime is less than or equal to StoredLifetime,
ignore the prefix, unless the Router Advertisement from which
this Prefix Information option was obtained has been
authenticated (e.g., via IPSec [RFC2402]). If the Router
Advertisment was authenticated, the StoredLifetime should be
set to the Lifetime in the received option.
3) Otherwise, reset the stored Lifetime in the corresponding
address to two hours.
Signed-off-by: kaies Chaouch <kc@simonwunderlich.de>
|
related to pull requests in openwrt and netifd: |
|
To follow this PR. |
|
@Noltari, @systemcrash: Have you seen this PR? |
@Neustradamus please stop pinging people for no reason. |
|
These look like cogent fixes to the stated problems in the commit messages. Recommend testing or understanding the function of the modified code-blocks more deeply to judge. |
| if ((pinfo->nd_opt_pi_flags_reserved & ND_OPT_PI_FLAG_ONLINK) && | ||
| !ptp_link) | ||
| changed |= odhcp6c_update_entry(STATE_RA_ROUTE, entry, | ||
| 7200, ra_holdoff_interval); | ||
| 0, ra_holdoff_interval); |
There was a problem hiding this comment.
This part regards when the onlink bit is set. But your commits mentions RFC 8461 - which regards MTA. Did you mean RFC 4861?????
In any case, the RFC 2462 part you refer to is updated by https://www.rfc-editor.org/rfc/rfc4862#section-5.5.3 (and potentially later RFC)
And that regards the Autonomous flag and not the onlink flag.
So I'm not sure why we set it to 0 here.
There was a problem hiding this comment.
PErhaps you mean this bit?:
For each Prefix Information option with the on-link flag set, a host
does the following:
- If the prefix is the link-local prefix, silently ignore the
Prefix Information option.
- If the prefix is not already present in the Prefix List, and the
Prefix Information option's Valid Lifetime field is non-zero,
create a new entry for the prefix and initialize its
invalidation timer to the Valid Lifetime value in the Prefix
Information option.
- If the prefix is already present in the host's Prefix List as
the result of a previously received advertisement, reset its
invalidation timer to the Valid Lifetime value in the Prefix
Information option. If the new Lifetime value is zero, time-out
the prefix immediately (see [Section 6.3.5](https://www.rfc-editor.org/rfc/rfc4861.html#section-6.3.5)).
- If the Prefix Information option's Valid Lifetime field is zero,
and the prefix is not present in the host's Prefix List,
silently ignore the option.
There was a problem hiding this comment.
The RFC is about a prefixes, but this line is about the route. For the prefixes, there is still the 7200 with this PR.
|
For RA_DNS and RA_DOMAINS, this changes the API (env vars in the script) without updating the Readme. And it depends on the linked PRs.
|
| /* update Address lifetime (RFC2462 5.5.3 e) */ | ||
| if (x && x->valid > new->valid && new->valid < safe) | ||
| new->valid = safe; | ||
| new->valid = (x->valid < safe) ? x->valid : safe; |
There was a problem hiding this comment.
If the received Valid Lifetime is greater than 2 hours or
greater than RemainingLifetime, set the valid lifetime of the
corresponding address to the advertised Valid Lifetime.
This would be
if (new->valid > safe || new->valid > x->valid) {keep the provided value}
If RemainingLifetime is less than or equal to 2 hours, ignore
the Prefix Information option with regards to the valid
lifetime [...]
This would be
else if (x->valid <= safe) new->valid = x->valid
Otherwise, reset the valid lifetime of the corresponding
address to 2 hours.
would be
else { new->valid = safe }
As the first case does nothing, we invert it:
if (new->valid <= safe && new->valid <= x->valid) {other cases}
And this looks like an off by one for both parts of the if condition.
Two cases remain. They look correct according to the remaining rules but still with an off by one.
It would be clever to write the more verbose code as I did here with quotes from the RFC to help readers in the future.
There was a problem hiding this comment.
For safe = zero, new->valid < safe should never be true (to disable this logic), but this depends on the used data types.
There was a problem hiding this comment.
@l-jonas could you cook up a PR please? Evidently it looks like you experience this corner case and know how to tackle it properly, so you can validate code in production also.
5 participants
No description provided.