Subject: Re: I want to reclaim 192.88.99.0/24 - does anyone have a problem with that?

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 13 Aug 2021 13:45:02 +0000

Nick,

> -----Original Message-----
> From: Nick Hilliard [mailto:[email-masked]]
> Sent: Friday, August 13, 2021 3:41 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Dale W. Carder <[email-masked]>; Hunter (US), Mark W <[email-masked]>; 6man WG <[email-masked]>; IETF
> discussion list <[email-masked]>; Nache (US), Samuel J <[email-masked]>; Dickson (US), Sean M
> <[email-masked]>; Dillenburg (US), Don <[email-masked]>; Tran (US), Katherine K
> <[email-masked]>
> Subject: Re: I want to reclaim 192.88.99.0/24 - does anyone have a problem with that?
> 
> Templin (US), Fred L wrote on 12/08/2021 23:10:
> > So, how does one go about earmarking an IPv4 /24 as a protocol-specific anycast
> > prefix for IANA to place in the special-use IPv4 addresses registry - just put it in
> > the "IANA Considerations" section of a standards-track ID and let nature take its
> > course?
> 
> one of the steps would be to describe to the ietf why 192.88.99.0/24 was
> significantly preferable to another address block, given that it is
> still routable on the big-I Internet dfz.

The 192.88.99.0/24 is our Plan A; Plan B is to somewhere find a different IPv4 /24
that is not currently used for any purpose and then ask IANA to register it as the
"OMNI Anycast Prefix" in the IPv4 special use address registry.

Thanks - Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 13 Aug 2021 14:49:14 +0000

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?

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?

Fred

> From: ietf [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Friday, August 13, 2021 6:45 AM
> To: Nick Hilliard <[email-masked]>
> Cc: Tran (US), Katherine K <[email-masked]>; 6man WG <[email-masked]>; IETF discussion list <[email-masked]>; Nache (US),
> Samuel J <[email-masked]>; Hunter (US), Mark W <[email-masked]>; Dickson (US), Sean M
> <[email-masked]>; Dillenburg (US), Don <[email-masked]>; Dale W. Carder <[email-masked]>

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 14 Aug 2021 11:50:25 +0100

> must now and forever be considered as "off-limits" to any new proposal. Or, am

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.

> within the /24. If that were to be the case, would it provide more reason to avoid

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