2013-02-07 16:34, Ray Hunter <v6...@globis.net> : > Ole Troan wrote: >> Remi, ... >> >> 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.
In RFC 4291; - 2.5 is Unicast addresses - 2.5.1 is Interface Identifiers. - It says: "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long" > draft-ietf-softwire-4rd proposes breaking that tight coupling. 4rd only depends on the RFC-4291 constraint that all native IPv6 destinations that don't start with 000 and enter a 4rd-CE site comply with the above. > > 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. No change of the current specification is needed, because of the above. > 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. (a) As a matter of fact, a 4rd IID is UNIVERSALLY UNIQUE: it contains a global IPv4 address (see the definition of a 4rd IPv4 address), followed by a CNP which cannot have the same value for two CEs sharing the same IPv4 address. (16-bit prefixes of two CE prefixes that differ only by n consecutive bits, with 0 < n < 16, are necessarily different) In view of your misinterpretation here, it may be useful to add a clarification on this in the 4rd draft itself. I can provide text if needed. (b) Seeing your reference to RFC 1918, I looked at Appendix E, the only place where it is referenced. It contains an unfortunate typo. If it facilitated the misunderstanding, sorry for that. Where it says "the public IPv4 prefix to be used for shared addresses is supposed to be 192.16.0.0/16 (0xc610)", it should have had 198.16.0.0/16. (a usual example value for a global IPv4 prefix, and equal to 0xC610). In this Appendix E, 4rd is used *as usual* for GLOBAL IPv4 over IPv6. It only happens that the (global) IPv6 is deployed using 6rd on an RFC1918 ISP network. > 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. 4rd doesn't work with RFC-1918 addresses. (And there isn't any magic bean anyway.) > 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. No problem as 4rd IPv4 addresses are all global. > 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. I have complete respect for the role of chairs, if for no other reason because I do know how difficult it is. (I a-have been long ago in such a position in another body.) I only feel being in my role when expressing my understanding of where we are. Thanks for the opportunity to correct the Appendix E typo. Regards, RD > > Respectfully yours, > RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
