kre, > The changes are relatively minor, and affect nothing at all > about the way that v6 works, or is used, or is currently > deployed, or ...
I do not agree. When designing IPv6 ASICs, one might like the hard limit at /64, for example. > Note: to go to DS we have to provide evidence of at least > two independent implementations of every feature of the doc. > Any that aren't actually implemented are required to be > removed (perhaps to another doc to recycle at PS, but more > often to experimental or just the vast emptiness of space). > Where are the implementations of the 'u' bit implying global > uniqueness? Where are the implementations requiring /64 > everywhere, everytime? If they don't exist, the IETF's rules > require this stuff to be removed. You are trying to use the 'u' bit as a scapegoat. If there was compelling reasons to remove the hard /64 boundary, I don't think the 'u' bit would be much of a problem. > So, let me turn the question around. Is there anyone out there > who believes the draft should stay as it is (in this area) and > who is willing to attempt to explain why? > If there's no-one, then to me that looks like consensus for a > change... This is not the way it works, IMHO. If the draft is there it's because it has reached consensus. The consensus question is about the changes you suggest, not the current state of the draft. I am using /64s for ptp links. They work fine. The argument that I am wasting precious address space is fud, as my site gets a /48 anyway. Only for the very few sites that actually require more than a /48 can there be a gain using longer prefixes, and most of the time that gain is null as well because sites that require more than a /48 do have internal aggregation, and there again the /64 point to point links are lost into the internal addressing structure. For ISPs/operators, assigning /64s to ptp links wastes 1/64k of their customer address space, peanuts. Here is where I stand: the RFC says that you should use /64. The only real argument to use longer prefixes is conservation, and it's fud. The potential 25% savings in 1% of situations is not worth modifying the addressing architecture document, as respecting it costs no more than not doing it, and as it has reached consensus. 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] --------------------------------------------------------------------
