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

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

[Toyo Abe]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

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

[-- Attachment #2: IPV6-ADDRCONF-Defer-dad-for-global-address-until-dad-for-linklocal-is-completed.patch --]
[-- Type: text/x-patch, Size: 5572 bytes --]

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

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.

Signed-off-by: Toyo Abe <tabe@miraclelinux.com>

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

diff --git a/include/linux/if_addr.h b/include/linux/if_addr.h
index 43f3bed..75ff0b8 100644
--- a/include/linux/if_addr.h
+++ b/include/linux/if_addr.h
@@ -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
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index e591e09..3080ded 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1532,21 +1532,20 @@ static int ipv6_generate_eui64(u8 *eui, struct net_device *dev)
 	return -1;
 }
 
-static int ipv6_inherit_eui64(u8 *eui, struct inet6_dev *idev)
+static struct inet6_ifaddr *ipv6_inherit_eui64(u8 *eui, struct inet6_dev *idev)
 {
-	int err = -1;
 	struct inet6_ifaddr *ifp;
 
 	read_lock_bh(&idev->lock);
 	for (ifp=idev->addr_list; ifp; ifp=ifp->if_next) {
-		if (ifp->scope == IFA_LINK && !(ifp->flags&IFA_F_TENTATIVE)) {
+		if (ifp->scope == IFA_LINK) {
+			in6_ifa_hold(ifp);
 			memcpy(eui, ifp->addr.s6_addr+8, 8);
-			err = 0;
 			break;
 		}
 	}
 	read_unlock_bh(&idev->lock);
-	return err;
+	return ifp;
 }
 
 #ifdef CONFIG_IPV6_PRIVACY
@@ -1808,13 +1807,13 @@ void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len)
 
 	if (pinfo->autoconf && in6_dev->cnf.autoconf) {
 		struct inet6_ifaddr * ifp;
+		struct inet6_ifaddr * ifl;
 		struct in6_addr addr;
 		int create = 0, update_lft = 0;
 
 		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 ((ifl = ipv6_inherit_eui64(addr.s6_addr + 8, in6_dev)) == NULL) {
 				in6_dev_put(in6_dev);
 				return;
 			}
@@ -1832,7 +1831,9 @@ ok:
 
 		if (ifp == NULL && valid_lft) {
 			int max_addresses = in6_dev->cnf.max_addresses;
-			u32 addr_flags = 0;
+			u32 addr_flags = IFA_F_PENDDAD;
+			struct inet6_dev *idev;
+			int dad_now = 0;
 
 #ifdef CONFIG_IPV6_OPTIMISTIC_DAD
 			if (in6_dev->cnf.optimistic_dad &&
@@ -1856,7 +1857,28 @@ ok:
 
 			update_lft = create = 1;
 			ifp->cstamp = jiffies;
-			addrconf_dad_start(ifp, RTF_ADDRCONF|RTF_PREFIX_RT);
+
+			/*
+			 * Defer dad for global address on the idev until
+			 * dad for linklocal is completed.
+			 */
+			idev = ifp->idev;
+			read_lock_bh(&idev->lock);
+			if (!(ifl->flags & IFA_F_TENTATIVE)) {
+				spin_lock(&ifp->lock);
+			    	if (ifp->flags & IFA_F_PENDDAD) {
+					ifp->flags &= ~IFA_F_PENDDAD;
+					dad_now = 1;
+				}
+				spin_unlock(&ifp->lock);
+			}
+			read_unlock_bh(&idev->lock);
+			/* Since we got a ifl->refcnt in ipv6_inherit_eui64(), release it. */
+			in6_ifa_put(ifl);
+
+			/* If dad for linklocal is already completed, start dad right away. */
+			if (dad_now)
+				addrconf_dad_start(ifp, RTF_ADDRCONF|RTF_PREFIX_RT);
 		}
 
 		if (ifp) {
@@ -2780,6 +2802,23 @@ out:
 	in6_ifa_put(ifp);
 }
 
+static void addrconf_dad_kick_pending(struct inet6_dev *idev) {
+	struct inet6_ifaddr *ifp;
+
+	read_lock_bh(&idev->lock);
+	for (ifp = idev->addr_list; ifp; ifp = ifp->if_next) {
+		spin_lock_bh(&ifp->lock);
+		if (!(ifp->flags & (IFA_F_TENTATIVE|IFA_F_PENDDAD))) {
+			spin_unlock_bh(&ifp->lock);
+			continue;
+		}
+		ifp->flags &= ~IFA_F_PENDDAD;
+		spin_unlock_bh(&ifp->lock);
+		addrconf_dad_kick(ifp);
+	}
+	read_unlock_bh(&idev->lock);
+}
+
 static void addrconf_dad_completed(struct inet6_ifaddr *ifp)
 {
 	struct net_device *	dev = ifp->idev->dev;
@@ -2790,6 +2829,11 @@ static void addrconf_dad_completed(struct inet6_ifaddr *ifp)
 
 	ipv6_ifa_notify(RTM_NEWADDR, ifp);
 
+	if ((dev->flags&IFF_LOOPBACK) == 0 &&
+	    (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
+		addrconf_dad_kick_pending(ifp->idev);
+	}
+
 	/* If added prefix is link local and forwarding is off,
 	   start sending router solicitations.
 	 */

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

[YOSHIFUJI Hideaki / 吉藤英明]

In article <48324792.5070309@miraclelinux.com> (at Tue, 20 May 2008 12:37:54 +0900), Toyo Abe <tabe@miraclelinux.com> says:

> 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

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

[Toyo Abe]

Yoshifuji-san,

Thanks for your response.

 > 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

YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <48324792.5070309@miraclelinux.com> (at Tue, 20 May 2008 
> 12:37:54 +0900), Toyo Abe <tabe@miraclelinux.com> says:
>
>> 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
>
>

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

[Toyo Abe]

Sorry for lack of explanation.

 > 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

Toyo Abe wrote:
> Yoshifuji-san,
>
> Thanks for your response.
>
> > 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
>
> YOSHIFUJI Hideaki / 吉藤英明 wrote:
>> In article <48324792.5070309@miraclelinux.com> (at Tue, 20 May 2008 
>> 12:37:54 +0900), Toyo Abe <tabe@miraclelinux.com> says:
>>
>>> 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
>>
>>
>
>

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

[Toyo Abe]

sorry again. there was typo.

Toyo Abe wrote:
> Sorry for lack of explanation.
>
> > 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.
... unless it receives DAD NS for corresponding global address from the host

>
>
> -toyo
>
> Toyo Abe wrote:
>> Yoshifuji-san,
>>
>> Thanks for your response.
>>
>> > 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
>>
>> YOSHIFUJI Hideaki / 吉藤英明 wrote:
>>> In article <48324792.5070309@miraclelinux.com> (at Tue, 20 May 2008 
>>> 12:37:54 +0900), Toyo Abe <tabe@miraclelinux.com> says:
>>>
>>>> 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
>>>
>>>
>>
>>
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[YOSHIFUJI Hideaki / 吉藤英明]

In article <4832C3CC.5070609@miraclelinux.com> (at Tue, 20 May 2008 21:27:56 +0900), Toyo Abe <tabe@miraclelinux.com> says:

> 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.

> 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 <yoshfuji@linux-ipv6.org>
---
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index e591e09..df99c5e 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -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

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

[Toyo Abe]

YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <4832C3CC.5070609@miraclelinux.com> (at Tue, 20 May 2008 21:27:56 +0900), Toyo Abe <tabe@miraclelinux.com> says:
> 
>> 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.
>
Maybe so.
Well, did you observe the same problem?


>> 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).
>
You're right. I agree with you that it'd be better than mine.

Thank you,
-toyo

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

[David Miller]

From: Toyo Abe <tabe@miraclelinux.com>
Date: Thu, 22 May 2008 02:30:52 +0900

> YOSHIFUJI Hideaki / 吉藤英明 wrote:
> > In article <4832C3CC.5070609@miraclelinux.com> (at Tue, 20 May 2008 21:27:56 +0900), Toyo Abe <tabe@miraclelinux.com> says:
> >> 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).
> >
> 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.

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

[Toyo Abe]

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

YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <4832C3CC.5070609@miraclelinux.com> (at Tue, 20 May 2008 21:27:56 +0900), Toyo Abe <tabe@miraclelinux.com> says:
> 
>> 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.
> 
>> 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 <yoshfuji@linux-ipv6.org>
> ---
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index e591e09..df99c5e 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -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
> 

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

[YOSHIFUJI Hideaki / 吉藤英明]

In article <485B1337.2000202@miraclelinux.com> (at Fri, 20 Jun 2008 11:17:27 +0900), Toyo Abe <tabe@miraclelinux.com> says:

> 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