Re: Contact data for outlook.com
You may also try the mailops list. On Tue, Mar 9, 2021, 12:55 PM Matthew V wrote: > If you haven't done this yet - start with the outlook postmaster > troubleshooting documentation and open a support ticket with them. > > https://sendersupport.olc.protection.outlook.com/pm/troubleshooting.aspx > > Matt > > On 2021-03-09 7:07 a.m., s...@circlenet.us wrote: > > You are not alone sir, for reasons as yet unknown outlook.com has > > recently started blocking my range as well. > > If I make progress in contacting someone with clue I will pass that > > information along privately. > > > > Sam Moats > > > > On 2021-03-08 16:18, Dan Walters via NANOG wrote: > >> Good afternoon, > >> > >> So I'm looking for a contact at Microsoft in particular someone on the > >> outlook spam protection/prevention team to assist us with a IP block. > >> I have allready signed up for SNDS and there is no data given . > >> Please feel free to contact me off the list. > >> > >> Best Regards, > >> > >> Daniel Walters >
Re: Network / Infrastructure security testing services
I'm looking for someone if anyone from this thread does it. On Tue, Mar 9, 2021 at 3:05 PM jim deleskie wrote: > > Your asking if anyone does it or your offering your services? > > -jim > > On Tue., Mar. 9, 2021, 3:56 p.m. Nathanael Cariaga, > wrote: >> >> Apologies for this shameless plug, but wanted to ask if any folks on this >> list who does network/infrastructure security testing? Please to reach back >> to me off the list. >> >> Thank you for your time. >>
Re: Network / Infrastructure security testing services
Your asking if anyone does it or your offering your services? -jim On Tue., Mar. 9, 2021, 3:56 p.m. Nathanael Cariaga, wrote: > Apologies for this shameless plug, but wanted to ask if any folks on this > list who does network/infrastructure security testing? Please to reach back > to me off the list. > > Thank you for your time. > >
Re: an IP hijacking attempt
RPKI can be very useful to mitigate an attempt. I used to process IP LOAs all the time. I never saw a RR attached but usually we did a check against the RIR just to make sure (because we made access-list per interface as well) On 3/9/2021 1:42 PM, Mel Beckman wrote: Not everyone uses RRs, and there is also the possibility that their upstream would register it. Having an RR doesn’t seem definitive either way. I can see reasons to wait on the RR until ready to receive traffic. -mel via cell On Mar 9, 2021, at 11:14 AM, Brian Turnbow wrote: If they had a route record that was close, I Would give them the benefit of doubt. They do not however as the only records start with 217. And our IPs are 45. So It Is very strange. Would you send a LOA without a route record? Brian Turnbow *Da:* Mel Beckman *Inviato:* martedì 9 marzo 2021 19:17 *A:* Brian Turnbow *Cc:* North American Network Operators' Group *Oggetto:* Re: an IP hijacking attempt It could just be a typo on the LOA. It seems unlikely any ISP would approve a forged LOA that could readily be debunked by contacting the IP space owner. The whole point of LOA’s is to facilitate this verification. -mel via cell > On Mar 9, 2021, at 10:01 AM, Brian Turnbow via NANOG wrote: > > Hello everyone, > > We received a strange request that I wanted to share. > An email was sent to us asking to confirm a LOA from a diligent ISP. > The Loa was a request to open bgp for an AS , that is not ours, to announce a /23 prefix that is ours. > So basically this entity sent to their upstream a request to announce a prefix from one our allocated ranges. > We have the allocation correctly registered and ROAs in place , but it is worrisome that someone would attempt this. > Obviously we have informed the ISP that the LOA is not valid and are trying to contact the originating party. > Aside from RIRs for the offending AS and our IPs, Is there anywhere to report this type of activity? > We have dealt with hijacking technically speaking in the past but this is the first time, to my knowledge, of someone forging a LOA with our IPs. > > Thanks in advance for any advice > > Brian > > P.S. a big thanks to Chris for checking the boxes before activating the filter if you are on the list! > > > >
Re: Network / Infrastructure security testing services
Huh -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Mar 9, 2021, at 13:57, Nathanael Cariaga wrote: > > > Apologies for this shameless plug, but wanted to ask if any folks on this > list who does network/infrastructure security testing? Please to reach back > to me off the list. > > Thank you for your time. >
Re: Ip space Dilemma
- On Mar 9, 2021, at 6:13 AM, Justin Wilson (Lists) li...@mtin.net wrote: Hi, > I am at the point I need to give the space back because it is unusable > to the > ISP customers. Does anyone have any creative ideas on how to fix this? Since they are a government entity, a process server might do the trick... Thanks, Sabri
Re: an IP hijacking attempt
Not everyone uses RRs, and there is also the possibility that their upstream would register it. Having an RR doesn’t seem definitive either way. I can see reasons to wait on the RR until ready to receive traffic. -mel via cell On Mar 9, 2021, at 11:14 AM, Brian Turnbow wrote: If they had a route record that was close, I Would give them the benefit of doubt. They do not however as the only records start with 217. And our IPs are 45. So It Is very strange. Would you send a LOA without a route record? Brian Turnbow Da: Mel Beckman Inviato: martedì 9 marzo 2021 19:17 A: Brian Turnbow Cc: North American Network Operators' Group Oggetto: Re: an IP hijacking attempt It could just be a typo on the LOA. It seems unlikely any ISP would approve a forged LOA that could readily be debunked by contacting the IP space owner. The whole point of LOA’s is to facilitate this verification. -mel via cell > On Mar 9, 2021, at 10:01 AM, Brian Turnbow via NANOG wrote: > > Hello everyone, > > We received a strange request that I wanted to share. > An email was sent to us asking to confirm a LOA from a diligent ISP. > The Loa was a request to open bgp for an AS , that is not ours, to announce a > /23 prefix that is ours. > So basically this entity sent to their upstream a request to announce a > prefix from one our allocated ranges. > We have the allocation correctly registered and ROAs in place , but it is > worrisome that someone would attempt this. > Obviously we have informed the ISP that the LOA is not valid and are trying > to contact the originating party. > Aside from RIRs for the offending AS and our IPs, Is there anywhere to > report this type of activity? > We have dealt with hijacking technically speaking in the past but this is the > first time, to my knowledge, of someone forging a LOA with our IPs. > > Thanks in advance for any advice > > Brian > > P.S. a big thanks to Chris for checking the boxes before activating the > filter if you are on the list! > > > >
Re: Ip space Dilemma
I did similar over a bad DNS firewall settings that where dropping queries causing the initial connection to take minutes. I’d already contacted the administrator and been told it would be looked into multiple times. After a several of months without a resolution, I escalated with a letter to the Minster, Shadow Minister and the CEO of the company the servers where outsourced too pointing out the problem. Fixed within a couple of days. -- Mark Andrews > On 10 Mar 2021, at 06:17, Kevin Wallace wrote: > > On Tue, Mar 9, 2021, at 6:13 AM, Justin Wilson (Lists) wrote: >> I [..] was finally told we were not a priority. > >> Does anyone have any creative ideas on how to fix this? > > You might write them a letter like the following: > >Dear $AGENCY, > >Pursuant to the Indiana Access to Public Records Act (IC 5-14-3), >I hereby request the following records: > * all internal communication regarding $PROBLEM_PREFIX > * all configuration files on $IMPLICATED_FIREWALL > >Thank you in advance for your anticipated cooperation in this matter. >I look forward to receiving your response to this request within 7 >business days, as the statute requires. > > See what that yields you, and go from there. YMMV, IANAL, etc. > > Kevin
Network / Infrastructure security testing services
Apologies for this shameless plug, but wanted to ask if any folks on this list who does network/infrastructure security testing? Please to reach back to me off the list. Thank you for your time.
Re: Ip space Dilemma
Here in Brazil we had a similar issue... The cause here was the lack of maintenance contract between the Firewall Suppliers and the Government Department. GeoIPBased Firewall Rule was deployed on the Public Health System in Brazil, saying: "To those servers, if IP is not from Brazil, drop!" After the service contract with the firewall vendor expired and was not renewed, automatic updates from Gei-IP-Base were blocked. The range 45.x.x.x was not allocated initially to BR, but in decurrency of phase 3 of IPv4 exhaustion on LACNIC, several blocks inside 45/8 were alocated to Brazilian ASNs. And that firewall did not receive the updates that would tell "hey firewall... those IPs are Brazilian now". And because of that, a significant part of the Bazilian Internet community had problems to access one of Public Health application on the Internet. That is described here at the following link (pt_BR) https://eng.registro.br/pipermail/gter/2019-September/077235.html After a MASSIVE campaign started on that mail list, and several colleagues sending repetitive e-mails to the responsible organizations, marking guys on facebook and linkedin... One day a magic was done and that blocks stopped. Em ter., 9 de mar. de 2021 às 11:16, Justin Wilson (Lists) escreveu: > Folks, > We have an IP block I have asked about help on a few times on > here. This is a block we received from ARIN in June of 2020. We have > several state networks here in Indiana dropping this traffic at their > firewalls. I have been working with them since we discovered this issue in > September. I am not getting anywhere with them and was finally told we > were not a priority. > > I am at the point I need to give the space back because it is > unusable to the ISP customers. Does anyone have any creative ideas on how > to fix this? > > > > Justin Wilson > j...@mtin.net > > — > https://j2sw.com - All things jsw (AS209109) > https://blog.j2sw.com - Podcast and Blog > > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Ip space Dilemma
On Tue, Mar 9, 2021, at 6:13 AM, Justin Wilson (Lists) wrote: > I [..] was finally told we were not a priority. > Does anyone have any creative ideas on how to fix this? You might write them a letter like the following: Dear $AGENCY, Pursuant to the Indiana Access to Public Records Act (IC 5-14-3), I hereby request the following records: * all internal communication regarding $PROBLEM_PREFIX * all configuration files on $IMPLICATED_FIREWALL Thank you in advance for your anticipated cooperation in this matter. I look forward to receiving your response to this request within 7 business days, as the statute requires. See what that yields you, and go from there. YMMV, IANAL, etc. Kevin
Re: an IP hijacking attempt
If they had a route record that was close, I Would give them the benefit of doubt. They do not however as the only records start with 217. And our IPs are 45. So It Is very strange. Would you send a LOA without a route record? Brian Turnbow Da: Mel Beckman Inviato: martedì 9 marzo 2021 19:17 A: Brian Turnbow Cc: North American Network Operators' Group Oggetto: Re: an IP hijacking attempt It could just be a typo on the LOA. It seems unlikely any ISP would approve a forged LOA that could readily be debunked by contacting the IP space owner. The whole point of LOA’s is to facilitate this verification. -mel via cell > On Mar 9, 2021, at 10:01 AM, Brian Turnbow via NANOG wrote: > > Hello everyone, > > We received a strange request that I wanted to share. > An email was sent to us asking to confirm a LOA from a diligent ISP. > The Loa was a request to open bgp for an AS , that is not ours, to announce a > /23 prefix that is ours. > So basically this entity sent to their upstream a request to announce a > prefix from one our allocated ranges. > We have the allocation correctly registered and ROAs in place , but it is > worrisome that someone would attempt this. > Obviously we have informed the ISP that the LOA is not valid and are trying > to contact the originating party. > Aside from RIRs for the offending AS and our IPs, Is there anywhere to > report this type of activity? > We have dealt with hijacking technically speaking in the past but this is the > first time, to my knowledge, of someone forging a LOA with our IPs. > > Thanks in advance for any advice > > Brian > > P.S. a big thanks to Chris for checking the boxes before activating the > filter if you are on the list! > > > >
Re: an IP hijacking attempt
It could just be a typo on the LOA. It seems unlikely any ISP would approve a forged LOA that could readily be debunked by contacting the IP space owner. The whole point of LOA’s is to facilitate this verification. -mel via cell > On Mar 9, 2021, at 10:01 AM, Brian Turnbow via NANOG wrote: > > Hello everyone, > > We received a strange request that I wanted to share. > An email was sent to us asking to confirm a LOA from a diligent ISP. > The Loa was a request to open bgp for an AS , that is not ours, to announce a > /23 prefix that is ours. > So basically this entity sent to their upstream a request to announce a > prefix from one our allocated ranges. > We have the allocation correctly registered and ROAs in place , but it is > worrisome that someone would attempt this. > Obviously we have informed the ISP that the LOA is not valid and are trying > to contact the originating party. > Aside from RIRs for the offending AS and our IPs, Is there anywhere to > report this type of activity? > We have dealt with hijacking technically speaking in the past but this is the > first time, to my knowledge, of someone forging a LOA with our IPs. > > Thanks in advance for any advice > > Brian > > P.S. a big thanks to Chris for checking the boxes before activating the > filter if you are on the list! > > > >
an IP hijacking attempt
Hello everyone, We received a strange request that I wanted to share. An email was sent to us asking to confirm a LOA from a diligent ISP. The Loa was a request to open bgp for an AS , that is not ours, to announce a /23 prefix that is ours. So basically this entity sent to their upstream a request to announce a prefix from one our allocated ranges. We have the allocation correctly registered and ROAs in place , but it is worrisome that someone would attempt this. Obviously we have informed the ISP that the LOA is not valid and are trying to contact the originating party. Aside from RIRs for the offending AS and our IPs, Is there anywhere to report this type of activity? We have dealt with hijacking technically speaking in the past but this is the first time, to my knowledge, of someone forging a LOA with our IPs. Thanks in advance for any advice Brian P.S. a big thanks to Chris for checking the boxes before activating the filter if you are on the list!
Re: Contact data for outlook.com
If you haven't done this yet - start with the outlook postmaster troubleshooting documentation and open a support ticket with them. https://sendersupport.olc.protection.outlook.com/pm/troubleshooting.aspx Matt On 2021-03-09 7:07 a.m., s...@circlenet.us wrote: You are not alone sir, for reasons as yet unknown outlook.com has recently started blocking my range as well. If I make progress in contacting someone with clue I will pass that information along privately. Sam Moats On 2021-03-08 16:18, Dan Walters via NANOG wrote: Good afternoon, So I'm looking for a contact at Microsoft in particular someone on the outlook spam protection/prevention team to assist us with a IP block. I have allready signed up for SNDS and there is no data given . Please feel free to contact me off the list. Best Regards, Daniel Walters
Re: Contact data for outlook.com
You are not alone sir, for reasons as yet unknown outlook.com has recently started blocking my range as well. If I make progress in contacting someone with clue I will pass that information along privately. Sam Moats On 2021-03-08 16:18, Dan Walters via NANOG wrote: Good afternoon, So I'm looking for a contact at Microsoft in particular someone on the outlook spam protection/prevention team to assist us with a IP block. I have allready signed up for SNDS and there is no data given . Please feel free to contact me off the list. Best Regards, Daniel Walters
Re: Is there an established method for reporting/getting removed a company with 100% false peeringdb entries?
That could be Justin, based on the timeline from domain registration to ARIN Object Creation ( Network and Abuse ) to PeeringDB Contact Update. That doesn't explain the recent update to Public Peering Info on 2021-03-07T20:35:22 months after the ASN stopped routing any IP space. The domain name associated with Manhattan Networks Corporation was created on June 2nd, on the same day it was updated, the operator created multiple ARIN objects: Domain Name: manhattannetworksco.com Updated Date: 2020-06-04T05:21:24Z Creation Date: 2020-06-02T13:05:12Z NETWO9241-ARIN - Thu, 04 Jun 2020 14:44:24 GMT (Thu Jun 04 2020 local time) ABUSE7921-ARIN - Thu, 04 Jun 2020 14:50:50 GMT (Thu Jun 04 2020 local time) The PeeringDB contact information entry was updated over an hour later. https://www.peeringdb.com/asn/18894 Contact Info Updated 2020-06-04T16:11:24Z Peering Facility Info Updated 2020-06-17T10:37:57Z Last Updated 2020-07-01T14:22:01Z Public Peering Info Updated 2021-03-07T20:35:22 On Jun 11th they created MNC-415 Registration - Thu, 11 Jun 2020 17:53:51 GMT (Thu Jun 11 2020 local time) Last Changed - Wed, 17 Jun 2020 04:39:38 GMT (Wed Jun 17 2020 local time) Comments - PDB: https://www.peeringdb.com/net/23440 On Jun 16th days later, the ASN was registered with ARIN. Source Registry ARIN Number 18894 Name MANHATTAN-US Handle AS18894 Registration - Tue, 16 Jun 2020 20:02:32 GMT (Tue Jun 16 2020 local time) Last Changed - Tue, 16 Jun 2020 20:02:32 GMT (Tue Jun 16 2020 local time) Activity wise, the IP space they were routing were leased from Cogent? Jul 17th - November 20th: announcing Cogent prefix 154.13.160.0/24 Aug 12th - Oct 6th: announcing Cogent prefix 154.13.161.0/24 On Fri, Mar 5, 2021 at 3:23 PM Justin Wilson (Lists) wrote: > I see from peering db: 2020-07-01T14:22:01Z > According to the bg.he.net link > AS18894 has not been visible in the global routing table since November > 28, 2020 > The information displayed is from that time. > > > Are they causing you or someone issues Eric? Maybe they went out of > business? Many businesses don’t worry about peering db entries. Looks like > the website has been under constructions since 2020. > > Sounds to me like they made a splash, and faltered. > > > Justin Wilson > j...@mtin.net > > — > https://j2sw.com - All things jsw (AS209109) > https://blog.j2sw.com - Podcast and Blog > > > On Mar 4, 2021, at 7:14 PM, Eric Kuhnke wrote: > > > > First, take a look at this: > > > > https://www.peeringdb.com/asn/18894 > > > > > > Now look at these (or use your own BGP table analysis tools): > > > > https://bgp.he.net/AS18894 > > > > https://stat.ripe.net/18894 > > > > The claimed prefixes announced, traffic levels and POPs appear to have > no correlation with reality in global v4/v6 BGP tables. > > > > It is also noteworthy that I have inquired with a number of persons I > know who are active in network engineering in NYC, and nobody has ever > encountered this company. > > > > > > > > > >
Re: AWS Using Class E IPv4 Address on internal Routing
Hi, On Tue, Mar 09, 2021 at 06:53:33AM -0800, Fred Baker wrote: > The "RFC" you're looking for is probably > https://tools.ietf.org/html/draft-wilson-class-e-02 there was/is also 'IPv4 unicast extensions project' (https://github.com/schoen/unicast-extensions) with a similar idea & approach. I for one think that from an operations perspective those addresses would be pretty much unusable in pretty much all complex networks (except for corner cases like, maybe, AWS' one), see https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-address-space/. cheers Enno , which was not agreed to and so has no RFC number. The fundamental issue that was raised during that discussion was that while repurposing class e would provide a few more IPv4 addresses and so delay the need to replace the IPv4 protocol for some period of time, APNIC's experience with a new /8 in 2011 (it was given the /8 in January 2011, and by April had largely distributed it to its members) suggests that the address space would be used up almost immediately if distributed publicly, and if used privately doesn't benefit the many networks that really honestly wish that we could squeeze more than 2^32 addresses into a 32 bit container. > > I'd really suggest using IPv6. Networks like Reliance JIO in India, which has > turned off or never turned on IPv4 for most of its services, find that they > don't need IPv4 apart from customer preference. > > > On Mar 9, 2021, at 6:36 AM, Douglas Fischer > > wrote: > > > > So, if an organization wants to use that, they will require from the > > vendors the compliance with that RFC. > > > > > > > > Em ter., 9 de mar. de 2021 ??s 11:00, Forrest Christian (List Account) > > escreveu: > > Back a little bit ago when the thread about running out of RFC-1918 space > > was going on, I was going to make a suggestion about repurposing the Class > > E space in the case where one ran out of space, assuming one could get the > > vendors on your network to support this address range. > > > > I sort of discarded the suggestion just because of the whole issue of that > > range being hardcoded as invalid in so many implementations that this > > didn't seem all that useful. > > > > On the other hand, if you're large enough that you're running out of > > RFC-1918 space you might be able to exert enough power over select vendors > > to get them to make this work for selected purposes. Router-to-Router > > links, especially between higher-end routers seems to be one of those cases > > that it might be useful. It might be the case that Amazon is already > > doing this > > > > > > On Mon, Mar 8, 2021 at 12:07 PM Douglas Fischer > > wrote: > > Has anybody seen that also? > > > > P.S.: I'm completely in favor of a complementary RFC assing FUTURE USE > > exclusively to "Between Routers" Link Networks... > > > > -- > > Douglas Fernando Fischer > > Eng?? de Controle e Automao > > > > > > -- > > - Forrest > > > > > > > -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator
Re: AWS Using Class E IPv4 Address on internal Routing
The "RFC" you're looking for is probably https://tools.ietf.org/html/draft-wilson-class-e-02, which was not agreed to and so has no RFC number. The fundamental issue that was raised during that discussion was that while repurposing class e would provide a few more IPv4 addresses and so delay the need to replace the IPv4 protocol for some period of time, APNIC's experience with a new /8 in 2011 (it was given the /8 in January 2011, and by April had largely distributed it to its members) suggests that the address space would be used up almost immediately if distributed publicly, and if used privately doesn't benefit the many networks that really honestly wish that we could squeeze more than 2^32 addresses into a 32 bit container. I'd really suggest using IPv6. Networks like Reliance JIO in India, which has turned off or never turned on IPv4 for most of its services, find that they don't need IPv4 apart from customer preference. > On Mar 9, 2021, at 6:36 AM, Douglas Fischer wrote: > > So, if an organization wants to use that, they will require from the vendors > the compliance with that RFC. > > > > Em ter., 9 de mar. de 2021 às 11:00, Forrest Christian (List Account) > escreveu: > Back a little bit ago when the thread about running out of RFC-1918 space was > going on, I was going to make a suggestion about repurposing the Class E > space in the case where one ran out of space, assuming one could get the > vendors on your network to support this address range. > > I sort of discarded the suggestion just because of the whole issue of that > range being hardcoded as invalid in so many implementations that this didn't > seem all that useful. > > On the other hand, if you're large enough that you're running out of RFC-1918 > space you might be able to exert enough power over select vendors to get them > to make this work for selected purposes. Router-to-Router links, especially > between higher-end routers seems to be one of those cases that it might be > useful. It might be the case that Amazon is already doing this > > > On Mon, Mar 8, 2021 at 12:07 PM Douglas Fischer > wrote: > Has anybody seen that also? > > P.S.: I'm completely in favor of a complementary RFC assing FUTURE USE > exclusively to "Between Routers" Link Networks... > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > > > -- > - Forrest > > > signature.asc Description: Message signed with OpenPGP
Re: AWS Using Class E IPv4 Address on internal Routing
I think this "intra-standard", probably using white-boxes, could be an Open-Standard conducted by an RFC or IANA definition. Something like: -> Equipments compliant with RFC WXYZ are able to use Classe E in their Interfaces without giving pokey messages "reserved for future use". So, if an organization wants to use that, they will require from the vendors the compliance with that RFC. Em ter., 9 de mar. de 2021 às 11:00, Forrest Christian (List Account) < li...@packetflux.com> escreveu: > Back a little bit ago when the thread about running out of RFC-1918 space > was going on, I was going to make a suggestion about repurposing the Class > E space in the case where one ran out of space, assuming one could get the > vendors on your network to support this address range. > > I sort of discarded the suggestion just because of the whole issue of that > range being hardcoded as invalid in so many implementations that this > didn't seem all that useful. > > On the other hand, if you're large enough that you're running out of > RFC-1918 space you might be able to exert enough power over select vendors > to get them to make this work for selected purposes. Router-to-Router > links, especially between higher-end routers seems to be one of those cases > that it might be useful. It might be the case that Amazon is already > doing this > > > On Mon, Mar 8, 2021 at 12:07 PM Douglas Fischer > wrote: > >> Has anybody seen that also? >> >> P.S.: I'm completely in favor of a complementary RFC assing FUTURE USE >> exclusively to "Between Routers" Link Networks... >> >> -- >> Douglas Fernando Fischer >> Engº de Controle e Automação >> > > > -- > - Forrest > -- Douglas Fernando Fischer Engº de Controle e Automação
Re: Ip space Dilemma
Have you written a state legislature yet? Reach out to your representative's offices and let them know. That's part of their job, constituent services. Since they are state government websites, they will have a little power. - Mike Bolitho On Tue, Mar 9, 2021, 7:15 AM Justin Wilson (Lists) wrote: > Folks, > We have an IP block I have asked about help on a few times on > here. This is a block we received from ARIN in June of 2020. We have > several state networks here in Indiana dropping this traffic at their > firewalls. I have been working with them since we discovered this issue in > September. I am not getting anywhere with them and was finally told we > were not a priority. > > I am at the point I need to give the space back because it is > unusable to the ISP customers. Does anyone have any creative ideas on how > to fix this? > > > > Justin Wilson > j...@mtin.net > > — > https://j2sw.com - All things jsw (AS209109) > https://blog.j2sw.com - Podcast and Blog > >
Re: AWS Using Class E IPv4 Address on internal Routing
Dnia Tue, Mar 09, 2021 at 07:00:47AM -0700, Forrest Christian (List Account) napisał(a): > to get them to make this work for selected purposes. Router-to-Router > links, especially between higher-end routers seems to be one of those cases > that it might be useful. BTW, some platforms and OS-es (like Linux) support routing IPv4 via IPv6 nexthops, this may help to conserve v4 p2p space in some environments. -- Pawel Malachowski @pawmal80
Ip space Dilemma
Folks, We have an IP block I have asked about help on a few times on here. This is a block we received from ARIN in June of 2020. We have several state networks here in Indiana dropping this traffic at their firewalls. I have been working with them since we discovered this issue in September. I am not getting anywhere with them and was finally told we were not a priority. I am at the point I need to give the space back because it is unusable to the ISP customers. Does anyone have any creative ideas on how to fix this? Justin Wilson j...@mtin.net — https://j2sw.com - All things jsw (AS209109) https://blog.j2sw.com - Podcast and Blog
Re: AWS Using Class E IPv4 Address on internal Routing
Back a little bit ago when the thread about running out of RFC-1918 space was going on, I was going to make a suggestion about repurposing the Class E space in the case where one ran out of space, assuming one could get the vendors on your network to support this address range. I sort of discarded the suggestion just because of the whole issue of that range being hardcoded as invalid in so many implementations that this didn't seem all that useful. On the other hand, if you're large enough that you're running out of RFC-1918 space you might be able to exert enough power over select vendors to get them to make this work for selected purposes. Router-to-Router links, especially between higher-end routers seems to be one of those cases that it might be useful. It might be the case that Amazon is already doing this On Mon, Mar 8, 2021 at 12:07 PM Douglas Fischer wrote: > Has anybody seen that also? > > P.S.: I'm completely in favor of a complementary RFC assing FUTURE USE > exclusively to "Between Routers" Link Networks... > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > -- - Forrest
