On Thu, 17 Jun 2010, Mark Andrews wrote:

Why was this traffic hitting your DNS server in the first place? It should have been rejected by the ingress filters preventing spoofing of the local network.

When I ran a smaller simpler network, I did have input filters on our transit providers rejecting packets from our IP space. With a larger network, multiple IP blocks, numerous multihomed customers, some of which use IP's we've assigned them, it gets a little more complicated to do. I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. The ACLs wouldn't be that long, or that hard to maintain. Is this common practice? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

On 6/16/2010 7:43 PM, Jon Lewis wrote:

On Thu, 17 Jun 2010, Mark Andrews wrote:

...

Why was this traffic hitting your DNS server in the first place? It should have been rejected by the ingress filters preventing spoofing of the local network.

When I ran a smaller simpler network, I did have input filters on our transit providers rejecting packets from our IP space. With a larger network, multiple IP blocks, numerous multihomed customers, some of which use IP's we've assigned them, it gets a little more complicated to do.

I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. The ACLs wouldn't be that long, or that hard to maintain. Is this common practice?

-

Sounds like a good use of URPF.

urpf doesn't work as well for stopping inbound traffic to your network, because most people aren't totally defaultless, so the default route makes all traffic valid. It works well for outbound traffic. On Jun 17, 2010, at 12:38 AM, Roy wrote:

On 6/16/2010 7:43 PM, Jon Lewis wrote:

...

On Thu, 17 Jun 2010, Mark Andrews wrote:

...

Why was this traffic hitting your DNS server in the first place? It should have been rejected by the ingress filters preventing spoofing of the local network.

When I ran a smaller simpler network, I did have input filters on our transit providers rejecting packets from our IP space. With a larger network, multiple IP blocks, numerous multihomed customers, some of which use IP's we've assigned them, it gets a little more complicated to do.

I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. The ACLs wouldn't be that long, or that hard to maintain. Is this common practice?

-

Sounds like a good use of URPF.

On 2010.06.17 17:10, William Herrin wrote:

On Thu, Jun 17, 2010 at 12:38 AM, Roy <r.engehausen@gmail.com> wrote:

...

On 6/16/2010 7:43 PM, Jon Lewis wrote:

...

With a larger network, multiple IP blocks, ***numerous multihomed customers***, some of which use IP's we've assigned them, it gets a little more complicated to do. I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers.

Sounds like a good use of URPF.

Reverse path filtering + asymmetric routing = epic fail. Jon did say Multihomed customer.

What RPF can do in this case though, is pro-actively prevent possible future problems. If all IP blocks are tied down to null, and urpf is enabled in loose mode on an interface, it will catch cases where someone is sourcing traffic to you using IPs from the unassigned space that you have in your free pools. Every month or so I re-route my blackholed traffic to a sinkhole, and more often than not, I see some ingress traffic from my unassigned space. Steve

On 2010.06.18 08:49, Chris Adams wrote:

Once upon a time, Steve Bertrand <steve@ipv6canada.com> said:

...

If all IP blocks are tied down to null, and urpf is enabled in loose mode on an interface, it will catch cases where someone is sourcing traffic to you using IPs from the unassigned space that you have in your free pools.

That's not true on JUNOS devices - discard routes still count as valid routes for loose-mode uRPF.

Are you saying that JUNOS will not drop on source even if the only valid route for an IP address is to null? On any other router I've used, null/disc etc is a valid route, but it is considered special in that if the route is to null, discard it, even on source. Steve

On 2010.06.18 09:06, William Herrin wrote:

On Fri, Jun 18, 2010 at 8:37 AM, Steve Bertrand <steve@ipv6canada.com> wrote:

...

If all IP blocks are tied down to null, and urpf is enabled in loose mode on an interface, it will catch cases where someone is sourcing traffic to you using IPs from the unassigned space that you have in your free pools.

I'm not sure what that accomplishes. It doesn't close any doors. With loose-mode RPF he can still forge packets from any address actually in use.

yes, that is correct. However, it stops someone from outside sending your network packets with a source address that currently resides in one of your free pools. What it does, is prevents packets with the illegal IP address from actually being delivered to the intended destination within your network preserving some (perhaps a very small amount) of bandwidth/router resources. For instance, if I send your mail server a packet with a source of one of your IPs that you currently do not have in use and you don't have rpf enabled, the forged packet will make it to the server, be sent back to it's next-hop, and then be discarded (if you have tie downs). With urpf enabled, the packet is discarded upon the first ingress into the network, thereby preventing it from going any further. This is what I use loose mode for anyway. Steve

For those that missed the presentation, it was a real eye-opener on just how important it is for you to move forward with IPv6 before something like this actually starts getting implemented. Owen On Jun 17, 2010, at 10:31 AM, Todd Underwood wrote:

jon, all,

i've received several questions about the context of this mail, so i thought it would be worth posting to clear up the reference.

for those who missed it, i presented a lightning talk at nanog 49 in san francisco yesterday on some very early conceptual work on a really interesting strategy to dramatically extend the useful life of v4 prefixes. the talk is linked from: http://nanog.org/meetings/nanog49/agenda.php and i encourage people to take a look at it.

if you like the general idea (Probabilistic Assignment of Prefixes: a System for Managing and Extending Address Resources is what some people are starting to call it), i'd encourage you to take the suggestion made at the mic by mark kosters, cto of arin, and work to help refine the proposal and establish a useful policy framework around its implementation.

work is needed especially in collision domain modeling and count of resource implications for the operational overhead per prefix. experience with high flow rate instrumentation is likely to be needed in the near future as well.

i wanted to thank everyone for the kind words and suggestions after the presentation and look forward to productively exploring this idea.

cheers,

todd underwood toddunder@gmail.com

On Thu, Jun 17, 2010 at 1:31 PM, Todd Underwood <toddunder@gmail.com> wrote:

jon, all,

i've received several questions about the context of this mail, so i thought it would be worth posting to clear up the reference.

for those who missed it, i presented a lightning talk at nanog 49 in san francisco yesterday on some very early conceptual work on a really interesting strategy to dramatically extend the useful life of v4 prefixes.  the talk is linked from: http://nanog.org/meetings/nanog49/agenda.php and i encourage people to take a look at it.

...nothing to see here, this is CGN's...

-----Original Message----- From: Todd Underwood [mailto:toddunder@gmail.com]

firstly: cgn puts reachability in the hands of a single organization. with the PAP System you have a set of distributed choices about reachability: different people can assess their different tolerance to certain kinds of unreachability.

Well, your proposal gives each "single organization" the same control as CGN. Except that if you announce somebody else's prefix, you're forcing your neighbors to choose whether to accept your announcement or the other organization's.

as i said in the presentation, the probability that there will be positive operational overhead for a prefix is related the the count of reuse within an association domain for a prefix ( p(Oop) = Cr(Ap) ). We need to work out how to subdivide which parts of the internet actually want to communicate directly with each other reliably and make sure that they are within association domains.

Yes, exactly. To minimize p(Oop), you need to consider what you'll leak. Generally, squat only when p(Oop) is very small, ideally when you can keep it all in. But seriously (and less scatalogically), when organizations can't get IPv4 addresses from their RIRs, some are likely to try using numbers registered to other organizations. In order of preference, they will use: 1) Globally unique, registered space 2) RFC1918 space 3) Space registered but unrouted (and unlikely to be routed) (see below) 4) Space registered and in use by someone very far away "Registered but unrouted" would include space that is in use in large private networks that aren't visible from your standard sources for route views, such as U.S. DoD (6, 11, 22, 26, 28, 29, 30 /8) or U.K. MoD (25/8). I've heard that some organizations are growing beyond rfc1918 space and starting to use addresses like these already (for devices not capable of IPv6) for internal networking (not publically routed). I believe this is generally considered bad citizenship, but I'm interested in why? Is there a range most people camp on? Lee

I just checked all those /8's none of them are in the table. -jim Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: Michael Dillon <wavetossed@googlemail.com> Date: Sat, 19 Jun 2010 17:39:07 To: Lee Howard<lee@asgard.org> Cc: <nanog@nanog.org>; Todd Underwood<toddunder@gmail.com> Subject: Re: Todd Underwood was a little late " "Registered but unrouted" would include space that is in use in large

private networks that aren't visible from your standard sources for route views, such as U.S. DoD (6, 11, 22, 26, 28, 29, 30 /8) or U.K. MoD (25/8).

Have you verified each of these address ranges or are you just a mindless robot repeating urban legends? By your definition, there is an awful lot more "registered but unrouted" space and researchers have been reporting on this for 10 years or more. In order to correctly identify what you think you are talking about, you need to take into account the date a range was registered and the date that you scanned the data. If the difference between the two dates is less than some small number, say one year, then it is probably routed space which has not yet been routed but soon will be. Different people will want to set that breakpoint at different timescales for obvious reasons. I encourage someone to do the work to list all such ranges along with the dates, and supply them as a feed, like Cymru does. Best would be to allow the feed recipient to filter based on age of block.

I've heard that some organizations are growing beyond rfc1918 space

Many organizations have grown beyond RFC 1918 space. The first ones that made it known publicly were cable companies about 15 years ago. And lets not forget that RFC 1597 and 1918 were relatively recent inventions. Before that, many organizations did "adopt" large chunks of class A space. One that I know of used everything from 1/8 to 8/8 and there were multiple disjoint instances of 1/8 in their many global networks. People have been building global networks with X.25 and frame relay transport layers for a lot longer than many realize. And the Internet did not become larger than these private networks until sometime in 1999 or so.

and starting to use addresses like these already (for devices not capable of IPv6) for internal networking (not publically routed).  I believe this is generally considered bad citizenship, but I'm interested in why?

Stupidity. Many people have no historical perspective and think that the only users of I{P address space that matter are ISPs. I don't consider it bad citizenship if the "adopted" space is not routed publicly, and even the definition of "publicly" is hard to pin down. If someone wants to route such space to a 100 or so ASNs in Russia, Kazakhstan, Kirghizstan, Uzbekistan, Afghanistan and China, then I don't think that they are blatantly being bad Internet citizens. Particularly if they carefully chose whose addresses to "adopt".

Is there a range most people camp on?

No. And it would be dumb to do that. Smarter is to use some range that nobody else is known to be camping on except the registrant and their network is geographically distant from yours. --Michael Dillon P.S. At this point, the IPv6 transition has failed, unlike the Y2K transition, and some level of crisis is unavoidable. In desperate times, people take desparate measures, and "adopting" IP address ranges that are not used by others in your locality seems a reasonable thing to do when economic survival is at stake. P.P.S. I saw a report that someone, somewhere, had analysed some data which indicates that IP address allocation rates are increasing and there is a real possibility that we will runout by the end of this year, 2010. Does anyone know where I can find the actual analysis that led to this report?

I see 11.2/16 in my table.

-----Original Message----- From: deleskie@gmail.com [mailto:deleskie@gmail.com] Sent: Saturday, June 19, 2010 10:10 AM To: Michael Dillon; Lee Howard Cc: nanog@nanog.org; Todd Underwood Subject: Re: Todd Underwood was a little late

I just checked all those /8's none of them are in the table.

-jim Sent from my BlackBerry device on the Rogers Wireless Network

-----Original Message----- From: Michael Dillon <wavetossed@googlemail.com> Date: Sat, 19 Jun 2010 17:39:07 To: Lee Howard<lee@asgard.org> Cc: <nanog@nanog.org>; Todd Underwood<toddunder@gmail.com> Subject: Re: Todd Underwood was a little late

" "Registered but unrouted" would include space that is in use in large

...

private networks that aren't visible from your standard sources for route views, such as U.S. DoD (6, 11, 22, 26, 28, 29, 30 /8) or U.K. MoD (25/8).

Have you verified each of these address ranges or are you just a mindless robot repeating urban legends?

By your definition, there is an awful lot more "registered but unrouted" space and researchers have been reporting on this for 10 years or more. In order to correctly identify what you think you are talking about, you need to take into account the date a range was registered and the date that you scanned the data. If the difference between the two dates is less than some small number, say one year, then it is probably routed space which has not yet been routed but soon will be. Different people will want to set that breakpoint at different timescales for obvious reasons.

I encourage someone to do the work to list all such ranges along with the dates, and supply them as a feed, like Cymru does. Best would be to allow the feed recipient to filter based on age of block.

...

I've heard that some organizations are growing beyond rfc1918 space

Many organizations have grown beyond RFC 1918 space. The first ones that made it known publicly were cable companies about 15 years ago.

And lets not forget that RFC 1597 and 1918 were relatively recent inventions. Before that, many organizations did "adopt" large chunks of class A space. One that I know of used everything from 1/8 to 8/8 and there were multiple disjoint instances of 1/8 in their many global networks. People have been building global networks with X.25 and frame relay transport layers for a lot longer than many realize. And the Internet did not become larger than these private networks until sometime in 1999 or so.

...

and starting to use addresses like these already (for devices not capable of IPv6) for internal networking (not publically routed).  I believe this is generally considered bad citizenship, but I'm interested in why?

Stupidity. Many people have no historical perspective and think that the only users of I{P address space that matter are ISPs. I don't consider it bad citizenship if the "adopted" space is not routed publicly, and even the definition of "publicly" is hard to pin down. If someone wants to route such space to a 100 or so ASNs in Russia, Kazakhstan, Kirghizstan, Uzbekistan, Afghanistan and China, then I don't think that they are blatantly being bad Internet citizens. Particularly if they carefully chose whose addresses to "adopt".

...

Is there a range most people camp on?

No. And it would be dumb to do that. Smarter is to use some range that nobody else is known to be camping on except the registrant and their network is geographically distant from yours.

--Michael Dillon

P.S. At this point, the IPv6 transition has failed, unlike the Y2K transition, and some level of crisis is unavoidable. In desperate times, people take desparate measures, and "adopting" IP address ranges that are not used by others in your locality seems a reasonable thing to do when economic survival is at stake.

P.P.S. I saw a report that someone, somewhere, had analysed some data which indicates that IP address allocation rates are increasing and there is a real possibility that we will runout by the end of this year, 2010. Does anyone know where I can find the actual analysis that led to this report?

On Jun 28, 2010, at 5:58 PM, Paul Stewart wrote:

Does anyone know of BGP statistical data based on country? If I wanted to know "top 5 service providers in country XYZ based on number of BGP peers" for example, is there something that can tell me this information? I can manually run a list of AS numbers against tools like Renesys for example but someone has probably already done this?

PCH has this internally, but the AS-to-country mappings are pretty fluid, so we don't hand it out without a lot of caveats... Otherwise policymakers would take it way more seriously than it should be taken, since they love them some rankings. If people generally think we should publish it every day, we'd be willing to, provided we think people are cognizant of the risks of policy folks misusing it. Or marketing folks. Or whatever. Otherwise, email me or Gaurab or Jonny, and we'll set you up with a current listing for whatever countries you're interested in. -Bill

-----Original Message----- From: Michael Dillon [mailto:wavetossed@googlemail.com] Sent: Saturday, June 19, 2010 12:39 PM To: Lee Howard Cc: Todd Underwood; Christopher Morrow; nanog@nanog.org Subject: Re: Todd Underwood was a little late

" "Registered but unrouted" would include space that is in use in large

...

private networks that aren't visible from your standard sources for route views, such as U.S. DoD (6, 11, 22, 26, 28, 29, 30 /8) or U.K. MoD (25/8).

Have you verified each of these address ranges or are you just a mindless robot repeating urban legends?

Turing test? "standard sources for route views" = "route-views" YSSfRVMV

By your definition, there is an awful lot more "registered but unrouted" space and researchers have been reporting on this for 10 years or more. In order to correctly identify what you think you are talking about, you need to take into account the date a range was registered and the date that you scanned the data. If the difference between the two dates is less than some small number, say one year, then it is probably routed space which has not yet been routed but soon will be. Different people will want to set that breakpoint at different timescales for obvious reasons.

I also chose not to define "The Internet" or "routing table" and avoided terms like "DFZ" and "WTF."

I encourage someone to do the work to list all such ranges along with the dates, and supply them as a feed, like Cymru does. Best would be to allow the feed recipient to filter based on age of block.

...

and starting to use addresses like these already (for devices not capable of IPv6) for internal networking (not publically routed).  I believe

Why? Just because it's never been routed doesn't mean it never will be. I said "unlikely to be routed," but using such space is a game of chance. Unless, of course, somebody at one of those organizations said, "This prefix will never be announced to "the Internet," where "the Internet" is defined in a meaningful way to the engineer applying the filter. this

...

is generally considered bad citizenship, but I'm interested in why?

Stupidity. Many people have no historical perspective and think that the only users of I{P address space that matter are ISPs. I don't consider it bad citizenship if the "adopted" space is not routed publicly, and even the definition of "publicly" is hard to pin down. If someone wants to route such space to a 100 or so ASNs in Russia, Kazakhstan, Kirghizstan, Uzbekistan, Afghanistan and China, then I don't think that they are blatantly being bad Internet citizens. Particularly if they carefully chose whose addresses to "adopt".

So you support Todd Underwood's proposal? http://www.nanog.org/meetings/nanog49/presentations/Wednesday/Prefixes_as_Bu ndles_of_Probability%20%281%29.pdf

...

Is there a range most people camp on?

No. And it would be dumb to do that. Smarter is to use some range that nobody else is known to be camping on except the registrant and their network is geographically distant from yours.

Geographically, not topologically, or usefully?

--Michael Dillon

P.S. At this point, the IPv6 transition has failed, unlike the Y2K transition, and

For certain values of "fail." The odds of a dual-stack transition as initially envisioned by the IETF are vanishingly small, but IPv6 will be a significant part of the coping strategies once RIRs allocate their last blocks of IPv4.

P.P.S. I saw a report that someone, somewhere, had analysed some data which indicates that IP address allocation rates are increasing and there is a real possibility that we will runout by the end of this year, 2010. Does anyone know where I can find the actual analysis that led to this report?

Geoff Huston's data are available, I think, so you can crunch your own numbers. InfoWorld had a chart where they only used five months of allocations to project the future, and it's not clear how many data points they used to draw their line. http://www.infoworld.com/d/networking/beware-the-black-market-rising-ip-addr esses-729 As of today, I see ten /8s assigned by IANA in 2010. I count 15 remaining /8s. When IANA has only five remaining, they will allocate one to each RIR. Will the last six months look like the first six months? Faster or slower? http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml Lee

...

...

P.S. At this point, the IPv6 transition has failed, unlike the Y2K transition, and

For certain values of "fail."  The odds of a dual-stack transition as initially envisioned by the IETF are vanishingly small, but IPv6 will be a significant part of the coping strategies once RIRs allocate their last blocks of IPv4.

it'd be interesting to hear michael's reasoning behind 'transition has failed' (to me at least). I agree it doesn't seem like it's moved along as anyone would (aside from Todd) have hoped, but it is moving along.

In January 2000, there was no IT crisis as the result of Y2K rollover. A few companies had a few problems that were mostly sorted out within days. With IPv6, I believe that after IPv4 exhaustion we will have an unavoidable period of chaos that will affect a large number of ISPs of all sizes. The window of opportunity for being well-prepared has been missed. In fact, some of the fallout from this will impact ISPs who have done a lot of preparation, for instance vendors who haven't implemented IPv6 support because so few customers were asking for it.

Currently the only real alternative to ipv6 at the end-user (in ~2yrs) will be giant-CGN-NAT-things or ... that's about it :(

Middleboxes mean increased instability, higher support costs, and wierd problems where customers can't reach a site even though the middlebox is handling traffic correctly, because too many users are sharing the same IP address and it is triggering some kind of traffic shaping at the other end. Middleboxes are a symptom of failure since they force operators to pay for the middleboxes, for training staff on how to operate and scale them, for customer support, and still pay for the normal native IPv6 transition. It will hurt the longer term balance sheet for anyone who is forced down that road, when compared to their competitors who don't have to implement as many or as complex middleboxes.

I don't think we'll have (nor would we have in 2005 even) gotten an ipv7/8/9/10 up and spec'd/coded/wrung-out before ~2 yrs from now either. So, given the cards we have, ipv6 isn't all bad.

On this we agree. The problem is not IPv6, it is the failure to deploy IPv6 soon enough. Not enough trained people, not enough testing, not enough bugs shaken out. --Michael Dillon

P.S. At this point, the IPv6 transition has failed, unlike the Y2K transition, and some level of crisis is unavoidable. In desperate times, people take desparate measures, and "adopting" IP address ranges that are not used by others in your locality seems a reasonable thing to do when economic survival is at stake.

P.P.S. I saw a report that someone, somewhere, had analysed some data which indicates that IP address allocation rates are increasing and there is a real possibility that we will runout by the end of this year, 2010. Does anyone know where I can find the actual analysis that led to this report?

This is where the claim of runout in December 2010 comes from. <http://news.techworld.com/networking/3227420/last-ipv4-addresses-could-run-out-by-december/> --Michael Dillon