Section 4 No. 9,10 Failed was occurred by IPv6 Ready Logo Conformance Test

DISCUSSION Yuki Machida 3 participants 7 messages Apr 1, 2016 – Apr 19, 2016

Subsystems (2)

Networking Network drivers

lore

Share & tools

lore

Yuki Machida

author

2016-04-01 07:31 UTC #0 lore raw

Hi all,

I tested 4.6-rc1 by IPv6 Ready Logo Core Conformance Test.
4.6-rc1 has some FAILs in Section 4 (RFC 1981: Path MTU Discovery for IP version 6). I conformed that it was PASSed in 3.14.28 and it was FAILed in 4.1.17. I will find a patch between 3.14 and 4.1.

IPv6 Ready Logo
https://www.ipv6ready.org/
TAHI Project
http://www.tahi.org/

I ran the IPv6 Ready Logo Core Conformance Test on Intel D510MO (Atom D510). It is using userland build with yocto project.

Test Environment
Test Specification : 4.0.6
Tool Version : REL_3_3_2
Test Program Version : V6LC_5_0_0
Target Device : Intel D510MO (Atom D510)

List of FAILs

Section 4: RFC 1981 - Path MTU Discovery for IPv6
- Test v6LC.4.1.6: Receiving MTU Below IPv6 Minimum Link MTU
- No. 9 Part A: MTU equal to 56
- No.10 Part B: MTU equal to 1279

Regards,
Yuki Machida

Rongqing Li

Acked-by YOSHIFUJI Hideaki Acked-by Hannes Frederic Sowa

2016-04-01 07:44 UTC #1 lore raw

Quoted 21 lines · Yuki Machida

Hi all,
I tested 4.6-rc1 by IPv6 Ready Logo Core Conformance Test.
4.6-rc1 has some FAILs in Section 4 (RFC 1981: Path MTU Discovery for IP version 6). I conformed that it was PASSed in 3.14.28 and it was FAILed in 4.1.17. I will find a patch between 3.14 and 4.1.
IPv6 Ready Logo
https://www.ipv6ready.org/
TAHI Project
http://www.tahi.org/
I ran the IPv6 Ready Logo Core Conformance Test on Intel D510MO (Atom D510). It is using userland build with yocto project.
Test Environment
Test Specification : 4.0.6
Tool Version : REL_3_3_2
Test Program Version : V6LC_5_0_0
Target Device : Intel D510MO (Atom D510)

Quoted 7 lines

List of FAILs
Section 4: RFC 1981 - Path MTU Discovery for IPv6
- Test v6LC.4.1.6: Receiving MTU Below IPv6 Minimum Link MTU
- No. 9 Part A: MTU equal to 56
- No.10 Part B: MTU equal to 1279

apply this one

commit 8013d1d7eafb0589ca766db6b74026f76b7f5cb4

Author: Hangbin Liu <[email protected]>
Date:   Thu Jul 30 14:28:42 2015 +0800

net/ipv6: add sysctl option accept_ra_min_hop_limit

Commit 6fd99094de2b ("ipv6: Don't reduce hop limit for an interface") disabled accept hop limit from RA if it is smaller than the current hop limit for security stuff. But this behavior kind of break the RFC
definition.

RFC 4861, 6.3.4. Processing Received Router Advertisements
A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time, and Retrans Timer) may contain a value denoting that it is unspecified. In such cases, the parameter should be ignored and the host should continue using whatever value it is already using.

If the received Cur Hop Limit value is non-zero, the host SHOULD set its CurHopLimit variable to the received value.

So add sysctl option accept_ra_min_hop_limit to let user choose the
minimum
hop limit value they can accept from RA. And set default to 1 to
meet RFC
standards.

Signed-off-by Hangbin Liu <[email protected]>

Acked-by YOSHIFUJI Hideaki <[email protected]>

Signed-off-by David S. Miller <[email protected]>

and revert the below one, the TAHI should be updated

commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2
Author: Hagen Paul Pfeifer <[email protected]>
Date: Thu Jan 15 22:34:25 2015 +0100

ipv6: stop sending PTB packets for MTU < 1280

Reduce the attack vector and stop generating IPv6 Fragment Header for paths with an MTU smaller than the minimum required IPv6 MTU size (1280 byte) - called atomic fragments.

See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1] for more information and how this "feature" can be misused.

[1]
https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00

Signed-off-by Fernando Gont <[email protected]>

Signed-off-by Hagen Paul Pfeifer <[email protected]>

Acked-by Hannes Frederic Sowa <[email protected]>

Signed-off-by David S. Miller <[email protected]>

-Roy

Quoted 3 lines

Regards,
Yuki Machida

Signature · 2 lines

Best Reagrds,
Roy | RongQing Li

Yuki Machida

author

2016-04-01 08:00 UTC #2 lore raw

Hi Roy,

Thank you for your advice.
I am very glad.

Futher comment below.

Quoted 60 lines · Rongqing Li

Quoted 21 lines · Yuki Machida
Hi all,
I tested 4.6-rc1 by IPv6 Ready Logo Core Conformance Test.
4.6-rc1 has some FAILs in Section 4 (RFC 1981: Path MTU Discovery for IP version 6). I conformed that it was PASSed in 3.14.28 and it was FAILed in 4.1.17. I will find a patch between 3.14 and 4.1.
IPv6 Ready Logo
https://www.ipv6ready.org/
TAHI Project
http://www.tahi.org/
I ran the IPv6 Ready Logo Core Conformance Test on Intel D510MO (Atom D510). It is using userland build with yocto project.
Test Environment
Test Specification : 4.0.6
Tool Version : REL_3_3_2
Test Program Version : V6LC_5_0_0
Target Device : Intel D510MO (Atom D510)
Quoted 7 lines
List of FAILs
Section 4: RFC 1981 - Path MTU Discovery for IPv6
- Test v6LC.4.1.6: Receiving MTU Below IPv6 Minimum Link MTU
- No. 9 Part A: MTU equal to 56
- No.10 Part B: MTU equal to 1279
apply this one
commit 8013d1d7eafb0589ca766db6b74026f76b7f5cb4
Author: Hangbin Liu <[email protected]>
Date:   Thu Jul 30 14:28:42 2015 +0800
net/ipv6: add sysctl option accept_ra_min_hop_limit
Commit 6fd99094de2b ("ipv6: Don't reduce hop limit for an interface") disabled accept hop limit from RA if it is smaller than the current hop limit for security stuff. But this behavior kind of break the RFC
definition.
RFC 4861, 6.3.4. Processing Received Router Advertisements
A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time, and Retrans Timer) may contain a value denoting that it is unspecified. In such cases, the parameter should be ignored and the host should continue using whatever value it is already using.
If the received Cur Hop Limit value is non-zero, the host SHOULD set its CurHopLimit variable to the received value.
So add sysctl option accept_ra_min_hop_limit to let user choose the
minimum
hop limit value they can accept from RA. And set default to 1 to
meet RFC
standards.

Quoted 3 lines

Signed-off-by Hangbin Liu <[email protected]>
Acked-by YOSHIFUJI Hideaki <[email protected]>
Signed-off-by David S. Miller <[email protected]>

I conformed that above patch has been applied at v4.3 in linux.git.

% git tag --contains=8013d1d7eafb0589ca766db6b74026f76b7f5cb4 | head v4.3
v4.3-rc1
v4.3-rc2
v4.3-rc3
v4.3-rc4
v4.3-rc5
v4.3-rc6
v4.3-rc7
v4.4
v4.4-rc1

Quoted 20 lines

and revert the below one, the TAHI should be updated
commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2
Author: Hagen Paul Pfeifer <[email protected]>
Date: Thu Jan 15 22:34:25 2015 +0100
ipv6: stop sending PTB packets for MTU < 1280
Reduce the attack vector and stop generating IPv6 Fragment Header for paths with an MTU smaller than the minimum required IPv6 MTU size (1280 byte) - called atomic fragments.
See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1] for more information and how this "feature" can be misused.

Quoted 7 lines

[1]
https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00
Signed-off-by Fernando Gont <[email protected]>
Signed-off-by Hagen Paul Pfeifer <[email protected]>
Acked-by Hannes Frederic Sowa <[email protected]>
Signed-off-by David S. Miller <[email protected]>

I will try.

Quoted 12 lines

-Roy
Quoted 3 lines
Regards,
Yuki Machida

Yuki Machida

author

2016-04-04 06:43 UTC #3 lore raw

Hi Roy,

Quoted 109 lines · Yuki Machida

Hi Roy,
Thank you for your advice.
I am very glad.
Futher comment below.
Quoted 60 lines · Rongqing Li
Quoted 21 lines · Yuki Machida
Hi all,
I tested 4.6-rc1 by IPv6 Ready Logo Core Conformance Test.
4.6-rc1 has some FAILs in Section 4 (RFC 1981: Path MTU Discovery for IP version 6). I conformed that it was PASSed in 3.14.28 and it was FAILed in 4.1.17. I will find a patch between 3.14 and 4.1.
IPv6 Ready Logo
https://www.ipv6ready.org/
TAHI Project
http://www.tahi.org/
I ran the IPv6 Ready Logo Core Conformance Test on Intel D510MO (Atom D510). It is using userland build with yocto project.
Test Environment
Test Specification : 4.0.6
Tool Version : REL_3_3_2
Test Program Version : V6LC_5_0_0
Target Device : Intel D510MO (Atom D510)
Quoted 7 lines
List of FAILs
Section 4: RFC 1981 - Path MTU Discovery for IPv6
- Test v6LC.4.1.6: Receiving MTU Below IPv6 Minimum Link MTU
- No. 9 Part A: MTU equal to 56
- No.10 Part B: MTU equal to 1279
apply this one
commit 8013d1d7eafb0589ca766db6b74026f76b7f5cb4
Author: Hangbin Liu <[email protected]>
Date:   Thu Jul 30 14:28:42 2015 +0800
net/ipv6: add sysctl option accept_ra_min_hop_limit
Commit 6fd99094de2b ("ipv6: Don't reduce hop limit for an interface") disabled accept hop limit from RA if it is smaller than the current hop limit for security stuff. But this behavior kind of break the RFC
definition.
RFC 4861, 6.3.4. Processing Received Router Advertisements
A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time, and Retrans Timer) may contain a value denoting that it is unspecified. In such cases, the parameter should be ignored and the host should continue using whatever value it is already using.
If the received Cur Hop Limit value is non-zero, the host SHOULD set its CurHopLimit variable to the received value.
So add sysctl option accept_ra_min_hop_limit to let user choose the
minimum
hop limit value they can accept from RA. And set default to 1 to
meet RFC
standards.
Quoted 3 lines
Signed-off-by Hangbin Liu <[email protected]>
Acked-by YOSHIFUJI Hideaki <[email protected]>
Signed-off-by David S. Miller <[email protected]>
I conformed that above patch has been applied at v4.3 in linux.git.
% git tag --contains=8013d1d7eafb0589ca766db6b74026f76b7f5cb4 | head v4.3
v4.3-rc1
v4.3-rc2
v4.3-rc3
v4.3-rc4
v4.3-rc5
v4.3-rc6
v4.3-rc7
v4.4
v4.4-rc1
Quoted 23 lines
and revert the below one, the TAHI should be updated
commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2
Author: Hagen Paul Pfeifer <[email protected]>
Date: Thu Jan 15 22:34:25 2015 +0100
ipv6: stop sending PTB packets for MTU < 1280
Reduce the attack vector and stop generating IPv6 Fragment Header for paths with an MTU smaller than the minimum required IPv6 MTU size (1280 byte) - called atomic fragments.
See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1] for more information and how this "feature" can be misused.
[1]
https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00

Quoted 6 lines

Quoted 4 lines
Signed-off-by Fernando Gont <[email protected]>
Signed-off-by Hagen Paul Pfeifer <[email protected]>
Acked-by Hannes Frederic Sowa <[email protected]>
Signed-off-by David S. Miller <[email protected]>
I will try.

I confirmed that v4.1.20 revert above patch is passed Section 4 No. 9 and 10 testcases in IPv6 Ready Logo Conformance Test.
I can't immediately revert above patch from v4.6-rc1 by implementation has changed.

I am considering how to fix this problem for mainline.

Quoted 13 lines

Quoted 13 lines
-Roy
Quoted 3 lines
Regards,
Yuki Machida

Yuki Machida

author

2016-04-15 08:47 UTC #4 lore raw

Hi,

I doesn't report this issue to contributers of commit 9d28971 yet. sorry.
I resend my information.

Regards,
Yuki Machida

-------- Forwarded Message --------
Subject: Re: Section 4 No. 9,10 Failed was occurred by IPv6 Ready Logo Conformance Test
Date: Mon, 4 Apr 2016 15:43:47 +0900
From: Yuki Machida <[email protected]>
To: Rongqing Li <[email protected]>, netdev <[email protected]>

Hi Roy,

Quoted 109 lines · Yuki Machida

Hi Roy,
Thank you for your advice.
I am very glad.
Futher comment below.
Quoted 60 lines · Rongqing Li
Quoted 21 lines · Yuki Machida
Hi all,
I tested 4.6-rc1 by IPv6 Ready Logo Core Conformance Test.
4.6-rc1 has some FAILs in Section 4 (RFC 1981: Path MTU Discovery for IP version 6). I conformed that it was PASSed in 3.14.28 and it was FAILed in 4.1.17. I will find a patch between 3.14 and 4.1.
IPv6 Ready Logo
https://www.ipv6ready.org/
TAHI Project
http://www.tahi.org/
I ran the IPv6 Ready Logo Core Conformance Test on Intel D510MO (Atom D510). It is using userland build with yocto project.
Test Environment
Test Specification : 4.0.6
Tool Version : REL_3_3_2
Test Program Version : V6LC_5_0_0
Target Device : Intel D510MO (Atom D510)
Quoted 7 lines
List of FAILs
Section 4: RFC 1981 - Path MTU Discovery for IPv6
- Test v6LC.4.1.6: Receiving MTU Below IPv6 Minimum Link MTU
- No. 9 Part A: MTU equal to 56
- No.10 Part B: MTU equal to 1279
apply this one
commit 8013d1d7eafb0589ca766db6b74026f76b7f5cb4
Author: Hangbin Liu <[email protected]>
Date:   Thu Jul 30 14:28:42 2015 +0800
net/ipv6: add sysctl option accept_ra_min_hop_limit
Commit 6fd99094de2b ("ipv6: Don't reduce hop limit for an interface") disabled accept hop limit from RA if it is smaller than the current hop limit for security stuff. But this behavior kind of break the RFC
definition.
RFC 4861, 6.3.4. Processing Received Router Advertisements
A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time, and Retrans Timer) may contain a value denoting that it is unspecified. In such cases, the parameter should be ignored and the host should continue using whatever value it is already using.
If the received Cur Hop Limit value is non-zero, the host SHOULD set its CurHopLimit variable to the received value.
So add sysctl option accept_ra_min_hop_limit to let user choose the
minimum
hop limit value they can accept from RA. And set default to 1 to
meet RFC
standards.
Quoted 3 lines
Signed-off-by Hangbin Liu <[email protected]>
Acked-by YOSHIFUJI Hideaki <[email protected]>
Signed-off-by David S. Miller <[email protected]>
I conformed that above patch has been applied at v4.3 in linux.git.
% git tag --contains=8013d1d7eafb0589ca766db6b74026f76b7f5cb4 | head v4.3
v4.3-rc1
v4.3-rc2
v4.3-rc3
v4.3-rc4
v4.3-rc5
v4.3-rc6
v4.3-rc7
v4.4
v4.4-rc1
Quoted 23 lines
and revert the below one, the TAHI should be updated
commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2
Author: Hagen Paul Pfeifer <[email protected]>
Date: Thu Jan 15 22:34:25 2015 +0100
ipv6: stop sending PTB packets for MTU < 1280
Reduce the attack vector and stop generating IPv6 Fragment Header for paths with an MTU smaller than the minimum required IPv6 MTU size (1280 byte) - called atomic fragments.
See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1] for more information and how this "feature" can be misused.
[1]
https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00

Quoted 6 lines

Quoted 4 lines
Signed-off-by Fernando Gont <[email protected]>
Signed-off-by Hagen Paul Pfeifer <[email protected]>
Acked-by Hannes Frederic Sowa <[email protected]>
Signed-off-by David S. Miller <[email protected]>
I will try.

I am considering how to fix this problem for mainline.

Quoted 13 lines

Quoted 13 lines
-Roy
Quoted 3 lines
Regards,
Yuki Machida

Hagen Paul Pfeifer

2016-04-15 13:59 UTC #5 lore raw

Quoted 23 lines · Yuki Machida

Quoted 22 lines
Quoted 21 lines
commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2
Author: Hagen Paul Pfeifer <[email protected]>
Date: Thu Jan 15 22:34:25 2015 +0100
ipv6: stop sending PTB packets for MTU < 1280
Reduce the attack vector and stop generating IPv6 Fragment Header for paths with an MTU smaller than the minimum required IPv6 MTU size (1280 byte) - called atomic fragments.
See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1] for more information and how this "feature" can be misused.
[1]
https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00
Signed-off-by Fernando Gont <[email protected]>
Signed-off-by Hagen Paul Pfeifer <[email protected]>
Acked-by Hannes Frederic Sowa <[email protected]>
Signed-off-by David S. Miller <[email protected]>

Quoted 5 lines

Quoted 1 line
I will try.
I confirmed that v4.1.20 revert above patch is passed Section 4 No. 9 and 10 testcases in IPv6 Ready Logo Conformance Test.
I can't immediately revert above patch from v4.6-rc1 by implementation has changed.

is it to please a conforming test tool or fix "revert 9d289715eb5c2" a real problem? If so: which problem do you have with 9d289715eb5c2 or draft-ietf-6man-deprecate-atomfrag-generation-06?

Hagen

Yuki Machida

author

2016-04-19 08:45 UTC #6 lore raw

Hi Hagen,

Quoted 23 lines · Hagen Paul Pfeifer

Quoted 23 lines · Yuki Machida
Quoted 22 lines
Quoted 21 lines
commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2
Author: Hagen Paul Pfeifer <[email protected]>
Date: Thu Jan 15 22:34:25 2015 +0100
ipv6: stop sending PTB packets for MTU < 1280
Reduce the attack vector and stop generating IPv6 Fragment Header for paths with an MTU smaller than the minimum required IPv6 MTU size (1280 byte) - called atomic fragments.
See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1] for more information and how this "feature" can be misused.
[1]
https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00
Signed-off-by Fernando Gont <[email protected]>
Signed-off-by Hagen Paul Pfeifer <[email protected]>
Acked-by Hannes Frederic Sowa <[email protected]>
Signed-off-by David S. Miller <[email protected]>

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
I will try.
I confirmed that v4.1.20 revert above patch is passed Section 4 No. 9 and 10 testcases in IPv6 Ready Logo Conformance Test.
I can't immediately revert above patch from v4.6-rc1 by implementation has changed.
is it to please a conforming test tool or fix "revert 9d289715eb5c2" a real problem? If so: which problem do you have with 9d289715eb5c2 or draft-ietf-6man-deprecate-atomfrag-generation-06?

Thank you for your reply.
I was wrong.

That real problem may not be 9d289715eb5c2,
Because Roy said "TAHI should be updated".

But I don't understand that real problem is in Test Tool or draft-ietf-6man-deprecate-atomfrag-generation-06. I am conforming it.

Regards,
Yuki Machida

Quoted 3 lines

Hagen