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 >> >