18 Apr
2014
18 Apr
'14
7:09 p.m.
John,
Lol...you know I meant the major /8's that were handed out long ago that, to date,
have never signed an agreement with their RIR.
I stand corrected, though, there are Legacy allocations smaller than /8 that exist as
well...but they are not listed in RFCs (as fixtures of the 'DARPA Internet').
-KB3VWG
22 Apr
22 Apr
7:09 p.m.
New subject: SIP on AMPRNet and announcing services
Eric,
Actually, there are some SIP servers on AMPRNet already; and I'm capable
of standing up a SIP server at my station. The only problem personally
is that there's not much of a reason to stand up multiple SIP servers.
Even if we did, it would be a good idea to standardize the call scheme
to interconnect them, so we could dial those with SIP registrations on
the various servers.
Regarding announcing services:
What exactly do those who want services announced wish to accomplish by
having services announced over the network (and to the world if added to
the DNS)?
My idea was more-so that those who don't mind informing the AMPRNet
at-large that they have a service to share (and don't mind sharing that
information) could post it to the list.
-KB3VWG
8:27 p.m.
New subject: SIP on AMPRNet and announcing services
Well, enum comes to mind.
Eric
On Tue, Apr 22, 2014 at 4:09 PM, <lleachii(a)aol.com> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Eric,
Actually, there are some SIP servers on AMPRNet already; and I'm capable
of standing up a SIP server at my station. The only problem personally is
that there's not much of a reason to stand up multiple SIP servers. Even if
we did, it would be a good idea to standardize the call scheme to
interconnect them, so we could dial those with SIP registrations on the
various servers.
Regarding announcing services:
What exactly do those who want services announced wish to accomplish by
having services announced over the network (and to the world if added to
the DNS)?
My idea was more-so that those who don't mind informing the AMPRNet
at-large that they have a service to share (and don't mind sharing that
information) could post it to the list.
-KB3VWG
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
10:55 p.m.
New subject: SIP on AMPRNet and announcing services
I'm not quite sure about the "announcement" aspect of it. Are we talking
announcements similar to BGP or ZeroConf that was mentioned earlier? What
kind of announcements are being made now on LAN networks beyond
printer/fileshare/UPnP for all of which you wouldn't want to have
advertised in such a fashion over the WAN (even 44net - seeing how people
get bent out of shape whenever any 'foreign' packet hits their firewall).
But to throw out a list...
-NNTP/Usenet Servers - Possibly gateway BBS/FBB into NNTP
-Common Databases - Callsign Database, Maidenhead and the like
-Streaming Audio/Video - repeaters, remote receivers, sarex, ATV feeds or
whatever you want to toss up there.
-Video Conferencing - but I'm still struggling getting this working
properly in the real world for public consumption... so may be a stretch
goal.
-Latency tolerant games like Chess, Poker... even TradeWars.
-Internet of Things - Feed/Entertain my cat for me when I'm traveling...
-Cameras - Not necessarily streaming... but for a while there on the
internet, we could watch the sun set in tahiti while freezing in
minneapolis... Let's hope it doesn't turn into ham radio #selfies :)
On Tue, Apr 22, 2014 at 5:27 PM, Eric Fort <eric.fort(a)gmail.com> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> Well, enum comes to mind.
>
> Eric
>
>
> On Tue, Apr 22, 2014 at 4:09 PM, <lleachii(a)aol.com> wrote:
>
> > (Please trim inclusions from previous messages)
> > _______________________________________________
> > Eric,
> >
> > Actually, there are some SIP servers on AMPRNet already; and I'm capable
> > of standing up a SIP server at my station. The only problem personally is
> > that there's not much of a reason to stand up multiple SIP servers. Even
> if
> > we did, it would be a good idea to standardize the call scheme to
> > interconnect them, so we could dial those with SIP registrations on the
> > various servers.
> >
> > Regarding announcing services:
> >
> > What exactly do those who want services announced wish to accomplish by
> > having services announced over the network (and to the world if added to
> > the DNS)?
> >
> > My idea was more-so that those who don't mind informing the AMPRNet
> > at-large that they have a service to share (and don't mind sharing that
> > information) could post it to the list.
> >
> >
> > -KB3VWG
> > _________________________________________
> > 44Net mailing list
> > 44Net(a)hamradio.ucsd.edu
> > http://hamradio.ucsd.edu/mailman/listinfo/44net
> >
>
23 Apr
23 Apr
12:45 a.m.
New subject: SIP on AMPRNet and announcing services
Lets not reinvent the wheel -- http://en.wikipedia.org/wiki/SRV_record
Example (for DPLUS D-STAR Linking)
host -t srv _dplus._udp.arlink.net
________________________________
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
12:28 p.m.
New subject: SIP on AMPRNet and announcing services
Lets not reinvent the wheel --
http://en.wikipedia.org/wiki/SRV_record
Example (for DPLUS D-STAR Linking)
Is this something that would be automatic or another manual process?
New servers should just should up in the resource list. Servers off
line should disappear. If it's on the list it should be live!
Bill, WA7NWP
10:05 a.m.
New subject: News on the Internet front
All,
I'm in the process of applying for number resources for ARIN for my workplace. I
received an email telling me to act on the ticket immediately.
So it seems, at midnight, ARIN entered Phase Four of thier IPv4 Depletion Countdown Plan -
having only /8 worth of IP addresses remaining.
https://www.arin.net/announcements/2014/20140423.html
-KB3VWG
24 Apr
24 Apr
9:52 a.m.
New subject: What is 44net?
Cory,
First, let me say, feel free to have your own opinion. I just wanted to note that
technical specifications speak contrary to your point of view.
IP allocations follow a system specified in RFC2050; not because there's a majority
consensus on the Internet that RIRs possess authority to issue IPs. The current DNS
structure exists because of the specifications in RFCs 1034 and 1035, not because people
simply agree. If they did not, or there was no global technical standard, there would be
no guarantee of unique names and numbers, different networks may reach a different
resource depending on their location (or not reach a resource whatsoever). Operating
System developers would have no way of programming and configuring defaults for
'standards' such as IPv4, IPv6, DNS, DHCP, etc.
44.0.0.0/8 is, in fact, one network, as specified in RFC1166. Many folk have noted that
they don't wish to have their allocation connect to others (or to the Internet for
that matter); that's their option and their firewall. In the same token, we have
others who come to the mailing list, asking how to get their allocations online. I
personally see it as a success that I established connectivity to the rest of AMPRNet; and
when I BGP in the future, I intend to maintain a 44GW that will be reachable via tunnel as
well. Others are using thier allocations for purposes that would not have thier allocation
connected to the rest of AMPRNet, only part time, or in some test/research capacity;
that's OK too. Regardless, so long as they are not announcing thier allocation (with
permission) from another AS, any Internet traffic destined to that subnet will travel to
where 44.0.0.0/8 is announced - your argument that 44/8 is not one network fails on that
one notion.
Jann,
You mentioned spoofing. This is the reason the encap file and route table should be kept
private. Only other amateurs would know the location of the other endpoints.
Also, thanks for the compliments regarding the aprscode tool.
-KB3VWG
1:47 p.m.
New subject: What is 44net?
Brian F.,
We'll agree to disagree on the point that 44/8 is not one network. The last time I
checked, there was an announcement on the Internet for 44.0.0.0/8; but as I've
mentioned before, to each their own opinion. I think we often get lost on the Internal
(within AMPR, we are an island of subnets that use a proprietary routing protocol) versus
External (from the Public Internet we are one /8) viewpoint.
Regarding the security through obscurity: I allow (and can route) all 44/8 address that
reach me via encap; I also only return traffic to subnets for which I have a route. I
never mentioned that my firewall treats those maches any differnt than another Public
Internet IP address. Only my 44 IPs who entered my GW via a local interface are trusted.
-KB3VWG
4:20 p.m.
New subject: What is 44net?
Eric,
So you're suggesting we totally do away with dynamic routing; and each station setup
(and keep updated) routes to others GWs manually?
-KB3VWG
5:27 p.m.
New subject: What is 44net?
No, the suggestion is to drop the whole encap stuff and do manual P2P...
And take down the whole global interconnection concept.
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of
lleachii(a)aol.com
Sent: Thursday, April 24, 2014 23:20
To: lleachii(a)aol.com; 44net(a)hamradio.ucsd.edu
Subject: Re: [44net] What is 44net?
(Please trim inclusions from previous messages)
_______________________________________________
Eric,
So you're suggesting we totally do away with dynamic routing; and each
station setup (and keep updated) routes to others GWs manually?
-KB3VWG
5:43 p.m.
New subject: What is 44net?
Actually you *BOTH* have it wrong. What I'm suggesting is exactly the use
of *DYNAMIC* routing and routing protocols with no need for the encap file
whatsoever with each subnet peering with the other subnets which they
decide to voluntarily exchange traffic with. The connection between said
subnets being done over an authenticated connection. Various subnets then
provide transit to other non peered subnets by use of dynamic routing
protocols. As it is right now with the tunnel mesh and encap.txt I'm as
obligated to accept (and route) traffic from miscreant.ampr.org as I am
from saint.ampr.org (at least if I follow the principles embodied in the
full mesh concept).
Eric
AF6EP
On Thu, Apr 24, 2014 at 2:27 PM, Marius Petrescu <marius(a)yo2loj.ro> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> No, the suggestion is to drop the whole encap stuff and do manual P2P...
> And take down the whole global interconnection concept.
>
> -----Original Message-----
> From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
> [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of
> lleachii(a)aol.com
> Sent: Thursday, April 24, 2014 23:20
> To: lleachii(a)aol.com; 44net(a)hamradio.ucsd.edu
> Subject: Re: [44net] What is 44net?
>
> (Please trim inclusions from previous messages)
> _______________________________________________
> Eric,
>
> So you're suggesting we totally do away with dynamic routing; and each
> station setup (and keep updated) routes to others GWs manually?
>
>
> -KB3VWG
>
>
>
6:50 p.m.
New subject: What is 44net?
Why mesh? I'm not seeing any advantage with mesh that you wouldn't have
with the RIP broadcasts? I do agree that intra RIP packets may be
warranted if networks with multiple gateways start popping up. Plus
there's always the chicken and the egg part in that how would you
authenticate and add new tunnels/bootstrap new nodes?
On Thu, Apr 24, 2014 at 2:43 PM, Eric Fort <eric.fort(a)gmail.com> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> Actually you *BOTH* have it wrong. What I'm suggesting is exactly the use
> of *DYNAMIC* routing and routing protocols with no need for the encap file
> whatsoever with each subnet peering with the other subnets which they
> decide to voluntarily exchange traffic with. The connection between said
> subnets being done over an authenticated connection. Various subnets then
> provide transit to other non peered subnets by use of dynamic routing
> protocols. As it is right now with the tunnel mesh and encap.txt I'm as
> obligated to accept (and route) traffic from miscreant.ampr.org as I am
> from saint.ampr.org (at least if I follow the principles embodied in the
> full mesh concept).
>
> Eric
> AF6EP
>
>
> On Thu, Apr 24, 2014 at 2:27 PM, Marius Petrescu <marius(a)yo2loj.ro> wrote:
>
> > (Please trim inclusions from previous messages)
> > _______________________________________________
> > No, the suggestion is to drop the whole encap stuff and do manual P2P...
> > And take down the whole global interconnection concept.
> >
> > -----Original Message-----
> > From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
> > [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of
> > lleachii(a)aol.com
> > Sent: Thursday, April 24, 2014 23:20
> > To: lleachii(a)aol.com; 44net(a)hamradio.ucsd.edu
> > Subject: Re: [44net] What is 44net?
> >
> > (Please trim inclusions from previous messages)
> > _______________________________________________
> > Eric,
> >
> > So you're suggesting we totally do away with dynamic routing; and each
> > station setup (and keep updated) routes to others GWs manually?
> >
> >
> > -KB3VWG
> >
> >
> >
6:54 p.m.
New subject: What is 44net?
I think the better model is BGP "nodes" which provide VPN to subnets.
The BGP node admins would provide the VPN authentication to know what
subnets were attaching and BGP would provide Internet connectivity
(including subnets).
________________________________
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
On Thu, Apr 24, 2014 at 3:50 PM, Don Fanning <don(a)00100100.net> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> Why mesh? I'm not seeing any advantage with mesh that you wouldn't have
> with the RIP broadcasts? I do agree that intra RIP packets may be
> warranted if networks with multiple gateways start popping up. Plus
> there's always the chicken and the egg part in that how would you
> authenticate and add new tunnels/bootstrap new nodes?
>
>
> On Thu, Apr 24, 2014 at 2:43 PM, Eric Fort <eric.fort(a)gmail.com> wrote:
>
>> (Please trim inclusions from previous messages)
>> _______________________________________________
>> Actually you *BOTH* have it wrong. What I'm suggesting is exactly the use
>> of *DYNAMIC* routing and routing protocols with no need for the encap file
>> whatsoever with each subnet peering with the other subnets which they
>> decide to voluntarily exchange traffic with. The connection between said
>> subnets being done over an authenticated connection. Various subnets then
>> provide transit to other non peered subnets by use of dynamic routing
>> protocols. As it is right now with the tunnel mesh and encap.txt I'm as
>> obligated to accept (and route) traffic from miscreant.ampr.org as I am
>> from saint.ampr.org (at least if I follow the principles embodied in the
>> full mesh concept).
>>
>> Eric
>> AF6EP
>>
>>
>> On Thu, Apr 24, 2014 at 2:27 PM, Marius Petrescu <marius(a)yo2loj.ro> wrote:
>>
>> > (Please trim inclusions from previous messages)
>> > _______________________________________________
>> > No, the suggestion is to drop the whole encap stuff and do manual P2P...
>> > And take down the whole global interconnection concept.
>> >
>> > -----Original Message-----
>> > From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
>> > [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of
>> > lleachii(a)aol.com
>> > Sent: Thursday, April 24, 2014 23:20
>> > To: lleachii(a)aol.com; 44net(a)hamradio.ucsd.edu
>> > Subject: Re: [44net] What is 44net?
>> >
>> > (Please trim inclusions from previous messages)
>> > _______________________________________________
>> > Eric,
>> >
>> > So you're suggesting we totally do away with dynamic routing; and each
>> > station setup (and keep updated) routes to others GWs manually?
>> >
>> >
>> > -KB3VWG
>> >
>> >
>> >
6:57 p.m.
New subject: What is 44net?
agreed, pretty much exactly what I was getting at. Peering in the BGP
sense.
Eric
AF6EP
On Thu, Apr 24, 2014 at 3:54 PM, K7VE - John <k7ve(a)k7ve.org> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> I think the better model is BGP "nodes" which provide VPN to subnets.
> The BGP node admins would provide the VPN authentication to know what
> subnets were attaching and BGP would provide Internet connectivity
> (including subnets).
>
> ________________________________
> John D. Hays
> K7VE
> PO Box 1223, Edmonds, WA 98020-1223
>
>
>
> On Thu, Apr 24, 2014 at 3:50 PM, Don Fanning <don(a)00100100.net> wrote:
> > (Please trim inclusions from previous messages)
> > _______________________________________________
> > Why mesh? I'm not seeing any advantage with mesh that you wouldn't
have
> > with the RIP broadcasts? I do agree that intra RIP packets may be
> > warranted if networks with multiple gateways start popping up. Plus
> > there's always the chicken and the egg part in that how would you
> > authenticate and add new tunnels/bootstrap new nodes?
> >
> >
> > On Thu, Apr 24, 2014 at 2:43 PM, Eric Fort <eric.fort(a)gmail.com> wrote:
> >
> >> (Please trim inclusions from previous messages)
> >> _______________________________________________
> >> Actually you *BOTH* have it wrong. What I'm suggesting is exactly the
> use
> >> of *DYNAMIC* routing and routing protocols with no need for the encap
> file
> >> whatsoever with each subnet peering with the other subnets which they
> >> decide to voluntarily exchange traffic with. The connection between
> said
> >> subnets being done over an authenticated connection. Various subnets
> then
> >> provide transit to other non peered subnets by use of dynamic routing
> >> protocols. As it is right now with the tunnel mesh and encap.txt I'm
as
> >> obligated to accept (and route) traffic from miscreant.ampr.org as I am
> >> from saint.ampr.org (at least if I follow the principles embodied in
> the
> >> full mesh concept).
> >>
> >> Eric
> >> AF6EP
> >>
> >>
> >> On Thu, Apr 24, 2014 at 2:27 PM, Marius Petrescu <marius(a)yo2loj.ro>
> wrote:
> >>
> >> > (Please trim inclusions from previous messages)
> >> > _______________________________________________
> >> > No, the suggestion is to drop the whole encap stuff and do manual
> P2P...
> >> > And take down the whole global interconnection concept.
> >> >
> >> > -----Original Message-----
> >> > From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
> >> > [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf
> Of
> >> > lleachii(a)aol.com
> >> > Sent: Thursday, April 24, 2014 23:20
> >> > To: lleachii(a)aol.com; 44net(a)hamradio.ucsd.edu
> >> > Subject: Re: [44net] What is 44net?
> >> >
> >> > (Please trim inclusions from previous messages)
> >> > _______________________________________________
> >> > Eric,
> >> >
> >> > So you're suggesting we totally do away with dynamic routing; and
each
> >> > station setup (and keep updated) routes to others GWs manually?
> >> >
> >> >
> >> > -KB3VWG
> >> >
> >> >
> >> >
6:29 p.m.
New subject: What is 44net?
Eric,
OK, well, since I want to get it *CORRECT* and I'm still not understanding you...I
wanted to be certain you are aware that we currently use dynamic routing via two methods,
ENCAP (so long as the station uses some method to regularly update the file) and RIP44.
Where I'm seeking clarity is on the statement:
with each subnet peering with the other subnets which
they
decide to voluntarily exchange traffic with
If you receive a dynamic routing statement over RIP44 or ENCAP, you're receiving all
valid routes from the core 44 router. You're suggestion implies that you'd remove
routes you do not wish to communicate with; or you'd explicitley firewall them. That
confuses me because you go on to state:
Various subnets then provide transit to
other non peered subnets by use of dynamic
routing protocols
Why would you delete/firewall routes from your dynamically populated table, just to have
another gateway route traffic on your behalf (who received the route information from the
same source)?
-KB3VWG
7:58 p.m.
New subject: What is 44net?
So, instead of simply getting our routes from AMPR dynamically, you suggest:
- going to each individual subnet operator one-by-one and setup a
peering relationship
- setup VPN tunneling to each subnet we directly connect to
- establish another way to maintain connection to GWs with dynamically
changing IPs
- then configure BGP on our gateways correctly to share routes and
transit for one another through that tunnel connection???
I'm trying to figure out if you all are just joking, or if you're being
serious.
Your idea requires a new operator to magically locate others to setup a
peering relationship with in order for their allocation to work. Not to
mention, your suggestion is extremely convoluted:
- there are many different kinds of VPN, and it seems a tunnel would
have to be erected to each peer who could be using different VPN solutions
- not all countries/ISPs allow VPNs
- not all equipment works well with multiple VPN connections
- I wouldn't expect everyone to simply know how to setup BGP
- we'd have to begin coordinating ASNs, in addition to 44 addresses, or
risk duplicates
- a misconfiguration with BGP could spill out of AMPRNet onto the Public
Internet
-KB3VWG
25 Apr
25 Apr
7:32 a.m.
New subject: What is 44net?
I'm still wondering if you all are joking, or if you all are serious.
I've seen alot of folk simply say "we'll just connect via BGP."
I have some serious questions:
What ISP do you folk have at home that allows BGP?!?!
Do you manage or own a business where you can "borrow" bandwidth and
setup your own BGP?!?!
Is your equipment already at a tower or location where you can peer with
the carrier(s) present there!?!?
- I don't know of any consumer ISP that allows their customers to route
via BGP
- There's an assumption that every nation in the world has
widely-available broadband Internet connections or that that every
nation will permit a Ham to connect via BGP
- I don't know of many Hams that happens to have a spare Cisco Nexus (or
other commercial equipment capable of BGP) laying around
- I don't know of any consumer connections that 1.) could handle traffic
for a /8 without reaching some bandwidth cap or restriction and 2.)
allows BGP, servers or commercial grade equipment to be connected to the
node
- If we BGP on the Internet, that requires every station to procure an
ASN plus equipment that can speak BGP, that's a large cost of entry just
to tinker around, if they can procure an ASNs from their RIR/LIR
Aside from all of those points, exactly how do we continue routing to
those who won't setup BGP, cannot setup BGP and/or cannot afford to
setup BGP???
-KB3VWG
1:25 p.m.
New subject: What is 44net?
John,
Working for a governmental ISP, the fact is that traffic, regardless if it's noise or
legitimate (which can only be determined by Deep Packet Inspection), can only be stopped
at the border. Once stopped at the border, you still have incurred the inbound bandwidth
costs.
Those running IPENCAP tunnels deal with this today, traffic destined to our subnets still
reaches our gateways, and the bandwidth has been spent. This is regardless of a firewall
to prevent traffic from entering the subnet, or a Destination Unreachable returned. That
cannot be changed, as 44/8 are public IP addresses. Traffic must be at your border,
that's the point of routing.
-KB3VWG
3:25 p.m.
New subject: What is 44net?
John,
Does not mean end users need BGP
A few, maybe as little as 10, border nodes might run BGP and *provide
VPN/Tunnel services to everyone else* and not everyone needs to run the
same VPN/Tunnel protocol.
Then who would be setting up this BGP???
Some of those who announce their allocations now refuse to maintain tunnels for others.
Your theories can be tested now, without BGP. My gateway startup script should currently
allow someone to route traffic to other valid nodes, simply test by pointing your gatewawy
towards mine, return traffic will be via thier route for you (multi-homing), add your BGP
later.
The idea is to have a fully connected address space
using the
Internet/BGP to interconnect.
The address space is fully connected now, problem are you trying to solve?
There can be multi-homing and tiers to minimize single
points of failure.
How many of you can say your 'home' ampr-lan doesn't have a single point
of failure?
The only way for my home ampr-lan to eliminate its single point of failure problem is to
get a second ISP at home and BGP with both of them; but you state above that this
"does not mean end users need BGP," so I'm confused.
Encap/IPIP and RIP tables could theoretically have 16
million entries for
Net-44, why not use aggregation and a tiered network instead?
???
Theoretically, yes, if all the space in 44net were divided into /32's. Realistically,
that is not the case. Your suggestion still requires AMPRGW and some select few to
maintain a "more complete" routing table than the end user has; currently, we
all have a copy of the full routing table.
As I see it, the end user would use a router (a cheap
Mikrotik or RasPi)
with one or more upstream VPN connections to a border node or sub-tier
router and would route all non-local 44net traffic over that
connection/those connections. All the user needs is a VPN/Tunnel
configuration and credentials provided by the border node/tier router
operator. So much simpler.
Think big net, not personal net.
You do know this is how AMPRNet currently works (minus the VPN portion), right?
-KB3VWG
4:46 p.m.
New subject: What is 44net?
...excluding AOL users?
(luckily Comcast is my ISP, I just use an AOL email address...)
-KB3VWG
4:55 p.m.
New subject: What is 44net?
John,
Failure to do so is grounds for losing one's
allocation.
I wholeheartedly agree with you; but in practice, that has not been the case (see the
archive).
----
I'd love to help begin testing this concept. My 44GW should currently forward traffic
to other IPENCAP destinations. You'd simply have to use my GW's public IP as your
tunnel's default route. If this works, then we simply have to work on connectivity and
peering of the other GWs providing the service.
Please be mindful that return traffic will take a path via the route in the other
endpoint's route table; meaning, that the destination 44GW must be using the current
Encap file or RIP44.
-KB3VWG
44.60.44.0/24
10:01 p.m.
New subject: What is 44net?
Any plan will have the potential for failures.
That's just inaccurate. You are theorizing to the absurd. AMPRGW
currently provides connectivity for all of 44/8. The recommendation
suggests a piecemeal option where people announce routes as they please,
that had the potential to leave some routes unreachable.
You might control your IPIP
tunnel but what if your ISP goes away?
If your ISP goes away, you loose all connectivity to the Internet,
period. I'm trying to follow the logic here.
-KB3VWG
10:40 p.m.
New subject: What is 44net?
It seems to me that tempers are running a little high and
that we've reached a point where there is more heat than
light in this discussion. What say we give it a rest and
all cool off a bit?
- Brian
27 Apr
27 Apr
2:12 p.m.
New subject: What is 44net?
BTW, your emails trigger gmail's spam filter --
------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
On Fri, Apr 25, 2014 at 7:01 PM, <lleachii(a)aol.com> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Any plan will have the potential for failures.
That's just inaccurate. You are theorizing to the absurd. AMPRGW currently
provides connectivity for all of 44/8. The recommendation suggests a
piecemeal option where people announce routes as they please, that had the
potential to leave some routes unreachable.
You might control your IPIP
tunnel but what if your ISP goes away?
If your ISP goes away, you loose all connectivity to the Internet, period.
I'm trying to follow the logic here.
-KB3VWG
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
3 May
3 May
3:19 p.m.
New subject: Request for Software - IP Protocol Filtering Measurement
Bart,
I confirm that I've also experienced the same symptoms on Comcast; but
the protocol number is 4 (IPENCAP). I suspected it for weeks and
determined it was occurring last week. I'm unable to tell with certainty
if it's dropped packets due to Comcast, or simply packets lost in transit.
It's not very wise to drop random encapsulated packets; because in most
cases, it would result in more traffic (e.g. a TCP encapsulated packet).
If you still wish to test this further, Ostinato is a packet
crafter/generator.
https://code.google.com/p/ostinato/
An easier method would be to setup a 44tunnel and directly ping another
user's node that happens to be on Comcast (my GW - 44.60.44.1).
-KB3VWG
6:46 p.m.
New subject: Request for Software - IP Protocol Filtering Measurement
Tom,
I think Steve was talking about the reference to a "cell site." If this
was about a Ham Radio network, it would be the first time I've ever
heard of a cell site operating according to Part 97 rules. I was
actually gonna ask Bart about that myself.
You mentioned that he was trying to identify ISPs that may not work well
with tunneling, his idea would not lead him to easilly discover that,
he'd have to run tests between a known good ISPs and the suspect ISP.
Notwithstanding, at Noon - Pacific time, all thread posts for the last
24 hours is sent out to all subscribers (with it's assigned Volume and
Issue number); Steve didn't start a new thread, he simply responded to
the daily digest.
-KB3VWG
8:22 p.m.
New subject: Request for Software - IP Protocol Filtering Measurement
On May 3, 2014 3:46 PM, <lleachii(a)aol.com> wrote:
I think Steve was talking about the reference to a
"cell site." If this
was about a Ham Radio network, it would be the first
time I've ever heard
of a cell site operating according to Part 97 rules. I was actually gonna
ask Bart about that myself.
"Cellular" describes a system where you have directional antennas and reuse
frequencies. For example, all antennas pointing north use 5920 MHz. Nothing
inherently anti-Part 97 there.
This page has a diagram. The "cell" Bart was talking about is referred to
as a distribution node here:
https://www.hamwan.org/t/tiki-index.php?page=Puget+Sound+Data+Ring
Tom KD7LXL
10:07 p.m.
New subject: Request for Software - IP Protocol Filtering Measurement
This page has a diagram. The "cell" Bart was
talking about is referred to
as a distribution node here:
https://www.hamwan.org/t/tiki-index.php?page=Puget+Sound+Data+Ring
Cool, thanks for the information.
-KB3VWG
4 May
4 May
9:57 p.m.
New subject: Request for Software - IP Protocol Filtering Measurement
Does this DNS zone exist online somewhere? Is there's an authoritative
nameserver that holds these entries?
If so, I'd like to setup my 44DNS server to just download the zone file.
I've been somewhat confused receiving an email of DNS entries every so
often. I'm wondering if there's supposed to be a resolver that holds
these records.
-KB3VWG
paine-s1.hamwan ADD CNAME ether1.paine-s1.hamwan.net
ether1.paine-s1.hamwan ADD A 44.24.240.131
wlan1.paine-s1.hamwan ADD A 44.24.240.145
corvallis-er1.hamwan ADD A 198.178.136.80
seattle-er1.corvallis-er1.hamwan ADD A 44.24.242.20
capitolpark.nq1e.corvallis-er1.hamwan ADD A 44.24.242.0
paine.k7nvh.corvallis-er1.hamwan ADD A 44.24.242.8
corvallis-srv1-kvm.corvallis-er1.hamwan ADD A 44.24.242.25
baldi.corvallis-er1.hamwan ADD A 44.24.242.2
paine.ae7sj.corvallis-er1.hamwan ADD A 44.24.242.4
wlan1.paine-s3.hamwan ADD A 44.24.240.177
ether1.paine-s3.hamwan ADD A 44.24.240.133
wlan1.paine.ae7sj.hamwan ADD A 44.24.242.7
corvallis-er1.hamwan ADD A 198.178.136.80
10 p.m.
New subject: Request for Software - IP Protocol Filtering Measurement
These are mistaken forwards to the mailing list, rather than the AMPR DNS robot. So, these
are HamWAN DNS records that would be added to the ampr.org zone. We are sending these
updates through our local coordinator, who has I assume occasionally mistyped the
destination address to forward to. HamWAN is using the ampr.org zone as a workaround until
we can get reverse DNS delegated so we can manage it ourselves on our authoritative
nameservers.
Thanks,
Nigel
K7NVH
On May 4, 2014, at 6:57 PM, lleachii(a)aol.com wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Does this DNS zone exist online somewhere? Is there's an authoritative nameserver
that holds these entries?
If so, I'd like to setup my 44DNS server to just download the zone file. I've
been somewhat confused receiving an email of DNS entries every so often. I'm wondering
if there's supposed to be a resolver that holds these records.
-KB3VWG
paine-s1.hamwan ADD CNAME
ether1.paine-s1.hamwan.net
ether1.paine-s1.hamwan ADD A 44.24.240.131
wlan1.paine-s1.hamwan ADD A 44.24.240.145
corvallis-er1.hamwan ADD A 198.178.136.80
seattle-er1.corvallis-er1.hamwan ADD A 44.24.242.20
capitolpark.nq1e.corvallis-er1.hamwan ADD A 44.24.242.0
paine.k7nvh.corvallis-er1.hamwan ADD A 44.24.242.8
corvallis-srv1-kvm.corvallis-er1.hamwan ADD A 44.24.242.25
baldi.corvallis-er1.hamwan ADD A 44.24.242.2
paine.ae7sj.corvallis-er1.hamwan ADD A 44.24.242.4
wlan1.paine-s3.hamwan ADD A 44.24.240.177
ether1.paine-s3.hamwan ADD A 44.24.240.133
wlan1.paine.ae7sj.hamwan ADD A 44.24.242.7
corvallis-er1.hamwan ADD A 198.178.136.80
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
10:08 p.m.
New subject: Request for Software - IP Protocol Filtering Measurement
That's exactly what happens....
________________________________
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
On Sun, May 4, 2014 at 7:00 PM, Nigel Vander Houwen <nigel(a)k7nvh.com> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
These are mistaken forwards to the mailing list, rather than the AMPR DNS robot. So,
these are HamWAN DNS records that would be added to the ampr.org zone. We are sending
these updates through our local coordinator, who has I assume occasionally mistyped the
destination address to forward to. HamWAN is using the ampr.org zone as a workaround until
we can get reverse DNS delegated so we can manage it ourselves on our authoritative
nameservers.
Thanks,
Nigel
K7NVH
10:15 p.m.
New subject: HamWAN DNS update
Delegated reverse DNS for 24.44.in-addr.arpa?
...that's interesting.
FYI, you listed A records, one was not a 44 address. You'll still need
those forward entries if you wish to reach a device by hostname.
Most records in the in-addr.arpa domain are PTR records. Also, just a
suggestion, you'll have to make sure that the DNS server is available
inside and outside AMPR, should it be delegated.
-KB3VWG
10:25 p.m.
New subject: HamWAN DNS update
Yes, When creating A records, If I recall (I haven't been handling our DNS updates)
PTR records are created, which is what we're after. We already manage our own A
records within the hamwan.net and hamwan.org domains.
We are aware of needing to have DNS servers be available to various sources, and our
authoritative (not recursive) servers already meet the need of serving external networks.
Nigel
K7NVH
On May 4, 2014, at 7:15 PM, lleachii(a)aol.com wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Delegated reverse DNS for 24.44.in-addr.arpa?
...that's interesting.
FYI, you listed A records, one was not a 44 address. You'll still need those forward
entries if you wish to reach a device by hostname.
Most records in the in-addr.arpa domain are PTR records. Also, just a suggestion,
you'll have to make sure that the DNS server is available inside and outside AMPR,
should it be delegated.
-KB3VWG
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
12:25 a.m.
New subject: IP Protocol Filtering
Greetings;
I have noticed that some of the internal routing within comcast hasn't
been as stable lately as it once was, and have especially noticed
extremely high latency between comcast.net and other cable based
networks such as rr.com from doing non-ipencap traces. This of course
would affect any ipencap frames trying to use the same path.
In regards to the thread that's _unnecessarily_ spawned off from this
same one, there's a huge difference between a protocol and a service.
ISP can filter protocols as most do OSPF, and some may indeed charge for
an OSPF based peer. I've yet, however, to see an ISP charge for a
protocol that a potential VPN would run on... I would think that would
kill corporate-based accounts for them.
--
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
23 Apr
23 Apr
10:26 a.m.
New subject: SIP on AMPRNet and announcing services
Actually, there are some SIP servers on AMPRNet
already; and I'm
capable of standing up a SIP server at my station. The only problem
personally is that there's not much of a reason to stand up multiple
SIP servers. Even if we did, it would be a good idea to standardize
the call scheme to interconnect them, so we could dial those with SIP
registrations on the various servers.
To deploy this kind of infrastructure we can
use a SIP Server like
("OpenSer"). This server will be a login server and a router server
(enroute call to the endpoints), and the mailbox and the rest of
services (echo test, text to speech, etc.) can be in individual Asterisk
Servers. With SIP we can implement Voice, presence and IM services.
In the other hand with SIP we can deploy RoIP (radio over IP) services.
for example HYT repeaters has a SIP interface to link to a PABX services
(like asterisk) using SIP protocol.
A few years ago, I was deploying a similar infrastructure into the
guifi.net network (Spanish wireless network).
I have more ideas to deploy services (cross-link DMR repeater to SIP
servers to make direct calls, for example), and I know that my spanish
colleague Alberto Sagredo will be interested in participate in this project.
Kind regards
Alex Casanova (EA5HJX)
Regarding announcing services:
What exactly do those who want services announced wish to accomplish
by having services announced over the network (and to the world if
added to the DNS)?
My idea was more-so that those who don't mind informing the AMPRNet
at-large that they have a service to share (and don't mind sharing
that information) could post it to the list.
-KB3VWG
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
3899
days inactive
3916
days old
35 comments
12 participants
participants (12)
-
Alex -
Bill Vodall -
Brian -
Brian Kantor -
Don Fanning -
Eric Fort -
K7VE - John -
lleachii.aol.com -
lleachii＠aol.com
-
Marius Petrescu -
Nigel Vander Houwen -
Tom Hayward