Personally, I am not in favor of taking out the /64 boundary. The main reason is that I do not see signficant benefits from doing so, but I do see negative consequences from revisiting the boundary. At a minimum, the discussion leading to this kind of change is likely to be divisive, and I don't see that as being particularly good way to focus this WG's cycles.
Personally, I believe it is potentially useful to have 64-bit interface identifiers in all addresses. They *could* have properties associated with them, but that is mostly future work. No need to close the door prematurely. (Note: the reason the current requirement for IIDs on all addresses except those with prefix 000 has to do with that 000 addresses are reserved for things that might well conflict with interface identifiers, such as IPv4-compatable addresses). Regarding kre's argument that globally-unique IIDs are useless and should therefore be abolished, my feeling is different. First, no one can (or is) credibly arguing that if the u bit is set a certain way, the interface ID is *guaranteed* to be globally unique. (Kre seems to assume this argument as a strawman.) However, if the u bit is set a certain way, implementations could take that as a hint that the IID is *probably* unique (or supposed to be unique), and in the case that it really cares, it could take additional steps to verify uniqueness and then use addresses with that property in a possibly different way. No one is doing that today (and I'm not advocating that they do either). However, it *might* be useful to be able to do so in the future. Whether it would be worth the effort to do the check, or what the check would be, is future work that would be done in conjunction with a proposal for how to take advantage of unique IIDs. Now, normally, I tend to resist putting in hooks that *might* be used in the future, because our track record of predicting what hooks will be needed (and getting them right) is generally rather poor. In this case, however, I believe a *lot* of people (and in particular, people mostly not in the IPv6 WG) feel pretty strongly that something like 8+8/GSE should be pursued. The current Interface ID we have leaves that door somewhat open, should a proposal come forward that the community believes can be made to work. Closing that door would likely be viewed as a slap-in-the face to those who want the door left open, and will do little to build support for IPv6 among those folk. I don't see what would be gained by doing this (rather, I see only negatives). More recently, there has been a proposal (though not particularly well received by this list) to perhaps allow other different types of indentifiers. For example, there is promising work going in with regards to embedding (parts of) public keys (or the signature of a public key) into an interface identifier in order to allow a node to "prove" it "owns" a particlar address/identifier. I'm not sure how (or if) that work will gain much traction, but again, I think it would be a mistake to close that door prematurely, because it *might* be a useful approach to solving a rather hard problem for which few options seem to be available. Getting back to the observation that some in the community are assigning /127s to the p2p links, this by itself does not imply that the interface identifier concept is inherently broken and should be removed from addrarch. Even if many operators turn out in fact to number all their p2p links this way, this will be an extremely small fraction of the total number of addressable end nodes. Thus, in practice, enough end nodes may be using 64-bit IIDs in order for the uniquness properties (as described above) to be useful enough to take advatange of. Obviously, those nodes that don't follow the scheme wouldn't be able to take advatange, but that may not matter. Future work can figure that out. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
