It would seem to me that while due to the fact we are tunneling most everything we may have a logical full mesh but far from a physical full mesh. What does a tunneled logical full mesh really accomplish for us other than making things all the more complicated? Wouldn't traditional peering and routing done "the normal way" be much easier? I can see a valid place for nailing up vpn links and various tunnels, i.e. last mile access and tying islands together though something other than IPIP with links negotiated on a peering basis as needed, but what does a full logical mesh of tunnels give us? It seems that since it's built of tunnels and thus virtual rather than physical we just unnecessarily complicate the mess wherein the tunneled traffic and the tunnels themselves end up taking multiple and somewhat changing hops to get from one end to another. IP was designed such that I could hand a packet off and basically go, "ok, now it's your problem to deliver it (on a best effort basis)", thus I shouldn't need to know every conceivable route to every conceivable endpoint. What prevents us from using it that way?
Eric AF6EP
On Fri, Mar 28, 2014 at 3:03 PM, Eric Fort eric.fort@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ It would seem to me that while due to the fact we are tunneling most everything we may have a logical full mesh but far from a physical full mesh. What does a tunneled logical full mesh really accomplish for us other than making things all the more complicated?
Right now it allows small/medium sized islands of amateur packet radio networks to interconnect with others around the planet at speeds faster and more reliable than HF or VHF.
Wouldn't traditional peering and routing done "the normal way" be much easier?
Not really because most networks are point to point (ie: you connect to your work VPN - not you connect to your work VPN which interconnects with every other VPN in the world). This essentially is a hack to backbone a semi-private network on top of the public internet.
I can see a valid place for nailing up vpn links and various tunnels, i.e. last mile access and tying islands together though something other than IPIP with links negotiated on a peering basis as needed, but what does a full logical mesh of tunnels give us? It seems that since it's built of tunnels and thus virtual rather than physical we just unnecessarily complicate the mess wherein the tunneled traffic and the tunnels themselves end up taking multiple and somewhat changing hops to get from one end to another.
Yup, nothing's perfect.
IP was designed such that I could hand a packet off and basically go, "ok, now it's your problem to deliver it (on a best effort basis)", thus I shouldn't need to know every conceivable route to every conceivable endpoint. What prevents us from using it that way?
Because the internet isn't built that way. You still need a source and destination address. You still need routers able to figure out how to get your packet from point A to point Z via points B,C,Q and V. And your packets need to know how to return back to you through said points. The way the current network works is that it sends a routing table to all participants of all these little islands of "44net" and how they could be reached over the public internet. And mind you, for it to work correctly, the traffic has to be effectively routable back to you without being dropped into a blackhole or routing loops occurring. One can just substitute 44/8 for 10/8 and the same problems are there.
The simplest way of routing a non-routable network is through encapsulation for which IPIP was chosen as it's part of the TCP/IP network protocol. This allows everyone to be part of the network while not having control or bandwidth being focused at any one single location.
A significantly harder solution would be to use BGP which is what is used on the larger internet. But there are many, many reasons why you don't want just anyone manipulating BGP routes. One wrong command and you could send China's internet traffic to Togo. Or create routing loops which would cause large interruptions not only for yourself but for a multitude of other people on the internet.
Most residential ISP's will not let you insert 44/8 addresses onto their networks. Even commercial hosting and colocation providers really want to see justification and the proper I's and T's dotted and crossed before they will host a 44/8 subnet for you as it's still not a trivial change. Then there is the problem of encapsulated and non-encapsulated. The few 44/8 subnets that have broken off the UCSD router are able to route across the internet just like anyone else but cannot reach other 44net islands that run the encapsulated tunnels without going back to the encap munge because those other islands either don't know how or are unable to reach them due to upstream providers blackholing 44/8 traffic as nonroutable.
One might suggest that we can just create a 44net VPN that we all connect into via PPTP or other means but who pays the hosting bill for that? Bandwidth and hosting still costs money at the end of the day as Netflix found out. And we don't have the advantage of doing commercial "peering" as our networks cannot be used for commercial purposes.
That's all I got...
Mesh is allowing more than just small islands to move data at higher speeds. I believe that nos has become more of an internet based protocol than anything else. The whole idea was to have internet protocols over rf back in the day, if I'm not mistaken. U cab run servers (Linux boxes) on a mesh network and have a very stable system, especially since WiFi devices can be bought pretty cheap these days. I thing there should be more experimentation with 44 and mesh than putting amprnet on the internet. Our job is to make rf networks. We should use these ip addresses in a manner to keep them or someone is gonna say, give em back, since ip4 type addresses have been depleted. As a whole, no one here is trying anything above 9k6 which kinda sucks. Just my opinion and observation.
Harold K7ILO On Mar 28, 2014 10:09 PM, "Don Fanning" don@00100100.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Fri, Mar 28, 2014 at 3:03 PM, Eric Fort eric.fort@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ It would seem to me that while due to the fact we are tunneling most everything we may have a logical full mesh but far from a physical full mesh. What does a tunneled logical full mesh really accomplish for us other than making things all the more complicated?
Right now it allows small/medium sized islands of amateur packet radio networks to interconnect with others around the planet at speeds faster and more reliable than HF or VHF.
Wouldn't traditional peering and routing done "the normal way" be much easier?
Not really because most networks are point to point (ie: you connect to your work VPN - not you connect to your work VPN which interconnects with every other VPN in the world). This essentially is a hack to backbone a semi-private network on top of the public internet.
I can see a valid place for nailing up vpn links and various tunnels, i.e. last mile access and tying islands together though something other than IPIP with links negotiated on a peering basis as needed, but what does a full
logical
mesh of tunnels give us? It seems that since it's built of tunnels and thus virtual rather than physical we just unnecessarily complicate the
mess
wherein the tunneled traffic and the tunnels themselves end up taking multiple and somewhat changing hops to get from one end to another.
Yup, nothing's perfect.
IP was designed such that I could hand a packet off and basically go, "ok, now it's your problem to deliver it (on a best effort basis)", thus I
shouldn't
need to know every conceivable route to every conceivable endpoint. What prevents us from using it that way?
Because the internet isn't built that way. You still need a source and destination address. You still need routers able to figure out how to get your packet from point A to point Z via points B,C,Q and V. And your packets need to know how to return back to you through said points. The way the current network works is that it sends a routing table to all participants of all these little islands of "44net" and how they could be reached over the public internet. And mind you, for it to work correctly, the traffic has to be effectively routable back to you without being dropped into a blackhole or routing loops occurring. One can just substitute 44/8 for 10/8 and the same problems are there.
The simplest way of routing a non-routable network is through encapsulation for which IPIP was chosen as it's part of the TCP/IP network protocol. This allows everyone to be part of the network while not having control or bandwidth being focused at any one single location.
A significantly harder solution would be to use BGP which is what is used on the larger internet. But there are many, many reasons why you don't want just anyone manipulating BGP routes. One wrong command and you could send China's internet traffic to Togo. Or create routing loops which would cause large interruptions not only for yourself but for a multitude of other people on the internet.
Most residential ISP's will not let you insert 44/8 addresses onto their networks. Even commercial hosting and colocation providers really want to see justification and the proper I's and T's dotted and crossed before they will host a 44/8 subnet for you as it's still not a trivial change. Then there is the problem of encapsulated and non-encapsulated. The few 44/8 subnets that have broken off the UCSD router are able to route across the internet just like anyone else but cannot reach other 44net islands that run the encapsulated tunnels without going back to the encap munge because those other islands either don't know how or are unable to reach them due to upstream providers blackholing 44/8 traffic as nonroutable.
One might suggest that we can just create a 44net VPN that we all connect into via PPTP or other means but who pays the hosting bill for that? Bandwidth and hosting still costs money at the end of the day as Netflix found out. And we don't have the advantage of doing commercial "peering" as our networks cannot be used for commercial purposes.
That's all I got...
On Fri, Mar 28, 2014 at 10:23 PM, Harold Kinchelow k7ilo1@gmail.com wrote:
I thing there should be more experimentation with 44 and mesh than putting amprnet on the internet.
Quite agree with you. However many of us are limited by terrain, biomass of interested people, regulations and other things. I'm fortunate to be in a very tech savvy town and they are growing a 5ghz HamWAN in my area. But this WAN still won't allow me to reach Germany without a internet tunnel. The only way I see truly global high speed networks is via satellite as nothing else will provide the bandwidth necessary over large non-densely populated swaths of the planet. Again, no bucks, no Buck Rogers...
But that being said, I can't wait till my HackRF shows up. :)
IMHO the whole "full mesh" approach is the only practical approach to allow easy configuration. Let me motivate this:
1.) IPIP is to my knowledge the only tunneling protocol available in standard linux distributions that allows point to multipoint connections (other OSes don't have any). Being stateless, it allows, based on non-standard use of kernel routes, to send encapsulated data to an arbitrary number of destinations, using a single virtual network interface.
2.) Again, because it is stateles, it does not have to send any control or keep-alive data on the tunnel to check the availability of endpoints, thus reducing data flow. Data is sent only if there is an active data exchange between peers, on a on demand basis.
3.) In order to provide a somehow dynamic routing table with regard to the various tunnel endpoints, initially there was this encap file, not providing routing info, but actual endpoint addresses for the needed tunnels (see 1).
4.) Because there was a need to have faster endpoint address updates, the RIPv2 broadcast method was introduced. Again it is not used as a dynamic routing protocol, but as a tunnel endpoint update method. The fact that it has the form of a routing protocol was just a choice not to reinwent the wheel by developing a proprietary protocol. This is why the processing of the RIPv2 boradcasts can not be done using standard routing tools, like e.g. quagga, but needs a custom mage script/daemon.
Any stateful approach by using classical P2P links will take away these advantages:
1.) One will need an individual network interface for every peer he wants to connect to, in order to be able to use that connection in a stateful manner (about 340 tunnels at the moment). This is the approach used on some routers not allowing P2MP on IPIP interfaces, e.g. mikrotik, even for classic IPIP setups, loosing the dynamic setup capability of the RIP broadcasts, since a script is needed to allow the setup of such a large number of tunnel interfaces.
2.) Each such interface will have its own routing and firewalling rules to be taken in account.
3.) Stateful P2P links have active data exchanges all the time, to be able to provide their link status to the endpoint hosts.
Using a direct global route announcement using BGP has also some drawbacks, especially regarding costs.
1.) A BGP enabled subnet in most of the countries is astronomically costly, being regarded as a "professional" network approach by the ISPs
2.) You most likely need a router capable of processing a full internet BGP table, which is HUGE, comprising more than 48k prefixes reaching a size of over 10MB. This needs filtering, big memory resources and fast CPUs. Raspberies won't do the job here.
3.) You will still have to provide tunnels in order to reach and be reached by 44net islands not using BGP.
Correctly setting up a stateful tunneled system or a BGP enabled network is certainly more complicated than a P2MP IPIP tunneling system.
73s de Marius, YO2LOJ
Using a direct global route announcement using BGP has also some drawbacks, especially regarding costs.
1.) A BGP enabled subnet in most of the countries is astronomically costly, being regarded as a "professional" network approach by the ISPs
I would suggest going for a small ISP in a datacenter, and not a colt or verizon or level3 or cogent or ... Just take a very local ISP, who still has good peerings and stuff.
The ISP that we got to start with our 44.144/16 BGP announcements is a very small ISP consisting of 3 people, and the owner is also the main network engineer. He thought of this as a challenge and was excited to be doing this. Furthermore we are lucky enough to get about 100mbit of bandwith for free from this ISP as a sort of sponsoring to the hamradio community in belgium. This means that the ISP is small but is still doing enough traffic that they can give away 100mbit without making any losses.
2.) You most likely need a router capable of processing a full internet BGP table, which is HUGE, comprising more than 48k prefixes reaching a size of over 10MB. This needs filtering, big memory resources and fast CPUs. Raspberies won't do the job here.
We use a Mikrotik CCR1036-12G for this. Cost is about EURO 800 (sounds like much, but hey, a decent VHF mobile radio costs about the same)
3.) You will still have to provide tunnels in order to reach and be reached by 44net islands not using BGP.
This is correct, we still route 44.0.0.0/8 to a system that does IPIP to the rest of amprnet. However, the route from the rest of amprnet back to us could be done purely over the internet. So the question might be, do we still need to announce ourselves in the encap file ?
Correctly setting up a stateful tunneled system or a BGP enabled network is certainly more complicated than a P2MP IPIP tunneling system.
Depends on experience I guess :)
73 Robbie, ON4SAX
On 29/03/2014 13:50, Robbie De Lise wrote:
This is correct, we still route 44.0.0.0/8 to a system that does IPIP to the rest of amprnet. However, the route from the rest of amprnet back to us could be done purely over the internet. So the question might be, do we still need to announce ourselves in the encap file ?
Yes. The explanation lies in the current routing configuration for 44/8 within UCSD. Mainly upstream router for the AMPR-GW at UCSD has a default route towards it's upstream router and a static route for 44/8, so any traffic leaving the AMPR GW at UCSD for a 44.144/16 address will be routed back to the AMPR-GW, actually creating a routing loop.
At least until the routing setup changes (if it changes at all) all of us *MUST* have an entry in the encap file in order to be reachable from within 44net.
73 de Marc
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Robbie De Lise Sent: Saturday, March 29, 2014 14:50 To: AMPRNet working group Subject: Re: [44net] isn't 44net being a "full mesh" a misnomer? Is it even necessary?
....................
This is correct, we still route 44.0.0.0/8 to a system that does IPIP to the rest of amprnet. However, the route from the rest of amprnet back to us could be done purely over the internet. So the question might be, do we still need to announce ourselves in the encap file ? ....................
The fact that routing back via internet is an false assumption.
If I sent an outgoing packet vit a 44net source address to my ISP (and I assume the same for others, too), that packet will just be dropped, since it does not originate from their IP address space. Allowing such behavior would open the door for IP spoofing... And if that response comes from one interface, while the request was snet via another will probably also allow RP filtering to kick in, unless you disable it on your routers (which is a bad idea for similar security reasons).
Also, an unnannounced network gets no forwarding in amprgw, since the encap destination is not known.
So yes, you need to announce yourselves, so that other endpoints could have the proper encapsulation destinations.
73 de Marius, YO2LOJ
On 3/28/2014 10:23 PM, Harold Kinchelow wrote:
addresses have been depleted. As a whole, no one here is trying anything above 9k6 which kinda sucks. Just my opinion and observation.
<shameless plug> https://www.hamwan.org/t/tiki-index.php </shameless plug>
--Bart
PS: Apologies in advance if some of my cohorts already did said plug and I'm being redundant.
On Fri, Mar 28, 2014 at 10:08 PM, Don Fanning don@00100100.net wrote:
On Fri, Mar 28, 2014 at 3:03 PM, Eric Fort eric.fort@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
It would seem to me that while due to the fact we are tunneling most everything we may have a logical full mesh but far from a physical full mesh. What does a tunneled logical full mesh really accomplish for us other than making things all the more complicated?
Right now it allows small/medium sized islands of amateur packet radio networks to interconnect with others around the planet at speeds faster and more reliable than HF or VHF.
Wouldn't traditional peering and routing done "the normal way" be much easier?
Not really because most networks are point to point (ie: you connect to your work VPN - not you connect to your work VPN which interconnects with every other VPN in the world). This essentially is a hack to backbone a semi-private network on top of the public internet.
If this is, " a hack to backbone a semi-private network on top of the public internet" then why do we need 44/8? Please explain why 10/8 would not work just as well?
Also, most links are point to point and connect various networks, or did I miss something in my networking classes? A host in the IP sense can be viewed as a /32 network though the link it's on generally requires a /30 for everything to work correctly (rfc3021 notwithstanding).
I can see a valid place for nailing up vpn links and various tunnels, i.e. last mile access and tying islands together though something other than IPIP with links negotiated on a peering basis as needed, but what does a full logical mesh of tunnels give us? It seems that since it's built of tunnels and thus virtual rather than physical we just unnecessarily complicate the mess wherein the tunneled traffic and the tunnels themselves end up taking multiple and somewhat changing hops to get from one end to another.
Yup, nothing's perfect.
IP was designed such that I could hand a packet off and basically go, "ok, now it's your problem to deliver it (on a best effort basis)", thus I shouldn't need to know every conceivable route to every conceivable endpoint. What prevents us from using it that way?
Because the internet isn't built that way. You still need a source and destination address. You still need routers able to figure out how to get your packet from point A to point Z via points B,C,Q and V. And your packets need to know how to return back to you through said points. The way the current network works is that it sends a routing table to all participants of all these little islands of "44net" and how they could be reached over the public internet. And mind you, for it to work correctly, the traffic has to be effectively routable back to you without being dropped into a blackhole or routing loops occurring. One can just substitute 44/8 for 10/8 and the same problems are there.
The simplest way of routing a non-routable network is through encapsulation for which IPIP was chosen as it's part of the TCP/IP network protocol. This allows everyone to be part of the network while not having control or bandwidth being focused at any one single location.
again, if it's not going to be routable then why do we need 44/8? use RFC1918 space and give 44/8 back. The easiest way to get things routable is to use a dynamic routing protocol and peer with others using standards based routing protocols and practices. That involves using working with others to peeer with protocols such as OSPF and BGP. We could attract many into this hobby if we'd simply offer to be the teachers of the IP networking craft using standards based methods used by everyone else across the internet.
A significantly harder solution would be to use BGP which is what is used
on the larger internet. But there are many, many reasons why you don't want just anyone manipulating BGP routes. One wrong command and you could send China's internet traffic to Togo. Or create routing loops which would cause large interruptions not only for yourself but for a multitude of other people on the internet.
Yes, I've seen this done both intentionally and unintentionally. sometimes one need be careful about what and who's anouncements are trustworthy. this is where mentoring and good network policy becomes increasingly importaint.
Most residential ISP's will not let you insert 44/8 addresses onto their networks. Even commercial hosting and colocation providers really want to see justification and the proper I's and T's dotted and crossed before they will host a 44/8 subnet for you as it's still not a trivial change. Then there is the problem of encapsulated and non-encapsulated. The few 44/8 subnets that have broken off the UCSD router are able to route across the internet just like anyone else but cannot reach other 44net islands that run the encapsulated tunnels without going back to the encap munge because those other islands either don't know how or are unable to reach them due to upstream providers blackholing 44/8 traffic as nonroutable.
And they should ask for and review that you have all your stuff in order prior to either hosting your netblock within their AS or offering to peer with you. It's then our task as custodians of 44/8 to mentor those who would use that space into being good network engineers and technicians. As far as reachability to and from other 44net islands, i.e. between those using BGP and those not that would seem to be resolvable via individual peering agreements between the respective islands. At the same time I'd think use of BGP wherever possible to route to and from the larger internet and smaller 44net islands ought be encouraged as the norm or again if that is not to be the case then maybe we ought seriously consider 10/8.
One might suggest that we can just create a 44net VPN that we all connect into via PPTP or other means but who pays the hosting bill for that? Bandwidth and hosting still costs money at the end of the day as Netflix found out. And we don't have the advantage of doing commercial "peering" as our networks cannot be used for commercial purposes.
Who pays to put your local repeater on the air and keep it there? Same thing. Also while our over the air ham band networks can not in most cases carry commercial traffic, our internet links most certainly could. the prohibition is against what goes over the air on the ham bands, not what travels over the 44/8 network - at least from a govt. regulatory viewpoint.
That's all I got...
Eric AF6EP
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Eric Fort Sent: Monday, March 31, 2014 05:12 To: Don Fanning; AMPRNet working group Subject: Re: [44net] isn't 44net being a "full mesh" a misnomer? Is it even necessary? ...
If this is, " a hack to backbone a semi-private network on top of the public internet" then why do we need 44/8? Please explain why 10/8 would not work just as well?
With 10/8 or other true private IPs you can not have a public gateway. Actually the whole 44/8 is accessible as a stub network via amprgw, and is routable. Just not each island directly.
Also, most links are point to point and connect various networks, or did I again, if it's not going to be routable then why do we need 44/8? use RFC1918 space and give 44/8 back. The easiest way to get things routable is to use a dynamic routing protocol and peer with others using standards based routing protocols and practices. That involves using working with others to peeer with protocols such as OSPF and BGP. We could attract many
i>nto this hobby if we'd simply offer to be the teachers of the IP
networking craft using standards based methods used by everyone else across the internet.
First, what would be the benefit of giving it back? And second, no one is stoping anyone from direct peering and usage of dynamic routing protocols, kipping IPIP. It is done in a lot of places (see on, de, oe, i). IPIP is just one of many solutions, but is resolves the need for individual arrangements between subnet operators. And it is dynamic via RIP/encap. For the ham network to be global, a central coodination and peer info distribution is needed anyway, no matter the peering method.
73s de Marius, YO2LOJ
On 31.3.2014 4:11, Eric Fort wrote:
If this is, " a hack to backbone a semi-private network on top of the public internet" then why do we need 44/8? Please explain why 10/8 would not work just as well?
10/8 iu sed by everyone else. 44/8 is used only by hams and in organized manner so there is no possibility for messing it up.
--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
-
Bart Kus -
Don Fanning -
Eric Fort -
Harold Kinchelow -
Marc, LX1DUC -
Marius Petrescu -
Robbie De Lise -
YT9TP Pedja