- NANOG - lists.nanog.org

Re: On consistency and 192.0.0.0/24
by Jakob Heitz (jheitz) 14 May '24

14 May '24

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: borg(a)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 <jtk(a)dataplane.org> To: NANOG <nanog(a)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-speci…>. >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

4 3

On consistency and 192.0.0.0/24
by John Kristoff 14 May '24

14 May '24

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

2 4

Alien Waves
by Mike Hammett 13 May '24

13 May '24

What are your experiences with alien waves, managed spectrum, spectrum as a service, etc? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

4 6

TIMELY - FINAL REMINDER - ARIN Email Template Retirement Scheduled for 3 June 2024
by John Curran 13 May '24

13 May '24

NANOGers - If you are still emailing SWIP requests to ARIN for reporting reallocations and reassignments, please contact the ARIN Helpdesk ASAP to move a more appropriate/secure technology. Thanks, /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: Subject: [arin-announce] FINAL REMINDER - ARIN Email Template Retirement Scheduled for 3 June 2024 ... On 3 June 2024, ARIN will retire SWIP email templates for reporting reallocations and reassignments as described in the community Consultation conducted in November of 2023. After 3 June 2024, ARIN will not accept or respond to email templates. We recognize this change is significant and have several alternative options for submitting reassignment information. To facilitate a smooth transition, we encourage users to explore ARIN’s Reg-RWS service, a secure and efficient means of interacting with ARIN’s database. Those who do not need to automate reallocation and reassignment submissions may find it convenient to use ARIN Online to report this information to ARIN. For organizations who are unable to utilize Reg-RWS or ARIN Online, or for those who prefer to continue composing reassignment information in email templates, ARIN has provided an open-source template processor that customers may run within their network. This software will allow users to convert email templates to REST calls compatible with Reg-RWS. This open-source template processor was released on GitHub on 1 November 2023, and is no longer maintained by ARIN post release. If you wish to use this product beyond its initial release, you will be able to fork the repository and maintain it as your needs require. To learn more, please visit: https://www.arin.net/resources/registry/reassignments/ostp/ If you have questions about this transition, or need assistance using Reg-RWS, please contact us by submitting an Ask ARIN ticket or chatting with us using ARIN Online, or calling the Registration Services Help Desk at +1.703.227.0660 (Monday-Friday, 7:00 AM – 7:00 PM ET). Regards, John Sweeting Chief Customer Officer American Registry for Internet Numbers (ARIN) ------- REFERENCES: ARIN Reg-RWS Service: https://www.arin.net/resources/manage/regrws/ Reporting Reassignments Using ARIN Online: https://www.arin.net/resources/registry/reassignments/#reporting-reassignme…

1 0

GOV zone operational update: DNSSEC transition to algorithm 13
by Christian Elmerot 13 May '24

13 May '24

Cloudflare will start the transition of the .GOV zone to use DNSSEC signing algorithm 13 (ECDSA P-256) about a week from now. We do not expect any action to be required by the operators of DNS resolvers or by end-users due to this change. This note is being sent as a courtesy, in the interests of operational transparency.. We plan to start the transition on May 20th, 2024. The initial step will be to include algorithm 13 signatures alongside algorithm 8 signatures in signed responses sent by the authoritative .GOV nameservers. The transition will proceed through the following sequence of events: 1. Algorithm 13 signatures are published in addition to algorithm 8 signatures 2. Algorithm 13 DNSKEY records are published alongside the current algorithm 8 DNSKEYs 3. Algorithm 13 DS record is published in the root zone 4. Algorithm 8 DS record is removed from the root zone 5. Algorithm 8 DNSKEY records are removed 6. Algorithm 8 signatures are removed from responses Cloudflare has been using algorithm 13 for zone signing since 2015, pioneering its use to the wider community. The widespread adoption since serves as a testament to the maturity of the resolver ecosystem's ability to recognize and validate the algorithm. Other important zones also use algorithm 13 today, such as the .COM and .NET Top-Level Domains (TLDs) that transitioned to algorithm 13 in the fourth quarter of 2023. While we anticipate minimal operational impact for end users, we encourage you to reach out to us with any questions or reports of unexpected behavior related to the transition. Christian Elmerot, Cloudflare

1 0

[Event] Call for Presentations EPF 2024, Vienna, Austria // NANOG
by Arnold Nipper 13 May '24

13 May '24

Dear all, This is a Call for Presentations for the European Peering Forum 2024. AMS-IX, DE-CIX, LINX, NETNOD and guest IXP VIX, are happy to host the European Peering Forum (EPF) 2024 from Sunday the 15th to Wednesday 18th September 2024 in Vienna, Austria. The event will welcome peering managers and coordinators from networks connected to the host and guest Internet exchanges. Besides some interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations related to peering and technical topics of interconnection. Your presentation could address: * Interconnection Automation * Regional Peering * Interconnection / Peering Internet Governance and Regulatory Topics * Economic and Product Trends * Peering / Interconnection strategies * Interesting findings about Peering / Interconnection * 400GE and beyond * Any other hot topic related to Interconnection / Peering Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee epf-pc(a)peering-forum.eu Please include: * Author's name and e-mail address * Presentation title * Abstract * Slides (can be a draft version as long as the storyline is presented clearly) * Time requested (max. 30 minutes incl. Q&A) Submissions will be rated by the programme committee and admitted according to the available time slots. Deadlines ========= Please send in your presentation asap. The latest date for submission is June 16th. More information about the event and other activities around EPF17 may be found at * https://peering-forum.eu/2024/ / On behalf of EPF, Best regards, AMS-IX, DE-CIX, LINX and NETNOD -- Keep calm, keep distance, keep connected! Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 0

Re: Alien Waves
by Mike Hammett 12 May '24

12 May '24

"a limited set of providers willing to sell it, if at all." I know of one (Windstream) that offers it on a portion of their footprint. I swore others did, but I couldn't find them. Does anyone know who else in the NANOG area who does this? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: Mark Tinka <mark(a)tinka.africa> To: Dave Cohen <craetdave(a)gmail.com> Cc: nanog(a)nanog.org, Mike Hammett <nanog(a)ics-il.net> Sent: Sun, 12 May 2024 17:34:19 -0500 (CDT) Subject: Re: Alien Waves On 5/13/24 00:11, Dave Cohen wrote: > Mark, > > Many/all of these points are fair. My experience is purely terrestrial and obviously both the capacity and economic calculations are vastly different in those situations, which I should have called out. Actually, terrestrial economics are easier to consider because you have the one thing the subsea applications don't have in abundance... power. Fair point, terrestrial revenues are significantly lower than subsea revenues on a per-bit basis, but so are the deployment costs. That evens out, somewhat. > However, I don’t think that the optical vendor is really the challenge - I would agree that, generally, spectrum is going to be available through larger providers that are using “traditional carrier grade” platforms - but rather at the service provider level. When something invariably breaks at 3 AM and the third shift Tier I NOC tech who hasn’t read the service playbook says “I don’t see any errors on your transponder, sorry, it’s not on our end” because they’re not aware that they actually don’t have access to the transponder and need to start looking elsewhere, that’s the sort of thing that creates systemic challenges for users regardless of whether the light is being shot across a Ciena 6500 or a Dave’s Box-o’-Lasers 1000. I think you are contradicting yourself a bit, unless I misunderstand your point. Legacy vendors who have spectrum controllers have made this concern less of an issue. But then again, to be fair, adopting spectrum controllers along with bandwidth expansions via things like gridless line systems and C+L backbone architectures that make spectrum sales a lot more viable at scale do come at a hefty $$ premium. So I can understand that offering spectrum independent of spectrum controllers is going to be more trouble than it is worth. Ultimately, what I'm saying is that technologically, this is now a solved problem, for the most part. That said, I don't think it will be the majority of DWDM operators offering spectrum services en masse, for at least a few more years. So even if you want to procure managed spectrum or spectrum sharing, you are likely to come up against a limited set of providers willing to sell it, if at all. Mark.

4 3

Re: Alien Waves
by Dave Cohen 12 May '24

12 May '24

My point was that the technology has little to do with the operational success of the service. Spectrum controllers better enabling providers to get out of their own way in selling spectrum did not actually enable the providers* to get out of their own way in selling spectrum. It *should* be easier than it used to be, but it isn't, and the problem is not really technical, but a question of 1) not having full-throated commitment to wanting to sell spectrum and 2) not having the talent to support it, which is really just a function of #1. *Speaking specifically about the very largest CLEC wavelength providers in North America On Sun, May 12, 2024 at 6:34 PM Mark Tinka <mark(a)tinka.africa> wrote: > > > On 5/13/24 00:11, Dave Cohen wrote: > > Mark, > > Many/all of these points are fair. My experience is purely terrestrial and obviously both the capacity and economic calculations are vastly different in those situations, which I should have called out. > > > Actually, terrestrial economics are easier to consider because you have > the one thing the subsea applications don't have in abundance... power. > > Fair point, terrestrial revenues are significantly lower than subsea > revenues on a per-bit basis, but so are the deployment costs. That evens > out, somewhat. > > However, I don’t think that the optical vendor is really the challenge - I would agree that, generally, spectrum is going to be available through larger providers that are using “traditional carrier grade” platforms - but rather at the service provider level. When something invariably breaks at 3 AM and the third shift Tier I NOC tech who hasn’t read the service playbook says “I don’t see any errors on your transponder, sorry, it’s not on our end” because they’re not aware that they actually don’t have access to the transponder and need to start looking elsewhere, that’s the sort of thing that creates systemic challenges for users regardless of whether the light is being shot across a Ciena 6500 or a Dave’s Box-o’-Lasers 1000. > > > I think you are contradicting yourself a bit, unless I misunderstand your > point. > > Legacy vendors who have spectrum controllers have made this concern less > of an issue. But then again, to be fair, adopting spectrum controllers > along with bandwidth expansions via things like gridless line systems and > C+L backbone architectures that make spectrum sales a lot more viable at > scale do come at a hefty $$ premium. So I can understand that offering > spectrum independent of spectrum controllers is going to be more trouble > than it is worth. > > Ultimately, what I'm saying is that technologically, this is now a solved > problem, for the most part. That said, I don't think it will be the > majority of DWDM operators offering spectrum services en masse, for at > least a few more years. So even if you want to procure managed spectrum or > spectrum sharing, you are likely to come up against a limited set of > providers willing to sell it, if at all. > > Mark. > -- - Dave Cohen craetdave(a)gmail.com

2 1

Whitebox Routers Beyond the Datasheet
by Mike Hammett 12 May '24

12 May '24

I'm looking at the suitability of whitebox routers for high through, low port count, fast BGP performance applications. Power efficiency is important as well. What I've kind of come down to (based on little more than spec sheets) are the EdgeCore AGR400 and the UfiSpace S9600-30DX. They can both accommodate at least three directions of 400G for linking to other parts of my network and then have enough 100G or slower ports to connect to transit, peers, and customers as appropriate. Any other suggestions for platforms similar to those would be appreciated. They both appear to carry buffers large enough to accommodate buffering differences in port capacities, which is an issue I've seen with boxes more targeted to cloud\datacenter switching. What isn't in the spec sheets is BGP-related information. They don't mention how many routes they can hold, just that they have additional TCAM to handle more routes and features. That's wonderful and all, but does it take it from 64k routes to 512k routes, or does it take it from 256k routes up to the millions of routes? Also, BGP convergence isn't listed (nor do I rarely ever see it talked about in such sheets). I know that software-based routers can now load a full table in 30 seconds or less. I know that getting the FIB updated takes a little bit longer. I know that withdrawing a route takes a little bit longer. However, often, that performance is CPU-based. An underpowered CPU may take a minute or more to load that table and may take minutes to handle route churn. Can anyone speak to these routers (or routers like these) ability to handle modern route table activity? My deployment locations and philosophies simply won't have me in an environment where I need the density of dozens of 400G\100G ports. That the routers that seem to be more marketed to the use case are designed for. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

7 9

VDSL >2 Pair Bonding Modems
by Mike Hammett 12 May '24

12 May '24

I recently figured out that my Calix E7s can bond more than 2 pair of VDSL lines. However, none of my modem vendors seem to support more than 2 pair. What modem platforms are people using in this scenario? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

1 1