Subject: Re: [6lowpan] Thoughts on draft-ietf-6lowpan-nd-07

From: "Reddy, Joseph" <[email-masked]>
Date: Tue, 17 Nov 2009 19:26:17 -0600

Hi Pascal,

The proxy-ND that you described from the draft may not always work....consider the case where a backbone node attempts to "ping6" a 6lowpan node. 

To the backbone node, the 6lowpan devices appears as "on-link" since the ER responds with NS on behalf of the 6lowpan device. This will cause the backbone node to communicate with the 6lowpan device using its link-local address as the source address. Then the 6lowpan device has no way to respond back to the backbone node since it only knows the link local address and not the global address of the backbone node ( unless 6lowpan routers can  forward packets with link-local destinations ). Did I miss something here ?

-Regards, Joseph

------------------------------

Date: Tue, 17 Nov 2009 18:36:37 +0100
From: "Pascal Thubert (pthubert)" <[email-masked]>
Subject: Re: [6lowpan] Thoughts on draft-ietf-6lowpan-nd-07
To: "Colin O'Flynn" <[email-masked]>, "Carsten Bormann"
	<[email-masked]>,	"Alexandru Petrescu" <[email-masked]>
Cc: 6lowpan <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

Hi Colin:

I think you're describing the draft. Basically the edge router does proxy-ND over the backbone.
So if a node on the backbone looks up a 6LoWPAN device, the edge router answers NS with NA on behalf of the device.
So the node sends packets via the edge router. The edge router forwards back to the device over the lowpan.
As you figures, this is why the device needs to periodically maintain the binding with the edge router.

This is somewhat similar to mobile IPv6 though there's no tunnel.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 18 Nov 2009 08:28:21 +0100

Hi Joseph:

Ping is a weird thing since you can force anything and some things just
won't work. 

I'd rather stick to SAS (RFC3484) and standard IPv6 behavior which was
good enough for RFC 3775 and family (3963, 5555, ...).

The link local of the lowpan device does not have the scope to reach the
backbone. 

So that address is not visible to the node on the backbone and there is
no way the backbone device can know it. 

So the node on the backbone should only resolve the global address of
device. 

For that address, SAS rules will cause the node to source with the same
scope (global) longest match (same prefix). 

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Reddy, Joseph
>Sent: mercredi 18 novembre 2009 02:26
>To: [email-masked]
>The proxy-ND that you described from the draft may not always
work....consider the case where a
>backbone node attempts to "ping6" a 6lowpan node.
>
>To the backbone node, the 6lowpan devices appears as "on-link" since
the ER responds with NS on behalf
>of the 6lowpan device. This will cause the backbone node to communicate
with the 6lowpan device using
>its link-local address as the source address. Then the 6lowpan device
has no way to respond back to
>the backbone node since it only knows the link local address and not
the global address of the
>backbone node ( unless 6lowpan routers can  forward packets with
link-local destinations ). Did I miss
>something here ?
>So if a node on the backbone looks up a 6LoWPAN device, the edge router
answers NS with NA on behalf
>of the device.
>So the node sends packets via the edge router. The edge router forwards
back to the device over the
>lowpan.
>As you figures, this is why the device needs to periodically maintain
the binding with the edge
>router.
>_______________________________________________
>6lowpan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Nov 2009 20:16:17 +0100

Reddy, Joseph a écrit :
> work....consider the case where a backbone node attempts to "ping6" a
> 6lowpan node.
> 
> the ER responds with NS on behalf of the 6lowpan device. This will
> cause the backbone node to communicate with the 6lowpan device using
> has no way to respond back to the backbone node since it only knows
> the link local address and not the global address of the backbone
> node ( unless 6lowpan routers can  forward packets with link-local
> destinations ). Did I miss something here ?

I agree with this example of the other node on backbone using its 
link-local address to talk to the lowpan node.

I also agree ER should not forward packets having src or dst fields an 
IP link-local address.

Moreover, it is not clear to me from the draft what kind of "proxy" ND 
is performed.  If it is similar to what the Mobile IPv6 rfc3775 HA does 
then is it for lowpan node's IP link-local or global address?  Anyways, 
it will not help detecting a collision of the short MAC address of the 
lowpan nodes of different ERs' lowpans.  Even if it did, it would have 
no means to change that.

It's strange to see proxy-ND used to detect duplicated addresses.

Alex

> Date: Tue, 17 Nov 2009 18:36:37 +0100 From: "Pascal Thubert
> (pthubert)" <[email-masked]> Subject: Re: [6lowpan] Thoughts on
> draft-ietf-6lowpan-nd-07 To: "Colin O'Flynn" <[email-masked]>,
> "Carsten Bormann" <[email-masked]>,	"Alexandru Petrescu"
> <[email-masked]> Cc: 6lowpan <[email-masked]> 
> Message-ID: 
> I think you're describing the draft. Basically the edge router does
> proxy-ND over the backbone. So if a node on the backbone looks up a
> 6LoWPAN device, the edge router answers NS with NA on behalf of the
> device. So the node sends packets via the edge router. The edge
> router forwards back to the device over the lowpan. As you figures,
> this is why the device needs to periodically maintain the binding
> with the edge router.
> 
> Pascal _______________________________________________ 6lowpan
> mailing list [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Nov 2009 20:35:07 +0100

> scope (global) longest match (same prefix). 

Pascal - if your intention is for a node on the backbone to reach a 
lowpan node then the solution is _not_ ND neither proxy-ND, but routes 
in the routing tables, which can be configured manually, or as result of 
ICMP Redirect, or a routing protocol.

If your intention is to detect duplicates of the lowpan's addresses then 
it's strange to perform proxy-ND to achieve that.

For one, the DAD-like ND-based operation detects duplicates of IP 
address, not of MAC addresses.  Or, here we risk having collisions of 
MAC addresses (when they're short).

Second, when two ERs each sends an NA about two different lowpan nodes' 
duplicated IP address, and put their own different MAC in it too - the 
effects on non-ER nodes exist too as below.

These backbone non-ER nodes will be forbidden to configure that IP 
address on their own interface - which is very fine, they don't care, 
because they'd never try, because the prefix on the backbone is 
different than the lowpan prefixes anyways.

However, these non-ER nodes on the backbone (1) will get an entry in 
their NC about that address, which is not good, because that IP address 
is not valid on that subnet and, worse, (2) will have inconsistent 
entries in their NC about that IP address.

I may not be very clear, but I have strong doubts about using proxy-ND 
on ER for detecting duplicates and reaching lowpan nodes.

Alex

> proxy-ND over the backbone.