Templin (US), Fred L wrote on 13/08/2021 15:49:
Nick, it occurred to me that there is something else to think about. When RFC3068 set aside 192.88.99.0/24, it only defined a use for one single IPv4 unicast address out of the 254 available within that prefix. I therefore think that that one address must now and forever be considered as "off-limits" to any new proposal. Or, am I wrong about that?
there are two aspects to this: policy and practice. From a policy point of view, 192.88.99.0/24 has been hard-coded from into routing code, application core and configurations everywhere, which means that reassigning it for other purposes should be avoided unless there's a clear and overriding reason to do so, long enough after the original function was formally deprecated to ensure that the prefix was no longer contaminated. This is simply a statement of reasonable resource stewardship.
There are plenty of examples of hard-coding (q.v. search engine output for 0xc0586300 or 192.88.99.0/24), so we're not even within sight of this as a long term aim.
From an operational point of view, 192.88.99.0/24 is still routed (and active) on the public Internet which means that if it's used for another purpose, then the two mechanisms will end up stomping on each other today. This will reduce the reliability, and hence the usefulness, of OMNI. It doesn't really that people probably oughtn't be announcing the prefix or depending on anycast 6to4 services: the point is that they are, and that serious operational problems are likely to occur if the prefix is repurposed.
But, a new proposal might want to make use out of all available unicast addresses within the /24. If that were to be the case, would it provide more reason to avoid 192.88.99.0/24?
there's been no rationale proposed for why 192.88.99.0/24 should be used here, and several reasons why it should be avoided. The rationale will need to be compelling enough to override any existing concerns about immediate re-use.
Nick
