|
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:
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: |
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
