Just FYI: Leo's email address is <leo.vegoda@icann.org> Regards, -drc On Feb 20, 2008, at 10:34 AM, Matthew Petach wrote:
Notes from day 4 of NANOG 42, we're on the home stretch now, so there's only a bit more of my spewage to wade through before we can resume our normal discussion of the imminent death of the internet as we know it. :)
Again, apologies for typos, misspellings of names, etc.
Matt
2008.02.20 opening remarks and analysis of PTR queries for IPv4 reserved addresses
Trying to measure use of unallocated IPv4 address space
Starting with Leo Vigoda, working at IANA now. leo.vigoda@icann.org
At last NANOG, did lightning talk about how people were using unallocated space, but didn't show lots of data.
Now, has a way to hopefully measure IPv4 addresses that people are trying to use.
Not all the addresses, but at least one view of it.
Problem? All unallocated unicast space will eventually be allocated; no more free /8's in the IANA pool at some point, as v6 won't get rolled out in time.
Some people are using the same addres space that's currently in the 'unallocated' pool.
Tried to measure it by looking at DNS queries at l.root for addresses in the unallocated blocks. root servers provide in-addr.arpa delegations, if a /8 isn't allocated, there's no delegation, so the root servers see the queries.
Can't measure well-maintained networks with split-horizon DNS, or with good egress filters.
Doesn't know how to measure truly private internal use; if you have ideas, let him know.
Results slide; long blue line at the far left, lots and lots of queries, then shallows off to the right side; some old rubbish names in in-addr people are querying for.
Left side is the fun stuff.
222/8, allocated to APNIC; not sure why it gets a lot more queries than the other /8's. Could be mail server lookups, since there's a lot of mail that comes out of 222/8; could be one rogue server. If you assume it's bogus, and chuck it out, data 'looks' better. 10/8 is near the top, as expected. 0/8 RFC3330 2/8 is unallocated; in the top 15 range. Odd there's unallocated space so close to the top of the queries range. If you take out all the unallocated stuff, there's still a lot of entries; looking at top 10 list: 2/8, 1/8, 23/8, 5/8, 100/8 is there at #5, which is odd. the next /8's they *were* going to give ARIN were 100/101, they decided to NOT give it out to figure out why there's so many hits on it in this round.
The top 10 list is the 30 day period ending sunday; he also compared to statistics he used at the esNOG meeting in madrid a few months ago.
Not very static; people leave top 10, new come on.
28dec-26jan, vs 19jan to 17feb
2/8 and 1/8 stay in #1 and #2 other /8s shift; 5/8 rises, 23/8 rises, 100/8 drops, 27/8 drops.
It's not static, there's movement, people are shifting and shuffling blocks.
Not measuring the query source address and AS # that could be gathered to inform people they're trying to talk to unallocated space.
Only gathering from l.root, would be good to get data from other root servers.
Leo's not a proper researcher, so would be good to get skillset from a real researcher.
Would like to get data from nodes all over the world to get more global information; can see if there's more of a local component, or if this is a global phenomenon. This would be a very big data analysis challenge, combining l, k, and other root server operators, and get a more complete view of the data.
Use it to either warn people, or help get things fixed if at all possible.
Q: Louis Lee, Equinix, want to find out if they've looked to see if the top10 prefixes are in the global routing table when the queries come in? A: No, that hasn't been looked at, but a proper researcher would probably have considered and tied that data in as well.
Q: Leo Bicknell, ISC: did they look at the source of queries? Are they all coming from a common resolver? A: no, not yet; would be the sort of thing that a proper researcher would be able to dig into. There are privacy considerations with looking at sources of queries, etc; needs to be thought through very carefully to make sure no per
Q: Keith Mitchell, Interesting work, thanks Leo; there's lots of information for gathering, sharing, and protecting privacy in OIRC; if he would like to work with OIRC, they can give pointers on how to handle that data with necessary
Q: further instrumenting to see if there's noise in the allocated space to see if this may be just part of overall background noise? A: this is the raw, basic data
Q: Duane Wessels, measurement factory; DNS queries behave differently when a result exists vs doesn't exist; may be worthwhile to temporarily make them exist on a set of servers, and collect the data from there, and see if the resolution process follows the delegation.
Q: Troy Jessup, Utah edu network; could 1, 2, 100, etc. network queries be due to malware that starts at one end of a block and just starts scanning indiscriminantly. 100 seems to be a common starting point for malware, for example. Haven't looked into it in that much detail--is it just 1.1.1.1/32, or 1.1.1.1/16, how much coverage within the block is there? is it just hot spots? These are really good ideas for the Real Researcher(tm) to delve into, once one can be tracked down.
If people want to send suggestions, email him at
leo.vigoda@icann.org