Note that none of these addresses (nor the other ones posted) have reverse DNS. I think we should make DNS entries (with callsign) mandatory for all allocated AMPRnet addresses!

Rob

On 11/19/21 9:01 PM, Ruben ON3RVH via 44Net wrote:

Hi Jeremy,

As one of the coordinators for ON land (44.144) I thank you for bringing this to our attention. I will investigate this matter.

Ruben - ON3RVH

It probably almost never is a problem.  There are so many AMPRnet addresses in use without a proper registration in ampr.org DNS (which automatically creates the reverse DNS record) that this cannot be the explanation for all of them. Apparently the DNS for 44.144 is very incomplete, the maintainer should bulk-update it. The DNS entries for 44.137 are completely in sync with the hosts file and addresses not appearing in that list are filtered at the gateway, just like on the UCSD gateway.  Everyone should do that.

Rob

On 11/20/21 10:28 AM, Falcon Darkstar Momot via 44Net wrote:

That could raise unexpected technical problems when rDNS is expected to be a particular thing.  If someone wants to do that, they'd do better to create a TXT record like 1.23.31.44.in-addr.arpa IN TXT "AF7MH".  But we know who the assignee is already!

AF7MH

On 2021-11-20 00:38, Rob PE1CHL via 44Net wrote:

...

Note that none of these addresses (nor the other ones posted) have reverse DNS. I think we should make DNS entries (with callsign) mandatory for all allocated AMPRnet addresses!

Rob

On 20 Nov 2021, at 15:05, Ruben ON3RVH via 44Net 44net@mailman.ampr.org wrote:

It is true that the 44.144 reverse zone is almost empty, however it - currently - is only updated at end user's request. There - currently - is no filtering on valid PTR records for internet access at our border, however we are designing a new connectivity system for our users and can incorporate that.

Whether or not everyone should do that is up for debate imo and if the majority should decide that and UCSD follows and makes it a rule of thumb then indeed everyone should do that. Maybe discussion to be held with the TAC?

I don't personally think it matters whether all allocated addresses have reverse PTR records, so long as:

1) Anyone suspecting a violation of our terms of service reports it to abuse@ardc.net mailto:abuse@ardc.net then it can be investigated and dealt with accordingly, and

2) Every individual responsible for using an IP address from ARDC is registered with us, so we know who to contact.

It is 2) that we have the problem with:

When a group or organisation (or in some cases individuals) registers a block of addresses then sub-allocates those addresses, often there is poor, or in some cases no audit trail to an individual user. I’ve had to deal with issues, for example, with folk setting up VPN servers then letting anyone use it without any vetting procedure or logs being kept.

This is a problem!

There is a new API being developed that will allow user registration and authentication, I would like to invite all parties that currently (or plan to) sub-allocate ARDC space to contact me so we can discuss integration of the API with their systems. We need a verifiable audit trail for users of our address space, this has to end with the Responsible Person for any allocated IP address.

73, Chris - G1FEF

I know many of the BGP subnets are not listed on the portal's network list.

I'm not sure if there is a reason for this or if it's some sort of technical oversight. And on that note, perhaps if they can/should be included, perhaps they can be noted as BPG?

On Sat, Nov 20, 2021 at 9:32 AM Chris Smith via 44Net 44net@mailman.ampr.org wrote:

...

On 20 Nov 2021, at 15:05, Ruben ON3RVH via 44Net 44net@mailman.ampr.org wrote:

It is true that the 44.144 reverse zone is almost empty, however it - currently - is only updated at end user's request. There - currently - is no filtering on valid PTR records for internet access at our border, however we are designing a new connectivity system for our users and can incorporate that.

Whether or not everyone should do that is up for debate imo and if the majority should decide that and UCSD follows and makes it a rule of thumb then indeed everyone should do that. Maybe discussion to be held with the TAC?

I don't personally think it matters whether all allocated addresses have reverse PTR records, so long as:

1. Anyone suspecting a violation of our terms of service reports it to abuse@ardc.net mailto:abuse@ardc.net then it can be investigated and dealt with accordingly, and

2. Every individual responsible for using an IP address from ARDC is registered with us, so we know who to contact.

It is 2) that we have the problem with:

When a group or organisation (or in some cases individuals) registers a block of addresses then sub-allocates those addresses, often there is poor, or in some cases no audit trail to an individual user. I’ve had to deal with issues, for example, with folk setting up VPN servers then letting anyone use it without any vetting procedure or logs being kept.

This is a problem!

There is a new API being developed that will allow user registration and authentication, I would like to invite all parties that currently (or plan to) sub-allocate ARDC space to contact me so we can discuss integration of the API with their systems. We need a verifiable audit trail for users of our address space, this has to end with the Responsible Person for any allocated IP address.

73, Chris - G1FEF

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

I think there are a few things that could be done in terms of BGP subnets.

Adding a property to Allocations and Assignments in the AMPRnet Portal that adds a column to the table when browsing with the authorized ASN.

The fixing of whois.ampr.org

The addition of origin: properties, similar to regular RPSL (RFC2622) route records to the aforementioned whois server using the ASN property.

Additionally in future with that property in the portal creating an ROA for the subnet automatically. With that/those ASN(s) being added to the origin property in the whois as mentioned. Making BGP routing of 44net more secure cause of the ROAs.

Note: for those not familiar with RPKI ROAs, it's a system of cryptography that allow verifiable authorization of BGP announcements. Since none of the data ever sent is encrypted, but simply signed with all the public keys, no data is not readable. It would to my knowledge at least comply with Canadian amateur regulations in regards to cryptography for over the air amateur transmissions.

Further using that same data to automatically generate route records in ARIN.

The addition of an ASN property to the portal with automatic ARIN route records and ROAs could make significant strides in helping ensure announcements are consistent with ARDC's goals. Whilst it won't fix abuse and commercial usage of AMPRnet. It will help in the enforcement of policies and eliminate hijacking of AMPRnet space, where I have several times reported such hijacks as I've come across them. As more and more networks and internet backbones reject routes that have invalid ROAs with more doing so over the years makes prefixes routable across the internet effectively impossible with an ROA that mismatches.

In terms of the automation of this, I am not aware of how the backend of the portal functions but no doubt it wouldn't require a massive overhaul to implement the automatic ROA and route record functions I've mentioned. ARIN provides a method for organizations to use an API to submit ROAs and route records automatically. I have used the API myself and am working on an automated system for some of my other networks.

I would suggest that once the system has been put into place, that all allocatees that hold a /24 or more receive an email stating they must submit the authorized ASN(s) by $date via the portal. And at such time an AS0 (or UCSD's AS7377) ROA for 44.0.0.0/9 and 44.128.0.0/10 will be issued making their announcement invalid without submitting an ASN and thus an ROA issued having their address space un-announceable via BGP.

I have mainly kept silent on this mailing list however I think that the addition of these changes are the best way to go all things considered. I thought this would be relevant considering the talk about abuse and how to control unauthorized announcements. And these changes would make revoking BGP announcements on unresponsive parties possible, easy and efficient for ARDC. Please be easy on me, I'm not that comfortable talking on mailing lists. Just some suggestions that could help.

Thought this was going to be a shorter email. woops.

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me On 11/20/21 12:01 PM, Steve L via 44Net wrote:

I know many of the BGP subnets are not listed on the portal's network list.

I'm not sure if there is a reason for this or if it's some sort of technical oversight. And on that note, perhaps if they can/should be included, perhaps they can be noted as BPG?

On Sat, Nov 20, 2021 at 9:32 AM Chris Smith via 44Net 44net@mailman.ampr.org wrote:

...

...

On 20 Nov 2021, at 15:05, Ruben ON3RVH via 44Net 44net@mailman.ampr.org wrote:

It is true that the 44.144 reverse zone is almost empty, however it - currently - is only updated at end user's request. There - currently - is no filtering on valid PTR records for internet access at our border, however we are designing a new connectivity system for our users and can incorporate that.

Whether or not everyone should do that is up for debate imo and if the majority should decide that and UCSD follows and makes it a rule of thumb then indeed everyone should do that. Maybe discussion to be held with the TAC?

I don't personally think it matters whether all allocated addresses have reverse PTR records, so long as:

1. Anyone suspecting a violation of our terms of service reports it to abuse@ardc.net mailto:abuse@ardc.net then it can be investigated and dealt with accordingly, and

2. Every individual responsible for using an IP address from ARDC is registered with us, so we know who to contact.

It is 2) that we have the problem with:

When a group or organisation (or in some cases individuals) registers a block of addresses then sub-allocates those addresses, often there is poor, or in some cases no audit trail to an individual user. I’ve had to deal with issues, for example, with folk setting up VPN servers then letting anyone use it without any vetting procedure or logs being kept.

This is a problem!

There is a new API being developed that will allow user registration and authentication, I would like to invite all parties that currently (or plan to) sub-allocate ARDC space to contact me so we can discuss integration of the API with their systems. We need a verifiable audit trail for users of our address space, this has to end with the Responsible Person for any allocated IP address.

73, Chris - G1FEF

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Scratch the fixing of the WHOIS, there is a specific block that I keep getting a database error for, I'll contact Chris about it privately.

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me

On 11/20/21 2:57 PM, Keaton VE5LPL via 44Net wrote:

woops, thought I'd make it a reply to the thread I have there, then thought it would be better as another thread.

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me On 11/20/21 2:56 PM, Keaton VE5LPL wrote:

...

I think there are a few things that could be done in terms of BGP subnets.

Adding a property to Allocations and Assignments in the AMPRnet Portal that adds a column to the table when browsing with the authorized ASN.

The fixing of whois.ampr.org

The addition of origin: properties, similar to regular RPSL (RFC2622) route records to the aforementioned whois server using the ASN property.

Additionally in future with that property in the portal creating an ROA for the subnet automatically. With that/those ASN(s) being added to the origin property in the whois as mentioned. Making BGP routing of 44net more secure cause of the ROAs.

Note: for those not familiar with RPKI ROAs, it's a system of cryptography that allow verifiable authorization of BGP announcements. Since none of the data ever sent is encrypted, but simply signed with all the public keys, no data is not readable. It would to my knowledge at least comply with Canadian amateur regulations in regards to cryptography for over the air amateur transmissions.

Further using that same data to automatically generate route records in ARIN.

The addition of an ASN property to the portal with automatic ARIN route records and ROAs could make significant strides in helping ensure announcements are consistent with ARDC's goals. Whilst it won't fix abuse and commercial usage of AMPRnet. It will help in the enforcement of policies and eliminate hijacking of AMPRnet space, where I have several times reported such hijacks as I've come across them. As more and more networks and internet backbones reject routes that have invalid ROAs with more doing so over the years makes prefixes routable across the internet effectively impossible with an ROA that mismatches.

In terms of the automation of this, I am not aware of how the backend of the portal functions but no doubt it wouldn't require a massive overhaul to implement the automatic ROA and route record functions I've mentioned. ARIN provides a method for organizations to use an API to submit ROAs and route records automatically. I have used the API myself and am working on an automated system for some of my other networks.

I would suggest that once the system has been put into place, that all allocatees that hold a /24 or more receive an email stating they must submit the authorized ASN(s) by $date via the portal. And at such time an AS0 (or UCSD's AS7377) ROA for 44.0.0.0/9 and 44.128.0.0/10 will be issued making their announcement invalid without submitting an ASN and thus an ROA issued having their address space un-announceable via BGP.

I have mainly kept silent on this mailing list however I think that the addition of these changes are the best way to go all things considered. I thought this would be relevant considering the talk about abuse and how to control unauthorized announcements. And these changes would make revoking BGP announcements on unresponsive parties possible, easy and efficient for ARDC. Please be easy on me, I'm not that comfortable talking on mailing lists. Just some suggestions that could help.

Thought this was going to be a shorter email. woops.

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me On 11/20/21 12:01 PM, Steve L via 44Net wrote:

...

I know many of the BGP subnets are not listed on the portal's network list.

I'm not sure if there is a reason for this or if it's some sort of technical oversight.  And on that note, perhaps if they can/should be included, perhaps they can be noted as BPG?

On Sat, Nov 20, 2021 at 9:32 AM Chris Smith via 44Net 44net@mailman.ampr.org wrote:

...

...

On 20 Nov 2021, at 15:05, Ruben ON3RVH via 44Net 44net@mailman.ampr.org wrote:

It is true that the 44.144 reverse zone is almost empty, however it - currently - is only updated at end user's request. There - currently - is no filtering on valid PTR records for internet access at our border, however we are designing a new connectivity system for our users and can incorporate that.

Whether or not everyone should do that is up for debate imo and if the majority should decide that and UCSD follows and makes it a rule of thumb then indeed everyone should do that. Maybe discussion to be held with the TAC?

I don't personally think it matters whether all allocated addresses have reverse PTR records, so long as:

1. Anyone suspecting a violation of our terms of service reports it

to abuse@ardc.net mailto:abuse@ardc.net then it can be investigated and dealt with accordingly, and

2. Every individual responsible for using an IP address from ARDC

is registered with us, so we know who to contact.

It is 2) that we have the problem with:

When a group or organisation (or in some cases individuals) registers a block of addresses then sub-allocates those addresses, often there is poor, or in some cases no audit trail to an individual user. I’ve had to deal with issues, for example, with folk setting up VPN servers then letting anyone use it without any vetting procedure or logs being kept.

This is a problem!

There is a new API being developed that will allow user registration and authentication, I would like to invite all parties that currently (or plan to) sub-allocate ARDC space to contact me so we can discuss integration of the API with their systems. We need a verifiable audit trail for users of our address space, this has to end with the Responsible Person for any allocated IP address.

73, Chris - G1FEF

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Ok, there is something you might not realize, I was aware of that, however when I wrote my message I forgot. I've asked around what the terms are with ARIN that are so unpalatable and have not gotten an actual response, could you clarify on that?

I'm real skeptical of RIPE in regards to AMPRnet switching over to registration with them. ARDC would be potentially be beholden to which ever LIR has sponsored AMPRnet and to my knowledge ARDC cannot become an LIR as ARDC is an American (non-profit). In addition to that I've heard rumors of RIPE being worse when it comes to maintaining legacy status. Unless there are more specifics that could be elaborated on, I would strongly encourage ARDC to go with ARIN.

To my knowledge of the ARIN NRPM, It specifies ARIN IPv6 as not the property of the organization that holds ARIN IPv6 space. No such clause applies to IPv4 and the language which the NRPM uses in regards to IPv4 tacitly encourages the presumption of IPv4 (and more so legacy IPv4) as the property of the organization that holds it. Whereas as far as I'm aware no such clause or presumption exists.

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me On 11/20/21 3:30 PM, Chris Smith via 44Net wrote:

Hi Keaton,

You make some valid points, however you are missing some critical information:

• We cannot create objects in ARIN’s IRR database as we don't have membership with them.
• As we don’t have membership with ARIN we cannot participate in RPKI.
• Same issue using ARIN's API.

Our address space is legacy space, it has to be registered “somewhere” to work, i.e. with one of the 5 RIR’s, and it happens to be with ARIN, but we are not ARIN members, therefore we get non of the resources available to ARIN members. Nor do we want to sign an agreement with ARIN as their terms are rather restrictive and could even result in us losing our legacy status.

We (ARDC) have been looking into these issues, and we have some ideas as to how we may be able to resolve them. One suggestion we have been investigating is to move our address space to a different RIR, e.g. RIPE as their terms are far more palatable and we wouldn’t have to sign away our legacy status.

BTW, the whois server isn’t faulty as such, it’s an intentional throttling mechanism, however it could be handled a bit better and is on my TODO list.

73, Chris - G1FEF

...

On 20 Nov 2021, at 20:56, Keaton VE5LPL via 44Net 44net@mailman.ampr.org wrote:

I think there are a few things that could be done in terms of BGP subnets.

Adding a property to Allocations and Assignments in the AMPRnet Portal that adds a column to the table when browsing with the authorized ASN.

The fixing of whois.ampr.org

The addition of origin: properties, similar to regular RPSL (RFC2622) route records to the aforementioned whois server using the ASN property.

Additionally in future with that property in the portal creating an ROA for the subnet automatically. With that/those ASN(s) being added to the origin property in the whois as mentioned. Making BGP routing of 44net more secure cause of the ROAs.

Note: for those not familiar with RPKI ROAs, it's a system of cryptography that allow verifiable authorization of BGP announcements. Since none of the data ever sent is encrypted, but simply signed with all the public keys, no data is not readable. It would to my knowledge at least comply with Canadian amateur regulations in regards to cryptography for over the air amateur transmissions.

Further using that same data to automatically generate route records in ARIN.

The addition of an ASN property to the portal with automatic ARIN route records and ROAs could make significant strides in helping ensure announcements are consistent with ARDC's goals. Whilst it won't fix abuse and commercial usage of AMPRnet. It will help in the enforcement of policies and eliminate hijacking of AMPRnet space, where I have several times reported such hijacks as I've come across them. As more and more networks and internet backbones reject routes that have invalid ROAs with more doing so over the years makes prefixes routable across the internet effectively impossible with an ROA that mismatches.

In terms of the automation of this, I am not aware of how the backend of the portal functions but no doubt it wouldn't require a massive overhaul to implement the automatic ROA and route record functions I've mentioned. ARIN provides a method for organizations to use an API to submit ROAs and route records automatically. I have used the API myself and am working on an automated system for some of my other networks.

I would suggest that once the system has been put into place, that all allocatees that hold a /24 or more receive an email stating they must submit the authorized ASN(s) by $date via the portal. And at such time an AS0 (or UCSD's AS7377) ROA for 44.0.0.0/9 and 44.128.0.0/10 will be issued making their announcement invalid without submitting an ASN and thus an ROA issued having their address space un-announceable via BGP.

I have mainly kept silent on this mailing list however I think that the addition of these changes are the best way to go all things considered. I thought this would be relevant considering the talk about abuse and how to control unauthorized announcements. And these changes would make revoking BGP announcements on unresponsive parties possible, easy and efficient for ARDC. Please be easy on me, I'm not that comfortable talking on mailing lists. Just some suggestions that could help.

Thought this was going to be a shorter email. woops.

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me On 11/20/21 12:01 PM, Steve L via 44Net wrote:

...

I know many of the BGP subnets are not listed on the portal's network list. I'm not sure if there is a reason for this or if it's some sort of technical oversight. And on that note, perhaps if they can/should be included, perhaps they can be noted as BPG? On Sat, Nov 20, 2021 at 9:32 AM Chris Smith via 44Net 44net@mailman.ampr.org wrote:

...

...

On 20 Nov 2021, at 15:05, Ruben ON3RVH via 44Net 44net@mailman.ampr.org wrote:

It is true that the 44.144 reverse zone is almost empty, however it - currently - is only updated at end user's request. There - currently - is no filtering on valid PTR records for internet access at our border, however we are designing a new connectivity system for our users and can incorporate that.

Whether or not everyone should do that is up for debate imo and if the majority should decide that and UCSD follows and makes it a rule of thumb then indeed everyone should do that. Maybe discussion to be held with the TAC?

I don't personally think it matters whether all allocated addresses have reverse PTR records, so long as:

1. Anyone suspecting a violation of our terms of service reports it to abuse@ardc.net mailto:abuse@ardc.net then it can be investigated and dealt with accordingly, and

2. Every individual responsible for using an IP address from ARDC is registered with us, so we know who to contact.

It is 2) that we have the problem with:

When a group or organisation (or in some cases individuals) registers a block of addresses then sub-allocates those addresses, often there is poor, or in some cases no audit trail to an individual user. I’ve had to deal with issues, for example, with folk setting up VPN servers then letting anyone use it without any vetting procedure or logs being kept.

This is a problem!

There is a new API being developed that will allow user registration and authentication, I would like to invite all parties that currently (or plan to) sub-allocate ARDC space to contact me so we can discuss integration of the API with their systems. We need a verifiable audit trail for users of our address space, this has to end with the Responsible Person for any allocated IP address.

73, Chris - G1FEF

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

On 20 Nov 2021, at 21:43, Paul Sladen via 44Net 44net@mailman.ampr.org wrote:

On Sat, 20 Nov 2021, Keaton VE5LPL via 44Net wrote:

...

I'm real skeptical of RIPE in regards to AMPRnet

Please try not to be skeptical towards RIPE ... RIPE is the most realistic RIR without the complications of ARIN.

I personally agree with that statement.

(What I don't understand is what the delays have been; my understanding is that the possibility of using RIPE for the remainder of 44/8 has now been under investigation for 2 years now…)

Patience Paul :)

These things take time, it has been discussed as an option, we are currently doing some investigation into the transfer process. We will not be rushing into anything as important as transferring the address space to another RIR. Any transfer, if it happens, will be done carefully and with all the right checks completed beforehand. Also, it’s not currently our highest priority.

73, Chris - G1FEF

On 20 Nov 2021, at 21:56, Keaton VE5LPL via 44Net 44net@mailman.ampr.org wrote:

Ok, there is something you might not realize, I was aware of that, however when I wrote my message I forgot. I've asked around what the terms are with ARIN that are so unpalatable and have not gotten an actual response, could you clarify on that?

I am not personally able to quote specific clauses for you, but board members have looked into this in some detail and their response was a most resounding “no” to ARIN membership. Whilst RIPE membership was a “definite possibility”. I can ask for specifics if you are particularly interested, or perhaps a board member could respond…?

I'm real skeptical of RIPE in regards to AMPRnet switching over to registration with them. ARDC would be potentially be beholden to which ever LIR has sponsored AMPRnet and to my knowledge ARDC cannot become an LIR as ARDC is an American (non-profit). In addition to that I've heard rumors of RIPE being worse when it comes to maintaining legacy status. Unless there are more specifics that could be elaborated on, I would strongly encourage ARDC to go with ARIN.

Ok, so IF we moved to RIPE, we would not be signing an agreement with any LIR. We ARE able to join RIPE ourselves and become an LIR - this has already been confirmed. It’s not about where an organisation is registered so much, rather more where the address space will be used, i.e. will it be used in the RIPE region. For example, the European HAMNET is the single largest user of our address space I do not believe we would have any problem convincing RIPE to let us become members.

73, Chris - G1FEF

To my knowledge of the ARIN NRPM, It specifies ARIN IPv6 as not the property of the organization that holds ARIN IPv6 space. No such clause applies to IPv4 and the language which the NRPM uses in regards to IPv4 tacitly encourages the presumption of IPv4 (and more so legacy IPv4) as the property of the organization that holds it. Whereas as far as I'm aware no such clause or presumption exists.

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me On 11/20/21 3:30 PM, Chris Smith via 44Net wrote:

...

Hi Keaton, You make some valid points, however you are missing some critical information:

• We cannot create objects in ARIN’s IRR database as we don't have membership with them.
• As we don’t have membership with ARIN we cannot participate in RPKI.
• Same issue using ARIN's API.

Our address space is legacy space, it has to be registered “somewhere” to work, i.e. with one of the 5 RIR’s, and it happens to be with ARIN, but we are not ARIN members, therefore we get non of the resources available to ARIN members. Nor do we want to sign an agreement with ARIN as their terms are rather restrictive and could even result in us losing our legacy status. We (ARDC) have been looking into these issues, and we have some ideas as to how we may be able to resolve them. One suggestion we have been investigating is to move our address space to a different RIR, e.g. RIPE as their terms are far more palatable and we wouldn’t have to sign away our legacy status. BTW, the whois server isn’t faulty as such, it’s an intentional throttling mechanism, however it could be handled a bit better and is on my TODO list. 73, Chris - G1FEF

...

On 20 Nov 2021, at 20:56, Keaton VE5LPL via 44Net 44net@mailman.ampr.org wrote:

I think there are a few things that could be done in terms of BGP subnets.

Adding a property to Allocations and Assignments in the AMPRnet Portal that adds a column to the table when browsing with the authorized ASN.

The fixing of whois.ampr.org

The addition of origin: properties, similar to regular RPSL (RFC2622) route records to the aforementioned whois server using the ASN property.

Additionally in future with that property in the portal creating an ROA for the subnet automatically. With that/those ASN(s) being added to the origin property in the whois as mentioned. Making BGP routing of 44net more secure cause of the ROAs.

Note: for those not familiar with RPKI ROAs, it's a system of cryptography that allow verifiable authorization of BGP announcements. Since none of the data ever sent is encrypted, but simply signed with all the public keys, no data is not readable. It would to my knowledge at least comply with Canadian amateur regulations in regards to cryptography for over the air amateur transmissions.

Further using that same data to automatically generate route records in ARIN.

The addition of an ASN property to the portal with automatic ARIN route records and ROAs could make significant strides in helping ensure announcements are consistent with ARDC's goals. Whilst it won't fix abuse and commercial usage of AMPRnet. It will help in the enforcement of policies and eliminate hijacking of AMPRnet space, where I have several times reported such hijacks as I've come across them. As more and more networks and internet backbones reject routes that have invalid ROAs with more doing so over the years makes prefixes routable across the internet effectively impossible with an ROA that mismatches.

In terms of the automation of this, I am not aware of how the backend of the portal functions but no doubt it wouldn't require a massive overhaul to implement the automatic ROA and route record functions I've mentioned. ARIN provides a method for organizations to use an API to submit ROAs and route records automatically. I have used the API myself and am working on an automated system for some of my other networks.

I would suggest that once the system has been put into place, that all allocatees that hold a /24 or more receive an email stating they must submit the authorized ASN(s) by $date via the portal. And at such time an AS0 (or UCSD's AS7377) ROA for 44.0.0.0/9 and 44.128.0.0/10 will be issued making their announcement invalid without submitting an ASN and thus an ROA issued having their address space un-announceable via BGP.

I have mainly kept silent on this mailing list however I think that the addition of these changes are the best way to go all things considered. I thought this would be relevant considering the talk about abuse and how to control unauthorized announcements. And these changes would make revoking BGP announcements on unresponsive parties possible, easy and efficient for ARDC. Please be easy on me, I'm not that comfortable talking on mailing lists. Just some suggestions that could help.

Thought this was going to be a shorter email. woops.

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me On 11/20/21 12:01 PM, Steve L via 44Net wrote:

...

I know many of the BGP subnets are not listed on the portal's network list. I'm not sure if there is a reason for this or if it's some sort of technical oversight. And on that note, perhaps if they can/should be included, perhaps they can be noted as BPG? On Sat, Nov 20, 2021 at 9:32 AM Chris Smith via 44Net 44net@mailman.ampr.org wrote:

...

...

On 20 Nov 2021, at 15:05, Ruben ON3RVH via 44Net 44net@mailman.ampr.org wrote:

It is true that the 44.144 reverse zone is almost empty, however it - currently - is only updated at end user's request. There - currently - is no filtering on valid PTR records for internet access at our border, however we are designing a new connectivity system for our users and can incorporate that.

Whether or not everyone should do that is up for debate imo and if the majority should decide that and UCSD follows and makes it a rule of thumb then indeed everyone should do that. Maybe discussion to be held with the TAC?

I don't personally think it matters whether all allocated addresses have reverse PTR records, so long as:

1. Anyone suspecting a violation of our terms of service reports it to abuse@ardc.net mailto:abuse@ardc.net then it can be investigated and dealt with accordingly, and

2. Every individual responsible for using an IP address from ARDC is registered with us, so we know who to contact.

It is 2) that we have the problem with:

When a group or organisation (or in some cases individuals) registers a block of addresses then sub-allocates those addresses, often there is poor, or in some cases no audit trail to an individual user. I’ve had to deal with issues, for example, with folk setting up VPN servers then letting anyone use it without any vetting procedure or logs being kept.

This is a problem!

There is a new API being developed that will allow user registration and authentication, I would like to invite all parties that currently (or plan to) sub-allocate ARDC space to contact me so we can discuss integration of the API with their systems. We need a verifiable audit trail for users of our address space, this has to end with the Responsible Person for any allocated IP address.

73, Chris - G1FEF

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Ok, considering that ARDC would be able to become an LIR that changes things and my opinion. I would suggest in any case that either ARIN membership or RIPE registration, that it not simply be a board decision but something brought before the community with all factors made available to the community.

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me On 11/20/21 4:59 PM, Chris Smith via 44Net wrote:

...

On 20 Nov 2021, at 21:56, Keaton VE5LPL via 44Net 44net@mailman.ampr.org wrote:

Ok, there is something you might not realize, I was aware of that, however when I wrote my message I forgot. I've asked around what the terms are with ARIN that are so unpalatable and have not gotten an actual response, could you clarify on that?

I am not personally able to quote specific clauses for you, but board members have looked into this in some detail and their response was a most resounding “no” to ARIN membership. Whilst RIPE membership was a “definite possibility”. I can ask for specifics if you are particularly interested, or perhaps a board member could respond…?

...

I'm real skeptical of RIPE in regards to AMPRnet switching over to registration with them. ARDC would be potentially be beholden to which ever LIR has sponsored AMPRnet and to my knowledge ARDC cannot become an LIR as ARDC is an American (non-profit). In addition to that I've heard rumors of RIPE being worse when it comes to maintaining legacy status. Unless there are more specifics that could be elaborated on, I would strongly encourage ARDC to go with ARIN.

Ok, so IF we moved to RIPE, we would not be signing an agreement with any LIR. We ARE able to join RIPE ourselves and become an LIR - this has already been confirmed. It’s not about where an organisation is registered so much, rather more where the address space will be used, i.e. will it be used in the RIPE region. For example, the European HAMNET is the single largest user of our address space I do not believe we would have any problem convincing RIPE to let us become members.

73, Chris - G1FEF

...

To my knowledge of the ARIN NRPM, It specifies ARIN IPv6 as not the property of the organization that holds ARIN IPv6 space. No such clause applies to IPv4 and the language which the NRPM uses in regards to IPv4 tacitly encourages the presumption of IPv4 (and more so legacy IPv4) as the property of the organization that holds it. Whereas as far as I'm aware no such clause or presumption exists.

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me On 11/20/21 3:30 PM, Chris Smith via 44Net wrote:

...

Hi Keaton, You make some valid points, however you are missing some critical information:

• We cannot create objects in ARIN’s IRR database as we don't have membership with them.
• As we don’t have membership with ARIN we cannot participate in RPKI.
• Same issue using ARIN's API.

Our address space is legacy space, it has to be registered “somewhere” to work, i.e. with one of the 5 RIR’s, and it happens to be with ARIN, but we are not ARIN members, therefore we get non of the resources available to ARIN members. Nor do we want to sign an agreement with ARIN as their terms are rather restrictive and could even result in us losing our legacy status. We (ARDC) have been looking into these issues, and we have some ideas as to how we may be able to resolve them. One suggestion we have been investigating is to move our address space to a different RIR, e.g. RIPE as their terms are far more palatable and we wouldn’t have to sign away our legacy status. BTW, the whois server isn’t faulty as such, it’s an intentional throttling mechanism, however it could be handled a bit better and is on my TODO list. 73, Chris - G1FEF

...

On 20 Nov 2021, at 20:56, Keaton VE5LPL via 44Net 44net@mailman.ampr.org wrote:

I think there are a few things that could be done in terms of BGP subnets.

Adding a property to Allocations and Assignments in the AMPRnet Portal that adds a column to the table when browsing with the authorized ASN.

The fixing of whois.ampr.org

The addition of origin: properties, similar to regular RPSL (RFC2622) route records to the aforementioned whois server using the ASN property.

Additionally in future with that property in the portal creating an ROA for the subnet automatically. With that/those ASN(s) being added to the origin property in the whois as mentioned. Making BGP routing of 44net more secure cause of the ROAs.

Note: for those not familiar with RPKI ROAs, it's a system of cryptography that allow verifiable authorization of BGP announcements. Since none of the data ever sent is encrypted, but simply signed with all the public keys, no data is not readable. It would to my knowledge at least comply with Canadian amateur regulations in regards to cryptography for over the air amateur transmissions.

Further using that same data to automatically generate route records in ARIN.

The addition of an ASN property to the portal with automatic ARIN route records and ROAs could make significant strides in helping ensure announcements are consistent with ARDC's goals. Whilst it won't fix abuse and commercial usage of AMPRnet. It will help in the enforcement of policies and eliminate hijacking of AMPRnet space, where I have several times reported such hijacks as I've come across them. As more and more networks and internet backbones reject routes that have invalid ROAs with more doing so over the years makes prefixes routable across the internet effectively impossible with an ROA that mismatches.

In terms of the automation of this, I am not aware of how the backend of the portal functions but no doubt it wouldn't require a massive overhaul to implement the automatic ROA and route record functions I've mentioned. ARIN provides a method for organizations to use an API to submit ROAs and route records automatically. I have used the API myself and am working on an automated system for some of my other networks.

I would suggest that once the system has been put into place, that all allocatees that hold a /24 or more receive an email stating they must submit the authorized ASN(s) by $date via the portal. And at such time an AS0 (or UCSD's AS7377) ROA for 44.0.0.0/9 and 44.128.0.0/10 will be issued making their announcement invalid without submitting an ASN and thus an ROA issued having their address space un-announceable via BGP.

I have mainly kept silent on this mailing list however I think that the addition of these changes are the best way to go all things considered. I thought this would be relevant considering the talk about abuse and how to control unauthorized announcements. And these changes would make revoking BGP announcements on unresponsive parties possible, easy and efficient for ARDC. Please be easy on me, I'm not that comfortable talking on mailing lists. Just some suggestions that could help.

Thought this was going to be a shorter email. woops.

Sincerely, Keaton VE5LPL A Saskatchewian ham who does stuff and things https://kagl.me me@kagl.me On 11/20/21 12:01 PM, Steve L via 44Net wrote:

...

I know many of the BGP subnets are not listed on the portal's network list. I'm not sure if there is a reason for this or if it's some sort of technical oversight. And on that note, perhaps if they can/should be included, perhaps they can be noted as BPG? On Sat, Nov 20, 2021 at 9:32 AM Chris Smith via 44Net 44net@mailman.ampr.org wrote:

...

> On 20 Nov 2021, at 15:05, Ruben ON3RVH via 44Net 44net@mailman.ampr.org wrote: > > It is true that the 44.144 reverse zone is almost empty, however it - currently - is only updated at end user's request. > There - currently - is no filtering on valid PTR records for internet access at our border, however we are designing a new connectivity system for our users and can incorporate that. > > Whether or not everyone should do that is up for debate imo and if the majority should decide that and UCSD follows and makes it a rule of thumb then indeed everyone should do that. Maybe discussion to be held with the TAC?

I don't personally think it matters whether all allocated addresses have reverse PTR records, so long as:

1. Anyone suspecting a violation of our terms of service reports it to abuse@ardc.net mailto:abuse@ardc.net then it can be investigated and dealt with accordingly, and

2. Every individual responsible for using an IP address from ARDC is registered with us, so we know who to contact.

It is 2) that we have the problem with:

When a group or organisation (or in some cases individuals) registers a block of addresses then sub-allocates those addresses, often there is poor, or in some cases no audit trail to an individual user. I’ve had to deal with issues, for example, with folk setting up VPN servers then letting anyone use it without any vetting procedure or logs being kept.

This is a problem!

There is a new API being developed that will allow user registration and authentication, I would like to invite all parties that currently (or plan to) sub-allocate ARDC space to contact me so we can discuss integration of the API with their systems. We need a verifiable audit trail for users of our address space, this has to end with the Responsible Person for any allocated IP address.

73, Chris - G1FEF

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Reverse DNS is not a mechanism to identify end users of subnet's. That mechanism already exits it's called whois.  In a perfect would the 44net registry would allow users to update their own whois entry from the portal.

Matt

On 21/11/21 2:05 am, Ruben ON3RVH via 44Net wrote:

It is true that the 44.144 reverse zone is almost empty, however it - currently - is only updated at end user's request. There - currently - is no filtering on valid PTR records for internet access at our border, however we are designing a new connectivity system for our users and can incorporate that.

Whether or not everyone should do that is up for debate imo and if the majority should decide that and UCSD follows and makes it a rule of thumb then indeed everyone should do that. Maybe discussion to be held with the TAC?

73

Ruben ON3RVH

-----Original Message----- From: 44Net 44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org On Behalf Of Rob PE1CHL via 44Net Sent: Saturday, November 20, 2021 10:54 To: Falcon Darkstar Momot via 44Net 44net@mailman.ampr.org Cc: Rob PE1CHL 44net@pe1chl.nl Subject: Re: [44net] Potential commercial use / TOS violation 44.144.50.0/24

It probably almost never is a problem.  There are so many AMPRnet addresses in use without a proper registration in ampr.org DNS (which automatically creates the reverse DNS record) that this cannot be the explanation for all of them. Apparently the DNS for 44.144 is very incomplete, the maintainer should bulk-update it. The DNS entries for 44.137 are completely in sync with the hosts file and addresses not appearing in that list are filtered at the gateway, just like on the UCSD gateway.  Everyone should do that.

Rob

On 11/20/21 10:28 AM, Falcon Darkstar Momot via 44Net wrote:

...

That could raise unexpected technical problems when rDNS is expected to be a particular thing.  If someone wants to do that, they'd do better to create a TXT record like 1.23.31.44.in-addr.arpa IN TXT "AF7MH".  But we know who the assignee is already!

AF7MH

On 2021-11-20 00:38, Rob PE1CHL via 44Net wrote:

...

Note that none of these addresses (nor the other ones posted) have reverse DNS. I think we should make DNS entries (with callsign) mandatory for all allocated AMPRnet addresses!

Rob

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

To a limited extent, they can --

The Description is taken from the IP allocation as input by the requestor The Locator is taken from the User Profile

whois -h whois.ampr.org 44.24.130.0

Complete editing could lead to the creation of bogus responses on whois.

Perhaps we could add the associated email with the OrgAbuseEmail and OrgTechEmail?

On Sat, Nov 20, 2021 at 4:32 PM Matt - VK2FLY via 44Net < 44net@mailman.ampr.org> wrote:

Reverse DNS is not a mechanism to identify end users of subnet's. That mechanism already exits it's called whois. In a perfect would the 44net registry would allow users to update their own whois entry from the portal.

Matt

On 21/11/21 2:05 am, Ruben ON3RVH via 44Net wrote:

...

It is true that the 44.144 reverse zone is almost empty, however it -

currently - is only updated at end user's request.

...

There - currently - is no filtering on valid PTR records for internet

access at our border, however we are designing a new connectivity system for our users and can incorporate that.

...

Whether or not everyone should do that is up for debate imo and if the

majority should decide that and UCSD follows and makes it a rule of thumb then indeed everyone should do that. Maybe discussion to be held with the TAC?

...

73

Ruben ON3RVH

-----Original Message----- From: 44Net 44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org On Behalf

Of Rob PE1CHL via 44Net

...

Sent: Saturday, November 20, 2021 10:54 To: Falcon Darkstar Momot via 44Net 44net@mailman.ampr.org Cc: Rob PE1CHL 44net@pe1chl.nl Subject: Re: [44net] Potential commercial use / TOS violation

44.144.50.0/24

...

It probably almost never is a problem. There are so many AMPRnet

addresses in use without a proper registration in ampr.org DNS (which automatically creates the reverse DNS record) that this cannot be the explanation for all of them.

...

Apparently the DNS for 44.144 is very incomplete, the maintainer should

bulk-update it.

...

The DNS entries for 44.137 are completely in sync with the hosts file

and addresses not appearing in that list are filtered at the gateway, just like on the UCSD gateway. Everyone should do that.

...

Rob

On 11/20/21 10:28 AM, Falcon Darkstar Momot via 44Net wrote:

...

That could raise unexpected technical problems when rDNS is expected to

be a particular thing. If someone wants to do that, they'd do better to create a TXT record like 1.23.31.44.in-addr.arpa IN TXT "AF7MH". But we know who the assignee is already!

...

...

AF7MH

On 2021-11-20 00:38, Rob PE1CHL via 44Net wrote:

...

Note that none of these addresses (nor the other ones posted) have

reverse DNS.

...

...

...

I think we should make DNS entries (with callsign) mandatory for all

allocated AMPRnet addresses!

...

...

...

Rob

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

-- _____ _____ |___ |___ / Matt Perkins VK2FLY (advanced) / / |_ \ Woolloomooloo NSW (QF56od) +61403571333 matt@vk2fly.com / / ___) | A pround member of ARNSW, The WIA, /_/ |____/ And the Waverley Amateur Radio Society.

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Until those who are allocated 44.x space are able to manage their own DNS entries, I wouldn't support this.  Once we can self manage (i.e. through the portal system) DNS, then it's a simple matter to keep entries up to date.

On 20/11/21 7:38 pm, Rob PE1CHL via 44Net wrote:

Note that none of these addresses (nor the other ones posted) have reverse DNS. I think we should make DNS entries (with callsign) mandatory for all allocated AMPRnet addresses!

Rob

On 11/19/21 9:01 PM, Ruben ON3RVH via 44Net wrote:

...

Hi Jeremy,

As one of the coordinators for ON land (44.144) I thank you for bringing this to our attention. I will investigate this matter.

Ruben - ON3RVH

---

44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Thanks Chris! Since this message we’ve looked into hotspots further and we’ve found them on the following IP addresses: (sorry for spam!)

44.92.55.234 44.108.10.10 44.108.10.22 44.108.10.34 44.108.10.35 44.108.10.42 44.108.10.43 44.140.47.153 44.140.47.156 44.144.50.2 44.144.50.5 44.144.50.6 44.144.50.7 44.144.50.8 44.144.50.9 44.144.50.10 44.144.50.11 44.144.50.12 44.144.50.13 44.144.50.14 44.144.50.16 44.144.50.17 44.144.50.19 44.144.50.20 44.144.50.21 44.144.50.22 44.144.50.24 44.144.50.25 44.144.50.27 44.144.50.28 44.144.50.29 44.144.50.30 44.144.50.31 44.144.50.32 44.144.50.33 44.144.50.35 44.144.50.44 44.144.50.47 44.144.50.48 44.144.50.49 44.144.50.51 44.144.50.52 44.144.50.53 44.144.50.56 44.144.50.58 44.144.50.59 44.144.50.61 44.144.50.66 44.144.50.67 44.144.50.68 44.144.50.69 44.144.50.70 44.144.50.71 44.144.50.73 44.144.50.78 44.144.50.79 44.144.50.80 44.144.50.81 44.144.50.82 44.144.50.84 44.144.50.85 44.144.50.86 44.144.50.87 44.144.50.88 44.144.50.100 44.144.50.101 44.144.50.102 44.144.50.103 44.144.50.104 44.144.50.105

On 2021-11-19, at 14:14, Chris Smith chris@ardc.net wrote:

Hi Jeremy,

For future reference, please report any issues with potential abuse to abuse@ardc.net mailto:abuse@ardc.net

I will look into this and take appropriate action.

Kind Regards, Chris - G1FEF — ARDC IT Director

Web: https://www.ardc.net https://www.ardc.net/

...

On 19 Nov 2021, at 19:54, Jeremy Cooper via 44Net <44net@mailman.ampr.org mailto:44net@mailman.ampr.org> wrote:

Hi all, I’d like the ARDC to investigate and possibly revoke the assignment for 44.144.50.0/25 due its use for commercial purposes.

I’m a long time member of the group here but I’m also heavily involved in the Helium radio-based blockchain. I’ve noticed three Helium “hotspots” or “miners” that are using this allocation. While I am personally a fan of Helium, I don’t think its use is permissible on the AMPRNet as Helium hotspots do earn monetary compensation for being connected to the Internet. As a responsible AMPR block recipient myself, I feel it’s important that we continue to honor the ARDC’s rules for the AMPR space, and this is one of them.

The hotspots in question are:

• zany-pecan-kitten at 44.144.50.71 (https://explorer.helium.com/hotspots/112en278X7KpSMfgH9JMnEfkfLSsi2osRjJ1mLE... https://explorer.helium.com/hotspots/112en278X7KpSMfgH9JMnEfkfLSsi2osRjJ1mLEC4pd6RKFiGPow)
• petite-flint-bird at 44.144.50.73 (https://explorer.helium.com/hotspots/11bkMgWVDYSteuq1fLvowC9z4BVReQrXNGCq4Fh... https://explorer.helium.com/hotspots/11bkMgWVDYSteuq1fLvowC9z4BVReQrXNGCq4FhKXytzTmWBG9b)
• furry-pine-raccoon at 44.144.50.74 (https://explorer.helium.com/hotspots/112TRAzGUMNvEYEtHawWymZTA4cX9BWu9QFw1vp... https://explorer.helium.com/hotspots/112TRAzGUMNvEYEtHawWymZTA4cX9BWu9QFw1vpicRD6c38c2GYD)

Sincerely, Jeremy Cooper (KE6JJJ) _________________________________________ 44Net mailing list 44Net@mailman.ampr.org mailto:44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

A reply by the ARDC IT director specifically requesting that abuse reports be sent to abuse@ardc.net mailto:abuse@ardc.net and you decide to double down and list more potentially offending addresses publicly?

Interesting approach.

Ian VE7BST

On Nov 19, 2021, at 2:18 PM, Jeremy Cooper via 44Net 44net@mailman.ampr.org wrote:

Thanks Chris! Since this message we’ve looked into hotspots further and we’ve found them on the following IP addresses: (sorry for spam!)

<list of potentially offending addresses snipped>

...

On 2021-11-19, at 14:14, Chris Smith chris@ardc.net wrote:

Hi Jeremy,

For future reference, please report any issues with potential abuse to abuse@ardc.net mailto:abuse@ardc.net

I will look into this and take appropriate action.

Kind Regards, Chris - G1FEF — ARDC IT Director