[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(usagi-users 03421) Re: Source address for neighbor solicitations
On Wed, Jun 22, 2005 at 08:17:34PM +0900, thus spake Noriaki TAKAMIYA:
> >> Wed, 22 Jun 2005 13:07:58 +0200
> >> [Subject: Re: (usagi-users 03412) Source address for neighbor solicitations]
> >> Ignacy Gawedzki <Ignacy.Gawedzki@xxxxxx> wrote...
>
> > > In RFC2461:
> > > --------------------------------------------------
> > > 4.3. Neighbor Solicitation Message Format
> > > :
> > > IP Fields:
> > >
> > > Source Address
> > > Either an address assigned to the interface from
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > which this message is sent or (if Duplicate Address
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Detection is in progress [ADDRCONF]) the
> > > unspecified address.
> > > :
> > > 7.2.2. Sending Neighbor Solicitations
> > > :
> > > If the source address of the packet prompting the solicitation is the
> > > same as one of the addresses assigned to the outgoing interface, that
> > > address SHOULD be placed in the IP Source Address of the outgoing
> > > solicitation. Otherwise, any one of the addresses assigned to the
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > interface should be used. Using the prompting packet's source
> ~~~~~~~~~~~~~~~~~~~~~~~~
> > > address when possible insures that the recipient of the Neighbor
> > > Solicitation installs in its Neighbor Cache the IP address that is
> > > highly likely to be used in subsequent return traffic belonging to
> > > the prompting packet's "connection".
> >
> > This is actually not what happens : if the source address of the packet
> > prompting the solicitation is not one of the addresses assigned to the
> > outgoing interface, the solicitation is not sent at all. I understand from
> > the above that it should then use _any_ address available.
>
> I think no. address should be assinged to the interfaces(see the
> above lines).
I'll give a concrete example to make myself clear.
Suppose you have three wireless stations, each with only one interface. They
are assigned global addresses ::101, ::102 and ::103. The topology is very
simple: ::101 uses ::102 as a relay to reach ::103, routing tables of the
nodes are set accordingly.
::101 ------------ ::102 ------------ ::103
Suppose that each interfaces is assigned a link-local address as well.
::101 ------------ ::102 ------------ ::103
fe80::1 fe80::2 fe80::3
Say ::101 wants to send a data packet to ::103. ::101 first issues a NS to
find ::102's link-layer address.
::101 > ff02::1:ff00:102 who has ::102
::102 > ::101 target is ::102
::101 > ::103 data packet
::102 replies with a NA and then ::101 sends the data packet to ::102. In
turn, ::102 issues a NS to find ::103's link-layer address.
fe80::2 > ff02::1:ff00:103 who has ::103
::103 > fe80::2 target is ::103
::101 > ::103 forwarded data packet
::103 replies with a NA so now ::102 can forward ::101's data packet to ::103.
Notice that ::102 uses its link-local address to send the NS.
Now suppose that something went wrong: someone removed link-local addresses.
If we do the same experiment, the first step (::101 sending the data packet to
::102) works okay. But the second step does not, since ::102 has no
link-local address to send its NS, so what happens is the following:
::101 > ff02::1:ff00:102 who has ::102
::102 > ::101 target is ::102
::101 > ::103 data packet
::102 > ::101 icmp ::103 address unreachable
I understand that removing the link-local addresses, we have already broken
RFC conformance and that then behavior is undefined in terms of RFC. But
anyway, I think a very simple idea may help here, still in accordance with the
RFC: ::102 may use its global address to issue the NS to find ::103's
link-layer address. This is okay with "address assigned to the interface from
which this message is sent" as well as with "any one of the addresses assigned
to the interface should be used".
--
Information wants to be beer, or something like that.