- NANOG - lists.nanog.org

Looking for an Amazon Cloudfront contact
by Eric Kuhnke 06 Apr '22

06 Apr '22

It looks like I may have a range of recently put into use residential symmetric gigabit last mile IP space that's being filtered/blocked at the application level. Please contact me off-list.

1 0

Now open - 2022 ARIN Community Grants for Internet infrastructure development/research projects
by John Curran 06 Apr '22

06 Apr '22

NANOGers - The ARIN Community Grant program has opened its 2022 "call for applications”. If you are aware of a non-commercial development or research project that could enhance Internet operations and might benefit from additional funding, please bring this opportunity to their attention. More information attached below. Thanks! /John John Curran President and CEO American Registry for Internet Numbers === From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [arin-announce] Apply Now for an ARIN Community Grant Date: 6 April 2022 at 11:11:35 AM EDT To: "arin-announce(a)arin.net<mailto:arin-announce@arin.net>" <arin-announce(a)arin.net<mailto:arin-announce@arin.net>> Do you have a project that needs funding, is non-commercial in nature, and benefits the Internet community with the ARIN service region? Apply now for a 2022 ARIN Community Grant. The ARIN Community Grant Program provides financial grants in support of operational and research projects that improve the overall Internet industry and Internet user environment that advance ARIN’s mission and broadly benefit the Internet community within the ARIN region. Projects must fit into one or more of these four broad categories: • Internet technical improvements that promote and facilitate the expansion, development, and growth of the infrastructure of the Internet consistent with the public interest • Registry processes and technology improvements that help maintain a globally consistent and highly usable Internet Number Registry system • Informational outreach that advances the Internet on topics such as, but not limited to: IPv6 deployment, Internet research, and Internet governance • Research related to ARIN’s mission and operations For 2022, the ARIN Board of Trustees has approved a total expenditure of up to $60,000 (USD) for grants of varying amounts, starting at $1,000 to $20,000 (USD) and based on project need. We invite you to learn more about ARIN’s Community Grant Program and to find the link to the application form at: https://www.arin.net/grants The call for applications is open now through 1 June 2022. We encourage all applicants to clearly demonstrate how projects meet eligibility guidelines and selection criteria through the application form to improve chances of selection. ARIN looks forward to funding important projects through the ARIN Community Grant Program in 2022. Regards, American Registry for Internet Numbers (ARIN) ===

1 0

Re: Enhance CG-NAT Re: V6 still not supported
by Abraham Y. Chen 06 Apr '22

06 Apr '22

Hi, Ant: 1) As I Cc:'ed you, I attempted to contact the author of the IPv4+ draft a few days ago to offer my reading of his work. I have not heard any response. In short, I believe that IPv4+ is paraphrasing the scheme of the unsuccessful RFC1385 that EzIP Draft cited as Informative Reference [12]. -- meaning that EzIP has avoided the trap of such approach. 2) I went back to earlier versions of the IPv4+ drafts and discovered a surprising trend. That is, through all eight revisions, there has been hardly any actual write-up text changes! It appears that the author is just keeping the six-months-timer ticking. 3) Since you indicated that IPv4+ was reported to NANOG, maybe you could retrieve that thread and check with the author about what is the status? 4) "Have you approached any vendors about the feasibility of IP Options being used for switching at line rate in silicon? ": No. For the first phase of implementing EzIP, the configuration is called RAN (Regional Area Network). It is essentially a numbering plan enhancement to CG-NAT. There is no change to the basic IPv4 Header. The only engineering effort is "disabling the program code that has been disabling the use of the 240/4 netblock", followed by retiring the NAT function. So that CG-NAT can operate as simple routers, by having the look-up state-tables capability as backup. 5) In the long run, yes, processing of the Option Word needs be considered and ideally be implemented in silicon to achieve the line rate switching. Many claim, however, such end-to-end connectivity is not needed according to the current trend, which is primarily Server / Client model by CDN business. So, EzIP is actually a forward looking two stage scheme. We can focus on the first phase for now to relieve the underlying issues. There will be plenty of lead time to upgrade the silicon when the demand for end-to-end connectivity begins to build up. 6) " ... but your replies are practically illegible because of formatting. ... ": I am still learning the proper eMail etiquette on NANOG. Could you please echo back some of my writings as you received? So that I can see what they got transformed to. Thanks, Abe (2022-04-06 11:25) On 2022-04-03 16:14, Anthony Newman wrote: > You should check outhttps://datatracker.ietf.org/doc/html/draft-tang-ipv4plus-08 which is still dragging on > after receiving similar treatment here to EzIP (although less patented by its author) and equally unlikely > to be possible to implement in the real world in a timely fashion. > > Have you approached any vendors about the feasibility of IP Options being used for switching at line rate in silicon? > Software IP stacks are the absolute least of your problem when proposing alterations to routing behaviour based on > packet contents. Apologies if this has been covered, but your replies are practically illegible because of formatting. > > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

FuboTV Geolocation
by Nicholas Warren 06 Apr '22

06 Apr '22

Is anyone on the list from FuboTV that can assist or point me in the right direction for a geolocation issue? Thank you, Nich Warren AS395658

1 0

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)
by behrnsjeff＠yahoo.com 06 Apr '22

06 Apr '22

Lumen / Level3 filtergen is trimming these routes now. Don't bother trying to query filtergen.level3.net currently; server is full. Small AS cone does not equal small societal footprint & impact. While I appreciate the intention upthread of proxy registering at ATLDB, it really just distracted from finding the root issue.

1 0

Gmail (thus Nanog) rejecting ipv6 email
by Dan Mahoney (Gushi) 06 Apr '22

06 Apr '22

I've been seeing a long thread about why ipv6 adoption isn't there yet. This is half a "paging someone with clue" post and half a "...really, guys?" Picard-facepalm post. I just (earlier this week) had to disable ipv6 outbound on one of $dayjob's MX servers, because Gmail, who hosts nanog.org, was rejecting our mail due to "our domain's very low reputation". (In this parlance, "Very Low" is an actual indicative metric.) Dayjob is the people who make BIND and run a root DNS server. Totally disreputable, I'm sure. I don't see anything indicating this in our postmaster tools. I am certain this action is happening completely transparently and invisibly to NANOG, unless others have complained. Whatever UI google gives them to manage their domain will not show this. There are no logs they can grep. I'm told that "gmail's filters for ipv6 are way tighter than ipv4" but that's from a non-canonical source. If this is the case, it does very little to further ipv6 adoption, that's for sure. I've posted over on mailop, and was given a contact (Brandon), but haven't heard back. Gmail's a black box. I've reached out to a few other people, but if anyone here can loan a bat-phone, please let me know. I'm loathe to randomly re-enable ipv6 without contact from someone saying why this happened, and how it's been fixed. -Dan (Who actually operates my own network) -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC FB: fb.com/DanielMahoneyIV LI: linkedin.com/in/gushi Site: http://www.gushi.org ---------------------------

13 36

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

05 Apr '22

My apologies for expressing myself poorly. What I meant to say is that this is primarily a problem caused by Sony and the Sonys of the world. Less so a problem inherent to IPv4. A root cause fix would address Sony's hostile behavior. - Jared Jordi Palet wrote: No, isn't only a Sony problem, becomes a problem for every ISP that has customers using Sony PSN and have CGN (NAT444), their IP blocks are black-listed when they are detected as used CGN. This blocking is "forever" (I'm not aware of anyone that has been able to convince PSN to unblock them). Then the ISP will rotate the addresses that are in the CGN (which means some work renumbering other parts of the network). You do this with all your IPv4 blocks, and at some point, you don't have any "not black-listed" block. Then you need to transfer more addresses. So realistically, in many cases, for residential ISPs it makes a lot of sense to analyze if you have a relevant number of customers using PSN and make your numbers about if it makes sense or not to buy CGN vs transfer IPv4 addresses vs the real long term solution, which is IPv6 even if you need to invest in replacing the customer CPEs. Regards, Jordi @jordipalet El 30/3/22, 21:02, "NANOG en nombre de Jared Brown" <nanog-bounces+jordi.palet=consulintel.es at nanog.org en nombre de nanog-isp at mail.com> escribió: 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

10 13

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