I've been noodling on these issues for a couple of days now (many thanks to all who've been trying to help me understand), and I'm kinda confused by how some unicast address semantics could be met (or not met). Specifically: how can you ping a CSID? It's possible to ping a SID, but I don't yet see how this works with CSIDs.
Per RFC 4443 S4.2, the source address of an Echo Reply MUST be the Destination Address. If I understand things correctly (a big "if") the first segment router won't reply to an Echo Request but instead `uncompress` the address and forward the packet on, until it reaches the last node. The last node won't be able to originate a packet with the correct source address though, I think. Am I missing something? Probably... On Sat, Oct 9, 2021 at 7:03 PM Erik Kline <ek.i...@gmail.com> wrote: > <random> > > To address the self-rewriting Destination Address complexity, and some > related objections, might it be possible to add a mutable TLV, requiring > the presence of an SRH (no SRH-less packets)? The mutable TLV would > contain any extra state necessary to continue decompression of the current > segment in the SRH into the Destination Address field or trigger > advancement to the next segment in the list. This would allow the DA to > remain a plain IPv6 address/SID (current operation). > > (I've had a few other thoughts, but they aren't without their own > shortcomings.) > > > On Sat, Oct 9, 2021 at 2:13 PM Brian E Carpenter < > brian.e.carpen...@gmail.com> wrote: > >> On 10-Oct-21 10:04, Robert Raszuk wrote: >> > >> > Please kindly correct me if I am wrong, but where do you see that SRv6 >> is mandated to use "IPv6 Interface IDs" ? >> >> I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that >> doesn't apply to SRV6, then it's impossible to claim that SRV6 is IPv6. >> >> This isn't just academic standards-oriented formalism. As others have >> pointed out, it has very significant deployment and operational >> implications, given that most products support IPv6, not SRV6. >> >> Brian >> >> > >> > On Sat, Oct 9, 2021 at 11:00 PM Mark Smith <markzzzsm...@gmail.com >> <mailto:markzzzsm...@gmail.com>> wrote: >> > >> > It's stated twice in section 2.5 of RFC4291. >> > >> > For all unicast addresses, except those that start with the binary >> > value 000, Interface IDs are required to be 64 bits long and to >> be >> > constructed in Modified EUI-64 format. >> > >> > >> > All Global Unicast addresses other than those that start with >> binary >> > 000 have a 64-bit interface ID field (i.e., n + m = 64), >> formatted as >> > described in Section 2.5.1 < >> https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.1>. Global >> Unicast addresses that start with >> > binary 000 have no such constraint on the size or structure of >> the >> > interface ID field. >> > >> > >> > Please also see RFC7421, Analysis of the 64-bit Boundary >> in IPv6 Addressing. >> > >> > >> > >> > >> > >> > >> > On Sun, 10 Oct 2021, 07:27 Robert Raszuk, <rob...@raszuk.net >> <mailto:rob...@raszuk.net>> wrote: >> > >> > > Hi Brian, >> > > >> > >> Which means: 64 bits. >> > > >> > > Sorry but what is so magic about /64 here ? >> > >> > It is mandated by the current IPv6 addressing architecture. >> >> > >> > >> > Really ? Where ? I am looking at RFC4291 and nowhere I can find >> /64 reference. >> > >> > Moreover sections 2.4 and 2.5 are very clear that there is no >> magic /64 hard defined. >> > >> > The text actually goes even further and says: >> > >> > Except for the knowledge of the subnet boundary discussed in >> the >> > previous paragraphs, nodes should not make any assumptions >> about the >> > structure of an IPv6 address. >> > >> > >> > Thx, >> > >> > R. >> > >> > >> > >> > >> > >> > Despite many discussions, there has never been consensus to >> change it. So if /64 is not the boundary between the routeable part and >> the host-specific part, it's not IPv6. >> > >> > Brian >> > >> > > >> > > Is this coming from the longest routable IPv6 prefix ? >> Sort of analogy to /24 in the IPv4 world ? Or something else ? >> > > >> > > I think LPM and CIDR techniques are pretty well >> established. >> > > >> > > Any fixed length of the address block with the meaning - >> do not use those bits inter or intra domain for anything useful even >> if your prefix+node can happily fit in /32 seems just dead wrong to me. >> And that is irrespective of any SRv6 discussion. >> > > >> > > In my books if I get allocated say /48 or /40 from RIR >> what I do with the remaining bits is my own business. >> > > >> > > Best, >> > > R. >> > > >> > > >> > > >> > > > Sorry, but it is a little bit late – RFC 8986 is >> already published. >> > > >> > > "Locators are assigned consistent with >> IPv6 infrastructure allocation." >> > > >> > > Which means: 64 bits. >> > > >> > > I have no time to study compressed SIDs, but if they >> trample on the >> > LOC they are not IPv6 addresses. >> > > >> > > Brian >> > > >> > > >> > > >> -------------------------------------------------------------------- >> > > IETF IPv6 working group mailing list >> > > i...@ietf.org <mailto:i...@ietf.org> <mailto: >> i...@ietf.org <mailto:i...@ietf.org>> >> > > Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 < >> https://www.ietf.org/mailman/listinfo/ipv6> >> > <https://www.ietf.org/mailman/listinfo/ipv6 < >> https://www.ietf.org/mailman/listinfo/ipv6>> >> > > >> -------------------------------------------------------------------- >> > > >> > >> > >> -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > i...@ietf.org <mailto:i...@ietf.org> >> > Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 < >> https://www.ietf.org/mailman/listinfo/ipv6> >> > >> -------------------------------------------------------------------- >> > >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> i...@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
