Particularly focusing on the FD00/8 space... I'll raise my sole dissention up front:
3.2.2 and 3.2.3 are unnecessarily prescriptive for local addresses. Since the goal is simply to get something which is 'good enough' unique, all you need is a mechanism for choosing a number that no-one else is likely to be using. For /48, hashing from an EUI-48 is currently good enough, although you are compressing 48 bits into 40 so it could possibly cause problems when the EUI-48 space is saturated. For /64 (ie by-subnet numbering), you can fit a full EUI-48 with some bits to spare. Operationally, the requirement is that the generated /64 prefix is unique compared to anything that else that a given node will see. Global uniqueness is a sufficient but not necessary criterion. Notice also that any two autoconfigured addresses are guaranteed to be unique, since the EUI-64 interface identifier will be dissimilar even if the /64 routing component is similar. Breaches of the EUI allocation notwithstanding. My ultimate observation is that I fail to see how a FD00::/8 address with site filtering differs in any meaningful way from an FEC0::/10 address, with two exceptions: (1) FEC0::/10 currently seems to allow overlapping disjoint scopes (ie an address is ambiguous at a particular node except for scope id). However, many implementations seem to ignore this and assume a single scope. (2) FEC0::/10 does not mandate uniqueness generation for subnet prefixes. This is a weakness, so don't deploy it without it. Do I therefore object to FD00::/8? Not at all. Paint your wheel blue rather than red if you like - I just want the functionality and two extra bits can't hurt. If redefining a chunk of the world is necessary to remove scope specifiers from local addressing, go for it. Though I will point out that once we ignore overlapping ambiguous scopes neither FEC0::/10 or FC00::/7 addresses make any difference to application writers. You are still left with two broad classes of addresses: those which promise to be filtered, and those which you can't tell. Unless we allow only one address per node an application writer MUST assume that any arbitrary source-destination pair may fail while another may succeed. And as demonstrated previously, in the absence of other information the local-local pair with longest prefix match is your most likely candidate for a working connection. -- Andrew White -------------------------------------------------------------------- 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] --------------------------------------------------------------------
