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.
this might be off topic. but I disagree with you. it is the property of using stable globally unique identifiers to generate the interface-id that adds stability. see the draft on stable-privacy-addresses for another example (one which sets u=0). given that no implementation uses the u-flag, it is hard to see what value it adds. >>>> 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. all implementations do validate uniqueness also for EUI-64 addresses. if you read the rest of RFC4862 that should be quite clear. > Anyway, even with your interpretation, this isn't against adding a new > reserved IID range to those of RFC5453. correct. >>>> 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. there appears to be quite a lot of pushback in 6man against the use of u/g bits as specified in the 4rd draft. do I understand you correctly, that you now want to withdraw that proposal, and instead propose to make 2^48 interface-ids reserved for 4rd? if so, I'm happy to have the discussion on the merit of that proposal here. I think the working group would benefit though, to hear from you what problem you are actually trying to solve. Best regards, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------