Pascal Thubert (pthubert) a écrit :
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 - 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
Pascal
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Reddy, Joseph
Sent: mercredi 18 novembre 2009 02:26
To: [email protected]
Subject: Re: [6lowpan] Thoughts on draft-ietf-6lowpan-nd-07
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 protected]>
Subject: Re: [6lowpan] Thoughts on draft-ietf-6lowpan-nd-07
To: "Colin O'Flynn" <[email protected]>, "Carsten Bormann"
<[email protected]>, "Alexandru Petrescu"
<[email protected]>
Cc: 6lowpan <[email protected]>
Message-ID:
<[email protected]>
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
