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.

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

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(a)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 :)

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:

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 &lt;44net(a)mailman.ampr.org&gt; 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(a)mailman.ampr.org&gt; wrote: -- ------------------------------ 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(a)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:

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:

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:

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

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 Tue, 6 Apr 2021, G1FEF via 44Net wrote: 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: 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: 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). 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: * Having *a plan* to /handle/ address space unavailability... is not the same as: * Having *a plan* to /cause/ address space unavailability... 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: Great Pierre, really good to hear about the development of a plan. Hopefully, yes---as a standard/plan that would be inaccessible to the primary userbase/ constituent-stakeholders would be of little benefit. 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 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: Hello Pierre et al, 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). (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. 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. 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. 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. 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...) 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:

@jeff: can you please confirm/infirm that the flag is still there? On 06/04/2021 23:17, Jeff Parrish-Personal via 44Net wrote:

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: