April 2022 - Test - lists.nanog.org

Re: V6 still not supported
by Jared Brown 05 Apr '22

05 Apr '22

Not to necessarily disagree with you, but that is more of a Sony problem than an IPv4 problem. - Jared Jordi Palet wrote: It is not a fixed one-time cost ... because if your users are gamers behind PSP, Sony is blocking IPv4 ranges behind CGN. So, you keep rotating your addresses until all then are blocked, then you need to transfer more IPv4 addresses ... So under this perspective, in many cases it makes more sense to NOT invest in CGN, and use that money to transfer up-front more IPv4 addresses at once, you will get a better price than if you transfer them every few months. Regards, Jordi @jordipalet El 30/3/22, 18:38, "NANOG en nombre de Jared Brown" <nanog-bounces+jordi.palet=consulintel.es at nanog.org en nombre de nanog-isp at mail.com> escribió: Randy Carpenter wrote: > >> >> Owen DeLong via NANOG wrote: > >> >> When your ISP starts charging $X/Month for legacy protocol support > >> > > >> > Out of interest, how would this come about? > >> > >> ISPs are facing ever growing costs to continue providing IPv4 services. > > Could you please be more specific about which costs you are referring to? > > > > It's not like IP transit providers care if they deliver IPv4 or IPv6 bits to > > you. > > Have you priced blocks of IPv4 addresses lately? IPv4 address blocks have a fixed one-time cost, not an ongoing $X/month cost. - Jared

4 4

More product suggestions: small/cheap IS-IS or VXLAN devices?
by Adam Thompson 05 Apr '22

05 Apr '22

At the risk of sounding like a broken record, I’m asking for product suggestions yet again: We’re wondering if anything small & cheap (think CPE-grade) exists that supports either IS-IS or VXLAN? If IS-IS, total route count it would have to carry would be small, probably in the ~500 range. If VXLAN, it needs to interoperate with Arista. If both… yay! When I say CPE-grade, I mean under C$1k (~US$800, ~€700), and can be emplaced at a customer site without any unusual infrastructure (e.g. no -48VDC power, or DIN rail mounting, non-business-office-typical). Thanks in advance, everyone. -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) athompson(a)merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/>

5 5

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
by Abraham Y. Chen 05 Apr '22

05 Apr '22

Hi, Pascal: 1) " ... for the next version. ... ": I am not sure that I can wait for so long, because I am asking for the basics. The reason that I asked for an IP packet header example of your proposal is to visualize what do you mean by the model of "realms and shafts in a multi-level building". The presentation in the draft sounds okay, because the floors are physically isolated from one another. And, even the building is isolated from other buildings. This is pretty much how PBX numbering plan worked. 2) When you extend each floor to use the whole IPv4 address pool, however, you are essential talking about covering the entire surface of the earth. Then, there is no isolated buildings with isolated floors to deploy your model anymore. There is only one spherical layer of physical earth surface for you to use as a realm, which is the current IPv4 deployment. How could you still have multiple full IPv4 address sets deployed, yet not seeing their identical twins, triplets, etc.? Are you proposing multiple spherical layers of "realms", one on top of the other? 2) When I cited the DotConnectAfrica graphic logo as a visual model for the EzIP deployment over current IPv4, I was pretty specific that each RAN was tethered from the current Internet core via one IPv4 address. We were very careful about isolating the netblocks in terms of which one does what. In other words, even though the collection of RANs form a parallel cyberspace to the Internet, you may look at each RAN as an isolated balloon for others. So that each RAN can use up the entire 240/4 netblock. Please clarify your configuration. Thanks, Abe (2022-04-01 17:44) On 2022-04-01 10:55, Abraham Y. Chen wrote: > On 2022-04-01 10:00, Pascal Thubert (pthubert) wrote: >> >> Makes sense, Abe, for the next version. >> >> Note that the intention is NOT any to ANY. A native IPv6 IoT device >> can only talk to another IPv6 device, where that other device may use >> a YATT address or any other IPv6 address. >> >> But it cannot talk to a YADA node. That’s what I mean by baby steps >> for those who want to. >> >> Keep safe; >> >> Pascal >> >> *From:* Abraham Y. Chen <aychen(a)avinta.com> >> *Sent:* vendredi 1 avril 2022 15:49 >> *To:* Vasilenko Eduard <vasilenko.eduard(a)huawei.com>; Pascal Thubert >> (pthubert) <pthubert(a)cisco.com>; Justin Streiner <streinerj(a)gmail.com> >> *Cc:* NANOG <nanog(a)nanog.org> >> *Subject:* Re: Let's Focus on Moving Forward Re: V6 still not >> supported re: 202203261833.AYC >> >> Hi, Pascal: >> >> What I would appreciate is an IP packet header design/definition >> layout, word-by-word, ideally in bit-map style, of an explicit >> presentation of all IP addresses involved from one IoT in one realm >> to that in the second realm. This will provide a clearer picture of >> how the real world implementation may look like. >> >> Thanks, >> >> Abe (2022-04-01 09:48) >> >> On 2022-04-01 08:49, Vasilenko Eduard wrote: >> >> As I understand: “IPv4 Realms” between “Shaft” should be capable >> to have a plain IPv4 header (or else why all of these). >> >> Then Gateway in the Shaft should change headers (from IPv4 to IPv6). >> >> Who should implement this gateway and why? He should be formally >> appointed to such an exercise, right? >> >> Map this 2 level hierarchy to the real world – you may fail with >> this. >> >> Ed/ >> >> *From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com >> <mailto:pthubert@cisco.com>] >> *Sent:* Friday, April 1, 2022 3:41 PM >> *To:* Vasilenko Eduard <vasilenko.eduard(a)huawei.com> >> <mailto:vasilenko.eduard@huawei.com>; Justin Streiner >> <streinerj(a)gmail.com> <mailto:streinerj@gmail.com>; Abraham Y. >> Chen <aychen(a)avinta.com> <mailto:aychen@avinta.com> >> *Subject:* RE: Let's Focus on Moving Forward Re: V6 still not >> supported re: 202203261833.AYC >> >> Hello Eduard: >> >> Did you just demonstrate that POPs cannot exist? Or that there >> cannot be a Default Free Zone? >> >> I agree with your real world issue that some things will have to >> be planned between stake holders, and that it will not be easy. >> >> But you know what the French say about “impossible”. >> >> Or to paraphrase Sir Arthur, now that we have eliminated all the >> impossible transition scenarios, whatever remains… >> >> There will be YADA prefixes just like there are root DNS. To be >> managed by different players as you point out. And all routable >> within the same shaft. >> >> Keep safe; >> >> Pascal >> >> *From:* Vasilenko Eduard <vasilenko.eduard(a)huawei.com> >> *Sent:* vendredi 1 avril 2022 14:32 >> *To:* Pascal Thubert (pthubert) <pthubert(a)cisco.com>; Justin >> Streiner <streinerj(a)gmail.com>; Abraham Y. Chen <aychen(a)avinta.com> >> *Subject:* RE: Let's Focus on Moving Forward Re: V6 still not >> supported re: 202203261833.AYC >> >> Hi Pascal, >> >> In general, your idea to create a hierarchy is good. >> >> In practice, it would fail because you have created a virtual >> hierarchy that does not map to any administrative border. Who >> should implement gateways for the “Shaft”? Why? >> >> If you would appoint Carrier as the Shaft responsible then it is >> not enough bits for Shaft. >> >> If you would appoint Governments as the Shaft responsible then >> would be a so big scandal that you would regret the proposal. >> >> Hence, I do not see proper mapping for the hierarchy to make YADA >> successful. >> >> Eduard >> >> *From:* NANOG >> [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org >> <mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org>] *On >> Behalf Of *Pascal Thubert (pthubert) via NANOG >> *Sent:* Friday, April 1, 2022 2:26 PM >> *To:* Justin Streiner <streinerj(a)gmail.com>; Abraham Y. Chen >> <aychen(a)avinta.com> >> *Cc:* NANOG <nanog(a)nanog.org> >> *Subject:* RE: Let's Focus on Moving Forward Re: V6 still not >> supported re: 202203261833.AYC >> >> For the sake of it, Justin, I just published >> https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/. >> >> The first section of the draft (YADA) extends IPv4 range in an >> IPv4-only world. For some people that might be enough and I’m >> totally fine with that. >> >> Keep safe; >> >> Pascal >> >> *From:* NANOG <nanog-bounces+pthubert=cisco.com(a)nanog.org> *On >> Behalf Of *Justin Streiner >> *Sent:* dimanche 27 mars 2022 18:12 >> *To:* Abraham Y. Chen <aychen(a)avinta.com> >> *Cc:* NANOG <nanog(a)nanog.org> >> *Subject:* Re: Let's Focus on Moving Forward Re: V6 still not >> supported re: 202203261833.AYC >> >> Abe: >> >> To your first point about denying that anyone is being stopped >> from working on IPv4, I'm referring to users being able to >> communicate via IPv4. I have seen no evidence of that. >> >> I'm not familiar with the process of submitting ideas to IETF, so >> I'll leave that for others who are more knowledgeable on that to >> speak up if they're so inclined. >> >> Thank you >> >> jms >> >> On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen >> <aychen(a)avinta.com> wrote: >> >> 1) "... no one is stopping anyone from working on IPv4 >> ... ": After all these discussions, are you still >> denying this basic issue? For example, there has not been any >> straightforward way to introduce IPv4 enhancement ideas to >> IETF since at least 2015. If you know the way, please make it >> public. I am sure that many are eager to learn about it. Thanks. >> >> Image removed by sender. >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >> >> >> >> Virus-free. www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >> >> > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

6 22

Re: IPv6 Only
by Jacques Latour 04 Apr '22

04 Apr '22

Exactly what I was asking, when and how will we collectively turn off the lights on IPv4? > -----Original Message----- > From: NANOG <nanog-bounces+jacques.latour=cira.ca(a)nanog.org> On > Behalf Of Mark Andrews > Sent: March 30, 2022 7:29 PM > To: NANOG <nanog(a)nanog.org> > Subject: [EXT] Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 > still not supported re: 202203261833.AYC > > Sites looking at the traffic they get and saying, you know what all our > customers connect to us over IPv6 with some of them also connecting over > IPv4. I think we can stop supporting IPv4 now. > > ISP’s saying this IPv4aaS isn’t getting much traffic anymore lets out source it > for the few customers that are still using it. Lots of ISPs are well down the > path leading to this point by turning off IPv4 on the access networks. > > Home / enterprise networks. All my gear is IPv6 capable and supports > IPv4aaS for the few legacy > IPv4 sites I need to connect to. This is happening today. > > In the end almost all the IPv4 traffic with be with the third party IPv4aaS > providers and collectively they will decide to turn off the lights. > > > On 30 Mar 2022, at 07:53, Jacques Latour <Jacques.Latour(a)cira.ca> wrote: > > > > So, in 25, 50 or 100 years from now, are we still going to be dual stack > IPv4/IPv6? > > When are we going to give up on IPv4? > > People can run IPv4 all they want inside their networks for 1000s of years. > > What will it take to be IPv6 only? > > > > 😊 > > > > From: NANOG <nanog-bounces+jacques.latour=cira.ca(a)nanog.org> On > Behalf > > Of Owen DeLong via NANOG > > Sent: March 29, 2022 3:52 PM > > To: Abraham Y. Chen <aychen(a)avinta.com> > > Cc: NANOG <nanog(a)nanog.org> > > Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not > > supported re: 202203261833.AYC > > > > Submit an Internet draft, same as any other IP related enhancement gets > introduced. > > > > What you’re really complaining about is that it’s been virtually impossible > to gain consensus to move anything IPv4 related forward in the IETF since at > least 2015. > > > > Well… It’s a consensus process. If your idea isn’t getting consensus, then > perhaps it’s simply that the group you are seeking consensus from doesn’t > like your idea. > > > > Your inability to convince the members of the various working groups that > your idea has merit isn’t necessarily a defect in the IETF process… It might > simply be a lack of merit in your ideas. > > > > Owen > > > > > > > > On Mar 26, 2022, at 15:43 , Abraham Y. Chen <aychen(a)avinta.com> > wrote: > > > > Hi, Justin: > > > > 1) "... no one is stopping anyone from working on IPv4 ... ": After all > these discussions, are you still denying this basic issue? For example, there > has not been any straightforward way to introduce IPv4 enhancement ideas > to IETF since at least 2015. If you know the way, please make it public. I am > sure that many are eager to learn about it. Thanks. > > > > Regards, > > > > > > Abe (2022-03-26 18:42) > > > > > > > > > > On 2022-03-26 11:20, Justin Streiner wrote: > > While the Internet is intended to allow the free exchange of information, > the means of getting that information from place to place is and has to be > defined by protocols that are implemented in a consistent manner (see: BGP, > among many other examples). It's important to separate the ideas from the > plumbing. > > > > That said, no one is stopping anyone from working on IPv4, so what > personal freedoms are being impacted by working toward deploying IPv6, > with an eye toward sunsetting IPv4 in the future? > > > > Keep in mind that IPv4 started out as an experiment that found its way > into wider use. It's a classic case of a test deployment that suddenly > mutated into a production service. Why should we continue to expend > effort to perpetuate the sins of the past, rather work toward getting v6 into > wider use? > > > > Is IPv6 a perfect protocol? Absolutely not, but it addresses the key pain > point of IPv4 - address space exhaustion. > > > > Thank you > > jms > > > > On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen <aychen(a)avinta.com> > wrote: > > > > 3) Re: Ur. Pts. 5) & 6): I believe that there is a philosophic / logic > baseline that we need to sort out, first. That is, we must keep in mind that > the Internet community strongly promotes "personal freedom". Assuming > that by stopping others from working on IPv4 will shift their energy to IPv6 is > totally contradicting such a principle. A project attracts contributors by its > own merits, not by relying on artificial barriers to the competitions. Based on > my best understanding, IPv6 failed right after the decision of "not > emphasizing the backward compatibility with IPv4". It broke one of the > golden rules in the system engineering discipline. After nearly three decades, > still evading such fact, but defusing IPv6 issues by various tactics is the real > impedance to progress, not only to IPv4 but also to IPv6. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

5 5

ICANN Survey on DNS Suffix Usage and New gTLD Delegation
by Casey Deccio 04 Apr '22

04 Apr '22

Dear colleagues, tl;dr: Please take our survey on DNS suffix usage here: https://forms.gle/ntvsn6eqzYH9YcTN6 The Internet Corporation for Assigned Names and Numbers (ICANN) is researching the technical impact of delegating new generic top-level domains (gTLDs). This research is part of the Name Collision Analysis Project (NCAP). More information about NCAP can be found at https://community.icann.org/display/NCAP. Since 2013 hundreds of new gTLDs have been introduced into the public DNS (https://newgtlds.icann.org/en/program-status/delegated-strings) In some cases those gTLDs might have been used as part of a DNS suffix by one or more organizations around the Internet, prior to their introduction. (By “DNS suffix” we mean a domain name used in the DNS resolver search list of a device, e.g., the “domain” and “search” entries in /etc/resolv.conf on UNIX/Linux, “Search Domains” in the macOS DNS configuration pane, and “DNS suffix search list” on Windows.) As a result, the behavior of systems or devices in these organizations might have changed because of a “name collision”. A name collision occurs when a name used in one context (in the organization's network) is interpreted in another context (in this case, in the public DNS after the corresponding gTLD went live). We are researching the causes and impact of name collisions. We are seeking qualitative data based on experiences of those organizations potentially affected. We expect that this additional data will greatly enhance our understanding of name collisions that resulted from adding new gTLDs. If you suspect that your organization has been impacted by the delegation of any new gTLDs, we invite you to please fill out the following brief survey regarding your experience. We would be grateful for your input! https://forms.gle/ntvsn6eqzYH9YcTN6 Your responses will remain anonymous, and any personal information will be discarded after the research has concluded. If you have any questions, please reply to this email. Thank you for your help! Sincerely, Casey Deccio ICANN Name Collisions Analysis Project

1 1

IP Reputation Services
by Mike Hammett 04 Apr '22

04 Apr '22

I'm checking in to see what people think of IP reputation services. I run an ISP (well, a couple of them) and we occasionally run into issues where customer IPs stop working with various services because of reputation issues. We run a fairly light-touch as to our customer's traffic, but when it creates support issues, one starts to look for better ways of skinning the cat. I've found a few of them out there, but they seem to be priced as if I'm a hosting company or an ESP, not an end-user-focused ISP. TIA ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

4 3

Re: IPv6 Only
by Jacques Latour 04 Apr '22

04 Apr '22

Is there a status page for this initiative? * M-21-07 (whitehouse.gov)<https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf> * SUBJECT: Completing the Transition to Internet Protocol Version 6 (IPv6) “Develop an IPv6 implementation plan by the end of FY 2021, and update the Information Resources Management (IRM) Strategic Plan as appropriate, to update all networked Federal information systems (and the IP-enabled assets associated with these systems) to fully enable native IPv6 operation. The plan shall describe the agency transition process and include the following milestones and actions: * At least 20% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2023; * At least 50% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2024; * At least 80% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2025;” “Cisco IT is Customer Zero for IPv6-only inside our networks” - Transitioning to IPv6 for Simplicity, Efficiency, and Modernization - Cisco Blogs<https://blogs.cisco.com/networking/transitioning-to-ipv6-for-simplicity-eff…> From: Matthew Petach <mpetach(a)netflight.com> Sent: March 31, 2022 2:54 PM To: Jacques Latour <Jacques.Latour(a)cira.ca> Cc: Mark Andrews <marka(a)isc.org>; NANOG <nanog(a)nanog.org> Subject: [EXT] Re: IPv6 Only On Thu, Mar 31, 2022 at 5:36 AM Jacques Latour <Jacques.Latour(a)cira.ca<mailto:Jacques.Latour@cira.ca>> wrote: Exactly what I was asking, when and how will we collectively turn off the lights on IPv4? Working on the World IPv6 Launch {day|week|forever} efforts, I noticed an interesting pattern of companies that put up IPv6 resources, with all the associated quad-As, and patted themselves on the back for making themselves available via IPv6; but I couldn't request those quad-A records via anything but IPv4 transport to their DNS servers. I've seen similar behaviour with hardware vendors. They have great IPv6 support, their boxes forward and accept IPv6 packets just fine; but, the deeper you dig, the more you find oddities, like syslog host destinations that only accept v4 IP addresses, or a requirement for an IPv4 router ID to be configured. I don't think we fully grasp just how wide the chasm is between "we support IPv6" and "we can fully turn off IPv4". There's a whole lot of "we support IPv6" in the world right now that comes with lingering IPv4 tendrils that are often under the surface, or in the darker corners of the config, that just keep working because most of the IPv6 world is still either dual-stacked, or has a translation layer that allows the lurking v4 bits to not cause issues. I don't think we'll be nearly as close to being ready to turn off the lights on IPv4 as we think we are, not just because of old customer CPE and legacy boxes, but because of embedded assumptions deep in software and firmware stacks. For example, let's take a relatively modern enterprise wireless platform: https://www.arubanetworks.com/techdocs/AOS-CX/10.07/HTML/5200-7852/Content/… " * ZTP operations are supported over IPv4 connections only. IPv6 connections are not supported for ZTP operations." Sure, the devices pass IPv6 traffic just fine; but you'd better keep your IPv4 network around so the devices can configure themselves after powering on. There's a *lot* of code out there that's been carried forward for years, with dark corners that haven't been touched for a while. I think we're going to be stumbling over "can't do that over IPv6 yet" areas for years and years to come, not because of any willful myopia around the migration from IPv4 to IPv6, but simply because it's code that doesn't get used very often, and in dual-stack networks, it just keeps working the few times it gets exercised. The only time it would run into a problem is in a pure IPv6-only network; and how many of those really exist in the world to flag it as an issue? And yet, in order to "turn off the lights on IPv4", we're going to have to root through all those dark corners of code that haven't been touched in years to update them to work in an IPv6-only world; and that's *really* pushing the rock uphill, because that's work that isn't going to see any cost recovery for it at all. No customer is going to say "I won't buy your product until you've rooted out every bit of IPv4-only code in your software". So, there's really no financial incentive for companies to work towards getting their software ready for an IPv6-only world. So--the tl;dr version of my answer to you? "when" is likely to be "not in any of our lifetimes"--because the "how" requires completely non-monetizable effort on the part of companies that have legacy codebases they're carrying forward. Thanks! Matt

1 0

is it still nfsen?
by Randy Bush 04 Apr '22

04 Apr '22

i am setting up new app/port monitoring. i like nfsen because i can zooom in and see who is sending all that port 43 tls between 11:42 and 12:19. is there some other tool at which i should look? randy

4 3

Cogent ...
by Laura Smith 02 Apr '22

02 Apr '22

Hmmm.... Spring has sprung and the waft of drivel from a new season Cogent salesdroid filled my telephone earpiece today. I've never liked the Cogent way of business and my understanding of their IP transit is that it falls into the "cheap for a reason" category. However, perhaps someone would care to elaborate (either on or off-list) what the deal is with the requirement to sign NDAs with Cogent before they'll discuss things like why they still charge for BGP, or indeed any other technical or pricing matters. Seems weird ?!? Laura

9 9

RFC 9225 - Software Defects Considered Harmful
by Job Snijders 01 Apr '22

01 Apr '22

Hi all, It's super official now: no more software bugs in networking gear. Sorry it took so long to document what the best current practise is! Kind regards, Job / Chris / Remco ----- Forwarded message from rfc-editor(a)rfc-editor.org ----- Date: Fri, 1 Apr 2022 10:17:37 -0700 (PDT) From: rfc-editor(a)rfc-editor.org To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org Cc: drafts-update-ref(a)iana.org, rfc-editor(a)rfc-editor.org Subject: RFC 9225 on Software Defects Considered Harmful A new Request for Comments is now available in online RFC libraries. RFC 9225 Title: Software Defects Considered Harmful Author: J. Snijders, C. Morrow, R. van Mook Status: Informational Stream: Independent Date: 1 April 2022 Mailbox: job(a)fastly.com, morrowc(a)ops-netman.net, remco(a)asteroidhq.com Pages: 6 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-dont-write-bugs-00.txt URL: https://www.rfc-editor.org/info/rfc9225 DOI: 10.17487/RFC9225 This document discourages the practice of introducing software defects in general and in network protocol implementations specifically. Software defects are one of the largest cost drivers for the networking industry. This document is intended to clarify the best current practice in this regard. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor(a)rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce(a)ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message -----

4 3