gabriel montenegro wrote:
We actually discussed this a while back with Erik Nordmark in some
detail. The issue is that an IPv6 link
can have several prefixes, and they are not guaranteed to be advertised
in any particular order by the router
or routers on that link. So one could not use a bit pattern easily to
refer to:
* "the" global prefix (cuz there may be more than one)
* "the first global prefix" (cuz node A's first might be node B's
second)
Yes, the global compressible prefix must be clearly identified if nodes
are assigned more than one prefix. Our thoughts are that this can be
done using either stateless autoconfiguration mechanisms (i.e. IPv6 ND),
by extending RAs and using a reserved bit to indicate its compressible
status; through stateful autoconfiguration (i.e. DHCPv6) through IA
Address options; or through some yet-to-be-defined 6LoWPAN configuration
protocol. If there is a configuration error and more than one global
prefix is marked as compressible, then the node must not compress the
prefix. This is not stated in the current draft and probably should be.
At the end we did not see a clear and easy way of doing so, so we
limited the header compression scheme
to only the link-local addresses (cuz the "prefix" in that case in
unequivocally known). It also did not seem
like overall, complicating the basic scheme with additional header
compression for global prefixes was
very meaningful as most traffic would probably be link-local anyways.
Link-local communication covers an important subset of applications. But
we do see benefits in allowing nodes to communicate directly with other
IP devices outside the LoWPAN network. By utilizing IP end-to-end,
LoWPAN nodes can readily communicate with any other non-LoWPAN node, and
it can do so without a stateful translation gateway in between.
In case it is not clear, an assumption above (as in all the format
document) was that we wanted to have
support for IPv6, not for some watered-down or somewhat tweaked (even if
only slightly) version of IPv6.
It was also pretty clear that without this we wouldn't have been able to
have a working group.
We completely agree that we would like to support full IPv6. LOWPAN_HC1g
supports just that, allowing nodes to communicate with any arbitrary prefix.
--
Jonathan Hui
[EMAIL PROTECTED]
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
