Andrew, you don't seem to see the *ambiguity* of FEC0::/10 prefixes as a major problem in itself, but operational experience with 10/8 suggests that ambiguity is actually a bigger pain than NAT in some scenarios (VPNs between two Net 10 networks, for example). The virtue of Bob's proposal is that it eliminates this ambiguity while conserving the perceived value of SLs.
As for being too prescriptive, I think it's important to specify an algorithm that will give good enough results when applied blindly. Are you arguing for a SHOULD here? Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK Andrew White wrote: > > 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] > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
