Great question.
I would like to extend it to "which procedures from which IPv6 RFCs
assume link transitivity and/or high-delivery-probability subnet-wide
multicast", as these are the assumptions violated by a LoWPAN (in most
configurations, excepting two-node and full-multicast mesh-under).
Just one example for the former: RFC 4861 redirect assumes that a
router can tell a host that it can reach another host via the same
link. Not true in LoWPANs.
The obvious RFC 4861 example for the problems caused by the latter,
i.e. (deliberate) lack of high-delivery-probability subnet-wide
multicast, is DAD. But there may be a lot of other protocols hit by
this. Is this a problem?
It would be if these protocols were likely to show up in LoWPANs. One
important assumption behind 6LoWPAN is that it is not so likely that
LoWPANs will be freely substituted for Ethernet (in the sense that
802.11 was essentially employed as an Ersatz Ethernet). Example:
People are not going to open their laptops and see, oh there is a
LoWPAN, and start using that for their normal Internet access
activities such as E-Mail and Web access (although these two actually
would pretty much work).
6LoWPAN started out by saying "let's build an IPv6 link out of
802.15.4", with the assumption it would then be like any other IPv6
link. It took a couple of years to readjust that assumption. People
newly coming in from high-power IPv6 may now also need some time to
readjust theirs.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
