In our local network we have several different kinds of tunnels, with
different header overhead.
As the usual MTU on an internet connection is 1500 (the ethernet MTU),
the typical MTU
for an IPIP tunnel is 1480, for GRE it is 1476, for GRE6 it is 1454, etc.
However, not everyone has a 1500 byte internet MTU. Some people have
PPPoE connections
to internet with MTU of typically 1492, sometimes 1480. So the
effective MTU of the
mentioned (and other) tunnel types becomes 8 or 20 bytes less. Some
people get a fixed address
subnet from their ISP and it is provided as some tunnel with an MTU of
1456 (quite common here).
This results in a wide variety of MTU values in our network.
Frequently issues arise for new connections where the chosen MTU for
some tunnel turns
out to be too large, and full-size packets are dropped. And in an
environment where those
tunneled packets encounter a point where the outer packet is too large
for the interface MTU,
the usual mechanism of returning "ICMP destination unreachable,
fragmentation required"
does not work very well, because the ICMP is returned to the router that
encapsulated the
packet, not the original source of the traffic. And I have never seen
an encapsulating router
that translated the ICMP to a new ICMP packet referring to the inner
addresses and sent it
back to the original source.
Also, there are sometimes issues when routes are changed by BGP. Of
course many routers
have TCP MSS clamping configured where the TCP MSS is reduced whenever
the TCP SYN
passes through a place with lower MTU, but this happens only on the
initial connection setup.
When the MTU later reduces due to a route change, this still results in
failure of the connection.
I wonder if other gateway operators have done something to alleviate
this problem.
Solutions that can be considered:
- ignore DF. much of the current TCP traffic has DF (don't fragment)
set, but this often causes
communications to unnecessarily break. Without DF, packets would be
fragmented as originally
designed in the IP protocol. sending everything with DF and
interpreting the ICMP responses
is the mechanism behind "Path MTU discovery", which was designed to
avoid fragmentation
and the overhead it causes in routers. however, in the AMPRnet we
seldomly encounter
so much traffic that CPU loading of the routers is an issue.
- standardize on a "default MTU" whenever we cannot offer a 1500 byte
MTU. this does
not solve all problems, but at least it solves some of them.
Note that most routers fragment packets in a particularly inefficient
way. When a packet
a few bytes too large for the next hop has to be forwarded (and DF is
not set), they will not
split the packet in two approximately equal halves, but rather they send
a first fragment as
large as the outgoing MTU can accept, then a small fragment with the
remainder of the
original packet. This can result in multiple fragmentations along the
way: first it has to be
fragmented to fit into a 1480 byte MTU of an IPIP tunnel, then further
on it has to be
fragmented again to fit a GRE or L2TP/IPsec tunnel with smaller MTU.
Whereas no
further fragmentation would be required when it had been split in equal
halves the first time.
So, I wonder what others do (if anything) to avoid the problems caused
by oversized packets
and maybe to avoid fragmentation. For some time, I have experimented
with "ignore DF"
and of course it keeps traffic flowing, but it is unclear if it causes
problems for some users.
Next I would consider to use a standard MTU value on all tunnels, so
there are mostly two
MTU values left in the network: 1500 and that smaller, to be determined,
value.
Of course the MTU should not be so low that it causes terrible
overhead. In the past we had
a 256 byte MTU on AX.25 packet radio (or even 216 when it was over
NET/ROM), but that
causes a 15% header overhead and made us very unpopular amongst plain
AX.25 users.
Fortunately the WiFi links we use today allow 1500 byte packets :-)
The minimal required MTU for IPv6 is 1280. The maximal MTU we can
accomodate with
the worst case tunnel headers is about 1400. So the preferable default
MTU would be
somewhere between 1280 and 1400.
Are people even using 256-byte MTU links today? Would it be worth it to
select an MTU
value that can be more efficiently fragmented into 256-byte packets? Or
is there another
small MTU size that would be a candidate for such considerations?
So again, I wonder what others have done w.r.t. this matter. Are admins
of gateways that
offer many kinds of different tunnels using a standard MTU in their
systems, or just
the max MTU that each tunnel technology allows?
Do you copy DF from the inner to the outer packet in a tunnel? Do you
ignore DF?
What would be your position on establishing a standard MTU for tunnels,
and what size
would you propose?
Rob PE1CHL
All,
I have a question to ponder again. In preparation for emergencies, I wanted to consider some of the following.
- Passing traffic thru another GW, we can use the test/example subnet
- If AMPRGW at USCD is unreachable, could we have other capable devices that elect between themselves and announce the routes from Chris' server?
- Can we test the redundancy of Chris' route server from whom they elect and receive
- I'm not sure if anyone is doing AX.25 to IP or vice versa; but I would like to try
- I'm curious if anyone has compiled kissattach and all utilities compiled; etc. in OpenWrt to connect a TNC and radio - I want to do an end-to-end test (I recall someone offered me a makefile for some libraries) - I want to migrate my base APRS radio to the router. I recall I have libax25 compiled...
73,
- Lynwood
KB3VWG
All,
I think there's big confusion here between what's called in the industry "Settlement Free Peering" and "paid transit services."
Comcast offers "Ethernet Dedicated Internet" service in my area (Washington, DC). They offer: Static IPs, DHCP and a BGP session. In this service, Comcast will not allow the user to BGP to a third party with the intention to use Comcast for carrying the 3rd party's traffic. This is simply called "paid transit service". When we refer to getting a BGP session with another AS for AMPRNet, look for "BGP transit service" plans.
Peering would be considered traffic between Comcast and another large ISP (i.e. the peering agreement would be relevant if e.g. USCD - AS7377, wanted to peer with Comcast). That's called [settlement free] peering (in a Tier 1 ISP's terminiolgy).
About the product: https://business.comcast.com/enterprise/products-services/data-networking/e…
For a list of cities with the product: https://business.comcast.com/enterprise/products-services/data-networking/m…
73,
- Lynwood
KB3VWG
I replied to you from my gmail address
Bob
On 2020-02-24 17:27, G1FEF via 44Net wrote:
Bob, nothing received from you. I have sent you an email, please reply
to if or let me know here if you don't receive it.
Regards,
Chris
Chris,
I wrote you an email from my address as listed in the portal.
Hopefully you received it this time.
Bob
On 2020-02-24 07:24, G1FEF via 44Net wrote:
Hi Bob,
On 24 Feb 2020, at 12:14, Bob Tenty via 44Net <44net(a)mailman.ampr.org> wrote:
Chris,
Sorry to write you in this way but I tried to reach you since the end of
October of last year with
emails without any reply. Also an email from the portal itself received no
reply
Please email me here: chris(a)g1fef.co.uk that should reach me.
Thanks,
Chris
Chris,
Sorry to write you in this way but I tried to reach you since the end of
October of last year with
emails without any reply. Also an email from the portal itself received no
reply
I need the follow change.
I route and have an entry for the subnet 44.135.92.0/24
Ron, VE3CGR wants to route the 44.135.92.8/29 part himself. He is
registered in the portal.
Can you add 44.135.92.8/29 to this entry? Please leave the rest of my
44.135.92.0/24 subnet intact.
Many thanks,
Bob (Boudewijn) VE3TOK
-- There is nothing permanent except change Heraclitus
Good evening.
I am looking for someone who would be an expert in BGP and using Comcast
for the transport.
Please contact me off list. I have some questions I'm looking to get
answered.
Thank you,
William Lewis / KG6BAJ
wlewis(a)myhostingsource.com
*
------------------------------------------------------------------------
*
This message is for the designated recipient only and MAY CONTAIN
PRIVILEGED OR CONFIDENTIAL INFORMATION.
If you have received it in error, please notify the sender immediately
and delete the original.
Any other use of this E-mail is prohibited.
Wm Lewis
Quan Zhou via 44Net <44net(a)mailman.ampr.org> wrote:
> Hi all,
> Sorry to bother you with a rant, but I'm feeling an urge to ask that what's happening on the AMPR/ARDC.
Thank you for your rant.
> ## Background
> A few weeks ago I have received a harsh email from Chris G1FEF accusing me for announcing a prefix was assigned to me. In that case, the claimed reason is that the prefix wasn't listed on the AMPR portal.
> I tried to clear things up by sending him the LOA from WB6CYT, which he claims that is NOT legitimate, also denied possibility there could a bug in the portal caused this. I have also complied with his demands on even more information including all conversations between me and Brian regarding that the assignment. Eventually he continued to ask for even more personal information without justification, threatening that not complying may cause "close of account".
> ## Questions
> 1. Has all previous assignment by WB6CYT been overruled? Or am I singled out?
Previous assignments by Brian (WB6CYT) have not generally been overruled.
Brian took very seriously his duty to both make space available to real
amateur radio operations and to deny space to opportunists trying to poach
the space for commercial, personal, spam/malware or other purposes.
Many people requested assignments, and most of them received
assignments. Those assignments are and were recorded in the ARDC
portal, which was initially programmed by Chris (G1FEF), and operated and
evolved by both Brian and Chris. The data in it was supplied by
Brian, by net44 users who register to receive allocations, and by the
volunteer regional coordinators who make allocations.
Any collection of detailed allocations too complicated to fit in one
person's memory or on the back of an envelope needs a definitive register
that provides the collective memory of all the past decisions. The portal
was and remains that definitive register.
If your allocation is not in that register, then we'd need to figure out
why it isn't. The ARDC Board has access to some of Brian's stored
email, as well as backup dumps of the Portal databases, so we can do
some searching among those if needed. So far, your rant did not mention
the particular IP address allocations involved, so we have had little
information to start from.
Most allocations are made via country-based and region-based volunteer
coordinators, who all have portal accounts with permission to make
sub-allocations in their region; Brian did not have to adjudicate most
of these.
Apparently your allocation is from the China subnet, and apparently
Brian was still handling those allocations. My guess is that he did not
have a volunteer coordinator for China who both had sufficient
experience and that Brian trusted to do the job well.
> 2. What are the current rules on allocation now? A snapshot of the latest version of ToS is at: https://web.archive.org/web/20190731094938/https://www.ampr.org/terms-of-se… -- It does not requires personal information beyond ASN addresses.
The current rules on allocation have not changed. However, Brian is
no longer with us to make decisions based on years of expertise. So
anyone who would take over that job will make a number of mistakes as
they gain similar expertise. Some of those mistakes will be in
allocating addresses to requesters who don't deserve them. Some of
the mistakes will be in denying addresses to requesters who do deserve
them, or in demanding more scrutiny than is warranted when requests
are made.
An allocation of 768 IP addresses, such as yours, which has considerable
monetary value if used commercially, will naturally get more scrutiny
than a typical request for a /29 that only has 8 addresses and can't be
routed via BGP.
The Chinese agency that licenses amateur radio operators, the State
Radio Regulation of China (http://www.srrc.org.cn) does not appear to
provide an English-language portal for looking up amateur radio
licenses. This currently makes it a more manual process to verify the
license status of Chinese hams. See:
https://en.wikipedia.org/wiki/Amateur_radio_licensing_in_China
(I hope some 44net users from Asia will improve that Wikipedia page,
which is still mostly a stub page.)
> 3. What is G1FEF's role in the allocation, which are the rights that ARDC holds has been delegated to this guy along.
G1FEF has been informally trying to continue providing service to
amateurs while the ARDC board and other volunteers scramble to pick up
the work that Brian was doing during his lifetime.
ARDC and G1FEF have been negotiating a contract that would specify just
what rights and powers ARDC would delegate to G1FEF, and which ARDC
would retain for exercise by its board (and eventually by a hired staff,
which we have been trying to hire the first person of). The first draft
contract was full of legalese that one side or the other didn't like,
and it also raised some more complex issues such as international
privacy practices, so we are re-drafting, consulting lawyers, and
continuing to negotiate.
> 4. The holding-the-ID-in-a-photo-of-you practice is pretty common when dealing with financial institutions and websites frequently deals with fraudsters. Since LIR, RIR, and BGP upstream also requires and validates these ID, Why this is necessary to do it again?
People who get legacy 44.x.y.z IP addresses from 44net don't have to get
addresses from an LIR or RIR, so LIR/RIR practices don't provide any
safeguard for 44net addresses.
Our previous policy, created and enforced by Brian, was not to demand
such identity documents of everyone. But Brian did reserve the right to
ask more questions and collect more information when he encountered a
situation that he thought was questionable, and to use his own judgment
in deciding whether to make an allocation. And he sometimes consulted
with the board about how to resolve such situations.
> 5. Is Chris Smith, G1FEF capable of handling sensitive personal data? He's handling data as natural person, or an legal entity that ARDC approves?
At the moment, as a natural person; he's a volunteer. One of the issues
being negotiated in the draft contract, and with lawyers, is to what
extent ARDC will collect sensitive personal data, how it would safeguard
that data that it does collect, and to what extent ARDC will be subject
to privacy controls such as the European GDPR. These issues have been
handled informally up to the time that Brian died.
The current situation is that when Chris requests identification photos
or documents, he examines them and then deletes them after approval.
> 6. If there's another change, do anyone with a allocation has to go through the same process again?
Since we haven't defined any changes yet, we also haven't decided that
issue.
> I see that we already have a problem with transparency, now we got bureaucracy? Also it's not my problem that the assignment wasn't added to the portal.
It is fortunate that small, informal organizations still have room to
operate in today's world, and can provide positive benefits to society.
ARDC under Brian's leadership was such an organization; the board helped
him around the edges, but he was our leader, and he also did most of the
work. Now we have no leader experienced in exactly what Brian did. As
organizations grow and become more formal, the world expects a degree of
impartiality, predictability, and adherence to rules that reduces the
flexibility of the informal processes.
Quan, you are simultaneously asking that you be given the benefit of an
informal process that provided you with the allocation you claim, and
yet also asking that we provide predictable rules and adhere to them,
rather than continuing informally. There is clearly a tension between
these extremes. The ARDC board (all volunteers) and the technical
volunteers such as Chris and the regional coordinators are trying to
chart a middle course. Thank you for your help in pointing out some
of the implications of the choices we are trying to make.
It DOES seem to be your problem that the assignment wasn't added to the
portal. If your assignment was in the portal, then your allocation
would not be getting the scrutiny it is currently getting. As the
wiki says in the "Requesting a block" page:
https://wiki.ampr.org/wiki/Requesting_a_block
"You must request an amprnet block direct from the Portal. First you
must create your account at the Portal. Once you do, you must
login..."
https://wiki.ampr.org/wiki/Announcing_your_allocation_directly
"Apply for your AMPRNet allocation via the Portal. Check the Direct
box to indicate that your connection will be using a direct
announcement of the subnet (via the BGP protocol).
"Upon verification and approval, the AMPRNet administrator will
provide authorization to your ISP allowing them to announce your
allocation."
If only one of your three /24 allocations is in the portal, then how did
Brian, the very meticulous AMPRNet administrator end up providing you
with a Letter of Authorization for the others?
> Best Regards,
> Quan
Best regards back to you,
John Gilmore, W0GNU
ARDC board member
Tracy N4LGH,
I drafted the OpenWrt Wiki with the help of others on the mailing list. The instructions in the Wiki definitely work - I've been running an AMPRNet node on OpenWrt for approximately seven years. I have ampr-ripd compiled for most of my routers.
I'm not sure how I missed your previous requests for assistance; but I'm willing to help setup an official OpenWrt firmware installation.
73,
- LynwoodKB3VWG
