#10: Proxying incorrectly referenced RFC4389
--------------------------------+-------------------------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: nd | Version: 00
Severity: - | Keywords:
--------------------------------+-------------------------------------------
In the -00 document it is currently stated that
"ND Proxy is specified in [RFC4389], and allows for two segments to be
merged into a single IPv6 link. This documents explains the application
of ND Proxy for use with Extended LoWPAN networks with multiple ERs on a
backbone link."
It was pointed out by Erik Nordmark, that although this document uses a
couple small features/concepts from RFC4389, in fact it is not really
using RFC4389 for the basic DAD and NS/NA operations on the backbone.
Instead they could simply be called whiteboard proxy operations on the
backbone. The application of RFC4389 involves proxying all ND messages
from one segment to the other, which we don't want to do in this document
among other things.
The recommendation is that RFC4389 should only be referenced as having
done similar things with ND proxying. Instead the proxy features described
(DAD on the backbone, defending addresses, answering NS on behalf) should
be defined as being specific to this document and not being RFC4389.
--
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/10>
6lowpan <http://tools.ietf.org/6lowpan/>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
