On Mon, Jan 30, 2012 at 14:00, Kristoff Bonne <kristoff@...> wrote:
Hi John,
As this is a D-STAR list, I'll try to keep the discussion as much as possible on that topic.
Â
Removed dstar_digital from the copy list.
Â
About using 44.x.y.z addresses for connecting D-STAR nodes without a public ipv4 address.
,
The idea for these kind of sites is like this:
- the site is allocated a /29 subnet in the 44.x.y.z range
- the site must have either a public ipv6 address; or there must be some gateway (ipv4 or ipv6) that has direct connectivity to that endnode.
I do not consider this the primary purpose. Â The primary purpose, from my perspective is to use Net-44 for a common Amateur Radio IP network. Â The idea is to make Net-44 a connected network using tunnels to perform the interconnection of subnets. Â Kind of an uber-VPN, that sometimes reaches out to the rest of the Internet.
Â
So, ipv4 44.x.y.z traffic is tunneled, either in ipv4-over-ipv6 directly to the destination, or -if this is not possibble- in ipv4-over-ipv4 or ipv4-over-ipv6 to an intermedia gateway.
The problem is this: how does a node that wants to communicate to 44.x.y.z address know the endpoint of the tunnel it needs to set up. I agree that static tables do not scale.
The routers maintain the tunnels, not the end nodes. The end nodes simply address the destination node they want to reach, all the end node needs to know is its default gateway.
Â
But, doesn't D-STAR already HAVE a "control channel" insfrastructure that connects D-STAR repeaters? Ircddb!!!
Don't think in the DV space, this is simply an encapsulated transport for Net-44, the traffic is payload.
Â
- Ircddb is currently only used for multicasting information for callsign routing; but -unless I am wrong- I do not see any reason why it cannot be used to transport other information.
- ircddb is TCP based, using a outgoing connection from the D-STAR repeater to the ircddb servers. As it is "outgoing", it should work even for nodes that are behind one or more NAT routers
- there already exist irc server software is ipv6-enabled
- ircddb already provides access-control and authentification.
- the ircddb infrastructure already exists and is based on open standards and open source.
But, again, the goal is only to use this as "plan B" to allow communication between D-STAR nodes that do not have public ipv4 address.
This isn't about D-STAR or connecting D-STAR gateways per se, its about creating an IP network. Â If a D-STAR gateway uses it, that is merely an application.
Â
I agree this kind of setup could also be used to simply keep on running on ipv4-only software and tunning traffic if necessairy.
The setup described about is far from perfect. Simply move to ipv6 and transport everything natively in ipv6 will always be better then tunneling. It should not be an excuse not to migrate the D-STAR software to ipv6 !!!! :-)
73
Kristoff - ON1ARF
John D. Hays
K7VE
K7VE
PO Box 1223, Edmonds, WA 98020-1223Â 
 
 
  Â
Offline 
Send Email