Alain, > Specifically, the part I object to are:
> - under the FD00::/8 prefix (Locally assigned): > using the 'all zero' pattern instead of random bits would have the > exact same effect > as using the 'site local' address: it would create ambiguous > addresses. The ipv6 > wg spend over a year deprecating 'site local' addresses for that > reason. It is the duty > of this wg to document that using that particular pattern can be > harmful. I think I understand your point here. > -under the FC00::/8 prefix (Centrally assigned:) > the document says that: > " The requirements for centrally assigned global ID allocations are: > - Available to anyone in an unbiased manner. > - Permanent with no periodic fees. > - Allocation on a permanent basis, without any need for renewal > and without any procedure for de-allocation." > I object that there is any technical requirement to mandate that the > allocations have to be permanent. There is a requirement to make > those addresses stable in time, but this is very different from > permanent allocation. Let me ask you this then. If the word "permanent" is not appropriate, what word is? To me, "not permanent" means that at some future time an allocation that has been made to an endsite may be revoked. But this begs the question of why an end site would ever want to use such addresses. I.e, this raises such questions as: - under what conditions would an address be reclaimed? - who does the revokation? - what recourse does the end site have? My understanding is that the whole point of these allocations being "permanent" is that once and ends site gets one, it can use it without worry that it will have to give it up at some future time. Also, why do we need to make these allocations "non permantent"? Is there some future scenario we're worried about where it becomes important to be able to reclaim these addresses? I.e., are they ever going to become a scarce resource? Also, would we ever conceive of taking back an end-site's usage of an address block it generated under the non-centrally allocated block? In particular, if your answer no, but yes for those from the centrally allocated block, I'd like to understand the rational behind that thinking. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
