Subject: Re: [6lowpan] #87: GP16 as source address in initial NS

From: Robert Cragie <[email-masked]>
Date: Mon, 02 Aug 2010 18:32:23 +0100

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

---

From: Dario Tedeschi <[email-masked]>
Date: Mon, 02 Aug 2010 12:57:50 -0700

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.

Robert

----- Original Message -----

From:

Dario Tedeschi <[email-masked]>

To:

"Erik Nordmark" <[email-masked]>

Cc:

<[email-masked]>

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

""

.. 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,

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,

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.

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

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,

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