Le 2012-12-21 à 10:37, Ole Troan <[email protected]> a écrit : ... >>>> 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.
I agree with "it is the property of using stable globally unique identifiers to generate the interface-id that adds stability", and therefore don't on what we would disagree here. ... > all implementations do validate uniqueness also for EUI-64 addresses. if you > read the rest of RFC4862 that should be quite clear. All implementations you know, OK, but there can be others that don't. For example, a small device that has a reserved OUI and an exclusive NIC number for this OUI, and that uses this link address to build its IID, MAY skip the check that no other interface on the link has the same address. This is what RFC 4291 says. Deleting this MAY would be a significant change for which AFAIK no justification has expressed. >> Anyway, even with your interpretation, this isn't against adding a new >> reserved IID range to those of RFC5453. > > correct. So, if you agree, end of this subject for this particular discussion. ... >> 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. FUD, yes, but technically founded pushback that haven't been answered, no one left AFAIK. For instance, in you own long list of doubts, you included: - The need to "update every implementation". It definitely doesn't exist. - The view that "we should design protocols that do not depend on well known addresses or ports". This doesn't concern 4rd which uses neither WHA nor WKP. With these two in particular, one can get the impression that your are trying to oppose 4rd by all possible means. Without clarification of when your chair hat is on or off, this is unfortunate IMHO. > 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. Well, I am still personally satisfied with the 4rd proposal as is. Yet, I acknowledge that the suggestion made by Brian to choose a better prefix is valuable. I therefore support that the 6man answer to Softwire includes the following update of the reserved-IIDs table: +-----------------------------------------+-------------------------+ | 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] | +-----------------------------------------+-------------------------+ Regards, RD -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
