The answer lies in RFC4429 (oDAD). This overrides RFC4862 wrt.
tentative address definition, most notably:
Tentative address (as per [RFC2462 [1]]) - 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 -----
From: Dario Tedeschi
To:"Erik Nordmark"
Cc:
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
Links:
------
[1] http://webmail.hosting.heartinternet.co.uk/./rfc2462
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
