Ole Troan wrote: > Remi, > >>>>> with Remi's proposal, a duplicate address will not even be detected. >>>> Correct: even if software is available to detect collisions between 4rd >>>> addresses and RFC 4291-compatible host addresses, it won't detect any. >>>> (Such software, which isn't mandatory for 4rd, is of course not excluded >>>> either.) >>>> >>>> The simple reason for this non-detection is that these addresses have IIDs >>>> in disjoint sets. >>> I think you have received quite a lot of pushback against creating disjoint >>> sets of IIDs. >> Different understanding. >> - Those who have supported haven't needed to repeat their support (see names >> in http://www.ietf.org/mail-archive/web/ipv6/current/msg17094, and one more >> in http://www.ietf.org/mail-archive/web/ipv6/current/msg16972) >> - Those who have objected continue to receive answers to their concerns (the >> above being one instance). >> >> Besides, these remaining concerns are aside from the question asked by >> Softwire (whether reserving a subset of an IID range unused by RFC 4291 is >> compatible with the IPv6 addressing architecture). > > I think our understanding of the IPv6 addressing architecture is incompatible. > there are no unused subset or unused ranges of interface-ids in IPv6. > > cheers, > Ole FWIW I agree with Ole.
An IID currently only has relevance to the IPv6 addressing architecture specified in RFC4291 only when concatenated behind a /64 unicast address prefix, and only on an individual link. draft-ietf-softwire-4rd proposes breaking that tight coupling. I'm not per se against breaking the tight coupling, because RFC4291 states "The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope." But it is a change to current specification. But in addition IMVHO..... RFC 4291 states "Modified EUI-64 format-based interface identifiers may have universal scope when derived from a universal token (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a global token is not available (e.g., serial links, tunnel end-points) or where global tokens are undesirable (e.g., temporary tokens for privacy [PRIV])." The intention here to me is quite clear, even if it isn't written in normative language. u=1 should be used for generating an IID derived from universal tokens. The examples of universal tokens given in the document are those, which by the nature of their distributed administration, can be assumed to universally unique. Appendix E of draft-ietf-softwire-4rd demonstrates how to generate an IPv6 address for use with 4rd from an RFC 1918 address. I do not consider an IPv4 RFC1918 address to be a global/universal token. I don't see how generating an identifier that has to be unique way beyond an individual link [by definition in 4rd], from an identifier or token that clearly isn't globally unique [RFC1918], fits anywhere within the spirit of any text contained in RFC4291. To quote RFC1918 "As before, any enterprise that needs globally unique address space is required to obtain such addresses from an Internet registry." Use of magic beans to ensure global uniqueness would seem to be excluded. So as I have previously asserted, I think there certainly needs to be some clarification of any possible transportation of 4rd across an AS boundary, regardless of any other discussions. Transporting RFC1918 addresses across an AS boundary (in a 4rd tunnel), accidentally or otherwise, would to me be a clear violation of RFC1918, and the IPv4 [sic] addressing architecture. Nothing I've read in the meantime has changed this view. Which is one reason why I continue to assert that a global IID reservation is not necessary for experimental deployment of 4rd at this time: IMVVHO 4rd as specified today in draft-ietf-softwire-4rd can only safely be deployed within a single AS. Inter-AS 4rd would be potentially harmful. And for the record, Remi: The IETF is a meritocracy. I don't believe it's your role to call consensus in this WG, or otherwise define or limit what is, or is not, a valid discussion or stand point. It isn't mine either for that matter. If the chairs wish to make a statement, I'm sure they will do. Respectfully yours, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
