On Sat, 28 Dec 2019 at 09:45, Robert Raszuk <rob...@raszuk.net> wrote: > > Hi Mark, > > Happy New Year ! > >> >> The key point is that RIDs look like IPv4 addresses, but are not. They only >> have adopted the formatting convention of IPv4 addresses. They're 32 bit >> quantities. They could have just as easily been formatted as 0x hex strings >> e.g. 0xffffffff for my example. Their continued use as 32 bit quantities and >> identifiers in IPv6 supporting OSPFv3 shows how decoupled from both IPv4 and >> IPv6 they are. > > > We are again in 100% agreement here. That was exactly my analogy to RID made > to Ron. But on the other hand let's also recognize that this is pretty common > to assign router_id to be yr loopback address in number of protocols. >
Right. I've done that. However, it is a convention, nothing more. In OSPF and BGP the RID is not an IPv4 address even if it looks like one, and is never used as an IPv4 address. SIDs are used as IPv6 addresses. When SIDs are used as IPv6 addresses, they must be compliant with the IPv6 specifications. >> >> SIDs on the other hand are at some point in time used as IPv6 destination >> addresses. > > > Well SID locators (of variable length) need to assure packet delivery to a > segment end points. That is a subtle but very important difference. > >> >> That means they have to either always comply with IPv6 address requirements >> - RFC4291 - or be converted to meet IPv6 address requirements when they're >> used as IPv6 addresses (e.g. they're 64 bit quantities that are then used as >> an IPv6 Interface Identifier by prepending an IPv6 addressing compliant /64 >> prefix) > > > IPv6 address fields are 128 bits (for good or for bad of it). >And there are no :: or : there to the point Alex made earlier. What matters is >to make sure that routing prefixes deliver packets to correct destinations. > > I am very puzzled reading those messages what is the point regarding all > remaining bits outside of locator ? If this is to say RFC4291 did not defined > a SID - sure you won - game over. But at the same time I do not see anything > in RFC4291 which would prohibit me to put any bit sequence I like in the > remaining (least significant) bits of the address. If you limit yourself to the Interface Identifier portion of the IPv6 address, you can encode other semantics in that portion that are significant to the end points. That is permitted by RFC 7136, "Significance of IPv6 Interface Identifiers:" "In all cases, the bits in an IID have no generic semantics; in other words, they have opaque values. In fact, the whole IID value MUST be viewed as an opaque bit string by third parties, except possibly in the local context." While the packet is being forwarded towards an end point, those end-point semantics are to be ignored, because IPv6 forwarding is longest match across all 128 bits: BCP 198/RFC 7608, "IPv6 Prefix Length Recommendation for Forwarding" Regards, Mark. >And I think this is the crux of the little discussion here. > > Cheers, > R. > > > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
