<snip> > Without that, the impression is that everyone is just silently agreeing > (other than those who say that the draft can't change because it already > exists) with the points being made, but I am pretty sure that's not the > case. But I have no idea at all why. Maybe someone can convince me that > there's actually some benefit that I just can't see. <snip>
I, for one, am silently agreeing with you. As best I can tell, here are the arguments involved (I will present each argument followed by my opinion on the argument): 1) The u bit only makes sense if we keep the 64-bit boundary, so we must keep the 64-bit boundary just in case we one day figure out how to use the u bit. This argument should be removed because even Michael Py states that it is a red herring. I.e., even Michael Py states that the strength of his argument for keeping the 64-bit boundary does not rest on the possible uses of the u bit. 3) EUI-64 is good. It shouldn't be removed! No one is advocating this. In fact, what we are advocating does not have any influence on how anyone else chooses to operate. I am simply asking for the freedom to use the last 64 bits in whatever way I choose. 3) The draft should not be updated. Instead, stability is crucial. The draft is already being updated. Furthermore, removing the 64-bit boundary does not appear to have an affect on any existing implementations. 3) Current implementations do not enforce the 64-bit boundary, nor do they enforce the uniqueness implied by the u bit. I am slightly unclear about these two points. I have seen that implementations do not inforce the uniqueness implied by the u bit; however, it has already been decided to ignore the u bit in this argument. I am not sure if implementations forbit prefixes longer than 64-bits. Based on what I have read on this list, they don't. If this is true, than it is fair to say implementation experience has proven that the 64-bit boundary is not necessary. Implementation experience is a very valid reason to update the draft. 4) Current practice does make use of prefixes longer than 64 bits. This increases the strength of the argument in number 3. Current practice should indeed have an influence on whether or not this draft should be updated. In other words, because using a /126 has been proven to be safe for point-to-point links, there is no reason to forbid it. 4) Allocation efficiency for point-to-point links. Some people feel that the the overhead of using a /64 for a point-to-point link is small, and quite justifiable if it simplifies things. Others feel that space should not be wasted, and that any simplification achieved is not justifiable, in this case. I feel that the amount of time you spend arguing a point should be based on the relative importance of the point. Having said that, I'd like to say...nothing (i.e. the importance of this point does not justify further argument) :) 5) I want to have maximum freedom with my /64. This is the most important argument, in my mind. I don't think any benefit gained from establishing a 64-bit boundary can possibly justify loosing the freedom of not being confined to that boundary. I think that this point will become increasingly important in the long run. Furthermore, I think any arguments in favor of the 64-bit boundary will likely become less important in the long run. 6) Not establishing a 64-bit boundary will make the lives of ASIC designers difficult. I know nothing about designing ASIC's. However, I presume that the header chaining used in IPv6 is an even more difficult challenge for ASIC designers. Hence, I doubt this argument has real merit. 7) Using a 64-bit boundary may permit certain memory optimizations since every prefix will be at most 64 bits long. This argument has been disproved in this thread twice. In summary, I feel that experience has shown that the 64-bit boundary is unnecessarily confining and should be removed. Best Regards, -jj -- o*s*o*pho*bi*a n. A common fear among embedded systems programmers. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
