Le 29/03/2012 14:29, Margaret Wasserman a écrit :
On Mar 29, 2012, at 1:12 PM, Alexandru Petrescu wrote:
Allow me a quick reply here. There are several active RFC
proposals recent at IETF that simply don't run ND. Or, how to
better say - if ND is present it is completely ignored, being
replaced by something else claimed better than ND for some issue
at hand.
This is the case for example in the RoLL (RPL protocol), 6lowpan
(IPv6 over header compression) and more. If I understand
correctly, CoAP considers the sensor node to be an 'IPv6 node' but
not necessarily run ND. If it did, then ICMP could be used without
intermediary, instead of CoAP.
There are several parts of ND used for different purposes, and I
think that might be the source of some confusion here...
6lowpan does include a definition for how ND works over IEEE
802.15.14 networks.
There are some environments where ND is not used for address
autoconfiguration, where duplicate address detection (DAD) is
unnecessary, or where there are other means of determining whether
neighbors are reachable or not. In those environments, those parts
of ND are sometimes unnecessary. That doesn't mean that it is okay
for a general purpose IPv6 implementation to omit ND.
I don't understand what it would even mean for ROLL (which is
routing protocol)
Well yes RPL is a routing protocol and uses ICMP message types. There
are number of ND incompatibility issues about it.
or COAP (which is an HTTP compression protocol) to "use ND", so I
don't know how to comment on those.
Sorry, I dont know either.
Somebody said that if node is not implementing ICMPv6 Redirect
then it wouldnt't be accepted as an IPv6 node.
I think this is something you may have taken away from a
conversation with me...
You said that you have an IPv6 implementation that can only store
one default route (no default router list) and cannot store any
other routes.
I said that if I were to store only one route that would be the default
and not a specific route, because the default route is the only way to
use a single routing entry table and reach the maximum number of
destinations. The draft I am proposing proposes a list of default
routers, not only one.
I told you that if you shipped that stack in a commercial product,
customers would be very unhappy with you because: (1) is not
acceptable (in the market) to ship and IPv6 node that can't fall back
to a second default router if the preferred one goes down,
I agree.
and (2) it is not acceptable to ship an IP node that can't create a
new route in response to an ICMP redirect.
This I am not sure. The point-to-point links (as in cellular) never use
Redirects because there are no alternative routers on the link. I do
agree though that Redirect is a necessary useful message on shared links.
That said, I believe it is also true that such a node would not be
RFC compliant, because IPv6 nodes are required to implement ICMPv6.
In general I tend to agree. Just I am not sure how far this requirement
goes when it comes to CoAP, RPL most header compression protocols. It
may be just me.
Yours,
Alex
Margaret
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif
