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