Mario,
My take from your description of what things should be like:
It is NOT the internet. By design and on purpose. We are free to experiment and explore in there
Is that you are thinking of private address space. Use 10/8, or 192.168/16, or one of the others. That space is specifically designated to not be publicly routable. If your ideal is a private VPN mesh, that’s the space to do it in. the 44/8 space *IS* part of the internet. It *IS* BGP announced, and there are smaller subsections that are announced separately.
Brian’s point is entirely accurate. If the routing issues at UCSD got fixed, everyone could talk to everyone else just fine, including the rest of the internet. It was previously mentioned the benefits of the “authentication” coming from a 44/8 address provides:
That is only you. Others do. While it is not a particularly strong authentication, people do assume that traffic originating from 44.x is originating from or on behalf of a licensed ham, in particular if it is TCP traffic with successful handshake.
If the routing were fixed, it would still work that way. Routing for non BGP announced subnets would go through UCSD through the tunnels, and would show up with the 44/8 source address like you see from your current tunnel partners. So, your statement here, would be incorrect:
Assume I run a 44.x machine at home, and I am not connected via BGP, without IPIP I can reach you only from my commercial IP, hence I have to implement NAT. breaking 44<->44 transparency.
My understanding of the organization here is that 44/8 space is for the amateur radio community to use and experiment with. There’s nothing that says it can’t be directly announced, or that we have to use it for Part 97 traffic, or whatever else. We’re amateur operators, and each of us uses the space in different ways. Some of us happen to have some technical resources available that let us direct announce our subnets and take UCSD out of a SPOF for internet connectivity.
Actually, no. The conceptual breakage starts when, in the global BGP, more specific routes are announced from a different AS. 44/8 is assigned to ARDC/Brian, and is announced via the AS of UCSD. That ought to be an authoritative statement.
With modern traffic engineering like anycast etc. it is useful to slightly bend the rules. In practice, such non-standard BGP configurations can still be made to work, if the parties within the affected (AMPR-) net cooperate and are willing to apply some further "non-standard" configuration.
This is not non-standard. This is exactly how routing is supposed to behave, more specific routes win over less specific routes. Those of us who BGP announce our subnets have more specific routes, and traffic comes to us. The issue comes when routers have statically configured general routes (like at UCSD), and ignore the *ENTIRELY VALID* more specific routes. This is, again, what breaks connectivity between IPIP users, and the BGP users. If the UCSD gateway had proper routing, they could talk fine, with proper source and dest addresses as I talked about above.
Since UCSD is donating the connectivity for all the rest of the 44/ users, and option 2 involves a signifcant burden to them, and ARDC, being the authority over 44/8 apparently agree, how about you implementing #1 ?
I’m aware of several folks who have offered to provide redundant announces, and the HamWAN project I’m part of is working on a peering policy so that anyone who wants to BGP announce can do so through us. I appreciate that UCSD is donating bandwidth to the project, but the routing is *factually* causing issues. I’d like to see it fixed, and then we can all go about our merry way without having these ridiculous threads about what’s “right”. If you want to do IPIP, do that, if you want to do BGP, do that too. Routing should work in either case, and right now it’s not.
Nigel
On Jun 13, 2015, at 05:19, Mario Lorenz ml@vdazone.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hello Bryan,
Am 13. Jun 2015, um 03:40:28 schrieb Bryan Fields:
- not everybody can do BGP
Granted. But saying the only other solution is via a single world wide gateway is down right silly in 2015.
Oh, it has been subject of considerable debate for at least 20 years. The general problem is, if you have multiple entries into the one AMPR network, under different management, how do you prevent split-brain situations ?
I'm actually providing redundant connections to my users via BGP, matter of fact we just turned up another subnet for another AMPRnet /24 this week via BGP.
Technically, no, if you are not part of the IPIP cloud, you do not. You form your own island, hopefully related to amateur radio digital comms, using 44 IP space, and connect that, possibly redundantly, to the internet.
- accessing your network will require NAT on the remote end (unless the
YLs/OMs ISP allows her/him to originate IP packets with 44net addresses), NAT breaks end-to-end communications
I don't understand what part NAT plays in this.
Assume I run a 44.x machine at home, and I am not connected via BGP, without IPIP I can reach you only from my commercial IP, hence I have to implement NAT. breaking 44<->44 transparency.
Hence we would have no transparent 44<->44 connectivity anymore.
- you won't be able to differentiate between commercial access to your
44net and 44net traffic NATed to commercial IP
Again, I don't understand where NAT fits in this discussion/model. I don't differentiate between a 44/8 sourced IP and another. It's all internet traffic, there is no inherent security/authentication of 44/8 addresses.
That is only you. Others do. While it is not a particularly strong authentication, people do assume that traffic originating from 44.x is originating from or on behalf of a licensed ham, in particular if it is TCP traffic with successful handshake.
If this were "all internet traffic" anyway, then you shouldnt be using 44. address space.
I agree, however the configuration of a single gateway announcing 44/8 without the ability to reach more specific networks is _broken_ routing. Let me say this again:
Actually, no. The conceptual breakage starts when, in the global BGP, more specific routes are announced from a different AS. 44/8 is assigned to ARDC/Brian, and is announced via the AS of UCSD. That ought to be an authoritative statement.
With modern traffic engineering like anycast etc. it is useful to slightly bend the rules. In practice, such non-standard BGP configurations can still be made to work, if the parties within the affected (AMPR-) net cooperate and are willing to apply some further "non-standard" configuration.
If BGP users announce a subnet that 99.99999% of the internet can see, but IPIP users behind the UCSD gateway can't reach it, it's not BGP users that have broken routing, it's the silly UCSD gateway.
You are confusing Internet BGP users, and 44. users. When you are concerned about AMPR, you should be concerned about 44. first, and here your statistics will look way worse.
The situation can be fixed via two ways:
1)you set up an IPIP endpoint via which UCSD and all 44.x can reach your network. You, being a BGP based ISP, do consider this a non-standard solution.
2)UCSD's outer BGP gateway (which is not the box that Brian controls) currently routes 44/8 to Brian's gateway, likely via a high preference static route. That router would have to be taught either all the currently valid 44/x routes, or the exceptions. That involves, at a minimum, lots of effort for the UCSD network admins; and certainly they do not consider this a standard solution.
Well that's the thing, as the UCSD gateway is implemented now, it enforces islands of routing; the IPIP users are basically their own VPN on top of the internet with special addresses. It's a quasi-private GRX like network.
Exactly. It is NOT the internet. By design and on purpose. We are free to experiment and explore in there, without the fear of causing worldwide internet BGP instability, for example. If we wanted to play with the real internet, we could do that (you, having BGP access, being proof). Then we wouldnt need 44/ IPs.
The way to fix this so it works for the legacy IPIP users and standards compliant BGP users of the AMPRNET space is to fix the routing at the gateway. This is simple conceptually and in practice, but as ARDC is not a members organization there is little that can be done other than bitch about it on the list.
No. Thats only the one of the two ways you prefer.
Since UCSD is donating the connectivity for all the rest of the 44/ users, and option 2 involves a signifcant burden to them, and ARDC, being the authority over 44/8 apparently agree, how about you implementing #1 ?
Mario
-- Mario Lorenz Internet: ml@vdazone.org Ham Radio: DL5MLO@DB0ERF.#THR.DEU.EU _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net