To clarify where something is "AMPRNet" vs "Interent". For example, the code I was going to post was specifically for handing out 44Net addresses for an OpenVPN IP pool. It seems confusing and odd to use the RFC5737 to document something specifically about AMPRNet like that.

-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Alistair Mackenzie via 44Net Sent: Monday, April 5, 2021 2:15 PM To: 44Net general discussion 44net@mailman.ampr.org Cc: Alistair Mackenzie magicsata@gmail.com Subject: Re: [44net] IP Ranges for Documentation

Jason,

Is there any reason that you are opposed to using the RFC5737 space? This seems like exactly the kind of thing the RFC is for.

Thanks, Alistair

On Mon, Apr 5, 2021 at 7:11 PM Jason McCormick via 44Net < 44net@mailman.ampr.org> wrote:

...

Is there an allocation for documentation similar to RFC 5737? I was going to upload some stuff to the GitLab server but I wanted to generalize it so people didn't just copy/paste deploy stuff with my IP allocations in it. I looked on the portal but couldn't find anything. If there isn't, I'd like to propose that two /24s get set aside for documentation out of 44.0.0.0/9 that don't seem ripe for future use such as 44.0.192.0/24 and 44.1.255.0/24.

Jason _________________________________________ 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

Hi Jason,

44.128.0.0/16 is reserved for testing and will never be allocated to anyone, unless we run out of space ;-)

I see no reason why you can’t use addresses from that block.

73, Chris

On 5 Apr 2021, at 19:19, Jason McCormick via 44Net 44net@mailman.ampr.org wrote:

To clarify where something is "AMPRNet" vs "Interent". For example, the code I was going to post was specifically for handing out 44Net addresses for an OpenVPN IP pool. It seems confusing and odd to use the RFC5737 to document something specifically about AMPRNet like that.

...

-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Alistair Mackenzie via 44Net Sent: Monday, April 5, 2021 2:15 PM To: 44Net general discussion 44net@mailman.ampr.org Cc: Alistair Mackenzie magicsata@gmail.com Subject: Re: [44net] IP Ranges for Documentation

Jason,

Is there any reason that you are opposed to using the RFC5737 space? This seems like exactly the kind of thing the RFC is for.

Thanks, Alistair

...

On Mon, Apr 5, 2021 at 7:11 PM Jason McCormick via 44Net < 44net@mailman.ampr.org> wrote:

Is there an allocation for documentation similar to RFC 5737? I was going to upload some stuff to the GitLab server but I wanted to generalize it so people didn't just copy/paste deploy stuff with my IP allocations in it. I looked on the portal but couldn't find anything. If there isn't, I'd like to propose that two /24s get set aside for documentation out of 44.0.0.0/9 that don't seem ripe for future use such as 44.0.192.0/24 and 44.1.255.0/24.

Jason _________________________________________ 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

Hi,

What is your plan for when this prefix ends up coming in to use? There will potentially be networks using this and break reachability elsewhere due to this.

There is also the fact that people often copy documentation exactly and use it which can cause problems. This has been seen with CloudFlare[1] and Cisco's documentation on ERSPAN.

it is not worth the possible problems and clean up operation required by using a prefix outside of RFC5737. This RFC was created to avoid the issues that I have mentioned and we should use it as intended wherever possible, including in AMRP/44net.

[1] https://www.youtube.com/watch?v=ZF_vsSPcMRo

On Mon, Apr 5, 2021 at 7:44 PM G1FEF via 44Net 44net@mailman.ampr.org wrote:

Hi Jason,

44.128.0.0/16 is reserved for testing and will never be allocated to anyone, unless we run out of space ;-)

I see no reason why you can’t use addresses from that block.

73, Chris

...

On 5 Apr 2021, at 19:19, Jason McCormick via 44Net <

44net@mailman.ampr.org> wrote:

...

To clarify where something is "AMPRNet" vs "Interent". For example, the

code I was going to post was specifically for handing out 44Net addresses for an OpenVPN IP pool. It seems confusing and odd to use the RFC5737 to document something specifically about AMPRNet like that.

...

...

-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of Alistair Mackenzie via 44Net Sent: Monday, April 5, 2021 2:15 PM To: 44Net general discussion 44net@mailman.ampr.org Cc: Alistair Mackenzie magicsata@gmail.com Subject: Re: [44net] IP Ranges for Documentation

Jason,

Is there any reason that you are opposed to using the RFC5737 space?

This

...

...

seems like exactly the kind of thing the RFC is for.

Thanks, Alistair

...

On Mon, Apr 5, 2021 at 7:11 PM Jason McCormick via 44Net < 44net@mailman.ampr.org> wrote:

Is there an allocation for documentation similar to RFC 5737? I was going to upload some stuff to the GitLab server but I wanted to generalize it so people didn't just copy/paste deploy stuff with my IP allocations in it. I looked on the portal but couldn't find anything. If there isn't, I'd like to propose that two /24s get set aside for documentation out of 44.0.0.0/9 that don't seem ripe for future use such as 44.0.192.0/24 and 44.1.255.0/24.

Jason _________________________________________ 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

I’ve seen a company that had problems with people copy pasting blindly and not changing the settings use something equivalent to 44.256.0.0. Since 256 is not valid, it could break, and you’d go back and see you needed to replace something. Interesting solution that was guaranteed to work :)

On 5 Apr 2021, at 21:40, Jason McCormick via 44Net 44net@mailman.ampr.org wrote:

RFC5737 doesn't support this use case which is why I asked in the first place about a dedicated documentation block to begin with.

The point of having a 44Net documentation block is so that it's painfully obvious that "YOUR ALLOCATION GOES HERE". The point of posting stuff on the GitLab server and hopefully other places is precisely to "copy documentation" and use it. Yes, there will always be those people who literally apply no thought to cutting-and-pasting in something but we can't do anything about that. My interest is having configuration that someone CAN literally copy/paste, make some very minor tweaks, and get their system running. Using a random RFC5737 address block which likely most people have never heard of isn't going to be helpful in reducing the learning curve and confusion.

However using the test space probably makes sense since that is the literal allocation titles of RFC5737 are TEST-NET-1, -2, and -3.

For what it's worth, I will be using 44.128.50.0/24 for my stuff.

Jason

The 44.128.0.0/16 block, by definition, will never be forwarded, announced or allocated.

There will never be someone using it later, outside the scope of a non-connected testing environment.

Why isn't that good enough?

To get more confusion to the less technical people not being able to distinguish between a potential valid RFC 5737 address in their own private address space and a 44net address?

BTW, 10.0.0.0/8 addresses are quite often used by providers for their infrastructure, so randomly playing around with them could actually trigger side effects that are very hard to track down, especially for some (I have as an example 2 providers, both have their PPPoE endpoint in the 10/8 space).

I would really go with the 44.128.0.0/16 (as I did in all my examples related to my code - it will just not work if they do not update it correctly).

Marius, YO2LOJ

On 05/04/2021 23:07, K7VE - John via 44Net wrote:

This is why I suggested the 10.44.x.x and 192.168.44.x blocks -- the '*44*' is a consistent clue for documentation, and yet would not be routable beyond the LAN if copied.

This may be a topic for the TAC

On Mon, Apr 5, 2021 at 12:45 PM Antonios Chariton (daknob) via 44Net < 44net@mailman.ampr.org> wrote:

...

I’ve seen a company that had problems with people copy pasting blindly and not changing the settings use something equivalent to 44.256.0.0. Since 256 is not valid, it could break, and you’d go back and see you needed to replace something. Interesting solution that was guaranteed to work :)

...

On 5 Apr 2021, at 21:40, Jason McCormick via 44Net <

44net@mailman.ampr.org> wrote:

...

RFC5737 doesn't support this use case which is why I asked in the first

place about a dedicated documentation block to begin with.

...

The point of having a 44Net documentation block is so that it's

painfully obvious that "YOUR ALLOCATION GOES HERE". The point of posting stuff on the GitLab server and hopefully other places is precisely to "copy documentation" and use it. Yes, there will always be those people who literally apply no thought to cutting-and-pasting in something but we can't do anything about that. My interest is having configuration that someone CAN literally copy/paste, make some very minor tweaks, and get their system running. Using a random RFC5737 address block which likely most people have never heard of isn't going to be helpful in reducing the learning curve and confusion.

...

However using the test space probably makes sense since that is the

literal allocation titles of RFC5737 are TEST-NET-1, -2, and -3.

...

For what it's worth, I will be using 44.128.50.0/24 for my stuff.

Jason

---

John D. Hays - K7VE Kingston, WA http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

Yep - 44.128.0.0/10 is announced by AS7377

?

Charlie

On Monday, April 5, 2021, 10:26:55 PM GMT+1, K7VE - John via 44Net 44net@mailman.ampr.org wrote:

root@vpn:/var/www/html# traceroute 44.128.0.1 traceroute to 44.128.0.1 (44.128.0.1), 30 hops max, 60 byte packets 1  10.0.0.49 (10.0.0.49)  0.297 ms  0.292 ms  0.322 ms 2  six.core1.sea1.fiberhub.net (206.81.80.229)  4.665 ms  4.681 ms  4.666 ms 3  129.250.199.57 (129.250.199.57)  5.645 ms  5.636 ms  5.619 ms 4  ae-14.r25.sttlwa01.us.bb.gin.ntt.net (129.250.5.133)  6.014 ms ae-8.r24.sttlwa01.us.bb.gin.ntt.net (129.250.5.117)  5.820 ms ae-14.r25.sttlwa01.us.bb.gin.ntt.net (129.250.5.133)  5.807 ms 5  ae-1.a03.sttlwa01.us.bb.gin.ntt.net (129.250.2.207)  5.150 ms ae-0.a03.sttlwa01.us.bb.gin.ntt.net (129.250.2.99)  5.165 ms  5.154 ms 6  ae-0.level3.sttlwa01.us.bb.gin.ntt.net (129.250.9.181)  5.118 ms  5.507 ms  5.508 ms 7  * * * 8  CENIC.ear1.SanJose1.Level3.net (4.15.122.46)  18.255 ms  18.277 ms 18.303 ms 9  dc-svl-agg8--svl-agg10-300g.cenic.net (137.164.11.81)  27.314 ms 27.300 ms  26.575 ms 10  dc-lax-agg8--svl-agg8-100ge-1.cenic.net (137.164.11.0)  27.999 ms lax-agg8--svl-agg8-100g-3.cenic.net (137.164.11.66)  28.031 ms dc-lax-agg8--svl-agg8-100ge-1.cenic.net (137.164.11.0)  28.082 ms 11  dc-tus-agg8--lax-agg8-300g.cenic.net (137.164.11.83)  27.978 ms  27.969 ms  28.123 ms 12  dc-sdg-agg4--tus-agg8-300g.cenic.net (137.164.11.85)  28.347 ms  28.392 ms  28.270 ms 13  dc-ucsd-100ge--sdg-agg4.cenic.net (137.164.23.177)  28.201 ms  28.227 ms  28.053 ms

*14  nodem-core-6807-vlan2767-gw.ucsd.edu http://nodem-core-6807-vlan2767-gw.ucsd.edu (132.239.254.61)  28.251 ms 28.397 ms  28.198 ms15  sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu http://sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu (132.239.255.50)  28.860 ms 28.583 ms  29.149 ms* 16  * * * 17  * * * 18  * * * 19  * * * 20  * * * 21  * * * 22  * * * 23  * * * 24  * * * 25  * * * 26  * * * 27  * * * 28  * * * 29  * * * 30  * * *

On Mon, Apr 5, 2021 at 2:18 PM Marius Petrescu via 44Net < 44net@mailman.ampr.org> wrote:

The 44.128.0.0/16 block, by definition, will never be forwarded, announced or allocated.

There will never be someone using it later, outside the scope of a non-connected testing environment.

Why isn't that good enough?

To get more confusion to the less technical people not being able to distinguish between a potential valid RFC 5737 address in their own private address space and a 44net address?

BTW, 10.0.0.0/8 addresses are quite often used by providers for their infrastructure, so randomly playing around with them could actually trigger side effects that are very hard to track down, especially for some (I have as an example 2 providers, both have their PPPoE endpoint in the 10/8 space).

I would really go with the 44.128.0.0/16 (as I did in all my examples related to my code - it will just not work if they do not update it correctly).

Marius, YO2LOJ

On 05/04/2021 23:07, K7VE - John via 44Net wrote:

...

This is why I suggested the 10.44.x.x and 192.168.44.x blocks -- the

'*44*'

...

is a consistent clue for documentation, and yet would not be routable beyond the LAN if copied.

This may be a topic for the TAC

On Mon, Apr 5, 2021 at 12:45 PM Antonios Chariton (daknob) via 44Net < 44net@mailman.ampr.org> wrote:

...

I’ve seen a company that had problems with people copy pasting blindly

and

...

...

not changing the settings use something equivalent to 44.256.0.0. Since

256

...

...

is not valid, it could break, and you’d go back and see you needed to replace something. Interesting solution that was guaranteed to work :)

...

On 5 Apr 2021, at 21:40, Jason McCormick via 44Net <

44net@mailman.ampr.org> wrote:

...

RFC5737 doesn't support this use case which is why I asked in the first

place about a dedicated documentation block to begin with.

...

The point of having a 44Net documentation block is so that it's

painfully obvious that "YOUR ALLOCATION GOES HERE". The point of posting stuff on the GitLab server and hopefully other places is precisely to

"copy

...

...

documentation" and use it. Yes, there will always be those people who literally apply no thought to cutting-and-pasting in something but we

can't

...

...

do anything about that. My interest is having configuration that someone CAN literally copy/paste, make some very minor tweaks, and get their

system

...

...

running. Using a random RFC5737 address block which likely most people

have

...

...

never heard of isn't going to be helpful in reducing the learning curve

and

...

...

confusion.

...

However using the test space probably makes sense since that is the

literal allocation titles of RFC5737 are TEST-NET-1, -2, and -3.

...

For what it's worth, I will be using 44.128.50.0/24 for my stuff.

Jason

---

John D. Hays - K7VE Kingston, WA http://k7ve.org/blog  http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 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

So? It reaches ucsd.edu as per the 44.128.0.0/10 public BGP route (as expected) and gets dropped. In the tunnel RIP messages it will never get announced, so there is no impact on another possible system using it.

No harm done and I do not see a problem with this.

On 06/04/2021 00:26, K7VE - John via 44Net wrote:

root@vpn:/var/www/html# traceroute 44.128.0.1 traceroute to 44.128.0.1 (44.128.0.1), 30 hops max, 60 byte packets 1 10.0.0.49 (10.0.0.49) 0.297 ms 0.292 ms 0.322 ms 2 six.core1.sea1.fiberhub.net (206.81.80.229) 4.665 ms 4.681 ms 4.666 ms 3 129.250.199.57 (129.250.199.57) 5.645 ms 5.636 ms 5.619 ms 4 ae-14.r25.sttlwa01.us.bb.gin.ntt.net (129.250.5.133) 6.014 ms ae-8.r24.sttlwa01.us.bb.gin.ntt.net (129.250.5.117) 5.820 ms ae-14.r25.sttlwa01.us.bb.gin.ntt.net (129.250.5.133) 5.807 ms 5 ae-1.a03.sttlwa01.us.bb.gin.ntt.net (129.250.2.207) 5.150 ms ae-0.a03.sttlwa01.us.bb.gin.ntt.net (129.250.2.99) 5.165 ms 5.154 ms 6 ae-0.level3.sttlwa01.us.bb.gin.ntt.net (129.250.9.181) 5.118 ms 5.507 ms 5.508 ms 7 * * * 8 CENIC.ear1.SanJose1.Level3.net (4.15.122.46) 18.255 ms 18.277 ms 18.303 ms 9 dc-svl-agg8--svl-agg10-300g.cenic.net (137.164.11.81) 27.314 ms 27.300 ms 26.575 ms 10 dc-lax-agg8--svl-agg8-100ge-1.cenic.net (137.164.11.0) 27.999 ms lax-agg8--svl-agg8-100g-3.cenic.net (137.164.11.66) 28.031 ms dc-lax-agg8--svl-agg8-100ge-1.cenic.net (137.164.11.0) 28.082 ms 11 dc-tus-agg8--lax-agg8-300g.cenic.net (137.164.11.83) 27.978 ms 27.969 ms 28.123 ms 12 dc-sdg-agg4--tus-agg8-300g.cenic.net (137.164.11.85) 28.347 ms 28.392 ms 28.270 ms 13 dc-ucsd-100ge--sdg-agg4.cenic.net (137.164.23.177) 28.201 ms 28.227 ms 28.053 ms

*14 nodem-core-6807-vlan2767-gw.ucsd.edu http://nodem-core-6807-vlan2767-gw.ucsd.edu (132.239.254.61) 28.251 ms 28.397 ms 28.198 ms15 sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu http://sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu (132.239.255.50) 28.860 ms 28.583 ms 29.149 ms* 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *

On Mon, Apr 5, 2021 at 2:18 PM Marius Petrescu via 44Net < 44net@mailman.ampr.org> wrote:

...

The 44.128.0.0/16 block, by definition, will never be forwarded, announced or allocated.

There will never be someone using it later, outside the scope of a non-connected testing environment.

Why isn't that good enough?

To get more confusion to the less technical people not being able to distinguish between a potential valid RFC 5737 address in their own private address space and a 44net address?

BTW, 10.0.0.0/8 addresses are quite often used by providers for their infrastructure, so randomly playing around with them could actually trigger side effects that are very hard to track down, especially for some (I have as an example 2 providers, both have their PPPoE endpoint in the 10/8 space).

I would really go with the 44.128.0.0/16 (as I did in all my examples related to my code - it will just not work if they do not update it correctly).

Marius, YO2LOJ

On 05/04/2021 23:07, K7VE - John via 44Net wrote:

...

This is why I suggested the 10.44.x.x and 192.168.44.x blocks -- the

'*44*'

...

is a consistent clue for documentation, and yet would not be routable beyond the LAN if copied.

This may be a topic for the TAC

On Mon, Apr 5, 2021 at 12:45 PM Antonios Chariton (daknob) via 44Net < 44net@mailman.ampr.org> wrote:

...

I’ve seen a company that had problems with people copy pasting blindly

and

...

...

not changing the settings use something equivalent to 44.256.0.0. Since

256

...

...

is not valid, it could break, and you’d go back and see you needed to replace something. Interesting solution that was guaranteed to work :)

...

On 5 Apr 2021, at 21:40, Jason McCormick via 44Net <

44net@mailman.ampr.org> wrote:

...

RFC5737 doesn't support this use case which is why I asked in the first

place about a dedicated documentation block to begin with.

...

The point of having a 44Net documentation block is so that it's

painfully obvious that "YOUR ALLOCATION GOES HERE". The point of posting stuff on the GitLab server and hopefully other places is precisely to

"copy

...

...

documentation" and use it. Yes, there will always be those people who literally apply no thought to cutting-and-pasting in something but we

can't

...

...

do anything about that. My interest is having configuration that someone CAN literally copy/paste, make some very minor tweaks, and get their

system

...

...

running. Using a random RFC5737 address block which likely most people

have

...

...

never heard of isn't going to be helpful in reducing the learning curve

and

...

...

confusion.

...

However using the test space probably makes sense since that is the

literal allocation titles of RFC5737 are TEST-NET-1, -2, and -3.

...

For what it's worth, I will be using 44.128.50.0/24 for my stuff.

Jason

---

John D. Hays - K7VE Kingston, WA http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 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

Of course, the 100% correct approach would be to return a network unreachable message, but let's not touch a working system and not offer more information than needed on IP scans.

Marius, YO2LOJ

On 06/04/2021 00:54, Marius Petrescu via 44Net wrote:

BTW, any unknown/unallocated 44 subnet will take that exactly same route and have the same faith: If it is not registered in the DNS, it will be dropped by ampr-gw.

On 06/04/2021 00:51, Marius Petrescu via 44Net wrote:

...

So? It reaches ucsd.edu as per the 44.128.0.0/10 public BGP route (as expected) and gets dropped. In the tunnel RIP messages it will never get announced, so there is no impact on another possible system using it.

No harm done and I do not see a problem with this.

---

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

I think the purpose of such "for documentation" subnets is that you can give some really valid examples of configuration, where e.g. the user has got a /29 subnet and you want to explain what is the network address, the address of the gateway (router), the subnet broadcast address, and the usable addresses in the network.

Sure you can use things like 44.xx.xx.xx 44.xx.xx.xx+1 etc but usually you will have lost the non-technical reader and it is much better to give examples with real addresses that only have to be adapted to the assigned subnet.

44.128.0.0/16 has been a test subnet for a long time, and there even is romoured use of that range outside AMPRnet as a "test network" or "local range" (similar to RFC1918) due to misunderstanding.  I think it would be the last network to ever use when we would ever run out of address space.  No need to worry about people having it in their configuration by then, they would have noticed their mistake long before. (44.128.0.0/16 has been in our bogon list of non-routed addresses ever since we established our gateway here in the Netherlands, together with RFC1918, RFC6598, IANA reserved nets)

Rob

On 4/6/21 12:04 AM, Cory (NQ1E) via 44Net wrote:

Ideally you wouldn't use properly formatted IP addresses at all when checking in your code unless they were meant to be used. You could instead use something like: 44.xx.xx.xx

A perfectly reasonable exception to that is if you need your code to pass automated tests that require a properly formatted value to exist there. In that case, using 44net's testing subnet seems not only appropriate, but ideal. ;) _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

This may not be a good idea if it stops being one in the future. And it’s test, not documentation technically..

I also recommend the RFC space, it’s designed for exactly these situations, and if there’s not enough (you need more /24 networks), then the 10.44 or the 192.168.44 idea isn’t that bad either.

Antonis

On 5 Apr 2021, at 20:34, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote:

I think 44.128.0.0/16 is still reserved as a test network and it would be possible to use subnets from there for documentation purposes.

Rob

My reply was sent before Chris’ but needed moderation. Since he knows much more on the topic, I trust his answer more than mine ;)

On 5 Apr 2021, at 21:28, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote:

It would not be 44Net if there would not always be some people who claim "it is not a good idea"....

Rob

On 4/5/21 8:39 PM, Antonios Chariton (daknob) via 44Net wrote:

...

This may not be a good idea if it stops being one in the future. And it’s test, not documentation technically..

---

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

On Tue, 6 Apr 2021, G1FEF via 44Net wrote:

Ok, to avoid any confusion Jann (chair of the TAC) and I have

Chris, Jann:

It would make *vastly* more sense to reserve eg.

44.123/16

(a) This is "obviously" (44.123.45.67) an example range.

(b) Allows for 44.128/9 suddenly getting sold.

Again, a little priro *open discussion* would solve most of these types of situations.

-Paul

On Tue, 6 Apr 2021, G1FEF via 44Net wrote:

...

(b) Allows for 44.128/9 suddenly getting sold.

It's 44.128/10 and that is not going to happen.

Chris:

1. 44.192/10 was sold---(and Jann is heavily involved with the largest former user of 44.192/10; ...aside from UCSD Telescope).

2. 44.128/10 (the remainder of the non-FCC/non-US block) would be the next logical block to be divested. [Whether or not that happens is orthogonal, it is the next logical block].

3. 44.128/10 + 44.192/10 = 44.128/9.

It makes little sense to put reserved/documentation ranges in 44.128/9.

-Paul

On Tue, 6 Apr 2021, pete M wrote:

Paul I don't think there is a plan

Not having a plan seems a like a technical oversight:-

1. Ideally there *should* be a plan on how to handle migration/active address space becoming ... unavailable (even if the plan is not enacted).

2. Likewise for the reflector transit/Network Telescope arrangement at UCSD becoming ... unavailable (even if the plan is not enacted).

In fact we the plan that the TAC works on include all the ip space AMPR have. None will be left aside or sold.

Great, but planning for 100% utilisation of an assest does little for risk management. Results in no moving space.

-Paul

On Tue, 6 Apr 2021, pete M wrote:

...

1. Ideally there *should* be a plan

You want to plan the selling of some ip space?

* Having *a plan* to /handle/ address space unavailability...

is not the same as:

* Having *a plan* to /cause/ address space unavailability...

I find this pretty odd.

It is risk management, learning from a previous documented incident that caused outage and disruption.

Ditto for:

* Having *a plan* to /handle/ outage of the CAIDA switch.

is not the same as:

* Having *a plan* to /cause/ outage of the CAIDA switch.

Likewise, there is opportunity to learning from previous (semi-) documented incidents that caused outage and disruption.

-Paul

On Wed, 7 Apr 2021, pete M wrote:

well there is a plan to manage the ip space that is into development.

Great Pierre, really good to hear about the development of a plan.

I am sure it will be available to all, after the TAC present it to the board of direction of ARDC and it being accepted.

Hopefully, yes---as a standard/plan that would be inaccessible to the primary userbase/ constituent-stakeholders would be of little benefit.

Presenting it here right now would not be very efficient as it can and will surely change till its final form.

Hopefully, that final form is not /the/ final form, but an opportunity for following rounds of [iteration + feedback + improvement]. (ie. avoiding the classic "v7, Final Draft, really - updated - 2".)

Chris has now setup Git for all, perhaps it would be worth keeping all the documentation there, so that everything is in one place, and things don't get lost/overlooked in future:

https://git.ampr.org/explore

And no, we wont talk about it here as it is a work in progress.

Seems like a missed opportunity to gain from the benefits of collaborative iteration, feedback, and sharing---the very spirit of Ham + open source + internet, where AMPRnet sits at the junction of.

73s, and living in hope,

-Paul

On Wed, 7 Apr 2021, pete M wrote:

...

...

And no, we wont talk about it here as it is a work in progress.

Seems like a missed opportunity to gain from the benefits of collaborative iteration, feedback, and sharing---the very spirit of Ham + open source + internet, where AMPRnet sits at the junction of.

Hello Pierre et al,

And it will be discussed here, but not before it will be more structured and close to its final form.

Hope so...: tomorrow, 2021-05-01 is T+2 years since 44.192/10 went.

...and 2021 is T+20 years since CAIDA published the Code Red data-analysis produced from the 2001-era 44/8 Amprnet logging.

That is 18 years of keeping one's mouth shut, participating in an "open secret" because the published research was good and useful---and politely ignoring the Miltech/DARPA/etc funding for development of large-scale automated capture + tapping infrastructure, occuring in the process, on HAM allocations.

That changed in mid-2019 with the (*apparently unanimous) decision of the three directors [all associated with UCSD/CAIDA]---removing a quarter of the monitored blackhole space (44.192/10), through enabling and allowing a sale to proceed.

Hence, my interpretion of that action (rightly or wrongly) was as implying that the primary research activities were substantially complete---and so no further need to participate in sustaining an open secret still unknown by many (including TAC members of the time).

Hence:

https://en.wikipedia.org/wiki/AMPRNet#UCSD_Network_Telescope

(Again, an open secret ... the research papers and slashdot commentary have been published for years---it's all cited with quotes and links to the biblography to assist others in their own reading).

The Tecnical Advisory Commitee (TAC) been created for such task. It is a nice working commitee that works on such project.

(To the best of my knowledge) members of the TAC were under-informed of the plans for 44.192/10 beforehand two years ago---leading to the corresponding technial breakage because of the lack of opportunity for meaningful input. And...

(To the best of my knowledge) members of the TAC remain (today) under-informed, not being proactively informed of the contractual arrangements with UCSD for on-going data-collection/colocation---or even the existence and timeline of those arrangements. ;-)

There seems little point scheming up ideas behind closed doors, whilst being simulataneously behind another closed door.

Maybe you can apply to work on it at the next opening?

Thank you for the thought----the TAC has [already] just recently gained a new chair, to try and pull things together; so there is the opportunity to transition to being meaningful open---but that requires buy-in from everyone.

My standing offer, remains to help assist in organising/filtering/curating the information already available, in order to provide a foundation for others (TAC, Hams, Directors, Employees, ...) to discussion and work effectively.

We can review:

https://git.ampr.org/explore

Not a single eg. board minute has been published, so far.

Not a single like of ARDC-funded portal code has been pushed, so far.

Should that situation change, you are welcome to re-approach me! ...IMHO, at the moment it is a more effective contribution to provide encouragement from the sidelines.

It would be kind of counterproductive to have a commitee and then have everyone commenting on a project,

Might be worth a try :-)

You don't know until you've done it, and it's highly likely that TAC may learn a thing-or-two about Amprnet in the process.

Of course some people wont be happy, there is always someone, don't ask why I know ;-)

Please share openly and tell us more... particularly so when excouraging others to sign up for roles within Ampr/ARDC/TAC it would be great to hear what's going on. At the moment it's the usual deafening radio silence.

But with planification, and change, the futur of the whole adress space will be taken into account and the plan does not account for selling any part of it,

Based on two years ago---TAC had/have _zero_ control over whether any address space is sold. What the TAC /could/ do, would be to be plan for how address migrations/realloc()ations should happen in response to such events.

(...If a plan cannot cope with sudden address space resizing/ dynamically adjusting (larger or smaller), then the plan is probably flawed...)

Keep watching here, when it will be more finish every one will see it.

We do, keep watching. CQ? CQ? CQ?

-Paul

Could we all just ignore this thread?

I don't think that there is so much documentation available that it poses a serious problem...

On 06/04/2021 21:41, Rob PE1CHL via 44Net wrote:

Can we please be a bit more reasonable?  It is a minor issue, nobody can look 25 years in the future, and we have more important work at hand than quibbling over some documentation address.

Why always the negativity?  Whenever something is proposed on this list, there always are several people who consider it a bad idea.  It demotivates people to propose or work on something.  And it is also one of the reasons why discussions about new things to do invariably end without accomplishing anything.

Rob

@jeff: can you please confirm/infirm that the flag is still there?

On 06/04/2021 23:17, Jeff Parrish-Personal via 44Net wrote:

73, Jeff Parrish - KB9GXK

Chris, what's the use of this? Now, instead of one invalid subnet (44.128.0.0/16) that we should ignore, we get three of them?

The new "documentation" subnet has exactly the same issues like the ones described for the initial one, nothing is solved.

Worse, one can not even exemplify a simple clearly visible /16 /24 sub-netting with clear numbers using 44.128.252.0/22, for people to understand netmasks.

And all of this just because some worry the address space will run out sometimes in the future, so we get to subnet it further? C'mon...

Either choose one OUTSIDE the address space, or leave it as it is.

In the mean time: Everybody please update your RIP filters to include 44.128.252.0/22 as well. And your blackhole routes too. Oh, and some scripts and daemons maybe....

Yes, and instead of one iptables rule, you need 3 of them.

At least make it half/half: 44.128.0.0/17 for documentation, 44.128.128.0/17 for those worrying data could show up in some readme and magically trash their tests.

Marius, YO2LOJ

On 06/04/2021 20:26, G1FEF via 44Net wrote:

Ok, to avoid any confusion Jann (chair of the TAC) and I have had a chat about this today. We agreed that it would make sense to reserve a small part of the address space specifically for documentation relating to 44net. I have updated the Portal to reflect this:

44.128.0.0/17 This is reserved for testing. Anyone may use this address space for private testing purposes, it will never be allocated to anyone, it will never be advertised on the Internet at large.

44.128.128.0/17 This is reserved for future testing. It also will never be allocated to anyone, nor will it ever be advertised on the Internet. Within this address space we have allocated:

44.128.252.0/22 This is reserved specifically for documentation.

Anyone implementing filtering may safely route 44.128.0.0/16 to /dev/null

73, Chris

---

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