From: Brian Haley <brian.haley@hp.com>
To: "YOSHIFUJI Hideaki / ????" <yoshfuji@linux-ipv6.org>
Cc: dlstevens@us.ibm.com, davem@davemloft.net, netdev@vger.kernel.org
Subject: Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address
Date: Sun, 30 Sep 2007 23:27:35 -0400 [thread overview]
Message-ID: <47006927.3030701@hp.com> (raw)
In-Reply-To: <20070929.100448.41933886.yoshfuji@linux-ipv6.org>
Hi Yoshifuji,
YOSHIFUJI Hideaki / ???? wrote:
> Dave, Brian,
>
> Let me double check this patch.
>
> Regards,
>
> --yoshfuji
>
> In article <OF5FC97D70.5FD0A80A-ON88257365.00025E58-88257365.00048D1E@us.ibm.com> (at Fri, 28 Sep 2007 17:50:38 -0700), David Stevens <dlstevens@us.ibm.com> says:
>
>> Brian,
>> A multicast address should never be the target of a neighbor
>> discovery request; the sender should use the mapping function for all
>> multicasts. So, I'm not sure that your example can ever happen, and it
>> certainly is ok to send ICMPv6 errors to multicast addresses in general.
>> But I don't see that it hurts anything. either (since it should never
>> happen :-)),
TAHI generates a lot of packets that shouldn't happen :) see below for
the problem. The patch in ndisc_send_redirect() is probably
unnecessary, but since the code was identical I figured it wouldn't hurt.
>> so I don't particularly object, either.
>> I think it'd also be better if you add the check to be:
>>
>> if (ipv6_addr_type(target) &
>> (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST))
I did have it:
if (ipv6_addr_type(target) &
(IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST) ==
(IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST))
but changed it since I had proposed ipv6_addr_linklocal() in a previous
patch because there are other possible users of that.
This is the actual packet trace that was sent to me, edited to remove
non-relevant data, but I've actually been unable to reproduce Packet 12
below (note the Destination MAC). My knee-jerk reaction was the
proposed patch. It could just be timing-related, I'll do more testing
Monday. Strangely, the TAHI test passes anyway, but it shouldn't.
Packet 10 : Icmpv6 : Redirect
Ethernet
Destination MAC.........................00:1A:4B:EB:FC:E6
Source MAC..............................00:00:10:10:10:60
Ipv6
Version.................................6
Next Header.............................58
Hop Limit...............................255
Source IP.....................FE80:0000:0000:0000:0200:10FF:FE10:1060
Destination IP................3000:0000:0000:0000:021A:4BFF:FEEB:FCE6
Icmpv6
Type....................................0x89
Code....................................0x00
Reserved................................0x00000000
Target Address................FF02:0000:0000:0000:0000:0000:0000:0001
Destination Address...........3001:0000:0000:0000:0200:10FF:FE10:1180
Options
LLAddressOption
Option Type.............................2
Option Length...........................1
Link-Layer Address......................0x000010101061
Packet 11 : Icmpv6 : Echo Request
Ethernet
Destination MAC.........................00:1A:4B:EB:FC:E6
Source MAC..............................00:00:10:10:10:60
Ipv6
Version.................................6
Next Header.............................58
Hop Limit...............................255
Source IP.....................3001:0000:0000:0000:0200:10FF:FE10:1180
Destination IP................3000:0000:0000:0000:021A:4BFF:FEEB:FCE6
Icmpv6
Type....................................0x80
Code....................................0x00
Identifier..............................0x0000
Sequence Number.........................0x0000
Data....................................0x00
Packet 12 : Icmpv6 : Echo Reply
Ethernet
Destination MAC.........................33:33:00:00:00:01
Source MAC..............................00:1A:4B:EB:FC:E6
Ipv6
Version.................................6
Next Header.............................58
Hop Limit...............................64
Source IP.....................3000:0000:0000:0000:021A:4BFF:FEEB:FCE6
Destination IP................3001:0000:0000:0000:0200:10FF:FE10:1180
Icmpv6
Type....................................0x81
Code....................................0x00
Identifier..............................0x0000
Sequence Number.........................0x0000
Data....................................0x00
This should have been sent to 00:00:10:10:10:60
-Brian
next prev parent reply other threads:[~2007-10-01 4:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-28 16:26 [IPV6] Fix ICMPv6 redirect handling with target multicast address Brian Haley
2007-09-29 0:50 ` David Stevens
2007-09-29 1:04 ` YOSHIFUJI Hideaki / 吉藤英明
2007-10-01 3:27 ` Brian Haley [this message]
2007-10-01 11:49 ` YOSHIFUJI Hideaki / 吉藤英明
2007-10-01 17:36 ` Brian Haley
2007-10-02 19:18 ` [IPv6] " Brian Haley
2007-10-02 20:39 ` David Stevens
2007-10-02 21:06 ` Brian Haley
2007-10-02 22:41 ` David Stevens
2007-10-03 14:44 ` [IPv6] Fix ICMPv6 redirect handling with target multicast address, try 3 Brian Haley
2007-10-08 7:12 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47006927.3030701@hp.com \
--to=brian.haley@hp.com \
--cc=davem@davemloft.net \
--cc=dlstevens@us.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.