route: 0.0.0.0/32 in LEVEL3 IRR

Thu Feb 1 10:48:32 UTC 2024

It's unfortunate, but quite common. I've seen similar occurrences in
several companies I worked for previously. For instance, one of my former
employers utilized public IP addresses belonging to others for IPMI server
access, even though it was solely for management purposes and not
communicated to any peers internally. Consequently, none of the customers
could access these public IPs. The reason for this? When the company
initially acquired these IPs, they were part of a leased range. Upon
termination of the agreement, instead of changing all the IPs, they opted
to continue using them due to the perceived hassle. Similarly, another
service provider used IPs from its leased range for DNS servers. When the
agreement ended and IPs were reallocated, they persisted with the old IPs
because updating DNS server settings on customer CPEs lacked automation and
thought it was too much trouble.

Unfortunately, such examples are not uncommon, and certainly don't
represent best practices

*Andrian Visnevschi*

On Thu, Feb 1, 2024 at 10:58 AM Owen DeLong via NANOG <nanog at nanog.org>
wrote:

>
>
> > On Jan 31, 2024, at 23:19, Frank Habicht <geier at geier.ne.tz> wrote:
> >
> > On 01/02/2024 01:45, Tom Beecher wrote:
> >> Seems a bit dramatic. Companies all over the world have been using
> other people's public IPs internally for decades. I worked at a place 20
> odd years ago that had an odd numbering scheme internally, and it was
> someone else's public space. When I asked why, the guy who built it said
> "Well I just liked the pattern."
> >> If you're not announcing someone else's space into the DFZ, or
> otherwise trying to do anything shady, the three letter agencies aren't
> likely to come knocking. Doesn't mean anyone SHOULD be doing it, but still.
> >
> > Well...
> >
> > If you're using 20.20.20.0/24 which is not "yours" (as I've seen
> happen), then certainly your customers can't get to the real 20.20.20.x
> > And even if that's not announced and used /today/ - this can change
> quickly...
> >
> > Frank
>
> You are repeating exactly the argument I made at the time.
>
> Owen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240201/00618213/attachment.html>