28 Mar
2014
28 Mar
'14
10:03 p.m.
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
29 Mar
29 Mar
5:08 a.m.
On Fri, Mar 28, 2014 at 3:03 PM, Eric Fort <eric.fort(a)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...
5:23 a.m.
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(a)00100100.net> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> On Fri, Mar 28, 2014 at 3:03 PM, Eric Fort <eric.fort(a)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...
>
5:44 a.m.
On Fri, Mar 28, 2014 at 10:23 PM, Harold Kinchelow <k7ilo1(a)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. :)
7:32 a.m.
New subject: isn't 44net being a "full mesh" a misnomer? Is it even necessary?
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
12:50 p.m.
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
1:03 p.m.
New subject: isn't 44net being a "full mesh" a misnomer? Is it even necessary?
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
1:14 p.m.
New subject: isn't 44net being a "full mesh" a misnomer? Is it even necessary?
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)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
30 Mar
30 Mar
4:54 a.m.
New subject: isn't 44net being a "full mesh" a misnomer? Is it even necessary?
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.
31 Mar
31 Mar
3:11 a.m.
On Fri, Mar 28, 2014 at 10:08 PM, Don Fanning <don(a)00100100.net> wrote:
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 Fri, Mar 28, 2014 at 3:03 PM, Eric Fort
<eric.fort(a)gmail.com> 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?
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).
(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.
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
5:14 a.m.
New subject: isn't 44net being a "full mesh" a misnomer? Is it even necessary?
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)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
6:28 a.m.
New subject: isn't 44net being a "full mesh" a misnomer? Is it even necessary?
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
3685
days inactive
3688
days old
12 comments
8 participants
participants (8)
-
Bart Kus -
Don Fanning -
Eric Fort -
Harold Kinchelow -
Marc, LX1DUC -
Marius Petrescu -
Robbie De Lise -
YT9TP Pedja