Hi Samita,
On Mar 30, 2010, at 7:43 PM, Samita Chakrabarti wrote:
I would vote for option 1. [ existing definition in rfc4944 -]
Just to be clear, option 1 still requires an update to RFC 4944 to
specify that the PAN ID is no longer used in constructing the IID.
Minimally, 6lowpan-hc either needs to (i) update Section 6 of RFC 4944
or (ii) no longer point to RFC 4944 and specify how to reconstruct the
IID from a short address. I am fine with either, but if we go with
the latter, then the 6lowpan-nd document needs to update Section 6 of
RFC 4944.
1) Maintain the RFC 4944 translation (short address -> ethernet
address ->
64-bit IID). Generated IIDs will be 64 bits in length and of the
form
(0000:00ff:fe00:xxxx), where xxxx is the short address.
This is simple and easy to understand and compute. ND assumtion is
that there is one single prefix per 6LoWPAN. If you are talking about
PANs under a 6LowPAN, then I think it is too implementation specific
and we don't need to standardize it at this point.
Yes, I agree with the desire of maintaining 64-bit prefixes.
So for simplicity and not adding more complexity to ND
autoconfiguration, can we say that
6LoWPAN-unique-prefix::00ff:fe00:xxxx would be the IPv6-address
derived from short address with the above 64-bit IID?
I think the only argument now is whether the 64-bit IID should take
the form '::ff:fe00:xxxx' or simply '::1:xxxx'. The latter is easier
to type IMHO, but I agree it is a minor point. Either way, we require
an update to RFC 4944 and 6lowpan-hc.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
