Loading ...
Sorry, an error occurred while loading the content.

Rebuilding 44 - Was: [dstar_digital] IPV6 for Starnet & Xrf?

Expand Messages
  • John D. Hays
    One of the uses I foresee for STARnet Digital is for it to support VPNs for D-STAR Digital Data. Currently, the D-STAR frame addresses one and only one
    Message 1 of 5 , Jan 29, 2012
    • 0 Attachment
      One of the uses I foresee for  STARnet Digital is for it to support "VPNs" for D-STAR Digital Data.  Currently, the D-STAR frame addresses one and only one destination.  The UR is either set to the gateway for NATing out to the Internet, or it is set to the call of a remote system.

      If the UR were to be set to STARnet Digital group, then each frame could be relayed back out to each terminal in the VPN/Group.  This still needs to be tested and probably refined.

      I think the Net-44 address space could be the unifying point for IP based amateur communications.  The NxN  
      text tables being distributed now to IPIP tunnel pockets of activity doesn't scale well and uses a format designed around a specific application.  I have been thinking, instead we should build a network around regional routers that each support one  44.x.x.x/16 address space (44.0-255.x.x) -- these could exist in a VPN (maybe LT2P) creating tunnels either to each other or through 1 or more continental/country routers.  

      In turn, these 256 POP routers, would support up to 256+ local networks (44.x.x.x/24), which in turn could distribute out to progressively smaller and smaller CIDR address spaces.

      When AMPRNET was created, the available hardware was either severely limited or financially unreachable for a hobby pursuit.  Now a US$40 router (http://routerboard.com/RB750 IPV4, IPV6, VPN, Tunnels, MPLS) can be pressed into service to provide these services (http://wiki.mikrotik.com/wiki/Manual:License#License_Levels) for any local jump off point to RF (even to a mesh or PTP high speed microwave link). The core routers can be had in the US$350 range (http://routerboard.com/RB1200).   There are a number of hams that own or have access to high bandwidth enabled data centers to house core and regional routers. 

      Additionally, with a little creativity we could  build a special DHCP that would examine the D-STAR, AX.25, or ??? frames to assign a Dynamic DNS address to each station (assuming amateur-relay.net as the domain, could be ampr.org):
      • In AX.25, if the source address was WF7R  and the SSID was 2 then Dynamic DNS records  would be created:
      • On D-STAR, if the mycall address was  K7VE and the 8th character (terminal ID) was C, then Dynamic DNS records would be created:
      Fixed stations and servers likely would have static IPs, but mobile stations, say D-STAR DD units moving from repeater/access point to repeater/access point could release and renew LAN IP addresses using DHCP.

      A STARnet Digital server could be modified to include a DHCP lease block for stations in the group/VPN, so mobile D-STAR stations would retain the same DNS entries moving from one repeater/access point to another.

      As the owner of the STARnetDigital Yahoo! forum, I invite anyone interested in this topic to reply to the thread there.


      John D. Hays
      K7VE
      PO Box 1223, Edmonds, WA 98020-1223 
        



      On Sun, Jan 29, 2012 at 04:55, Kristoff Bonne <kristoff@...> wrote:


      To bad this resource is so little used. There could be some nice things to can be done with this. Why not a "HAM VPN" connection radio-clubs worldwide to allow services like shared file-services, video-conf links, remote operations on receivers, etc. A bit like the equivalent VPNs using in the hackerspace communities.

      However, I guess a full discussion about this is probably offtopic here.

      > 73 Andre PE1RDW
      73
      Kristoff - ON1ARF
      --
      Kristoff Bonne <kristoff@...>

      __._,_.__
    • Andre
      ... There is a roaming block in ampr.org for people without a fixed LAN 44.192/24 and as far as I can tell nothing is asigned in that block so you can ask
      Message 2 of 5 , Jan 29, 2012
      • 0 Attachment
        --- In STARnetDigital@yahoogroups.com, "John D. Hays" <john@...> wrote:
        >
        > One of the uses I foresee for STARnet Digital is for it to support "VPNs"
        > for D-STAR Digital Data. Currently, the D-STAR frame addresses one and
        > only one destination. The UR is either set to the gateway for NATing out
        > to the Internet, or it is set to the call of a remote system.
        >
        > If the UR were to be set to STARnet Digital group, then each frame could be
        > relayed back out to each terminal in the VPN/Group. This still needs to be
        > tested and probably refined.
        >
        > I think the Net-44 address space could be the unifying point for IP based
        > amateur communications. The NxN
        > text tables being distributed now to IPIP tunnel pockets of activity
        > doesn't scale well and uses a format designed around a specific
        > application. I have been thinking, instead we should build a network
        > around regional routers that each support one 44.x.x.x/16 address space
        > (44.0-255.x.x) -- these could exist in a VPN (maybe LT2P) creating tunnels
        > either to each other or through 1 or more continental/country routers.
        >
        > In turn, these 256 POP routers, would support up to 256+ local networks
        > (44.x.x.x/24), which in turn could distribute out to progressively smaller
        > and smaller CIDR address spaces.
        >
        > When AMPRNET was created, the available hardware was either severely
        > limited or financially unreachable for a hobby pursuit. Now a US$40 router
        > (http://routerboard.com/RB750 IPV4, IPV6, VPN, Tunnels, MPLS) can be
        > pressed into service to provide these services (
        > http://wiki.mikrotik.com/wiki/Manual:License#License_Levels) for any local
        > jump off point to RF (even to a mesh or PTP high speed microwave link). The
        > core routers can be had in the US$350 range (http://routerboard.com/RB1200).
        > There are a number of hams that own or have access to high bandwidth
        > enabled data centers to house core and regional routers.
        >
        > Additionally, with a little creativity we could build a special DHCP that
        > would examine the D-STAR, AX.25, or ??? frames to assign a Dynamic DNS
        > address to each station (assuming amateur-relay.net as the domain, could be
        > ampr.org):
        >
        > - In AX.25, if the source address was WF7R and the SSID was 2 then
        > Dynamic DNS records would be created:
        > - wf7r-2 IN A 44.24.73.2 ; Using wf7r-2.amateur-relay.net domain
        > name set IP to 44.24.73.2
        > - 2.73.24.44.in-addr.arpa. PTR wf7r-2.amateur-relay.net. ; Shows
        > wf7r-2.amateur-relay.net on hostname lookup of IP 44.24.73.2
        > - On D-STAR, if the mycall address was K7VE and the 8th character
        > (terminal ID) was C, then Dynamic DNS records would be created:
        > - k7ve-c IN A 44.24.88.230
        > - 230.88.24.44.in-addr.arpa PTR k7ve-c.amateur-relay.net.
        >
        > Fixed stations and servers likely would have static IPs, but mobile
        > stations, say D-STAR DD units moving from repeater/access point to
        > repeater/access point could release and renew LAN IP addresses using DHCP.
        >
        > A STARnet Digital server could be modified to include a DHCP lease block
        > for stations in the group/VPN, so mobile D-STAR stations would retain the
        > same DNS entries moving from one repeater/access point to another.
        >
        > As the owner of the STARnetDigital Yahoo! forum, I invite anyone interested
        > in this topic to reply to the thread there.
        >
        > ------------------------------
        > 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>
        >
        There is a roaming block in ampr.org for people without a fixed LAN 44.192/24 and as far as I can tell nothing is asigned in that block so you can ask brian if it can be used for dhcp on starnet.

        How do you propose to handle routing when there are more then one lan in a subregional block, this has always been the drawback of tcp/ip on ax25, In the Netherlands blocks are parallel with Hroute areas and there are several laps opperating in the same Hroute area, one sysop could route all trafic of the Hroute area to his ports and leave users of laps that are downstream out in the cold.
        Adding another paralel network could make it even worse.

        73 Andre PE1RDW

        ps check out http://www.ampr.org/amprnets.txt and ftp://hamradio.ucsd.edu/pub/ampr.org for the current status of ampr.org and contact brian WB6CYT for posabileties of world wide blocks
      • John D. Hays
        Andre, I think local administration and network mapping can be handled locally, my intent is that overall we could rebuild network 44 into the universal IP
        Message 3 of 5 , Jan 29, 2012
        • 0 Attachment
          Andre,

          I think local administration and network mapping can be handled locally, my intent is that overall we could rebuild network 44 into the universal IP network for amateur to amateur IP networking.  The idea is that one (or more) routers would be setup for each administrative area.  E.g., I am the coordinator for 44.24.0.0/16  (65K addresses 44.24.0.0 - 44.24.255.255) and should have a router to forward traffic to and from those addresses. Within that address space we have a number of "LANs" e.g. 44.24.100.x - 44.24.127.x and so on.  Each of those LANs could have a router that is the "next hop" for anything in net 44 not directly known on the LAN.  Likewise, the Netherlands has 44.137.0.0/16, which may have a different topology. So if traffic needs to go from an address in 44.24.x.x to one in 44.137.x.x, the "Subnet-24" router would tunnel that traffic either directly to the "Subnet-137" router or could pass it up to a core router for "Net-44" which would forward it to "Subnet-137".

          How the LANs are organized below these regional "44.0-255/24" routers is up to local coordination and planning. There is nothing unique about whether those LANs are for D-STAR DD, AX.25, HSMM, etc., they are just address spaces.

          A single fixed station might have a static address in each of multiple, overlapping, LANs as they do now. That does not change. However, for mobile stations, they may be moving in and out of various LANs and loosing routing. 

          Lets look at one scenario that could happen, using 44.24.0.0 subnet as the prototype.

          We could determine we need some LANs for roving D-STAR DD stations, any given repeater/access point might only need 64 addresses split between fixed and DHCP addresses. So we take maybe 44.24.50.0/24 and subnet it to:
          44.24.50.0/26 (44.24.50.0-63)
          44.24.50.64/26 (44.24.50.64-127)
          44.24.50.128/26 (44.24.50.128-191)
          44.24.50.192/26 (44.24.50.192-255)

          Each would be assigned to a D-STAR gateway that supports D-STAR DD and the owner of that gateway would split those addresses up between fixed use and DHCP.  

          Lets say for the first case, 44.24.50.1-44.24.50.24 are allocated to fixed use and 44.24.50.25-44.24.50.62 are available for DHCP use. The rest of the network doesn't really need to know this is how they are allocated, they just need to know how to route to the appropriate next hop router to get to them.

          One of the weaknesses of the current D-STAR DD implementation is that they treat an entire class A network (16M addresses - 10.x.x.x) as a flat address space and didn't do any real network engineering. This means the user who plugs an IP device into his DD radio needs to know too much about the network and associating callsigns with hostnames (and how disable chatty OS network services). We really haven't done good network planning and design for a fully connected Net 44 network, often managing individual IP to callsign/SSID relationships at the station level.

          Having a roving, worldwide subnet only marginally makes sense on HF networks where propagation might allow a maritime station to participate in the network, but even then using DHCP as they move between shore stations/channels would likely be more effective.

          By rebuilding network 44 to be fully connected through a series of reliable tunnels between major (e.g. /16) subnets which further create smaller, right sized, LANs through CIDR allocations, will make the network more useful and more reliable.


          John D. Hays
          K7VE
          PO Box 1223, Edmonds, WA 98020-1223 
            



          On Sun, Jan 29, 2012 at 14:03, Andre <pe1rdw@...> wrote:
           
          There is a roaming block in ampr.org for people without a fixed LAN 44.192/24 and as far as I can tell nothing is asigned in that block so you can ask brian if it can be used for dhcp on starnet.

          How do you propose to handle routing when there are more then one lan in a subregional block, this has always been the drawback of tcp/ip on ax25, In the Netherlands blocks are parallel with Hroute areas and there are several laps opperating in the same Hroute area, one sysop could route all trafic of the Hroute area to his ports and leave users of laps that are downstream out in the cold.
          Adding another paralel network could make it even worse.

          73 Andre PE1RDW

          ps check out http://www.ampr.org/amprnets.txt and ftp://hamradio.ucsd.edu/pub/ampr.org for the current status of ampr.org and contact brian WB6CYT for posabileties of world wide blocks

        • John
          ... This does not break any laws, at least in most countries. AMBE is used in almost every modern digital voice system in the world. It is a part, like a
          Message 4 of 5 , Jan 30, 2012
          • 0 Attachment
            On Sun, Jan 29, 2012 at 23:07, Marius Petrescu <marius@...> wrote:

            Tis all looks very nice… in theory.

             

            First of all, the AMBE codec being proprietary and D-STAR being supported only by Icom, I don't see why to encourage such a commercial intrusion in or hobby (and I think this eve breaks a law or two…).


            This does not break any laws, at least in most countries.  AMBE is used in almost every modern digital voice system in the world.   It is a part, like a microprocessor or resistor.  It is patented, but so were AM, FM, SSB, etc. and that did not keep them out of amateur radio.  The vast majority of radios on amateur radio are manufactured by commercial interests (Yaesu, Motorola, Kenwood, Icom, Tait, Wouxun, Johnson, Ericsson, ...) 

            The D-STAR protocol is an open specification protocol and anyone can  implement it (and some folks are doing so in various projects and products).  Icom is the only "big name" manufacturer selling mobiles and handhelds (and now a base station) at the current time, but there is a lot of interesting homebrew going on right now and a few products out or in the works,

            But AMBE has nothing to do with what we are talking about here.  AMBE as a voice stream is not related to IP, other than gateways use UDP to do ROIP/VOIP.  D-STAR has two major payload formats.  The first is known as Digital Voice (DV), which carries AMBE interleaved with raw data (like a serial pipe) on a single bitstream. The other is Digital Data (DD), which is Ethernet frames encapsulated in D-STAR frames, those Ethernet frames can contain IP (or Appletalk, or Decnet, or XNS, ...) and this is where there is an opportunity to unify amateur radio IP communications. 

             

            The fact that the current 44 net doesn't rely on dedicated gateways (except 44.0.0.1 for relaying internet-ampr traffic) is a big plus and it reduces router bandwidth drastically.

            It is true, except some Cisco routers other don't support the NOS-IPIP encapsulation, and the current modified RIP dynamic routing works properly only on linux based machines.

            The current setup supports localisation of 44.x.x.x/16 segments without any change of the existing ampr arhitecture. So no one stops  a organisation/group to delegate the handling of a /16 or /24 network segment to a dedicated gateway and even provide VPN services (L2TP, PPTP, OpenVPN or whatever) by just cleaning all their subnet registrations and registering their single /16 or /24 subnet with one single gateway. 

            But in that case, all the subnets will rely on a single point of failure which is that gateway. And that gateway will depend on a single service provider, which can pull the plug anytime. And since amateur radio support is no money maker for that particular isp, that interest is low, and this will happen sooner or later. No one sponsors something whithout commercial purpose.

             


            It doesn't necessarily need to be a single point of failure as a properly engineered network using standard and modern technology can have fail over and redundancy.  It just takes planning and cooperation.  The difference is that with a cohesive plan we can have a mostly connected network.  Right now it seems to be mostly little pockets, often isolated, and underutilized. 

            I would also suggest that most Net-44 traffic would stay within Net-44, the "thin pipe" out to the rest of the Internet may or may not be a good thing.
             

            Imho it would be more interesting to port the 44 related stack elements (IPIP and 44RIP daemon) to embedded systems (OpenWRT beeing one) so it could work on low cost routers (including mikrotik and their nice MetaRouter environment) and even lobby the inclusion of NOS-IPIP in cheap routers (emphasizing on the backwards compatibility with traditional IPIP and flexibility of that solution).


            That is one approach.
             

            A simple gateway robot registration change will do, and it works. In my current setup, I provide gateway functions for 2 44.x.x.x/24 networks, including VPN access, and it works nicely (but sadly no one uses this beyond some testing).

             


            If its anything like what I've experienced, its because its mostly 1200 bps within islands of operation.  We need interesting applications and interesting applications come when there are enough nodes interconnected to create a user base.  Terminal to terminal "RTTY" on an IP stack encapsulated in AX.25 transport will not hold interest beyond, as you say, the occasional test or experiment.  Though for most experiments with IP, the commercial Internet provides a much richer environment. (I have 24mb/24mb symmetrical IP service over Fiber Optic cable to my house and could do local area stuff at much higher data rates over RF than is typical in amateur radio.)   
             

            Marius, YO2LOJ

             


             
          • John D. Hays
            Kristoff, ... Removed dstar_digital from the copy list. ... I do not consider this the primary purpose. The primary purpose, from my perspective is to use
            Message 5 of 5 , Jan 30, 2012
            • 0 Attachment
              Kristoff,



              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
              PO Box 1223, Edmonds, WA 98020-1223 
                



               
            Your message has been successfully submitted and would be delivered to recipients shortly.