Hi Robert
Yes, but then later on in section 3.2 of RFC4429:
* (modifies section 7.2.2) A node MUST NOT use an Optimistic Address
as the source address of a Neighbor Solicitation.
So now, since oDAD has been brought into the picture, I have a new
question: Is an IP address under 6LoWPAN registration an optimistic
address or a tentative address?
Regards
Dario
Robert Cragie wrote:
The answer lies in RFC4429 (oDAD). This overrides RFC4862
wrt. tentative address definition, most notably:
Tentative address (as per [RFC2462]) - an address whose uniqueness on
a link is being verified, prior to its assignment to an
interface. A Tentative address is not considered assigned to an
interface in the usual sense. An interface discards received
packets addressed to a Tentative address, but accepts Neighbor
Discovery packets related to Duplicate Address Detection for the
Tentative address.
So this allows ND packets to be sent to a tentative address (and
correspondingly be originated from one). Whilst I personally would
prefer to see the 16-bit address carried in the ARO, I have been
convinced that it is legitimate to use 16-bit address based address for
IP source address.
So, yes, some rules do have to be put in but the rule is a tentative
NCE has to be treated differently to a normal NCE. So the case you
describe below should be able to be dealt with.
Robert
----- Original Message -----
To:
"Erik Nordmark" <[email protected]>
Cc:
<[email protected]>
Sent:
Thu, 29 Jul 2010 14:18:55 -0700
Subject:
Re: [6lowpan] #87: GP16 as source address in initial NS
Perhaps there's been a misunderstanding: I have been implying IP
addresses where others may have been thinking of MAC address. Perhaps I
should have been more specific. I've
been talking about duplicate IP addresses not duplicate MAC addresses.
However, since some IP addresses are derived from MAC addresses, I can
see how one might view the 6LoWPAN registration process as MAC address
registration. I view the registration process as IP address
registration, and it's only coincidental (from a DAD perspective) that
the IID in the IP address matches the MAC address
So, to reiterate my previous point:
""
.. since we are doing some kind of DAD (by having IP
address
registration), sending a "duplicate" response to the appropriate node
needs similar technical consideration as in classic DAD. Specifically,
that sending a "duplicate" response to the duplicate IP address is
problematic.
""
I'd like to come back to the two solutions mentioned in previous emails
on this thread:
- The ARO in the NS carries the address to which a NA response
is
sent.
- The use of a temporary NCE.
If the first solution were used, then I would suggest that we just swap
address fields: The return IP address goes into the IP source field of
the NS and the IP address under registration goes into the ARO.
Having thought about the second solution a bit more and how I would
implement it in the stack we are currently using (BSD), I can not see
how it
would work at all without hacks. Lets say that a valid NCE (NCE1)
exists
for an IP address (A1). If a duplicate is then detected for A1, a
temporary NCE (NCE2) is created. Both NCE1 and NCE2 are keyed on A1.
Now comes time for the NA "duplicate" response. 6LoWPAN ND creates the
NA packet and pushes it down to the IP layer. Next, lets say that the
IP layer does IP to MAC address resolution at this point (BSD does this
in the network-interface driver, but it doesn't really matter
for this example). Since the response is to be sent to A1, how exactly
does the stack resolve the appropriate destination MAC address.
Specifically, how does the NCE-lookup function determine which NCE to
return when both NCEs are keyed on the same address. There's no
discriminatory information that can be used at this point. One might
think that the EUI-64 could be used to discriminate, but that would
mean the EUI-64 of the destination would need to be gleaned from the
ARO in the outgoing packet. One other thing to note is that some stacks
store NCEs in their routing tables and don't allow duplicate keys (i.e.
duplicate destination IP addresses).
Perhaps someone can explain this to me, but I can't understand why we
are placing a tentative address in the IP source address field, when no
other Internet protocol (I know of) does that. The idea that "this is
the 6LoWPAN realm and we can do what we want" is no answer in my
opinion. It is risky thinking that when we are trying to remain
compatible with the wider Internet.
Dario
Erik Nordmark wrote:
On
07/28/10 01:40 PM, Dario Tedeschi
wrote:
My point is that since we are doing some kind of DAD (by having address
registration), sending a "duplicate" response to the appropriate node
needs similar technical consideration as in classic DAD. Specifically,
that sending a "duplicate" response to the duplicate address is
problematic.
I don't think so. The approach in 4862 was based on concerns around the
behavior of token ring and fddi where sending a unicast packet to a MAC
address, when two stations use the same MAC address, could be
problematic. We also have the same issue with Ethernet bridges learning
MAC addresses.
But for 6lowpan we don't have those issues since even if the MAC
address is duplicate both radios will receive the packet.
Note that the above is all about duplicate *MAC* addresses.
In the case of duplicate *IP* addresses with unique MAC addresses there
is no issue in sending a unicast response.
I'm sure that's why RFC text like the above
even exists and
part of the reason why the "Target Address" field in an NS exists. The
designers of classic ND must have experienced or thought of this
technicality.
FWIW I'm not aware that DAD was ever tested (on Ethernet, fddi, etc)
using duplicate MAC addresses. To my knowledge the duplicate IP address
case is part of test suites.
Using a trick like "a temporary NCE" in an
implementation might work,
but it comes with its own problems. Wouldn't it just be simpler and
safer if the requesting NS used a valid source address (one that is
considered unique in the WPAN).
Are you talking about the source IP address or source MAC address? For
IP we don't have an issue.
The use of a tentative NCE also has the benefit of removing a security
issue we have in nd-11 where an off-link attacker can cause NCE to be
created, which is something that isn't possible in base ND.
Erik
|
