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. > 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. 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
