On Oct 12, 2009, at 12:01 PM, JP Vasseur wrote:
On Oct 12, 2009, at 6:50 PM, Colin O'Flynn wrote:
Hello Adam,
Also, one specific question: how would an IPv6 host deal with an
802.15.4 network interface if the IPv6 adaptation layer would
require
changes to the core of the IPv6 stack to function properly?
Having a router in between seems sensible to me. You can get uIPv6
somewhere
small, so I don't see having a simple router as a big problem...
I do not think that the issue is the code size itself but a change
in the architecture, thus
the reasonable question on whether we could find a simpler approach
compatible with
4861 to handle the case of non transitive links that preserves the
architecture.
I do agree that we have to be very careful with the architectural
implications. For me, it's not about whether or not we require an
extra router in between or some extra code. It's more about making
sure we are OK with the proposed simplifications changing the
semantics of ND operations defined (explicitly or implicitly) by RFC
4861. Some examples that come to mind:
1) Assuming that link-layer addresses can always be computed from
IIDs. While this assumption can remove the need for NS/NA for address
resolution, the implication is that the IIDs are limited to the link-
layer addresses in use. 802.15.4 radio hardware is typically limited
to one short and one extended address at a time and that limits the
number and structure of IIDs that can be assigned at any time.
2) Using NR/NC exchanges to provide NUD. With the current draft, NR/
NC exchanges only maintain reachability information for the link-local
address of the attachment router. However, NR/NC exchanges, as
defined, cannot provide reachability information for global
addresses. Additionally, NR/NC messages cannot be used to maintain
reachability information for neighboring hosts (not routers).
I'm not convinced that these are the only examples that we need to be
aware of with the existing draft. I'm also not convinced that enough
people have weighed in on the examples above to say that such
implications are OK
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
