ADDRCONF: Defer dad for global address until dad for linklocal is completed.

IPV6 Toyo Abe 3 participants 10 messages May 20, 2008 – Jun 20, 2008

Subsystems (3)

Networking Network drivers IPv4/IPv6

lore

Share & tools

lore

Toyo Abe

author

2008-05-20 04:04 UTC #0 lore raw

When RA packet with prefix option is received during processing DAD for linklocal address, Linux initiates DAD for global address derived from the received prefix. It can be succeeded even if a duplicated linklocal address is detected.

RFC4862 5.4.5, which describes the behaviour on DAD failure, says;

If the address is a link-local address formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP operation on the interface SHOULD be disabled. By disabling IP operation, the node will then:

- not send any IP packets from the interface,

- silently drop any IP packets received on the interface, and

- not forward any IP packets to the interface (when acting as a router or processing a packet with a Routing header).

This problem was observed by testing with beta version of TAHI test suite (v4.0.0b2)
- Stateless Address Autoconfiguration test #3, #5, #14, and #15 force dad for linklocal to be failed and send RA to the host, then check if the host doesn't respond to DAD NS with respect to its global address. However, 2.6.26-rc2 send DAD NA in response to the DAD NS so the test scenarios were failed.

This patch fixes the problem by deferring DAD initiation for global address until DAD for linklocal address is completed. Now the failed test scenarios noted above are all passed.

Thank you,
-toyo

[IPV6] ADDRCONF: Defer dad for global address until dad for linklocal is completed.

RFC4862 5.4.5, which describes the behaviour on DAD failure, says;

- not send any IP packets from the interface,

- silently drop any IP packets received on the interface, and

- not forward any IP packets to the interface (when acting as a router or processing a packet with a Routing header).

This patch fixes the problem by deferring DAD initiation for global address until DAD for linklocal address is completed. Now the failed test scenarios noted above are all passed.

Signed-off-by Toyo Abe <[email protected]>

---
 include/linux/if_addr.h |    1 +
 net/ipv6/addrconf.c     |   62 ++++++++++++++++++++++++++++++++++++++++-------
 2 files changed, 54 insertions(+), 9 deletions(-)

include/linux/if_addr.h +1 -0

index 43f3bed..75ff0b8 100644
@@ -40,6 +40,7 @@ enum
 
 #define	IFA_F_NODAD		0x02
 #define IFA_F_OPTIMISTIC	0x04
+#define IFA_F_PENDDAD		0x08
 #define	IFA_F_HOMEADDRESS	0x10
 #define IFA_F_DEPRECATED	0x20
 #define IFA_F_TENTATIVE		0x40

net/ipv6/addrconf.c +53 -9

113 lines not on this page · raw message

YOSHIFUJI Hideaki / 吉藤英明

2008-05-20 08:33 UTC #1 lore raw

In article <[email protected]> (at Tue, 20 May 2008 12:37:54 +0900), Toyo Abe <[email protected]> says:

Quoted 3 lines

This patch fixes the problem by deferring DAD initiation for global address until DAD for linklocal address is completed. Now the failed test scenarios noted above are all passed.

Why don't we just ignore RA until DAD for link-local address has been successfully completed?

--yoshfuji

Toyo Abe

author

2008-05-20 12:27 UTC #2 lore raw

Yoshifuji-san,

Thanks for your response.

Quoted 2 lines

Why don't we just ignore RA until DAD for link-local address has been successfully completed?

I was also thinking so. And I tried it at first.
But then, many other test scenarios in TAHI test suite went to FAIL. It was because the tester node send RA with prefix option to the host right after it receives DAD NS from the host, which is obviously in autoconfiguration process for linklocal address.

Besides, RFC4862 section 4(protocol overview) says;
---
To speed the autoconfiguration process, a host may generate its link- local address (and verify its uniqueness) in parallel with waiting for a Router Advertisement. Because a router may delay responding to a Router Solicitation for a few seconds, the total time needed to complete autoconfiguration can be significantly longer if the two steps are done serially.
---

The text indicates that a host *may* accept RA including prefix option even before completion of DAD for linklocal address.
Since current addrconf code actually accepts RA including prefix option while DAD for linklocal address is processing, changes of the behaviour looks like a degradation for me. Hence, I chose to accept RA at that moment and defer sending DAD NS for global addresses.

Thanks,
-toyo

Quoted 12 lines · YOSHIFUJI Hideaki / 吉藤英明

In article <[email protected]> (at Tue, 20 May 2008 12:37:54 +0900), Toyo Abe <[email protected]> says:
Quoted 3 lines
This patch fixes the problem by deferring DAD initiation for global address until DAD for linklocal address is completed. Now the failed test scenarios noted above are all passed.
Why don't we just ignore RA until DAD for link-local address has been successfully completed?
--yoshfuji

Toyo Abe

author

2008-05-20 12:35 UTC #3 lore raw

Sorry for lack of explanation.

Quoted 3 lines

But then, many other test scenarios in TAHI test suite went to FAIL. It was because the tester node send RA with prefix option to the host right after it receives DAD NS from the host, which is obviously in autoconfiguration process for linklocal address.

And the tester node never accepts RS(es) from the host after sending the RA. The tester node determine FAIL unless it doesn't receive DAD NS for corresponding global address from the host.

-toyo

Quoted 45 lines · Toyo Abe

Yoshifuji-san,
Thanks for your response.
Quoted 2 lines
Why don't we just ignore RA until DAD for link-local address has been successfully completed?
I was also thinking so. And I tried it at first.
But then, many other test scenarios in TAHI test suite went to FAIL. It was because the tester node send RA with prefix option to the host right after it receives DAD NS from the host, which is obviously in autoconfiguration process for linklocal address.
Besides, RFC4862 section 4(protocol overview) says;
---
To speed the autoconfiguration process, a host may generate its link- local address (and verify its uniqueness) in parallel with waiting for a Router Advertisement. Because a router may delay responding to a Router Solicitation for a few seconds, the total time needed to complete autoconfiguration can be significantly longer if the two steps are done serially.
---
The text indicates that a host *may* accept RA including prefix option even before completion of DAD for linklocal address.
Since current addrconf code actually accepts RA including prefix option while DAD for linklocal address is processing, changes of the behaviour looks like a degradation for me. Hence, I chose to accept RA at that moment and defer sending DAD NS for global addresses.
Thanks,
-toyo
Quoted 12 lines · YOSHIFUJI Hideaki / 吉藤英明
In article <[email protected]> (at Tue, 20 May 2008 12:37:54 +0900), Toyo Abe <[email protected]> says:
Quoted 3 lines
This patch fixes the problem by deferring DAD initiation for global address until DAD for linklocal address is completed. Now the failed test scenarios noted above are all passed.
Why don't we just ignore RA until DAD for link-local address has been successfully completed?
--yoshfuji

Toyo Abe

author

2008-05-20 12:53 UTC #4 lore raw

sorry again. there was typo.

Quoted 4 lines · Toyo Abe

Sorry for lack of explanation.
Quoted 1 line
But then, many other test scenarios in TAHI test suite went to FAIL.
It was because

Quoted 8 lines

Quoted 1 line
the tester node send RA with prefix option to the host right after
it receives DAD NS
Quoted 1 line
from the host, which is obviously in autoconfiguration process for
linklocal address.
And the tester node never accepts RS(es) from the host after sending the RA. The tester node determine FAIL unless it doesn't receive DAD NS for corresponding global address from the host.

... unless it receives DAD NS for corresponding global address from the host

Quoted 56 lines

-toyo
Quoted 45 lines · Toyo Abe
Yoshifuji-san,
Thanks for your response.
Quoted 2 lines
Why don't we just ignore RA until DAD for link-local address has been successfully completed?
I was also thinking so. And I tried it at first.
But then, many other test scenarios in TAHI test suite went to FAIL. It was because the tester node send RA with prefix option to the host right after it receives DAD NS from the host, which is obviously in autoconfiguration process for linklocal address.
Besides, RFC4862 section 4(protocol overview) says;
---
To speed the autoconfiguration process, a host may generate its link- local address (and verify its uniqueness) in parallel with waiting for a Router Advertisement. Because a router may delay responding to a Router Solicitation for a few seconds, the total time needed to complete autoconfiguration can be significantly longer if the two steps are done serially.
---
The text indicates that a host *may* accept RA including prefix option even before completion of DAD for linklocal address.
Since current addrconf code actually accepts RA including prefix option while DAD for linklocal address is processing, changes of the behaviour looks like a degradation for me. Hence, I chose to accept RA at that moment and defer sending DAD NS for global addresses.
Thanks,
-toyo
Quoted 12 lines · YOSHIFUJI Hideaki / 吉藤英明
In article <[email protected]> (at Tue, 20 May 2008 12:37:54 +0900), Toyo Abe <[email protected]> says:
Quoted 3 lines
This patch fixes the problem by deferring DAD initiation for global address until DAD for linklocal address is completed. Now the failed test scenarios noted above are all passed.
Why don't we just ignore RA until DAD for link-local address has been successfully completed?
--yoshfuji
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

YOSHIFUJI Hideaki / 吉藤英明

2008-05-21 16:57 UTC #5 lore raw

In reply to Toyo Abe

In article <[email protected]> (at Tue, 20 May 2008 21:27:56 +0900), Toyo Abe <[email protected]> says:

Quoted 7 lines

I was also thinking so. And I tried it at first.
But then, many other test scenarios in TAHI test suite went to FAIL. It was because
the tester node send RA with prefix option to the host right after it receives DAD NS
from the host, which is obviously in autoconfiguration process for linklocal address.

If so, we should complain about the spec / tests.

Quoted 6 lines

Since current addrconf code actually accepts RA including prefix option while DAD for
linklocal address is processing, changes of the behaviour looks like a degradation for me.
Hence, I chose to accept RA at that moment and defer sending DAD NS for global addresses.

Well I don't think so.
We should choose simpler way - avoid introducing new "unique" state so far.

If you really think is worth accepting RA during DAD for link-local address, we should cancel all of on-going DADs for global address(es) if the RA for link-local address has failed, intead of deferring DAD for global address(es).

---
[RFC PATCH] [IPV6] ADDRCONF: Do not generate "global" address unless valid link-local address is available.

Signed-off-by YOSHIFUJI Hideaki <[email protected]>

---

net/ipv6/addrconf.c +8 -2

index e591e09..df99c5e 100644
@@ -1813,8 +1813,14 @@ void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len)
 
 		if (pinfo->prefix_len == 64) {
 			memcpy(&addr, &pinfo->prefix, 8);
-			if (ipv6_generate_eui64(addr.s6_addr + 8, dev) &&
-			    ipv6_inherit_eui64(addr.s6_addr + 8, in6_dev)) {
+			if (ipv6_inherit_eui64(addr.s6_addr + 8, in6_dev)) {
+				/*
+				 * If a valid link-local address is not found,
+				 * let's ignore autonomous flag.
+				 */
+				if (net_ratelimit())
+					printk(KERN_DEBUG "IPv6 addrconf: valid link-local address not found on %s\n",
+					       in6_dev->dev->name);
 				in6_dev_put(in6_dev);
 				return;
 			}

--yoshfuji

Toyo Abe

author

2008-05-21 17:30 UTC #6 lore raw

Quoted 10 lines · YOSHIFUJI Hideaki / 吉藤英明

In article <[email protected]> (at Tue, 20 May 2008 21:27:56 +0900), Toyo Abe <[email protected]> says:
Quoted 7 lines
I was also thinking so. And I tried it at first.
But then, many other test scenarios in TAHI test suite went to FAIL. It was because
the tester node send RA with prefix option to the host right after it receives DAD NS
from the host, which is obviously in autoconfiguration process for linklocal address.

Quoted 2 lines

If so, we should complain about the spec / tests.

Maybe so.
Well, did you observe the same problem?

Quoted 4 lines

Quoted 3 lines
Since current addrconf code actually accepts RA including prefix option while DAD for linklocal address is processing, changes of the behaviour looks like a degradation for me. Hence, I chose to accept RA at that moment and defer sending DAD NS for global addresses.

Quoted 8 lines

Well I don't think so.
We should choose simpler way - avoid introducing new "unique" state so far.
If you really think is worth accepting RA during DAD for link-local address, we should cancel all of on-going DADs for global address(es) if the RA for link-local address has failed, intead of deferring DAD for global address(es).

You're right. I agree with you that it'd be better than mine.

Thank you,
-toyo

David Miller

maintainer

2008-05-21 20:30 UTC #7 lore raw

From: Toyo Abe <[email protected]>
Date: Thu, 22 May 2008 02:30:52 +0900

Quoted 12 lines

Quoted 11 lines · YOSHIFUJI Hideaki / 吉藤英明
In article <[email protected]> (at Tue, 20 May 2008 21:27:56 +0900), Toyo Abe <[email protected]> says:
Quoted 6 lines
Since current addrconf code actually accepts RA including prefix option while DAD for
linklocal address is processing, changes of the behaviour looks like a degradation for me.
Hence, I chose to accept RA at that moment and defer sending DAD NS for global addresses.
Well I don't think so.
We should choose simpler way - avoid introducing new "unique" state so far.

Quoted 6 lines

Quoted 5 lines
If you really think is worth accepting RA during DAD for link-local address, we should cancel all of on-going DADs for global address(es) if the RA for link-local address has failed, intead of deferring DAD for global address(es).
You're right. I agree with you that it'd be better than mine.

Hideaki-san, let me know if I should apply your patch.

Thank you.

Toyo Abe

author

2008-06-20 02:17 UTC #8 lore raw

In reply to YOSHIFUJI Hideaki / 吉藤英明

Hi,

I'm wondering why the fix inlined below is not included.
I'd tested this fix w/ TAHI test suite. Then, the failed test cases - v6LC.3.1.2 Part B, Part D, v6LC.3.1.3 Part I, and Part J in IPv6 Stateless Address Autoconfiguration test - were all passed. If just waiting for verification info, I'm really sorry for the lazy response.

I think this can be merged.

Thank you,
-toyo

Quoted 53 lines · YOSHIFUJI Hideaki / 吉藤英明

In article <[email protected]> (at Tue, 20 May 2008 21:27:56 +0900), Toyo Abe <[email protected]> says:
Quoted 7 lines
I was also thinking so. And I tried it at first.
But then, many other test scenarios in TAHI test suite went to FAIL. It was because
the tester node send RA with prefix option to the host right after it receives DAD NS
from the host, which is obviously in autoconfiguration process for linklocal address.
If so, we should complain about the spec / tests.
Quoted 3 lines
Since current addrconf code actually accepts RA including prefix option while DAD for linklocal address is processing, changes of the behaviour looks like a degradation for me. Hence, I chose to accept RA at that moment and defer sending DAD NS for global addresses.
Well I don't think so.
We should choose simpler way - avoid introducing new "unique" state so far.
If you really think is worth accepting RA during DAD for link-local address, we should cancel all of on-going DADs for global address(es) if the RA for link-local address has failed, intead of deferring DAD for global address(es).
---
[RFC PATCH] [IPV6] ADDRCONF: Do not generate "global" address unless valid link-local address is available.
Signed-off-by YOSHIFUJI Hideaki <[email protected]>
---
net/ipv6/addrconf.c +8 -3
index e591e09..df99c5e 100644
@@ -1813,8 +1813,14 @@ void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len)
 
 		if (pinfo->prefix_len == 64) {
 			memcpy(&addr, &pinfo->prefix, 8);
-			if (ipv6_generate_eui64(addr.s6_addr + 8, dev) &&
-			    ipv6_inherit_eui64(addr.s6_addr + 8, in6_dev)) {
+			if (ipv6_inherit_eui64(addr.s6_addr + 8, in6_dev)) {
+				/*
+				 * If a valid link-local address is not found,
+				 * let's ignore autonomous flag.
+				 */
+				if (net_ratelimit())
+					printk(KERN_DEBUG "IPv6 addrconf: valid link-local address not found on %s\n",
+					       in6_dev->dev->name);
 				in6_dev_put(in6_dev);
 				return;
 			}
 
--yoshfuji

YOSHIFUJI Hideaki / 吉藤英明

2008-06-20 02:31 UTC #9 lore raw

In article <[email protected]> (at Fri, 20 Jun 2008 11:17:27 +0900), Toyo Abe <[email protected]> says:

Quoted 8 lines

Hi,
I'm wondering why the fix inlined below is not included.
I'd tested this fix w/ TAHI test suite. Then, the failed test cases - v6LC.3.1.2 Part B, Part D, v6LC.3.1.3 Part I, and Part J in IPv6 Stateless Address Autoconfiguration test - were all passed. If just waiting for verification info, I'm really sorry for the lazy response.
I think this can be merged.

Because it still an ad-hoc patch and I've been seeking better approach. I'll send it later.

Thank you for you patience.

--yoshfuji