Gabriel, Thanks for weighing in. To expand a little on Jonathan's comments... The potential to have multiple global ipv6 would not seem to suggest that NONE of them should be compressible. hc1g allows ONE of them to be, but doesn't prevent the use of the others. Doesn't it seem a shame to lose the advantages of 6LoWPAN just because you assign IPv6 addresses to the nodes in addition to the default link local address. The philosophy of 6LoWPAN seems to be to provide a way to improve the common case while still supporting the general case correctly. We cannot compress all the UDP ports, just a selected region. I think that you would agree that two of the most important reasons for putting IPV6 on the 802.15.4 network in the first place is the ability to name a node with a globally meaningful IP address and the ability to route packets to and from nodes on the 802.15.4 network. HC1g preserves the the HC1 compression in these two cases.
On 7/16/07, Jonathan Hui <[EMAIL PROTECTED]> wrote:
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
