44net December 2015

44net@mailman.ampr.org

32 participants
24 discussions

Misconfigured router?
by Brian 22 Dec '15

22 Dec '15

I'm getting bombed with these frames: -- IP: len 162 10.1.1.5->239.192.152.143 ihl 20 ttl 1 DF prot UDP UDP: len 142 40445->6771 Data 134 0000 BT-SEARCH * HTTP/1.1..Host: 239.192.152.143:6771..Port: 8999..In 0040 fohash: c28b3973f693bae99c1b0c13a137a051eef8d9d5..cookie: 5f9721 0080 ...... ax0: fm PY2ZEN-15 to QST ctl UI pid=CC(IP) len 162 IP: len 162 10.1.1.5->239.192.152.143 ihl 20 ttl 1 DF prot UDP UDP: len 142 40445->6771 Data 134 0000 BT-SEARCH * HTTP/1.1..Host: 239.192.152.143:6771..Port: 8999..In 0040 fohash: c28b3973f693bae99c1b0c13a137a051eef8d9d5..cookie: 5f9721 0080 ...... ax0: fm PY2ZEN-15 to QST ctl UI pid=CC(IP) len 162 IP: len 162 10.1.1.5->239.192.152.143 ihl 20 ttl 255 DF prot UDP UDP: len 142 6771->6771 Data 134 0000 BT-SEARCH * HTTP/1.1..Host: 239.192.152.143:6771..Port: 8999..In 0040 fohash: c28b3973f693bae99c1b0c13a137a051eef8d9d5..cookie: 5f9721 0080 ...... ax0: fm PY2ZEN-15 to QST ctl UI pid=CC(IP) len 162 IP: len 162 10.1.1.5->239.192.152.143 ihl 20 ttl 255 DF prot UDP UDP: len 142 6771->6771 Data 134 0000 BT-SEARCH * HTTP/1.1..Host: 239.192.152.143:6771..Port: 8999..In 0040 fohash: c28b3973f693bae99c1b0c13a137a051eef8d9d5..cookie: 5f9721 0080 ...... Someone have a misconfigured router? The only thing worse than an extreme left-wing state is an extreme left-wing commonwealth protected by the sovereign doctrine. 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

2 1

Re: [44net] Portal API: networks and allocations
by Rob Janssen 21 Dec '15

21 Dec '15

> Subject: > [44net] Portal API: networks and allocations > From: > Tom Hayward <esarfl(a)gmail.com> > Date: > 12/21/2015 08:53 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > I just looked through the portal API document > (https://portal.ampr.org/api.php) and don't see an endpoint for the > network list and the user's own allocation list. Is this currently > available? Can it be added? > > This would be useful for automation software. For example, you could > plug your AMPR portal username into the software and it would fetch > your list of allocations and automatically program your router to use > those allocations. > > Tom KD7LXL > You can do that by simply watching the RIP broadcast and filter your own external address. This is what ampr-ripd also does. Rob

2 1

Portal API: networks and allocations
by Tom Hayward 21 Dec '15

21 Dec '15

I just looked through the portal API document (https://portal.ampr.org/api.php) and don't see an endpoint for the network list and the user's own allocation list. Is this currently available? Can it be added? This would be useful for automation software. For example, you could plug your AMPR portal username into the software and it would fetch your list of allocations and automatically program your router to use those allocations. Tom KD7LXL

1 0

Re: [44net] Proposal for allocation of AS numbers
by Rob Janssen 18 Dec '15

18 Dec '15

Marius: > Coming back to the IP range/AS assignment: > > IMHO there must and shall not be such a correspondence. An AS is used to > group one or more subnets into an well, Autonomous System (AS), and it > should support, based on network architecture and layout, a possible > migration of subnets from/to a specific AS, without any changes in the > peering structure. > e.g. If there is a subnet with access via AS 1 it should be there. But if > later this subnet will be reorganized, and lets say will be accessed via AS > 2, it should be possible to move it to AS 2 without any change in the BGP > peering. This is not possible using AS numbers generated from IPs. The idea behind using the IP address to calculate the AS is to make sure that AS numbers are always unique, without having to use a registry and without having to coordinate. When there is more than one subnet, it does not matter which one is used to calculate the AS number. When the one that was used to calculate the AS is being moved, some care will be required so it is not used again for this purpose at the new site. Up to now we only route to the "regional subnet" level and each region has only a single subnet, so there are no problems. If an additional subnet is added and then the original one is moved there could be problems, but this is not likely. This whole thing can depend on local issues and policies, but it does not really matter how you do things locally as long as everyone uses the same method to generate the prefix of the number. I will stick to that E.212 thing as it uses only 3 digits and because others are already doing this. (if not, I would probably have removed the "44" digits and added 2 available digits at the end, as proposed by Robbie) Rob

7 15

Re: [44net] Proposal for allocation of AS numbers
by Rob Janssen 12 Dec '15

12 Dec '15

> Subject: > Re: [44net] Proposal for allocation of AS numbers > From: > Egbert - DD9QP <dd9qp(a)db0res-svr.ampr.org> > Date: > 12/11/2015 06:13 PM > > To: > 44net(a)hamradio.ucsd.edu > > > > > EU HAMNET has started thinking about using private 32bit-ASN quite some time ago. Diskussions in our regular meetings pulsed up since 32bit-ASN where available. > > But what we always were missing up to now was an international proposal for all countries using the 44-Net and, of course, a common agreement for using that. It makes no sense when everyone is rolling out a different System without talking to > others. Chances of crashing are high and planing isn't even worth the time. > > Regardless wether there is a registry, policy, human- or computerbased IP-Net-to-ASN-Generator out there, we all have to respect one minimal policy to keep everything running in the future: > > Don't use concurrent private-ASN-proposals in parallel! > Everything else is left to the countries themselves. > > For example: > Using the 42<mcc>xxxxxx in all countries is fine. But if some country starts using eg 42<IP-OctetofCountryDeployment>xxxxx there is high risk to crash with: > > Greece, Netherlands, Belgium, France, Monaco, Andorra, Spain, Hungary, Bosnia, Croatia, Serbia, Montenegro, Italy, Vatican, Romania, Switzerland, Czech Rep., Slovak Rep., Austria, United Kingdom, Denmark, Sweden, Finland, Lithuania, Latvia, > Estonia, Russia, Ukraine > > All of them have mcc-codes between 0 and 255. That is correct, that is why I decided to drop that proposal, although I still think it was better because: - it did not rely on another number list that has questionable status w.r.t. availability (my first attempts to download a complete list ended at some ITU site that requires a subscriber login, but later I found places where the full list is available in the open) - it handles the issue that the USA has much more network space relative to the number of E.212 entries - it left a lot of space in the private ASN range unused for future ideas (4225600000 - 4294967294) However, these issues are not that relevant in practice, and I am willing to go with the E.212 based system because it is already there. It gives all countries at least 100000 AS numbers to work with without any risk of duplicates, and some countries have more than one mcc number. That should be plenty, especially when they are not based on another number like a network address, but generated at some central site. Finally, when space ever runs out we can always assign "reserved" E.212 numbers as an overflow. 100000 numbers is a lot, and allows for regional subdivision where appropriate. Rob

1 0

Re: [44net] Proposal for allocation of AS numbers
by Rob Janssen 11 Dec '15

11 Dec '15

Unfortunately my mail connection broke down for a few hours shortly after I posted my proposal, so I missed most of the replies in my mail. I am now replying based on the archive, but this means it is difficult to quote your messages. Robbie: that is a good point. In my design I anticipated that one would not want to route a smaller network than a /24, but in fact that could happen in the AMPRnet. The reason I put the 44 in the AS number is to reduce the probability that an AS would collide with another private AS allocated using a different system. However, it of course uses precious space. See below. Marius: that is interesting. This is exactly the kind of response I hoped for, as I prefer to use a method that is already established rather than inventing my own. I found it appealing that the subnet address can be seen and recognized, these E.212 codes are obscure to me (but probably not to the person who invented this method). This method leaves 5 digits within the country range, which allows for smaller subnets as Robbie proposed. I see one problem: because there is no 1:1 mapping between E.212 code and AMPRnet /16 subnet, it will not always be possible to directly number the AS from the subnet. For typical European countries it will work well, but for the USA there is a "problem" because there are many more /16 subnets allocated to them than there are E.212 codes. Of course there are still more than enough AS numbers, but it means they need to use some registry instead of a direct derivation of the number. Pedja: as mentioned early in the message, these AS are not for use on the public internet but only on our private radio network. Gateways between radio and internet are supposed not to be running BGP across them, or to filter the private AS and send out the routing under their public AS. That is already happening. It looks like I will modify the system to look like this for our local use (and others are welcome to follow it: 42eeexxxyy where eee is the E.212 code, xxx is the third octet of the IP address, and yy is a local sequence number 00-99 in cases where multiple AS exist in that subnet. So for 44.137.40.0/22 it will be 4220404000 (204 is the E.212 code for the Netherlands which has 44.137.0.0/16) When I would want an AS for my personal subnet 44.137.41.96/28 it could be 4220404096 or some other arbitrary 42204040xx number. (for now, we only route to the regional subnets level) In my opinion, it is less easy to read than the first proposal, but of course it has the advantage of more AS space within the local area, and the fact that it is already established in some places. That is an important advantage. Rob

6 12

Re: [44net] Proposal for allocation of AS numbers
by DD9QP 11 Dec '15

11 Dec '15

On Thu Dec 10 01:13:16 PST 2015 Sam VK4AA wrote: > You are correct, but we cant count on everyone on the same playing field > But then this is a hobby of learning so it may take a while for us all to be > on the same page. Sam - for (maybe) you and all others who are not sure what the hell we are talking about those 32bit AS-numbers this nice article may be some help to get you on the same page: http://www.networkworld.com/article/2233273/cisco-subnet/understanding-4-by… It's nice to read and gives some hints on how to fit old 16bit and new 32bit ASNs together. (Thanks to Thomas DL9SAU for finding this article in the net.) So whatever method should be used, it should assure to map "old" 16bit-ASNs to the new 32bit-ASNs in a way as easy as possible. Keep in mind that in Europe there is a "European HAMNET" driven by 16 countries. It was founded in early 2000s and is using 16bit-ASNs because the 32bit-range was not available at that time. There is a registry to avoid ASN-doubles and it is working very well. As I know it is by far the largest bgp-driven network within the 44-Net worldwide, as far as the number of countries, number of participants and area is concernd. For more info about that see links at bottom of this mail (all in english). Either the 42<mcc>xxxxx or the 42<dxcc>xxxxx proposals give the chance to map old 16bit-ASNs 1:1 into the new 32bit-ASNs because they leave the lower 16bit-part to the countries for individual use. Even an IP-subnet-coded ASN like e.g. for Austria 42143xxxxx would fit this. The first proposal from Rob PE1CHL does not. It is incompatible to everything that was used or proposed before. Glad to hear that Rob is willing to change this. I don't think that the discussion about either 42<mcc>xxxxx or 42<dxcc>xxxx is only cosmetical. We must keep in mind different sizes of different countries and there networks. MCC has 7 # for USA and 2 # for China. Each other country has 1. Within DXCC every country has 1 # ready to go. I agree with Marius YO2LOJ: At a first glance the mcc proposal seems to be prefereable because it allows more ASN-Range for big countries on the go. On DXCC-numbers something has to be added to make it recognize different sizes of countries. That causes unnecessary work and - to say it with Peja's words: "you will have to provide mapping table and make sure it is updated all the time." for dxcc. I would be very glad to have a worldwide usable sulution (proposal) for the whole 44-Net which is commonly accepted and published on a central site. This gives all new countries willing to join a bgp-routed network within 44-Net something at hand they can deal with from startup. Don't let us hesitate on this topic and let's plan it very well. 73s de Egbert DD9QP -- Infos about European Hamnet: https://www.tapr.org/pdf/DCC2014-TheEuropeanHAMNET-DG8NGN.pdf https://www.youtube.com/watch?v=3A6DDrJRcws

2 1

Re: [44net] Proposal for allocation of AS numbers
by Rob Janssen 10 Dec '15

10 Dec '15

> Subject: > Re: [44net] Proposal for allocation of AS numbers > From: > Egbert - DD9QP <dd9qp(a)db0res-svr.ampr.org> > Date: > 12/10/2015 08:46 PM > > To: > 44net(a)hamradio.ucsd.edu > > > >> Well... We have been using that but the exact reason for this whole >> proposal >> was that I was extremely p*ssed off this week ... > > LOL > > Rob - > > I think this is not the plenum and thread to discuss your emotional situation. > > As I have heard some 3 weeks ago you occupied an additional ASN which was advertised to Slowenia since 2012 without asking maintainers or anybody else and without agreement from slowenia for using it. Well thats community rules and it works for 16 > countries. I personaly think you did it by mistake because it was documented well only on 2 Sites in the net and you had no time to read it or ask some of the maintainers. Taking all this into account I can understand that others than you had some > more reasons to get p*ssed off. We were told that the place to register information was hamnetdb.net and indeed there is a list of AS numbers there. When we ran out of the 4 assigned numbers I took the next one (skipping one that was registered to Slovenia) which was not registered. It was only later that it turned out that there is another place where "blocks" of AS numbers are handed out, and not being registered on hamnetdb does not mean the AS is available. In my experience, asking something to the maintainer of hamnetdb is not an effective way of getting knowledge. > > >> Initially we (the Netherlands) got an allocation of 4 AS numbers,... > > This was kind of an an initial "dummy" block assigned in 2010-2012 when the netherlands not even were thinking about joining that Network. We never heard of them until end 2014. Believe it or not: It was some German Guys that proposed in a very > early planing phase to put the netherlands in for future use because they could not believe that the Netherlands would not be interested in the future. Some more guys that have reason to get p*ssed off now? Well it's your decision not to > participate. Whenever a country ran out of ASN-space it got some more, without doing a caroussel for all others, but _after_ a request to the community/registry. Packet radio has been all but dead here for over a decade, because of the fast deployment of flatrate always-on internet in our densely populated country. The interest in radio networking has only come back the past 2 years. We are setting up a network for experiments and for our multisite repeater network. We are more interested in experimenting than in copying a network concept that has already been rolled out elsewhere. We want to make sure we can interface with others, but we for sure don't want to walk on other people's leech. For example, we have a completely different view on how our network interfaces with Internet than your group has. And I think that is good, you should not blindly follow our ideas either. We were notified of the AS allocation only last year, but apparently it existed longer than that. It turned out that the German Guys had decided how to divide the Netherlands into regions without discussing that concept with us. That is not the way we work anymore here, and it has been some time. Would you have deferred that allocation until after some discussion, that would also have been the moment to explain how those allocations are made and where they are registered. That never happened. But anyhow, the problem was not that I had mistakenly taken an AS number that turned out to be assigned to someone else. I immediately offered to move that AS and asked for another block of numbers to put the AS and the next ones we needed. What p*ssed me off is the SILLY policy of that registry that the AS numbers are assigned to a country by contiguous block, that the blocks are allocated without any space between them, and that the only way to get a block extended is to allocate a new block and move everything over. Now, that would not have been too hard for the 5 numbers that we had in place, but I just don't want to be using a registry with a silly policy like that (there is no reason whatsoever why AS numbers need to be allocated in contiguous blocks!) and risk more and more useless renumbering in the future, so the decision was made to evacuate immediately to avoid further damage. (I was alerted to similar problems experienced by the people operating the DMR repeaters here and they have made a similar move recently) Fortunately the availability of the 32-bit AS range means that there is no need for cooperation with people that want to manage others. We can just setup a system like the one we are discussing now, and there is no more need to work overtime to please the German Guys. > > Rob, what you brought into this list is a question of behavior and how one should interact with a community, but it has nothing to do with technical reasons, so I am not willing to discuss this any more on this list or in this thread. > I think I have explained what the problem was and why we don't want to use your registry anymore. It has policy that has nothing to do with technical issues. The result is problems like the one we experienced. Indeed there is no need to reply anymore. Our position is clear, and the whole problem has been worked around. You can delete our registration, I have already removed all those AS numbers from hamnetdb objects. Rob

1 0

Re: [44net] Proposal for allocation of AS numbers
by Rob Janssen 10 Dec '15

10 Dec '15

DD9QP: > Keep in mind that in Europe there is a "European HAMNET" driven by 16 > countries. It was founded in early 2000s and is using 16bit-ASNs because > the 32bit-range was not available at that time. There is a registry to > avoid ASN-doubles and it is working very well. Well... We have been using that but the exact reason for this whole proposal was that I was extremely p*ssed off this week when I discovered that this registry only wants to allocate 1 contiguous range of AS numbers per country, and allocates only tiny ranges. Every time one outgrows the range of numbers, one is supposed to renumber the entire network. What a joke! Initially we (the Netherlands) got an allocation of 4 AS numbers, and when we needed more, the range immediately after that turned out to be already allocated since before we got our 4. So we apparently had been put in a hole left by someone else moving. When I noted that I did not like this and would like a second block to expand our allocation, the owner of the adjacent block was requested to renumber!!! He even complained that he had to renumber twice before. Then, we could expand our allocation to 19. And this process was completed before I even could note that I did not want to make others do the work that I did not see as useful. So then the decision was made to leave that registry and find another solution where neither we or others were forced to renumber or live with sub-optimal solutions (trying to limit the number of ASN). Our block can be returned to the free pool or be given back to the previous owner in case he did not start the actual renumbering work. Rob

2 1

Proposal for allocation of AS numbers
by Rob Janssen 10 Dec '15

10 Dec '15

Some of the radio networks implementing AMPRnet use BGP as a routing protocol, and therefore require some AS numbers that should be unique within those networks. Note I am not referring to BGP routing on internet, but only within local radio networks. There usually are one or more gateways that are connecting those networks to internet, but BGP routing information is not carried across them, they only route a fixed subnet and may or may not use BGP on the inside as well. It is customary to use AS numbers from the "private AS ranges" on those radio networks documented in RFC6996: 64512 - 65534 and 4200000000 - 4294967294. The first (old) range has 1023 available numbers, so it requires some registry where individual areas can get numbers allocated to them to guarantee the uniqueness of the numbers within the network. As always, the policies of such registries lead to discussion and feelings, and I like to solve that by making the allocation fixed up to the regional level, so everyone can determine their own numbers without having to agree with others how it is done exactly and how many numbers each one requires and will get, and whether they need to be changed. Since 2009, BGP implementatations must support 32-bit AS numbers, and the second larger range has become available. My proposal is to map the assigned IP address ranges for countries and states directly to AS numbers in this AS range. Advantages: - the range of AS numbers automatically remains contiguous for countries and regions. - no need for an "international" registry, and probably not even for a "national" registry. - local operators can derive the AS number for their region from the local subnet address. - very sparse use of the available space makes for very low chance of conflicts, even in the presence of other private AS numbers that were allocated outside of this system. - future proof as there is no 1023-AS limit for the AMPRnet radio networks. - very easy to mnemonically map an AS number seen in a table or trace to the place where it is allocated, without need to refer to an allocation database. I propose the following AS number structure: For an IP network with the address 44.xxx.yyy.0/zz, the AS number will be: 4244xxxyyy. E.g. for my local network 44.137.40.0/22 the AS will be 4244137040. When areas of AS allocation are larger, an arbitrary subnet (e.g. the first) within that area can be used to derive the AS number. Alternatively, a national allocation system can be set up to manage the range available for a country or state when local operators like to do so, and use registered AS numbers from 000-999 within the range derived from the /16 address. E.g. the Netherlands has 44.137.0.0/16, so we can use the 1000-number AS range of 4244137000-4244137999 and subdivide it the way we like. There may be a slight chance that some very old equipment would not support 32-bit AS numbers, but the popular MikroTik, Ubiquiti and Linux(quagga) routers have no issue at all, and there is some interoperability with peers running the older version. I'd like to hear the opinions on this and possible enhancements/modifications. Rob

8 9

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net December 2015