> The reason being RFC4944 disallows the use of the "zero address" in the > fake-48.
Does it? I don't know what For either address format, all zero addresses MUST NOT be used. actually means (it doesn't say whether this is about 16-bit, 48-bit or 64-bit addresses). I think this was meant to exclude :: as the IID, but that may be just my interpretation. > With no PAN-ID (ie: zero's for the PAN-ID bits), this disallows > short address 0. Using some non-zero PAN-ID would remove that problem. Even if fake-48 == '0'*48 is not allowed: Is losing one out of 32k 16-bit addresses actually a problem? > One could use the 0xFFFF PAN-ID, which would not be accidently considered > valid. That would be the result of interpreting if no PAN ID is known, 16 zero bits may be used as "in non-associated mode, the PAN-ID is known to be 0xFFFF". We could certainly agree on that, if we want. That would be a change from current implementation practice, AFAIK. > Or we could add a note to hc saying that ::ff:fe00:0 is indeed a valid > address with this scheme. This would be the cleanest solution, I'm not sure > if it's "allowed"? If we really need that 32768th address, we could also do that. Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
