On Wed, Feb 21, 2007 at 01:30:31AM -0800, David Miller wrote:
> From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> Date: Wed, 21 Feb 2007 17:15:45 +0900 (JST)
>
> > In article <[EMAIL PROTECTED]> (at Wed, 21 Feb 2007 00:02:22 -0800 (PST)),
> > David Miller <[EMAIL PROTECTED]> says:
> >
> > > > So, I
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Wed, 21 Feb 2007 17:15:45 +0900 (JST)
> In article <[EMAIL PROTECTED]> (at Wed, 21 Feb 2007 00:02:22 -0800 (PST)),
> David Miller <[EMAIL PROTECTED]> says:
>
> > > So, I think it is ready. Here's my sign-off:
> > >
> > > Signed-off-by: YOSHIFUJI
In article <[EMAIL PROTECTED]> (at Wed, 21 Feb 2007 00:02:22 -0800 (PST)),
David Miller <[EMAIL PROTECTED]> says:
> > So, I think it is ready. Here's my sign-off:
> >
> > Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
>
> Neil, please keep this patch ready for the next merge window.
Dave
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Wed, 14 Feb 2007 06:46:49 +0900 (JST)
> In article <[EMAIL PROTECTED]> (at Tue, 13 Feb 2007 15:45:15 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
> > Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
>
> I'm starting regression tests now.
Tha
In article <[EMAIL PROTECTED]> (at Tue, 13 Feb 2007 15:45:15 -0500), Neil
Horman <[EMAIL PROTECTED]> says:
> Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
I'm starting regression tests now.
--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
>I still have a question. Now, who will install the kernel route for
> > the incoming packet? Can we get packet for our unicast address during
> > optimistic DAD period?
As per Yoshifjui's observation, the current patch doesn't currently allow for
the reception of inbound packets to our optimis
On Tue, Feb 13, 2007 at 08:27:59AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Thu, 8 Feb 2007 08:07:15 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
> > > I still have a question. Now, who will install the kernel route for
> > > the incoming packet? Can we g
In article <[EMAIL PROTECTED]> (at Thu, 8 Feb 2007 08:07:15 -0500), Neil Horman
<[EMAIL PROTECTED]> says:
> > I still have a question. Now, who will install the kernel route for
> > the incoming packet? Can we get packet for our unicast address during
> > optimistic DAD period?
> >
> Not sure
>
> New patch attached with these fixes included
>
>
Ping? Any further thoughts here? My (allbeit limited) testing seems to be going
fairly well so far...
Neil
> Thanks & Regards
> Neil
>
> Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
>
>
> include/linux/if_addr.h |1
> include/linu
On Fri, Feb 09, 2007 at 02:10:37AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Thu, 8 Feb 2007 11:41:52 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
>
> These should be placed
>
> > }
>
> here. No?
>
Yes, you're right. After re-reading the logic, its
In article <[EMAIL PROTECTED]> (at Thu, 8 Feb 2007 11:41:52 -0500), Neil Horman
<[EMAIL PROTECTED]> says:
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 7b7bd44..07a5f4d 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -859,6 +859,40 @@ static int ip6_
On Thu, Feb 08, 2007 at 07:26:20AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Wed, 7 Feb 2007 15:55:03 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
> > @@ -559,7 +562,7 @@ void ndisc_send_ns(struct net_device *dev, struct
> > neighbour *neigh,
> >
On Thu, Feb 08, 2007 at 06:52:06AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Wed, 7 Feb 2007 15:55:03 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
> > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> > index 7b7bd44..8a1ea96 100644
> > --- a/net/
In article <[EMAIL PROTECTED]> (at Wed, 7 Feb 2007 15:55:03 -0500), Neil Horman
<[EMAIL PROTECTED]> says:
> @@ -559,7 +562,7 @@ void ndisc_send_ns(struct net_device *dev, struct
> neighbour *neigh,
> return;
>
> len = sizeof(struct icmp6hdr) + sizeof(struct in6_addr);
> -
In article <[EMAIL PROTECTED]> (at Wed, 7 Feb 2007 15:55:03 -0500), Neil Horman
<[EMAIL PROTECTED]> says:
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 7b7bd44..8a1ea96 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -859,6 +859,34 @@ static int ip6_
Darn... and it was looking so good...
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 7b7bd44..8a1ea96 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -859,6 +859,34 @@ static int ip6_dst_lookup_tail(struct sock *sk,
> err = ipv6_get_sadd
On Tue, Feb 06, 2007 at 04:13:25PM -0500, Vlad Yasevich wrote:
> Hi Neil
>
> a few comments. sorry, just can't resist... :)
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Its really ok :). Brian found some other minor typos as well. I've attached
the latest patch which ta
Hi Neil
a few comments. sorry, just can't resist... :)
> @@ -2627,6 +2673,9 @@ static void addrconf_dad_completed(struct inet6_ifaddr
> *ifp)
>* Configure the address for reception. Now it is valid.
>*/
>
> + if (ifp->flags & IFA_F_OPTIMISTIC)
> + addrcon
On Tue, Feb 06, 2007 at 07:51:44AM -0500, Neil Horman wrote:
> On Tue, Feb 06, 2007 at 10:24:05AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> > Hello.
> >
>
> Thank you Yoshifuji. To be honest, I've been focused on functionality rather
Ok, New patch attached, taking Vlad and Yoshifujis latest comm
On Tue, Feb 06, 2007 at 10:24:05AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> Hello.
>
Thank you Yoshifuji. To be honest, I've been focused on functionality rather
than pretty so far, figuring I'd clean up the tabbing from my various patch
inclusions/reversions when we had agreed that the function
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Tue, 06 Feb 2007 10:44:08 +0900 (JST)
> Yes, I agree, but I think it is different issue, and
> maybe, we should check and change other places as well,
> in separate patch(es).
I agree.
-
To unsubscribe from this list: send the line "unsubscribe ne
In article <[EMAIL PROTECTED]> (at Mon, 05 Feb 2007 17:32:58 -0800 (PST)),
David Miller <[EMAIL PROTECTED]> says:
> From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> Date: Tue, 06 Feb 2007 10:24:05 +0900 (JST)
>
> > > @@ -498,7 +500,8 @@ static void ndisc_send_na(struct net_device *dev,
> > > struc
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Tue, 06 Feb 2007 10:24:05 +0900 (JST)
> > @@ -498,7 +500,8 @@ static void ndisc_send_na(struct net_device *dev,
> > struct neighbour *neigh,
> > msg->icmph.icmp6_unused = 0;
> > msg->icmph.icmp6_router= router;
> > m
Hello.
In article <[EMAIL PROTECTED]> (at Mon, 5 Feb 2007 15:56:51 -0500), Neil Horman
<[EMAIL PROTECTED]> says:
> if (ifp == NULL && valid_lft) {
> int max_addresses = in6_dev->cnf.max_addresses;
> + u32 addr_flags = 0;
> +
> +#ifdef CONF
On Mon, Feb 05, 2007 at 12:33:55PM -0500, Brian Haley wrote:
> >Please, if you think you can find a way for us to do optimistic dad flags
> >as
> >opt-in, rather than masked out, I'm all for it. Thanks!
>
> This patch should apply on-top of yours, if you want I can send the
> whole thing out to
Please, if you think you can find a way for us to do optimistic dad flags as
opt-in, rather than masked out, I'm all for it. Thanks!
This patch should apply on-top of yours, if you want I can send the
whole thing out too. I've only compile-tested it, so don't know if it
behaves the same as y
On Fri, Feb 02, 2007 at 06:57:37PM -0500, Brian Haley wrote:
> Hi Vlad,
>
> Vlad Yasevich wrote:
> >Brian Haley wrote:
> >>Hi Neil,
> >>
> >>>@@ -830,7 +836,8 @@ retry:
> >>> ift = !max_addresses ||
> >>> ipv6_count_addresses(idev) < max_addresses ?
> >>>ipv6_add_addr(idev,
On Fri, Feb 02, 2007 at 05:22:31PM -0500, Vlad Yasevich wrote:
> Neil Horman wrote:
> > On Fri, Feb 02, 2007 at 11:46:08AM -0800, David Miller wrote:
> >> From: Neil Horman <[EMAIL PROTECTED]>
> >> Date: Fri, 2 Feb 2007 14:06:34 -0500
> >>
> >>> Ok, I'm still testing it, but heres a new patch for r
On Fri, Feb 02, 2007 at 04:50:35PM -0500, Vlad Yasevich wrote:
> Neil Horman wrote:
> > Ok, I'm still testing it, but heres a new patch for review. Significant
> > changes
> > include the addition of a CONFIG_IPV6_OPTIMISTIC_DAD option that is
> > dependent on
> > the inclusion of both IPPV6 and
Hi Vlad,
Vlad Yasevich wrote:
Brian Haley wrote:
Hi Neil,
@@ -830,7 +836,8 @@ retry:
ift = !max_addresses ||
ipv6_count_addresses(idev) < max_addresses ?
ipv6_add_addr(idev, &addr, tmp_plen,
- ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
IFA_F_TEMPORA
Neil Horman wrote:
> On Fri, Feb 02, 2007 at 11:46:08AM -0800, David Miller wrote:
>> From: Neil Horman <[EMAIL PROTECTED]>
>> Date: Fri, 2 Feb 2007 14:06:34 -0500
>>
>>> Ok, I'm still testing it, but heres a new patch for review.
>>> Significant changes include the addition of a
>>> CONFIG_IPV6_OP
Brian Haley wrote:
> Hi Neil,
>
>> @@ -830,7 +836,8 @@ retry:
>> ift = !max_addresses ||
>>ipv6_count_addresses(idev) < max_addresses ?
>> ipv6_add_addr(idev, &addr, tmp_plen,
>> - ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
>> IFA_F_TEMPORARY) : NULL;
>>
Neil Horman wrote:
> Ok, I'm still testing it, but heres a new patch for review. Significant
> changes
> include the addition of a CONFIG_IPV6_OPTIMISTIC_DAD option that is dependent
> on
> the inclusion of both IPPV6 and EXPERIMENTAL options, as well as a new method
> for redirecting packets fr
Hi Neil,
@@ -830,7 +836,8 @@ retry:
ift = !max_addresses ||
ipv6_count_addresses(idev) < max_addresses ?
ipv6_add_addr(idev, &addr, tmp_plen,
- ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
IFA_F_TEMPORARY) : NULL;
+ ipv6_addr_type(&addr)&I
On Fri, Feb 02, 2007 at 11:46:08AM -0800, David Miller wrote:
> From: Neil Horman <[EMAIL PROTECTED]>
> Date: Fri, 2 Feb 2007 14:06:34 -0500
>
> > Ok, I'm still testing it, but heres a new patch for review.
> > Significant changes include the addition of a
> > CONFIG_IPV6_OPTIMISTIC_DAD option tha
From: Neil Horman <[EMAIL PROTECTED]>
Date: Fri, 2 Feb 2007 14:06:34 -0500
> Ok, I'm still testing it, but heres a new patch for review.
> Significant changes include the addition of a
> CONFIG_IPV6_OPTIMISTIC_DAD option that is dependent on the inclusion
> of both IPPV6 and EXPERIMENTAL options,
Ok, I'm still testing it, but heres a new patch for review. Significant changes
include the addition of a CONFIG_IPV6_OPTIMISTIC_DAD option that is dependent on
the inclusion of both IPPV6 and EXPERIMENTAL options, as well as a new method
for redirecting packets from optimistic sources to incompl
On Wed, Jan 31, 2007 at 01:16:29AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Tue, 30 Jan 2007 08:02:08 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
> > > I do not think we should copy neighbor information from (one of)
> > > default routers, but use temporar
In article <[EMAIL PROTECTED]> (at Tue, 30 Jan 2007 08:02:08 -0500), Neil
Horman <[EMAIL PROTECTED]> says:
> > I do not think we should copy neighbor information from (one of)
> > default routers, but use temporary neigh entry (or neigh in new state)
> > for such datagrams in stead. We should aw
On Tue, Jan 30, 2007 at 07:25:36AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Mon, 29 Jan 2007 16:30:13 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
> > Quick reality check here. In thinking about how best to go about this
> > redirection of frames to the de
In article <[EMAIL PROTECTED]> (at Mon, 29 Jan 2007 16:30:13 -0500), Neil
Horman <[EMAIL PROTECTED]> says:
> Quick reality check here. In thinking about how best to go about this
> redirection of frames to the default router, based on Dave M.s input, I think
> that the best solution would be in
Quick reality check here. In thinking about how best to go about this
redirection of frames to the default router, based on Dave M.s input, I think
that the best solution would be in ndisc_send_ns. What I was thinking was that
in ndisc_send_ns, we already detect if a source address is optimistic
On Fri, Jan 26, 2007 at 04:42:41PM -0500, Vlad Yasevich wrote:
> Neil Horman wrote:
> > On Fri, Jan 26, 2007 at 03:28:40PM -0500, Vlad Yasevich wrote:
> >> Hi Neil
> >>
> >> Neil Horman wrote:
> >>> On Fri, Jan 26, 2007 at 09:13:31AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL
Neil Horman wrote:
> On Fri, Jan 26, 2007 at 03:28:40PM -0500, Vlad Yasevich wrote:
>> Hi Neil
>>
>> Neil Horman wrote:
>>> On Fri, Jan 26, 2007 at 09:13:31AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article <[EMAIL PROTECTED]> (at Thu, 25 Jan 2007 14:45:00 -0500), Neil
Horman <[EMAIL P
On Fri, Jan 26, 2007 at 03:28:40PM -0500, Vlad Yasevich wrote:
> Hi Neil
>
> Neil Horman wrote:
> > On Fri, Jan 26, 2007 at 09:13:31AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> >> In article <[EMAIL PROTECTED]> (at Thu, 25 Jan 2007 14:45:00 -0500), Neil
> >> Horman <[EMAIL PROTECTED]> says:
> >
>
Hi Neil
Neil Horman wrote:
> On Fri, Jan 26, 2007 at 09:13:31AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
>> In article <[EMAIL PROTECTED]> (at Thu, 25 Jan 2007 14:45:00 -0500), Neil
>> Horman <[EMAIL PROTECTED]> says:
>
>
> New patch attached with most of your suggestions incorporated. I've a fe
On Fri, Jan 26, 2007 at 09:13:31AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Thu, 25 Jan 2007 14:45:00 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
New patch attached with most of your suggestions incorporated. I've a few
comments mixed in for some of the su
On Sat, Jan 27, 2007 at 12:44:29AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Fri, 26 Jan 2007 09:27:30 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
> > I'm looking for it at the moment, but I too had assumed that redirecting the
> > outgoing packet to the de
In article <[EMAIL PROTECTED]> (at Fri, 26 Jan 2007 09:27:30 -0500), Neil
Horman <[EMAIL PROTECTED]> says:
> I'm looking for it at the moment, but I too had assumed that redirecting the
> outgoing packet to the default router would happen automatically within the
> routing code as a result of not
On Thu, Jan 25, 2007 at 05:13:57PM -0500, Vlad Yasevich wrote:
> Hi Neil
>
> >
> > I prefer to be more explicit in my order of operation, but that does seem
> > more
> > consistent with the prevaling style. New patch attached.
> >
>
> Looks good to me.
>
> One question thought. What causes
YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Thu, 25 Jan 2007 14:45:00 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index 2a7e461..46f91ee 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>>
In article <[EMAIL PROTECTED]> (at Thu, 25 Jan 2007 14:45:00 -0500), Neil
Horman <[EMAIL PROTECTED]> says:
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 2a7e461..46f91ee 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -830,7 +830,8 @@ retry:
> ift = !m
Hi Neil
I went through the RFC again it seems like the following is missing:
Section 3.3:
> * (modifies section 5.4.2) The host MUST join the all-nodes multicast
>address and the solicited-node multicast address of the
>Tentative address. The host SHOULD NOT delay before sending
>Ne
Hi Neil
>
> I prefer to be more explicit in my order of operation, but that does seem more
> consistent with the prevaling style. New patch attached.
>
Looks good to me.
One question thought. What causes the stack to send via Default Router instead
of sending an NS (Section 3.2). I see ther
On Thu, Jan 25, 2007 at 03:18:59PM -0500, Vlad Yasevich wrote:
> Hi Neil
>
> > @@ -1027,15 +1029,17 @@ int ipv6_dev_get_saddr(struct net_device *daddr_dev,
> > }
> > }
> >
> > - /* Rule 3: Avoid deprecated address */
> > +
Hi Neil
> @@ -1027,15 +1029,17 @@ int ipv6_dev_get_saddr(struct net_device *daddr_dev,
> }
> }
>
> - /* Rule 3: Avoid deprecated address */
> + /* Rule 3: Avoid deprecated and optimistic address */
>
On Thu, Jan 25, 2007 at 12:16:59PM -0500, Vlad Yasevich wrote:
> I tend to agree with Neil here. Marking optimistic addresses as deprecated
> doesn't
> buy as much since the address can transition in and out of deprecated state
> regardless
> of DAD.
>
> However, there is a problem with the c
Neil Horman wrote:
> On Wed, Jan 24, 2007 at 05:54:47PM -0800, Sridhar Samudrala wrote:
>> Sec 2.1 of RFC 4429 says
>>
>>Unless noted otherwise, components of the IPv6 protocol stack should
>>treat addresses in the Optimistic state equivalently to those in the
>>Deprecated state, indica
On Wed, Jan 24, 2007 at 05:54:47PM -0800, Sridhar Samudrala wrote:
> Sec 2.1 of RFC 4429 says
>
>Unless noted otherwise, components of the IPv6 protocol stack should
>treat addresses in the Optimistic state equivalently to those in the
>Deprecated state, indicating that the address is
Sec 2.1 of RFC 4429 says
Unless noted otherwise, components of the IPv6 protocol stack should
treat addresses in the Optimistic state equivalently to those in the
Deprecated state, indicating that the address is available for use
but should not be used if another suitable address is av
On Tue, Jan 23, 2007 at 09:18:20AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> Hello.
New patch attached, incorporating Yoshijui and Vlads latest comments. I didn't
follow guidance on the ndisc_recv_ns comment, Yoshifuji, since Vlad had already
suggested an alternate solution in a previous post, bu
Hi Neil
Neil Horman wrote:
> + /*
> + * This is not a dad solicitation, meaning we
> may
> + * need to respond to it, if we are
> + * an optimistic node, go ahead, otherwise
> +
On Mon, Jan 22, 2007 at 03:25:39PM -0500, Vlad Yasevich wrote:
> Hi Neil
Yeah, I think your right. I missed the implication of testing for (!dad) at the
top of that clause. I think we could accomplish the same thing by moving my
additions to the top of the clause, but I think your logic reads m
Hello.
In article <[EMAIL PROTECTED]> (at Mon, 22 Jan 2007 13:15:28 -0500), Neil
Horman <[EMAIL PROTECTED]> says:
> Reposted patch, with your suggestions/corrections incorporated. The only
> thing
> I left alone was your last comment regarding the checking of saddr for being a
> unicast addres
Hi Neil
I don't this is still right...
> @@ -746,6 +772,7 @@ static void ndisc_recv_ns(struct sk_buff *skb)
> int dad = ipv6_addr_any(saddr);
> int inc;
> int is_router;
> + int type;
>
> if (ipv6_addr_is_multicast(&msg->target)) {
> ND_PRINTK2(KERN_WAR
On Mon, Jan 22, 2007 at 08:39:24PM +0200, Mika Penttilä wrote:
> Neil Horman wrote:
>
> I think you should remove / modify the :
> if (!dad)
>goto out;
>
> which makes the rfc4429 tests not functional.
>
> --Mika
>
Yeah, I think you're right. In fact, as I look at it more closely I think
Neil Horman wrote:
On Sat, Jan 20, 2007 at 08:05:07AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
Hello.
In article <[EMAIL PROTECTED]> (at Fri, 19 Jan 2007 16:23:14 -0500), Neil Horman
<[EMAIL PROTECTED]> says:
Patch to Implement IPv6 RFC 4429 (Optimistic Duplicate Address Detection). I
On Sat, Jan 20, 2007 at 08:05:07AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> Hello.
>
> In article <[EMAIL PROTECTED]> (at Fri, 19 Jan 2007 16:23:14 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
> > Patch to Implement IPv6 RFC 4429 (Optimistic Duplicate Address Detection).
> > In
>
> Good
On Sat, Jan 20, 2007 at 08:05:07AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> Hello.
>
> In article <[EMAIL PROTECTED]> (at Fri, 19 Jan 2007 16:23:14 -0500), Neil
> Horman <[EMAIL PROTECTED]> says:
>
> > Patch to Implement IPv6 RFC 4429 (Optimistic Duplicate Address Detection).
> > In
>
> Good
Hello.
In article <[EMAIL PROTECTED]> (at Fri, 19 Jan 2007 16:23:14 -0500), Neil
Horman <[EMAIL PROTECTED]> says:
> Patch to Implement IPv6 RFC 4429 (Optimistic Duplicate Address Detection). In
Good work. We will see if this would break core and basic ipv6 code.
Dave, please hold on.
Some qu
Patch to Implement IPv6 RFC 4429 (Optimistic Duplicate Address Detection). In
short, this is a feature whereby a node with a Tentative address can begin to
make use of that address almost immediately after its configured. To enable
this, extra rules need to be followed during the Duplicate addres
71 matches
Mail list logo
