(META: I've corrected the Subject to actually describe the topic of this note. I wish more people would do the same -- so that Subject: lines reflect the actual topic discussed by the note. :-)
1) As Joel and Tony have already noted, there is never a requirement to use local-scope Identifier values. 2) Local-scope Identifier values exist only because there are some (relatively small) user communities that desire to use non-global Identifiers of various kinds. 3) The EUI-64 syntax is carefully designed to make it easy to distinguish a local-scope Identifier from a global-scope Identifier, so there is no protocol issue lurking here. DISCUSSION: Now, all that said, I don't see why this is suddenly confusing to anyone. All of the above is also true for IPv6 Interface Identifiers, which are also based on EUI-64, have some deployment. Separately, IPv6 is purportedly widely understood and apparently has some growing deployment. In fact, the big difference between IPv6 and ILNPv6 (or ILNPv4 which also uses EUI-64 Identifiers) is that the Identifier names the *interface* for IPv6, and names the *node* for ILNP. This semantic change is absolutely crucial, because this change is what permits IP sessions to remain up even though a correspondent node's subnetwork point of attachment (SNPA) changes. Clearly, node mobility is hugely simpler when a global-scope ID value is used. The ILNP specifications say that normally a global-scope ID is used, while allowing individuals that want to use some local-scope ID to do so. Again, no one is ever required to use a local-scope ID value. That noted, mobility can work fine with a local-scope ID, because the session Nonce permits differentiation of different nodes using the same (e.g. local-scope) ID values. Implementations of ILNP are required to use cryptographically-random Nonce values, so an off-path attacker won't be able to predict a nonce value externally. Existing IPv4 and IPv6, including Mobile IPv4/IPv6, are vulnerable to a wide range of on-path attacks unless IPsec is used to protect the IP session. IPsec for ILNP works well even in the presence of changed node location, unlike currently deployed IPsec, and can be used to eliminate the threat of an on-path attacker. So there is no loss of security in moving from IP to ILNP, or in moving from Mobile IPv* to ILNP mobility, or in moving from existing multi-homing methods to ILNP multi-homing methods. Yours, Ran Atkinson _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
