kre, | Michel Py wrote: | - There is currently no use made of the 'u' bit for any current or | future multihoming protocol I know of.
> kre wrote: > So you have no problem if the text that tells about its > "global scope" gets yanked from the doc? I personally don't and in the bigger picture I would not lose sleep over it. As I said before, if there are compelling reasons to move away from the /64 hard boundary, the 'u' bit by itself does not appear to me to be a good enough reason to block that change. | - The 'u' bit is not a blocking reason why prefixes longer than | /64 are not allowed. > It is the only one I can see. It is also the only one I care > about. I think you are making a mistake here. If I may, I think that the reason you have failed to convince the WG to move away from the /64 hard boundary is *not* because you have failed to convince that we needed to get rid of the 'u' bit, but because you have failed to convince that we needed to move away from the /64 boundary as being its own issue. I might not have been clear, but the reason I support keeping the 'u' bit is *not* because I want to use it as an excuse to keep the /64 boundary, but because it makes little sense removing it as long as the /64 boundary is there. Forget about the 'u' bit. From my seat here, the hypothetical availability of a "son of GSE" is a very little factor in deciding to move away from the /64 hard boundary. If you have a case to make, make it on the real issue which is the /64 boundary. It appears to me that you are trying to modify the Addressing Architecture doc in order to allow very minor optimizations. Trying to make a comparison with IPv4: - Using a /30 on a ptp is a no-brainer. - Using a /31 is a slight enhancement. It still not is widely deployed, the reason being that, even in a v4 environment where addresses do need to be aggressively conserved, the gain from moving to /31 instead of /30 is not that significant. - Finally, there is un-numbered, and I don't see much of it and don't use it myself. Why is un-numbered to being universally used for ptp links? Because the operational annoyances resulting from using it are such a pain that they do not balance the fact that un-numbered provides unlimited ptp links without using any precious IPv4 IP addresses. In weighing the pros and cons of removing the /64 hard boundary, my opinion is that the savings that it would bring are not significant enough compared to the potential operational annoyances. I can feel your desire to produce a spec that is as perfect as it possibly could. Please keep something in mind, though: IPv6 has been designed from the ground-up with an explicit trade-off between allocation efficiency and simplicity. You call this trade-off waste, I don't. I think that removing the /64 hard boundary goes too far on the allocation efficiency side of that trade-off. Michel. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
