ipv6 iol intact certification

[kaies0007]

IPV6 IOL INTACT certification:

1-Test 'v6LC.2.2.25 (C): Recursive DNS (RDNSS) Option Expired' Failed

Test Description

1. TR1 to transmit Router Advertisement A with a lifetime 60 in the RDNSS Option.
2. Configure the HUT to transmit an Echo Request with a destination of 'node1.test.example.com'.
3. Observe the HUT transmitting a DNS Query to DNS-Server.
4. Wait 65 seconds.
5. Configure the HUT to transmit an Echo Request with a destination of node1.test.example.com.
6. Observe the HUT doesn't transmit a DNS Query to DNS-Server

Fail Reason

• openwrt doesn't support DNS server expiry time. We have to add support on odhcp6c , netifd and dhcpv6.script

Solution

• odhcp6c RA_DNS format is changed from RA_DNS="dns1 dns2 dns3 ..." to RA_DNS="dns1,valid1 dns2,valid2 dns3,valid3..."
• dhvpv6.script should parse the entries correctly and call 'proto_add_dns_server' using two arguments: proto_add_dns_server "$dns" "$lifetime"

2-Test 'v6LC.2.2.25 (F): Search List (DNSSL) Option Expired' Failed

Test Description

1. TR1 to transmit Router Advertisement A. The RDNSS Option has a lifetime that lasts the
2. entire test. The DNSSL Option has a lifetime of 60.
3. Configure the HUT to transmit an Echo Request with a destination of 'node1'.
4. Observe the HUT transmitting a DNS Query to DNS-Server.
5. Wait 65 seconds.
6. Configure the HUT to transmit an Echo Request with a destination of 'node1'.
7. Observe the HUT doesn't transmit a DNS Query to DNS-Server.

Fail Reason

• openwrt doesn't support search domain expiry time. We have to add support on odhcp6c, netifd and dhcpv6.script

Solution

• odhcp6c RA_DNS format is changed from RA_DOMAINS="domain1 domain2 domain3 ..." to RA_DOMAINS="domain1,valid1 domain2,valid2 domain3,valid3 ..."
• dhvpv6.script should parse the entries correctly and call 'proto_add_dns_search'
  using two arguments: proto_add_dns_search "$dns" "$lifetime"

3-Test 'v6LC.2.2.15 (A) RA Processing – Reachable Time' Failed

Test Description

1. TR1 transmits the Router Advertisement with a Router Lifetime of 0 seconds and a Reachable Time of 10 seconds.
2. TN1 transmits a link-local Echo Request to the HUT. TN1 must reply to any Neighbor Solicitations from the HUT.
3. The HUT should solicit for TN1’s link-local address and transmit an Echo Reply.
4. Repeat Step 2 every second for 40 seconds.
5. The HUT should transmit a Neighbor Solicitation with a Target Address of TN1’s link-local address at an interval between 10 and 20 seconds. [ReachableTime time (between 5 and 15 seconds) + DELAY_FIRST_PROBE_TIME (5 seconds)].
6. TR1 transmits the Router Advertisement with a Reachable Time of 40 seconds.
7. Repeat Step 2 every second for 140 seconds.
8. The HUT should transmit Neighbor Solicitations at an interval between 25 and 65 seconds. [ReachableTime time (between 20 and 60 seconds) + DELAY_FIRST_PROBE_TIME (5 seconds)].

Fail Reason

• reachable time isn't set correctly when we receive a Router Advertisement

Solution

-dhcpv6.script is writing on sysctl path : /proc/sys/net/ipv6/neigh/$device/base_reachable_time_ms and /proc/sys/net/ipv6/neigh/$device/retrans_time_ms when ra-updated is called with condition "$ADDRESSES$RA_ADDRESSES$PREFIXES$USERPREFIX" is not empty.
-RA is sent with Lifetime equal to Zero that mean that no ipv6 addresses are set mean that "$ADDRESSES$RA_ADDRESSES$PREFIXES$USERPREFIX" is false. We have to set configure sysctl params
even if no ipv6 address assigned according to RFC486:

If the received Reachable Time value is non-zero, the host SHOULD set
its BaseReachableTime variable to the received value. If the new
value differs from the previous value, the host SHOULD re-compute a
new random ReachableTime value. ReachableTime is computed as a
uniformly distributed random value between MIN_RANDOM_FACTOR and
MAX_RANDOM_FACTOR times the BaseReachableTime. Using a random
component eliminates the possibility that Neighbor Unreachability
Detection messages will synchronize with each other.

-We split the setup configuration to setup_interface_neigh and setup_interface. setup_interface_neigh should always be called.
-Modify REACHABLE TIME sysctl path only when we the value is changed and set 'gc_stale_time' three times reachable time
as the Kernel code source process when 'accept_ra' sysctl paramater is true.

[kaies0007]

related to pull requests in odhcp6c and netifd:
netifd: openwrt/netifd#46
odhp6c: openwrt/odhcp6c#97

[schuettecarsten]

@systemcrash @robimarko what do you think?

[systemcrash]

I suspect @kaies0007 meant RFC4861 - ND. This PR should target master first (then CP to 24 later).

@kaies0007 3-Test 'v6LC.2.2.15 (A) RA Processing – Reachable Time' Failed

Does HUT = TN1? Or "any other DUT" but TN1 or TR1

I fully support endeavours to have spec compliant behaviour in the IPv6 layer. ( Its flexibility is growing in more recent RFC for DHCPv6 and RA/ND, and open up more complex scenarios, but those newer behaviours generally depend on or update more historically defined behaviours ).

I would like to see a push to review and merge the PR for netifd, odhcpd, odhcp6c. There's LOTS of good stuff there being introduced, which has been tested. ( I know all of my PR there have been compiled, put on a DUT and run-tested and do as described. )

[robimarko]

@schuettecarsten I have no knowledge about this at all

[robimarko]

To follow this PR.

Please stop doing this, just click on the subscribe button

[kouellette]

Hi @systemcrash, I'm the lead developer of the IOL INTACT test tool that was mentioned in the PR summary. I just wanted to quickly pop in to answer your questions and let you know I'm happy to answer any other questions you or anyone else may have.

I suspect @kaies0007 meant RFC4861 - ND. This PR should target master first (then CP to 24 later).

Correct, this test references RFC 4861

@kaies0007 3-Test 'v6LC.2.2.15 (A) RA Processing – Reachable Time' Failed

Does HUT = TN1? Or "any other DUT" but TN1 or TR1

No, HUT stands for Host Under Test and can often be used interchangeably with Device Under Test (DUT). The two device types of a DUT can be host or router so we use HUT in this scenario since the processing of RA's is a Host specific capability and not applicable to routers.

I fully support endeavours to have spec compliant behaviour in the IPv6 layer. ( Its flexibility is growing in more recent RFC for DHCPv6 and RA/ND, and open up more complex scenarios, but those newer behaviours generally depend on or update more historically defined behaviours ).

I would like to see a push to review and merge the PR for netifd, odhcpd, odhcp6c. There's LOTS of good stuff there being introduced, which has been tested. ( I know all of my PR there have been compiled, put on a DUT and run-tested and do as described. )

[Neustradamus]

For information, I have sent an e-mail to @kaies0007 about this PR.