>>> Still, using IID == 0 seems to be asking for trouble, since it's a > reserved value and is definitely special-cased in some code. Unless, that > is, you want exactly the properties described in RFC4291 section 2.6.1 > (thanks, Mark Smith). >> >> As Michael described, this assignment to loopback interfaces works fine. >> The addresses are assigned as /128’s, not prefixes, the > router subnet anycast concern is not applicable. > > > I'm not sure about that. Is there a risk that ICMP replies sent to such an > address might get lost? Standard host stacks identify any such address as a > router when they save it in the neighbor cache. My home router declines to > answer ICMP pings sent to such an address. (Try pinging fe80::) However, that > is not our problem here. > > On the other hand, it seems that as the compressed SIDs are shifted out one > at a time, we will end up with an effective zero IID at the final recipient. > So the DA would then be a subnet router anycast address, according > to RFC4291. That seems a bit strange and might have unexpected consequences, > such as more than one box handling the packet and decapsulating it. >
Just to be clear. An IPv6 node does not make any assumption about the prefix length. Ref RFC5942. IID has no meaning unless both the address and associated subnet prefix length is known. I agree with you though, there appears to be a need for clarification regarding the properties of these addresses. RFC6052 updated 4291 and had the following: When a /32 prefix is used, an all-zero suffix results in an all-zero interface identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet- router anycast address. However, in our specification, there is only one node with an IPv4-translatable IPv6 address in the /64 subnet, so the anycast semantic does not create confusion. We thus decided to keep the null suffix for now. This issue does not exist for prefixes larger than 32 bits, such as the /40, /56, /64, and /96 prefixes that we recommend in Section 3.3. Looks like this issue goes back to RFC8986 or even RFC8754(?) If this is not partiuclar to the srh-compression draft, could a separate document, updating RFC4291, and clarifying the particular properties of these addresses work? O.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
