Re: Small Internet border router options?

[Richard Holbo]

+1 on the Ubiquiti Infinity.. I've used a number of them in various roles..
Linux based and have had 1 hardware failure after a couple years.  Try to
keep bridging to a minimum as it'll eat the processor, but for routed
traffic, no issues.
/rh


On Mon, May 13, 2024 at 11:56 AM Tom Samplonius  wrote:

>
>   What are using for small campus border routers?  So four to eight 10G
> ports with a FIB for full scale L3?
>
>
> Tom
>
>
>

RE: Q: is RFC3531 still applicable?

[Adam Thompson]

I may have mis-read it (I admit I didn’t read it all that carefully) but I 
think RFC3531 is talking about the strategy for assigning /64s out of a larger 
pool (a /56, say).
-Adam

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca
Chat with me on 
Teams

From: Mel Beckman 
Sent: Tuesday, May 14, 2024 3:13 PM
To: Adam Thompson 
Cc: nanog 
Subject: Re: Q: is RFC3531 still applicable?

I never could understand the motivation behind RFC3531. Just assign /64s. A 
single /64 subnet has 18,446,744,073,709,551,616  host addresses.  It is 
enough. Period.




 -mel


On May 14, 2024, at 12:54 PM, Adam Thompson 
mailto:athomp...@merlin.mb.ca>> wrote:

Not an IPv6 newbie by any stretch, but we still aren’t doing it “at scale” and 
some of you are, so…

For a very small & dense (on 128-bit scales, anyway) network, is RFC3531 still 
the last word in IPv6 allocation strategies?

Right now, we’re just approaching it as “pick the next /64 in the range”, as it 
all gets aggregated at the BGP border anyway, and internally if I really try 
hard, I might get to 200 subnets someday.

Is there any justification for the labour in doing something more complex like 
center-allocation in my situation?  Worrying about allocation strategies seems 
appropriate to me if you have 100,000 subnets, not 100.

Opinions wanted, please.
-Adam

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca
Chat with me on 
Teams

Re: Q: is RFC3531 still applicable?

[Mel Beckman]

I never could understand the motivation behind RFC3531. Just assign /64s. A 
single /64 subnet has 18,446,744,073,709,551,616  host addresses.  It is 
enough. Period.


 -mel

On May 14, 2024, at 12:54 PM, Adam Thompson  wrote:


Not an IPv6 newbie by any stretch, but we still aren’t doing it “at scale” and 
some of you are, so…

For a very small & dense (on 128-bit scales, anyway) network, is RFC3531 still 
the last word in IPv6 allocation strategies?

Right now, we’re just approaching it as “pick the next /64 in the range”, as it 
all gets aggregated at the BGP border anyway, and internally if I really try 
hard, I might get to 200 subnets someday.

Is there any justification for the labour in doing something more complex like 
center-allocation in my situation?  Worrying about allocation strategies seems 
appropriate to me if you have 100,000 subnets, not 100.

Opinions wanted, please.
-Adam

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca
Chat with me on 
Teams

Q: is RFC3531 still applicable?

[Adam Thompson]

Not an IPv6 newbie by any stretch, but we still aren't doing it "at scale" and 
some of you are, so...

For a very small & dense (on 128-bit scales, anyway) network, is RFC3531 still 
the last word in IPv6 allocation strategies?

Right now, we're just approaching it as "pick the next /64 in the range", as it 
all gets aggregated at the BGP border anyway, and internally if I really try 
hard, I might get to 200 subnets someday.

Is there any justification for the labour in doing something more complex like 
center-allocation in my situation?  Worrying about allocation strategies seems 
appropriate to me if you have 100,000 subnets, not 100.

Opinions wanted, please.
-Adam

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca
Chat with me on 
Teams

[NANOG-announce] NANOG 91: Keynote & Conference Kit Announcement  + More

[Nanog News]

*Announcing NANOG 91 Keynote! *
*Juniper Networks' Kireeti Kompella Will Present "Network Digital Twin"*


*SVP and Chief Engineer for the AWAN BU in Juniper Networks, Kompella, will
discuss "digital twins" and how they are used in many contexts.*
As networks ramp up on automation, this is a logical next step. This talk
will describe what a network digital twin is, what form it could take, how
it can be instantiated, what one can do with an NDT, and in what use cases
an NDT becomes vital.

*VIEW MORE * 

*Guest Blog: RPKI ROV Deployment Reaches Major Milestone!*
*BGP Experts Kentik's Doug Madory + Fastly's Job Snijders Review the Latest
RPKI ROV Deployment Metrics *

*Why it's Worth Your Time:* For the first time in the history of RPKI
(Resource Public Key Infrastructure), the majority of IPv4 routes in the
global routing table, are covered by ROAs (Route Origin
Authorizations) according
to the NIST RPKI Monitor. IPv6 crossed this milestone late last year.

*R
EAD
MORE
*

*NANOG 91 Conference Kit Available! *
*Share on your Social, Newsletter, Website, + More! *

*Help us spread the word about NANOG 91! *Our new NANOG 91 Conference Kit
is available. Our website contains all N91 materials, including messaging,
logos, and graphics, needed to promote our next meeting. Download and share
with your community today!

*VIEW NOW * 

*Don't Miss out on Hackathon! *
*Sponsored by [Your Company Here - Email Us for Info]*

Your opportunity to build relationships with global industry peers in a
casual setting, boost your resume, + have fun at our upcoming meeting,
NANOG 91!

*GAME ON! * 
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

NANOG 91: Keynote & Conference Kit Announcement  + More

[Nanog News]

*Announcing NANOG 91 Keynote! *
*Juniper Networks' Kireeti Kompella Will Present "Network Digital Twin"*


*SVP and Chief Engineer for the AWAN BU in Juniper Networks, Kompella, will
discuss "digital twins" and how they are used in many contexts.*
As networks ramp up on automation, this is a logical next step. This talk
will describe what a network digital twin is, what form it could take, how
it can be instantiated, what one can do with an NDT, and in what use cases
an NDT becomes vital.

*VIEW MORE * 

*Guest Blog: RPKI ROV Deployment Reaches Major Milestone!*
*BGP Experts Kentik's Doug Madory + Fastly's Job Snijders Review the Latest
RPKI ROV Deployment Metrics *

*Why it's Worth Your Time:* For the first time in the history of RPKI
(Resource Public Key Infrastructure), the majority of IPv4 routes in the
global routing table, are covered by ROAs (Route Origin
Authorizations) according
to the NIST RPKI Monitor. IPv6 crossed this milestone late last year.

*R
EAD
MORE
*

*NANOG 91 Conference Kit Available! *
*Share on your Social, Newsletter, Website, + More! *

*Help us spread the word about NANOG 91! *Our new NANOG 91 Conference Kit
is available. Our website contains all N91 materials, including messaging,
logos, and graphics, needed to promote our next meeting. Download and share
with your community today!

*VIEW NOW * 

*Don't Miss out on Hackathon! *
*Sponsored by [Your Company Here - Email Us for Info]*

Your opportunity to build relationships with global industry peers in a
casual setting, boost your resume, + have fun at our upcoming meeting,
NANOG 91!

*GAME ON! * 

Re: On consistency and 192.0.0.0/24

[Warren Kumari]

On Tue, May 14, 2024 at 1:24 PM, Tom Beecher  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.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 
>> To: NANOG 
>> 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:
>> > 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 

Re: On consistency and 192.0.0.0/24

[borg]

From what I looked at IANA Special Registry, this whole range looks
like some service IPs. I mean, they provide specific service within AS.
From me then, it looks like bogon. You should not receive routing for those
addresses from other AS. (PNI is out of scope here).


-- Original message --

From: Tom Beecher 
To: "Jakob Heitz (jheitz)" 
Cc: "nanog@nanog.org" 
Subject: Re: On consistency and 192.0.0.0/24
Date: Tue, 14 May 2024 13:24:47 -0400

>
> 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 
> To: NANOG 
> 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
>
>

Re: On consistency and 192.0.0.0/24

[Tom Beecher]

>
> 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 
> To: NANOG 
> 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
>
>

Re: On consistency and 192.0.0.0/24

[Jakob Heitz (jheitz) via NANOG]

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 
To: NANOG 
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:
.

>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

Re: On consistency and 192.0.0.0/24

[borg]

No, I am not confusing those two. Actually, Im using 192.0.2.0 as well
here, for server's internal SNAT.

Okey, I checked that registry and there is nothing I care about.
It seems the choice to using 192.0.0.0/24 internally at desktop
was smart enough ;)

Thx for info.


-- Original message --

From: John Kristoff 
To: nanog@nanog.org
Subject: Re: On consistency and 192.0.0.0/24
Date: Tue, 14 May 2024 07:29:54 -0500

On Tue, 14 May 2024 12:00:15 +0200 (CEST)
b...@uu3.net wrote:

> Was RFC5736 obsoleted?

No.

> Its a nice tiny subnet for special purposes. I personaly use it

Are you confusing this with 192.0.2.0/24?  192.0.0.0/24 is occasionally
updated with new assignments drawn from it.  Just be aware you're
potentially colliding with some other, new use in that range.

John

Re: Small Internet border router options?

[Rubens Kuhl]

Used/Refurbished Cisco ASR 900 or 1000 family, perhaps ?

Rubens

On Mon, May 13, 2024 at 3:53 PM Tom Samplonius  wrote:
>
>
>   What are using for small campus border routers?  So four to eight 10G ports 
> with a FIB for full scale L3?
>
>
> Tom
>
>

Re: On consistency and 192.0.0.0/24

[borg]

[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 
To: NANOG 
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:
.

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

Re: Small Internet border router options?

[Christopher Hawker]

+1 on the CCR2216 routers, rock-solid stuff...

Regards,
Christopher Hawker

From: NANOG  on behalf of Tony 
Wicks 
Sent: Tuesday, May 14, 2024 5:08 AM
To: 'Tom Samplonius' 
Cc: 'NANOG' 
Subject: RE: Small Internet border router options?

Juniper MX204, Nokia SR1/SR1s or for the cheaper side  Mikrotik CCR2216

-Original Message-
From: NANOG  On Behalf Of Tom
Samplonius
Sent: Tuesday, May 14, 2024 6:52 AM
To: NANOG 
Subject: Small Internet border router options?


  What are using for small campus border routers?  So four to eight 10G
ports with a FIB for full scale L3?


Tom