- Test - lists.nanog.org

Re: Q: is RFC3531 still applicable?
by Willy Manga 15 May '24

15 May '24

Hi, On 15/05/2024 16:00, nanog-request(a)nanog.org wrote: > Message: 10 > Date: Tue, 14 May 2024 19:52:43 +0000 > From: Adam Thompson<athompson(a)merlin.mb.ca> > To: nanog<nanog(a)nanog.org> > Subject: Q: is RFC3531 still applicable? > Message-ID: > <YT3PR01MB10768B5A9FEFE157A78096F509BE32(a)YT3PR01MB10768.CANPRD01.PROD.OUTLOOK.COM> > > Content-Type: text/plain; charset="iso-8859-1" > > 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? You can read this article [1] . It's a more 'contemporary' approach. 1. https://www.daryllswer.com/ipv6-architecture-and-subnetting-guide-for-netwo… -- Willy Manga

1 0

Small Internet border router options?
by Tom Samplonius 15 May '24

15 May '24

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

11 10

NANOG 91: Keynote & Conference Kit Announcement 📢 + More
by Nanog News 14 May '24

14 May '24

*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 * <https://nanog.org/events/nanog-91/> *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 <https://nanog.org/stories/articles/rpki-rov-deployment-reaches-major-milest…>EAD MORE <https://nanog.org/stories/articles/rpki-rov-deployment-reaches-major-milest…>* *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 * <https://nanog.org/events/nanog-91/conference-kit/> *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! * <https://nanog.org/events/nanog-91-hackathon/>

1 0

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 13 May '24

13 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