On Tue, May 14, 2024 at 1:24 PM, Tom Beecher <beec...@beecher.cc> wrote:

> That means that some IP addresses in the block 192.0.0.0/24 may be
>> routable.
>>
>

It feels like people are talking past each other when they are saying
"routable" — these are fairly clearly not routable on the Global Internet,
but addresses like 192.0.0.10/32 (the TURN anycast address) look like they
are intended to be routed within a network:
"IP anycast can also be used for TURN service discovery.  A packet
   sent to an anycast address is delivered to the "topologically
   nearest" network interface with the anycast address."

but this is clearly not **supposed** to leak:
"In a network without any TURN server that is aware of the TURN
   anycast address, outgoing TURN requests could leak out onto the
   external Internet, possibly revealing information.

   Using an IANA-assigned well-known TURN anycast address enables border
   gateways to block such outgoing packets.  In the default-free zone,
   routers should be configured to drop such packets."

W


>> So, I would not make this a bogon.
>>
>
> This ignores note 2 on the IANA definitions page, next to 192.0.0.0/24 :
>
>> [2]
>>
>> Not useable unless by virtue of a more specific reservation.
>>
>>  Which then lists the more specific reservations, of which SOME are
> forwardable , and some are not.
>
> The categorization as 'bogon' or not would really be determined by
> individual operator use cases, and where/how such a bogon filter is
> applied.
>
>
>
> On Tue, May 14, 2024 at 12:23 PM Jakob Heitz (jheitz) via NANOG <nanog@
> nanog.org> wrote:
>
>> RFC 5736 was obsoleted by RFC 6890.
>>
>> It says in part:
>>
>>
>>
>> 2.2.1.  Information Requirements
>>
>>
>>
>>    The IPv4 and IPv6 Special-Purpose Address Registries maintain the
>>
>>    following information regarding each entry:
>>
>> …
>>
>>    o  Forwardable - A boolean value indicating whether a router may
>>
>>       forward an IP datagram whose destination address is drawn from the
>>
>>       allocated special-purpose address block between external
>>
>>       interfaces.
>>
>> …
>>
>>
>>
>> That means that some IP addresses in the block 192.0.0.0/24 may be
>> routable.
>>
>> So, I would not make this a bogon.
>>
>>
>>
>> A better way to filter IP routes is by policy, for example based upon
>>
>> IRR and RPKI records.
>>
>>
>>
>> Kind Regards,
>>
>> Jakob
>>
>>
>>
>> ---------- Original message ----------
>>
>> Date: Tue, 14 May 2024 12:00:15 +0200 (CEST)
>> From: b...@uu3.net
>>
>>
>> [10] 192.0.0.0/24 reserved for IANA IPv4 Special Purpose Address Registry
>> [RFC5736]. Complete registration details for 192.0.0.0/24 are found in
>> [IANA registry iana-ipv4-special-registry].
>>
>> Was RFC5736 obsoleted? I think not, so I would treat it as bogon.
>>
>> Its a nice tiny subnet for special purposes. I personaly use it
>> as my Internal VM Net on my desktop for example.
>>
>>
>> ---------- Original message ----------
>>
>> From: John Kristoff <j...@dataplane.org>
>> To: NANOG <nanog@nanog.org>
>> Subject: On consistency and 192.0.0.0/24
>> Date: Mon, 13 May 2024 16:18:47 -0500
>>
>> As one to never let a good academic question go unasked... what is it
>> about 192.0.0.0/24 that is or isn't a bogon. This doesn't seem so
>> straightforward an answer to me, at least in theory.  Although in
>> practice it may already be decided whether one likes the answer or not.
>>
>> 192.0.0.0/24 was originally assigned to IANA for "protocol assignments"
>> in IETF RFC 5736, and later added to the list of reserved / special use
>> addresses in IETF RFC 6890 (aka BCP 153).   There is a corresponding
>> IPv6 block (2001::/23), but it has a significantly different history.
>>
>> Team Cymru's bogon list includes the v4 prefix.  NLNOG's bogon
>> filtering guide does not.  When I asked Job about NLNOG's position he
>> said:
>>
>>   "I was unsure what this prefix??s future plans would be and erred on
>>   the side of caution and didn??t include this prefix in the NLNOG bogon
>>   list recommendations."
>>
>> The /24 as specified is not for "global" use, but some of the more
>> specific assignments are or can be.  See:
>> <https://www.iana.org/assignments/iana-ipv4-special-registry/
>> iana-ipv4-special-registry.xhtml>.
>>
>> From my cursory examination I can't find cases where the v4 prefix or
>> more specifics have been publicly announced to any significant degree.
>> This however is not the case for the IPv6 prefix (e.g., the AS112
>> project, Teredo).
>>
>> Maybe you'd say the /24 should be filtered, but not the more specifics
>> that are deemed available for global use.  That might be reasonable,
>> except many reasonable people will filter small prefixes.
>>
>> IANA's language may have put any "do not filter" camp in a relatively
>> weak position:
>>
>>   "Address prefixes listed in the Special-Purpose Address Registry are
>>   not guaranteed routability in any particular local or global context."
>>
>> I can't remember hearing anyone complaining about bogon-related
>> reachability problems with the aggregate IANA prefixes generally.  Is
>> there a strong case to make that ops should not bogon filter any
>> addresses in these prefixes?  At least with IPv4?  What about for IPv6?
>>
>> John
>>
>

Reply via email to