[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    Re: I want to reclaim 192.88.99.0/24 - does anyone have a problem with that?
From:       Nick Hilliard <nick () foobar ! org>
Date:       2021-08-14 10:50:25
Message-ID: 93bdffac-c881-7f4c-36c5-99bc80edde12 () foobar ! org
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]