2012-12-20 20:29, Ole Troan <[email protected]> : > Remi, > > [...] > >>> To make assertions about IP addresses based on the EUI-64 is to impose >>> requirements that don't actually exist in IP. It's a little like saying >>> that concrete MUST ("are required to") be grey because the rocks we use in >>> it happen to be grey; no I can have concrete of other colors if I want. >> >> I do agree that, despite a rule exists in some RFC one can see >> configurations that don't comply with it. >> Consequently, "intended to be globally unique" doesn't mean "guaranteed to >> be globally unique in real life", right. >> >> This isn't a reason, however, to abandon rules that proved to be useful. >> AFAIK, the rule that IIDs having u=1 must (so far) only be based on global >> IEEE EUI-64 addresses is one of these useful rule not to be abandoned. > > how has it proved to be useful? > I'm not aware of any protocol or implementation using it.
As already said, it facilitates address stability. This is so with OSes that, by default, base their IIDs on EUI-64 addresses of their link adapters. >>> The comment Brian is making refers to IP's requirements, which are that the >>> IID used in a subnet by an interface must be unique within that subnet. >> >> This is a clear requirement, on which I think we all agree. >> >> It is worth noting here that satisfaction of this requirement DOES DEPEND in >> part on IIDs having u=1 being actually unique. >> (Reason is that RFC 4862 says (uppercase added) "IPv6 nodes are NOT required >> to validate that interface identifiers created with modified EUI-64 tokens >> with the "u" bit set to universal are unique".) > > to be pedantic it is RFC4291 that says that. Right, the RFC number wasn't the right one. Thanks. > the only thing it says is that an implementation does not have to validate > that a interface-id is _globally_ unique (how could it?), it still > has to validate that an address created with that interface-id is unique. I find it very hard to interpret the above sentence the way you do. Since, as you rightly imply, there is no way locally to check _global_ uniqueness, this sentence is useful only if it means that it is uniqueness _on the link_ that is "not required to be validated" if u=1. Anyway, even with your interpretation, this isn't against adding a new reserved IID range to those of RFC5453. > >>> If one has a physical machine with an interface that supports a dozen >>> virtual machines, the requirement is not that all of the physical and >>> virtual machines use IP addresses derived from the physical interface MAC >>> address; >> >> Well understood. >> >>> the requirement is that they each have IIDs that are unique within the >>> subnet. The obvious choice will be to use privacy addresses for the VMs, >>> which will appear outside the physical machine as the one interface having >>> that many IP addresses. >> >> Agreed. >> Since these IIDs will have u=0, this is neutral in the discussion on u=1 >> IIDs. >> >> >> AFAIK, no technical and/or operational consideration remains that would >> prevent the IANA registry on IIDs to be updated as follows (the 4rd range is >> that proposed by Brian). > > that's a different question than what was asked by the softwire. > is the question to the 6man WG now, "is it acceptable to reserve 2^48 > interface-id's" using the RFC5453 registry? The basic question is whether reserving for 4rd a specific 8-bit IID is "compatible with the IPv6 addressing architecture" as currently specified. Besides some expressed FUD, which isn't illegitimate in face of anything new, no such conflict has been identified by those who checked carefully. This would normally lead to a flat "yes it is compatible" but, during the discussion, it appeared that the proposed 8-bit prefix can advantageously be replaced by a longer prefix closer to an already reserved prefix, and this without any problem for 4rd. A suggestion by 6man to change the proposed prefix value can therefore be constructive complement to the flat answer. I hope the WG will make this step forward. Regards, RD > > cheers, > Ole > > >> >> The answer returned to Softwire can then be a request to change the 4rd >> draft accordingly. >> >> +-----------------------------------------+-------------------------+ >> | Interface Identifier Range | Description | >> +-----------------------------------------+-------------------------+ >> | 0000:0000:0000:0000 | Subnet-Router Anycast | >> | | [RFC4291] | >> | | | >> | FDFE:0000:0000:0000-FDFE:FFFF:FFFF:FFFF | Reserved 4rd Unicast | >> | | Addresses [RFCxxxx] | >> | | | >> | FDFF:FFFF:FFFF:FF80-FDFF:FFFF:FFFF:FFFF | Reserved Subnet Anycast | >> | | Addresses[RFC2526] | >> +-----------------------------------------+-------------------------+ > > cheers, > Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
